我正在为一家虚构的在线披萨店设计一个数据库。
考虑一个表,其连接键为 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,因为唯一出现在多个地方的就是外键。
他们是吗?
恕我直言,披萨店的业务是
准确地库存尚未“与披萨相关”的配料,而这正是为了能够制作披萨。 你所说的相当于“发动机总是与汽车相连”。 一旦汽车离开生产车间,这种说法可能是正确的,但只要发动机在生产车间的库存/供应中等待“连接到汽车”,它就肯定是“不”正确的。