我在好久以前的一篇文章中介紹了數據庫模型設計中的基本三範式，今天，我來講一說更高級的BC範式和第四範式。html
我用大白話來回顧一下什麼是三範式：數據庫
第一範式：每一個表應該有惟一標識每一行的主鍵。函數
第二範式：在複合主鍵的狀況下，非主鍵部分不該該依賴於部分主鍵。大數據
第三範式：非主鍵之間不該該有依賴關係。人工智能
這是咱們設計數據庫的基本規則，可是隻有這三個規則並不能徹底解決數據的增刪改的異常狀況，下面就來看看BC範式的例子。spa
BC範式（BCNF）是Boyce-Codd範式的縮寫，其定義是：在關係模式中每個決定因素都包含候選鍵，也就是說，只要屬性或屬性組A可以決定任何一個屬性B，則A的子集中必須有候選鍵。BCNF範式排除了任何屬性(不光是非主屬性，2NF和3NF所限制的都是非主屬性)對候選鍵的傳遞依賴與部分依賴。設計
好比咱們有一個學生導師表，其中包含字段：學生ID，專業，導師，專業GPA，這其中學生ID和專業是聯合主鍵。htm
| StudentId | Major | Advisor | MajGPA |
| 1 | 人工智能 | Edward | 4.0 |
| 2 | 大數據 | William | 3.8 |
| 1 | 大數據 | William | 3.7 |
| 3 | 大數據 | Joseph | 4.0 |
這個表的設計知足三範式，有主鍵，不存在主鍵的部分依賴，不存在非主鍵的傳遞依賴。可是這裏存在另外一個依賴關係，「專業」函數依賴於「導師」，也就是說每一個導師只作一個專業方面的導師，只要知道了是哪一個導師，咱們天然就知道是哪一個專業的了。對象
因此這個表的部分主鍵依賴於非主鍵部分，那麼咱們能夠進行如下的調整，拆分紅2個表：blog
學生導師表：
| 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），第五範式處理的是無損鏈接問題，這個範式基本沒有實際意義，由於無損鏈接不多出現，並且難以察覺。而域鍵範式試圖定義一個終極範式，該範式考慮全部的依賴和約束類型，可是實用價值也是最小的，只存在理論研究中。