首頁 > 書法

資料庫的六大正規化,你都知道嗎?

作者:由 資料庫技術分享社群 發表于 書法日期:2022-08-20

第二正規化存在什麼問題

資料庫的六大正規化,你都知道嗎?

前言

資料庫正規化是關係型資料庫設計的基本理論,好的資料庫設計離不開資料庫正規化的支撐,資料庫正規化規範了資料庫的設計原則,使得資料庫能更加有效的應用於各種網際網路系統當中。本篇文章主要透過結合實際例子給大家介紹一下資料庫正規化相關的知識,希望能給大家帶來一些實際應用的幫助。

1、資料庫正規化的意義

資料庫正規化主要是為解決關係資料庫中資料冗餘、更新異常、插入異常、刪除異常問題而引入的設計理念。簡單來說,資料庫正規化可以避免資料冗餘,減少資料庫的儲存空間,並且減輕維護資料完整性的成本。是關係資料庫核心的技術之一,也是從事資料庫開發人員必備知識。

2、資料庫正規化分類

正規化是評價資料庫模式規範化程度從低到高主要有:1NF、2NF、3Nf、BCNF、4NF、5NF。

資料庫的六大正規化,你都知道嗎?

2。1 1NF 第一正規化

強調屬性的原子性約束,要求屬性具有原子性,不可再分解。

舉例:

學生表(學號、姓名、年齡、性別、地址)。因為地址可以細分為國家、省份、城市、市區、街道,那麼該模式就沒有達到第一正規化。

第一正規化存在問題:冗餘度大、會引起修改操作的不一致性、資料插入異常、資料刪除異常。

2。2 2NF 第二正規化

第二正規化,強調記錄的唯一性約束,資料表必須有一個主鍵,並且沒有包含在主鍵中的列必須完全依賴於主鍵,而不能只依賴於主鍵的一部分。

舉例:

版本表(版本編碼,版本名稱,產品編碼,產品名稱),其中主鍵是(版本編碼,產品編碼),這個場景中,資料庫設計並不符合第二正規化,因為產品名稱只依賴於產品編碼。存在部分依賴。所以,為了使其滿足第二正規化,可以改造成兩個表:版本表(版本編碼,產品編碼)和產品表(產品編碼,產品名稱)

2。3 3NF 第三正規化

第三正規化,強調資料屬性冗餘性的約束,也就是非主鍵列必須直接依賴於主鍵。也就是消除了非主屬性對碼的傳遞函式依賴。

舉例:

訂單表(訂單編碼,顧客編碼,顧客名稱),其中主鍵是(訂單編碼),這個場景中,顧客編碼、顧客名稱都完全依賴於主鍵,因此符合第二正規化,但顧客名稱依賴於顧客編碼,從而間接依賴於主鍵,所以不能滿足第三正規化。如果要滿足第三正規化,需要拆分為兩個表:訂單表(訂單編碼,顧客編碼)和顧客表(顧客編碼,顧客名稱)。

說明:3NF的模式肯定滿足2NF。產生冗餘和異常的兩個重要原因是部分依賴和傳遞依賴。3NF模式中不存在非主屬性對碼的部分函式依賴和傳遞函式依賴,效能較好。1NF、2NF一般不適合作為資料庫模式,通常需要轉換為3NF或者更高級別的正規化,這種變換過程稱為關係模式規範化處理。

2。4 BCNF(Bovce Codd Normal Form 巴克斯正規化)

屬於修正的第三正規化,是防止主鍵的某一列會依賴於主鍵的其他列。當3NF消除了主屬性對碼的部分函式依賴和傳遞函式依賴稱為BCNF。

特性:

1、所有主屬性對每一個碼都是完全函式依賴

2、所有主屬性對每一個不包含它的碼,也是完全函式依賴

3、沒有任何屬性完全函式依賴與非碼的任何一組屬性

舉例:庫存表(倉庫名,管理員名,商品名,數量),主鍵為(倉庫名,管理員名,商品名),這是滿足前面三個正規化的,但是倉庫名和管理員名之間存在依賴關係,因此刪除某一個倉庫,會導致管理員也被刪除,這樣就不滿足BCNF。

資料庫的六大正規化,你都知道嗎?

2。5 4NF 第四正規化

非主屬性不應該有多值。如果有多值就違反了第四正規化。4NF是限制關係模式的屬性間不允許有非平凡且非函式依賴的多值依賴。

舉例:使用者聯絡方式表(使用者id,固定電話,行動電話),其中使用者id是主鍵,這個滿足了BCNF,但是一個使用者有可能會有多個固定電話或者多個行動電話,那麼這種設計就不合理,應該改為(使用者id,聯絡方式型別,電話號碼)。

說明:如果只考慮函式依賴,關係模式規範化程度最高的正規化是BCNF;如果考慮多值依賴則是4NF。

2。6 5NF 第五正規化

第五正規化屬於最終正規化,消除了4NF中的連線依賴,第五正規化需要滿足以下要求:

1、必須滿足第四正規化

2、表必須可以分解為較小的表,除非那些表在邏輯上擁有與原始表相同的主鍵。

一般實際應用中不必考慮第五正規化。