通過E-R圖轉換得出一組關系模式后
**選擇1：**把一些關系模式合并為更大的關系 —— 會產生過多的數據冗余

inst_dept(ID, name, salary, dept_name, building, budget)

如果通過E-R模型轉換得出如下兩個關系模式

sec_class(sec_id, building, room_number) and section(course_id, sec_id, semester, year)

那么在邏輯設計中，可以將上述兩個關系合并為如下關系

section(course_id, sec_id, semester, year, building, room_number)

上述關系模式不會產生數據冗余

設計選擇2：更小的模式？
如果通過E-R模型轉換得出inst_dept關系模式，那么在邏輯設計中，我們可以將其分解為兩個關系模式

instructor(ID, name, salary, dept_name) department(dept_name, building, budget) # 從而避免(building, budget)的數據冗余

如何知道該合并或分解關系模式呢?

可以通過保持如下一條規則：dept_name確定(building, budget)數據，即保持函數依賴：dept_name → building, budget

由于dept_name在inst_dept關系中不是主碼，因此需要將其拆分為更小的關系模式

并不是所有的關系模式拆分是有益的
將employee(ID, name, street, city, salary)分解為

employee_attr1(ID, name) employee_attr2(name, street, city, salary)

name無法作為employee_attr2關系的主碼，有可能會重名
無法通過分解出的employee_attr1和employee_attr2重建（自然連接）得出原始關系
我們稱無法通過自然連接重建原始關系元組的分解為有損分解 (lossy decomposition)

無損分解

$R=(A,B,C)$的分解
$R1=(A,B)R2=(B,C)$

KaTeX parse error: Undefined control sequence: \join at position 18: …= \Pi_{A,B}(r) \?j?o?i?n? ?\Pi_{B,C)(r)和$R(A,B,C)$等價

函數依賴

假設$r(R)$是一個關系模式,$\alpha ?R$, $\beta ?R$, 模式R上的函數依賴
$$\alpha \to \beta$$

成立的條件是：如果對于任意關系實例r中任意兩個元組t1 和t2，如果兩者的屬性(集)$\alpha$取值相同, 那么它們的屬性(集)$\beta$取值也相同。也就是
$$t1[\alpha ]=t2[\alpha ]?t1[\beta ]=t2[\beta ]$$

稱之為$\alpha$函數確定$\beta$, $\beta$函數依賴于$\alpha$

假設r(A,B) 有如下關系實例

1 4 1 5 3 7

$A\to B$不成立，反之成立

函數依賴和碼

? 超碼：在某關系中，若一個或多個屬性的集合$\{A_1,A_2,\dots ,A_n\}$函數決定該關系中的其它全部屬性，則稱該屬性為該關系的超碼
?若屬性組K滿足K → R，則K 是關系模式R的超碼

? 候選碼：若集合$\{A_1,A_2,\dots ,A_n\}$的任何真子集均不能函數決定該關系中的其它屬性，則此時$\{A_1,A_2,\dots ,A_n\}$是最小的超碼，即候選碼
? K → R 且不存在$\alpha ?K$, 滿足 $\alpha \to R$

? 外碼：若關系模式R中屬性或屬性組X是另一關系模式的主碼，則稱X是R的外碼

S（Sno，Sname，Sdept，Sage） SC（Sno，Cno，G）

函數依賴允許我們表達超碼不能表達的約束。考慮下面的模式：
$$ins{t}_{d}ept(\underline{ID},name,salary,dept\_name,building,budget).$$

超碼函數依賴：
ID → name, salary, dept_name, building, budget

函數依賴在關系實例和關系模式上的體現區別：

如果關系實例r在函數依賴集F上合法，則稱r滿足F

如果模式R上的所有合法關系實例都滿足函數依賴集F，我們說F在關系模式R上成立

notice：即使函數依賴并沒有對關系模式r?的所有合法實例成立，這個關系模式的其中一個具體實例r可能滿足函數依賴

相關術語

有些函數依賴被稱為平凡(trivial)的，因為它們在所有關系中都是滿足的
? name → name
? ID, name → ID

如果$\beta ?\alpha$, $\alpha \to \beta$是平凡的函數依賴
$\beta ?\alpha$, $\alpha \to \beta$則這個是非平凡的函數依賴
$\alpha \to \beta$ 則$\alpha$是決定因素

函數依賴$\alpha \to \beta$ 稱為部分依賴的條件是：存在$\alpha$的真子集γ，
使得$\gamma \to \beta$

閉包

從給定函數依賴集F能夠推導出的所有函數依賴的集合，我們稱之為F集合的閉包
$$A\to B,B\to C$$
推出$A\to C$
我們用$F^{+}$來表示函數依賴集F的閉包,是F的超集

給定關系模式r( R )，如果r( R ) 的每個滿足F的 實例也滿足某個函數依賴ｆ，則R上的函數依賴ｆ邏輯蘊含（logically imply）于ｒ上的函數依賴集F

已知關系R上的函數依賴集T、F，如果對于該關系中滿足F的每一個關系實例都滿足T，稱函數依賴集F 邏輯蘊含 函數依賴集T

若F蘊含于T，且T蘊含于F，則函數依賴集T和F是等價的，記為T≡F

推理規則

Armstrong公理:

如果$\beta ?\alpha$, , 則有 $\alpha \to \beta$ (自反律)

如果 $\alpha \to \beta$, 則有 $\gamma \alpha \to \gamma \beta$ (增補律)

如果 $\alpha \to \beta$及$\beta \to \gamma$, 則有 $\alpha \to \gamma$ (傳遞律)

有效的：它們不會產生錯誤的函數依賴
完備的：對一個給定函數依賴集F，它們能產生整個F+

函數依賴證明(A → H)：
已知A → B，根據函數依賴定義，可得：

對于任意元組t1, t2，如果t1[A] = t2[A]，那么 t1[B]=t2[B] 已知B → H，同理可得：如果t1[B] = t2[B]，那么 t1[H]=t2[H] 綜上可得：如果t1[A] = t2[A]，那么t1[H] = t2[H]，即A → H得證

計算函數依賴集F的閉包算法:

repeatfor each F +中的函數依賴 f在f上應用自反律和增補律將結果加入到F +中for each F +中一對函數依賴f1和 f2if f1 和 f2 可以使用傳遞律結合起來將結果加入到F +中 until F + 不再發生變化

附加定理:
若有 $\alpha \to \beta$ 及$\alpha \to \gamma$, 則有 $\alpha \to \gamma \beta$ (合并律)
若有 $\alpha \to \gamma \beta$, 則有$\alpha \to \beta$ 及 $\alpha \to \gamma$ (分解律)
若有 $\alpha \to \beta$及$\beta \gamma \to \delta$, 則有 $\alpha \gamma \to \delta$ (偽傳遞律)

給定屬性集$\alpha$, 我們稱在函數依賴集F下由$\alpha$函數確定的所有屬性集合為F下$\alpha$的閉包，記為${\alpha }^{+}$

算法

result := α; while (result發生變化) dofor each 函數依賴 β → γ in F dobeginif β ? result then result := result ∪ γend

閉包用途

屬性閉包算法有多個用途：

超碼的判斷：

• 判斷α 是不是超碼，通過計算α+，看α+ 是否包含R中的所有屬性

驗證函數依賴：

• 要檢驗函數依賴α → β是否成立 (換句話說，是否在F +中), 只需要檢驗是否β ? α+
• 也就是說，我們用屬性閉包計算α+ ，看它是否包含β
• 是一個簡單快速的驗證方法，但是很有用

計算F的閉包：

• 對任意的γ ? R, 我們找出閉包γ+；對任意的S ? γ+, 我們輸出一個函數依賴γ → S

規范化（Normalization）

一個數據庫的描述對象包括：學生（Sno），系（Sdept）、系負責人（Name）、課程（Cname）和成績（G）

U ={Sno, Sdept, Name, Cname, G} FD ={ Sno->Sdept,Sdept->Name,(Sno,Cname)->G }建立關系模式：S(Sno, Sdept, Name, Cname, G)

存在問題：
? 數據冗余
? 需要用空值來表示某些信息

可以將S分解為三個關系模式：

S(Sno, Sdept)SG(Sno, Cname, G)Dept(Sdept, Name)

假設R是關系模式，具有函數依賴集F
在關系模式不是“好”的模式的情況下，將其分解成
關系模式集 $\{A_1,A_2,\dots ,A_n\}$

每個關系模式都是好的模式：無數據冗余（符合一定范式，例如BCNF）

分解是無損連接分解

最好的是，分解是保持依賴的（p225）

各種范式之間包含關系如下
$1NF?2NF?3NF?BCNF?4NF?5NF$
某一關系模式R最高屬于第n范式，可簡記為R∈nNF

第一范式

如果某個域的元素被認為是不可分的單元，那么這個域就是原子的

?非原子域的例子： ? 復合屬性（E-R模型） ? 類似于CS101的ID（只要數據庫應用沒有將CS標識號拆開并解析為系的縮寫，那么可認為是原子的）

如果一個關系模式R的所有屬性域都是原子的，我們稱關系模式R屬于第一范式
非原子的值會造成復雜存儲及數據冗余

第二范式

例: 關系模式 SLC(S#, SD, SL, C#, G)
SL為學生住處，假設每個系的學生住在同一個地方
SD為學生所在系，假設每個學生屬于一個系

若存在如下函數依賴
$$\{(S\#,C\#)\stackrel{f}{\to }G;(S\#,C\#)\stackrel{P}{\to }SD;SD\to SL;(S\#,C\#)\stackrel{P}{\to }SL\}$$

SLC (S#, SD, SL, C#, G)分解為
兩個關系模式:
$$SC（\underline{S\#},\underline{C\#},G）SL（\underline{S\#},SD,SL）$$

2NF的定義
若關系模式R∈1NF，且在F+中每一個非主屬性完全函數依賴于候選碼，則R∈2NF

Boyce-Codd范式 BCNF

具有函數依賴集F的關系模式R屬于BCNF的條件是：對所有F+中形如$\alpha \to \beta$的函數依賴（ $\beta ?R$且$\alpha ?R$ ），下面至少有一個成立：

$\alpha \to \beta$是平凡函數依賴

$\alpha$是模式R的一個超碼

不屬于BCNF的模式的例子:

$$inst\_dept(\underline{ID},name,salary,dept\_name,building,budget)$$
因為 dept_name → building, budget 在inst_dept上成立，但是 dept_name 不是超碼

另一個判定標準：
另一個判定準則：在關系模式R（U, F）中，如果F+中的每一個非平凡 函數依賴的 決定屬性集都包含候選碼（即為超碼），則
$$r(R)\in BCNF$$

BCNF范式：排除了任何屬性（包括主屬性和非主屬性）對候選碼的部分依賴和傳遞依賴，也排除了主屬性之間的傳遞依賴

例子

r( R)=r(A,B,C), F={ A->B,B->C }.
r( R)的候選碼為A
$$r(R)\in /BCNF$$

r( R)=r(A,B,C),F={ AB->C,C->A }.
r( R)的候選碼為AB和BC
$$r(R)\in /BCNF$$

r( R)=r(A,B,C),F={ AB->C,BC->A }.
r( R)的候選碼為AB和BC
$$r(R)\in BCNF$$

假設有模式R，及其一個非平凡依賴$\alpha \to \beta$ 不屬于BCNF，那么我們可以將R分解成：
$$(a\cup \beta )和(R?(\beta ?\alpha ))$$
inst_dept的例子中

α = dept_name β = building, budget

inst_dept 被以下兩個模式取代

( dept_name, building, budget )( ID, name, salary, dept_name )

有可能分解完之后仍有關系模式不符合BCNF，那么continue

保持依賴

檢查包括各種約束（碼、check子句、函數依賴、斷言等）的開銷是很大的，但是如果只涉及到單個關系，檢查約束的開銷相對較低

然而，BCNF分解會妨礙某些函數依賴的高效檢查

如果F上的每一個函數依賴都在其分解后的一個關系上成立，那么這個分解是保持依賴的

因為通常無法同時實現BCNF和保持依賴，因此我們考慮另外一種范式，它比BCNF寬松，允許我們保持依賴，稱為第三范式

第三范式

具有函數依賴集F的關系模式R屬于第三范式（3NF）的條件是：對F+ 中所有形如? → ? 的函數依賴中，至少有以下之一成立

$\alpha \to \beta$ 是一個平凡的函數依賴

α 是R的一個超碼

β - α 中的每個屬性A都包含在R的候選碼中
(注意: 每個屬性也許包含在不同的候選碼中

? 第三個條件是BCNF的一個最小放寬：即允許存在主屬性對候選碼的傳遞依賴和部分依賴，在函數依賴集F中用來滿足保持某些函數依賴

等價定義
關系模式R(U, F)中，若不存在這樣的碼X、屬性組Y及非主屬性Z($Z?Y$)使得$X\to Y$($Y\to X,Y\to X,Y\to Z$),則稱
$$R(U,F)\in 3NF$$

具有屬性依賴集F的關系模式R屬于3NF，則R張任何非主屬性A不部份依賴與碼也不傳遞依賴于R的碼

在關系模式SJP（S，J，P）中，S表示學生，J表示課程, P表示名次。存在函數依賴集F：{(S，J)→P，(J，P)→S}
候選碼: (S，J), (J，P)
S, J, P都是主屬性

因為： 沒有非主屬性部份依賴或傳遞依賴于候選碼 所以： STJ ∈ 3NF因為:對于F任意一個 X → Y,X都是候選碼 所以：STJ ∈ BCNF

例：在關系模式STJ（S，T，J）中，S表示學生，T表示教師，J表示課程。存在如下函數依賴：

每一教師只教一門課；某一學生選定某門課，就確定了一位授課教師；某個學生選修某個教師的課就確定了所選課的名稱（假設）F={T→J，(S，J)→T，(S，T)→J}

∵ (S，J)和(S，T)都是候選碼 ∴ S、T、J都是主屬性∵ 沒有非主屬性部分依賴或傳遞依賴于候選碼 ∴ STJ∈3NF∵ T→J，T是決定屬性集，T不是候選碼 ∴ STJ \not ∈ BCNF

解決方法：將STJ分解為二個關系模式：
TJ(T，J) ∈ BCNF， ST(S，T) ∈ BCNF

原始函數依賴(S，J)→T，(S，T)→J 在該符合BCNF的關系模式中無法保持

BCNF足夠優秀嗎？

考慮一個關系模式
inst_info (ID, child_name, phone)
其中，一個instructor可以有多個children和多個phone
由于該關系模式中只有平凡的函數依賴關系存在，因此其屬于BCNF

然而該BCNF模式仍存在由多值依賴（p238）造成的信息冗余：如果需要為99999教師增加一個電話號碼981-992-3443，那么需要增加兩條元組，如下

(99999, David, 981-992-3443) (99999, William, 981-992-3443)

可以將inst_info關系模式分解為兩個關系模式
inst_child(ID, child_name)
inst_phone(ID, phone)

因此，需要更為嚴格的范式來規范關系模式，如4NF

函數依賴理論

正則覆蓋

函數依賴集可能存在冗余依賴（這些依賴可以從其他依賴中推導出來）
在 {A → B, B → C, A→C }中A → C是冗余的

函數依賴集的一部分也可能是冗余的
如: {A → B, B → C, A → CD }
可以簡化成 {A → B, B → C, A → D }
如: {A → B, B → C, AC → D }
可以簡化為 {A → B, B → C, A → D }

直觀上，F的正則覆蓋$F_c$沒有任何冗余依賴或存在冗余部分的依賴
$F_c$具有和F相同的函數依賴集閉包。其意義在于：驗證$F_c$比驗證F更加容易、3NF算法必備

無關屬性

如果去除函數依賴中的一個屬性不改變該函數依賴集的閉包，則稱該屬性是無關屬性（extraneous）

形式化定義：考慮函數依賴集F及F中函數依賴 α → β

• 如果A ∈ α并且F邏輯蘊涵(F – {α→ β}) ∪ {(α – A)→β}，則屬性A在α 中是無關的
• 如果A ∈ β并且函數依賴集(F – {α→β}) ∪ {α→(β–A)} 邏輯蘊涵F，則屬性A在β中是無關的

eg: 給定 F = {A → C, AB → C}

• B 是AB → C中的無關屬性，因為 {A → C, AB → C}邏輯蘊涵A → C (即從 AB → C中去掉B后的結果)

eg: 給定 F = {A → C, AB → CD}

• C是AB → CD中的無關屬性

驗證方法

考慮函數依賴集F及F中的函數依賴α → β.
驗證屬性A ∈ α 是不是多余的

使用F中的函數依賴計算屬性集閉包$(\alpha –A{)}^{+}$

驗證$(\alpha –A{)}^{+}$ 是否包含β；如果包含，那么A 是多余屬性

驗證屬性A ∈ β 在 β 中是否多余

使用函數依賴集F’= (F –{α → β}) ∪ {α →(β–A)}計算${\alpha }^{+}$

驗證${\alpha }^{+}$ 是否包含A；如果包含，那么A 在α中是多余屬性

正則覆蓋

計算F的正則覆蓋算法：首先，初始化Fc= F； repeat使用合并律將Fc中的形如α1 → β1 及 α1 → β2 的依賴替換為 α1 → β1β2在Fc中找出 在α或?中含無關屬性的函數依賴α → β/* 注意：使用Fc而不是F檢驗無關屬性*/若發現無關屬性則將它從Fc中的α → β中刪除 until Fc 不再發生變化

注意：在刪除了某些無關屬性后可能需要使用合并律，因此合并律會重復應用

F的正則覆蓋Fc是一個函數依賴集 ，具有如下特性：

• F 邏輯蘊涵Fc中的所有函數依賴
• Fc邏輯蘊涵F中的所有函數依賴
• Fc中任何函數依賴都不含無關屬性
• Fc中函數依賴的左半部都是不同的

R = (A, B, C) F = { A → BC，B → C，A → B，AB → C }?合并 A → BC 和 A → B ，形成 A → BC修改Fc1為{ A → BC, B → C, AB → C }?A在AB → C中是無關屬性利用Fc1檢驗(AB-A)＋是否包含C包含，則修改Fc2為{ A → BC, B → C }?C在A → BC中是無關屬性計算F’｛A → B, B → C｝下A＋閉包是否包含C包含，則修改Fc3為｛A → B, B → C｝

正則覆蓋是
$$\begin{gathered} A\to B \\ B\to C \end{gathered}$$

無損分解

對于R = (R1, R2), 我們要求模式R上的所有可能關系r都有
$$r={\Pi }_{R1}(r)?{\Pi }_{R2}(r)$$

如果下面的依賴中至少有一個屬于$F^{+}$，那么將R分解成 R1 和R2 是無損分解連接:
$$\begin{gathered} R1\cap R2\to R1 \\ R1\cap R2\to R2 \end{gathered}$$
即 R1 ∩ R2 是R1或R2的超碼

上述函數依賴測試只是無損連接分解的一個充分條件；只有當所有約束都是函數依賴時，它才是必要條件(某些情況下，即使不存在函數依賴的情況下，仍可保證一個分解是無損分解)

eg

R = ( A, B, C ) F = { A → B, B → C } // 可以通過兩種方式分解 1.R1 = (A, B), R2 = (B, C) 無損連接分解： R1 ∩ R2 = { B }B→ BC2. R1 = (A, B), R2 = (A, C)無損連接分解： R1 ∩ R2= { A }A → AB

保持依賴

F為模式R上的一個函數依賴集，R1,R2, … , Rn為R的一個分解。F在Ri上的限定是$F^{+}$中所有只包含Ri中屬性的函數依賴的集合Fi

方法一（圖8-10）：令$F’=F_1\cup F_2\cup \dots \cup F_n$。 F’ 是模式R上的一個函數依賴集

• 如果下面的式子成立，那么分解是保持依賴的
  $$(F’{)}^{+}=F^{+}$$
• 稱具有性質$(F’{)}^{+}=F^{+}$的分解為保持依賴的分解

方法二（充要條件）：當R分解成R1, R2, …, Rn后，應用以下算法，驗證F中每一個函數依賴α → β 是否被保持：

result = α while (result發生變化) dofor each 分解后的Rit =((result ∩ Ri)^+) ∩ Riresult = result ∪ t

• 如果result 包含β中的所有屬性，那么函數依賴 α → β 被保持
• 可以將這個驗證應用到所有F中的依賴，來驗證這個分解是否保持依賴
• 方法的好處：沒有計算F在Ri上的限定并使用它計算result 的屬性閉包，而是使用F上（result ∩ Ri）上的屬性閉包得到一個相同的結果`

eg

R = (A, B, C) F = {A → B, B → C} // 可以通過兩種方式分解R1 = (A, B), R2 = (B, C) 無損連接分解： 保持依賴R1 ∩ R2 = {B} and B → BCR1 = (A, B), R2 = (A, C) 無損連接分解： 不保持依賴 R1 ∩ R2 = {A} and A → AB(不計算R1 \Join R2, 無法驗證B →C)

分解算法

對于$F^{+}$中非平凡依賴$\alpha \to \beta$驗證是否違反BC范式

計算${\alpha }^{+}$

檢驗是否包含R的所有屬性，驗證是否是R的超碼

檢查R是否屬于BCNF，檢查F的函數依賴是否違反BCNF（如果F中沒有違反BCNF的函數依賴，那么F+中也不會有違反BCNF的函數依賴）

在檢測由關系R分解后的關系Ri是否滿足BCNF范式時，只使用F是不正確的

R = (A, B, C, D, E), F = { A → B, BC → D} ? 將R 分解成R1 = (A,B) 和 R2 = (A,C,D, E) ? F中沒有一個依賴僅包含來自(A,C,D,E)的屬性，所以我們可能誤認為R2滿足BCNF ? 事實上，F+中有一個函數依賴AC → D，這表明R2不屬于BCNF

檢查R分解后的關系Ri是否屬于BCNF

• 使用F在Ri上的限定檢測$R_i$是否滿足BCNF (即，$F^{+}$中只包含$R_i$中的屬性的FD)
• 使用R中成立的原來的依賴集F 進行以下測試
  • 對每個屬性集$\alpha \in R_i$, 確保${\alpha }^{+}$（在F下的）要么不包含$R_i?\alpha$的任何屬性，要么包含$R_i$的所有屬性
  • 如果F中的某些函數依賴$\alpha \to \beta$違反了該條件，那么
    如下函數依賴出現在F+中： $\alpha \to ({\alpha }^{+}?\alpha )\cap R_i$則Ri違反了BCNF
    
    我們將關系模式R分解成：
• $(\alpha \cup \beta )$
• $(R?(\beta ?\alpha ))$

$\alpha$ = dept_name
$\beta$ = building, budget

inst_dept

• $(\alpha \cup \beta )$ = ( dept_name, building, budget )
• $(R?(\beta ?\alpha ))$ = ( ID, name, salary, dept_name )

example

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候選碼{course_id, sec_id, semester, year}.

分析：
course_id→ title, dept_name, credits 不符合BCNF要求
但是 {building, room_number} 不是class-1的超碼
拆成三部分

R = (J, K, L ) F = {JK → L， L → K }

兩個候選碼：JK 和JL
?R 不滿足BCNF
?R 滿足3NF
?R 的任何分解都不可能保持
$$JK\to L$$
?這意味著要驗證 JK → L 需要連接操作

?BCNF分解可能無法做到保持依賴
?能夠有效的驗證更新是否違反函數依賴很重要
解決方法：采用一個稍弱的范式，第三范式

允許冗余（會引起問題）

但是函數依賴可以在不進行連接操作的情況下在單個關系上檢驗

總是能夠在無損連接及保持依賴的情況下分解成3NF

關系dept_advisor:
dept_advisor (s_ID, i_ID, dept_name)
F = { s_ID, dept_name → i_ID, i_ID → dept_name }

兩個候選碼: s_ID, dept_name, 和 i_ID, s_ID

R 是3NF

• s_ID, dept_name → i_ID
  • s_ID，dept_name 是超碼
• i_ID → dept_name
  • $\beta ?\alpha$= dept_name 在一個候選碼中

冗余覆蓋

? 信息重復

R中( l1, k1)

dept_advisor中(i_ID, dept_name)

? 需要使用空值

R中沒有對應l2, k2的J值.

dept_advisor (s_ID，i_ID, dept_name) 沒有學生信息時

cust_banker_branch = (customer_id, employee_id, branch_name, type)函數依賴是: 1. customer_id, employee_id → branch_name, type 2. employee_id → branch_name 3. customer_id, branch_name → employee_id

計算正則覆蓋

? 1 st 依賴中是branch_name多余的 ? 沒有其他冗余屬性,所以得到 FC =customer_id, employee_id → typeemployee_id → branch_namecustomer_id, branch_name → employee_id產生下面的3NF模式: (customer_id, employee_id, type) <- primary key(c_id, e_id) (employee_id, branch_name) <- primary key(e_id) (customer_id, branch_name, employee_id)<- primary key(c_id, b_name)

(customer_id, employee_id, type ) 包含了原模式的一個候選碼，因此沒有其他關系模式需要添加

檢測并刪除類似(employee_id, branch_name)的模式，這個模式是其它模式的子集

由此產生的簡化3NF模式為:

(customer_id, employee_id, type) (customer_id, branch_name, employee_id)

BC和3的比較

BCNF和3NF的比較
? 總能夠把一個關系分解為多個滿足3NF的關系，并且:
?分解是無損的
?保持依賴
?可能存在信息冗余
? 總能夠把一個關系分解為多個滿足BCNF的關系，并且:
?分解是無損的
?可能不滿足保持依賴

? 關系數據庫設計目標：
?BCNF
?無損
?保持依賴
? 如果不能同時達到上述三個目標，選擇接受下面的其中一個
?缺少保持依賴
?使用3NF，可能帶來冗余
? 除了可以通過用主碼外，SQL不提供指定函數依賴的途徑.
特殊的FD可以使用斷言，但是測試代價太高（目前不被大多
數數據庫所支持）
? 即使我們能夠得到保持依賴的分解，使用SQL 還是不能有效
地測試一個左邊不是主碼的函數依賴

review
?什么是有損分解、無損分解？
?什么是原子域和第一范式？
?什么是函數依賴？
?什么是BCNF和3NF？
?什么是邏輯蘊含？函數依賴集的閉包、屬性集
的閉包、正則覆蓋？
?如何將一個關系模式分解為屬于BCNF、3NF
的關系模式

總結

以上是生活随笔為你收集整理的数据库理论 05 关系数据库设计——基于《数据库系统概念》第七版的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。