數據庫的六大范式知識是什么

本篇內容主要講解“數據庫的六大范式知識是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“數據庫的六大范式知識是什么”吧!

 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、表必須可以分解為較小的表，除非那些表在邏輯上擁有與原始表相同的主鍵。

一般實際應用中不必考慮第五范式。

到此，相信大家對“數據庫的六大范式知識是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！