我在很久之前的一篇文章中介紹了數據庫模型設計中的基本三范式，今天，我來說一說更高級的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），第五范式處理的是無損連接問題，這個范式基本沒有實際意義，因為無損連接很少出現，而且難以察覺。而域鍵范式試圖定義一個終極范式，該范式考慮所有的依賴和約束類型，但是實用價值也是最小的，只存在理論研究中。