范式：4 vs 5

我正在努力理解 4NF、5NF 以及它们的区别。

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

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

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

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

我们有实体餐厅、披萨品种和送货区。我们可以通过一个连接表（包括所有三个）来实现它们的多对多关系。然而，如果正确地思考这些数据，这些三元组只是 2 个 N:N 关系的产物：餐厅：比萨饼和餐厅：送货区。如果“A1 Pizza”餐厅决定将“Thin Crust”披萨品种纳入其保留范围，那么我必须将具有相同餐厅/披萨品种的一行插入“A1 Pizza”的所有送货区域，这将感觉 4 .多余的，或者只插入特定的送货区域，这会让人感觉无效。 4.因为没有商店会为送货区域提供更少的品种（或者至少，我们的规范是这么说的）。

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

我们有实体“推销员”、“品牌”和“类型”。我们可以通过一个连接表（包括所有三个）来实现它们的多对多关系。然而，由于“以下规则适用”部分，三元组实际上是 3 个可用的 N:N 关系的（笛卡尔）乘积，因此，正确的方法是为其拥有 3 个连接表。 “注意此设置如何帮助消除冗余。”这部分很像我的第四点。

这种情况变得更加令人困惑，因为虽然文章指出“另请注意该表位于 4NF 中”，但事实是，如果该表具有它应该包含的所有行，以便涵盖“以下规则”，那么它不会涵盖 4NF！正确的？

那么..什么是 E1 和 E2 之间的差异使得其中一个成为 4NF，并且 还有一个 5NF 的例子吗？

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

由于 JD，非 4NF 和非 5NF 关系都表现出更新异常； 4NF 意味着二进制 JD 没有异常，5NF 意味着任何数量的 JD 都没有异常。维基百科示例标准化为 4NF 消除了二进制 JD——该关系是一个有问题的双向连接。 5NF 规范化消除了 3 路 JD——该关系是一个有问题的 3 路连接。 （由于它是从 4NF 开始的，所以它不可能有任何有问题的二进制 JD。）

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

（具有这样的连接序列的这种允许的 JD 被称为“由 CK（候选键）隐含”。）

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

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

From 该表采用哪种最高范式？ https://stackoverflow.com/q/47729927/3404097

关系含义/谓词

另一方面，假设你知道关系的含义到 您知道它包含做出真实陈述的元组的程度 从一个（特征）谓词可以表示为合取 其他人说

    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 （即 合取关系是否是 原件），以检查 JD 是否是原件所暗示的 CK。

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