資料庫管理系統 - 正規化化

函式依賴

函式依賴 (FD) 是關係中兩個屬性之間的一組約束。函式依賴表示如果兩個元組在屬性 A1、A2、…、An 上具有相同的值，則這兩個元組必須在屬性 B1、B2、…、Bn 上具有相同的值。

函式依賴用箭頭符號 (→) 表示，即 X→Y，其中 X 函式決定 Y。左側屬性決定右側屬性的值。

阿姆斯特朗公理

如果 F 是一組函式依賴，則 F 的閉包，記作 F⁺，是由 F 邏輯上隱含的所有函式依賴的集合。阿姆斯特朗公理是一組規則，重複應用這些規則可以生成函式依賴的閉包。

• 自反規則 − 如果 α 是一組屬性，而 β 是 α 的子集，則 α 包含 β。

• 增廣規則 − 如果 a → b 成立，而 y 是屬性集，則 ay → by 也成立。也就是說，在依賴中新增屬性不會改變基本依賴。

• 傳遞規則 − 與代數中的傳遞規則相同，如果 a → b 成立且 b → c 成立，則 a → c 也成立。a → b 稱為函式決定 b。

平凡函式依賴

• 平凡的 − 如果函式依賴 (FD) X → Y 成立，其中 Y 是 X 的子集，則稱為平凡的 FD。平凡的 FD 總是成立的。

• 非平凡的 − 如果函式依賴 (FD) X → Y 成立，其中 Y 不是 X 的子集，則稱為非平凡的 FD。

• 完全非平凡的 − 如果函式依賴 (FD) X → Y 成立，其中 X 與 Y 的交集 = Φ，則稱為完全非平凡的 FD。

正規化化

如果資料庫設計不完善，則可能包含異常，這對任何資料庫管理員來說都像是一場噩夢。管理包含異常的資料庫幾乎是不可能的。

• 更新異常 − 如果資料項分散且未正確連結到彼此，則可能導致奇怪的情況。例如，當我們嘗試更新一個數據項時，它的副本分散在多個位置，一些例項被正確更新，而另一些例項保留舊值。此類例項會使資料庫處於不一致狀態。

• 刪除異常 − 我們試圖刪除一條記錄，但由於不知道資料也儲存在其他地方，一部分記錄未被刪除。

• 插入異常 − 我們試圖在一個根本不存在的記錄中插入資料。

正規化化是一種消除所有這些異常並將資料庫置於一致狀態的方法。

第一正規化

第一正規化在關係（表）的定義中定義。此規則定義關係中的所有屬性都必須具有原子域。原子域中的值是不可分割的單元。

我們將關係（表）重新排列如下，以將其轉換為第一正規化。

每個屬性必須僅包含來自其預定義域的單個值。

第二正規化

在學習第二正規化之前，我們需要了解以下內容：

• 主鍵屬性 − 作為候選鍵一部分的屬性稱為主鍵屬性。

• 非主鍵屬性 − 不是主鍵一部分的屬性稱為非主鍵屬性。

如果我們遵循第二正規化，則每個非主鍵屬性都應完全函式依賴於主鍵屬性。也就是說，如果 X → A 成立，則 X 的任何真子集 Y 都不能使 Y → A 也成立。

我們在 Student_Project 關係中看到，主鍵屬性是 Stu_ID 和 Proj_ID。根據規則，非鍵屬性，即 Stu_Name 和 Proj_Name 必須依賴於兩者，而不能單獨依賴於任何主鍵屬性。但是我們發現 Stu_Name 可以獨立地由 Stu_ID 識別，Proj_Name 可以獨立地由 Proj_ID 識別。這稱為部分依賴，第二正規化不允許這種情況。

我們如上圖所示將關係分解為兩個。因此不存在部分依賴。

第三正規化

為了使關係處於第三正規化，它必須處於第二正規化，並且必須滿足以下條件：

• 任何非主鍵屬性都不傳遞依賴於主鍵屬性。
• 對於任何非平凡函式依賴 X → A，則：
  X 是超鍵，或者
  • A 是主鍵屬性。

我們發現在上面的 Student_detail 關係中，Stu_ID 是鍵並且是唯一的主鍵屬性。我們發現 City 可以由 Stu_ID 和 Zip 本身識別。Zip 既不是超鍵，City 也不是主鍵屬性。此外，Stu_ID → Zip → City，所以存在傳遞依賴。

為了將此關係轉換為第三正規化，我們將關係分解為兩個關係，如下所示：

Boyce-Codd正規化

Boyce-Codd 正規化 (BCNF) 是對第三正規化的嚴格擴充套件。BCNF 指出：

• 對於任何非平凡函式依賴 X → A，X 必須是超鍵。

在上圖中，Stu_ID 是 Student_Detail 關係中的超鍵，Zip 是 ZipCodes 關係中的超鍵。所以，

Stu_ID → Stu_Name，Zip

和

Zip → City

這證實了這兩個關係都處於 BCNF。