是否有可能完全摆脱所谓的“虚假元组”？

Question

是否有可能完全摆脱所谓的“虚假元组”？

例如：在教科书中的这个例子中，有一个原始表：

我认为它的两个预测没有任何问题：

但是他们的加入仍然产生虚假的元组：

（这些数字来自ToddEverett 的回答。]

Answer 1

这是一个很好的问题。 超出BCNF 的规范化非常难以理解。希望我能提供一个有意义的答案。多亏了 Fabian Pascal 的实用数据库基础系列，我在这些概念上挣扎了 20 多年，才最终弄明白了它们。

提供的示例是一个EmpRoleProjR 表，如下所示：

然后继续显示原始EmpRoleProjR 表的投影，如下所示：

你看不出什么毛病基表的原因Table 1，并Table 2为您不考虑相关性规则（在这种情况下，多值依赖（MVD）规则）中描述的业务规则的商业模式定义。如果我们为了举例而假设在业务规则中没有定义 MVD，那么 EmpRoleProj 就在 5NF 中，尽管“出现”了冗余。例如，Smith 是设计师的信息似乎被冗余存储。亚马逊项目中需要设计师的信息似乎也被冗余存储。虽然情况似乎如此，但通过了解实际上这些不是MVD，实际情况是 Smith恰好是在几个项目的设计师，但它不是一个事实，史密斯是一名设计师，因此这一事实应不进行推断。当表 1 和表 2 连接时，结果：

显示琼斯是尼罗河项目的设计师，但我们知道事实并非如此。

让我们假设，而不是商业模式没有说有分别的MVD的empName-->>role和role-->>projName。在这种情况下，这些 MVD 的意思是，如果员工扮演某个角色，并且该角色在某个项目中，则根据定义，该员工在该项目中扮演该角色。在这个例子中，同样的EmpRoleProj表，现在不是在5NF，现在也从冗余受到影响。现在，这样的事实，史密斯是一名设计师，有必要对亚马逊的项目设计师的冗余存储为这些事实可以推断，从加入表1和表2！同样，现在将表 1 和表 2 连接起来没有由于根据 MVD 定义的业务规则，推断 Jones 是 Nile 项目的设计师现在是一个事实，因此会产生一个虚假的元组。

这就是为什么你不能在不知道依赖关系和定义的键的情况下评估任何 R 表的正常形式。做出任何假设，即使是您认为合理的假设，都可能是危险的。如果你被问到 R 表的范式是什么，你必须要求评估依赖关系。除了 Fabian 的系列论文之外，Chris Date 的作品还提供了有关归一化理论的最佳信息。