資料庫正規化實戰 (一)：從零狀態到第一正規化，主鍵與重複群組消除

動態網站效能與擴展性的基石在於資料庫設計。正規化是消除冗餘與不當相依的系統化方法。本系列五篇將帶您從零狀態逐步推進至 5NF，首篇聚焦 0NF → 1NF 轉換與主鍵建立。

零狀態 (0NF) — 未正規化的初始表

情境：建立用戶資訊表，含姓名、公司、公司地址、個人收藏網址。

users (0NF):
name | company | company_address | url1 | url2
Joe  | ABC     | 1 Work Lane     | abc.com | xyz.com
Jill | XYZ     | 1 Job Street    | abc.com | xyz.com

明顯缺陷

• 重複群組：url1, url2 為同一語意欄位橫向展開
• 擴展性差：需第三個網址時必須 ALTER TABLE ADD url3 — 結構變更成本高、易破壞相容性
• 查詢困難：找「所有使用 abc.com 的用戶」需 WHERE url1='abc.com' OR url2='abc.com'

第一正規化 (1NF) — 消除重複群組、建立主鍵

三大規則：

1. 消除每個表格中的重複群組
2. 為每組相關資料建立獨立表格
3. 使用主鍵識別每組相關資料

什麼是主鍵？

• 每筆記錄唯一識別碼
• 通常為自動遞增整數 (Auto-increment INT / BIGINT / UUID)
• 區分同名不同人、支援外鍵參考

轉換後 (1NF)

users (1NF):
userId | name | company | company_address | url
1      | Joe  | ABC     | 1 Work Lane     | abc.com
1      | Joe  | ABC     | 1 Work Lane     | xyz.com
2      | Jill | XYZ     | 1 Job Street    | abc.com
2      | Jill | XYZ     | 1 Job Street    | xyz.com

1NF 解決與新問題

為何需要主鍵而非天然鍵？

• 天然鍵 (如 email、身分證字號) 可能變更、重複、含機敏資訊
• 代理鍵 (Surrogate Key / 人造鍵) : 純技術識別碼，業務意義為零，永不變更，效能最佳
• 現代最佳實務：主鍵 = 代理鍵，業務唯一性用 UNIQUE 約束保護

下一步預告

第二篇將實作 2NF：抽離 URL 獨立表，建立 users.userId → urls.relUserId 外鍵關聯，解決公司資訊重複問題的前奏。