簡介

????? 數(shù)據(jù)庫范式在數(shù)據(jù)庫設(shè)計中的地位一直很曖昧，教科書中對于數(shù)據(jù)庫范式倒是都給出了學術(shù)性的定義，但實際應用中范式的應用卻不甚樂觀，這篇文章會用簡單的語言和一個簡單的數(shù)據(jù)庫DEMO將一個不符合范式的數(shù)據(jù)庫一步步從第一范式實現(xiàn)到第四范式。

?

范式的目標

????? 應用數(shù)據(jù)庫范式可以帶來許多好處，但是最重要的好處歸結(jié)為三點：

????? 1.減少數(shù)據(jù)冗余（這是最主要的好處，其他好處都是由此而附帶的）

????? 2.消除異常（插入異常，更新異常，刪除異常）

????? 3.讓數(shù)據(jù)組織的更加和諧…

????

?????? 但劍是雙刃的，應用數(shù)據(jù)庫范式同樣也會帶來弊端，這會在文章后面說到。

?

什么是范式

????? 簡單的說，范式是為了消除重復數(shù)據(jù)減少冗余數(shù)據(jù)，從而讓數(shù)據(jù)庫內(nèi)的數(shù)據(jù)更好的組織，讓磁盤空間得到更有效利用的一種標準化標準，滿足高等級的范式的先決條件是滿足低等級范式。(比如滿足2nf一定滿足1nf)

?

DEMO

????? 讓我們先從一個未經(jīng)范式化的表看起,表如下：

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

對表進行第一范式(1NF)

????如果一個關(guān)系模式R的所有屬性都是不可分的基本數(shù)據(jù)項，則R∈1NF。

????簡單的說,第一范式就是每一個屬性都不可再分。不符合第一范式則不能稱為關(guān)系數(shù)據(jù)庫。對于上表，不難看出Address是可以再分的，比如”北京市XX路XX小區(qū)XX號”，著顯然不符合第一范式，對其應用第一范式則需要將此屬性分解到另一個表,如下:

對表進行第二范式(2NF)

若關(guān)系模式R∈1NF，并且每一個非主屬性都完全函數(shù)依賴于R的碼，則R∈2NF

?

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

對表進行第三范式(3NF)

關(guān)系模式R<U，F> 中若不存在這樣的碼X、屬性組Y及非主屬性Z（Z ? Y）, 使得X→Y，Y→Z，成立，則稱R<U，F> ∈ 3NF。

?

簡單的說，第三范式是為了消除數(shù)據(jù)庫中關(guān)鍵字之間的依賴關(guān)系，在上面經(jīng)過第二范式化的表中，可以看出jobDescription(崗位職責)是由job(崗位)所決定，則jobDescription依賴于job,可以看出這不符合第三范式，對表進行第三范式后的關(guān)系圖為：

上表中，已經(jīng)不存在數(shù)據(jù)庫屬性互相依賴的問題，所以符合第三范式

?

對表進行BC范式(BCNF)

設(shè)關(guān)系模式R<U，F>∈1NF，如果對于R的每個函數(shù)依賴X→Y，若Y不屬于X，則X必含有候選碼，那么R∈BCNF。

?

簡單的說，bc范式是在第三范式的基礎(chǔ)上的一種特殊情況，既每個表中只有一個候選鍵（在一個數(shù)據(jù)庫中每行的值都不相同，則可稱為候選鍵），在上面第三范式的noNf表中可以看出，每一個員工的email都是唯一的（難道兩個人用同一個email??）則，此表不符合bc范式，對其進行bc范式化后的關(guān)系圖為:

對表進行第四范式(4NF)

關(guān)系模式R<U，F>∈1NF，如果對于R的每個非平凡多值依賴X→→Y（Y ? X），X都含有候選碼，則R∈4NF。

簡單的說，第四范式是消除表中的多值依賴，也就是說可以減少維護數(shù)據(jù)一致性的工作。對于上面bc范式化的表中，對于員工的skill，兩個可能的值是”C#,sql,javascript”和“C#，UML,Ruby”,可以看出，這個數(shù)據(jù)庫屬性存在多個值，這就可能造成數(shù)據(jù)庫內(nèi)容不一致的問題，比如第一個值寫的是”C#”,而第二個值寫的是”C#.net”,解決辦法是將多值屬性放入一個新表，則第四范式化后的關(guān)系圖如下：

而對于skill表則可能的值為:

?

總結(jié)

???? 上面對于數(shù)據(jù)庫范式進行分解的過程中不難看出，應用的范式登記越高，則表越多。表多會帶來很多問題：

1 查詢時要連接多個表，增加了查詢的復雜度

2 查詢時需要連接多個表，降低了數(shù)據(jù)庫查詢性能

而現(xiàn)在的情況，磁盤空間成本基本可以忽略不計，所以數(shù)據(jù)冗余所造成的問題也并不是應用數(shù)據(jù)庫范式的理由。

因此，并不是應用的范式越高越好，要看實際情況而定。第三范式已經(jīng)很大程度上減少了數(shù)據(jù)冗余，并且減少了造成插入異常，更新異常，和刪除異常了。我個人觀點認為，大多數(shù)情況應用到第三范式已經(jīng)足夠，在一定情況下第二范式也是可以的。

轉(zhuǎn)載于:https://www.cnblogs.com/liaods/p/7929194.html

總結(jié)

以上是生活随笔為你收集整理的数据库范式那些事的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。