我正在学习数据库规范化和连接依赖项和 5NF。我过得很艰难。谁能给我一些多值依赖规则的实际例子：
MVD3：（传递性）如果 X ↠ Y 和 Y ↠ Z，则 X ↠ (Z − Y)。
【问题讨论】：
标签： database normalization database-normalization
函数依赖/归一化理论和包括 BCNF 在内的范式，是在所有数据属性（列/类型/...）在某种意义上是“原子”的假设上发展起来的。这种“某种意义”现在早已被弃用，但本质上它归结为“表格中的单个单元格值本身不能包含多个值”的概念。想一想，一个 ISBN 编号的文本 CSV 列表，一个在表格的单元格中显示为值的表格（真正的嵌套表格），......
现在想象一个示例，其中课程、教授和学习书籍用作课程材料。想象一下，所有这些都建模在一个 3 列表中，上面写着“教授 (P) 教授课程 (C) 并使用书籍 (B) 作为课程材料”。如果任何给定课程 (Cn) 可以使用多于一本书 (B) 并且任何给定教授 (Pn) 可以教授多于一门课程 (C) 并且可以有多个教授 (P) 教学任何给定的课程（Cn），那么这个表显然是全键（键是完整的属性集 {P,C,B} ）。
这意味着这个表满足 BCNF。
但现在想象一下，有一条规则大意是“用于任何给定课程 (Cn) 的 set 书籍必须相同，无论哪位教授教授它。”。
在规范化发展为现在众所周知的形式的日子里，不允许拥有本身就是表（关系）的表列（关系属性）。 （因为这样的设计被认为违反了 1NF，这个概念现在被认为是可疑的。）
想象一下，我们确实被允许将关系属性建模为关系类型。然后我们可以对我们的 3 列表 (/relation) 建模如下：“教授 (P) 教授课程 (C) 并使用 THE SET OF BOOKS (SB) 作为课程材料。”。属性 SB 将不再是 ISBN 编号，就像之前更明显的设计中那样，但它将是一个（可能是一元的）RELATION，包含整个 ISBN 编号集。如果我们像这样绘制我们的设计，然后我们考虑我们的规则“所有教授对同一门课程使用相同的书集”，那么我们看到该规则现在可以表示为从 (C) 到 (SB) 的 FD ！！！这意味着我们手头违反了较低的 NF ！！！
4 和 5 NF 是由此类问题产生的（其中单个属性值 -courseID (C)- 的出现导致要求出现 A MULTITUDE 行（多个(B) ISBn 数字) 很早就被识别出来，但没有当前被认为是最好的解决方案 (RVA)，被认为是有效的解决方案。因此，4 和 5 NF 被创建为“新的和更进一步的范式”，其中如果 RVA 被认为是一种有效的设计方法，那么当时存在的 2、3 和 BC NF 的定义已经足以应对当前的情况。
为了支持这一说法，让我们看看在使用 FD C->SB 的 {P,C,SB} 设计中应该采取哪些措施来消除 NF 违规：
我们会将表拆分为两个单独的表 {P,C} 和 {C,SB}，键分别为 {P,C} 和 {C}。两个表都满足 BCNF。
但是我们仍然有这个 SB 属性，它包含一个 set ISBN 号码。可以通过应用“UNGROUPING”之类的技术来解决这个问题。将此应用于我们的 {C,SB} 表将得到一个 {C,B} 表，其中 B 是 ISBN 书号（或您喜欢在数据库中使用的任何标识符），表的键是 {C ，乙}。如果我们消除了 4/5 NF 违规，这与我们得到的设计完全相同！！！
【讨论】：