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

Question

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

例如：在this example 中，我看不出基表有什么问题。

但是，加入后它仍然会生成虚假元组。

Answer 1

如果关系 R 等于 R1 JOIN R2 JOIN ... 那么我们可以使用 R1 JOIN R2 JOIN ... 代替 R。显然。但是 R1, R2, ... 将是 R 的投影。而如果我们采用 R 的投影 R1', R2', ... 其中 R not 等于 R1' JOIN R2' JOIN .. . 那么我们不能使用 R1' JOIN R2' JOIN ... 而不是使用 R。显然。但是 R1' JOIN R2' JOIN ... 会像 R 加上其他一些元组。与 R 和 R1 JOIN R2 JOIN ... 的值相比，它们是“虚假元组”。但他们属于在 R1' JOIN R2' JOIN ... 。 那不是 R。要“摆脱虚假元组”只是不要使用 R1' JOIN R2' JOIN ... for R。但是，为什么会你呢？仅当您认为 R JOIN 的任何旧投影都返回到 R 时。但他们没有。但是，为什么会他们呢？

所以你的问题措辞很奇怪。我们想要替换一个表，该表是其他一些连接的表。我们不想要替换一个不是由其他人连接的表。所以我们可以总是通过不这样做“摆脱虚假元组”。

规范化是关于用其他人替换作为其他人连接的表。当 R = R1 JOIN R2 JOIN ...我们说 JD（连接依赖）在 R 中成立。与公认的观点相反，如果我们正在寻找并且知道我们的表的意思。当 R 持有“...A1a...A1b... AND ...A2a...A2b... AND ...”的元组时，它是 R1, R2, ... 在各个属性集 {A1a, A1b, ...}, {A2a, A2b, ...}, ... 上的连接，具有各自的含义“...A1a。 ..A1b...", "...A2a...A2b...", ... .我们自然从设计开始开始使用R1、R2、...大部分时间。公认的观点是，不伴随 FD（功能依赖）的 JD 很少见。它们是，但只是因为大多数 JD 是如此明显，以至于我们的初始设计避免了它们。它们“很难找到”只是因为它们很容易找到。 （不分解每个不会引起问题的 JD 有点复杂。）

Answer 2

在关系模式的分解中，“虚假元组”只是丢失信息的假设症状。这意味着在给定关系中表示的某些依赖关系将由于将该关系拆分为两个或多个组件而丢失。这是否是您需要解决的问题取决于丢失的依赖项对您的重要性。

在您提到的示例中，EmpRoleProj 表告诉我们每个员工正在从事哪些项目。在表 1、表 2 设计中，信息丢失了——我们不能再分辨出琼斯只在亚马逊项目上工作而不在尼罗河项目上工作。

作为数据库设计人员，您需要考虑丢失了哪些信息或完整性，然后决定采取什么措施：更改设计、添加额外的完整性约束或决定新的分解实际上是对之前的改进。