正常化。寻找关于什么应该是 3NF 的反馈答案

【问题标题】：Normalization. Looking for feedback on what should be 3NF正常化。寻找关于什么应该是 3NF 的反馈
【发布时间】：2017-05-01 01:47:27
【问题描述】：

我正在我的数据库类中为超市创建一个数据库。数据库至少需要 3nf，但如果可能，BCNF。有人可以告诉我这是否令人满意吗？我相信是的，我只是想确定一下。

【问题讨论】：

不要将东西放入 SYSTEM 或 SYS 架构中。
相关：orderitems 也应该有自己的价格字段。
请始终尽可能使用文本。例如这张图的全部内容。
正常化到 BCNF 使用函数依赖，但你没有提到它们。这表明您缺乏一些关于标准化的基本概念。为什么你“相信它是”？

标签： database entity-relationship database-normalization 3nf bcnf

【解决方案1】：

这些值看起来都是原子的，我看到的唯一问题是在您的 System.orders 表中。 3NF 不应存储计算值。

Here's a good topic page on calculated values.

另一个我不确定的是 System.orderItems 上缺少主键。有人告诉我，每个表都有一个主键是一种很好的做法。在您的关系表上，您将 orderId 和 itemId 都设为链接的主键。

Here's a good discussion on the need for a Primary Key.

希望对您有所帮助。

【讨论】：

System.Orders 表中的 Total - Total 是数量 * 价格。当我学习规范化时，值必须是原子的。计算值不是原子的，它取决于其他两个表中的值。
“Calculated”、“computed”和“generated”用于 DBMS 评估的列。在规范化中可以忽略这样的列，因为它是计算出来的。这个问题并没有说它是在这个意义上计算的。无论如何，表所在的 NF 是其可能值的函数，但 TOTAL 也将是其他一些表的函数，并且该约束/冗余不会影响 NF。（尽管它与良好的设计有关。）（在 Orders 中也是产品的总和。）在 OrderItems（作为产品）中也是同样的情况。 Orderitem 中的价格和数量都违反了 3NF。
您还误用了“原子”一词，它与函数依赖无关。（虽然“atomicity”与“规范化”和“1NF”的一些定义有关，但这些定义或多或少与更高的 NF 无关，它不关心列的类型。）
原子，该值不可分割或不能进一步分解。根据定义，总值是由其他两个表中的值组成的，是可分割的和可分解的。它不是原子的，也不是 3NF。 stackoverflow.com/questions/24029620/what-is-atomicity-in-dbms
我刚刚给出了我对该链接问题的答案的链接。（而且 MikeSherrill'CatRecall' 的回答也很好。）你的评论不清楚，我不知道你想说什么，但它看起来不像我还没有反驳过的任何东西。您需要从教科书、演示文稿或课程中了解 FD 和更高 NF 的标准化。（很多都在线。）祝你好运。