簡介
數據庫範式在數據庫設計中的地位一直很曖昧，教科書中對於數據庫範式倒是都給出了學術性的定義，但實際應用中範式的應用卻不甚樂觀，這篇文章會用簡單的語言和一個簡單的數據庫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 查詢時需要連接多個表，降低了數據庫查詢性能
而現在的情況，磁盤空間成本基本可以忽略不計，所以數據冗餘所造成的問題也並不是應用數據庫範式的理由。
因此，並不是應用的範式越高越好，要看實際情況而定。第三範式已經很大程度上減少了數據冗餘，並且減少了造成插入異常，更新異常，和刪除異常了。我個人觀點認爲，大多數情況應用到第三範式已經足夠，在一定情況下第二範式也是可以的。