數據庫三大範式

轉自：http://www.cnblogs.com/CareySon/archive/2010/02/16/1668803.html

簡介

      數據庫範式在數據庫設計中的地位一直很曖昧，教科書中對於數據庫範式卻是都給出了學術性的定義，但實際應用中範式的應用卻不甚樂觀，這篇文章會用簡單的語言和一個簡單的數據庫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<U，F> 中若不存在這樣的碼X、屬性組Y及非主屬性Z（Z  Y）, 使得X→Y，Y→Z，成立，則稱R<U，F> ∈ 3NF。

 

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

上表中，已經不存在數據庫屬性互相依賴的問題，因此符合第三範式

 

對錶進行BC範式(BCNF)

設關係模式R<U，F>∈1NF，若是對於R的每一個函數依賴X→Y，若Y不屬於X，則X必含有候選碼，那麼R∈BCNF。

 

簡單的說，bc範式是在第三範式的基礎上的一種特殊狀況，既每一個表中只有一個候選鍵（在一個數據庫中每行的值都不相同，則可稱爲候選鍵），在上面第三範式的noNf表中能夠看出，每個員工的email都是惟一的（難道兩我的用同一個email??）則，此表不符合bc範式，對其進行bc範式化後的關係圖爲:

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

關係模式R<U，F>∈1NF，若是對於R的每一個非平凡多值依賴X→→Y（Y  X），X都含有候選碼，則R∈4NF。

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

而對於skill表則可能的值爲:

 

總結

     上面對於數據庫範式進行分解的過程當中不難看出，應用的範式登記越高，則表越多。表多會帶來不少問題：

1 查詢時要鏈接多個表，增長了查詢的複雜度

2 查詢時須要鏈接多個表，下降了數據庫查詢性能

而如今的狀況，磁盤空間成本基本能夠忽略不計，因此數據冗餘所形成的問題也並非應用數據庫範式的理由。

所以，並非應用的範式越高越好，要看實際狀況而定。第三範式已經很大程度上減小了數據冗餘，而且減小了形成插入異常，更新異常，和刪除異常了。我我的觀點認爲，大多數狀況應用到第三範式已經足夠，在必定狀況下第二範式也是能夠的。

 

因爲本人對數據庫研究還處於初級階段，因此上述若有不當之處，還望高手不吝指教…