數據庫的范式，第一、二、三、四、五范式、BC范式

數據庫的規范化（上一篇博客有寫到）的程度不同，便有了這么多種范式。數據庫范式是數據庫設計必不可少的知識，沒有對范式的理解，就無法設計出高效率、優雅的數據庫，甚至設計出錯誤誤的數據庫。課本中的定義比較抽象，不太直觀，也不易理解，記是肯定記不住的。

關系數據庫

常用范式

關系數據庫知道了，再來理解范式。范式是關系數據庫關系模式規范化的標准，從規范化的寬松到嚴格，分為不同的范式，通常使用的有第一范式。第二范式、第三范式及BC范式。范式是建立在函數依賴基礎上的。

函數依賴

如果一個表中某一個字段Y的值是由另外一個字段或一組字段X的值來確定的，就稱為Y函數依賴於X。

 

函數依賴

定義

設X,Y是關系R的兩個屬性集合，當任何時刻R中的任意兩個元組中的X屬性值相同時，則它們的Y屬性值也相同，則稱X函數決定Y，或Y函數依賴於X。

3.平凡函數依賴

當關系中屬性集合Y是屬性集合X的子集時(Y⊆X)，存在函數依賴X→Y，即一組屬性函數決定它的所有子集，這種函數依賴稱為平凡函數依賴。

4.非平凡函數依賴

當關系中屬性集合Y不是屬性集合X的子集時，存在函數依賴X→Y，則稱這種函數依賴為非平凡函數依賴。

5.完全函數依賴

設X,Y是關系R的兩個屬性集合，X’是X的真子集，存在X→Y，但對每一個X’都有X’!→Y，則稱Y完全函數依賴於X。

6.部分函數依賴

設X,Y是關系R的兩個屬性集合，存在X→Y，若X’是X的真子集，存在X’→Y，則稱Y部分函數依賴於X。

7.傳遞函數依賴

設X,Y,Z是關系R中互不相同的屬性集合，存在X→Y(Y !→X),Y→Z，則稱Z傳遞函數依賴於X。

屬性關系

屬性之間有三種關系，但並不是每一種關系都存在函數依賴。設R(U)是屬性集U上的關系模式，X、Y是U的子集：

● 如果X和Y之間是1：1關系（一對一關系），如學校和校長之間就是1:1關系，則存在函數依賴X → Y和Y →X。

● 如果X和Y之間是1：n關系（一對多關系），如年齡和姓名之間就是1:n關系，則存在函數依賴Y → X。

●如果X和Y之間是m：n關系（多對多關系），如學生和課程之間就是m:n關系，則X和Y之間不存在函數依賴。

案例分析

編輯

例: Student(Sno, Sname, Ssex, Sage, Sdept)

假設不允許重名，則有:

Sno → Ssex， Sno → Sage , Sno → Sdept，

Sno ←→ Sname, Sname → Ssex， Sname → Sage

Sname → Sdept

但Ssex －\→ Sage

若 X → Y，並且 Y → X, 則記為 X ←→ Y。

若 Y 不函數依賴於 X, 則記為 X －\→ Y。

在關系模式R(U)中，對於U的子集X和Y，

1.如果 X → Y，但 Y 不為 X 的子集，則稱 X → Y 是非平凡的函數依賴

例：在關系SC(Sno, Cno, Grade)中，

非平凡函數依賴： (Sno, Cno) → Grade。

2.若 X → Y，但 Y 為 X 的子集, 則稱 X → Y 是平凡的函數依賴

平凡函數依賴： (Sno, Cno) → Sno ，(Sno, Cno) → Cno。

 

3.若 x → y 並且，存在 x 的真子集 x1，使得 x1 → y, 則 y 部分依賴於 x。

例：學生表（學號，姓名，性別，班級，年齡）關系中，

部分函數依賴：（學號，姓名）→ 性別，學號 → 性別，所以（學號，姓名）→ 性別 是部分函數依賴。

4.若 x → y 並且，對於 x 的任何一個真子集 x1，都不存在 x1 → y 則稱y完全依賴於x。

例：成績表（學號，課程號，成績）關系中，

完全函數依賴：（學號，課程號）→ 成績，學號 －\→ 成績，課程號 －\→ 成績，所以（學號，課程號）→ 成績 是完全函數依賴。

5.若x → y並且y → z，而y －\→ x，則有x → z，稱這種函數依賴為傳遞函數依賴。

例：關系S1（學號，系名，系主任），

學號 → 系名，系名 → 系主任，並且系名 －\→ 學號，系主任 －\→ 系名，所以學號 → 系主任為傳遞函數依賴。

具體的函數依賴應該是通過理解數據項和該企業的內部規則來決定的（不同企業間有差異），根據表的內容得出的函數依賴可能是不正確的。

范式間的關系

關系數據庫有六種，一、二、三、四、五和BC。滿足最低要求的范式是第一范式。在第一范式的基礎上進一步滿足更多要求的稱為第二范式，其余范式以此類推。一般情況的數據庫只需滿足第三范式即可。

1NF

如果關系模式R是第一范式的模式，那么，R的每一個關系r的屬性都是原子項，不可分割。

1NF是關系模式應具備的最起碼的條件，如果數據庫設計不能滿足第一范式，就不能稱為關系型數據庫。關系數據庫設計研究的關系規范化是在1NF之上進行的。

2NF

如果關系模式R是1NF，且每一個非主屬性完全依賴於候選建，那么就稱R是第二范式。

第二范式要滿足的條件：首先要滿足第一范式， 其次每一個非主屬性要完全函數依賴於候選鍵，或者是主鍵。也就是說，每個非主屬性是由整個主鍵函數決定的，而不能有主鍵的一部分來決定。

第二范式（2NF）：符合1NF，並且，非主屬性完全依賴於碼。（一個候選碼中的主屬性也可能是好幾個。如果一個主屬性，它不能單獨做為一個候選碼，那么它也不能確定任何一個非主屬性。

什么樣的實例不符合第二范式？

舉一個教務管理系統的例子。

學生上課指定一個老師，一本教材，一個教室，一個時間，學生去上課，怎么設計數據庫？

有如下關系成立：

（學生，課程）——>教室；

（學生，課程）——>老師；

（學生，課程）——>老師職稱；

（學生，課程）——>教材；

（學生，課程）——>上課時間；

可以得出（學生，課程）是一個碼。

又： 課程——>教材；

 

• （學生，課程）是一個碼，課程卻決定了教材，這就叫做不完全依賴，或者說部分依賴。

 

出現了這種情況，就不滿足第二范式了。

解決辦法：分解。進行投影分解：

3NF

如果關系模式R是2NF，且關系模式R（U,F）中的 所有非主屬性對任何候選關鍵字都不存在傳遞依賴，則稱關系R是屬於第三范式。

第三范式（3NF）；符合2NF，並且，消除傳遞依賴。

上圖中符合2NF ，但存在傳遞依賴（老師——>老師職稱。一個老師一定能確定一個老師職稱）。

解決辦法：分解。投影分解：

其他范式

第四范式：要求把同一表內的多對多關系刪除。

第五范式：從最終結構重新建立原始結構。

BC范式（BCNF）：符合3NF，並且，主屬性不依賴於主屬性。若關系模式R屬於第一范式，且每個屬性都不傳遞依賴於鍵碼，則R屬於BC范式。