設計穩健的資料架構不僅需要簡單地連結表格；它還需要對結構與完整性採取嚴謹的態度。對資料架構師而言，正規化不僅是教科書中的理論練習，更是可維護、可擴展且可靠的資料庫系統的基石。在建立實體關係圖（ERD）時，模式設計階段所做的決策將決定應用程式的長期健康狀態。適當的正規化能減少資料重複，確保邏輯一致性，避免後續產生連鎖錯誤。
本指南概述了每位資料架構師都必須應用的關鍵正規化規則。我們將從基本的原子性逐步探討到複雜的依賴關係，分析每一項規則對儲存空間、查詢效能與資料品質的影響。遵循這些原則，您將建立出能經得起時間考驗的系統。
為何結構在模式設計中至關重要 📐
在深入探討特定形式之前，理解正規化的目標至關重要。主要目標是將資料隔離，使修改、刪除與插入操作不會導致異常。若缺乏結構化的方法，資料庫將容易產生三種特定類型的異常：
-
插入異常： 無法在不同時新增與另一個無關實體相關資料的情況下，加入某個實體的資料。
-
更新異常： 必須在多個資料列中更新相同的值，若有一筆資料列被遺漏，將導致不一致的風險。
-
刪除異常： 在刪除另一個實體的資料時，意外地喪失了某個實體的資料。
正規化透過根據依賴規則將屬性組織成表格來解決這些問題。這種分離使資料庫能作為單一可信來源運作。雖然此過程可能顯得繁瑣，但其能大幅降低維護成本與資料損壞風險，因此是一項關鍵的投資。
基礎：第一正規化形式（1NF） 🧱
正規化的第一步是達成第一正規化形式。這是任何關係型資料庫的基本要求。若一張表格滿足兩個條件，則屬於1NF：僅包含原子值，且每一欄在每一列中僅包含一個值。單元格內不應存在重複群組或陣列。
1NF的違反常發生在開發人員試圖將清單儲存在單一欄位時，例如將多個電話號碼以逗號分隔儲存在同一欄位中。這種做法會使查詢與索引變得複雜。相反地，每一筆資料應獨立存在於自己的資料列中。
-
原子性： 確保每個欄位僅包含單一且不可分割的值。
-
唯一資料列： 每筆資料列都必須是唯一的，通常由主鍵強制執行。
-
欄位順序： 欄位的順序不應影響資料的意義。
考慮一個客戶資料表。若一位客戶有三個電子信箱，切勿建立三個電子信箱欄位。應建立一個獨立的「電子信箱」資料表，並透過外鍵連結。此結構確保新增第四個電子信箱時，無需修改資料表結構。
消除部分依賴（2NF） ⚖️
當表格已達1NF後，下一步是檢查是否存在部分依賴。若表格已達1NF，且所有非鍵屬性均完全依賴於主鍵，則該表格屬於第二正規化形式。此規則在處理複合主鍵時尤為重要。
複合主鍵由兩個或更多欄位組成。在此情境下，若非鍵屬性僅依賴於複合主鍵的一部分，則會產生部分依賴。例如，在追蹤訂單項目之資料表中，主鍵為（OrderID, ProductID），則「ProductName」欄位可能僅依賴於「ProductID」，而非兩者合併。
-
完全依賴： 確保每個非鍵欄位均依賴於整個主鍵。
-
關注點分離： 將依賴於鍵的一部分的屬性移至新的資料表中。
-
完整性檢查： 確認在沒有完整鍵的情況下，無法推斷出任何屬性。
透過將「ProductName」移至由「ProductID」連結的獨立表格中，可消除某一筆訂單的名稱變更而其他訂單未變更的風險。這可減少所需的儲存空間，並確保所有訂單記錄的一致性。
消除傳遞依賴（第三範式） 🔗
第三範式進一步優化結構，以處理傳遞依賴問題。若一個表格已符合第二範式，且所有非鍵屬性均非傳遞依賴於主鍵，則該表格即符合第三範式。本質上，這表示非鍵欄位不應依賴於其他非鍵欄位。
想像一個包含 EmployeeID、EmployeeName、DepartmentID 和 DepartmentName 的表格。若 EmployeeName 決定 DepartmentName，則存在傳遞依賴。若員工更換部門，而員工表格中的 DepartmentName 未正確更新，可能會變得過時。為解決此問題，應將部門表格分離。
-
僅允許直接依賴： 屬性應僅直接依賴於鍵，而非其他屬性。
-
資料邏輯分組： 將具有共同決定因素的相關屬性歸類至獨立的實體中。
-
外鍵： 使用外鍵將分離的表格連結起來。
此分離確保部門資訊僅儲存一次。若部門名稱變更，只需在一個地方更新，所有員工記錄便能透過關係自動反映變更。
當第三範式不足時：BCNF 及更進一步的應用 🚀
雖然第三範式涵蓋了大多數標準設計情境，但仍存在某些邊際情況下，嚴格的第三範式仍不夠充分。博伊斯-科德範式（BCNF）是第三範式的更嚴格版本，適用於存在多個候選鍵的情況。BCNF 要求對於每一個函數依賴 X → Y，X 必須是超鍵。
考慮一個情境：一名學生可有多位老師，而一位老師可教授多門科目。若主鍵為（學生，科目），且老師依科目指派，可能會出現依賴邏輯以複雜方式重疊的情況。BCNF 確保沒有任何欄位是由非候選鍵的欄位組合所決定。
-
超鍵要求： 任何依賴關係中的決定因素必須是超鍵。
-
複雜關係： 使用中間表格處理多對多關係。
-
開銷考量： 更高階的範式可能增加連接的複雜度。
第四範式（4NF）與第五範式（5NF）處理多值依賴與連接依賴。這類情況在一般商業應用中較為罕見，但在專業的資料倉儲或科學資料建模中至關重要。
策略性反規範化的藝術 ⚡
規範化並非總是最終目標。在某些高性能量環境中，嚴格的規範化可能導致過多的連接，進而降低查詢速度。這正是策略性反規範化發揮作用之處。反規範化涉及向資料庫中加入冗餘資料，以優化讀取效能。
然而，這絕不應隨意進行。必須清楚理解讀取速度與寫入複雜度之間的權衡。當讀取操作遠多於寫入操作時，冗餘可能是合理的。
-
讀取密集型工作負載： 若報表功能為主要用途，反規範化可減少查詢時間。
-
快取層： 在修改資料結構前，應先使用應用層快取。
-
資料一致性風險： 請注意，冗餘資料可能會出現不同步的情況。
-
寫入懲罰： 每次寫入操作都必須更新資料的所有冗餘副本。
一種常見的模式是將報表儀表板的摘要表格去規範化，同時將核心交易資料保持在第三範式（3NF）。這種混合方法在資料完整性與效能之間取得平衡。
正規化形式的比較
|
正規化形式 |
主要重點 |
關鍵約束 |
常見使用案例 |
|---|---|---|---|
|
1NF |
原子值 |
無重複群組 |
初始資料結構設計 |
|
2NF |
完全依賴 |
複合鍵上無部分依賴 |
複雜鍵 |
|
3NF |
遞移依賴 |
非鍵屬性僅依賴於鍵 |
一般商業邏輯 |
|
BCNF |
超鍵 |
決定因素必須是超鍵 |
複雜候選鍵 |
數據架構師實用檢查清單 ✅
為確保您的實體關係圖（ERD）符合業界標準，請在設計階段執行此檢查清單。此過程有助於在撰寫程式碼前識別潛在問題。
-
驗證原子性： 確保沒有任何欄位包含多個不同的值。
-
識別主鍵： 確認每個表格都有一個唯一的識別符。
-
檢查依賴關係： 列出每個欄位與主鍵之間的關係。
-
檢視外鍵： 確保關係被明確定義。
-
分析異常： 在腦中模擬插入、更新和刪除操作。
-
評估效能： 判斷 3NF 是否足夠，或是否需要反規範化。
-
記錄約束條件： 清楚定義資料輸入和驗證的規則。
-
規劃成長： 考慮資料結構將如何處理資料量的增加。
透過遵循這些步驟，您將建立一個能抵禦變化的資料結構。資料架構並非靜態的；它會隨著業務需求而演進。一個良好的規範化基礎能使這種演進更順暢，因為系統某一部分的變更不會不預期地波及到其他部分。
請記住，規範化是一種工具，而非法則。雖然 3NF 是交易系統的標準，但您應用程式的特定需求可能需要做出調整。目標始終是資料完整性與系統效率。務必仔細權衡這兩個因素，您的實體關係圖（ERD）才能成為整個應用生態系統的穩固基礎。
採用這些關鍵的規範化規則，能讓您建立的系統不僅今日運作順暢，也具備未來的適應能力。專注於資料點之間的關係，結構自然就會順理成章地形成。