作者：京東科技 鄭龍飛

范式定義

百度百科:設計關系數據庫時，遵從不同的規范要求，設計出合理的關系型數據庫，這些不同的規范要求被稱為不同的范式，各種范式呈遞次規范，越高的范式數據庫冗余越小。

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

而通常我們用的最多的就是第一范式（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年的鍛煉，是一定會發覺范式的局限性的。此時再去打破范式，設計更合理的反范式部分。

審核編輯 黃宇