第二范式问题

Question

当我正常化时，我对自己的思维方式缺乏安全感。我正在为一家虚构的在线披萨店设计一个数据库。

考虑一个表，其连接键为 order_nr 和 Pizza_article_nr。

我被披萨配料困住了。我认为，从根本上来说，他们不依赖披萨，因为从技术上讲，他们可以独立存在。但实际上它们总是与披萨联系在一起。那么它们是否独立存在，以便我在 3NF 中处理它们，或者“配料”列是否在 2NF 中失败，因为它确实依赖于实际现实中的披萨？

Answer 1

您感到困惑的根源在于您在多个地方看到了钥匙，并且您认为这一定是冗余的。事实是，在标准化过程中，您需要忽略键中的伪冗余。这并不是真正的冗余，而只是信息的重复。重复是有原因的，即表示实体之间的关系。

如果您有可用的配料表，即主键是 topping_id，那么该表会告诉您哪个披萨上有哪种配料，即 3NF。如果您没有有配料查找表，而是将配料名称放入披萨成分表中，那么我想很多人会说您违反了 2NF。如果顶级名称“不是”不可变，那么他们就是对的。如果顶级名称碰巧是不可变的，则有一个参数表明顶级名称是隐式顶级表的主键。然而，作为最佳实践，一般情况下使用无意义的密钥是件好事 - 除非您能根据具体情况提出使用有意义的密钥的充分理由。因此，请避免在披萨成分表中使用配料名称。 由于您经常可以一次订购多个披萨（我削减了代码并且有两个十几岁的儿子，所以我根据经验发言）您的模式可能应该是这样的：

ORDER:
  order_id (PK)
, date_taken
, deliver_to (or FK to a CUSTOMER table if you're being ambitious)

PIZZA:
  pizza_id (PK)
, order_id (FK)
, size

TOPPING:
  topping_id (PK)
, topping_name

PIZZA_COMPOSITION:
, pizza_id (PK, FK)
, topping_id (PK, FK)
, quantity (My kids insist on double cheese)
, coverage (One likes half plain cheese...)

此模式是 3NF，因为唯一出现在多个位置的就是外键。

Answer 2

他们是吗？

恕我直言，披萨店的业务是

准确地

库存尚未“与披萨相关”的配料，而这正是为了能够制作披萨。 你所说的相当于“发动机总是与汽车相连”。一旦汽车离开生产车间，这种说法可能是正确的，但只要发动机在生产车间的库存/供应中等待“连接到汽车”，它就肯定是“不”正确的。