第一范式(1NF)
強調的是列的原子性，即列不能夠再分成其他幾列。
第二范式(2NF)
首先是 2NF，另外包含兩部分內容一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。
第三范式(3NF)
首先是 2NF，另外非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴。即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。
第三范式通常已經可以滿足業務需求了，表之間的關系也比較清楚了，容易維護。但是為什么要反范式呢？
首先我們需要了解到定義數據庫范式的歷史背景，在20世紀70年代到80年代范式基本完善定型。在那個時候的系統下：一個硬盤的大小有限，一般也就幾百兆（價格也比較高），上網的人也少，所以范式的理論強調減少依賴，降低冗余節省空間的使用。而現在最普通的硬盤都是500G，大一點的就上T了而且價格便宜，同時上網人數也增多了，數據庫面臨則高並發，業務邏輯復雜，低延遲的要求。很難在遵循這范式的基礎上進行數據庫設計開發，那么適當的降低范式，增加冗余，用空間來換時間是值得的。最低可以把范式降低到1NF。
通常在設計數據庫時遵循以下原則：
1.核心業務使用范式。在類似交易有關的這種敏感核心業務中，強調數據安全和一致性，需要遵循范式保證數據唯一和一致。具體什么是核心業務視情況而定。
2.弱一致性需求——反ACID。在一些對數據一致性要求不高的場合，不必完全遵循ACID，出現適當的數據不一致是可以容忍的。如在線人數，靜態頁等。當下流行的NoSQL技術，就是基於弱一致性需求，降低數據完整性和一致性換取效率的。
3.空間換時間，冗余換效率。由於一條可見的記錄被拆分到多個表中記錄，當數據量比較大的時候，聯表查詢就比較費時，sql語句也變的比較復雜，難於優化。此時就需要適當的冗余了。在統計報表，視圖中就是對這一條規則的體現。統計報表通常會對很多列，有的時候多達上百列，需要對幾個十幾個表進行聯表，數度緩慢，使用人數一多可能會時數據庫服務器宕機。這種情況就需要使用冗余表了，冗余表一般符合第一和第二范式。冗余表一邊是定期轉儲。
4.避免不必要的冗余。范式理論不是說反就反的，反范式理論不是不要范式，而是在必要時創建冗余表或者總結表。不必要的冗余任然是要避免的。所有的規則都是有使用場景的，我們不應該固守規則，在某些情況下，應懂得變通。