接下來我們詳細解釋 BC 范式（Boyce-Codd范式，簡稱 BCNF），并通過具體例子說明其定義和應用。
一、BC范式的定義
BC范式（Boyce-Codd范式，BCNF）是數據庫規范化理論中的一種范式，它比第三范式（3NF）更嚴格。其核心定義如下：
BCNF 定義：
在關系模式中，如果每個決定因素（即能夠決定其他屬性的屬性或屬性組）都包含候選鍵，則該關系模式滿足 BCNF。換句話說，如果關系模式中不存在非平凡的函數依賴，使得決定因素不包含候選鍵，則該關系模式滿足 BCNF。
關鍵點：
- 決定因素：一個屬性或屬性組，能夠決定另一個屬性或屬性組。
- 候選鍵：能夠唯一標識關系中每一行的屬性或屬性組。
- 非平凡函數依賴：指不是恒等式的函數依賴，例如 A → B，其中 A 和 B 是不同的屬性。
BCNF 的目標是進一步消除冗余，確保數據的一致性，避免數據更新異常。
二、BC范式的例子
1. 初始表結構
假設我們有一個存儲學生選課信息的表，但存在一些復雜的依賴關系：
表：StudentCourse
| StudentID (學號) | CourseID (課程號) | Professor (教授) |
|---|---|---|
| 1001 | CS101 | 李教授 |
| 1001 | CS201 | 王教授 |
| 1002 | EE101 | 趙教授 |
| 1003 | CS101 | 李教授 |
| 1003 | CS301 | 劉教授 |
| 在這個表中： |
- 候選鍵是 (StudentID, CourseID)，因為它們共同唯一標識每一行。
- 存在函數依賴：CourseID → Professor（即課程號決定教授）。
2. 分析是否滿足 BCNF
檢查函數依賴 CourseID → Professor：
- 決定因素是 CourseID。
- CourseID 不是候選鍵（候選鍵是 (StudentID, CourseID)）。
因此，這個關系模式不滿足 BCNF，因為存在一個決定因素（CourseID）不包含候選鍵。
3. 分解以滿足 BCNF
為了滿足 BCNF，我們需要將表分解為兩個關系模式，消除 CourseID → Professor 的依賴：
- 第一個關系模式：包含課程和教授的信息。
- 關系模式：Course (CourseID, Professor)
- 候選鍵：CourseID
- 函數依賴：CourseID → Professor
- 第二個關系模式：包含學生選課的信息。
- 關系模式：StudentCourse (StudentID, CourseID)
- 候選鍵：(StudentID, CourseID)
分解后的兩個表：
Course 表：
| CourseID (課程號) | Professor (教授) |
|---|---|
| CS101 | 李教授 |
| CS201 | 王教授 |
| EE101 | 趙教授 |
| CS301 | 劉教授 |
StudentCourse 表：
| StudentID (學號) | CourseID (課程號) |
|---|---|
| 1001 | CS101 |
| 1001 | CS201 |
| 1002 | EE101 |
| 1003 | CS101 |
| 1003 | CS301 |
4. 驗證 BCNF
- Course 表：
- 候選鍵：CourseID
- 所有函數依賴（如 CourseID → Professor）的決定因素都是候選鍵。
- 滿足 BCNF。
- StudentCourse 表：
- 候選鍵：(StudentID, CourseID)
- 不存在其他函數依賴，只有候選鍵決定其他屬性。
- 滿足 BCNF。
三、總結
- BCNF 的核心要求：每個決定因素都必須是候選鍵，從而消除冗余和更新異常。
- 分解方法：通過將表分解為多個滿足 BCNF 的子表，確保每個子表的函數依賴都滿足 BCNF 的要求。
- 優點：進一步減少數據冗余，提高數據一致性和查詢效率。
- 適用場景：適用于需要高數據一致性和低冗余的復雜關系模式。
接下來我們來詳細解釋第四范式（4NF）。
一、4NF的定義
第四范式（Fourth Normal Form, 4NF）是數據庫規范化理論中的高級范式，它處理的是**多值依賴（Multivalued Dependency, MVD）**的問題。它建立在第三范式（3NF）或 Boyce-Codd 范式（BCNF）的基礎之上。
4NF 的定義：
一個關系模式 R 屬于第四范式（4NF），當且僅當，對于 R 中的每一個非平凡的多值依賴 X →→ Y（即 X 不能決定 R 的所有屬性，Y 不是 R 的子集），X 都包含 R 的一個超鍵（Superkey）。
換句話說，在滿足 4NF 的關系中，不允許存在非平凡的多值依賴，除非該依賴的決定因素（X）是一個超鍵。
關鍵概念：
- 多值依賴 (Multivalued Dependency, MVD)：
- 與函數依賴（FD）不同，函數依賴是一個屬性（或屬性組）決定另一個屬性的唯一值。而多值依賴是指一個屬性（或屬性組）可以對應另一個屬性（或屬性組）的多個獨立的集合。
- 形式化表示：X →→ Y 意味著對于 X 的一個值，Y 可以有多個獨立的值與之對應，并且這些 Y 的值與關系中的其他屬性（Z）的值無關。
- 舉例：如果
部門 →→ 部門經理，那么一個部門可以有多個經理，這些經理的集合是獨立的，與其他屬性（如部門地點）無關。
- 非平凡多值依賴 (Non-Trivial MVD)：
- 指的是
X →→ Y，其中Y不是R的一個子集，并且X不能決定R的所有屬性（即R - (X U Y)不是空集）。
- 指的是
- 超鍵 (Superkey)：
- 指關系模式中能夠唯一標識元組的一個屬性或屬性組合，并且它可能包含多余屬性（即它可能包含候選鍵之外的其他屬性）。
為什么需要 4NF？
違反 4NF 的關系模式會導致數據冗余和插入、刪除異常。當關系中存在非平凡的多值依賴且決定因素不是超鍵時，相關的多值屬性集合必須作為一個整體出現或消失，這限制了數據的靈活性。
- 指關系模式中能夠唯一標識元組的一個屬性或屬性組合，并且它可能包含多余屬性（即它可能包含候選鍵之外的其他屬性）。
二、4NF的例子
1. 初始表結構（違反 4NF）
假設我們有一個 Department（部門）表，存儲部門信息，包括部門名稱、部門經理和部門地點。
表：Department (DeptName, Manager, Location)
| DeptName | Manager | Location |
|---|---|---|
| IT | Alice | Building A |
| IT | Bob | Building A |
| IT | Alice | Building B |
| IT | Bob | Building B |
| HR | Charlie | Building C |
| HR | Charlie | Building D |
分析：
- 這個關系模式的關鍵屬性可能是
(DeptName, Manager, Location)的組合，但這顯然不是好的鍵。 - 更合理的候選鍵可能是
(DeptName, Manager)或(DeptName, Location)，但這兩個都不能唯一標識一個元組（例如，IT 部門有多個經理，有多個地點）。 - 實際上，
(DeptName)可能是唯一能標識部門相關信息的屬性。但是(DeptName)并不能唯一標識表中的每一行。 - 這里存在兩個獨立的多值依賴：
DeptName →→ Manager(一個部門有多個經理)DeptName →→ Location(一個部門有多個地點)
- 這些多值依賴是非平凡的（
Manager和Location都不是DeptName的子集，且R - (DeptName U Manager) = Location和R - (DeptName U Location) = Manager都不是空集）。 - 決定因素
DeptName不是一個超鍵（因為它不能唯一標識表中的每一行）。 - 因此，這個
Department表違反了 4NF。
問題： - 冗余： 每個經理-地點的組合都必須存在。例如，如果 IT 部門有 Alice 和 Bob 兩個經理，在 Building A 和 Building B 兩個地點，那么表里就必須有 4 行（Alice-A, Alice-B, Bob-A, Bob-B）。
- 插入異常： 如果想插入一個新的部門經理，但該部門尚未有地點信息，或者想插入一個新的部門地點，但該部門尚未有經理信息，都很難做到，因為
(DeptName, Manager, Location)需要同時有值。 - 刪除異常： 如果刪除了 IT 部門在 Building A 的記錄，可能會意外地刪除了 Bob 是 IT 部門經理的信息（如果 Alice 只在 Building B）。反之亦然。
2. 分解為滿足 4NF 的表
為了滿足 4NF，我們需要將違反 4NF 的關系模式分解，使得每個新的關系模式中不再存在非平凡的多值依賴，或者這些依賴的決定因素是超鍵。
將 Department 表分解為三個表：
- 主表 (可選，用于存儲部門基本信息，如果需要的話):
Departments(DeptName) - DeptName 是主鍵。
- 分解多值依賴
DeptName →→ Manager:DeptManagers(DeptName, Manager)- 主鍵：
(DeptName, Manager)(保證一個部門一個經理只出現一次) - 外鍵：
DeptName引用Departments(DeptName)
- 分解多值依賴
DeptName →→ Location:DeptLocations(DeptName, Location)- 主鍵：
(DeptName, Location)(保證一個部門一個地點只出現一次) - 外鍵：
DeptName引用Departments(DeptName)
分解后的表：
表：Departments (DeptName)
| DeptName |
|---|
| IT |
| HR |
表：DeptManagers (DeptName, Manager)
| DeptName | Manager |
|---|---|
| IT | Alice |
| IT | Bob |
| HR | Charlie |
表：DeptLocations (DeptName, Location)
| DeptName | Location |
|---|---|
| IT | Building A |
| IT | Building B |
| HR | Building C |
| HR | Building D |
驗證 4NF：
Departments表：DeptName是主鍵，也是唯一的超鍵。沒有非平凡的多值依賴。滿足 4NF。DeptManagers表：- 候選鍵：
(DeptName, Manager)，這也是唯一的超鍵。 - 檢查多值依賴：是否存在
X →→ Y？DeptName可以決定Manager，但這實際上是函數依賴DeptName → Manager（在給定的元組范圍內，一個 DeptName 對應一個唯一的 Manager 值，因為主鍵是(DeptName, Manager)）。函數依賴是函數依賴的特殊情況，不違反 4NF。- 沒有其他非平凡的多值依賴。
- 滿足 4NF。
- 候選鍵：
DeptLocations表：- 候選鍵：
(DeptName, Location)，這也是唯一的超鍵。 - 檢查多值依賴：類似
DeptManagers表，DeptName → Location是函數依賴。 - 沒有其他非平凡的多值依賴。
- 滿足 4NF。
優點：
- 候選鍵：
- 消除冗余： 現在，IT 部門的經理和地點信息存儲在單獨的表中，不再需要重復組合。
- 避免異常： 可以獨立地插入、刪除或更新經理信息或地點信息，而不會影響其他信息。例如，可以輕松添加一個新的 IT 部門經理，即使還沒有指定地點；可以刪除 IT 部門在 Building A 的信息，而不會刪除 Bob 作為 IT 部門經理的信息。
三、總結
- 4NF 目標： 消除由非平凡多值依賴引起的冗余和更新異常。
- 核心要求： 關系模式中所有非平凡的多值依賴的決定因素都必須是超鍵。
- 分解方法： 將具有非平凡多值依賴且決定因素不是超鍵的關系模式，分解為多個關系模式，每個模式只包含一個獨立的多值依賴。
- 適用場景： 當關系模式中存在多個獨立的多值屬性集合時，應考慮應用 4NF。
- 關系： 4NF 是比 BCNF 更強的規范化形式。如果關系滿足 4NF，則它一定也滿足 BCNF。
)
