database - 在 BCNF 分解后获得与开始时相同的 FD？

Question

我对具有 5 个函数依赖关系的关系进行了 BCNF 分解，最终得到 5 个关系。但是，每个新关系都具有与原始函数依赖项之一相同的属性和 FD。

例如一个函数依赖关系是 AB -> C，我最终得到的 5 个关系之一具有属性 ABC 和 AB -> C 函数依赖关系。其他四个关系也是如此(与原始 FD 之一相同的属性和 FD)。

这是否意味着我的 BCNF 分解不正确？

我发现了这个问题 Specific BCNF decomposition描述了类似的情况，并且应该是正确的。

这是否意味着您根本不必遵循 BCNF 算法，只需从每个 FD 中获取属性并将其放入一个关系中，然后每个关系都将在 BCNF 中，因此新的关系组成的新模式也会这样吗？

Answer 1

当给定 FD 成立时，阿姆斯特朗公理所暗示的所有 FD 也成立。我们无法确定 CK(候选键)或 NF(范式)until we have a cover --一组 FD，表示所有持有的 FD。但是，如果我们只给出了一些成立的 FD，那么除了 FD 之外，它们还意味着通常还有更多的 FD 可能成立，也可能不成立。

有时，当我们将分解的组件连接回原始组件时，所有原始的 FD 都会保持不变。原来持有的FD不需要为此全部持有组件；它们只需要包含在组件中的 FD 中即可。这是“保留 FD”的时候。如果可以在保留 FD 的同时分解原始文件，那么通常我们更愿意使用保留 FD 的分解。 (对于 3NF 的归一化，以及常见的“3NF”算法实际产生的更严格的 EKNF，这始终是可能的。)但是，并非每次分解为 BCNF 都会保留所有 FD。而且在分解为BCNF时并不总是能够保留所有的FD。不可能的情况都是CK(候选键)重叠的情况。

不清楚“只需从每个 FD 获取属性并将其放入关系”是什么意思。但有时当我们将一个 FD 的属性分配给组件时，没有一个组件拥有所有这些属性，因此 FD 不能包含在任何组件中。如果 FD 没有暗示它在某些组件中具有所有属性，因此确实保留在这些组件中，那么它就不会被保留。 BCNF 算法是 BCNF 算法因为它处理所有情况，如果您不遵循一个算法，那么您将不会总是得到 BCNF 分解。如果你想了解为什么这样的算法是按照它们的方式设计的，那么请阅读一个介绍。例如，Silberschatz、Korth 和 Sudarshan 的数据库系统概念第 7 章关系数据库设计，第 7.6 节 Boyce–Codd 范式(7.6.2 分解算法和 7.6.3 依赖性保持)和 7.7 第三范式。您可以在线找到文本和幻灯片。

7.6.3 Dependency Preservation

Not every BCNF decomposition is dependency preserving.

Recall that lossless join is an essential condition for a decomposition, to avoid loss of information. We are therefore forced to give up either BCNF or dependency preservation. In Section 7.7 we present an alternative normal form, called third normal form, which is a small relaxation of BCNF; the motivation for using third normal form is that there is always a dependency preserving decomposition into third normal form.

There are situations where there is more than one way to decompose a schema into BCNF. Some of these decompositions may be dependency preserving, while others may not.

In general, the database designer should therefore look at alternative decompositions, and pick a dependency preserving decomposition where possible.