原文地址：https://blog.csdn.net/g_beginner/article/details/6789308

1． 定義

當下面性質成立時，一個數據庫模式中的表T及函式依賴集F被稱為符合Boyce-Codd正規化（BCNF）：任何F可推匯出的函式依賴X->A都在T中，這裡A是不在X中的單一屬性，X必須是T的一個超鍵。當一個數據庫模式包含的所有表都符合BCNF時，這個資料庫被稱為符合BCNF.

2． 說明

BCNF是比第三正規化更嚴格一個正規化。它要求關係模型中所有的屬性（包括主屬性和非主屬性）都不傳遞依賴於任何候選關鍵字。也就是說，當關系型表中功能上互相依賴的那些列的每一列都是一個候選關鍵字時候，該滿足BCNF。

BCNF實際上是在第三正規化的基礎上，進一步消除了主屬性的傳遞依賴。

3． 舉例

有這樣一個配件管理表WPE(WNO,PNO,ENO,QNT),其中WNO表示倉庫號，PNO表示配件號，ENO表示職工號，QNT表示數量。

有以下約束要求：

（1）       一個倉庫有多名職工；

（2）       一個職工僅在一個倉庫工作；

（3）       每個倉庫裡一種型號的配件由專人負責，但一個人可以管理幾種配件；

（4）       同一種型號的配件可以分放在幾個倉庫中。

分析表中的函式依賴關係，可以得到：

（1）       ENO->WNO;

（2）       （WNO，PNO）->QNT

（3）       （WNO，PNO）->ENO

（4）       （ENO，PNO）->QNT

可以看到，候選鍵有：（ENO,PNO）;(WNO,PNO)。所以，ENO,PNO,WNO均為主屬性，QNT為非主屬性。顯然，非主屬性是直接依賴於候選鍵的。所以此表滿足第三正規化。

而我們觀察一下主屬性：（WNO,PNO）->ENO;ENO->WNO。顯然WNO對於候選鍵（WNO,PNO）存在傳遞依賴，所以不符合BCNF.

解決這個問題的辦法是分拆為兩個表：管理表EP（ENO，PNO，QNT）；工作表EW（ENO，WNO）。但這樣做會導致函式依賴（WNO,PNO）->ENO丟失。

4． 應用

雖然，不滿足BCNF，也會導致一些冗餘和一致性的問題。但是，將表分解成滿足BCNF的表又可能丟失一些函式依賴。所以，一般情況下不會強制要求關係表要滿足BCNF。

5.第四正規化（4NF）

1． 定義

第四正規化需要滿足以下要求：

（1）       必須滿足第三正規化

（2）       表中不能包含一個實體的兩個或多個互相獨立的多值因子。

2． 說明

     顯然，第四正規化也是一個比第三正規化嚴格的正規化。

     第四正規化的意思是：當一個表中的非主屬性互相獨立時（3NF），這些非主屬性不應該有多值。若有多值就違反了第四正規化。定義比較抽象，可以參照下面的例子理解。

3． 舉例

有這樣一個使用者聯絡方式表TELEPHONE(CUSTOMERID,PHONE,CELL)。 CUSTOMERID為使用者ID,PHONE為使用者的固定電話,CELL為使用者的行動電話。

      本來，這是一個非常簡單的第3正規化表。主鍵為CUSTOMERID，不存在傳遞依賴。但在某些情況下，這樣的表還是不合理的。比如說，使用者有兩個固定電話，兩個行動電話。這時，表的具體表示如下：

      由於PHONE和CELL是互相獨立的，而有些使用者又有兩個和多個值。這時此表就違反第四正規化。

      在這種情況下，此表的設計就會帶來很多維護上的麻煩。例如，如果使用者放棄第一行的固定電話和第二行的行動電話，那麼這兩行會合並嗎？等等

      解決問題的方法為，設計一個新表NEW_PHONE(CUSTOMERID,NUMBER,TYPE).這樣就可以對每個使用者處理不同型別的多個電話號碼，而不會違反第四正規化。

4． 應用

顯然，第四正規化的應用範圍比較小，因為只有在某些特殊情況下，要考慮將表規範到第四正規化。所以在實際應用中，一般不要求表滿足第四正規化。

六．第五正規化（5NF）

1． 定義

第五正規化有以下要求：

（1）       必須滿足第四正規化

（2）       表必須可以分解為較小的表，除非那些表在邏輯上擁有與原始表相同的主鍵。

2． 說明

第五正規化是在第四正規化的基礎上做的進一步規範化。

第四正規化處理的是相互獨立的多值情況，而第五正規化則處理相互依賴的多值情況。

3． 舉例

有一個銷售資訊表SALES（SALEPERSON，VENDOR，PRODUCT）。SALEPERSON代表銷售人員，VENDOR代表供和商，PRODUCT則代表產品。

在某些情況下，這個表中會產生一些冗餘。可以將表分解為PERSON_VENDOR表（SALEPERSON，VENDOR）；PERSON_PRODUCT表（SALEPERSON，PRODUCT）；VENDOR­_PRODICT表（VENDOR，PRODUCT）。

4． 應用

第五正規化的應用就更少了，很多時候，我認為分解為第五正規化是完全沒必要的。可能在某些情況下會有意義吧。不懂。。。

總結：

   總之，規範化的過程就是在資料庫表設計時移除資料冗餘的過程。隨著規範化的進行，資料冗餘越來越少，但資料庫的效率也越來越低。

   這就要求你在資料庫設計中，能結合實際應用的效能要求，規範到合適的正規化。一般情況下，如何效能允許的話，都要求規範到第三正規化的。

===================================================

例子：STC(Sid,Tid,Cid) 學生選課m:n，老師授課m:1， 
有以下函式依賴：(Sid,Cid)->Tid;(Sid,Tid)->Cid;Tid->Cid 

這個表不符合BCNF但符合第三正規化。 
改為：ST(Sid,Tid);TC(Tid,Cid)。現在就符合BCNF了。 

3NF->BCNF 需要消除主屬性對鍵的部分和傳遞函式依賴。