Table of Contents

第八章關係數據庫設計

8.1 好的關係設計的特點

8.1.1 設計選擇：更大的模式

例如，使用inst_dept(ID, name, salary, dept_name, building, budget)來替代instructor和department。

這樣會存在以下問題：

信息冗餘，維護一致性比較困難
無法表示一部分信息和概念，例如：一個新的department，但是沒有教師。

8.1.2 設計選擇：更小的模式

函數依賴（function dependency）： dept_name --> budget

有損分解（lossy decomposition）

無損分解（lossless decomposition）

8.2 原子域和第一範式

一個域是原子的（atomic），如果該域的元素被認爲是不可分的單元。

第一範式（First Normal Form, 1NF）: 當一個關係模式R的所有屬性的域都是原子的，那麼這個關係模式滿足第一範式。

例如：名字的集合是非原子的；組合屬性如address也具有非原子域。

在許多含有複雜結構的實體域中，強制使用第一範式會給應用程序員造成不必要的負擔，他必須編碼將數據轉換成原子形式，轉換過程增加了額外的開銷。因此支持非原子性的值是非常必要的。

8.3 使用函數依賴進行分解

我們用r(R)表示關係r，其屬性集爲R。K代表關係r(R)的超碼。

8.3.1 碼和函數依賴

合法實例（legal instance）:滿足所有這些現實世界的約束的關係實例是一個合法實例。

函數依賴讓我們可以表達唯一標識某些屬性的值的約束。考慮一個關係某事r(R)，令α⊆R且或β⊆R，

給定r(R)的一個實例，這個實例滿足(satisfy)函數依賴α -> β的條件是：若實例中所以有元組對t1和t2，若t1[α]=t2[α]，則t1[β]=t2[β]
如果在r(R)的每個合法實例中都滿足函數依賴α -> β，則我們說該函數依賴在模式r(R)上成立(hold)。

我們將以兩種方式使用函數依賴：

判定關係的實例是否滿足給定函數依賴集F
說明合法關係集上的約束。因此，我們將只關心滿足給定函數依賴集的那些關係實例。如果只考慮模式R上滿足函數依賴集F的關係，則說F在r(R)上成立。

在所有關係中都滿足的函數依賴是平凡的(trivial)函數依賴。

函數依賴集F的閉包（closure）代表能夠從給定F集合中推導出的所有函數依賴的集合，表示爲F+。

8.3.2 Boyce-Codd範式（BCNF）

具有函數依賴集F的關係模式R屬於BCNF的條件是：對於F+中所有形如α -> β的函數依賴（其中α⊆R且或β⊆R），下面一條至少成立：

α -> β是平凡的函數依賴（即：β⊆α）
α是關係模式R的一個超碼

例如：department(dept_name, building, budget) 是滿足BCNF的，因爲多有成立的非平凡函數依賴，例如：

dept_name-> building, budget中，dept_name是department的一個超碼。

分解不屬於BCNF的模式的一般規則：

設R爲不屬於BCNF的一個模式，則存在至少一個非平凡的函數依賴α -> β，其中α不是R的超碼。我們在設計中用一下兩個模式取代R：

(α∪β)
(R-(β-α))

例如：在上面的inst_dept(ID, name, salary, dept_name, building, budget)中存在

ID->name, salary, dept_name

dept_name->building, budget

其中ID是inst_dept的主碼

此時α=dept_name, β={building, budget}，此時inst_dept可被取代爲：

(α∪β) = {dept_name, building, budget}
(R-(β-α)) = (ID, name, dept_name, salary)

在這個例子中 β-α = β

8.3.3 BCNF和保持依賴

每次數據庫更新時，檢查這些一致性約束的開銷都很大。

如果函數依賴的檢驗只需要考慮一個關係就可以完成，那麼檢查這種約束的開銷就很低。

BCNF的分解有時會妨礙對某些函數依賴的高效檢查。

例如：一個教師只能與一個系關聯，且一個學生可以有多個導師，但是一個給定的系中至多一位。

dept_advisor(s_ID, i_ID, dept_name)存在約束：

s_ID, dept_name -> i_ID

i_ID->dept_name

此時第二個約束不滿足BCNF，因爲i_ID不是超碼，根據BCNF分解規則，得到

(s_ID, i_ID)
(i_ID, dept_name)

上面的兩個模式都屬於BCNF，但是這兩個關係模式都無法包含函數依賴s_ID, dept_name -> i_ID中出現的所有屬性。

====> 稱這個設計不是保持依賴的(dependency preserving)。

8.3.4 第三範式

第三範式的要求比BCNF更寬鬆一些。

具有函數依賴集F的關係模式R屬於第三範式（third normal form）的條件是：對於F+中所有形如α -> β的函數依賴（其中α⊆R且或β⊆R），下面一條至少成立：

α -> β是平凡的函數依賴（即：β⊆α）
α是關係模式R的一個超碼
β-α中的每個屬性A都包含於R的一個候選碼中

注意：滿足BCNF的關係模式一定會滿足第三範式。

例如：8.3.3中的案例，dept_advisor(s_ID, i_ID, dept_name)存在約束：

s_ID, dept_name -> i_ID

i_ID->dept_name

此時dept_advisor是不滿足BCNF的，但是它是滿足3NF的。

這是因爲： dept_name - i_ID = dept_name 並且dept_name屬於主碼(s_ID, dept_name)的一部分，所以滿足3NF。

8.3.5 更高的範式

在某些情況下，使用函數依賴分解模式可能不足以避免不必要的信息重複，因此，定義了另外的依賴和範式。見8.6節和8.7節。

8.4 函數依賴理論

8.4.1 函數依賴集的閉包

邏輯蘊含(logically imply)：給定模式上的函數依賴集F，我們可以證明某些其他的函數依賴在該關係模式上也成立。我們稱這些函數依賴被F邏輯蘊含。

給定關係r(R), 如果r(R)上的每個滿足F的實例也滿足f，則R上的函數依賴f被r上的函數依賴集F所邏輯蘊含。
- 例如： F={A->B, B->C} 那麼 f=A->C被F邏輯蘊含

閉包（closure）：令F是一個函數依賴集，F的閉包是被F邏輯蘊含的所有函數依賴的集合，記作F+。

Armstrong公理（Armstrong's axiom）: 提供了尋找邏輯蘊含的三條規則

令(α, β, γ,...)表示屬性集，每個字母代表單個屬性；用αβ表示α∪β

自反律(reflexivity rule)：若α爲一屬性集，且β⊆α, 則α -> β成立
增補律(augmentation rule)：若α -> β成立且 γ爲一屬性集，則 αγ -> βγ
傳遞率(transitivity rule)：若α -> β，β -> γ成立，則α -> γ成立

爲了進一步簡化計算，另外還有一些規則。這些規則可以通過Armstrong公理證明。

合併律（union rule）:若α -> β，β -> γ成立，則αβ -> γ成立
分解律（decomposition）:若α -> βγ成立，則α -> β，α -> γ成立
僞傳遞律（pseudotransitivity rule）:若α -> β 和 βγ ->θ 成立，則 αγ -> θ成立

圖8-7形式化的給出了利用Armstrong公里計算F+的過程。

8.4.2 屬性集的閉包

如果α -> B，則稱屬性B被α函數確定(funcitonally determine)。

令α是一個屬性集，我們將函數依賴集F下被α函數所確定的所有屬性的集合稱爲F下α的閉包，記作α+。

計算屬性閉包的算法：

例如：計算R=(A, B,C,G,H,I), F={A->B, A->C, CG->H, CG->I, B->H}中(AG)+。開始時result = AG，repeat循環執行：

第一次repeat：

第二次repeat，無新的屬性加入result，循環結束

經證明，最壞的情況下，該算法執行時間爲F集合規模的二次方。

屬性閉包算法的多種用途：

判斷α是否爲超碼：可以計算α+，檢查α+是否包含R中所有的屬性
通過檢查是否β⊆α+，可以判斷函數依賴α->β是否成立。
該算法提供了我們另一種計算F+的方法：對於任意γ⊆R, 我們找出閉包γ+；對於任意的S⊆γ+,我們輸出一個函數依賴γ->S

8.4.3 正則覆蓋

如果去除函數依賴中的一個屬性不改變該函數依賴集的閉包，則稱該屬性是無關的(extroneous)。

無關屬性（extroneous attribute）的形式化定義：考慮函數依賴集F及F中的函數依賴α->β。

如果A∈α，並且F邏輯蘊含（F-{α->β}}）∪ {(α-A)->β}，則屬性A在α中無關的。
如果A∈β，並且（F-{α->β}}）∪ {α->(β-A)}邏輯蘊含F，則屬性A在β中無關的。

例如：F中有AB->C和A->C，那麼B在AB->C中是無關的；F中有AB->CD和A->C，那麼C在AB->CD中是無關的。

如何檢驗一個屬性是否無關？

令R爲一個關係模式，且F是R上的函數依賴集。考慮α->β的一個屬性A：

如果A∈β，爲了檢驗A是否是無關的，考慮集合

F' = （F-{α->β}}）∪ {α->(β-A)}s

並檢驗α->A是否能夠由F‘推出。爲此，計算F’下的α閉包；如果α+包括A，那麼A在β中是無關的。

如果A∈α，爲了檢驗A是否是無關的，令γ=α-{A}，並且檢查γ->β是否可以由F推出。爲此，計算F下的γ+；如果γ+包含β中的所有屬性，則A在α中是無關的。

F的正則覆蓋（canonical cover）是Fc是一個依賴集，F邏輯覆蓋Fc中的所有依賴，並且Fc也邏輯蘊含F中的所有依賴。此外，Fc必須具有以下性質：

Fc中任何函數依賴都不含無關屬性
Fc中函數依賴的左半部分都是唯一的。即：Fc中不存在兩個依賴α1->β1，α2->β2滿足α1=α2。

注意：在圖8-9中，如果一個依賴的右半部分只包含一個屬性，如：A->C，並且這個屬性是無關的。那麼我們將得到一個右半部分爲空的函數依賴，這樣的函數依賴應該被刪除。

注意：正則覆蓋Fc和F具有相同的閉包！Fc是最小的——它不含無關屬性，並且合併了具有相同左半部分的函數依賴。

例如：R=(A, B,C)上有函數依賴F={A->BC, A->B, B->C, AB->C}

合併具有相同左半部分的依賴 A->BC， A->B===> A->BC
對於AB->C，其中A是無關的，因爲F邏輯蘊含 {F-(AB->C)} ∪ (B->C)成立，所以==> B->C
C在A->BC中是無關的，因爲A->BC，被A->B和B->C覆蓋

===> {A->B, B->C}

注意：正則覆蓋未必是唯一的！

8.4.4 無損分解

令r(R)是一個關係模式，F爲r(R)上的函數依賴集。令R1和R2爲R的分解。如果用兩個關係模式r(R1)和r(R2)替代r(R)時沒有信息損失，則我們稱該分解是無損分解（lossless decomposition）。

無損分解滿足：

不是無損分解的分解爲有損分解(lossy decomposition).

用函數依賴描述無損分解：

令R1，R2，R和F如上。如果一下函數依賴至少有一個屬於F+，那麼R1和R2是R的無損分解：

R1∩R2 -> R1
R1∩R2 -> R2

即：R1∩R2是R1或者R2的超碼，那麼它們是R上的無損分解。

例如：inst_dept(ID, name, dept_name, salary, building budget)

==>instructor(ID, dept_name, name, salary), department(dept_name, building, budget)是無損分解

8.4.5 保持依賴

令F爲R上的一個函數依賴集，R1，R2，...,Rn爲R的一個分解。F在R上的限定（restriction）是F+中所有隻包含Ri中屬性的函數依賴的集合Fi。

例如：F={A->B, B->C}，計算F在AC上的限定={A->C}

保持依賴的分解(dependency-preserving decomposition)：

令F‘=F1∪F2∪...∪Fn，Fi爲Ri對應的限定，如果F'+ = F+，那麼我們稱這是一個保持依賴的分解。

下面的算法可以用來驗證保持依賴性，但是代價很大（指數時間）。

另外兩種驗證保持依賴的方法：

方法1：一個保持依賴的充分條件：
- 如果F中的每一個函數依賴都可以在分解得到的某一個關係上驗證，那麼這個分解是保持依賴的。
- 但是，F中也可能存在一個依賴，它無法在分解後的任意一個關係上驗證。
方法2：該驗證方法對F中的每一個α->β使用下面的過程：（多項式時間）

這裏的屬性閉包是函數依賴集F下的。如果result包含β中的所有屬性，則函數依賴α->β保持。

一個分解是保持依賴的 <=充要條件=>當且僅當F中的所有依賴都保持上述過程

該方法的思想：

驗證F中每一個函數依賴α->β，看它是否在F’中保持。爲此，我們計算F'下的α閉包，當該閉包包含β時，該依賴得以保持。該分解是保持依賴的 ==當且僅當===F中的所有函數依賴都保持
使用修改後的屬性閉包算法計算F'下的閉包。該方法避免了計算F‘的閉包，減少了計算量。因爲F’是Fi的並集，而Fi是F在Ri上的限定。該算法計算出F上的屬性閉包，並與R相交，然後將結果屬性集加入result，這一系列步驟等價於計算Fi下的result閉包。repeat for Ri得到F‘下的result閉包。

8.5 分解算法

8.5.1 BCNF分解

8.5.1.1 BCNF的判定方法

判定方法一：在某些情況下，判定一個關係是否滿足BCNF做如下簡化：
- 爲了檢查非平凡的函數依賴α->β是否違反BCNF，計算α+，並驗證它是否包含R中的所有屬性，即：驗證α是R的超碼
- 檢查關係模式R是否屬於BCNF，僅需檢查給定集合F中的函數依賴是否違反BCNF就可以了，不用檢查F+中的所有函數依賴。

但是，當一個關係分解後，後一步過程就不再適用。

判定方法二：爲了檢查分解後的關係Ri是否屬於BCNF，可以進行如下判定
- 對於Ri中屬性的每個子集α，確保α+要麼不包含Ri-α的任何屬性，要麼包含Ri的所有屬性。

如果Ri存在某個屬性集α違反BCNF，則α->(α+ - α) ∩ R出現在F+中。

8.5.1.2 BCNF分解算法

下面給出了BCNF分解算法，用這個算法得到的BCNF分解，還是一個無損分解。

驗證：用(Ri-β)和（α，β）取代Ri時，依賴α->β成立，並且(Ri-β) ∩（α，β）=α

這個算法所需時間爲指數級別，因爲算法中檢查一個Ri是否屬於BCNF的代價是指數級別。

舉例： class(course_id, title, dept_name, credits, sec_id, semester, year, building, room_number, capacity, time_slot_id ) 存在

course_id -> title, dept_name, credits

building, room_number -> capacity

course_id, sec_id, semester, year -> building, room_number, time_slot_id

則，計算BCNF分解：

函數依賴course_id -> title, dept_name, credits成立，但是course_id不是超碼，所以class可被分解爲
- course(course_id, title, dept_name, credits) - 屬於BCNF
- class-1(course_id, sec_id, semester, year, building, room_number, capacity, time_slot_id)
函數依賴building, room_number -> capacity，building和room_number不是class-1的候選碼，所以class-1可被分解爲：
- classroom(building, room_number, capacity) - 屬於BCNF
- section(course_id, sec_id, semester, year, building, room_number, time_slot_id) - 屬於BCNF

於是==> 分解得到course，classroom，section，它們都屬於BCNF。

8.5.2 3NF分解

圖8-12給出了將模式轉爲3NF的保持依賴且無損的算法。其中Fc是F的正則覆蓋。

運算時間爲多項式時間，

例如：dept_advisor(s_ID, i_ID, dept_name), 其函數依賴集爲s_ID, dept_name->i_ID, i_ID -> dept_name

在執行下述算法的過程中，

得到R1(i_ID, dept_name), R2(s_ID, i_ID, dept_name)，
由於R2包含R的候選碼，所以不再繼續創建關係模式
由於R1包含在R2中，所以刪除R1

可以看出，這個算法會刪除被其他關係模式所包含的模式。

有時3NF算法的結果不僅是3NF，也是BCNF。說明該算法可以作爲另一種求解BCNF的算法。

首先使用3NF計算出分解
然後對於分解中任何不屬於BCNF 的模式，用BCNF進行分解。如果結果不是保持依賴的，則還原到3NF。

8.5.3 3NF算法的正確性

3NF如何保證無損分解？

3NF通過保留至少有一個模式包含被分解模式的候選碼，確保該分解是一個無損分解。

3NF的結果不是唯一確定的，因爲Fc不是唯一的。並且某些情況下，算法的結果還與Fc中函數依賴的順序有關。

8.5.4 BCNF和3NF的比較

3NF的優缺點：

優點：總是可以再滿足無損並保持依賴的前提下得到3NF
缺點：可能不得不用空值來表示數據項間的某種可能有意義的聯繫，並且存在信息重複的問題。

使用函數依賴進行數據庫設計的目標是：

BCNF
無損
保持依賴

由於不是總能達到BCNF，所以需要在BCNF和3NF中做個權衡和選擇。

通常來講，再不能得到保持依賴的BCNF時，我們傾向於使用3NF。因爲SQL檢查非主碼約束的函數依賴很困難。

目前沒有數據庫支持強制實施函數依賴的所需的複雜斷言
可以再分解不能保持依賴時，使用物化視圖上的主碼約束對其進行檢查，以降低開銷
- 若一個非保持依賴的BCNF分解，存在α->β，利用物化視圖存儲αβ，並令其主碼爲α。進而可以在物化視圖上維護該函數依賴。
- 缺點：會有時間和空間的額外開銷；目前大多數數據庫系統不支持物化視圖上的約束
- 優點：程序員不需要額外的工作來維護冗餘數據上的一致性

8.6 使用多值依賴的分解

有些關係模式雖然是BCNF，但從某種意義上也存在信息重複的問題。例如：多值屬性。

多值依賴、第四範式（Fourth Normal Form）。

引用第四範式處理多值依賴，它比BCNF的約束更嚴格。

屬於4NF的一定屬於BCNF ，屬於BCNF的不一定是4NF。

8.6.1 多值依賴

函數依賴A->B成立，那麼不能有兩個元組在A上的值相同，B上的值不同。多值依賴允許這種情況發生。

因此，函數依賴有時也稱爲相等產生依賴（equality-generating dependency），而多值依賴也稱爲元組產生依賴（tuple-generating dependency）。

多值依賴multivalued dependency：

令r(R)爲一個關係模式，並令α⊆R且β⊆R，那麼多值依賴可表示爲：α ->-> β。

多值依賴在R上成立的條件是：在關係r(R)上的任意合法實例中，對於r中任意一對滿足t1[α]=t2[α]的元組t1和t2，r中都存在元組t3和t4，使得：

與函數依賴相同，將以兩種方式使用多值依賴：

1，檢查關係以確定它們在給定的函數依賴集和多值依賴集下是否合法

2. 在合法關係集上指定約束，我們希望只考慮滿足給定函數依賴和多值依賴的集合

令D表示多值依賴和函數依賴的集合。D的閉包D+是由D邏輯蘊含的所有函數依賴和多值依賴的集合。

根據多值依賴的定義，可以利用如下規則推導依賴集，對於α⊆R，β⊆R：

若α->β，則α->->β。每個函數依賴也是一個多值依賴
若α->->β，則α->->R-α-β

8.6.2 第四範式

8.6.3 4NF分解

8.7 更多的範式

投影-連接範式（Project-Join Normal Form， PJNF，第五範式）：

連接依賴join dependency：更一般的概化了多值依賴

域-碼範式（Domain-key Normal Form， DKNF）：處理更一般化的額約束

其缺點是：難易推導，且沒有完備和有效的推導規則，使用很少。

8.8 數據庫設計過程

本節介紹規範化是如何融合在整體數據庫設計過程中的。

8.3節至今，講述瞭如何對給定關係模式r(R)進行規範化。

我們可以採用以下幾種方式得到模式r(R):

E-R圖生成
利用規範化將r(R)分解爲更小的模式
r(R)是一個即席設計的結果，然後檢驗其是否滿足一個期望的範式

8.8.1 E-R模型和規範化

函數依賴有助於我們檢測到不好的E-R設計。

規範化可以留給數據庫設計者在E-R建模時靠直覺實現，也可以從E-R模型生成的關係模式上規範的進行，二者可以任選其一。

創建E-R設計的過程傾向於產生4NF設計。

如果一個多值依賴成立且不是被相應的函數依賴所隱含的，那麼它通常由以下情況引起：

一個多對多的聯繫集
實體集的一個多值屬性

對於多對多的聯繫集，每個相關的實體集都有自己的模式，並且存在一個額外的模式用於表示聯繫集。

對於多值屬性，會創建一個單獨的模式，包含該屬性以及實體集的主碼。

8.8.2 屬性和聯繫的命名

隨着模式變得變得更大，聯繫集的數量的不斷增加，對屬性、聯繫和實體一致的命名方式會使得數據庫管理者更加輕鬆。常用的規則包括：

數據庫設計的一個期望特性是唯一角色假設（unique-role assumption）: 即：每個屬性名在數據庫中只有唯一的含義。這使得我們不能在不同的模式中使用同一個屬性來表示不同的東西。
如果不同關係中的屬性有相同的含義，則可以使用相同的名字進行表示。
模式中的屬性的順序無關緊要，然而管把主碼放在前面
聯繫集常常以相關試題集名稱的拼接來命名，可能使用連字符或下劃線連接，例如：inst_sec。
實體集的命名通常採用單數，但不絕對，只要系統中保持一致就好。

8.8.3 爲了性能去規範化

有時候爲了提高性能，數據庫設計者會選擇包含冗餘信息的模式，即沒有規範化。其代價是需要一些額外的工作來保持冗餘數據的一致性。

例如：查詢課程的所有先修課程，需要連接course和prereq

一個不計算連接的方法是保存一個包含course和prereq的所有屬性的關係==> 查詢更快，但是具有冗餘信息，維護起來更復雜。

去規範化（denormalization）：把一個規範化的模式變成非規範化的操作。

另外一種方法是，使用規範化的模式，但是將course和prereq的連接作爲物化視圖存儲==> 會帶來一些時間和空間上的開銷，但是數據庫可以自行維護更新。

8.8.4 其他設計問題

數據庫設計中有一些方面不能用規範化描述，可能會導致不好的數據庫設計。例如與時間段有關的數據就容易存在這樣的問題。

例如：存儲不同年份中每個系的教師總數

設計1：total_inst(dept_name, year, size)，爲的函數依賴時dept_name, year->size，屬於BCNF
設計2：建立total_inst_2007, total_inst_2008,....，==>雖然這些也屬於BCNF，但是這樣關係太多，查詢起來比較費勁
設計3：建立單獨的dept_year(dept_name, total_inst_2007, total_inst_2008, total_inst_2009...) ==> 關係需要經常變化，查詢起來會比較費勁

像設計3這種的表示方法，屬性的每一個值一列，叫做交叉表（crosstab）。雖然它很有用，但是在數據庫的設計中並不可取。

8.9 時態數據模型

時態數據（temporal data）是具有關聯的時間段的數據，在時間段之間有效（valid）。

數據的快照（snapshot）表示一個特定的時間點上該數據的值。

時態函數依賴(temporal functional dependency)：在某個特定時間點上成立的函數依賴稱爲時態函數依賴。形式化的說：下圖的公式在關係模式r(R)上成立的條件是，對於r(R)的所有合法實例，r的所有快照都滿足函數依賴X->Y.

時態數據庫的設計方法：

方法1：把起始時間和終止時間作爲每個這樣的關係添加有效時間信息。
- 例如：course(course_id, title, dept_name, start, end)
- 如果另一個關係有一個參照時態關係的外碼，數據庫設計者必須決定參照是否針對當前版本的數據還是一個特定時間點的數據。在後一種情況下，參照關係必須也記錄時間信息。

一個時態關係中的原始主碼無法再唯一的表示一條元組。爲了解決這個問題，我們可以在主碼中添加起始和終止時間。但是也存在一些問題：

有可能存在存儲時間段存在重合的數據，該問題主碼約束無法捕獲。如果系統能夠支持自帶的有效時間類型，它就能檢測和避免這種重疊的時間段
爲了指明這種參照關係的外碼，參照元組必須包含起始和終止時間屬性爲它們的外碼的一部分，其值也必須與被參照元組相匹配。同時，更新也必須得到傳遞。

方法2：如果所有對時態數據的參照都僅僅指向當前數據，更簡單的方法是不在關係中添加時間信息，而爲過去的值創建一個history關係，history中可以包含start_time和end_time。

總結

本章給出了數據庫設計中易犯的錯誤，和怎樣系統的設計數據庫模式以避免這樣的錯誤。這些錯誤包括：信息重複和不能表示某些信息
我們給出了從E-R設計到關係數據庫設計的發展過程，什麼時候可以安全的合併模式，什麼時候應該分解模式。所有有效的分解都必須是無損的。
原子域和第一範式
函數依賴，BCNF，3NF
如果分解是保持依賴的，則給定一個數據庫更新，所有的函數依賴都可以由單個的關係進行驗證，而無需計算分解後的關係的連接。
我們展示瞭如何用函數依賴進行推導。我們着重講了什麼依賴是一個依賴集邏輯蘊含的。我們還定義了正則覆蓋的概念，它是與給定函數依賴集等價的最小的函數依賴集。
我們概述了一個將關係分解爲BCNF的算法；有一些關係不存在保持依賴的 BCNF分解
我們用正則覆蓋分解成3NF，它比BCNF的條件更弱一些。屬於3NF的關係也許會有冗餘，但是總存在保持依賴的 3NF分解
我們介紹了多值依賴的概念，它指明僅用函數依賴無法指明的約束。我們用多值依賴定義了第四範式（4NF）。
其他的範式，如PJNF和DKNF，消除了更多更細微的冗餘。但是其操作困難且很少使用
我們之所以可以對關係數據庫設計你定義嚴格的方法，是因爲關係數據庫模型建立在嚴謹的數學基礎上，這是關係模型相對於其他數據模型的主要優勢之一。

《數據庫系統概念》學習筆記——第八章 關係數據庫設計

第八章 關係數據庫設計