当我正常化时，我对自己的思维方式感到不安全。我正在为一家虚构的在线披萨店设计一个数据库。
考虑一个表，其连接键为 order_nr 和 Pizza_article_nr。
我不喜欢披萨配料。我认为从字面上看，他们不依赖披萨，因为从技术上讲，他们可以独立存在。然而实际上，它们总是与披萨有关。那么它们是独立存在的，因此我将在 3NF 中处理它们，还是“toppings”列在 2NF 中失败，因为它确实依赖于实际现实中的比萨饼？
【问题讨论】：
标签： database-design normalization
“但实际上它们总是与披萨有关。”
是吗？
比萨店的业务是，恕我直言，恰好库存中的配料尚未“与比萨饼相关联”，而这正是为了达到目的能够制作比萨饼。
您所说的相当于“引擎始终与汽车相连”。一旦汽车离开生产车间，该陈述可能是正确的，但只要发动机在生产车间的库存/供应中等待获取，它就肯定不是正确的 “连接到汽车”。
【讨论】：
您感到困惑的根源在于您在多个地方看到了密钥，并且您认为它一定是冗余的。事实是，在规范化中，您需要忽略密钥中的伪冗余。这不是真正的冗余，而仅仅是信息的重复。重复是有原因的，即表示实体之间的关系。
如果你有一个可用的配料表，即主键是 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，因为出现在多个地方的唯一内容是外键。
【讨论】：