關系模式的范式

????主要有4種范式，1NF，2NF，3NF，BCNF，按從左至右的順序一種比一種要求更嚴格。要符合某一種范式必須也滿足它前邊的所有范式。一般項目的數據庫設計達到3NF就可以了，而且可根據具體情況適當增加冗余，不必教條地遵守所謂規范。

簡單而言，1NF就是要求一張表里只放相互關聯的字段，一個字段里只放一條信息，這只是最基本的要求。至于2NF，3NF，BCNF雖然描述的內容不同，但表現在數據特點上很相似，就好比在說不要為了向某廠訂購一批貨記下來，就把的廠的面積、電話等都放在同一張表里，而應該用兩張表，以盡量避免浪費數據存儲空間。因為和同一個廠可能會交易好幾次，但沒必要每次交易都記錄全部的信息。

從范式所允許的函數依賴方面進行比較，四種范式之間的關聯如下圖所示。

?

?

以下對每種范式作一一說明。

2.3.4.2??第一范式

在關系模式R中的每一個具體關系r中，如果每個屬性值 都是不可再分的最小數據單位，則稱R是第一范式的關系。

例：如職工號，姓名，電話號碼組成一個表（一個人可能有一個辦公室電話 和一個家里電話號碼） 規范成為1NF有三種方法：
一是重復存儲職工號和姓名。這樣，關鍵字只能是電話號碼。
二是職工號為關鍵字，電話號碼分為單位電話和住宅電話兩個屬性
三是職工號為關鍵字，但強制每條記錄只能有一個電話號碼。
以上三個方法，第一種方法最不可取，按實際情況選取后兩種情況。

2.3.4.3??第二范式

關系的第二范式(2NF)定義： 如果關系模式R為1NF，并且R中的每一個非主屬性都完全依賴于R的某個候選關鍵字，則稱R是第二范式的，簡記為2NF。

【例2.40】 設有關系模式R(學號S#,課程號C#,成績G,任課教師TN,教師專長TS)，基于R的函數依賴集F={(S#,C#)→G,C#→TN,TN→TS},判斷R是否為2NF。

解：

(1) 容易看出，關系模式R是1NF。因為R符合關系的定義，R的所有屬性值都是不可再分的原子值。

R是否為2NF，應根據2NF的定義來判斷。??????????????????????????????????????????

首先要確定關系模式R中各屬性間的函數依賴情況。如果沒有直接給出R的函數依賴集，就要按照語義把它確定下來。在本例中，已直接給出基于R的函數依賴集F，我們可使用阿氏推理規則并結合下面介紹的方法，進一步確定R中哪些是主屬性、哪些是非主屬性、侯選關鍵字由哪些屬性構成。

方法①??寫出函數依賴集F中的各個函數依賴以幫助分析。方法①的特點是直接。

F={(S#,C#)→G，

C#→TN，

TN→TS

}

????方法②??用有向圖表示屬性間函數依賴，結點表示屬性，方框包含若干個結點表示屬性組合，有向箭頭表示函數依賴。本例的函數依賴圖如圖2.9所示。方法②的特點是直觀。

?

圖2.9 函數依賴圖例子

????方法③??把關系模式R與函數依賴集F結合起來，屬性組合用下劃線(或上劃線)表示，函數依賴用有向箭頭表示。本例的函數依賴簡圖如圖2.10所示。方法③的特點是簡單。

?

圖2.10函數依賴簡圖例子

????用阿氏推理規則由F可推出：(S#,C#)→{S#,C#,G,TN,TS}，即屬性組合(S#,C#)是R的候選關鍵字(R只有這一個候選鍵)。(S#,C#)的一個值可惟一標識R中的一個元組(并且沒有多余的屬性)。

在R中，S#,C#是主屬性；其余的屬性G,TN,TS為非主屬性。

借助上面的圖，我們可以看到，非主屬性G對鍵是完全依賴：(S#,C#)→G。但非主屬性TN,TS對鍵是部分依賴(他們僅依賴于鍵的真子集C#)。由于R中存在非主屬性對候選鍵的部分依賴，所以關系模式R不是2NF。

R中存在非主屬性對候選鍵的部分依賴，將會引起數據冗余、數據操作異常等問題?？梢园殃P系R無損聯接地分解成兩個2NF的關系模式：

ρ={R₁,R₂}，R₁={S#.C#,G},R₂={C#,TN,TS}。

【例2.41】選課關系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO為學號， CNO為課程號，GRADEGE 為成績，CREDIT 為學分。

由以上條件，關鍵字為組合關鍵字（SNO，CNO）
在應用中使用以上關系模式有以下問題：
a.數據冗余，假設同一門課由40個學生選修，學分就 重復40次。
b.更新異常，若調整了某課程的學分，相應的元組CREDIT值都要更新，有可能會出現同一門課學分不同。
c.插入異常，如計劃開新課，由于沒人選修，沒有學號關鍵字，只能等有人選修才能把課程和學分存入。
d.刪除異常，若學生已經結業，從當前數據庫刪除選修記錄,就會可能連課程號及學分完全從數據庫中刪除，則此門課程及學分記錄無法保存。
原因：非關鍵字屬性CREDIT僅函數依賴于CNO，也就是CREDIT部分依賴組合關鍵字（SNO，CNO）而不是完全依賴。
解決方法：分成兩個關系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新關系包括兩個關系模式，它們之間通過SC1中的外關鍵字CNO相聯系，需要時再進行自然聯接，恢復了原來的關系

?

2.3.4.4??第三范式

關系的第三范式(3NF)定義： 如果關系模式R為2NF，并且R中的每一個非主屬性都不傳遞依賴于R的某個候選關鍵字，則稱R是第三范式的，簡記為3NF。

【例2.42】續上例2.40（R(學號S#,課程號C#,成績G,任課教師TN,教師專長TS)），判斷關系模式R₁={S#.C#,G},R₂={C#,TN,TS} 是否為3NF。

解：

(1) 在關系模式R₁={S#,C#,G}，候選關鍵字是(S#,C#)，主屬性是S#,C#，非主屬性是G，函數依賴為(S#,C#)→G。??由于R₁中不存在非主屬性對候選關鍵字的傳遞依賴，所以關系模式R₁是3NF。

(2) 在關系模式R₂={C#,TN,TS}，候選關鍵字是C#，主屬性是C#，非主屬性是TN,TS，函數依賴為C#→TN，TN→TS。由于R₂中存在非主屬性對候選關鍵字的傳遞依賴C#TS，所以關系模式R₂不是3NF。

可以把關系R₂無損聯接地分解成兩個3NF的關系模式：

ρ={R₃,R₄}，R₃={C#,TN},R₄={TN,TS}。

【例2.43】如（SNO，SNAME，DNO，DNAME，LOCATION） 各屬性分別代表學號，
姓名，所在系，系名稱，系地址。 判斷關系模式S1是否為3NF。

關鍵字SNO決定各個屬性。由于是單個關鍵字，沒有部分依賴的問題，是2NF。

但這關系有大量的冗余，有關學生所在的幾個屬性DNO，DNAME，LOCATION將重復存儲，插入，刪除和修改時也將產生類似以上例的情況。
原因：關系中存在傳遞依賴造成的。關鍵字 SNO 對 LOCATION 函數決定是通過傳遞依賴:SNO -> DNO，及DNO -> LOCATION實現的。也就是說，SNO不直接決定非主屬性LOCATION，不是3NF。
解決目地：每個關系模式中不能留有傳遞依賴。
解決方法：分為兩個關系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：關系S中不能沒有外關鍵字DNO。否則兩個關系之間失去聯系。

2.3.4.5?? Boyce-Codd范式

關系的Boyce-Codd范式(BCNF)定義： 如果關系模式R為1NF，并且R中的每一個函數依賴X→Y(Y?X),必有X是R的超關鍵字，則稱R是Boyce-Codd范式的，簡記為BCNF。

從BCNF的定義中，可以明顯地得出如下結論：

(1) 所有非主屬性對鍵是完全函數依賴；

(2) 所有主屬性對不包含它的鍵是完全函數依賴；

(3)沒有屬性完全函數依賴于非鍵的任何屬性組合。

與2NF,3NF的定義不同，BCNF的定義直接建立在1NF的基礎上。但實質上BCNF是3NF的改進形式。3NF僅考慮了非主屬性對鍵的依賴情況，BCNF把主屬性對鍵的依賴情況也包括進去。BCNF要求滿足的條件比3NF所要求的更高。如果關系模式R是BCNF的，那么R必定是3NF，反之，則不一定成立。

【例2.43】 續前例2.42（學號S#,課程號C#,成績G,任課教師TN,教師專長TS）,判斷兩個3NF關系模式R₃={C#,TN},R₄={TN,TS}是否為BCNF。

解：在關系模式R₃中有函數依賴C#→TN，決定因素C#是R₃的鍵；

在關系模式R₄中有函數依賴TN→TS，決定因素TN是R₄的鍵；

???? R₃,R₄都滿足BCNF的定義，所以，這兩個關系模式都是BCNF。

【例2.44】配件管理關系模式 WPE（WNO，PNO，ENO，QNT）分別表倉庫號，配件號，職工號，數量。有以下條件
a.一個倉庫有多個職工。
b.一個職工僅在一個倉庫工作。
c.每個倉庫里一種型號的配件由專人負責，但一個人可以管理幾種配件。
d.同一種型號的配件可以分放在幾個倉庫中。
分析：由以上得 PNO 不能確定QNT，由組合屬性（WNO，PNO）來決定，存在函數依賴（WNO，PNO） -> ENO。由于每個倉庫里的一種配件由專人負責，而一個人可以管理幾種配件，所以有組合屬性（WNO，PNO）才能確定負責人，有（WNO，PNO）-> ENO。因為 一個職工僅在一個倉庫工作，有ENO -> WNO。由于每個倉庫里的一種配件由專人負責，而一個職工僅在一個倉庫工作，有 （ENO，PNO）-> QNT。
找一下候選關鍵字，因為（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此 （WNO，PNO）可以決定整個元組，是一個候選關鍵字。根據ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能決定整個元組，為另一個候選關鍵字。屬性ENO，WNO，PNO 均為主屬性，只有一個非主屬性QNT。它對任何一個候選關鍵字都是完全函數依賴的，并且是直接依賴，所以該關系模式是3NF。
分析一下主屬性。因為ENO->WNO，主屬性ENO是WNO的決定因素，但是它本身不是關鍵字，只是組合關鍵字的一部分。這就造成主屬性WNO對另外一個候選關鍵字（ENO，PNO）的部 分依賴，因為（ENO，PNO）-> ENO但反過來不成立，而P->WNO，故（ENO，PNO）-> WNO 也是傳遞依賴。
雖然沒有非主屬性對候選關鍵遼的傳遞依賴，但存在主屬性對候選關鍵字的傳遞依賴，同樣也會帶來麻煩。如一個新職工分配到倉庫工作，但暫時處于實習階段，沒有獨立負責對某些配件的管理任務。由于缺少關鍵字的一部分PNO而無法插入到該關系中去。又如某個人改成不管配件了去負責安全，則在刪除配件的同時該職工也會被刪除。
解決辦法：分成管理EP（ENO，PNO，QNT），關鍵字是（ENO，PNO）工作EW（ENO，WNO）其關鍵字是ENO
缺點：分解后函數依賴的保持性較差。如此例中，由于分解,函數依賴（WNO，PNO）-> ENO 丟失了, 因而對原來的語義有所破壞。沒有體現出每個倉庫里一種部件由專人負責。有可能出現 一部件由兩個人或兩個以上的人來同時管理。因此，分解之后的關系模式降低了部分完整性約束。

轉載于:https://www.cnblogs.com/BensonHe/articles/1872241.html

總結

以上是生活随笔為你收集整理的转：数据库关系模式的范式详解的全部內容，希望文章能夠幫你解決所遇到的問題。

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