技術分析：資料庫範式那些事

知識 03-11

簡介

資料庫範式在資料庫設計中的地位一直很曖昧，教科書中對於資料庫範式倒是都給出了學術性的定義，但實際應用中範式的應用卻不甚樂觀，這篇文章會用簡單的語言和一個簡單的資料庫DEMO將一個不符合範式的資料庫一步步從第一範式實現到第四範式。

範式的目標

應用資料庫範式可以帶來許多好處，但是最重要的好處歸結為三點：

1.減少數據冗餘(這是最主要的好處，其他好處都是由此而附帶的)

2.消除異常(插入異常，更新異常，刪除異常)

3.讓數據組織的更加和諧…

但劍是雙刃的，應用資料庫範式同樣也會帶來弊端，這會在文章後面說到。

什麼是範式

簡單的說，範式是為了消除重複數據減少冗餘數據，從而讓資料庫內的數據更好的組織，讓磁碟空間得到更有效利用的一種標準化標準，滿足高等級的範式的先決條件是滿足低等級範式。(比如滿足2nf一定滿足1nf)

DEMO

讓我們先從一個未經範式化的表看起,表如下：

先對錶做一個簡單說明，employeeId是員工id,departmentName是部門名稱，job代表崗位，jobDescription是崗位說明，skill是員工技能，departmentDescription是部門說明，address是員工住址

對錶進行第一範式(1NF)

如果一個關係模式R的所有屬性都是不可分的基本數據項，則R∈1NF。

簡單的說,第一範式就是每一個屬性都不可再分。不符合第一範式則不能稱為關係資料庫。對於上表，不難看出Address是可以再分的，比如」北京市XX路XX小區XX號」，著顯然不符合第一範式，對其應用第一範式則需要將此屬性分解到另一個表,如下:

對錶進行第二範式(2NF)

若關係模式R∈1NF，並且每一個非主屬性都完全函數依賴於R的碼，則R∈2NF

簡單的說，是表中的屬性必須完全依賴於全部主鍵，而不是部分主鍵.所以只有一個主鍵的表如果符合第一範式，那一定是第二範式。這樣做的目的是進一步減少插入異常和更新異常。在上表中，departmentDescription是由主鍵DepartmentName所決定，但卻不是由主鍵EmployeeID決定，所以departmentDescription只依賴於兩個主鍵中的一個，故要departmentDescription對主鍵是部分依賴，對其應用第二範式如下表：

對錶進行第三範式(3NF)

關係模式R中若不存在這樣的碼X、屬性組Y及非主屬性Z(Z ? Y), 使得XY，YZ，成立，則稱R∈ 3NF。

簡單的說，第三範式是為了消除資料庫中關鍵字之間的依賴關係，在上面經過第二範式化的表中，可以看出jobDescription(崗位職責)是由job(崗位)所決定，則jobDescription依賴於job,可以看出這不符合第三範式，對錶進行第三範式後的關係圖為：

上表中，已經不存在資料庫屬性互相依賴的問題，所以符合第三範式

對錶進行BC範式(BCNF)

設關係模式R∈1NF，如果對於R的每個函數依賴XY，若Y不屬於X，則X必含有候選碼，那麼R∈BCNF。

簡單的說，bc範式是在第三範式的基礎上的一種特殊情況，既每個表中只有一個候選鍵(在一個資料庫中每行的值都不相同，則可稱為候選鍵)，在上面第三範式的noNf表中可以看出，每一個員工的email都是唯一的(難道兩個人用同一個email??)則，此表不符合bc範式，對其進行bc範式化後的關係圖為:

對錶進行第四範式(4NF)

關係模式R∈1NF，如果對於R的每個非平凡多值依賴XY(Y ? X)，X都含有候選碼，則R∈4NF。

簡單的說，第四範式是消除表中的多值依賴，也就是說可以減少維護數據一致性的工作。對於上面bc範式化的表中，對於員工的skill，兩個可能的值是」C#,sql,javascript」和「C#，UML,Ruby」,可以看出，這個資料庫屬性存在多個值，這就可能造成資料庫內容不一致的問題，比如第一個值寫的是」C#」,而第二個值寫的是」C#.net」,解決辦法是將多值屬性放入一個新表，則第四範式化後的關係圖如下：