对 5NF 的依赖
Dependencies on 5NF
根据我的 earlier question on 5NF，我想扩展问题并在此处添加更多问题。
同样，以下 table 取自 online resource on normalization：
STOCK
(Agent Company Product)
a1 c1 p1
a1 c2 p1
a1 c1 p3
a1 c2 p4
a2 c1 p1
a2 c1 p2
a3 c2 p4
我的问题是：
- 为什么上面的例子中说没有MVD？是因为属性之间的相互关系吗？
- 为什么上面的关系是4NF而不是5NF？
多值依赖项 (MVD) 适用于 4NF，
将依赖项 (JD) 加入 5NF。
A table 有 4NF 问题，当它有 2 个相互独立的多值列时，所有值的组合都已存储。然而，这个问题从来没有用 "multivalued attributes" 来表述；相反，它是用 MVD 表示的。我个人觉得用 JD 来定义它更容易。在那种情况下，您将拥有一个包含 2 个组件的 JD。
因此，让我们将其应用到您的示例中。您首先需要对
进行预测
STOCK(Agent Company Product)
a1 c1 p1
a1 c2 p1
a1 c1 p3
a1 c2 p4
a2 c1 p1
a2 c1 p2
a3 c2 p4
首先我们选择 Agent, Company
AC(Agent Company)
a1 c1
a1 c2
a2 c1
a3 c2
您只需省略 Product 列，然后消除重复项。
其次我们做代理，产品
AP(Agent Product)
a1 p1
a1 p3
a1 p4
a2 p1
a2 p2
a3 p4
你现在加入他们并获得：
ACP1
a1 c1 p1
a1 c1 p3
a1 c1 p4
a1 c2 p1
a1 c2 p3
a1 c2 p4
a2 c1 p1
a2 c1 p2
a3 c2 p4
如您所见，ACP1 与原来的 table STOCK 不同，因此没有 JD 和 2 个组件。因此没有 MVD，因此 4NF 没有问题。它在 4NF 中。
当 JD 存在 3 个（或更多）组件时，5NF 会出现问题。
在手头的示例中，由于只有 3 列，我们唯一可以做的其他投影是公司、产品：
CP(Company Product)
c1 p1
c2 p1
c1 p3
c2 p4
c1 p2
我们现在需要将 3 个投影连接回去，看看我们是否得到原始 table。一半的工作已经完成，因为那是 ACP1。我们现在需要加入它与 CP。这产生：
ACP2
a1 c1 p1
a2 c1 p1
a1 c2 p1
a1 c1 p3
a1 c2 p4
a3 c2 p4
a2 c1 p2
由于在ACP1中我们已经有了所有的列，所以加入CP的效果是不加列；相反，它是过滤掉某些行。
如你所见，ACP2确实和STOCK一样。行的顺序不同这一事实并不重要；你得到完全相同的行。所以你有一个 JD，因此 5NF 有问题； STOCK 不在 5NF 中。
解决方案是将其拆分（在 3 table 秒内），这并不难；它只是 AC、AP 和 CP。
希望对您有所帮助。
LR
4NF 和 5NF 有点抽象，尤其是当您尝试以数学方式理解它们时。
当您使用常识方法时，您可能会惊讶于事情竟然如此平庸。
为了知道多个投影是否一起构成连接依赖项，您首先要在原始 table 上进行这些投影，然后将生成的 table 重新连接在一起.如果这产生了与原始相同的 table，则这些组件有一个 JD。
例如：我正在使用您所引用的幻灯片的符号，更具体地说在第 70 页：
* { AC(Agent, Company), AP(Agent, Product), CP(Company Product) }
是一个包含 3 个组件的 JD，我们在我之前的 post 中看到过，我在那里完成了程序，它成立。
同时
* { AC(Agent, Company), AP(Agent, Product) }
是一个有 2 个分量的 JD，我们已经看到它不成立。
现在对于2个组件的JD，他们真的说你和一对MVD一样
Agent ->-> Company
Agent ->-> Product
你也可以更简洁地写成
Agent ->-> Company | Product
FD（例如 X -> Y）意味着对于给定的 X 值，您将始终看到相同的 Y 值。
因此，如果您找到 X 为 5 且 Y 为 'f' 的第一行，并且您进一步查找值为 5 的第二个 X，则 Y 将再次具有值 'f'。
如果没有，则没有 FD。
您可以用相同的方式直观地理解 MVD，但这次 Y 有多个值分布在几行中。
所以对于 X ->-> Y，X 可能是 5，你会发现一个 Y 在一行上有（假设）'f'，在另一行上有 'j'，还有 'm'在另一排。
然后你期望其他 5s 也有 'f', 'j', 'm'.
出于某种原因，我觉得这不容易申请。相反，我更喜欢有 2 个组件的 JD。
我也注意到你说的MVDs agent->->company, company->->product, agent->->product。
对于 4NF，中间的太多了。对于 5NF：它不是关于 MVD，而是关于具有 3 个组件的 JD。
在你最初的问题中你问了：
why is it stated that there is no MVD in the above example?
Is it because of the interrelationships between the attributes?
我完成了 2 个组件的 JD 程序，显示 JD 不成立，因此也没有 MVD。因此 4NF 是可以的；它在 4NF 中。
所以不是，不是"because of the interrelationships between the attributes"，我连'interrelationships'是什么都不知道，只知道FD，MVD，JD。没有 MVD，因为程序告诉我的。
Why is the above relation in 4NF and not in 5NF?
我也用 3 个组件完成了程序并显示 JD 成立，所以关系不在 5NF 中。
我再次知道这一点，因为我经历了允许我测试（在样本数据上）JD 存在的假设的过程。
在更直观的层面上：
幻灯片状态（第 4 点，第 67 页）
If an agent sells a product and he represents the company making that product, then he sells that product for that company.
这就是导致元组强制的业务规则。这是 wat 强制执行某些组合（公司和产品）。
当然，这就是我们想要在数据中检测到的，因为它会导致 JD（有 3 个组件，但你现在知道了）。
不在 5NF 中的关系通常有一个业务规则，当其他行存在时强制某些行存在。
因此，当代理商 a1 销售产品 p1（可能是另一家公司，假设是 c2）并且公司 c1 恰好生产该产品时，(a1 c1 p1) 必须存在一行，因为 (a1 c2 p1) 也存在。
回顾一下：
A sells P AP
A represents C AC
C makes P CP
==> A sells P made by C STOCK
so the following JD holds :
* { AP(Agent, Product), AC(Agent, Company), CP(Company Product) }
看这里，深思；它会来找你 ;-)
没错。
数学公式很笨拙。你应该明白，但正式的定义让人难以理解的是：有 3 种 JD：1) 琐碎的 JD，2) 键隐含的 JD，以及 3) 其他 JD。
前两个不是问题，因此是允许的；第三个是问题，您应该通过拆分 table.
来解决这些问题
1) trivial 表示JD 中的一个组件是原始table 的整个标题。 （见幻灯片第 70 页）
2) implied by keys 表示每个组件都包含一个key；那是一个完整的密钥，而不仅仅是密钥的一部分。 （见第 71 页）
3) 其他 JD 有问题：它们是 tuple-forcing 个。
"AP, AC and CP are in 5NF because all these projections don't have any JD, is that right?". 没错：您需要一个具有 3 个组件的连接依赖关系，但在每个关系中您只有 2 个属性。所以这是不可能的。还要注意，如果您将这两个属性都作为组件之一包括在内，则 JD 变得微不足道。
根据我的 earlier question on 5NF，我想扩展问题并在此处添加更多问题。
同样，以下 table 取自 online resource on normalization：
STOCK
(Agent Company Product)
a1 c1 p1
a1 c2 p1
a1 c1 p3
a1 c2 p4
a2 c1 p1
a2 c1 p2
a3 c2 p4
我的问题是：
- 为什么上面的例子中说没有MVD？是因为属性之间的相互关系吗？
- 为什么上面的关系是4NF而不是5NF？
多值依赖项 (MVD) 适用于 4NF， 将依赖项 (JD) 加入 5NF。
A table 有 4NF 问题，当它有 2 个相互独立的多值列时，所有值的组合都已存储。然而，这个问题从来没有用 "multivalued attributes" 来表述；相反，它是用 MVD 表示的。我个人觉得用 JD 来定义它更容易。在那种情况下，您将拥有一个包含 2 个组件的 JD。
因此，让我们将其应用到您的示例中。您首先需要对
进行预测STOCK(Agent Company Product)
a1 c1 p1
a1 c2 p1
a1 c1 p3
a1 c2 p4
a2 c1 p1
a2 c1 p2
a3 c2 p4
首先我们选择 Agent, Company
AC(Agent Company)
a1 c1
a1 c2
a2 c1
a3 c2
您只需省略 Product 列，然后消除重复项。
其次我们做代理，产品
AP(Agent Product)
a1 p1
a1 p3
a1 p4
a2 p1
a2 p2
a3 p4
你现在加入他们并获得：
ACP1
a1 c1 p1
a1 c1 p3
a1 c1 p4
a1 c2 p1
a1 c2 p3
a1 c2 p4
a2 c1 p1
a2 c1 p2
a3 c2 p4
如您所见，ACP1 与原来的 table STOCK 不同，因此没有 JD 和 2 个组件。因此没有 MVD，因此 4NF 没有问题。它在 4NF 中。
当 JD 存在 3 个（或更多）组件时，5NF 会出现问题。 在手头的示例中，由于只有 3 列，我们唯一可以做的其他投影是公司、产品：
CP(Company Product)
c1 p1
c2 p1
c1 p3
c2 p4
c1 p2
我们现在需要将 3 个投影连接回去，看看我们是否得到原始 table。一半的工作已经完成，因为那是 ACP1。我们现在需要加入它与 CP。这产生：
ACP2
a1 c1 p1
a2 c1 p1
a1 c2 p1
a1 c1 p3
a1 c2 p4
a3 c2 p4
a2 c1 p2
由于在ACP1中我们已经有了所有的列，所以加入CP的效果是不加列；相反，它是过滤掉某些行。
如你所见，ACP2确实和STOCK一样。行的顺序不同这一事实并不重要；你得到完全相同的行。所以你有一个 JD，因此 5NF 有问题； STOCK 不在 5NF 中。
解决方案是将其拆分（在 3 table 秒内），这并不难；它只是 AC、AP 和 CP。
希望对您有所帮助。
LR
4NF 和 5NF 有点抽象，尤其是当您尝试以数学方式理解它们时。 当您使用常识方法时，您可能会惊讶于事情竟然如此平庸。
为了知道多个投影是否一起构成连接依赖项，您首先要在原始 table 上进行这些投影，然后将生成的 table 重新连接在一起.如果这产生了与原始相同的 table，则这些组件有一个 JD。
例如：我正在使用您所引用的幻灯片的符号，更具体地说在第 70 页：
* { AC(Agent, Company), AP(Agent, Product), CP(Company Product) }
是一个包含 3 个组件的 JD，我们在我之前的 post 中看到过，我在那里完成了程序，它成立。
同时
* { AC(Agent, Company), AP(Agent, Product) }
是一个有 2 个分量的 JD，我们已经看到它不成立。
现在对于2个组件的JD，他们真的说你和一对MVD一样
Agent ->-> Company
Agent ->-> Product
你也可以更简洁地写成
Agent ->-> Company | Product
FD（例如 X -> Y）意味着对于给定的 X 值，您将始终看到相同的 Y 值。 因此，如果您找到 X 为 5 且 Y 为 'f' 的第一行，并且您进一步查找值为 5 的第二个 X，则 Y 将再次具有值 'f'。 如果没有，则没有 FD。
您可以用相同的方式直观地理解 MVD，但这次 Y 有多个值分布在几行中。 所以对于 X ->-> Y，X 可能是 5，你会发现一个 Y 在一行上有（假设）'f'，在另一行上有 'j'，还有 'm'在另一排。 然后你期望其他 5s 也有 'f', 'j', 'm'.
出于某种原因，我觉得这不容易申请。相反，我更喜欢有 2 个组件的 JD。
我也注意到你说的MVDs agent->->company, company->->product, agent->->product。 对于 4NF，中间的太多了。对于 5NF：它不是关于 MVD，而是关于具有 3 个组件的 JD。
在你最初的问题中你问了：
why is it stated that there is no MVD in the above example?
Is it because of the interrelationships between the attributes?
我完成了 2 个组件的 JD 程序，显示 JD 不成立，因此也没有 MVD。因此 4NF 是可以的；它在 4NF 中。
所以不是，不是"because of the interrelationships between the attributes"，我连'interrelationships'是什么都不知道，只知道FD，MVD，JD。没有 MVD，因为程序告诉我的。
Why is the above relation in 4NF and not in 5NF?
我也用 3 个组件完成了程序并显示 JD 成立，所以关系不在 5NF 中。 我再次知道这一点，因为我经历了允许我测试（在样本数据上）JD 存在的假设的过程。
在更直观的层面上： 幻灯片状态（第 4 点，第 67 页）
If an agent sells a product and he represents the company making that product, then he sells that product for that company.
这就是导致元组强制的业务规则。这是 wat 强制执行某些组合（公司和产品）。 当然，这就是我们想要在数据中检测到的，因为它会导致 JD（有 3 个组件，但你现在知道了）。 不在 5NF 中的关系通常有一个业务规则，当其他行存在时强制某些行存在。 因此，当代理商 a1 销售产品 p1（可能是另一家公司，假设是 c2）并且公司 c1 恰好生产该产品时，(a1 c1 p1) 必须存在一行，因为 (a1 c2 p1) 也存在。
回顾一下：
A sells P AP
A represents C AC
C makes P CP
==> A sells P made by C STOCK
so the following JD holds :
* { AP(Agent, Product), AC(Agent, Company), CP(Company Product) }
看这里，深思；它会来找你 ;-)
没错。
数学公式很笨拙。你应该明白，但正式的定义让人难以理解的是：有 3 种 JD：1) 琐碎的 JD，2) 键隐含的 JD，以及 3) 其他 JD。
前两个不是问题，因此是允许的；第三个是问题，您应该通过拆分 table.
来解决这些问题1) trivial 表示JD 中的一个组件是原始table 的整个标题。 （见幻灯片第 70 页） 2) implied by keys 表示每个组件都包含一个key；那是一个完整的密钥，而不仅仅是密钥的一部分。 （见第 71 页） 3) 其他 JD 有问题：它们是 tuple-forcing 个。
"AP, AC and CP are in 5NF because all these projections don't have any JD, is that right?". 没错：您需要一个具有 3 个组件的连接依赖关系，但在每个关系中您只有 2 个属性。所以这是不可能的。还要注意，如果您将这两个属性都作为组件之一包括在内，则 JD 变得微不足道。