關係型資料庫設計三大範式

作者：鄭龍飛

範式定義

百度百科:設計關係資料庫時，遵從不同的規範要求，設計出合理的關係型資料庫，這些不同的規範要求被稱為不同的範式，各種範式呈遞次規範，越高的範式資料庫冗餘越小。

人類語言: 範式可以理解為設計一張數據表的表結構，符合的標準級別、規範和要求。

而通常我們用的最多的就是第一範式（1NF）、第二範式（2NF）、第三範式（3NF），也就是本文要講的“三大範式”。

範式的優點

採用範式可以降低數據的冗餘性。

為什麼要降低數據的冗餘性？

1. 十幾年前，磁碟很貴，為了減少磁碟存儲。
2. 以前沒有分散式系統，都是單機，只能增加磁碟，磁碟個數也是有限的。
3. 一次修改，需要修改多個表，很難保證數據一致性。

範式的缺點

範式的缺點是獲取數據時，需要通過Join拼接出最後的數據。

目前範式的分類

目前業界範式有：第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯-科德範式(BCNF)、第四範式(4NF)、第五範式(5NF)。

什麼是函數依賴？

百度百科:函數依賴簡單點說就是：某個屬性集決定另一個屬性集時，稱另一屬性集依賴於該屬性集。

人類語言:以下麵表格為例，通俗易懂的解釋，什麼是函數依賴。

完全函數依賴

官方定義:設X，Y是關係R的兩個屬性集合，X’是X的真子集，存在X→Y，但對每一個X’都有X’!→Y，則稱Y完全函數依賴於X。

人類語言:比如通過，(學號，課程) 推出分數 ，但是單獨用學號推斷不出來分數，那麼就可以說：分數 完全依賴於(學號，課程) 。

總結:即：通過A B能得出C，但 是A B單獨得不出C，那麼說C完全依賴於AB。

部分函數依賴

官方定義:假如 Y函數依賴於 X，但同時 Y 並不完全函數依賴於 X，那麼我們就稱 Y 部分函數依賴於 X。

人類語言:比如通過，(學 號，課程) 推出姓名，因為其實直接可以通過，學號推出姓名，所以：姓名 部分依賴於 (學號，課程)。

總結:通過AB能得出C，通過A也能得出C，或者通過B也能得出C，那麼說C部分依賴於AB。

傳遞函數依賴

官方定義:傳遞函數依賴：設X，Y，Z是關係R中互不相同的屬性集合，存在X→Y(Y !→X),Y→Z，則稱Z傳遞函數依賴於X。

人類語言:比如：學號 推出 系名 ， 系名 推出 系主任， 但是，系主任推不出學號，系主任主要依賴於系名。這種情況可以說：系主任 傳遞依賴於 學號 。

總結:即：通 過A得 到B，通 過B得 到C，但 是C得不到A，那 麽說C傳遞依賴於A。

三範式的區別

第一範式

第一範式1NF核心原則：屬性不可切割。

舉例說明:

很明顯上面表格設計是不符合第一範式的，學籍信息列中的數據不是原子數據項，是可以進行分割的，因此對錶格進行修改，讓表格符合第一範式的要求，修改結果如下圖所示：

實際上 ，1NF是所有關係型資料庫的最基本要求 ,你在關係型資料庫管理系統（RDBMS），例如SQL Server，Oracle，MySQL中創建數據表的時候，如果數據表的設計不符合這個最基本的要求，那麼操作一定是不能成功的。也就是說，只要在RDBMS中已經存在
的數據表，一定是符合1NF的。

第二範式

第二範式2NF核心原則：不能存在“部分函數依賴”。

舉例說明:

以上表格明顯存在，部分依賴。比 如，這張表的主鍵是 (學號，課名），分數確實完全依賴於(學號，課名），但是姓名並不完全依賴於(學號，課名）,讓表格符合第二範式的要求，修改結果如下圖所示：

以上符合第二範式，去掉部分函數依賴依賴。

第三範式

第三範式 3NF核心原則：不能存在傳遞函數依賴。

舉例說明:

在上面這張表中，存 在傳遞函數依賴：學號->系 名->系主任，但是系主任推不出學號。

上面表需要再次拆解：

反三範式

沒有冗餘的資料庫未必是最好的資料庫，有時為了提高運行效率，就必須降低範式標準，適當保留冗餘數據。具體做法是： 在概念數據模型設計時遵守第三範式，降低範式標準的工作放到物理數據模型設計時考慮。降低範式就是增加欄位，減少了查詢時的關聯，提高查詢效率，因為在資料庫的操作中查詢的比例要遠遠大於DML的比例。但是反範式化一定要適度，並且在原本已滿足三範式的基礎上再做調整的。

總結

引用知乎大佬對範式的理解:

資料庫設計應該也是分為三個境界的：

第一個境界，剛入門資料庫設計，範式的重要性還未深刻理解。這時候出現的反範式設計，一般會出問題。

第二個境界，隨著遇到問題解決問題，漸漸瞭解到範式的真正好處，從而能快速設計出低冗餘、高效率的資料庫。

第三個境界，再經過N年的鍛煉，是一定會發覺範式的局限性的。此時再去打破範式，設計更合理的反範式部分。