範式篇 - BCNF、3NF和4NF

Boyce - Codd範式

具有函數依賴集合F的關係模式R屬於BCNF的條件是，當且僅當對F⁺中所有函數依賴α → β（其中，α包含於β，且β包含於R），下列至少有一項成立：

• α → β是平凡的函數依賴（即，β包含於α）
• α是R的超碼（即，R包含於α⁺，α → R）

回顧：公共部分是否已子關係的鍵 → 無損連接分解

檢查是否爲BCNF

爲檢查非平凡依賴α →β 是違反BCNF的要求

• 計算α⁺
• 檢驗α⁺是否包含R的所有屬性（即，是否爲R的超碼）

簡化的測試：爲檢查具有函數依賴集合F的關係模式R是否屬於BCNF，只需檢查F中的函數依賴是否違反BCNF即可，而不需要檢查F⁺中的所有函數依賴

• 可以證明如果F中沒有違反BCNF的依賴，則F⁺中也沒有違反BCNF的依賴
  —因爲F⁺是由Armstrong的3個公理從F推出的而任何公理都會使函數依賴的左邊變小（拆分），故若果F中沒有違反BCNF的函數依賴（即，左邊是超碼），則F⁺中也不會。

但是，當檢查R的分解後的關係時僅用F是錯誤的。

BCNF 分解算法

BCNF分解示例

BCNF與保持依賴

BCNF分解不總是保持依賴的

因此，我們並不總能滿足這三個設計目標：

• 無損連接
• BCNF
• 保持依賴

第三範式（3NF）- 動機

存在這樣的情況

• BCNF不保持依賴
• 但是，有效檢查更新是違反函數依賴是重要的

解決方法：定義一種較弱的範式，稱爲第三範式（3NF）

• 允許出現一些冗餘（從而會帶來一些問題）
• 但函數依賴可以在當個關係中檢查，不必計算鏈接
• 總是存在到3NF的無損連接分解，且是保持依賴的

定義： 關係模式R屬於第三範式（3NF）當且僅當對所有F⁺中的函數依賴α → β使得下列條件中至少一個成立：

• α → β是平凡的函數依賴（即，β∈α）
• α是β的超碼
• β - α中的每個屬性A都包含於R的一個候選碼中（即A∈β - α 是主屬性，若α ∩ β = ∅，則A = β是主屬性）

注：各屬性可能包含在不同的候選碼中。

推論：

• 若一個關係屬於BCNF則一定屬於3NF；
• 第三範式相對於BCNF來說放款了約束，允許非平凡函數依賴的左邊不是超碼。因爲候選碼是最小的超碼，他在任何一個真子集都不是超碼；
• 第三個條件是對BCNF條件的最小放寬，以確保每一個模式都有保持依賴的3NF分解。

BCNF 與 3NF的比較

總是可以將一個關係分解到3NF並且滿足

• 分解是無損的
• 保持依賴

總是可以將一個關係分解到BCNF並且滿足

• 分解是無損的
• 但可能不保持依賴

檢查是否爲3NF

優化：只需要檢查F中的函數依賴，而不必檢查F⁺中所有的函數依賴；
對於每一個依賴α→β，利用屬性閉包來檢查α是否爲超碼；
若果α不是超碼，必須檢查β中的每個屬性是否包含在R的某個候選碼中

• 這個檢查較昂貴，因爲它涉及求候選碼
• 檢查是否屬於3NF是NP-hard的
• 有趣的是，分解到第三範式可以在多項式時間內完成

3NF分解算法

3NF示例

練習

視頻講解

設計目標

關係數據庫設計目的是：

• BCNF
• 無損連接
• 依賴保持

如果不能達到這些，也可以接受：

• 缺少保持依賴
• 因3NF引起的冗餘

除了超碼之外，SQL並沒有提供直接聲明函數依賴的方法。可以通過斷言聲明函數依賴，但是檢測代價太大；

因此即使我們有一個保持依賴的分解，使用SQL，我們也不能有效的檢測左部不是碼的函數依賴。

多值依賴

有時屬於BCNF的模式任然未充分規範化

考慮數據庫

classes（course，teacher，book）

定義（c，t，b）∈ classes，分別代表課程c由教師t來教，需要用到該課程的教材b。

數據庫將爲每門課程列出能講授該科的教師的集合，以及需要用的教材的集合（不管誰講授該課程）。

• course：teacher = 1：n，course：book = 1：n
• teacher和book是多值屬性，並且teacher和book相互獨立

由於沒有非平凡依賴，（course，teacher，book）是唯一的鍵，因此該關係模式屬於BCNF。

冗餘與插入異常：如果Sara是能教數據庫的新教師，必須插入兩條元組教材不同

• （database，Sara，DB Concepts）
• （database，Sara，UIIman）

多值依賴定義

在前面的例子中：

• course →→ teacher
• course →→ book

上述形式定義表達了這種概念：

• 給定Y（course）的特定值，則有一個Z（teacher）值的集合和一個W（book）值的集合與之相關聯，而這兩個集合在某種意義上是相互獨立的。

多值依賴理論

根據多值依賴定義，課導出下列規則：

• 若α → β，則α →→ β，即函數依賴是多值依賴的特例

D的閉包D⁺是D邏輯蘊含的所有函數依賴和多值依賴的集合

• 可根據函數依賴與多值依賴的形式定義來從D計算D⁺
• 我們只對在實踐中較常見的簡單多值依賴可用這樣的推理
• 對於複雜的依賴，最好利用一套推理規則來對依賴集合進行推理

第四範式（4NF）

關係模式R關於函數依賴及多值依賴集合D屬於4NF當且僅當對D⁺中所有形如α →→ β的多值依賴，其中α包含於R且β包含於R，下列條件中至少一個成立：

• α →→ β是平凡的（即，β包含於α 或 α ∪ β = R）
• α是模式R的超碼

若關係屬於4NF，則它必屬於BCNF

更多的範式

鏈接依賴概化了多值依賴

• 並引出了另一種範式投影 - 鏈接範式（PJNF）

還有一類更一般化的約束，它引出一種稱作域 - 碼範式（domain - key normal form）

使用這些一般化的約束的一個實際問題是，他們不僅難以推導，而且也還沒有形成一套具有正確有效性和完備性的推理規則用於約束的推導，因此，很少使用。

數據庫設計過程

假設給定了模式R

• R可能是經轉換E-R圖到表而生成的
• R可能是單個包含所有屬性的關係（稱爲全關係）
• 規範化將R分解成較小的關係
• R可能是某種特定設計的結果，然而再測試/轉換成範式

E- R模型和規範化

當我們小心地定義當E - R圖，並正確地標識所有實體，則從E - R圖生成的關係模式就不需要太多進一步的規範化；
但是，在現實（不完善的）設計中可能存在從實體的非碼屬性到其他屬性的函數依賴

• 例如：employee實體具有屬性department_name和building，以及函數依賴department_name → building
• 好的設計應該將department作爲實體

從聯繫集的非碼屬性引出函數依賴是可能的，但極少一一多數聯繫是二元的

爲了性能去規範化

當我們小心地定義當E - R圖，並正確地標識所有實體，則從E - R圖生成的關係模式就不需要太多進一步的規範化；
爲了提高性能可能使用非規範化的模式。

例如：假定每次訪問一門課程時，所有先修課都必須和課程信息一起顯示，需將course和preq鏈接。
做法1：使用包括course以及preq的所有上述屬性的反規範化關係

• 查找迅速
• 額外空間以及額外更新執行時間
• 程序員的額外編碼工作以及更多出錯可能性

做法2：如下定義的物化視圖

其他設計問題

有些數據庫設計問題不能被規範解決

總結

• 我們概述了一個將關係分解成BCNF的算法，有一些關係不存在保持依賴的BCNF分解；
• 用正則覆蓋將關係分解成3NF，它比BCNF的條件弱一些。屬於3NF的關係也會含有冗餘，但是總存在保持依賴的3NF分解；
• 介紹了多值依賴的概念，它指明僅用函數依賴無法指明的約束；
• 用多值依賴定義了4NF；
• 其他的範式，如PJNF和DKNF，消除了更多細微形式的冗餘。但是，他們難以操作而且很少使用；
• 數據庫設計過程中，要考慮的規範化問題。