第5章 關系模式的規(guī)范化設計

第5章關系模式的規(guī)范化設計

主要內容:本章討論關系模式的規(guī)范化設計。這章將從數據庫邏輯設計中如何構造一個好的數據庫模式這一問題出發(fā)，闡明了關系規(guī)范化理論研究的實際背景，介紹關系內部屬性與屬性之間的一種約束關系即函數依賴的各種形式。介紹規(guī)范化理論，討論各種范式及可能存在的插入、刪除等問題，并直觀地描述解決辦法。

25.1問題提出前面的章節(jié)已經介紹了數據庫當中涉及到的基本概念，關系模型的三個部分(關系數據結構、關系操作集合和關系完整性)以及關系數據庫的標準語言。 但是有一個很基本的問題沒有提及，就是針對一個具體的問題，應該構造幾個關系模式，每個關系由哪些屬性組成，各屬性之間的依賴關系及其對關系模式性能的影響等。 這就是關系數據庫邏輯設計的問題。本章主要來討論實體內部屬性與屬性之間的數據關聯(lián)，目標就是要設計一個“好”的數據庫。3關系模型原理的核心內容就是規(guī)范化概念。

規(guī)范化是把數據庫組織成在保持存儲數據完整性的同時最小化冗余數據的結構的過程。 規(guī)范化的數據庫必須符合關系模型的范式規(guī)則。范式可以防止在使用數據庫時出現(xiàn)不一致的數據，并防止數據丟失。 關系模型的范式有第一范式、第二范式、第三范式、BCNF范式、第四范式等多種。45.2數據依賴 數據依賴是關系內部屬性與屬性之間的一種約束關系。這種約束關系是通過屬性間值的相等與否體現(xiàn)出來的數據間的相關聯(lián)系，它是現(xiàn)實世界屬性間相互聯(lián)系的抽象，是數據內在的性質，是語義的體現(xiàn)。如教師姓名和地址之間，每一個教師都有個確定的地址，意味著：

教師編號確定了，地址就確定了．地址依賴于教師編號。

5數據依賴的類型函數依賴（FunctionalDependency，簡記為FD）多值依賴（MultivaluedDependency，簡記為MVD）其他6數據依賴對關系模式的影響“好”的模式：不會發(fā)生插入異常、刪除異常、更新異常，數據冗余應盡可能少“不好”原因：由存在于模式中的某些數據依賴引起的解決方法：通過分解關系模式來消除其中不合適的數據依賴75.2.2函數依賴函數依賴（functiondependency）是最基本的一種數據依賴，也是設計關系模式時應著重考慮的因素.-平凡函數依賴與非平凡函數依賴-完全函數依賴與部分函數依賴-傳遞函數依賴函數依賴定義5.1設R(U)是屬性集U上的一個關系模式。X和Y是U的子集。若對于R(U)中任意一個可能關系r，r中不存在有兩個元組，它們在X上的屬性值相等，而在Y上的屬性值不等，則稱“X函數決定Y”，或稱“Y函數依賴于X”。記作X→Y。8函數依賴Y=f(X)函數Y=sin(X)Y=X+1Y=X2+2X+1省=f(城市)系名=f(學號)?X是自變量，自變量確定了，Y的值也就確定了城市=f(省)學號=f(系名)√9一個關系模式由五部分組成，即它是一個五元組：描述為：R(U,D,dom,F)。其中：（1）R是關系名；（2）U是一組屬性，即組成R的全部屬性的集合；（3）D為域的集合，即屬性取值范圍的集合；（4）dom為U與D之間的映象；（5）F是屬性組U上的一組函數依賴。

說明：由于域的定義對關系模式設計關系不大，（3）和（4）往往可以忽略。10術語和符號如果X→Y，但Y不是X的子集，則稱X→Y是非平凡的函數依賴。如果X→Y

，但Y是X的子集，則稱X→Y為平凡的函數依賴。說明：平凡函數依賴對于任一關系模式都是必然成立的。因此，一般討論的都是非平凡的函數依賴。例：在關系選修(學號,課程號,成績)中，(學號,課程號)→成績(學號,所在系)→所在系非平凡依賴平凡依賴11術語和符號(續(xù))如果X→Y，則X稱作決定因素或決定屬性集。 如:學號→所在系，則學號稱作決定因素。如果X→Y，并且Y→X，則可記作X←→Y。如果Y不函數依賴于X，則記作

。12定義5.2在R(U)中，如果X→Y，并且對于X的任何一個真子集X’，都有,

則稱Y對X完全函數依賴，記作若X→Y，但Y不完全函數依賴于X，則稱Y對X部分函數依賴，記作。13例題（學號，課程號）→課程名（學號，課程號）→學分（學號，課程號）→成績部分函數依賴部分函數依賴完全函數依賴[例]在成績表SC(Sno,Cno,Credit,Grade)中，Sno是學號，Cno是課程號，Credit是學分，Grade是成績。14定義5.3在R(U)中，如果X→Y，Y→Z，且Y不是X的子集，Z不是Y的子集（非平凡的函數依賴），則稱Z對X傳遞函數依賴。記為：說明:如果Y→X，即X←→Y，則Z直接依賴于X。[例]:在關系Std(Sno,Sdept,Mname)中，Sno是學號，Sdept是系名，Mname是系主任名，有：

Sno→Sdept，Sdept→Mname

Mname傳遞函數依賴于Sno155.2.4鍵本節(jié)用函數依賴的概念來定義鍵。 定義5.5設K為R（U，F(xiàn)）中的屬性或屬性組合，若K→U則K為R的候選鍵。若候選鍵多于一個，則選定其中的一個為主鍵（Primarykey）。 含在任何一個候選鍵中的屬性,叫做主屬性(Primeattribute)。 不包含在任何鍵中的屬性稱為非主屬性(Nonprimeattribute)。 最簡單的情況：單個屬性是鍵。 最極端的情況：整個屬性組是鍵,稱為全鍵（All-key).

16定義5.6關系模式R中屬性或屬性組X并非R的鍵,但X是另一個關系模式的鍵,則稱X是R的外部鍵(Foreignkey)也稱外鍵。如在SC（Sno，Cno，Grade）中，Sno不是碼，但Sno是關系模式S（Sno，Sdept，Sage）的碼，則Sno是關系模式SC的外碼。主鍵與外部鍵提供了一個表示關系間聯(lián)系的手段。175.3規(guī)范化的關系模式 范式是符合某一種級別的關系模式的集合。關系數據庫中的關系必須滿足一定的要求。滿足不同程度要求的為不同范式。范式的種類： 第一范式(1NF)，第二范式(2NF)，第三范式(3NF) BC范式(BCNF)，第四范式(4NF)，第五范式(5NF)18各種范式之間的關系195.3.1第一范式1NF的定義 定義5.7如果一個關系模式R的所有屬性都是不可分的基本數據項，則R∈1NF說明：第一范式是對關系模式的最起碼的要求。不滿足第一范式的數據庫模式不能稱為關系數據庫。但是滿足第一范式的關系模式并不一定是一個好的關系模式20例如，在表1，籍貫含有省、市／縣兩項，出現(xiàn)了“表中有表”的現(xiàn)象，則為非規(guī)范化關系（不符合“第一范式”），而把籍貫分成省、市／縣兩列，將其規(guī)范化，如表2所示。姓名籍貫省市/縣王洪黑龍江齊齊哈爾李利吉林長春表1不規(guī)范的關系表2規(guī)范后的關系長春吉林李利齊齊哈爾黑龍江王洪市/縣省姓名小表不允許表中有表21[例5-6]關系模式S-L-C(Sno,Sdept,Sloc,Cno,G)其中，Sno為學生的學號，Sdept為學生的系別，Sloc為學生住處，假設每個系的學生住在同一個地方，Cno為課程號，G為學生的成績。本例中的函數依賴包括：5.3.2第二范式22關系模式S-L-C的函數依賴關系圖S-L-C滿足第一范式。

S-L-C的碼為(Sno,Cno)非主屬性Sdept和Sloc部分函數依賴于碼(Sno,Cno)本例中的函數依賴包括：說明：實線表示完全函數依賴，虛線表示部分函數依賴23一個“非2NF”的關系模式Sno（學號）Sdept（系別）Sloc（學生住處）Cno（課程號）G（成績）S1電子商務10號樓180S1電子商務10號樓290S1電子商務10號樓375S2計算機20號樓185S2計算機20號樓382S3外語15號樓288S4會計30號樓58624S-L-C不是一個“好”的關系模式(1)插入異常 沒有選課的學生記錄插不進去，因為Cno是主碼的一部分，主碼不能為空。(2)刪除異常 刪除選課記錄會將學生信息也一同刪掉。即不該刪除的信息也刪除掉了。(3)數據冗余度大 系別和學生住處會重復存放。如一個學生選修了10門課程，那么他的Sdept和Sloc的值就要重復存儲10次。(4)修改復雜 如某個學生從電子商務系轉到外語系，本來只需要修改此學生的Sdept值。但因為關系模式SLC中還含有系的住處Sloc屬性，學生轉系將同時改變住處，因此還必須修改Sloc的值。如果該學生選修了3門課，由于Sdept和Sloc的值重復存放了3次，當數據更新時必須無遺漏的修改3個元組中全部Sdept和Sloc的值，這就造成了修改的復雜化。25“不好”原因

分析該例，可見有2種非主屬性，一是G，它對碼（Sno,Cno）是完全函數依賴。另一種是Sdept和Sloc，它們都是部分函數依賴于碼（Sno,Cno）。解決方法

用投影分解把S-L-C分解為兩個關系模式，以消除這些部分函數依賴

SC（Sno，Cno，G）

S-L（Sno，Sdept，Sloc）26“分解”以后的函數依賴圖：關系模式SC的碼為（Sno，Cno）關系模式S-L的碼為Sno這樣非主屬性對碼都是完全函數依賴27定義5.8若R∈1NF，且每一個非主屬性完全函數依賴于鍵，則R∈2NF。第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求實體的非主屬性完全函數依賴于主鍵，不存在非主屬性對主鍵的部分函數依賴5.3.2第二范式S-L-C(Sno,Sdept,Sloc,Cno,G)SC(Sno,Cno,G)S-L(Sno,Sdept,Sloc)282NF總結：

所有非主屬性都完全函數依賴于主鍵，

即：不存在部分函數依賴例：學生成績表（課程號，學號，姓名，成績）是否滿足2NF？為什么？不滿足2NF，因為成績依賴于（課程號，學號）而姓名只依賴于學號，因此存在部分函數依賴29解決辦法：把此關系分解為如下兩個表：

學生：

(學號,姓名)；

選課：

(學號,課程號,成績)

這樣的數據庫表是符合第二范式的30采用投影分解法將一個1NF的關系分解為多個2NF的關系，可以在一定程度上減輕原1NF關系中存在的插入異常、刪除異常、數據冗余度大、修改復雜等問題。但是，將一個1NF關系分解為多個2NF的關系，并不能完全消除關系模式中的各種異常情況和數據冗余。315.3.3第三范式定義5.9若R∈2NF，且每一個非主屬性都不傳遞函數依賴于鍵，則R∈3NF。說明：若R∈3NF，則每一個非主屬性既不部分依賴于鍵也不傳遞依賴于鍵。若R∈3NF，則若R∈2NF； 反之不成立。32【例5-6】2NF關系模式S-L(Sno,Sdept,Sloc)中函數依賴：

由于Sno→Sdept

Sdept→Sloc

可得：，即S-L中存在非主屬性對鍵的傳遞函數依賴，因此33解決方法 采用投影分解法，把S-L分解為兩個關系模式，以消除傳遞函數依賴：

S-D（Sno，Sdept）

D-L（Sdept，Sloc）

其中，S-D的鍵為Sno，D-L的鍵為Sdept。分解后的關系模式S-D與D-L中不再存在傳遞函數依賴34S-D的鍵為Sno，D-L的鍵為Sdept35所謂傳遞函數依賴，指的是如果存在“A→B→C”的決定關系，則C傳遞函數依賴于A。例：關于職工，有如下關系。假定：每個級別對應不同的工資。請問該關系是否屬于3NF？3NF總結：

不存在傳遞函數依賴職工號姓名級別工資001張三技41500002李四技61200傳遞依賴關系：職工號－>級別－>工資36解決辦法：把此關系分解為如下兩個表：

這樣的數據庫表是符合第三范式的職工號姓名級別001張三技4002李四技6級別工資技41500技61200第三范式——消除了非主屬性對鍵的傳遞函數依賴375.3.6規(guī)范化小結關系數據庫的規(guī)范化理論是數據庫邏輯設計的工具。一個關系只要其分量都是不可分的數據項，它就是規(guī)范化的關系，但這只是最基本的規(guī)范化。規(guī)范化程度可以有多個不同的級別。規(guī)范化的目的：盡量消除插入異常、刪除異常，修改復雜、數據冗余基本思想：逐步消除數據依賴中不合適的部分實質：概念的單一化（“一事一地”原則）38關系模式的規(guī)范化過程是通過對關系模式的分解來實現(xiàn)的。把低一級的關系模式分解為若干個高一級的關系模式。說明：這種分解不是唯一的。關系模式規(guī)范化的基本步驟39不能說規(guī)范化程度越高的關系模式就越好在設計數據庫模式結構時，必須對現(xiàn)實世界的實際情況和用戶應用需求作進一步分析，確定一個合適的、能夠反映現(xiàn)實世界的模式上面的規(guī)范化步驟可以在其中任何一步終止40規(guī)范化程度過低的關系不一定能夠很好地描述現(xiàn)實世界，可能會存在插入異常、刪除異常、修改復雜、數據冗余等問題。一個低一級范式的關系模式，通過模式分解（投影）方法可以轉換為若干個高一級范式的關系模式集合，這種過程就叫關系模式的規(guī)范化。規(guī)范化的方式是進行模式分解。415.5模式分解

模式分解：把低一級的關系模式分解為若干個高一級的關系模式。 模式分解的方法并不是唯一的。只有能夠保證分解后的關系模式與原關系模式等價，分解方法才有意義。 三種模式分解“等價”的定義：

1．分解具有無損連接性。（數據的完整性）

2．分解要保持函數依賴。（語義的完整性）

3．分解既要保持函數依賴，又具有無損連接性。42例【5-17】：S-L（Sno，Sdept，Sloc）

F={Sno→Sdept,Sdept→Sloc,Sno→Sloc}S-L∈2NF分解方法可以有多種：1.S-L分解為三個關系模式：

SN(Sno)

SD(Sdept)

SO(Sloc)2.S-L分解為下