單一主鍵讓 2NF 自動成立，但重複一點都沒少

「框架預設用 id 當 PK，所以第二正規化自動滿足」——這句話定義上成立，但讀成「所以不用拆表」就會做出一張到處重複的表。

為什麼定義上成立

部分相依的定義就是「相依於主鍵的一部分」。主鍵只有一欄時，它沒有「一部分」可言——就像一塊沒切過的餅乾拿不出「半塊的一部分」。所以 2NF 不是被你檢查通過的，是這個問題在單一 PK 下不存在。

注意這是定義層面的豁免，不是「資料變乾淨了」。

為什麼它是半個真話

同一張表加上代理主鍵：

order_item_id (PK)	customer_id	customer_name	item_id	item_name	price
1	1	阿寶	1	鉛筆	20
2	1	阿寶	2	橡皮擦	50
5	3	老皮	1	鉛筆	20

「阿寶」還是寫了兩次，「鉛筆 20」也是。重複一點都沒少，改名還是要改很多列。變的只有這個問題的罪名：

• PK = (customer_id, item_id) 時，customer_name 巴著主鍵的一半 → 2NF 違規
• PK = order_item_id 時，customer_name 巴著 customer_id 這個普通欄位 → 3NF 違規（遞移相依：欄位靠另一個普通欄位才連到主鍵）

同一個毛病換了個窗口辦手續，該拆的表一張都沒少拆，拆完的結果也一模一樣。

正確讀法

單一 id 當 PK 只是讓你不必在 2NF 這一關費心，不是讓你可以不拆表。 檢查表乾不乾淨，要看的是 改漏一列的代價不是工多，是資料安靜地不一致，不是哪一關過了。

同一個陷阱在 BCNF 也有一個版本（「PK 單欄 → 3NF 即 BCNF」），成因相同：條文寫「主鍵」，但真正的判準是候選鍵 — 見 正規化的判準是候選鍵，不是主鍵。