我对具有5个函数依赖关系的关系进行了BCNF分解，最终得到了5个关系。但是，每个新关系都具有相同的属性，FD与原始功能依赖关系之一。
e.g。一个功能依赖是AB - ＆gt; C和我最终得到的5个关系中的一个具有属性ABC和AB - > C功能依赖。其他四个关系（相同的属性和FD与原始FD之一）相同。
这是否意味着我错误地进行了BCNF分解？
我发现这个问题Specific BCNF decomposition描述了类似的情况，并且认为它是正确的。
这是否意味着您根本不必遵循BCNF算法，并且可以从每个FD获取属性并将其置于关系中，然后每个关系将在BCNF中，因此由新关系组成的新模式也是如此？
答案 0 :(得分：0)
有时，所有原始FD（功能依赖性）都存在于分解的组件中。这是“保留FD”的时间，如果可能，则优先考虑。 （这对于3NF的归一化以及常见的“3NF”算法实际产生的更严格的EKNF总是可能的。）但是，并非每次对BCNF的分解都会保留所有FD。并且在分解为BCNF时并不总是可以保留所有FD。不可能的情况是CK（候选键）重叠。
不清楚你的意思是“只需从每个FD获取属性并将其置于关系中”。但有时当你分离FD的属性时，其他一些FD不再仅仅在一个组件中具有所有属性，因此它不能最终存在于其中一个组件中，即它不会被保留。 BCNF算法是 BCNF算法因为它处理所有情况，如果你不遵循一个，那么你不会总是得到BCNF分解。如果你想了解为什么这些算法按照它们的方式设计，那么请阅读一个介绍。例如Silberschatz，Korth＆amp; Sudarshan的数据库系统概念第7章关系数据库设计，第7.6节Boyce-Codd范式（7.6.2分解算法和7.6.3依赖保留）和7.7第三范式。您可以在线找到文本和幻灯片。
7.6.3依赖保留
并非每个BCNF分解都是依赖保留。
回想一下，无损连接是分解的必要条件，以避免信息丢失。因此，我们被迫放弃BCNF或依赖保留。在7.7节中，我们提出了一种替代的正规形式，称为第三范式，它是BCNF的一种小松弛;使用第三范式的动机是始终存在依赖，保持分解为第三范式。
在某些情况下，有多种方法可以将架构分解为BCNF。其中一些分解可能是依赖性保留，而其他分解可能不是。
一般而言，数据库设计者应该考虑替代方案 分解，并尽可能选择保留分解的依赖。