資料庫正規化實戰 (三)：第四、第五正規化與多對多關聯模型深度解析

承接前兩篇，本文進入第四正規化 (4NF) 與第五正規化 (5NF) 領域，核心聚焦於多對多關聯的結構優化，並說明正規化理論淵源。

三種基本資料關聯類型回顧

從 3NF 到 4NF：解決多對多冗餘

3NF 階段結構 (仍存冗餘)

users:          userId | name | relCompId
companies:      compId | company | company_address
urls:           urlId  | url
url_relations:  relationId | relatedUrlId | relatedUserId

問題：urls 表中同一 URL 可能被多用戶重複儲存 (如 abc.com 出現多次)。

4NF 解決方案：關聯獨立成表

4NF 定義：在多對多關聯中，獨立實體不得存放於同一表格。

建立專門關聯表 url_relations，欄位全為主鍵或外鍵：

url_relations:
relationId | relatedUrlId (FK→urls) | relatedUserId (FK→users)
1          | 1                       | 1
2          | 1                       | 2
3          | 2                       | 1
4          | 2                       | 2

效果：urls 表每個 URL 僅存一筆，徹底消除重複。

查詢範例

-- 查詢 Joe 的所有 URL
SELECT u.name, url.url
FROM users u, urls url, url_relations ur
WHERE ur.relatedUserId = 1
  AND u.userId = 1
  AND url.urlId = ur.relatedUrlId;

-- 遍歷所有人的 URL
SELECT u.name, url.url
FROM users u, urls url, url_relations ur
WHERE u.userId = ur.relatedUserId
  AND url.urlId = ur.relatedUrlId;

第五正規化 (5NF) / 投影-連接正規化 (PJNF)

原則：原始表格必須可由分解出的表格透過連接 (JOIN) 重建，且不引入額外欄位。

• 確保分解無損失 (Lossless Decomposition)
• 避免虛假關聯 (Spurious Tuples)
• 極少實務場景需要，除非處理極大規模、高複雜度關聯網路
• 屬良好設計習慣，但通常 3NF/4NF 已足夠

正規化理論淵源

• 1NF~3NF：1972 年 E.F. Codd 博士論文《關聯資料庫模型的進一步正規化》
• 4NF、5NF：後續由集合論與關聯數學家理論化 (如 Fagin、Date 等)

實務決策指南

結語

正規化不是教條，而是依業務複雜度權衡結構清晰度與查詢效能的工具。大多數 OLTP 系統 3NF 即足夠；含大量 M:N 關聯的系統 (如標籤系統、推薦引擎) 需 4NF；極罕見情況才觸及 5NF。理解原理，才能在實務中做出正確取捨。