SQL 中的規範化：1NF、2NF、3NF 和 BCNF

規範化是確保關係數據庫模型高效、適用於通用查詢並且沒有諸如插入、更新和刪除異常等不良特徵的系統過程，從而導致數據的完整性丟失。 此規範化過程還有助於消除數據冗餘並減少任何插入、更新或刪除操作後出現不一致的機會。

為了更好地理解，請考慮以下模式：學生（姓名、地址、學科、年級）

此模式存在一些問題或效率低下。

1)冗餘：學生的地址在他註冊的每個科目中重複。

2）更新異常：我們可能在一個元組（行）中更新了地址，而在其他行中保持不變。 因此，我們不會為每個學生提供始終如一的唯一地址。

3)插入異常：我們不會在沒有註冊至少一門學科的情況下記錄學生的地址。 同樣，當學生想要註冊新學科時，可能會插入不同的地址。

4）刪除異常：如果學生決定停止所有已註冊的科目，那麼學生的地址也會在刪除過程中丟失。

因此，重要的是通過在元組添加、刪除或更新操作之後不會創建異常的關係來表示用戶數據。 這只能通過仔細分析完整性約束，尤其是數據庫的數據依賴關係來實現。

應該設計關係，以便只有那些自然存在在一起的屬性才被分組。 這主要可以通過對所有數據屬性的含義的基本理解來完成。 但是，我們仍然需要一些正式的措施來確保我們的設計目標。

規範化是正式的措施。 它回答了為什麼一個特定的屬性組會比其他屬性更好的問題。

截至今天存在七種範式：

• 第一範式 (1NF)
• 第二範式 (2NF)
• 第三範式 (3NF)
• Boyce-Codd 範式 (BCNF)
• 第四範式 (4NF)
• 第五範式 (5NF)
• 第六或域鍵範式 (6NF)

閱讀： SQL 中的視圖類型

第一範式（1NF 或最小形式）

• 行沒有從上到下的排序，列沒有從左到右的排序。
• 沒有重複的行。
• 每個行列交集都包含來自適用域的一個值或空值。 此條件指示所有列值都應該是原子的、標量的或僅包含單個值。 此處不允許在多列中重複信息或值。
• 所有列都是規則的（即行沒有隱藏組件，例如行 ID、對象 ID 或隱藏時間戳）。

讓我們以未規範化的模式為例。 假設設計師希望記錄客戶的姓名和電話號碼。 他們定義了一個客戶表，如下所示：

在這裡，它不在 1 NF 中。 電話號碼列不是原子的或沒有標量值，即它有多個值，這在 1 NF 中是不允許的。

使其成為 1 NF

• 我們將首先將我們的單個表分解（分解）為兩個。
• 每個表應該只包含一個實體的信息。

此設計中不會出現重複的電話號碼組。 相反，每個客戶到電話號碼的鏈接都出現在其自己的記錄中。

結帳：最常見的 SQL 面試問題和答案

第二範式

每個範式都比其前身俱有更多的約束條件。 因此，根據定義，任何處於第二範式 (2NF) 或更高形式的表也屬於 1NF。 另一方面，在 1NF 中的表可能在也可能不在 2NF 中； 如果它在 2NF 中，它可能在也可能不在 3NF 中，依此類推。

當且僅當一個 1NF 表的非主屬性在功能上都不依賴於候選鍵的一部分（正確子集）時，才稱 1NF 表在 2NF 中。 （非主屬性不屬於任何候選鍵。）

請注意，當 1NF 表沒有復合候選鍵（候選鍵由多個屬性組成）時，該表自動處於 2NF。

檢查是否將 FD 設置為 { BC 的關係 R (A, B, C, D, E) D，交流？ 是，乙？ E } 在 2NF 中？

• 正如我們所看到的，通過應用隸屬度算法，AC 的閉包是 (AC)+ = {A, C, B, E, D}。 但是它的子集都不能自己確定關係的所有屬性，所以AC是這個關係的候選鍵。 此外，A 和 C 都不能從關係的任何其他屬性派生，因此只有 1 個候選鍵，即 {AC}。
• 這裡 {A, C} 是主要屬性，{B, D, E} 是非主要屬性。
• 關係 R 已經處於第一範式，因為 1NF 中的關係 DBMS 不允許多值或複合屬性。

卑詩省？ D 是第二範式，因為 BC 不是候選密鑰 AC 的真子集，

交流電？ BE 是第二範式，因為 AC 本身就是候選鍵，並且

乙？ E 是第二範式 B 不是候選密鑰 AC 的真子集。

因此，給定的關係 R 是第二範式。

第三範式

當且僅當對於它的每個功能依賴關係時，才稱表處於 3NF 中。

X → A ，至少滿足下列條件之一：

• X 包含 A（即 X → A 是一個平凡的函數依賴），或者
• X 是超級鍵，或
• A 是主要屬性（即，A 存在於候選鍵中）

3NF 的另一個定義表明，R 的每個非鍵屬性都非傳遞地依賴（即直接依賴）R 的主鍵。這意味著沒有非主屬性（不是候選鍵的一部分）在功能上依賴於其他非主屬性。 如果有兩個依賴項，例如 A ？ B 和 BC，那麼從這些 FD 中，我們可以推導出 A ? C. 這種依賴AC 是傳遞的。

3NF 示例：

考慮以下關係 Order (Order#, Part, Supplier, UnitPrice, QtyOrdered) 與給定的 FD 集：

命令＃ ？ 零件、供應商、訂購數量和供應商、零件？ 單價）

這裡 Order# 是關係的關鍵。

使用 Amstrong 公理，我們得到

命令＃ ？ 零件，訂單？ 供應商和訂單？ 訂購數量。

命令＃ ？ 部分，供應商和供應商，部分？ 單價，都給出訂單#？ 單價。

因此，我們看到所有非主屬性都依賴於鍵 (Order#)。 但是，Order# 和 UnitPrice 之間存在傳遞依賴關係。 所以這個關係不在 3NF 中。 我們如何在 3NF 中實現它？

我們不能存儲任何供應商提供的任何零件的單價，除非有人為該零件下訂單。 所以我們必須分解表格，使其遵循 3NF，如下所示。

訂單（Order#、Part、Supplier、QtyOrdered）和價格主數據（Part、Supplier、UnitPrice）。

現在不存在傳遞依賴。 該關係在 3NF 中。

另請閱讀：用於數據科學的 SQL

從世界頂級大學在線學習軟件課程。 獲得行政 PG 課程、高級證書課程或碩士課程，以加快您的職業生涯。

結論

規範化還有更多內容，例如 BCNF、4NF、5NF 和 6NF。 簡而言之，BCNF 只不過是 3NF 的擴展，因為 3NF 的最後一條規則在這裡不適用。 所有功能依賴項都需要在左側具有關鍵屬性，而在右側沒有。 （BCNF 也稱為 3.5NF）。 然而，4NF 及以後的範式很少在常規實踐中實施。

如果您有興趣了解有關全棧開發的更多信息，請查看 upGrad & IIIT-B 的全棧軟件開發執行 PG 計劃，該計劃專為在職專業人士設計，提供 500 多個小時的嚴格培訓、9 個以上的項目、和任務、IIIT-B 校友身份、實用的實踐頂點項目和頂級公司的工作協助。