范式（Normal Form，簡稱NF）：數據庫表結構的設計標準級別，目前關系數據庫有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又稱完美范式）。從1~6對表的設計要求越來越高，每個范式是上個范式的升級，是下一個范式的基礎。通常實際應用中只需要滿足前三個范式（1NF~3NF）就足夠了。

第一范式（1NF）

表中所有屬性都不可再分，即數據項不可分。第一范式強調數據表的原子性，是其他范式的基礎。

例如：一張表有一個sheng(省)-shi(市)-qu(區)列，這個列有三個屬性，省、市、區，所以不符合第一范式，需要拆分成sheng、shi、qu三列，這樣就符合了第一范式。

要符合第一范式的必要條件：

1、每一列屬性都是不可再分的屬性值，確保每一列的原子性；

2、兩列的屬性相近或相似或一樣，盡量合并屬性一樣的列，確保不產生冗余數據；

3、單一屬性的列為基本數據類型構成；

4、設計出來的表都是簡單的二維表。

第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。

第二范式（2NF）要求實體的屬性完全依賴于主關鍵字。

所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。

例如：記錄人員的歸屬地時，將歸屬地和人員的信息放到一張表中，就會出現不同的人在相同的歸屬地的情況，這時用區劃id和人員證件號（card_number）組成聯合主鍵后這時實體的屬性就不完全依賴于主關鍵字（人員依賴于card_number，區劃信息依賴于id）。

基于第一范式中的區劃表進行修改，將表中的人員提出到一張表中，再加一個人員與區劃關聯表或在人員表中關聯區劃表id。

第三范式（3NF）

滿足第三范式（3NF）必須先滿足第二范式（2NF）。

第三范式（3NF）要求一個數據庫表中不包含已在其它表中包含的非主關鍵字信息，即數據不能存在傳遞關系，即每個屬性都跟主鍵有直接關系而不是間接關系。

例如：在第二范式中的人員表里有一個人員的電話號字段，如果同時在人員區劃的關聯關系表中也有人員的電話號字段的話，這樣就不符合第三范式。當人員換電話號后關系表中的手機號數據就是不一致的。

所以phone字段只需要在人員表中就可以，通過關聯表中的card_number就可以查詢到對應人員的電話。

巴斯-科德范式（BCNF）

滿足巴斯-科德范式（BCNF）必須先滿足第三范式（3NF）。

巴斯-科德范式（BCNF）要求每個字段信息，都不依賴于非主關鍵字信息。

例如：在第三范式的人員表中加一個編號字段，字段值要求是姓名全拼加上手機號，這樣就不符合巴斯-科德范式，因為編號字段的值需要先知道姓名和手機號才能插入并且依賴的字段（phone）修改了會導致數據不一致。

第四范式（4NF）

滿足第四范式（4NF）必須先滿足巴斯-科德范式（BCNF）。

第四范式（4NF）要求主關鍵字信息和非主關鍵字信息不能有一對多關系。

例如：在人員表中‘張三’在生活中有三個角色：兒子、老公、父親，在表中如果分成三條數據保存就違反了第四范式。

第五范式（5NF）

滿足第五范式（5NF）必須先滿足第四范式（4NF）。

第五范式（5NF）要求每個依賴關系，都有主屬性推出。就是表的字段只能跟一個主屬性字段依賴確定唯一性，如果有兩個字段都可以作為主屬性，那么就不符合第五范式。

例如：在人員表中證件號（card_number）和編號（number）都可以作為唯一標識的主屬性，這樣就不符合第五范式。

通常我們在工作中遇到的用戶、角色、權限管理的表結構設計中符合第五范式的要求：用戶關聯角色，角色關聯權限

反范式

在實際的業務查詢中會大量存在著表的關聯查詢，而表設計都做成了范式化設計（甚至很高的范式），大量的表關聯很多的時候非常影響查詢的性能。

所以反范式就是為了性能和讀取效率而適當的違反對數據庫設計范式的要求，并存在部分（少量）冗余數據，是用空間來換取時間的一種方式。

范式化與反范式對比

總結

數據表沒有最完美的設計，只有最合適的設計，所以不需要一味的最求范式化設計，但也不能忽略范式的要求。根據業務需求在范式化與反范式中做權衡，才能設計出更好的表結構。