披萨配料是否单独存在于 3NF 中,还是列“配料”存在? 2NF 失败是因为它确实依赖于现实中的披萨吗?

发布于 2024-10-30 18:13:37 字数 1432 浏览 3 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

孤君无依 2024-11-06 18:13:37

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

如果您有一个可用的配料表,即主键是 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,因为唯一出现在超过有一个地方是外键。

The source of your confusion is that you are seeing keys in more than one place and you're thinking that it must be redundancy. The fact is that in normalization you need to ignore the psuedo-redundancy in the keys. This is not real redundancy but merely repetition of information. The repetition is there for a reason, namely to indicate the relationship between entities.

If you have a table for toppings that are available, i.e. the primary key is topping_id, then a table that tells you which topping is on which pizza is 3NF. If you don't have a lookup table for toppings and instead put the topping name in your pizza composition table, then I think a lot of people would say you're violating 2NF. They would be right if topping names are not immutable. If the topping names happen to be immutable then there's an argument to say that the topping name is your primary key to an implicit topping table. However, as a matter of best practice, it's good to have meaningless keys in general - unless you can come up with a really good reason to use a meaningful key on a case by case basis. Therefore avoid using topping name in your pizza composition table.

Since you can often order more than one pizza at a time (I cut code and have two teenage sons, so I speak from experience) your schema should probably be along these lines:

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...)

This schema is 3NF because the only thing that appears in more than one place is a foreign key.

吹泡泡o 2024-11-06 18:13:37

“但实际上它们总是与披萨联系在一起。”

他们是吗?

恕我直言,披萨店的业务就是库存尚未“与披萨相关”的配料,而这恰恰是为了 >能够制作披萨

你所说的相当于“发动机总是与汽车相连”。一旦汽车离开生产车间,这种说法可能是正确的,但只要发动机在生产车间的库存/供应中等待得到,它就肯定是不正确的。 “连接到汽车”。

"Yet in reality they're always connected to a pizza."

Are they ?

The business of a pizza shop is, imho, precisely to have toppings in stock that are not yet "connected to a pizza", and this precisely for the purpose of being able to create a pizza.

What you're saying is equivalent to "engines are always connected to a car". That statement may be true once the car leaves the production hall, but it most certainly is not true as long as the engine is waiting in the production hall's stock/supply to get "connected to a car".

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文