資料庫關系規范化

1. 對資料庫模式進行規范化處理是在資料庫設計的什麼階段

邏輯設計階段。

因為開發到後面資料庫用的地方多了，資料庫動一動都是大改。

關系模式的規范化就是根據一個關系屬性間不同的依賴情況來區分其為第一，第二，第三，和第四範式，然後用直觀的描述將具有不合適性質的關系轉換為更合適的形式。

(1)資料庫關系規范化擴展閱讀：

如果關系模式在達到1NF的基礎上，使每個非主屬性都完全依賴於每個關系鍵，則該關系模式達到2NF的要求。

如果關系模式屬於2NF，且每個非主屬性都不傳遞依賴於關系的任何鍵，這該關系模式屬於3NF的要求。

若關系符合1NF，且對於每個函數依賴X→Y，X必含有候選鍵，或者關系中的每個決定屬性集都是候選鍵，則關系達到BCNF的要求。

2. 在資料庫的（） 階段將關系模式進行規范化

是C
在關系資料庫邏輯設計的時候我們要考慮的一個問題就是：如何構造一個適合於某一具體問題的數據模式。這就牽扯到資料庫邏輯設計的工具——關系資料庫的規范化理論。
關系模式的規范化就是根據一個關系屬性間不同的依賴情況來區分其為第一，第二，第三，和第四範式，然後用直觀的描述將具有不合適性質的關系轉換為更合適的形式。

3. 資料庫如何判斷規范化程度

S➡D，D➡M，可以推出S➡M；所以存在傳遞依賴；
第三範式規定不存在函數依賴，所以不滿足第三範式；
屬性不可再分，滿足第一範式；
第一範式基礎上，不存在部分函數依賴，所以滿足第二範式，即2NF；
你可能對部分函數依賴不理解，我解釋一下：S➡D，意味著D依賴於S，也就是S的內容決定著D的內容；如果{A,B}➡M,同時有B➡M，那就有部分函數依賴了，因為{A,B}中的一個子集是B，B是集合中的一部分；這就是部分函數依賴。

4. 資料庫中為什麼要對關系模式進行規范化

關系模式進行規范化的目地：規范化目的是使結構更合理，消除存儲異常，使數據冗餘盡量小，便於插入、刪除和更新
關系模式進行規范化的原則：遵從概念單一化 "一事一地"原則，即一個關系模式描述一個實體或實體間的一種聯系。規范的實質就是概念的單一化。
關系模式進行規范化的方法：將關系模式投影分解成兩個或兩個以上的關系模式。
要求：分解後的關系模式集合應當與原關系模式"等價"，即經過自然聯接可以恢復原關系而不丟失信息，並保持屬性間合理的聯系。
注意：一個關系模式結這分解可以得到不同關系模式集合，也就是說分解方法不是唯一的。最小冗餘的要求必須以分解後的資料庫能夠表達原來資料庫所有信息為前提來實現。其根本目標是節省存儲空間，避免數據不一致性，提高對關系的操作效率，同時滿足應用需求。實際上，並不一定要求全部模式都達到BCNF不可。有時故意保留部分冗餘可能更方便數據查詢。尤其對於那些更新頻度不高，查詢頻度極高的資料庫系統更是如此。

5. 關系資料庫規范化理論的基礎和內容

一個關系資料庫模式由一組關系模式組成，一個關系模式由一組屬性名組成。關系資料庫設計，就是如何把已給定的相互關聯的一組屬性名分組，並把每一組屬性名組成關系的問題。然而，屬性的分組不是唯一的，不同的分組對應著不同的資料庫應用系統，它們的效率往往相差很遠。
為了使資料庫設計合理可靠，簡單實用，長期以來，形成了關系資料庫設計的理論——規范化理論。
6.1 關系規范化的作用
規范化，就是用形式更為簡潔，結構更加規范的關系模式取代原有關系模式的過程。
如果將兩個或兩個以上實體的數據存放在一個表裡，就會出現下列三個問題：
Ø 數據冗餘度大
Ø 插入異常
Ø 刪除異常
所謂數據冗餘，就是相同數據在資料庫中多次重復存放的現象。數據冗餘不僅會浪費存儲空間，而且可能造成數據的不一致性。
插入異常是指，當在不規范的數據表中插入數據時，由於實體完整性約束要求主碼不能為空的限制，而使有用數據無法插入的情況。
刪除異常是指，當不規范的數據表中某條需要刪除的元組中包含有一部分有用數據時，就會出現刪除困難。
（以P98工資表為例）
解決上述三個問題的方法，就是將不規范的關系分解成為多個關系，使得每個關系中只包含一個實體的數據。
（講例子解）
當然，改進後的關系模式也存在另一問題，當查詢職工工資時需要將兩個關系連接後方能查詢，而關系連接的代價也是很大的。
那麼，什麼樣的關系需要分解？分解關系模式的理論依據又是什麼？分解完後能否完全消除上述三個問題？回答這些問題需要理論指導。下面，將加以討論：

6.2 函數依賴

6.2.1屬性間關系

實體間的聯系有兩類：一類是實體與實體之間聯系；另一類是實體內部各屬性間的聯系。資料庫建模一章中討論的是前一類，在這里我們將學習第二類。

和第一類一樣，實體內部各屬性間的聯系也分為1:1、1:n和m:n三類：

例：職工（職工號，姓名，身份證號碼，職稱，部門）

1、 一對一關系（1:1）

設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中至多有一個值與之對應，反之，對於Y中的任一具體值，X中也至多有一個值與之對應，則稱X、Y兩屬性間是一對一關系。

如本例職工關系中職工號與身份證號碼之間就是一對一關系。

2、一對多關系（1:n）

設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中可以找到多個值與之對應，而對於Y中的任一具體值，X中至多隻有一個值與之對應，則稱屬性X對Y是一對多關系。

如職工關系中職工號與職稱之間就是一對多的關系。

3、多對多關系（m:n）

設X、Y是關系R的兩個屬性（集）。如果對於X中的任一具體值，Y中有n個值與之對應，而對於Y中的任一具體值，X中也有m個值與之對應，則稱屬性X對Y是一對多（m:n）關系。

例如，職工關系中，職稱與部門之間就是多對多的關系。

上述屬性間的三種關系，實際上是屬性值之間相互依賴與相互制約的反映，因而稱之為屬性間的數據依賴。

數據依賴共有三種：

Ø 函數依賴（Functional Dependency，FD）

Ø 多值依賴（Multivalued Dependency，MVD）

Ø 連接依賴（Join Dependency，JD）

其中最重要的是函數依賴和多值依賴。

6.2.2 函數依賴

函數依賴，是屬性之間的一種聯系。在關系R中，X、Y為R的兩個屬性或屬性組，如果對於R的所有關系r 都存在：對於X的每一個具體值，Y都只有一個具體值與之對應，則稱屬性Y函數依賴於屬性X。或者說，屬性X函數決定屬性Y，記作X→Y。其中X叫作決定因素，Y叫作被決定因素。

上述定義，可簡言之：如果屬性X的值決定屬性Y的值，那麼屬性Y函數依賴於屬性X。換一種說法：如果知道X的值，就可以獲得Y的值，則可以說X決定Y。

若Y函數不依賴於X，記作：X→Y。

X Y

若X→Y，Y→X，記作：

前面學習的屬性間的三種關系，並不是每種關系中都存在著函數依賴。

u 如果X、Y間是1:1關系，則存在函數依賴 X←→Y

u 如果X、Y間是1:n關系，則存在函數依賴： X→Y或Y→X（多方為決定因素）

u 如果X、Y間是m:n關系，則不存在函數依賴。

注意，屬性間的函數依賴不是指R的某個或某些關系子集滿足上述限定條件，而是指R的一切關系子集都要滿足定義中的限定。只要有一個具體的關系r（R的一個關系子集）不滿足定義中的條件，就破壞了函數依賴，使函數依賴不成立。

這里的關系子集，指的是R的某一部分元組的集合，例如：地測學院的學生關系中只包含了地測學院學生的數據，所以它是長安大學學生關系的一個子集。

6.2.3 碼的定義

前面，我們對碼進行了直觀化的定義，下面用函數依賴的概念對碼作出較為精確的形式化的定義：

設K是關系模式R（U，F）中的屬性或屬性組，K』是K的任一子集。若K→U，而不存在K』→U，則K為R的候選碼（Candidate Key）

Ø 若候選碼多於一個，則選其中的一個為主碼（Primary Key）；

Ø 包含在任一候選碼中的屬性，叫做主屬性（Primary Attribute）；

Ø 不包含在任何碼中的屬性稱為非主屬性（Nonprime Attribute）或非碼屬性（Nonkey Attribute）

Ø 關系模式中，最簡單的情況是單個屬性是碼，稱為單碼（Single Key）；最極端的情況是整個屬性組是碼，稱為全碼（All－Key）。

前面已多次遇到單碼的情況，下面是一個全碼的例子：

簽約（演員名，製片公司，電影名）

外碼：設有兩個關系R和S，X是R的屬性或屬性組，並且X不是R的碼，但X是S的碼（或與S的碼意義相同），則稱X是R的外部碼（Foreign Key），簡稱外碼或外鍵。

如：職工（職工號，姓名，性別，職稱，部門號）

部門（部門號，部門名，電話，負責人）

其中職工關系中的「部門號」就是職工關系的一個外碼。

在此需要注意，在定義中說X不是R的碼，並不是說X不是R的主屬性，X不是碼，但可以是碼的組成屬性，或者是任一候選碼中的一個主屬性。

如：學生（學生號，姓名，性別，年齡…）

課程（課程號，課程名，任課老師…）

選課（學生號，課程號，成績）

在選課關系中，（學生號，課程號）是該關系的碼，學生號、課程號又分別是組成主碼的屬性（但單獨不是碼），它們分別是學生關系和課程關系的主碼，所以是選課關系的兩個外碼。

關系間的聯系，可以通過同時存在於兩個或多個關系中的主碼和外碼的取值來建立。如要查詢某個職工所在部門的情況，只需查詢部門表中的部門號與該職工部門號相同的記錄即可。所以，主碼和外碼提供了一個表示關系間聯系的途徑。

6.2.4 函數依賴和碼的唯一性

由上述碼的形式化定義，我們可以說：碼是由一個或多個屬性組成的，可唯一標識元組的最小屬性組。

碼在關系中總是唯一的，即一個碼函數唯一地決定一行。如果碼的值重復，則整個元組都會重復。否則，違反了實體完整性規則。而元組的重復則表示存在兩個完全相同的實體，這顯然是不可能的，所以碼是不允許重復取值的。

所以，只有當某個屬性或屬性組能夠函數決定關系中的每一個其它的屬性，且該屬性組的任何一個真子集都做不到這一點時，該屬性或屬性組才是該關系的碼。

函數依賴是一個與數據有關的事物規則的概念。如果屬性B函數依賴於屬性A，那麼若知道了A的值，則完全可以找到B的值。這並非是可以由A的值計算出B的值，而是邏輯上只能存在一個B的值。

6.3 關系模式的規范化

一、非規范化的關系

當一個表中存在還可以再分的數據項時，這個表就是非規范化的表。非規范化表存在兩種情況：

Ø 表中具有組合數據項（P102表6-4）

Ø 表中具有多值數據項（P103表6-5）

例：

職工號
姓名
工資

基本工資
職務工資
工齡工資

1002
張三
1000
800
200

職工號
姓名
職稱
系名
系辦地址
學歷
畢業年份

001
張三
教授
計算機
1305
大學

研究生
1963

1982

那麼什麼是規范化關系呢？

當一個關系中的所有分量都是不可再分的數據項時，該關系是規范化的。即當表中不存在組合數據項和多值數據項，只存在不可分的數據項時，這個表是規范化的。

二維表按其規范化程度從低到高可分為5級範式（Normal Form），分別稱為1NF、2NF、3NF（BCNF）、4NF、5NF。規范化程度較高者必是較低者的子集，即：

1NF 2NF 3NF BCNF 4NF 5NF

二、第一範式（1NF）

定義1：如果關系模式R中不包含多值屬性，則R滿足第一範式（First Normal Form），記作：

R∈1NF

1NF是對關系的最低要求，不滿足1NF的關系是非規范化的關系。

非規范化關系轉化為規范化關系1NF方法很簡單，只要上表分別從橫向、縱向展開即可。如下表：

職工號
姓名
基本工資
職務工資
工齡工資

1002
張三
1000
800
200

1005
李四
1200
900
150

職工號
姓名
職稱
系名
系辦地址
學歷
畢業年份

1002
張三
教授
計算機
1305
大學
1963

1002
張三
教授
計算機
1305
研究生
1982

1005
李四
講師
信電
2206
大學
1989

上表雖然符合1NF，但仍是有問題的關系，表中存在大量的數據冗餘和潛在的數據更新異常。原因是（職工號，學歷）是右表的碼，但姓名、職稱、系名、系辦地址卻與學歷無關，只與碼的一部分有關。所以上表還需進一步地規范化。

三、第二範式（2NF）

定義1：設X、Y是關系R的兩個不同的屬性或屬性組，且X → Y。如果存在X的某一個真子集X』，使X』 → Y成立，則稱Y部分函數依賴於X，記作：X P→ Y（Partial）。反之，則稱Y完全函數依賴於X，記作：X F→ Y （Full）

定義2：如果一個關系 R∈1NF，且它的所有非主屬性都完全函數依賴於R的任一候選碼，則R屬於第二範式，記作：R∈2NF。

說明：上述定義中所謂的候選碼也包括主碼，因為碼首先應是候選碼，才可以被指定為碼。

例如關系模式：

職工（職工號，姓名，職稱，項目號，項目名稱，項目角色）中

（職工號，項目號）是該關系的碼，而職工號→姓名、職工號→職稱、項目號→項目名稱…

所以（職工號，項目號）P→ 職稱、（職工號，項目號）P→ 項目名稱

故上述職工關系不符合第二範式要求。它存在三個問題：插入異常、刪除異常和修改異常。

其中修改異常是這樣的，當職工關系中項目名稱發生變化時，由於參與該項目的人員很多，每人一條記錄，要修改項目信息，就得對每一個參加該項目的人員信息進行修改，加大了工作量，還有可能發生遺漏，存在著數據一致性被破壞的可能。

可把上述職工關系分解成如下三個關系：

職工（職工號，姓名，職稱）

參與項目（職工號，項目號，項目角色）

項目（項目號，項目名稱）

上述三個關系都符合定義2的要求，所以都符合2NF

推論：如果關系模式R∈1NF，且它的每一個候選碼都是單碼，則R∈2NF

符合第二範式的關系模式仍可能存在數據冗餘、更新異常等問題。如關系

職工信息（職工號，姓名，職稱，系名，系辦地址）

雖然也符合2NF，但當某個系中有100名職工時，元組中的系辦地址就要重復100次，存在著較高的數據冗餘。原因是關系中，系辦地址不是直接函數依賴於職工號，而是因為職工號函數決定系名，而系名函數決定系辦地址，才使得系辦地址函數依賴於職工號，這種依賴是一個傳遞依賴的過程。

所以，上述職工信息的關系模式還需要進一步的規范化。

四、第三範式（3NF）

定義1：在關系R中，X、Y、Z是R的三個不同的屬性或屬性組，如果X→Y，Y→Z， 但Y→X，且Y不是X的子集，則稱Z傳遞函數依賴於X。

定義2：如果關系模式R∈2NF，且它的每一個非主屬性都不傳遞依賴於任何候選碼，則稱R是第三範式，記作：R∈3NF

推論1：如果關系模式R∈1NF，且它的每一個非主屬性既不部分依賴、也不傳遞依賴於任何候選碼，則R∈3NF

推論2：不存非主屬性的關系模式一定為3NF

五、改進的3NF——BCNF（Boyee－Codd Normal Form）

定義：設關系模式R（U，F）∈1NF，若F的任一函數依賴X→Y（Y X）中X都包含了R的一個碼，則稱R∈BCNF。

換言之，在關系模式R中，如果每一個函數依賴的決定因素都包含碼，則R∈BCNF

推論：如果R∈BCNF，則：

Ø R中所有非主屬性對每一個碼都是完全函數依賴；

Ø R中所有主屬性對每一個不包含它的碼，都是完全函數依賴；

Ø R中沒有任何屬性完全函數依賴於非碼的任何一組屬性。

定理：如果R∈BCNF，則R∈3NF一定成立。

證明：（結合傳遞依賴的定義，用反證法）

注意：當R∈3NF時，R未必屬於BCNF。因為3NF比BCNF放寬了一個限制，它允許決定因素不包含碼。例如：

通訊（城市名，街道名，郵政編碼）中：

F＝｛（城市名，街道名）→郵政編碼，郵政編碼→城市名｝

非主屬性郵政編碼完全函數依賴於碼，且無傳遞依賴，故屬於3NF，但郵政編碼也是一個決定因素，而且它沒有包含碼，所以該關系不屬於BCNF。

又如：

Teaching（Student，Teacher，Course） 簡記為Teaching（S，T，C）

規定：一個教師只能教一門課，每門課程可由多個教師講授；學生一旦選定某門課程，教師就相應地固定。

F＝｛T→C，（S，C）→T,(S，T) →C｝

該關系的候選碼是（S，C）和（S，T），因此，三個屬性都是主屬性，由於不存在非主屬性，該關系一定是3NF。但由於決定因素T沒包含碼，故它不是BCNF。

關系模式Teaching仍然存在著數據冗餘問題，因為存在著主屬性對碼的部分函數依賴問題。

確切地表示：F＝｛T→C，（S，C）P→T,(S，T) P→C｝

所以Teaching關系可以分解為以下兩個BCNF關系模式：

Teacher（Teacher，Course） Student（Student，Teacher）

3NF的「不徹底」性，表現在可能存在主屬性對碼的部分依賴和傳遞依賴。

一個關系模式如果達到了BCNF，那麼，在函數依賴范圍內，它就已經實現了徹底的分離，消除了數據冗餘、插入和刪除異常。
6.4 多值依賴和第四範式

一、多值依賴（Multivalued Dependency）

課程C
教員T
參考書B

物理
李勇
普通物理學

物理
李勇
光學原理

物理
李勇
物理習題集

物理
王軍
普通物理學

物理
王軍
光學原理

物理
王軍
物理習題集

數學
李勇
數學分析

數學
李勇
微分方程

數學
李勇
高等代數

數學
張平
數學分析

數學
張平
微分方程

數學
張平
高等代數

計算數學
張平
數學分析

計算數學
張平
計算數學

計算數學
周峰
數學分析

計算數學
周峰
計算數學

課程C
教員T
參考書B

物理
李勇

王軍
普通物理學

光學原理

物理習題集

數學
李勇

張平
數學分析

微分方程

高等代數

計算數學
張平

周峰
數學分析

計算數學

例：學校中某一門課程由多個教員講授，他們使用相同的一套參考書，每個教員可以講授多門課程，每種參考書可以供多門課程使用。下列是用一個非規范化的表來表示教員T，課程C和參考書B之間的關系。

把上表變換成一張規范化的二維表Teaching，如右表

關系模式Teaching（C，T，B）的碼是（C，T，B），即All－Key。因而Teaching∈BCNF。按照上述語義規定，當某門課程增加一名講課教員時，就要向Teaching表中增加與相應參考書等數目的元組。同樣，某門課程要去掉一本參考書時，則必須刪除相應數目的元組。

對數據的增、刪、改很不方便，數據的冗餘也十分明顯。如果仔細考察這類關系模式，會發現它具有一種稱之為多值依賴的數據依賴關系。

定義：設R（U）是屬性集U上的一個關系模式，X，Y，Z是U的子集，且Z＝U-X-Y。如果對R（U）的任一關系r，給定一對（x，z）值，都有一組y值與之對應，這組y值僅僅決定於x值而與z值無關。則稱Y多值依賴於X，或X多值決定Y，記作：X→→Y。――

例如，在關系模式Teaching中，對於一個（C，B）值（物理，普通物理學），有一組T值｛李勇，王軍｝，而這組值僅僅決定於課程C上的值（物理）。即對於另一個（物理，光學原理），它對應的T值仍然是｛李勇，王軍｝，所以T的值與B的值無關，僅決定於C的值，即C→→T 。

多值依賴的另一個等價的形式化定義為：

設關系模式R（U），X、Y、Z是U的子集，Z＝U-X-Y，r是R的任意一個關系，t1、t2是r的任意兩個元組。如果t1[X]=t2[X]，並在r中存在兩個元組t3、t4，使得：

t3[X]=t4[X]=t1[X]

t3[Y]=t1[Y]，t3[Z]=t2[Z]，

t4[Y]=t2[Y]，t4[Z]=t1[Z]

成立，則X→→Y。

換句話說：如果X→→Y在R（U）中成立，則只要在R的任一關系r中存在兩個元組t1、t2在X屬性上的值相等，則交換這兩個元組在Y（或Z）上的值後得到的兩個新元組t3、t4也必是關系r中的元組。

定義中如果Z＝Ф（空集），則稱X→→Y為平凡的多值依賴，否則為非平凡的多值依賴。

多值依賴具有如下性質：

1. 對稱性：若X→→Y，則X→→Z，其中Z＝U-X-Y

2. 傳遞性：若X→→Y，Y→→Z，則X→→Z-Y

3. 若X→→Y，X→→Z，則X→→YZ

4. 若X→→Y，X→→Z，則X→→Y∩Z

5. 若X→→Y，X→→Z，則X→→Y-Z，X→→Z-Y

多值依賴與函數依賴相比，具有下面兩個基本區別：

（1）多值依賴的有效性與屬性集的范圍有關

若X→→Y在U上成立，則在V（XY V U）上一定成立；反之則不然，即X→→Y在V(V U)上成立，在U上並不一定成立。這是因為多值依賴的定義中不僅涉及屬性組X、Y，而且涉及U中的其餘屬性Z（Z＝U-X-Y）。

一般地說，在R（U）上若有X→→Y在V（V U）上成立，則稱X→→Y為R（U）的嵌入型多值依賴。

而在關系模式R（U）中函數依賴X→Y的有效性，僅決定於X和Y這兩個屬性集的值。只要在R（U）的任何一個關系r中，元組在X和Y上的值使得X→Y成立，則X→Y在任何屬性集V（XY V U）上也成立。

（2）若函數依賴X→Y在R（U）上成立，則對於任何Y』 Y 均有X→Y』 成立。而多值依賴X→→Y若在R（U）上成立，卻不能斷言對於任何Y』 Y有X→→Y』 成立。

多值依賴的約束規則：在具有多值依賴的關系中，如果隨便刪去一個元組，就會破壞其對稱性，那麼，為了保持多值依賴關系中的「多值依賴」性，就必須刪去另外的相關元組以維持其對稱性。這就是多值依賴的約束規則。目前的RDBMS尚不具有維護這種約束的能力，需要程序員在編程中實現。

函數依賴可看成是多值依賴的特例，即函數依賴一定是多值依賴。而多值依賴則不一定就有函數依賴。

二、第四範式（4NF）

定義：如果關系模式R∈1NF，對於R的每個非平凡的多值依賴X→→Y（Y X），X含有碼，則稱R是第四範式，即R∈4NF

課程C
教員T
參考書B

物理
李勇
普通物理學

物理
李勇
光學原理

物理
李勇
物理習題集

物理
王軍
普通物理學

物理
王軍
光學原理

物理
王軍
物理習題集

數學
李勇
數學分析

數學
李勇
微分方程

數學
李勇
高等代數

數學
張平
數學分析

數學
張平
微分方程

數學
張平
高等代數

計算數學
張平
數學分析

計算數學
張平
計算數學

計算數學
周峰
數學分析

計算數學
周峰
計算數學

Teaching關系

關系模式R∈4NF時，R中所有的非平凡多值依賴實際上就是函數依賴。因為每一個決定因素中都含有碼，所以R一定屬於BCNF。

4NF實際上就是限制關系模式的屬性間不允許有非平凡，而且非函數依賴的多值依賴存在。反過來說，4NF所允許的非平凡多值依賴實際上是函數依賴。

例題中的Teaching關系屬於BCNF，但它不屬於4NF。因為它的碼是（C，T，B），關系中存在非平凡多值依賴C→→T ，C→→B，但C不包含碼，而只是碼的一部分。

課程C
參考書B

物理
普通物理學

物理
光學原理

物理
物理習題集

數學
數學分析

數學
微分方程

數學
高等代數

計算數學
數學分析

計算數學
計算數學

CB關系

課程C
教員T

物理
李勇

物理
王軍

數學
李勇

數學
張平

計算數學
張平

計算數學
周峰

CT關系

要使Teaching關系符合4NF，必須將其分解為CT（C，T）和CB（C，B）兩個關系模式。如右表：

從表中顯而易見，符合BCNF的關系Teaching仍然存在著數據冗餘，而分解後的關系CT和CB中只有平凡多值依賴，所以符合4NF，它們已經消除了數據冗餘。可以說：BCNF是在只有函數依賴的關系模式中，規范化程度最高的範式，而4NF是在有多值依賴的關系模式中，規范化程度最高的範式。

如果關系模式中存在連接依賴，即便它符合4NF，仍有可能遇到數據冗餘及更新異常等問題。所以對於達到4NF的關系模式，還需要消除其中可能存在的連接依賴，才可以進一步達到5NF的關系模式。

關於連接依賴和5NF的內容，已超出了本課程教學大綱的要求，在此不再介紹。

6. 說明在關系資料庫設計中為什麼進行關系的規范化

進行資料庫關系規范化原因：
規范的資料庫關系可以有效的減少數據冗餘量
規范的資料庫關系可以提高查詢的效率，特別是在多表查詢時。
規范的資料庫關系可以是程序設計更加合理，有效

7. 關系資料庫的規范化理論是為了解決什麼問題

關系資料庫邏輯設計的好壞與其所含的各個關系模式設計的好壞相關。如果各個關系模式結構合理、功能簡單明確、規范化程度高，就能確保所建立的資料庫具有較少的數據冗餘、較高的數據共享度、較好的數據一致性，並為資料庫系統能夠很好的應用於實際打下良好的基礎。
因此，關系的規范化理論就是為解決數據冗餘、刪除異常和插入異常等問題而提出來的。

8. 理解什麼是資料庫規范化

理解資料庫規范化的意義
【TechTarget中國原創】資料庫規范化是由Edgar Frank Codd提出的，他是IBM公司的一位計算機科學家，他在自己的論文《20世紀70年代大型共享數據銀行數據關系模型》中首次提出這種說法。資料庫規范化是一個過程，這個過程中需要對現存表結構進行修改，把表轉化使遵循一系列先進的範式。
它著重於消除開發人員和他們項目的「電子表格綜合症」。電子表格綜合症是指開發人員傾向於在盡可能少的表中擠下盡可能多的信息。
早些時候，由於受電子表格的概念以及在電子表格中管理數據思路的影響，開發人員們一直採用與涉及電子表格相同的思路設計MySQL資料庫。現在，再用這種方法設計MySQL資料庫被認為是不明智的做法，因為這種電子表格綜合症設計的表在每次資料庫有很小的改變時，都要持續不斷地進行重新設計。
在MySQL中實現資料庫規范化的好處
通過智能數據分類，降低存儲空間使用量是對MySQL實現資料庫規范化的眾多好處之一。它幫助實現了更好，更快，更強的搜索功能，因為它與早期基於混合實體的搜索方式相比，需要掃描更少的實體。通過資料庫規范化，數據完整性也得以改善，因為它把所有數據分成單獨的實體，並用關聯數據在實體間建立強連接。
Mike Hillyer是之前MySQL AB的一位技術作家，他解釋說：「資料庫規范化的目標是確保每個表中所有非鍵列都直接依賴於主鍵：整個都是鍵，除了鍵沒有其它。有了這個目標，隨之而來還有一些好處，我們降低了冗餘，減少了異常，提高了效率。」
數據規范化很容易做到
下面的例子將說明資料庫規范化如何幫助實現MySQL中的良好設計。下面的表展示了需要在資料庫中捕獲的數據。
Chad Russell is a programmer and system administrator who owns his own internet hosting company. Jon Stephens is a member of the MySQL AB documentation team.
在上面展示的例子中，如果任意一個條件作為識別主鍵的話，會有大量的存儲空間被浪費掉。因此，資料庫規范化是必不可少的。這是一個循序漸進的過程，不能隨意進行。下面的步驟可以幫你在MySQL中實現資料庫規范化。轉載僅供參考，版權屬於原作者。祝你愉快，滿意請採納哦

9. 資料庫的規范化設計方法～

第一範式（1NF）：資料庫表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字元型、邏輯型、日期型等。

例如，如下的資料庫表是符合第一範式的：

欄位1 欄位2 欄位3 欄位4

而這樣的資料庫表是不符合第一範式的：

欄位1 欄位2 欄位3 欄位4
欄位3.1 欄位3.2

很顯然，在當前的任何關系資料庫管理系統（DBMS）中，傻瓜也不可能做出不符合第一範式的資料庫，因為這些DBMS不允許你把資料庫表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一範式的資料庫都是不可能的。

第二範式（2NF）：資料庫表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。

假定選課關系表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：

(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)

這個資料庫表不滿足第二範式，因為存在如下決定關系：

(課程名稱) → (學分)

(學號) → (姓名, 年齡)

即存在組合關鍵字中的欄位決定非關鍵字的情況。

由於不符合2NF，這個選課關系表會存在如下問題：

(1) 數據冗餘：

同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。

(2) 更新異常：

若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。

(3) 插入異常：

假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫。

(4) 刪除異常：

假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。

把選課關系表SelectCourse改為如下三個表：

學生：Student(學號, 姓名, 年齡)；

課程：Course(課程名稱, 學分)；

選課關系：SelectCourse(學號, 課程名稱, 成績)。

這樣的資料庫表是符合第二範式的， 消除了數據冗餘、更新異常、插入異常和刪除異常。

另外，所有單關鍵字的資料庫表都符合第二範式，因為不可能存在組合關鍵字。

第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴於A。因此，滿足第三範式的資料庫表應該不存在如下依賴關系：

關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y

假定學生關系表為Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：

(學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話)

這個資料庫是符合2NF的，但是不符合3NF，因為存在如下決定關系：

(學號) → (所在學院) → (學院地點, 學院電話)

即存在非關鍵欄位"學院地點"、"學院電話"對關鍵欄位"學號"的傳遞函數依賴。

它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。

把學生關系表分為如下兩個表：

學生：(學號, 姓名, 年齡, 所在學院)；

學院：(學院, 地點, 電話)。

這樣的資料庫表是符合第三範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。

鮑依斯-科得範式（BCNF）：在第三範式的基礎上，資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。

假設倉庫管理關系表為StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個資料庫表中存在如下決定關系：

(倉庫ID, 存儲物品ID) →(管理員ID, 數量)

(管理員ID, 存儲物品ID) → (倉庫ID, 數量)

所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵欄位為數量，它是符合第三範式的。但是，由於存在如下決定關系：

(倉庫ID) → (管理員ID)

(管理員ID) → (倉庫ID)

即存在關鍵欄位決定關鍵欄位的情況，所以其不符合BCNF範式。它會出現如下異常情況：

(1) 刪除異常：

當倉庫被清空後，所有"存儲物品ID"和"數量"信息被刪除的同時，"倉庫ID"和"管理員ID"信息也被刪除了。

(2) 插入異常：

當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。

(3) 更新異常：

如果倉庫換了管理員，則表中所有行的管理員ID都要修改。

把倉庫管理關系表分解為二個關系表：

倉庫管理：StorehouseManage(倉庫ID, 管理員ID)；

倉庫：Storehouse(倉庫ID, 存儲物品ID, 數量)。

這樣的資料庫表是符合BCNF範式的，消除了刪除異常、插入異常和更新異常。

範式應用

我們來逐步搞定一個論壇的資料庫，有如下信息：

（1） 用戶：用戶名，email，主頁，電話，聯系地址

（2） 帖子：發帖標題，發帖內容，回復標題，回復內容

第一次我們將資料庫設計為僅僅存在表：

用戶名 email 主頁 電話 聯系地址 發帖標題 發帖內容 回復標題 回復內容

這個資料庫表符合第一範式，但是沒有任何一組候選關鍵字能決定資料庫表的整行，唯一的關鍵欄位用戶名也不能完全決定整個元組。我們需要增加"發帖ID"、"回復ID"欄位，即將表修改為：

用戶名 email 主頁 電話 聯系地址 發帖ID 發帖標題 發帖內容 回復ID 回復標題 回復內容

這樣數據表中的關鍵字(用戶名，發帖ID，回復ID)能決定整行：

(用戶名,發帖ID,回復ID) → (email,主頁,電話,聯系地址,發帖標題,發帖內容,回復標題,回復內容)

10. 什麼是資料庫中的規范化

規范化理論把關系應滿足的規范要求分為幾級，滿足最低要求的一級叫做第一範式(1NF)，在第一範式的基礎上提出了第二範式(2NF)，在第二範式的基礎上又提出了第三範式(3NF)，以後又提出了BCNF範式，4NF，5NF。範式的等級越高，應滿足的約束集條件也越嚴格。

第一範式（1NF）
在關系模式R中中，如果每個屬性值都是不可再分的原子屬性，則稱R是第一範式的關系[2]。例如：關系R（職工號，姓名，電話號碼）中一個人可能有一個辦公室電話和一個住宅電話號碼，規范成為1NF的方法一般是將電話號碼分為單位電話和住宅電話兩個屬性，即 R（職工號，姓名，辦公電話，住宅電話）。1NF是關系模式的最低要求。

第二範式（2NF）
如果關系模式R是1NF且其中的所有非主屬性都完全函數依賴於關鍵字，則稱關系R 是屬於第二範式的[2]。例：選課關系 SC（SNO，CNO，GRADE，CREDIT）其中SNO為學號， CNO為課程號，GRADEGE 為成績，CREDIT 為學分。 由以上條件，關鍵字為組合關鍵字（SNO，CNO）。在應用中使用以上關系模式有以下問題： （1）數據冗餘，假設同一門課由40個學生選修，學分就重復40次；（2）更新復雜，若調整了某課程的學分，相應元組的CREDIT值都要更新，有可能會出現同一門課學分不同；（3）插入異常，如計劃開新課，由於沒人選修，沒有學號關鍵字，只能等有人選修才能把課程和學分存入；（4）.刪除異常，若學生已經結業，從當前資料庫刪除選修記錄，而某些課程新生尚未選修，則此門課程及學分記錄無法保存。以上問題產生的原因是非主屬性CREDIT僅函數依賴於CNO，也就是CREDIT部分依賴組合關鍵字（SNO，CNO）而不是完全依賴。解決方法是將以上關系分解成兩個關系模式 SC（SNO，CNO，GRADE）和C（CNO，CREDIT）。新關系包括兩個關系模式，它們之間通過SC中的外鍵CNO相聯系，需要時再進行自然聯接，恢復原來的關系

第三範式（3NF）
如果關系模式R是2NF且其中的所有非主屬性都不傳遞依賴於碼，則稱關系R是屬於第三範式的[1]。例如關系模式S（SNO，SNAME，DNO，DNAME，LOCATION）中各屬性分別代表學號、姓名、所在系、系名稱、系地址。關鍵字SNO決定各個屬性。由於是單個關鍵字，沒有部分依賴的問題，肯定是2NF。但關系S肯定有大量的冗餘，有關學生所在系的幾個屬性DNO，DNAME，LOCATION將重復存儲，插入、刪除和修改時也將產生類似以上例的情況。原因在於關系中存在傳遞依賴，即SNO -> DNO，DNO -> LOCATION, 因此關鍵字SNO對LOCATION函數決定是通過傳遞依賴SNO -> LOCATION 實現的。也就是說，SNO不直接決定非主屬性LOCATION。解決方法是將該關系模式分解為兩個關系S（SNO，SNAME，DNO）和D（DNO，DNAME，LOCATION），兩個關系通過S中的外鍵DNO聯系。

BC範式(BCNF)
如果關系模式R的所有屬性（包括主屬性和非主屬性）都不傳遞依賴於R的任何候選關鍵字，那麼稱關系R是屬於BCNF的。或者說關系模式R中，如果每個決定因素都包含關鍵字（而不是被關鍵字所包含），則R是BCNF[3]。 通常認為BCNF是修正的第三範式，有時也稱為擴充的第三範式。