一句話核心思想

第三范式就是：消除“間接依賴”，表中不能有“子關系”。

更專業一點說：在滿足第二范式的基礎上，確保表中的每一列都直接依賴于主鍵，而不能依賴于其他非主鍵列（即不能存在傳遞依賴）。

用一個生動的例子來解釋

假設我們有一張 學生表，記錄學生、他們的學院以及學院的詳細信息。

這張表有什么問題？（它違反第三范式）

1. 冗余重復：

   • 張三是計算機學院的，李四也是。那么“計算機學院”的院長和地點信息就被重復存儲了多次。如果一個學院有幾千個學生，這個信息就會被重復幾千次！

2. 更新異常：

   • 如果計算機學院換院長了，新任院長是“王教授”。我們必須找到所有所在學院 = 計算機學院的記錄，一條一條地去修改學院院長字段。萬一漏改了一行，就會導致數據不一致（有的記錄是李教授，有的記錄是王教授）。

3. 插入異常：

   • 學校新成立了一個“法學院”，已經任命了院長“趙教授”，地點在“社科樓C座”。但是，如果還沒有學生被錄入這個學院，我們就無法把這個新學院的信息插入到這張表里。因為學號主鍵不能為空。

4. 刪除異常：

   • 如果學生“李四”畢業了，我們從表中刪除了他的記錄。假如他恰好是計算機學院的最后一個學生，那么刪除這條記錄的同時，我們也會意外地丟失“計算機學院”的院長和地點信息。

為什么會這樣？

因為這張表里存在“間接依賴”，也叫“傳遞依賴”。我們來分析一下依賴關系：

• 學號 (主鍵) -> 決定了姓名和所在學院。 ? (這沒問題)

• 學號 (主鍵) -> 所在學院 -> 決定了學院院長和學院地點。 ? (問題在這里！)

學院院長和學院地點并不是直接由學號決定的，而是由所在學院這個非主鍵字段決定的。學號決定了所在學院，所在學院又決定了學院院長，這就形成了一個傳遞鏈。

這種“一個非主鍵字段決定了其他非主鍵字段”的情況，就是違反第三范式的根源。

如何改造？（使其符合第三范式）

核心操作：繼續拆表！把“子關系”獨立出去。

我們把上面那張表拆成兩張表：

1. 學生表 (核心信息：學生和學院的從屬關系)

2. 學院表 (專門管理學院的詳細信息)

改造后的好處：

• 數據冗余徹底消除：每個學院的信息（院長、地點）只存儲一次，而不是隨著學生數量重復存儲。

• 避免更新異常：計算機學院換院長，只需在學院表里修改一條記錄即可。

• 避免插入異常：新成立的“法學院”可以直接添加到學院表，完全不受是否有學生的影響。

• 避免刪除異常：即使計算機學院的所有學生都畢業了，其信息依然安全地保存在學院表中。

總結：如何判斷和滿足第三范式？

1. 第一步：確保你的表已經滿足了第二范式。

2. 第二步：檢查表中的每一個非主鍵字段，問自己兩個問題：

   a. “這個字段是直接依賴于主鍵嗎？”
   b. “這個字段會不會依賴于另一個非主鍵字段？”

3. 第三步：如果發現存在這種“傳遞依賴”（即字段A依賴于主鍵，但字段B又依賴于字段A），就把這些間接依賴的字段（B）拆出去，建立一張新表，讓決定它們的那個字段（A）成為新表的主鍵。

一個簡單的記憶口訣

• 第一范式（1NF）：列不可再分。（保證原子性）

• 第二范式（2NF）：消除部分依賴。（非主鍵字段必須完全依賴整個主鍵）

• 第三范式（3NF）：消除傳遞依賴。（非主鍵字段之間不能有依賴關系）

最終記住那個簡單的比喻：

• 違反2NF：像一個員工同時向兩個部門經理匯報工作，職責不清。

• 違反3NF：像在員工表里不僅記錄了員工的部門，還記錄了部門的預算、部門的規章制度等。這些信息本應屬于部門表，而不是員工表。