規范化（Normalization） 是數據庫設計中的核心流程，旨在通過結構化表與字段，消除數據冗余和避免數據異常（插入/更新/刪除異常），同時確保數據依賴合理。其核心方法是將大表拆分為多個小表，并通過主鍵和外鍵建立關聯。
📌 核心目標
- 消除冗余：相同數據不重復存儲（如避免多處存儲用戶地址）。
- 保證一致性：修改數據只需更新一處。
- 防止異常：
- 插入異常：無法插入部分數據（如未錄入商品時無法添加分類）。
- 更新異常：修改冗余數據時遺漏部分導致不一致。
- 刪除異常：刪除數據時意外丟失關聯信息（如刪訂單導致客戶信息消失）。
🧩 常見范式（Normal Forms, NF）
從低到高逐級優化，通常需滿足前三個范式（3NF）：
1. 第一范式（1NF）—— 原子性
- 每列值必須是不可再分的原子值（禁止多值或復合結構）。
- 違反示例：
訂單ID 商品列表 1001 手機, 耳機, 充電器 - 符合1NF：
訂單ID 商品名稱 1001 手機 1001 耳機
2. 第二范式（2NF）—— 消除部分依賴
- 滿足1NF + 所有非主鍵字段必須完全依賴主鍵（針對聯合主鍵）。
- 違反示例（主鍵：
訂單ID, 商品ID）：訂單ID 商品ID 客戶姓名 商品價格 1001 P01 張三 ￥599 - ? 問題：
客戶姓名只依賴訂單ID（部分依賴），與商品ID無關。
- ? 問題：
- 解決方案：拆表！
- 訂單表（主鍵：
訂單ID）→ 訂單ID, 客戶姓名 - 訂單商品表（主鍵：
訂單ID, 商品ID）→ 訂單ID, 商品ID, 商品價格
- 訂單表（主鍵：
3. 第三范式（3NF）—— 消除傳遞依賴
- 滿足2NF + 非主鍵字段之間不能有傳遞依賴（A→B→C）。
- 違反示例：
員工ID 部門ID 部門地址 E001 D01 北京 - ? 問題：
部門地址依賴部門ID，而部門ID依賴主鍵員工ID（傳遞依賴）。
- ? 問題：
- 解決方案：再拆表！
- 員工表 → 員工ID, 部門ID
- 部門表 → 部門ID, 部門地址
🤔 為什么需要規范化？
- 減少存儲空間：避免重復數據。
- 提升操作可靠性：更新/刪除數據時不會意外破壞完整性。
- 簡化復雜查詢：通過關聯多表精確獲取數據。
? 注意事項
- 并非越高越好：更高范式（如BCNF、4NF）可能增加表連接開銷，需平衡查詢性能。
- 適時反規范化（Denormalization）：對高頻查詢的表，可故意增加冗余以提升讀取速度（如數據倉庫的寬表設計）。
? 實踐建議：大多數業務系統設計到3NF即可兼顧清晰性與性能。
