正常形式：4 对 5答案

【问题标题】：Normal forms: 4 vs 5正常形式：4 对 5
【发布时间】：2018-11-02 10:00:41
【问题描述】：

我很难理解 4NF、5NF 及其区别。

这是我向不知道的人描述 4/5NF 的方式（或者，我将如何描述实现它的步骤）。我之所以这么说，是因为这将显示我真正理解的内容。

通常，N:N 实体关系应通过为它们的可能组合创建一个连接表来实现。如果有 3 个或更多实体与 N:N 关系相关，则应仔细考虑：

更通用（包括）的解决方案是实现一个连接表，其中包含所有实体作为字段，并将它们的所有组合作为值（行）
但是，如果这些实体之间的关系不是真正的 per-full-tuple case，而是（一些）的（笛卡尔）乘积他们的二元 N:N 关系，然后仔细考虑最小需要的双字段表的数量。
概括 2，总是更喜欢（当然，如果它是正确的）具有尽可能少的字段的连接表。显然，不要创建无用的连接表。
区分上述情况的一个有用提示是，当插入完成时，如果您的心 (!) 告诉您正在做多余或无效的事情，那么您应该选择后面的方法之一。

E1) 维基百科关于 4NF 的页面示例： https://en.wikipedia.org/wiki/Fourth_normal_form

我们有实体餐厅、披萨品种和送货区。我们可以用一个包含所有三个的连接表来实现它们的多对多关系。但是，如果对数据的看法正确，这些三元组仅是 2 个 N:N 关系的乘积：餐厅：比萨和餐厅：外卖区。如果“A1 Pizza”餐厅决定将“Thin Crust”Pizza Variety 添加到其曲目中，那么我必须在“A1 Pizza”的所有交付区域插入一排具有相同餐厅/披萨品种的披萨，这会让人感觉 4 .redundant，或者只插入特定的送货区域，这会让人感觉 4.invalid，因为没有商店会为送货区域提供更少的品种（或者至少，假设我们的规范是这样说的）。

E2) 维基百科关于 5NF 的页面示例： https://en.wikipedia.org/wiki/Fifth_normal_form

我们有实体 Salesman、Brand 和 Type。我们可以用一个包含所有三个的连接表来实现它们的多对多关系。但是，由于“适用以下规则”部分，三元组实际上是可用的 3 个 N:N 关系的（笛卡尔）乘积，因此，正确的方法是为其设置 3 个连接表。 “请注意此设置如何帮助消除冗余。”部分很像我的第 4 点。

这种情况更加令人困惑，因为虽然文章指出“还要注意该表处于 4NF 中”，但事实是，如果该表包含所有行，那么它应该涵盖“以下规则” "，那么它就不会涵盖 4NF！对吧？

所以.. 什么是 E1 和 E2 之间的区别使得其中一个成为 4NF 和其他5NF示例？

【问题讨论】：

阅读我对stackoverflow.com/questions/7083699/… 的回答，了解违反 4NF 如何导致问题的示例。
@philipxy 首先，这不是功课。公式部分只是我试图要求基于示例的答案。其次，我认为我在试图理解差异方面所花费的时间确实保证了我有权提出一些问题。每个问题都可以通过阅读足够的书籍来回答，为什么会有这么多呢？关于多个问题，Q1 和 Q3 实际上更像是一个陈述，我知道我可能不理解，但只是表明我的努力。然后我会进行编辑，谢谢你的那部分。
家庭作业链接仍然是合适的。并非所有问题都是 SO 的主题。很少有事情是通过例子来解释的；一个例子说明了一个解释。如果没有 FD、CK、投影和连接，您将无法理解 NF，并且放入 NF 的算法使用这些。不幸的是，正如我所说，您正试图通过不相关的概念来理解，这些概念并未在您应该阅读的教科书中使用。例如，wiki 文章虽然很差，但仍然是正确的。参考一些关于 NF 定义或算法的学术介绍，并询问您遇到的问题。
请编辑更清楚。例如：“感觉”是什么意思？还是“覆盖”规则或“不覆盖”NF？这些例子有什么“令人困惑”的地方？另外：那些不是“产品”；尽管它们是（自然的）连接。您的意思是“三元组是” 的元素。 “没有商店”应该是“一些商店”吗？您将关系（船舶）基数与 arity 混淆了。您将 n 元关系（ship）的概念与多个二元关系（ship）的概念混淆了。 PS

标签： sql database database-design relational-database database-normalization

【解决方案1】：

E1 和 E2 之间有什么区别，其中一个是 4NF，另一个是 5NF 示例？

非 4NF 和非 5NF 关系都表现出由于 JD 引起的更新异常； 4NF 表示二进制 JD 没有异常，5NF 表示任何数量的 JD 没有异常。维基百科对 4NF 的规范化示例摆脱了二进制 JD——这种关系是一个有问题的 2-way join。对 5NF 的规范化摆脱了 3-way JD——关系是一个有问题的 3-way join。（因为它是从 4NF 开始的，所以它不可能有任何有问题的二进制 JD。）

一个关系（值或变量）在 5NF 中，当它可以被无损地分解（即成为连接回它的投影）（即对应的 JD（连接依赖）成立）时，组件可以被连接回某种顺序，其中每个连接的公共列是原始的超键。（Fagin 的 PJ/NF 论文的隶属度算法。） 4NF 的定义是相同的，只是它可以无损分解为两个投影的方式很重要（即对应的 JD 是二进制的）（即一个对应的 MVD（多值依赖）成立）。

（具有这样一个连接序列的允许 JD 被称为“由 CK（候选键）暗示”。）

我们的想法是，如果我们可以分解为连接回原始的投影，那么我们应该这样做，除非超级键上的连接不会导致任何问题/异常。

当 FD（函数依赖）S -> A 与属性集 R 存在关系时，该关系可在 S U {A} & R - {A} 上无损分解。所以 JD {S U {A}, R - {A}} 成立，MVD S ->> {A} 成立。

来自Which highest normal form is this table in?

关系含义/谓词

另一方面，假设您知道关系的含义 你知道它包含能做出真实陈述的元组的程度来自一个（特征）谓词，可以表达为别人说
    ticket Ticket was submitted by a person with first name Vname
AND there is a person with name Vname Nname
AND ticket Ticket was submitted by a person with last name Nname
Join 的设计使其输出的谓词是与其输入的谓词。所以你会知道检查是否有对应的原始分解满足 JD（即来自合取的关系是否是 original) 等来检查 JD 是否被原件所暗示 CK。

归一化到更高 NF 的要点是，当一个 JD 成立时关系的谓词可以表示为其他人的合取和它们的关系是原始的投影，所以我们可以使用取而代之的是更简单的单独关系，除非我们还不如 JOIN/AND 成对共享 CK 上的关系/谓词，因为有仍然没有更新异常。（如果 FD{x, ...} -> a 成立，那么一定 MVD 持有 & 某个二进制 JD 持有和谓词关系可以表示为... AND a = f(x, ...)。）

【讨论】：

我仍在努力理解，但至少有一些东西可以理解。您的其他链接也很有帮助！当我掌握了“加入依赖”的概念时，我想这一切都会变得清晰。谢谢。

【解决方案2】：

区别不是很重要，因为 4NF 本身并不重要，除非您对数据库设计理论的历史感兴趣。

5NF 要求表满足的每个连接依赖关系 (JD) 必须由该表的超键隐含。 4NF 只关注多值依赖 (MVD) 的概念，但由于 MVD 总是意味着存在相应的 JD，因此根本不需要关注 4NF。 4NF 存在的历史原因是它碰巧首先被发明，然后被 5NF 有效地取代——就像 3NF 被 EKNF/BCNF 取代一样。

【讨论】：

【解决方案3】：

两个维基百科示例：

从BCNF 中的表格开始（整个标题是关键）。
表有冗余。
引入一个规则，它实际上说明可以分解表格。
分解表会消除冗余。
一旦分解，投影（新表）都在 6NF 中（因此在 5、4、..、1 中）

这就是为什么很难看出差异的原因。唯一真正的区别是，在第一种情况 (E1) 中，表格被分解为两个投影，而在第二种情况 (E2) 中，被分解为三个。

这实际上遵循 DB-history。以下内容可能无法准确描述历史事件，但已经足够接近：
曾几何时，一群 DB 数学家聚在一起喝酒（会议），其中一个人说：“嘿，看这个：我在 BCNF 有一张桌子，它有冗余，可以分解成两个投影，冗余消失了”。他们：思考，思考，喝酒，数学，更多的数学，最终有人定义了称为多值依赖和4NF的东西。他们喝了几杯，喝了五杯，然后回家了。
时间流逝，雪落，融化。他们又聚在一起了，你猜怎么着？ “嘿伙计们，BCNF 中的一个表，但这次它可以分解为三个投影。”同上冗余。他们又想又喝。最后一个 4NF 定义并没有削减它。数学，数学，思考，喝酒，思考。尤里卡，所以有人提出了加入依赖的概念，5NF诞生了。派对一直持续到深夜。剩下的就是历史了，从那时起，他们就一直把所有人都搞糊涂了。

什么是加入依赖？非正式地：如果您将关系 R 分解为 N 个投影 (X1 ... XN)，然后将这些投影合并回来，您必须得到相同的关系。不应该有多余的元组，也不应该缺少元组（列也是如此）。顺便说一句，什么是多值依赖？嗯，它是 join 依赖项 的一个特例——一个具有 正好两个 组件 (N=2) 的连接依赖项。

理解规则如何拼写出连接依赖take a look at this SO Q/A。

【讨论】：