6.0 《数据库系统概论》之关系数据库的规范化理论（数据依赖对表的影响[插入-删除-修改-冗余]、1NF-2NF-3NF-BCNF-4NF、函数依赖与多值依赖）
文章目錄
- 0.思維導圖
- 1.為什么要學習關系數據庫規范化理論？
- （1）基本概念回顧
- （2）關系模式的形式化定義
- （3）什么是數據依賴F？
- （4）數據依賴F對關系模式的影響
- 1?? 數據冗余(Data redundancy)
- 2?? 更新異常(update anomalies )
- 3?? 插入異常(insertion anomalies )
- 4?? 刪除異常( deletion anomalies)
- 2.規范化---改造關系模式，解決插入異常、刪除異常、更新異常和數據冗余問題。
- （1）規范化研究什么？
- （2）函數依賴
- ① 函數依賴
- ② 平凡函數依賴與非平凡函數依賴
- ③ 完全函數依賴與部分函數依賴
- ④ 傳遞函數依賴
- （3）碼
- ① 候選碼、超碼、主碼
- ② 主屬性和非主屬性
- ③ 外部碼
- （4）范式
- ① 1NF
- ② 2NF
- ③ 3NF
- ④ BCNF
- ⑤ 3NF與BCNF的關系
- （5）多值依賴
- ① 多值依賴的定義
- ② 平凡多值依賴和非平凡多值依賴
- ③ 多值依賴與函數依賴的區別
- （6）4NF
- （7）規范化小結---重點歸納步驟
0.思維導圖
1.為什么要學習關系數據庫規范化理論？
感性認識：
- 當我們面對一個實際問題時，我們應該如何去建數據庫，建表，庫的結構，表的結構我們該如何組織，才能更好的解決問題。
- 如何省內存，提高查詢修改刪除更新的效率？
- 如何避免可能出現的隱患，如修改刪除更新插入等異常？
- 以上就是關系數據庫規范化理論研究解決的問題,說白了就是告訴你如何才能設計出合適的庫和表
下面我們回顧幾個概念和問題，以便更好地學習后面的關系數據庫規范化理論
（1）基本概念回顧
-
關系：可簡單的理解為二維表
-
關系模式：即二維表的邏輯結構
-
關系數據庫：指采用了關系模型來組織數據的數據庫，其以行和列的形式存儲數據，關系型數據庫這一系列的行和列被稱為表，一組表組成了數據庫。
-
關系數據庫的模式：即關系數據庫的邏輯結構
（2）關系模式的形式化定義
- 這里我們回顧一下《數據庫系統概論》中對二維表結構的定義
關系模式由五部分組成，即它是一個五元組：
R(U, D, DOM, F)
R： 關系名,即表名
U： 組成該關系的屬性名集合
D： 屬性組U中屬性所來自的域。數據的取值范圍和類型
DOM： 屬性向域的映象集合
F： 屬性組U上的一組數據依賴。
關系數據庫規范化理論研究的就是R、F、U，之間的關系。
因為D和DOM對研究表的設計關系不大，所以在學習關系數據庫規范化理論時可以將五元組簡化成三元組
三元組：R（U, F）
當且僅當U上的一個關系r滿足F時，r稱為關系模式 R（U, F）的一個關系
（3）什么是數據依賴F？
這里我們對F中的數據依賴進行簡單解釋，后面會詳細敘述函數依賴和多值依賴。
數據依賴是一個關系內部屬性與屬性之間的一種約束關系。
這種約束關系是通過屬性間值的相等與否體現出來的數據間相關聯系。
它是現實世界屬性間相互聯系的抽象，是數據內在的性質，是語義的體現。
數據依賴分類：
- 函數依賴（Functional Dependency，簡記為FD）
函數依賴極為普遍地存在于現實生活中。比如描述一個學生的關系，可以有學號(Sno)、姓名(Sname)、 系名(Sdept) 等幾個屬性。由于一個學號只對應一個學生，一個學生只在一一個系學習。因而當“學號”值確定之后，學生的姓名及所在系的值也就被唯一地確定了。屬性間的這種依賴關系類似于數學中的函數y=f(x)，自變量x確定之后，相應的函數值y也就唯一地確定 了。
- 多值依賴（Multivalued Dependency，簡記為MVD）
- 其他
（4）數據依賴F對關系模式的影響
- 因為關系數據庫規范化理論主要研究的是三元組R(U,F)，U我們都好理解，最重要的是F，這里我們簡單的了解一下F對關系模式，即表的邏輯結構的影響，讓我們理性的認識為什么學習關系數據庫規范化理論
舉個例子：
[例1]建立一個描述學校教務的數據庫,數據庫涉及的對象有：
學生的學號（Sno）、所在系（Sdept）、系主任姓名（Mname）、課程名（Cname）、成績（Grade）
這里我們用單一的關系模式Student來表示這些對象：
Student <U、F>
該關系的屬性集合：
U ＝｛ Sno, Sdept, Mname, Cname, Grade ｝
這里說明一下現實世界的事實語義，關于這些對象之間的聯系：
①一個系有若干學生，但一個學生只屬于一個系。
②一個系只有一名(正職)負責人。
③一個學生可以選修多門課程，每門課程有若干學生選修。
④每個學生學習每一一門課程有一個成績。
于是得到屬性組U上的一組函數依賴F
F={Sno- > Sdept, Sdept- >Mname, (Sno, Cno)- >Grade}
(如圖所示)
- 如果只考慮函數依賴這一種數據依賴， 可以得到一個描述學生的關系模式Student <U,F>。表6.1是某一時刻關系模式Student的一個實例，即數據表。
這個關系模式設計的并不好,存在以下問題:
1?? 數據冗余(Data redundancy)
- 比如，每一個系的系主任姓名重復出現，重復次數與該系所有學生的所有課程成績出現次數相同，如表6.1所示。這將浪費大量的存儲空間。
2?? 更新異常(update anomalies )
- 由于數據冗余，當更新數據庫中的數據時，系統要付出很大的代價來維護數據庫的完整性，否則會面臨數據不一致的危險。 比如，某系更換系主任后，必須修改與該系學生有關的每一個元組。
3?? 插入異常(insertion anomalies )
- 如果一個系剛成立，尚無學生，則無法把這個系及其系主任的信息存入數據庫。
4?? 刪除異常( deletion anomalies)
- 如果某個系的學生全部畢業了，則在刪除該系學生信息的同時，這個系及其系主任的信息也丟掉了。
鑒于存在以上種種問題，可以得出這樣的結論:
- Student關系模式不是一個好的模式。
- “好”的模式：
不會發生插入異常、刪除異常、更新異常，數據冗余應盡可能少 - 原因：由存在于模式中的某些數據依賴引起的
- 解決方法：通過分解關系模式來消除其中不合適 的數據依賴
可以把這個單一模式分成3個關系模式：
- S（Sno，Sdept，Sno → Sdept）;
- SC（Sno，Cno，Grade，（Sno，Cno） → Grade）;
- DEPT（Sdept，Mname，Sdept→ Mname）
這三個模式都不會發生插入異常、刪除異常的問題，數據的冗余也得到了控制。
一個模式的數據依賴會有哪些不好的性質，如何改造一個不好的模式，這就是接下來2.規范化要討論的內容。
2.規范化—改造關系模式，解決插入異常、刪除異常、更新異常和數據冗余問題。
（1）規范化研究什么？
- 規范化討論如何根據屬性間依賴情況來判定關系是否具有某些不合適的性質
- 通常按屬性間依賴情況來區分關系規范化程度為第一范式、第二范式、第三范式和第四范式等
- 用來改造關系模式，通過分解關系模式來消除其中不合適的數據依賴，以解決插入異常、刪除異常、更新異常和數據冗余問題。
接下來我們依次學習以下內容，來更好的掌握規范化理論，來更好的設計表的結構，設計關系模式。
- 函數依賴
- 碼
- 范式
- 2NF
- 3NF
- BCNF
- 多值依賴
- 4NF
其中函數依賴、碼是為了學習范式、1NF,2NF,3NF……打基礎
（2）函數依賴
這里我們討論數據依賴F中的函數依賴，分為以下幾種類型：
- 函數依賴
- 平凡函數依賴與非平凡函數依賴
- 完全函數依賴與部分函數依賴
- 傳遞函數依賴
① 函數依賴
注意:函數依賴不是指關系模式R的某個或某些關系滿足的約束條件，而是指R的一切關系均要滿足的約束條件。
以下是一個錯誤的例子：
sno->sdept，sno應該唯一決定sdept
函數依賴和別的數據依賴樣是語義范疇的概念，只能根據語義來確定一個函數依賴。
例如，姓名→年齡這個函數依賴只有在該部門沒有同名人的條件下成立。如果允許有同名人，則年齡就不再函數依賴于姓名了。
② 平凡函數依賴與非平凡函數依賴
③ 完全函數依賴與部分函數依賴
④ 傳遞函數依賴
直接依賴這里我們舉個例子：
BH(sno,idCard,address)
X：sno 學號
Y：idCard 身份證號
Z：address 住址
X->Y，Y->X，X<->Y，Y->Z
所以我們說Z直接依賴于X
（3）碼
- 碼是關系模式中的一個重要概念。在 碼的定義中有關碼的若干定義， 這里用函數依賴的概念來定義碼。
- 碼唯一決定一個實體集
① 候選碼、超碼、主碼
② 主屬性和非主屬性
主屬性與非主屬性
- 包含在任何一個候選碼中的屬性 ，稱為主屬性（Prime attribute）
- 不包含在任何碼中的屬性稱為非主屬性（Nonprime attribute）或非碼屬性（Non-key attribute）
舉幾個例子：
[例2]
關系模式S(Sno,Sdept,Sage)，單個屬性Sno是碼，
SC（Sno，Cno，Grade）中，（Sno，Cno）是碼
[例3]
關系模式R（P，W，A）
P：演奏者 W：作品 A：聽眾
一個演奏者可以演奏多個作品
某一作品可被多個演奏者演奏
聽眾可以欣賞不同演奏者的不同作品
碼為(P，W，A)，即All-Key
③ 外部碼
（4）范式
- 范式是符合某一種級別的關系模式的集合
- 關系數據庫中的關系必須滿足一定的要求。滿足不同程度要求的為不同的范式。
- 級別越高，表設計的越合理
范式的種類：
各種范式之間存在聯系：
- 某一關系模式R為第n范式，可簡記為R∈nNF。
一個低一級范式的關系模式，通過模式分解可以轉換為若干個高一級范式的關系模式的集合，這種過程就叫規范化
① 1NF
1NF的定義:
- 如果一個關系模式R的所有屬性都是不可分的基本數據項，則R∈1NF
- 第一范式是對關系模式的最起碼的要求。不滿足第一范式的數據庫模式不能稱為關系數據庫
- 但是滿足第一范式的關系模式并不一定是一個好的關系模式
以下是一個滿足1NF，但不是好的關系模式的例子：
關系模式 S-L-C(Sno, Sdept, Sloc, Cno, Grade)
Sloc為學生住處，假設每個系的學生住在同一個地方
- 這個例子中存在函數依賴，不是一個好的關系模式
圖形化表示：
S-L-C不是一個好的關系模式，一個關系模式 R不屬于2NF,就會產生以下幾個問題:
- (1)插入異常。假若要插入一個學生Sno=S7， Sdept =PHY， Sloc =BLD2， 但該生還未選課，即這個學生無Cno,這樣的元組就插不進S-L-C中。因為插入元組時必須給定碼值，而這時碼值的一部分 為空，因而學生的固有信息無法插入。
- (2)刪除異常。假定某個學生只選一門課，如S4就選了一門課C3，現在C3這門課他也不選了，那么C3這個數據項就要刪除。而C3是主屬性，刪除了C3，整個元組就必須一起刪除，使得S4的其他信息也被刪除了，從而造成刪除異常，即不應刪除的信息也刪除了。
- (3)修改復雜。某個學生從數學系(MA)轉到計算機科學系(CS)，這本來只需修改此學生元組中的Sdept分量即可，但因為關系模式S-L-C中還含有系的住處Sloc屬性，學生轉系將同時改變住處，因而還必須修改元組中的Sloc分量。另外，如果這個學生選修了k門課，Sdept、 Sloc重復存儲了k次，不僅存儲冗余度大，而且必須無遺漏地修改k個元組中全部Sdept、Sloc 信息，造成修改的復雜化。
為什么會有這些問題呢？
- 原因：
Sdept、 Sloc部分函數依賴于碼。 - 解決方法(也就是2NF的處理方法)
S-L-C分解為兩個關系模式，以消除這些部分函數依賴
SC（Sno， Cno， Grade）
S-L（Sno， Sdept， Sloc）
② 2NF
-
采用投影分解法將一個1NF的關系分解為多個2NF的關系，可以在一定程度上減輕原1NF關系中存在的插入異常、刪除異常、數據冗余度大、修改復雜等問題。
-
將一個1NF關系分解為多個2NF的關系，并不能完全消除關系模式中的各種異常情況和數據冗余。所以又引入了3NF。
③ 3NF
這里我們對上面的2NF例子再次進行剖析：
解決方法：
- 采用投影分解法，把S-L分解為兩個關系模式，以消除傳遞函數依賴：
S-D（Sno， Sdept）
D-L（Sdept，Sloc） - S-D的碼為Sno， D-L的碼為Sdept。
- 分解后的關系模式S-D與D-L中不再存在傳遞依賴
-
采用投影分解法將一個2NF的關系分解為多個3NF的關系，可以在一定程度上解決原2NF關系中存在的插入異常、刪除異常、數據冗余度大、修改復雜等問題。
-
將一個2NF關系分解為多個3NF的關系后，仍然不能完全消除關系模式中的各種異常情況和數據冗余。
④ BCNF
BCNF ( Boyce Codd Normal Form)是由Boyce與Codd提出的，比上述的3NF又進了一步，通常認為BCNF是修正的第三范式，有時也稱為擴充的第三范式。
下面用幾個例子說明屬于3NF的關系模式有的屬于BCNF，但有的不屬于BCNF。
[例5] 關系模式C（Cno，Cname，Pcno）
C∈3NF
C∈BCNF
關系模式C(Cno, Cname, Peno)， 它只有一個碼Cno, 這里沒有任何屬性對Cno部分依賴或傳遞依賴，所以C∈3NF。同時C中Cno是唯一的決定因素， 所以C ∈BCNF。
[例6]關系模式S(Sno, Sname, Sdept, Sage)
假定S有兩個碼Sno，Sname
S∈3NF。
S ∈ BCNF
假定Sname也具有唯一性， 那么S就有兩個碼，這兩個碼都由單個屬性組成，彼此不相交。其他屬性不存在對碼的傳遞依賴與部分依賴，所以S∈3NF。
同時S中除Sno、Sname外沒有其他決定因素，所以S也屬于BCNF。
［例7］關系模式SJP（S，J，P）
SJP∈3NF，
SJP∈BCNF
[例6.7]關系模式SJP(S, J, P)中，S是學生，J表示課程，P表示名次。
每一個學生選修每門課程的成績有一定的名次，
每門課程中每一名次只有一個 學生(即沒有并列名次)。
由語義可得到下面的函數依賴:
(S,J)→P; (J,P)→S
所以(S,J) 與(J,P)都可以作為候選碼。
這兩個碼各由兩個屬性組成，而且它們是相交的。
這個關系模式中顯然沒有屬性對碼傳遞依賴或部分依賴。
所以SJP∈3NF，而且除(S,J)與(J,P)以外沒有其他決定因素，所以SJP∈BCNF。
[例8] 關系模式STJ(S, T, J)中，S表示學生，T表示教師，J表示課程。
每一教師只教一門課，
每門課有若干教師，
某一學生選定某門課， 就對應一個固定的教師。
由語義可得到如下的函數依賴。
(S,J)→T，(S,T)-J, T→J
函數依賴關系可以用如圖表示
這里(S,J)、 (S,T)都是候選碼。
STJ是3NF,因為沒有任何非主屬性對碼傳遞依賴或部分依賴，
但STJ不是BCNF關系，因為T是決定因素，而T不包含碼。
如何解決才能讓STJ是BCNF關系呢？
⑤ 3NF與BCNF的關系
- 3NF和BCNF是在函數依賴的條件下對模式分解所能達到的分離程度的測度。
- 一個模式中的關系模式如果都屬于BCNF,那么在函數依賴范疇內它已實現了徹底的分離，已消除了插入和刪除的異常。
- 3NF的“不徹底”性表現在可能存在主屬性對碼的部分依賴和傳遞依賴。
（5）多值依賴
- 前面我們講了數據依賴分為函數依賴和多值依賴，函數依賴在上面已經敘述了，這里我們再討論多值依賴。
用一個例子引入多值依賴：
[例9] 學校中某一門課程由多個教師講授，他們使用相同的一套參考書。每個教員可以講授多門課程，每種參考書可以供多門課程使用。
可以用一個非規范化的關系來表示教師T、課程C和參考書B之間的關系
把這張表變成一張規范化的二維表：
-
關系模型Teaching (C, T,B)的碼是(C, T, B)，即all-key,因而Teaching∈BCNF。
-
但是當某一課程(如物理)增加一名講課教師(如周英)時，必須插入多個(這里是三個)元組:
(物理，周英，普通物理學)，(物理，周英，光學原理)，(物理，周英，物理習題集)。 -
同樣，某一門課(如數學)要去掉一本參考書(如微分方程)，則必須刪除多個(這里是兩個)元組:
(數學，李勇，微分方程)，(數學，張平，微分方程)。 -
可以看出對數據的增刪改很不方便，數據的冗余也十分明顯。
-
仔細考察這類關系模式，發現它具有一種稱之為多值依賴(Multi-Valued Dependency, MVD)的數據依賴。
① 多值依賴的定義
例如，在關系模式Teaching中，對于一個(物理，光學原理)有一組T值{李勇，王軍}，這組值僅僅決定于課程C上的值(物理)。
也就是說對于另一個(物理，普通物理學)，它對應的一組T值仍是{李勇，王軍}，盡管這時參考書B的值已經改變了。
因此T多值依賴于C，即C→→T。
② 平凡多值依賴和非平凡多值依賴
下面再舉一個具有多值依賴的關系模式的例子。
- 對于W的每一個值Wi, S有一個完整的集合與之對應而不問C取何值。所以W→→S(多值依賴)。
如果用圖下圖來表示這種對應
- 則對應W的某一個值Wi的全部S值記作{S}wi (表示此倉庫工作的全部保管員)
- 全部C值記作{C}wi (表示在此倉庫中存放的所有商品)。
- 應當有{S}wi中的每一個值和{C}wi中的每一個C值對應。
- 于是{S}wi與{C}wi之間正好形成一個完全二分圖，因而W→→S。
- 由于C與S的完全對稱性，必然有W→→C成立。
多值依賴具有以下性質:
③ 多值依賴與函數依賴的區別
（6）4NF
（7）規范化小結—重點歸納步驟
-
關系數據庫的規范化理論是數據庫邏輯設計的工具
-
目的：盡量消除插入、刪除異常，修改復雜，數據冗余
-
基本思想：逐步消除數據依賴中不合適的部分
實質：·概念的單一化·
關系模式規范化的基本步驟:
參考：《數據庫系統概論第五版》—王珊
總結
以上是生活随笔為你收集整理的6.0 《数据库系统概论》之关系数据库的规范化理论（数据依赖对表的影响[插入-删除-修改-冗余]、1NF-2NF-3NF-BCNF-4NF、函数依赖与多值依赖）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Object与equals
- 下一篇： 5.1.2 操作系统控制I/O设备的I/