1．第一范式(確保每列保持原子性)
第一范式是最基本的范式。如果數據庫表中的所有字段值都是不可分解的原子值，就說明該數據庫表滿足了第一范式。
第一范式的合理遵循需要根據系統的實際需求來定。比如某些數據庫系統中需要用到“地址”這個屬性，本來直接將“地址”屬性設計成一個數據庫表的字段就行。但是如果系統經常會訪問“地址”屬性中的“城市”部分，那么就非要將“地址”這個屬性重新拆分為省份、城市、詳細地址等多個部分進行存儲，這樣在對地址中某一部分操作的時候將非常方便。這樣設計才算滿足了數據庫的第一范式，如下表所示。
上表所示的用戶信息遵循了第一范式的要求，這樣在對用戶使用城市進行分類的時候就非常方便，也提高了數據庫的性能。
2．第二范式(確保表中的每列都和主鍵相關)
第二范式在第一范式的基礎之上更進一層。第二范式需要確保數據庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。也就是說在一個數據庫表中，一個表中只能保存一種數據，不可以把多種數據保存在同一張數據庫表中。
比如要設計一個訂單信息表，因為訂單中可能會有多種商品，所以要將訂單編號和商品編號作為數據庫表的聯合主鍵，如下表所示。
訂單信息表
這樣就產生一個問題：這個表中是以訂單編號和商品編號作為聯合主鍵。這樣在該表中商品名稱、單位、商品價格等信息不與該表的主鍵相關，而僅僅是與商品編號相關。所以在這里違反了第二范式的設計原則。
而如果把這個訂單信息表進行拆分，把商品信息分離到另一個表中，把訂單項目表也分離到另一個表中，就非常完美了。如下所示。
這樣設計，在很大程度上減小了數據庫的冗余。如果要獲取訂單的商品信息，使用商品編號到商品信息表中查詢即可。
3．第三范式(確保每列都和主鍵列直接相關,而不是間接相關)
第三范式需要確保數據表中的每一列數據都和主鍵直接相關，而不能間接相關。
比如在設計一個訂單數據表的時候，可以將客戶編號作為一個外鍵和訂單表建立相應的關系。而不可以在訂單表中添加關於客戶其它信息（比如姓名、所屬公司等）的字段。如下面這兩個表所示的設計就是一個滿足第三范式的數據庫表。
這樣在查詢訂單信息的時候，就可以使用客戶編號來引用客戶信息表中的記錄，也不必在訂單信息表中多次輸入客戶信息的內容，減小了數據冗余。
BC范式
BC范式（BCNF）是Boyce-Codd范式的縮寫，其定義是：在關系模式中每一個決定因素都包含候選鍵，也就是說，只要屬性或屬性組A能夠決定任何一個屬性B，則A的子集中必須有候選鍵。BCNF范式排除了任何屬性(不光是非主屬性，2NF和3NF所限制的都是非主屬性)對候選鍵的傳遞依賴與部分依賴。
比如我們有一個學生導師表，其中包含字段：學生ID，專業，導師，專業GPA，這其中學生ID和專業是聯合主鍵。
| StudentId | Major | Advisor | MajGPA |
| 1 | 人工智能 | Edward | 4.0 |
| 2 | 大數據 | William | 3.8 |
| 1 | 大數據 | William | 3.7 |
| 3 | 大數據 | Joseph | 4.0 |
這個表的設計滿足三范式，有主鍵，不存在主鍵的部分依賴，不存在非主鍵的傳遞依賴。但是這里存在另一個依賴關系，“專業”函數依賴於“導師”，也就是說每個導師只做一個專業方面的導師，只要知道了是哪個導師，我們自然就知道是哪個專業的了。
所以這個表的部分主鍵依賴於非主鍵部分，那么我們可以進行以下的調整，拆分成2個表：
學生導師表：
| StudentId | Advisor | MajGPA |
| 1 | Edward | 4.0 |
| 2 | William | 3.8 |
| 1 | William | 3.7 |
| 3 | Joseph | 4.0 |
導師表：
| Advisor | Major |
| Edward | 人工智能 |
| William | 大數據 |
| Joseph | 大數據 |
第四范式
如果滿足了BC范式，那么就不再會有任何由於函數依賴導致的異常，但是我們還可能會遇到由於多值依賴導致的異常。
比如我們建立課程教師和教材的模型，我們規定，每門課程有對應的一組教師，每門課程也有對應的一組教材，一門課程使用的教程和教師沒有關系。這樣我們首先肯定有三個實體表，分別表示課程，教師和教材。現在我們要建立這三個對象的關系，於是我們建立的關系表，定義如下：
課程ID，教師ID，教程ID；這三列作為聯合主鍵。
以下是示例，為了表述方便，我們用Name代替ID，這樣更容易看懂：
| Course | Teacher | Book |
| 英語 | Bill | 人教版英語 |
| 英語 | Bill | 美版英語 |
| 英語 | Jay | 美版英語 |
| 高數 | William | 人教版高數 |
| 高數 | Dave | 美版高數 |
這個表除了主鍵，就沒有其他字段了，所以肯定滿足BC范式，但是卻存在多值依賴導致的異常。
我們先來看看多值依賴的定義：
一個關系，至少存在三個屬性（A、B、C），才能存在這種關系。對於每一個A值，有一組確定的B值和C值，並且這組B的值獨立於這組C的值。
假如我們下學期想采用一本新的英版高數教材，但是還沒確定具體哪個老師來教，那么我們就無法在這個表中維護Course高數和Book英版高數教材的的關系。
解決辦法是我們把這個多值依賴的表拆解成2個表，分別建立關系。這是我們拆分后的表：
| Course | Teacher |
| 英語 | Bill |
| 英語 | Jay |
| 高數 | William |
| 高數 | Dave |
| Course | Book |
| 英語 | 人教版英語 |
| 英語 | 美版英語 |
| 高數 | 人教版高數 |
| 高數 | 美版高數 |
第四范式的定義很簡單：已經是BC范式，並且不包含多值依賴關系。
除了第四范式外，我們還有更高級的第五范式和域鍵范式（DKNF），第五范式處理的是無損連接問題，這個范式基本沒有實際意義，因為無損連接很少出現，而且難以察覺。而域鍵范式試圖定義一個終極范式，該范式考慮所有的依賴和約束類型，但是實用價值也是最小的，只存在理論研究中。