我正在学习数据库规范化并加入依赖关系和 5NF。我很难过。任何人都可以给我一些多值依赖规则的实际例子：
MVD3 :(传递性）如果X↠Y和Y↠Z，则X↠（Z - Y）。
答案 0 :(得分：1)
功能依赖/归一化理论和直到并包括BCNF的正常形式是在所有数据属性（列/类型/ ......）在某种意义上都是“原子”的假设下开发的。这种“某种意义”长期以来一直被弃用，但基本上它归结为“表格中的单个单元格值本身不能保持多种价值”这一概念。想想一下，ISBN号的文本CSV列表，一个表格在表格的单元格中出现（真正的嵌套表格），...
现在想象一下课程，教授和学习用书作为课程材料的例子。想象一下，所有这些都是在一个单独的3列表中建模的，该表说“教授（P）教授课程（C）并使用书籍（B）作为课程材料。”如果任何特定课程（Cn）可以使用多本书（B），并且任何一位教授（Pn）可以教授不止一门课程（C），并且可以有不止一位教授（P）教学任何给定的课程（Cn），那么这个表显然是全键的（键是完整的属性集{P，C，B}）。
这意味着该表满足BCNF。
但是现在想象一下这样的规则：“用于任何特定课程（Cn）的书籍的集合必须是相同的，无论哪个教授教授它。”。< / p>
在将规范化发展到现在通常已知的形式的日子里，不允许有表格列（关系属性）本身就是表格（关系）。 （因为这样的设计被认为违反了1NF，这个概念现在被认为是可疑的。）
想象一下，我们确实允许将关系属性建模为类型关系。然后我们可以如下建模我们的3列表（/关系）：“教授（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-＆gt; SB来消除我们的{P，C，SB}设计中的NF违规应该做些什么：
我们会将表分成两个独立的表{P，C}和{C，SB}，其中包含密钥{P，C}和{C}。两个表都满足BCNF。
但是我们仍然拥有这个包含ISBN号的集的SB属性。处理这个可以通过应用像“UNGROUPING”这样的技术来完成。将此应用于我们的{C，SB}表将获得{C，B}表，其中B是ISBN书号（或您希望在数据库中使用的任何标识符），表的关键是{C ，B}。这与我们消除4/5 NF违规!!!我们将获得的设计完全相同!!!