我在很久之前的一篇文章中介紹了資料庫模型設計中的基本三正規化，今天，我來說一說更高階的BC正規化和第四正規化。

回顧

我用大白話來回顧一下什麼是三正規化：

第一正規化：每個表應該有唯一標識每一行的主鍵。

第二正規化：在複合主鍵的情況下，非主鍵部分不應該依賴於部分主鍵。

第三正規化：非主鍵之間不應該有依賴關係。

這是我們設計資料庫的基本規則，但是隻有這三個規則並不能完全解決資料的增刪改的異常情況，下面就來看看BC正規化的例子。

BC正規化

BC正規化（BCNF）是Boyce-Codd正規化的縮寫，其定義是：在關係模式中每一個決定因素都包含候選鍵，也就是說，只要屬性或屬性組A能夠決定任何一個屬性B，則A的子集中必須有候選鍵。BCNF正規化排除了任何屬性(不光是非主屬性，2NF和3NF所限制的都是非主屬性)對候選鍵的傳遞依賴與部分依賴。

比如我們有一個學生導師表，其中包含欄位：學生ID，專業，導師，專業GPA，這其中學生ID和專業是聯合主鍵。

StudentId	Major	Advisor	MajGPA
1	人工智慧	Edward	4.0
2	大資料	William	3.8
1	大資料	William	3.7
3	大資料	Joseph	4.0

這個表的設計滿足三正規化，有主鍵，不存在主鍵的部分依賴，不存在非主鍵的傳遞依賴。但是這裡存在另一個依賴關係，“專業”函式依賴於“導師”，也就是說每個導師只做一個專業方面的導師，只要知道了是哪個導師，我們自然就知道是哪個專業的了。

所以這個表的部分主鍵依賴於非主鍵部分，那麼我們可以進行以下的調整，拆分成2個表：

學生導師表：

StudentId	Advisor	MajGPA
1	Edward	4.0
2	William	3.8
1	William	3.7
3	Joseph	4.0

導師表：

Advisor	Major
Edward	人工智慧
William	大資料
Joseph	大資料

 

第四正規化

如果滿足了BC正規化，那麼就不再會有任何由於函式依賴導致的異常，但是我們還可能會遇到由於多值依賴導致的異常。

比如我們建立課程教師和教材的模型，我們規定，每門課程有對應的一組教師，每門課程也有對應的一組教材，一門課程使用的教程和教師沒有關係。這樣我們首先肯定有三個實體表，分別表示課程，教師和教材。現在我們要建立這三個物件的關係，於是我們建立的關係表，定義如下：

課程ID，教師ID，教程ID；這三列作為聯合主鍵。

以下是示例，為了表述方便，我們用Name代替ID，這樣更容易看懂：

Course	Teacher	Book
英語	Bill	人教版英語
英語	Bill	美版英語
英語	Jay	美版英語
高數	William	人教版高數
高數	Dave	美版高數

這個表除了主鍵，就沒有其他欄位了，所以肯定滿足BC正規化，但是卻存在多值依賴導致的異常。

我們先來看看多值依賴的定義：

一個關係，至少存在三個屬性（A、B、C），才能存在這種關係。對於每一個A值，有一組確定的B值和C值，並且這組B的值獨立於這組C的值。

假如我們下學期想採用一本新的英版高數教材，但是還沒確定具體哪個老師來教，那麼我們就無法在這個表中維護Course高數和Book英版高數教材的的關係。

解決辦法是我們把這個多值依賴的表拆解成2個表，分別建立關係。這是我們拆分後的表：

Course	Teacher
英語	Bill
英語	Jay
高數	William
高數	Dave

 

Course	Book
英語	人教版英語
英語	美版英語
高數	人教版高數
高數	美版高數

第四正規化的定義很簡單：已經是BC正規化，並且不包含多值依賴關係。

除了第四正規化外，我們還有更高階的第五正規化和域鍵正規化（DKNF），第五正規化處理的是無損連線問題，這個正規化基本沒有實際意義，因為無損連線很少出現，而且難以察覺。而域鍵正規化試圖定義一個終極正規化，該正規化考慮所有的依賴和約束型別，但是實用價值也是最小的，只存在理論研究中。