我对一个有 5 个函数依赖的关系进行了 BCNF 分解，最终得到了 5 个关系。但是，每个新关系都具有与原始函数依赖项之一相同的属性和 FD。
例如，一个功能依赖是 AB -> C，而我最终得到的 5 个关系之一具有属性 ABC 和 AB -> C 功能依赖。其他四个关系也是如此（与原始 FD 之一相同的属性和 FD）。
这是否意味着我错误地进行了 BCNF 分解？
我发现这个问题描述了类似情况的特定 BCNF 分解，据说它是正确的。
这是否意味着您根本不必遵循 BCNF 算法，并且可以从每个 FD 中获取属性并将其放入一个关系中，然后每个关系都将在 BCNF 中，因此由新的关系也会如此吗？
当给定 FD 成立时，阿姆斯特朗公理所隐含的所有 FD 也成立。我们无法确定 CK（候选键）或 NF（范式），直到我们有一个封面——一组 FD，它暗示了所有持有的 FD。但是，如果我们只得到一些持有的 FD，那么除了这些 FD 之外，它们暗示通常还有更多的 FD 可能持有也可能不持有。
有时，当我们将分解的组件连接回原始时，所有原始 FD 都保持不变。原来持有的FD不需要为此全部持有在组件中；它们只需要被包含在组件中的 FD 所暗示。这是“保留FD”的时候。如果可以在保留 FD 的同时分解原始文件，那么通常我们更喜欢使用保留 FD 的分解。（这对于 3NF 和更严格的 EKNF 的归一化始终是可能的，这是常见的“3NF”算法实际产生的。）但是，并非每个 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 依赖保持
并非每个 BCNF 分解都是依赖保留的。
回想一下，无损连接是分解的必要条件，以避免信息丢失。因此，我们被迫放弃 BCNF 或依赖保留。在第 7.7 节中，我们提出了另一种范式，称为第三范式，它是 BCNF 的一个小松弛；使用第三范式的动机是始终存在保持依赖关系的分解为第三范式。
在某些情况下，将模式分解为 BCNF 的方法不止一种。这些分解中的一些可能是依赖关系保留的，而另一些则可能不是。
一般来说，数据库设计者应该因此考虑替代分解，并在可能的情况下选择依赖关系保持分解。