我正在为一家虚构的在线披萨店设计一个数据库。
考虑一个表，其连接键为 order_nr 和 Pizza_article_nr。
披萨配料不依赖于披萨，因为它们可以独立存在。然而它们总是与披萨联系在一起。
披萨配料是否单独存在，以便我在 3NF 中处理它们，或者“配料”列是否在 2NF 中失败，因为它确实依赖于实际现实中的披萨？
您感到困惑的根源在于您在多个地方看到了钥匙，并且您认为这一定是冗余的。 事实是，在标准化过程中，您需要忽略键中的伪冗余。 这并不是真正的冗余，而只是信息的重复。 重复是有原因的，即表示实体之间的关系。
如果您有一个可用的配料表，即主键是 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，因为唯一出现在多个地方的就是外键。
他们是吗？
恕我直言，披萨店的业务是
准确地库存尚未“与披萨相关”的配料，而这正是为了能够制作披萨。 你所说的相当于“发动机总是与汽车相连”。 一旦汽车离开生产车间，这种说法可能是正确的，但只要发动机在生产车间的库存/供应中等待“连接到汽车”，它就肯定是“不”正确的。