資料庫設計範式完全指南：1NF、2NF、3NF 核心原則與實例演示

範式 是關聯式資料庫結構設計的規範標準，分為 1NF 到 6NF，實務上 **滿足 3NF 通常即足夠**。本文以通俗範例逐層拆解 1NF、2NF、3NF 定義、違反情形與修正步驟，助你建立不冗餘、易維護的資料模型。

範式階層關係

1NF (最低要求) ⊂ 2NF ⊂ 3NF ⊂ BCNF ⊂ 4NF ⊂ 5NF ⊂ 6NF (最高)
實務建議：達到 3NF 即可平衡正規化與效能

範例情境：顧客購物紀錄

原始未正規化表：
Customer | Item Purchased | Purchase Price
Thomas   | Shirt          | $40
Maria    | Tennis shoes   | $35
Evelyn   | Shirt          | $40
Pajaro   | Trousers       | $25

問題：刪除 Thomas 會導致 Shirt $40 價格資訊遺失 (刪除異常)；新增商品價格需虛擬顧客 (插入異常)；修改 Shirt 價格需更新多列 (更新異常)。

第一范式 (1NF)：原子性

定義：每個欄位皆為不可再分割的原子值，同一欄位不包含多值、無重複群組。

• ✅ 上表已滿足 1NF (每格單一值)
• ❌ 違反範例：Tags 欄位存 "tag1,tag2,tag3"、或同一列重複 Phone1, Phone2, Phone3
• 修正：拆分為獨立關聯表 (標籤表、電話表)

第二范式 (2NF)：完全函數相依 (消除部分相依)

前提：滿足 1NF。定義：非主鍵屬性**完全函數相依**於**整個**候選鍵 (複合主鍵情況下，非主鍵不得僅相依於主鍵一部分)。

拆解步驟

1. 識別候選鍵：(Customer, Item Purchased) 複合主鍵
2. 檢查非主鍵 Purchase Price：僅相依於 Item Purchased (部分相依) ❌
3. 拆分兩表：
   • Customer_Item(Customer, Item Purchased) — 購買關係
   • Item_Price(Item Purchased, Purchase Price) — 商品價格

結果：刪除顧客不影響商品價格；新增商品無需虛擬顧客。

第三范式 (3NF)：傳遞函數相依 (消除傳遞相依)

前提：滿足 2NF。定義：非主鍵屬性**不傳遞相依**於候選鍵 (即：非主鍵 → 非主鍵 → 候選鍵 鏈條不得存在)。

延伸情境：加入供應商資訊

Item_Price 表擴充：
Item | Price | Supplier | Supplier_Phone
Shirt | $40 | ABC Co. | 555-1234

問題：Supplier_Phone 相依於 Supplier，而 Supplier 相依於 Item → 傳遞相依 ❌

修正：再拆分供應商表

• Item(Item, Price, Supplier_ID)
• Supplier(Supplier_ID, Supplier_Name, Supplier_Phone)

三大異常對比表

實務判斷口訣

1. 1NF：有無多值/重複欄位？→ 拆關聯表
2. 2NF：有無複合主鍵？非主鍵是否只靠主鍵「一部分」決定？→ 拆表
3. 3NF：非主鍵之間是否有「決定」關係？(A 決定 B，B 決定 C) → 拆表

適度反正規化提醒

• 高頻 Join 的維度表 (如日期、地區) 可適度冗餘關鍵欄位
• 報表/OLAP 專用資料採星狀/雪花 schema，刻意保留冗餘換查詢速度
• 原則：OLTP 正規化到 3NF，OLAP 視查詢模式反正規化

掌握 1NF→2NF→3NF 三步拆解法，資料模型不再臃腫、異常全消，奠定高效能、可擴展系統的堅實基石。