資料庫正規化那些事[轉]

weixin_34219944發表於2010-03-06

簡介

資料庫正規化在資料庫設計中的地位一直很曖昧，教科書中對於資料庫正規化倒是都給出了學術性的定義，但實際應用中正規化的應用卻不甚樂觀，這篇文章會用簡單的語言和一個簡單的資料庫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對主鍵是部分依賴，對其應用第二正規化如下表：

對錶進行第三正規化(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”,解決辦法是將多值屬性放入一個新表，則第四正規化化後的關係圖如下：