資料庫設計/函式依賴

函式依賴 (FD) 是兩個屬性之間的關係，通常是表中主鍵和其他非主鍵屬性之間的關係。對於任何關係 R，屬性 Y 函式依賴於屬性 X（通常是主鍵），如果對於 X 的每個有效例項，該 X 值都唯一地確定 Y 的值。這種關係由下面的表示表示

X ———–> Y

上述 FD 圖的左側稱為決定因素，右側稱為依賴因素。這裡有一些例子。

在第一個例子中，SIN 決定 Name、Address 和 Birthdate。給定 SIN，我們可以確定表中的任何其他屬性。

SIN ———-> Name, Address, Birthdate

對於第二個例子，SIN 和 Course 決定完成日期 (DateCompleted)。對於複合主鍵，這也必須有效。

SIN, Course ———> DateCompleted

第三個例子表明 ISBN 決定 Title。

ISBN ———–> Title

函式依賴規則

考慮表 11.1 中所示的關係模式 R(ABCDE) 的資料表 r(R)。

表 11.1. 函式依賴示例，作者：A. Watt。

當你看這個表時，問問自己：在表 R 中的屬性之間，我們能觀察到什麼樣的依賴關係？由於 A 的值是唯一的（a1、a2、a3 等），因此從 FD 定義可以得出

A → B, A → C, A → D, A → E

也可以得出 A →BC （或 ABCDE 的任何其他子集）。
這可以概括為 A →BCDE。
從我們對主鍵的理解來看，A 是主鍵。

由於 E 的值始終相同（全部為 e1），因此可以得出

A → E, B → E, C → E, D → E

但是，我們通常不能用 ABCD → E 來概括以上內容，因為通常情況下， A → E, B → E, AB → E。

其他觀察結果

BC 的組合是唯一的，因此 BC → ADE。
BD 的組合是唯一的，因此 BD → ACE。
如果 C 值匹配，則 D 值也匹配。
1. 因此， C → D
2. 但是，D 值不能確定 C 值
3. 所以 C 不能確定 D，而 D 也不能確定 C。

檢視實際資料可以幫助澄清哪些屬性是依賴屬性，哪些是決定因素。

推理規則

阿姆斯特朗公理是用於推斷關係資料庫上所有函式依賴的一組推理規則。它們是由威廉·W·阿姆斯特朗開發的。以下是描述將在符號方面使用的內容，以解釋這些公理。

令 R(U) 是一個在屬性集 U 上的關係模式。我們將使用字母 X、Y、Z 來表示 U 的任何子集，並簡寫兩個屬性集的並集，而不是通常的 X U Y。

自反公理

該公理表示，如果 Y 是 X 的子集，則 X 決定 Y（見圖 11.1）。

圖 11.1. 自反公理的方程。

例如，PartNo —> NT123 其中 X (PartNo) 由多個資訊組成；即 Y (NT) 和 partID (123)。

擴充公理

擴充公理，也稱為部分依賴，表示如果 X 決定 Y，則 XZ 決定 YZ，對於任何 Z（見圖 11.2）。

圖 11.2. 擴充公理的方程。

擴充公理表示每個非主鍵屬性都必須完全依賴於主鍵。在下面顯示的示例中，StudentName、Address、City、Prov 和 PC（郵政編碼）僅依賴於 StudentNo，而不依賴於 StudentNo 和 Grade。

StudentNo, Course —> StudentName, Address, City, Prov, PC, Grade, DateCompleted

這種情況不可取，因為每個非主鍵屬性都必須完全依賴於主鍵。在這種情況下，學生資訊僅部分依賴於主鍵 (StudentNo)。

要解決這個問題，我們需要將原始表分解成兩個，如下所示

表 1：StudentNo, Course, Grade, DateCompleted
表 2：StudentNo, StudentName, Address, City, Prov, PC

傳遞公理

傳遞公理表示，如果 X 決定 Y，而 Y 決定 Z，則 X 也必須決定 Z（見圖 11.3）。

圖 11.3. 傳遞公理的方程。

下面的表包含與學生沒有直接關係的資訊；例如，ProgramID 和 ProgramName 應該有自己的表。ProgramName 不依賴於 StudentNo；它依賴於 ProgramID。

StudentNo —> StudentName, Address, City, Prov, PC, ProgramID, ProgramName

這種情況不可取，因為一個非主鍵屬性 (ProgramName) 依賴於另一個非主鍵屬性 (ProgramID)。

要解決這個問題，我們需要將此表分解成兩個：一個用於儲存有關學生的資訊，另一個用於儲存有關程式的資訊。

表 1：StudentNo —> StudentName, Address, City, Prov, PC, ProgramID
表 2：ProgramID —> ProgramName

但是，我們仍然需要在學生表中保留外部索引鍵，以便我們可以識別學生註冊的哪個程式。

並集

此規則表明，如果兩個表是分開的，而主鍵相同，則您可能需要考慮將它們放在一起。它表示如果 X 決定 Y 並且 X 決定 Z，則 X 也必須決定 Y 和 Z（見圖 11.4）。

圖 11.4. 並集規則的方程。

例如，如果

SIN —> EmpName
SIN —> SpouseName

您可能希望將這兩個表合併成一個，如下所示

SIN –> EmpName, SpouseName

一些資料庫管理員 (DBA) 可能選擇將這些表分開，原因有二。第一，每個表都描述了一個不同的實體，所以應該將這些實體分開。第二，如果 SpouseName 要在大多數情況下保留為 NULL，則無需將其包含在與 EmpName 相同的表中。

分解

分解是並集規則的逆運算。如果您有一個表，其中似乎包含兩個由相同主鍵決定的實體，請考慮將它們分解成兩個表。此規則表示，如果 X 決定 Y 和 Z，則 X 分別決定 Y 和 X 決定 Z（見圖 11.5）。

圖 11.5. 補償規則的方程。

依賴圖

依賴圖（見圖 11.6）說明了非規範化表中可能存在的各種依賴關係。非規範化表是指其中存在資料冗餘的表。

圖 11.6. 依賴圖。

此表中確定了以下依賴關係

ProjectNo 和 EmpNo 共同構成主鍵。
部分依賴
- ProjectNo —> ProjName
- EmpNo —> EmpName, DeptNo,
- ProjectNo, EmpNo —> HrsWork
傳遞依賴
- DeptNo —> DeptName

關鍵詞

阿姆斯特朗公理: 一組用於推斷關係資料庫中所有函式依賴的推理規則

DBA: 資料庫管理員

分解: 一條規則，建議如果有一個表看起來包含兩個由相同主鍵確定的實體，則考慮將它們拆分成兩個表。

依賴: 函式依賴圖的右側

決定因素: 函式依賴圖的左側

函式依賴 (FD): 兩個屬性之間的關係，通常是表中的主鍵和其他非鍵屬性之間的關係。

非規範化表: 包含資料冗餘的表

並集: 一條規則，建議如果兩個表是分開的，而主鍵是相同的，則考慮將它們合併。

練習

參見下一章。

歸屬

資料庫設計的本章（包括影像，除非另有說明）是維基百科自由百科全書中阿姆斯特朗公理的衍生副本，該副本在知識共享署名-相同方式共享 3.0 未移植許可下獲得許可。

以下材料由 Adrienne Watt 撰寫

一些函式依賴規則
關鍵詞

參考資料

BCOpenCampus：資料庫設計

← ER 建模

資料庫設計

規範化 →