什麼是第二正規形式（2NF）？

在處理數據庫時，常常會遇到像是冗餘數據和不一致更新等問題。第二范式是一個數據庫規範化步驟，建立在第一范式（1NF）的基礎上，用於創建更清潔和高效的數據表。

理解第二范式對於從事數據庫設計或數據管理的人員至關重要，並為諸如第三范式（3NF）之類的更高規範化形式奠定基礎。在本文中，我們將探討第二范式的工作原理，以及如何通過實際示例將表轉換為滿足第二范式要求。我們還將討論第二范式的好處和缺點，以及適合的使用案例。

理解第二范式

第二范式是一個專注於消除部分依賴的數據庫規範化步驟。它是由關係數據庫的先驅埃德加·科德（Edgar F. Codd）引入的，作為他在規範化工作中的一部分。

在表能夠達到第二范式之前，它必須滿足第一范式的規則：

• 原子性：每個儲存格必須包含單一值（不允許重複組或陣列）。
• 唯一列：表格必須有明確的主鍵。

2NF 進一步加入額外規則：消除部分相依性。

當非主要屬性（不是任何候選鍵的一部分的列）依賴於複合鍵的部分而不是整個鍵時，就會發生部分依賴。第2范式確保所有非主要屬性都依賴於整個主鍵，而不僅僅是其中的一部分。在表中保留部分依賴意味著冗余數據可能會進入數據庫，這將導致更新或刪除時的效率低下和潛在的不一致。

僅憑理論可能有點枯燥，讓我們看一個實際例子。

以下是 Datacamp 學生的課程註冊表。

這裡，主鍵是學生ID和課程ID的組合。然而，非主要屬性課程名稱和課程費用僅依賴於課程ID，而不是整個鍵。這違反了2NF。

將表格分解以達成第二正規形式的步驟

為了確保表格符合第二正規形式的規則，您需要：

1. 識別所有候選鍵：確定能唯一識別表中行的最小屬性集。這些就是您的候選鍵。
2. 確定函數依賴：識別表中的所有函數依賴。具體來說，尋找那些非主屬性（不屬於任何候選鍵的屬性）僅依賴於複合鍵的一部分的依賴。
3. 消除部分依賴：對於每個部分依賴：
• 將依賴的屬性連同它們所依賴的鍵的一部分移入一個新表。
• 確保新表有一個唯一的主鍵。
4. 重複直到沒有部分依賴為止：確認所有表中的每個非主屬性都完全依賴於其各自的主鍵。

第二范式實踐示例

現在讓我們看兩個例子。

示例 1：課程註冊表

早些時候，我們看到了以下課程選課表：

讓我們按照上一節中概述的步驟進行。

1. 確定我們的候選鍵。

在這種情況下，候選鍵是學生ID和課程ID的複合鍵。這個獨特組合識別表中的每一行。

2. 確定我們的函數依賴。

課程名稱和教師姓名取決於課程ID，而不是完整的複合鍵（學生ID，課程ID）。這是部分依賴，因為這些屬性僅取決於複合鍵的一部分。

3. 消除部分依賴

我們需要將僅依賴部分主鍵（課程名稱和教師姓名）的屬性移至一個新表，該表僅基於課程ID。

分解後，我們的新表如下：

課程報名表

課程詳細資料表

範例2：訂單表

我們將從這個訂單表開始。請嘗試遵循我們上面概述的步驟，自己對這個表進行拆解！

1. 確定我們的候選鍵

訂單編號和商品編號的組合唯一識別每一行，使得（訂單編號，商品編號）成為一個複合候選鍵。因為沒有單個列可以唯一識別行，原因如下：

• 訂單編號本身並不是唯一的，因為多個產品可以屬於同一訂單。
• 產品編號本身並不是唯一的，因為相同的產品可以出現在不同的訂單中。

這意味著（訂單編號，產品編號）也是我們的主鍵。

2. 確定我們的功能依賴性

訂單日期取決於訂單編號（而不是完整的複合鍵）。這是部分依賴。

產品名稱 和 供應商名稱 取決於 產品編號（而非完整複合鍵）。這些也是部分依賴。

3. 消除部分依賴

我們需要將表格拆分為更小的表格，每個表格處理一個邏輯依賴。

首先，我們將創建一個包含訂單信息的表，其中包含特定於訂單編號的信息。

訂單表

然後，我們創建一個包含特定於產品編號的信息的表。

訂單表

現在，我們的資料庫已經達到第二范式（2NF），因為 1) 所有部分依賴已被消除，2) 非主屬性完全依賴於其各自的主鍵。

何時實施第二范式

那麼，為什麼您應該將數據庫重構為第二范式（2NF）？這是否足夠，還是您應該更進一步，目標是第三范式（3NF）？

第二范式的優點和限制

第二范式提供了幾個優勢，使其成為數據庫正規化過程中的一個有用步驟：

• 增強數據完整性：通過消除部分依賴，2NF 最小化插入、更新和刪除異常，從而導致更可靠的數據庫。
• 減少冗餘：2NF 減少數據重複，優化存儲使用並簡化數據維護。
• 改善的資料結構: 通過建立更乾淨和更有效的數據庫設計，為進一步規範化，如達到第三范式，奠定基礎。

但它確實帶來了一些限制:

• 增加的複雜性: 將表分解以滿足2NF可能會使設計過程變得更加複雜，尤其是在處理複合鍵和依賴關係時。
• 額外的連接：拆分表可能需要在查詢中進行更多的連接，可能會影響大型數據集或複雜查詢系統的性能 – 更多請參見以下內容。
• 殘留冗余：第二正規化減少了部分依賴性，但並未解決遞歸依賴性問題，直到在第三正規化中解決之前仍然存在一些冗余。

第二正規化的性能考慮

將表進行分解以消除部分依賴可能直接影響數據庫性能。一方面，實現2NF可減少數據冗余並改善一致性，從而在插入、更新或刪除操作期間減少異常。另一方面，規範化可能增加表的數量，這意味著在檢索相關數據時需要進行額外的連接。這可能會影響大型數據集中的查詢性能。

為確保規範化的數據庫保持高性能，請確保您遵循以下最佳實踐：

• 索引： 使用索引加快分解表之間的連接速度。
• 查詢優化： 優化查詢以最小化額外聯接的成本。
• 混合方法： 在性能重要的區域，如報告表格中，將正規化與非正規化相結合。
• 定期監控： 使用性能分析工具持續評估您的數據庫性能，以捕捉任何潛在問題。

第二范式是否只是達到第三范式的過渡步驟？

在大多數情況下，數據庫設計師通常力求實現第三正規形，因為它能進一步減少冗余並提高整體數據完整性。然而，實現第三正規形通常需要額外的工作，例如創建更多表和關係，這可能會在查詢執行中引入複雜性和性能折衷。

有時僅使用第二正規形就可以足夠。如果簡單性和快速實施是優先考慮的因素，例如在小規模項目、原型設計或數據冗余最小的情況下，第二正規形就可以滿足要求。例如，在所有屬性已經完全依賴於簡單主鍵的系統中，實現第二正規形可能就能實現減少部分依賴的主要目標，而無需進一步進行規範化。

超越第二正規形：邁向第三正規形

如果您希望進一步規範化您的數據庫，可以持續重構您的表以達到第三正規形。

3NF 在 2NF 的基礎上解決了 傳遞依賴 的問題——即非鍵屬性依賴於其他非鍵屬性而不是主鍵的情況。這一進程確保每個屬性直接依賴於主鍵而不是其他任何東西。

例如，在一個跟踪課程註冊的表格中：

• 2NF：確保屬性（如課程名稱和學生姓名）完全依賴於它們各自的主鍵（例如，學生ID和課程ID）。這消除了部分依賴，其中非關鍵屬性僅依賴於複合鍵的一部分。
• 第三正規化（3NF）：確保像教師詳細資訊或部門資訊等屬性被存儲在單獨的表中，消除了轉移依賴。

3NF非常適合更複雜的系統，特別是在數據量增長時，數據完整性和效率至關重要。如果您想了解更多關於3NF及其更嚴格形式BCNF的信息，請查看我們的什麼是第三正規形式？文章。

結論

第二正規化是數據庫規範化中的一個基本步驟，填補了1NF和3NF等高級形式之間的差距。通過刪除部分依賴，2NF減少了冗余並提高了數據的可靠性。盡管可能會增加一些複雜性，但改善數據完整性和簡化維護的好處使其成為有效數據庫設計中至關重要的一部分。

如果您準備進一步提升技能，探索我們的數據庫設計課程，深入了解規範化技術及其實際應用。您還可以通過我們的SQL認證來驗證您的SQL和數據庫管理技能，向潛在雇主展示您的專業知識！

最後，我想說，如果您是企業的決策者，並且知道您需要做一些工作來建立更乾淨、更高效的數據庫，考慮提交一個企業DataCamp演示請求。我們可以幫助提升您的團隊能力，使您能夠創建推動業務效率和創新的可擴展數據庫系統。我們甚至可以創建定制的學習路徑和課程。