（粗體主鍵。）消除傳遞函數依賴條件
在我的一次演講中，我們採取了以下模式
R（A，B，Ç，d，E）
甲 - >乙
ë - >乙
C，d - >一個
C，d - >乙
C，d - >電子
並把它帶到2NF如下：
R1（Ç，d，A，E）
C，d - > a和e
R2（A，E ，b）（不在2NF）
甲 - >乙
ë - >乙
當然，如果我想利用我的模式，以3NF這會導致一個問題，因爲b不能被部分遏制由a和e開採。我想要做的就是簡單地創建單獨的關係如下：
R3（ê，B）
é - >乙
和
R4（一個，B）
a - > b
在這種情況下，b完全依賴於主鍵，這使得我得到了2NF，對於關係3和4來說，轉換的依賴關係被取消，whi ch在3NF。然而，我認爲可以認爲，這種解決方案並不令人滿意，因爲b的價值可能會因爲每個關係而不同，並且當它不可避免地被用作外鍵時可能會出現異常。對此有何想法？
我們尋求分解「保留」FD和（通常沒有明確說明）不引入其他約束。 FD在某個組件中存放時會被保留。我們的想法是，我們可以通過檢查它在組件中的存在來檢查FD是否存在重構，而不是必須加入然後檢查。我們也更喜歡FD和它的屬性只在一個組件中，或者我們需要添加一個約束，在行列式值同意相關值同意的地方。總是有一個3NF模式保留所有FD而不引入其他約束。當一個FD不能保存到BCNF時，就會引入一個「等式依賴」，因爲兩個組件必須在FD屬性上具有相同的投影。
我們沒有通過移動較低的NF來標準化給定的NF。這可能會導致更高的NF設計出現。我們對給定的NF使用一種算法。
當某些FD（功能依賴性）成立時，其他人根據阿姆斯特朗的公理來做。我們必須在之間查找所有 FD的NF違規者和FD以保存，而不僅僅是某些形成封面的給定者。算法也考慮到了這一點。
PS PK（主鍵）並不重要，CK（候選鍵）也可以。可以有多個，它們可以是複合的。 PK只是你決定叫PK的一些CK。所以突出PK的屬性通常是不夠的。只需列出CK。
PPS一個（更新）異常是一個特定的事情，這不是你使用「異常」的東西。
你是什麼意思，「把它拿到2NF」？當我們將一個模式「分解」爲一個NF時，我們正在濫用語言來表示「NF中的一堆其他模式」。原始模式已經消失。 （所以我編輯了「R（...）」到「R1（...）」）。但是由於你的第一個分解仍然有一個組件不在2NF中，所以你*沒有「把它帶到2NF」。你似乎認爲R1仍然是R，而R1是在2NF，或者R1被命名爲R，因爲有理由認爲「取R到2NF」，但這沒有意義。 – philipxy