Boyce Codd分解後的剩餘函數依賴關係？

Question

這個分解的例子是在課堂上給出的，然而這個解決方案令人困惑，因爲它似乎讓一些FD沒有被解決。請確認3）以下是BCNF，還是不能投入BCNF？

Let R be a relation schema, with schema(R) = {C,T,H,R,S,G} 

set of FDs F over R : 
C->T 
HR->C 
HT->R 
CS->G 
HS->R 

分解：

1) C T H R S G 
2) C T  C H R S G 
3) C T  H R C  H R S G 
end. (Not further decomposed.) 

在3）HRSG包含屬性R和G沒有出現滿足HT-> R或CS->克。

HT-> r被打折的，因爲我們沒有噸餘熱鍋爐 CS - > g的折扣，因爲我們沒有下，在餘熱鍋爐

是否有一個規則，如果一個功能性的LHS依賴關係包含不在關係中的屬性，FD不適用？謝謝

Answer 1

FD仍然適用於整體數據庫設計。

每個FD總是表達一些業務規則。所有聲明的業務規則總是適用，無論它們是在數據庫模式的單表版本上執行還是在其分解版本上執行。然而，表達他們作爲FD要求所有參與FD屬性出現在同一relvar（因爲這是他們是如何發明：爲表達一個應用於規則的一種方式關係模式（請注意，它不說「數據庫模式」在這裏）。合乎邏輯的結果是，FD的只是不能表達的規則，即「跨越」不僅僅是一個關係模式。的合乎邏輯的結果那是，它是正常的「分解關係模式」可能會導致一些FD變得難以形容（而不是「不適用」）在新版本中。 （1）通過將FD的LHS聲明爲關係模式的關鍵字，可以「實施」FD仍然可以在分解/歸一化到BCNF之後被表達的FD。 （2）已經在分解的模式中變得不可表達的FD將不得不在數據庫約束的形式下在整個數據庫設計中恢復。這個「數據庫約束」與（1）中對應於這些FD的關鍵約束非常相似，因爲這些數據庫約束也是一類的「關鍵」，它們不是數據庫模式中關係的關鍵，相反，它們是可以在數據庫模式中定義的「虛擬」關係（又稱「視圖」）的關鍵。該視圖是所涉及的關係模式的JOIN（s）（因此，「從分解的部分重新構建」）的投影（正好在FD的任一側提及的屬性）。

這是很多單詞，也許很難遵循，但程序是（對於cs-> g）：將分解後的關係模式（在HR之後，給我們一個關係HRCSG再次回來），向下投影到涉及FD的屬性（因此，向下投影到CSG），並且在這個關係中，CS必須是關鍵。

請注意，我在這裏說「關鍵」，因爲不允許相同的CS值組合以不同的G值出現。不是說這是你可以對任何DBMS執行這樣的規則的聲明。如果數據庫管理系統能夠有效地做到這一點，那麼數據庫設計將會容易得多:-)意義規則的執行，並看到沒有數據會違反這個規則，現在取決於你。

幸運的是，實際上這些情況並不是很多，大多數情況下您會注意到原始版本中的絕大多數FD最終只是在BCNF表中聲明的鍵。