數據庫設計範式2——BC範式和第四範式

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