我對一個有5個函數依賴關係的關係進行BCNF分解，最後得到5個關係。但是，每個新的關係都具有與原始功能依賴關係相同的屬性和FD。BCNF分解後獲得相同的FD？
例如一個函數依賴是AB - > C，並且我最終得到的5個關係之一具有ABC與AB - > C函數依賴關係的屬性。對於其他四種關係（與原始FD中的一個相同的屬性和FD）也是如此。
這是否意味着我錯誤地進行了BCNF分解？
我發現這個問題Specific BCNF decomposition描述了類似的情況，並認爲它是正確的。
這並不意味着您不必遵循BCNF算法，只需從每個FD中獲取屬性並將其放入一個關係中，然後每個關係將在BCNF中，因此新的由新關係構成的模式也將如此？
有時，所有原始的FD（函數依賴）都存在於分解的組成部分中。這是「FD被保存」的時候，如果可能，那麼它是優選的。 （這對於歸一化到3NF以及對於常見的「3NF」算法實際產生的更嚴格的EKNF來說總是可能的。）然而，並非每個BCNF分解都保留所有的FD。分解爲BCNF時，並不總是可以保留所有的FD。不可能的情況是當CK（候選鍵）重疊時。
目前還不清楚你的意思是「只從每個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。其中一些分解可能是依賴性保留，而另一些分解可能不是。
一般來說，數據庫設計者因此應該考慮其它 分解，並選擇一個依賴分解保留在可能的情況。
一般來說NO。這因情況而異。如果你編輯你的問題，添加關係，FD和你的解決方案，那麼你可以得到你的具體例子的答案。 – Renzo
是的，有時所有的FD都保存在BCNF分解中。但那並不意味着他們永遠都是，而且這並不意味着他們永遠都是。 – philipxy