1. 程式人生 > 實用技巧 >資料庫的三正規化詳細解釋

資料庫的三正規化詳細解釋

1.定義

三正規化是資料庫的規範化的內容,所謂的資料庫三正規化通俗的講就是設計資料庫表所應該遵守的一套規範,如果不遵守就會造成設計的資料庫不規範,出現數據庫欄位冗餘,資料的查詢,插入等操作等問題。

注意:資料庫不僅僅只有三正規化(1NF/2NF/3NF),還有BCNF、4NF、5NF…,不過在實際的資料庫設計時,遵守前三個正規化就足夠了。再向下就會造成設計的資料庫產生過多不必要的約束。

2.資料庫的三正規化內容及詳解

第一正規化:資料庫表中的每一列都不可再分,也就是原子性

解釋:如下表所示,可以看到,列部門崗位是不滿足原子性的要求的。所謂原子就是最小的。不能再把它進行劃分了。在部門崗位中,是可以進行劃分為部門和崗位的。

在這裡插入圖片描述
修改後的表:

在這裡插入圖片描述

第二正規化:在滿足第一正規化基礎上要求每個欄位都和主鍵完整相關,而不是僅和主鍵部分相關(主要針對聯合主鍵而言)

第二正規化的另一種表述方式是:兩張表要通過外來鍵關聯,不儲存冗餘欄位。

注意:如果不是聯合主鍵(兩個欄位共同充當表的主鍵),不存在不遵守第二正規化的問題。

解釋:如下表:
在這裡插入圖片描述

直接看這個表可能第一感覺就是沒毛病。但是當一個表中出現聯合主鍵時,我們就需要進行詳細的分析了。
“訂單詳情表”使用“訂單編號”和“產品編號”作為聯合主鍵。此時“產品價格”、 “產品數量”都和聯合主鍵整體相關,但 “訂單金額”和“下單時間” 只和聯合主鍵中的“訂單編號”相關,和“產品編號”無關

。所以只關聯了主鍵中的部分欄位,不滿足第二正規化。

修改表如下:把“訂單金額”和“下單時間”移到訂單表就符合第二正規化了。
在這裡插入圖片描述

第三正規化:表中的非主鍵欄位和主鍵欄位直接相關,不允許間接相關

在這裡插入圖片描述
上面表中的“部門名稱”和“員工編號”的關係是“員工編號”→“部門編號” →“部門名稱”,不是直接相關。此時會帶來下列問題:
1.資料冗餘:“部門名稱”多次重複出現。
2.插入異常:組建一個新部門時沒有員工資訊,也就無法單獨插入部門資訊。就算強行插入部門資訊,員工表中沒有員工資訊的記錄同樣是非法記錄。
3. 刪除異常:刪除員工資訊會連帶刪除部門資訊導致部門資訊意外丟失。
4.更新異常:哪怕只修改一個部門的名稱也要更新多條員工記錄。

正確的方式:把上表拆分成兩張表,以外來鍵形式關聯

在這裡插入圖片描述

3.實際開發中注意事項

三大正規化是設計資料庫表結構的規則約束,但是在實際開發中允許區域性變通。

如何變通呢?

比如為了快速查詢到關聯資料可能會允許冗餘欄位的存在。例如在員工表 中儲存部門名稱雖然違背第三正規化,但是免去了對部門表的關聯查詢。

根據業務功能設計資料庫表

1).看得見的欄位
能夠從需求文件或原型頁面上直接看到的資料都需要設計對應的資料庫表、欄位來儲存。例如設計一個登入介面的功能。設計表需要有賬號、密碼。

2).看不見的欄位
除了能夠直接從需求文件中看到的欄位,實際開發中往往還會包含一 些其他欄位來儲存其他相關資料。 例如主鍵、建立賬戶時間。

3).冗餘欄位
為了避免建表時考慮不周有所遺漏,到後期再修改表結構非常麻煩, 所以有時會設定一些額外的冗餘欄位備用。