三范式是數據庫設計中最基本的三個規范，那么，三范式到底是什么？在實際開發中，為了性能，我們需要違反三范式嗎？這篇文章，我們一起來聊一聊。

一、三大范式

1. 第一范式（1NF）

第一范式要求數據庫中的每個表格的每個字段（列）都具有原子性，即字段中的值不可再分割。換句話說，每個字段只能存儲一個單一的值，不能包含集合、數組或重復的組，即確保每列保持原子性。

如下示例： 假設有一個學生表 Student，結構如下：

在這個表中，電話號碼字段包含多個號碼，違反了1NF的原子性要求。為了滿足1NF，需要將電話號碼拆分為單獨的記錄或創建一個新的表。

滿足 1NF后的設計：

學生表 Student：

電話表 Phone：

2. 第二范式（2NF）

第二范式要求滿足第一范式，并且消除表中的部分依賴，即非主鍵字段必須完全依賴于主鍵，而不是僅依賴于主鍵的一部分，即確保表中的每列都和主鍵相關。這主要適用于復合主鍵的情況。

如下示例：假設有一個訂單詳情表 OrderDetail，結構如下：

在上述表中，主鍵是復合主鍵 (訂單ID, 商品ID)。商品名稱和單價只依賴于復合主鍵中的商品ID，而不是整個主鍵，存在部分依賴，違反了2NF。

滿足 2NF后的設計：

訂單詳情表 OrderDetail：

商品表 Product：

3. 第三范式（3NF）

第三范式要求滿足第二范式，并且消除表中的傳遞依賴，即非主鍵字段不應依賴于其他非主鍵字段。換句話說，所有非主鍵字段必須直接依賴于主鍵，而不是通過其他非主鍵字段間接依賴，或者說：確保每列都和主鍵列直接相關，而不是間接相關。

如下示例：假設有一張員工表 Employee，結構如下：

在這張表中，部門名稱依賴于部門ID，而部門ID依賴于主鍵員工ID，形成了傳遞依賴，違反了3NF。

滿足3NF后的設計：

員工表 Employee：

部門表 Department：

通過將部門信息移到單獨的表中，消除了傳遞依賴，使得數據庫結構符合第三范式。

最后，我們總結一下數據庫設計的三大范式：

• 第一范式（1NF）： 確保每個字段的值都是原子性的，不可再分。
• 第二范式（2NF）： 在滿足 1NF的基礎上，消除部分依賴，確保非主鍵字段完全依賴于主鍵。
• 第三范式（3NF）： 在滿足 2NF的基礎上，消除傳遞依賴，確保非主鍵字段直接依賴于主鍵。

二、破壞三范式

在實際工作中，盡管遵循數據庫的三大范式（1NF、2NF、3NF）有助于提高數據的一致性和減少冗余，但在某些情況下，為了滿足性能、簡化設計或特定業務需求，我們可能需要違反這些范式。

下面列舉了一些常見的破壞三范式的原因及對應的示例。

1. 性能優化

在高并發、大數據量的應用場景中，嚴格遵循三范式可能導致頻繁的聯表查詢，增加查詢時間和系統負載。為了提高查詢性能，設計者可能會通過冗余數據來減少聯表操作。

假設有一個電商系統，包含訂單表 Orders 和用戶表 Users。在嚴格 3NF設計中，訂單表只存儲 用戶ID，需要通過聯表查詢獲取用戶的詳細信息。

但是，為了查詢性能，我們通常會在訂單表中冗余存儲 用戶姓名 和 用戶地址等信息，因此，查詢訂單信息時無需聯表查詢 Users 表，從而提升查詢速度。

破壞 3NF后的設計：

2. 簡化查詢和開發

嚴格規范化可能導致數據庫結構過于復雜，增加開發和維護的難度，為了簡化查詢邏輯和減少開發復雜度，我們也可能會選擇適當的冗余。

比如，在內容管理系統（CMS）中，文章表 Articles 和分類表 Categories 通常是獨立的，如果頻繁需要顯示文章所屬的分類名稱，聯表查詢可能增加復雜性。因此，通過在 Articles 表中直接存儲 分類名稱，可以簡化前端展示邏輯，減少開發工作量。

破壞 3NF后的設計：

3. 報表和數據倉庫

在數據倉庫和報表系統中，通常需要快速讀取和聚合大量數據。為了優化查詢性能和數據分析，可能會采用冗余的數據結構，甚至使用星型或雪花型模式，這些模式并不完全符合三范式。

在銷售數據倉庫中，為了快速生成銷售報表，可能會創建一個包含維度信息的事實表。

破壞 3NF后的設計：

在事實表中直接存儲 產品名稱 和 類別，避免了需要聯表查詢維度表，提高了報表生成的效率。

4. 特殊業務需求

在某些業務場景下，可能需要快速響應特定的查詢或操作，這時通過適當的冗余設計可以滿足業務需求。

比如，在實時交易系統中，為了快速計算用戶的賬戶余額，可能會在用戶表中直接存儲當前余額，而不是每次交易時都計算。

破壞 3NF后的設計：

在交易記錄表中存儲每筆交易的增減，但直接在用戶表中維護 當前余額，避免了每次查詢時的復雜計算。

5. 兼顧讀寫性能

在某些應用中，讀操作遠多于寫操作。為了優化讀性能，可能會通過數據冗余來提升查詢速度，而接受在數據寫入時需要額外的維護工作。

社交媒體平臺中，用戶的好友數常被展示在用戶主頁上。如果每次請求都計算好友數量，效率低下。可以在用戶表中維護一個 好友數 字段。

破壞3NF后的設計：

通過在 Users 表中冗余存儲 好友數，可以快速展示，無需實時計算。

6. 快速迭代和靈活性

在快速發展的產品或初創企業中，數據庫設計可能需要頻繁調整。過度規范化可能導致設計不夠靈活，影響迭代速度。適當的冗余設計可以提高開發的靈活性和速度。

一個初創電商平臺在初期快速上線，數據庫設計時為了簡化開發，可能會將用戶的收貨地址直接存儲在訂單表中，而不是單獨創建地址表。

破壞3NF后的設計：

這樣設計可以快速上線，后續根據需求再進行規范化和優化。

7. 降低復雜性和提高可理解性

有時，過度規范化可能使數據庫結構變得復雜，難以理解和維護。適度的冗余可以降低設計的復雜性，提高團隊對數據庫結構的理解和溝通效率。

在一個學校管理系統中，如果將學生的班級信息獨立為多個表，可能增加理解難度。為了簡化設計，可以在學生表中直接存儲班級名稱。

破壞3NF后的設計：

通過在學生表中直接存儲 班級名稱 和 班主任，減少了表的數量，簡化了設計。

三、總結

本文，我們分析了數據庫的三范式以及對應的示例，它是數據庫設計的基本規范。但是，在實際工作中，為了滿足性能、簡化設計、快速迭代或特定業務需求，我們很多時候并不會嚴格地遵守三范式。

所以說，架構很多時候都是業務需求、數據一致性、系統性能、開發效率等各種因素權衡的結果，我們需要根據具體應用場景做出合理的設計選擇。