由於在寫項目時與同伴關於數據庫到底建多少張表，每張表應包含哪些屬性產生分歧，因此又好好研究了一下關係型數據庫在設計時應該遵照怎樣的規則以提升數據庫性能。web
在閱讀本篇文章前讀者須掌握關係數據庫結構基礎及函數依賴與鍵的定義。
可直戳如下目錄空降相關知識點↓↓↓數據庫
首先咱們給出一張數據表，該表涵蓋咱們所要記錄的全部屬性
該關係模式爲：
SLC（Sno,Sname,Sdept（所在系），Loca（住處），Cno（課程號），Grade（成績））
Sno | Sname |Sdept|Loca|Cno|Grade
-------- | —
03001 | 甲|網絡工程|A|C1|95
03001 | 甲|網絡工程|A|C2|88
04001 | 乙|計算機科學與技術|B|C2|93
04001 | 乙|計算機科學與技術|B|C4|75
03002 | 丙|網絡工程|A|C1|77
02001 | 丁|網絡工程|A|C5|82
02002 | 戊|計算機科學與技術|B|C2|87網絡
若是關係模式R中的全部屬性都是不可分的數據項，則稱R屬於第一範式，記爲R∈1NF。svg
對數據表進行分析，可知其每一個屬性都不可再分，既知足1NF，但因爲只有屬性Grade對鍵(Sno,Cno)是徹底函數依賴，而其餘非主屬性都是對鍵的部分函數依賴，也正是由於關係中存在部分函數依賴，致使數據操做中必然會存在異常，故須要運用投影運算將關係模式SLC進行分解，轉向更高一級範式。函數
若關係模式R∈1NF，且每一個非主屬性都徹底依賴於R的鍵，則R∈2NF。性能
關係SLC中，Sno、Cno爲主屬性，Sname，Sdept，Loca，Grade均爲非主屬性，Grade對鍵是徹底函數依賴，其他非主屬性對鍵均爲部分函數依賴，因此SLC∉2NF。
爲消除關係模式SLC中的部分函數依賴，咱們採用投影分解法，將部分函數依賴從SLC中分解出來，獲得如下兩個關係模式：
SC:（Sno，Cno）->[f]Grade
SL:（Sno->[f]Sname, Sno->[f]Sdept, Sno->[f]Loca）
分解後關係模式SC和SL的非主屬性對鍵都是徹底函數依賴，因此SC∈2NF，SL∈2NF。編碼
知足2NF後咱們再分析對數據進行操做時可能出現的異常問題是否獲得有效解決：
①插入異常：
【已解決】若學生未選課，仍能將相關信息插入表SL中。
【未解決】若某系還未進行招生，即Sno爲空時，該系相關信息沒法插入。
②刪除異常：
【已解決】即便刪除SC表中某個學生的所有選課信息，但表SL中仍有其其他信息存在。
【未解決】若某系全部學生畢業，刪除所有學生信息的同時，該系的相關信息也被刪除了。
③更新異常：
【已解決】由於學生的選課信息與基本信息分別存儲在兩張表中，基本信息在SL表中只保存了一次，因此當學生的基本信息（如姓名）產生變化時，Sname的值只須要修改一次，減小了數據冗雜。
【未解決】若某系更名，則要對每一個學生記錄中的Sdept進行修改。
④數據冗雜
【未解決】一個系中有多個學生，對每一個學生記錄，相關的Sdept和Loca都要儲存一次。設計
所以SL仍不是一個好的關係模式，須要對其進行進一步分解，轉化爲更高一級的範式。xml
對於關係模式R，每個非主屬性鍵既不部分函數依賴於鍵，也不傳遞函數依賴於鍵，則R∈3NF。資源
關係模式SC中非主屬性Grade既不部分函數依賴於鍵，也不傳遞函數依賴於鍵，因此SC∈3NF，但在關係模式SL中，因爲Sno->Sdept, Sdept->Loca, Sdept-(×)>Sno,因此Sno->[t]Loca，因此SL∉3NF。所以仍要對SL進行投影分解，獲得如下兩個關係模式
S（Sno,Sname,Sdept）
L（Sdept,Loca）
如今關係模式S和L中既不存在部分函數依賴，也不存在傳遞函數依賴，因此S∈3NF，L∈3NF。
一般狀況下，數據庫的設計知足3NF即已達到標準，此時全部異常問題都能獲得解決，但因爲3NF只是規定了非主屬性對鍵的依賴關係，沒有限制主屬性對鍵的依賴關係，若存在主屬性對鍵的部分函數依賴和傳遞函數依賴關係，一樣會出現數據冗雜，插入異常，更新異常，刪除異常等問題，所以咱們引入BC範式。
關係模式R∈1NF，若X->Y，且Y∉X時X必爲鍵（），則R屬於BCNF。即在關係模式R中，若每個決定因素都爲鍵，則R必定屬於BCNF。
對於知足BCNF的關係模式，具備如下性質：
①全部非主屬性都徹底函數依賴於每一個候選鍵。
②全部主屬性都徹底函數依賴於每一個不包含它的鍵。
③沒有任何屬性徹底函數依賴於非鍵的任何一組屬性。簡單來講，相比3NF，BCNF更爲嚴格的一點就是要求R的每個屬性都不部分函數依賴於候選鍵且不傳遞函數依賴於候選鍵
若R∈BCNF則R必定∈3NF，但反之不必定成立。
例如對關係模式S（Sno,Sname,Sdept），S∈3NF，同時S中Sno是惟一的決定性因素，所以S∈BCNF。
再例如，有一個關係模式City（Cname,Street,Code）,其中Cname表示城市名，Street表示街道名，Code表示街道所在地區的郵政編碼，其上所具備的函數依賴關係爲：
（Cname,Street）->Code, Code->Cname
候選鍵爲（Cname,Street）和（Code,Street），不存在非主屬性，故City∈3NF，但決定因素Code不是鍵，因此City∉BCNF。
再舉一例，有一個關係模式STJ（S，T，J），其中S表示學生，T表示教師，J表示課程，每一個教師只講授一門課程，每門課程可由多個教師講授，某一學生選定某門課程，就對應一個肯定的教師，所以可得以下函數依賴：
（S，J）->T，（S，T）->J，T->J
（S，J）和（S，T）都是候選鍵，因此該關係中的S、T、J均爲主屬性，不存在非主屬性鍵，也就不存在非主屬性對鍵的部分函數依賴和傳遞函數依賴，STJ∈3NF，但STJ∉BCNF，由於在T->J中，T是決定因素，但T不是鍵。
對於關係模式STJ，咱們可舉一條實例分析不是BCNF的關係模式將會存在怎樣的異常問題
學生S |教師T|課程J
-------- | —
甲 | 教授A|大學語文
乙 | 教授A|大學語文
丙 | 教授B|大學語文
丁 | 教授B|大學語文
乙 | 教授C|大學英語
乙 | 教授D|大學英語
乙 | 教授E|C語言
①數據冗雜：每一個教師只講授一門課程，但選修了該門課程的多個學生記錄中都要存儲教師信息。
②插入異常：若學生尚未選課，則教師及課程的信息沒法錄入，由於主屬性此時爲空。
③更新異常：當課程更名後，全部選修了該課程的學生紀錄須要逐條修改屬性J的值，容易形成數據的不一致，破壞數據庫完整性。
④刪除異常：若選修了某門課程的全部學生畢業，在刪除全部學生信息的同時，有關課程的信息也被刪除了。
所以，將該關係模式分解爲如下兩個關係模式：ST（S，T）和TJ（T，J），他們間存在的函數依賴爲S->T，T->J
此時關係模式ST和TJ均達到BCNF，從而解決上述提到的異常。
一個關係模式若是達到了BCNF，那麼在函數依賴範疇內，它就已經實現了完全的分離，消除數據操做中可能出現的異常。
###①多值依賴
在關係模式中，函數依賴不能表示屬性值之間的一對多聯繫，這些屬性之間有些雖然沒有直接關係，但存在間接的關係，把沒有直接聯繫、但有間接的聯繫稱爲多值依賴的數據依賴。
簡單來講，在函數依賴中，X與Y是否存在函數依賴關係，只需考察X,Y的兩組屬性，與別的屬性無關。而在多值依賴中，X與Y是否存在多值依賴還需看屬性Z。
數學定義： 設R(U)是一個屬性集合U上的一個關係模式，X, Y, 和Z是U的子集，而且Z=U-X-Y，多值依賴X->->Y成立當且僅當對R的任一個關係r，r在(X,Z)上的每一個值對應一組Y的值，這組值僅僅決定於X值而與Z值無關。
平凡的多值依賴與非平凡的多值依賴：
若X->->Y,而Z爲空集，則稱X->->Y爲平凡的多值依賴；若Z不爲空，則稱其爲非平凡的多值依賴。
多值依賴的缺點在於數據冗雜太大。
舉例：有這樣一個關係 <倉庫管理員，倉庫號，庫存產品號> ，假設一個產品只能放到一個倉庫中，可是一個倉庫能夠有若干管理員，那麼對應於一個 <倉庫管理員，庫存產品>有一個倉庫號，而實際上，這個倉庫號只與庫存產品號有關，與管理員無關，就說這是多值依賴。
多值依賴具備如下性質：
①對稱性：若X->->Y，則X->->Z，其中Z=U-X-Y
②傳遞性：若X->->Y，Y->->Z，則X->->Z-Y
③合併性：若X->->Y，X->->Z，則X->->YZ
④分解性：若X->->Y，X->->Z，則X->->（Y∩Z），X->->Z-Y，X->->Y-Z均成立，也就是說兩個相交的屬性子集均多值依賴於另外一個屬性子集，則這兩個屬性子集因相交而分割成的3部分也都多值依賴於該屬性子集。
**⑤函數依賴能夠看做是多值依賴的特例。**若X->Y，則X->->Y，由於，當X->Y時，對X的每個取值x，Y有一個肯定的值y與之相對應，因此X->->Y。
那麼若想上例中的關係模式消除多值依賴，做模式分解，使子模式的Z=Ø，僅有平凡多值依賴，即子模式爲R1(倉庫號,倉庫管理員),R2(倉庫號,庫存產品號)
###②第四範式4NF
在多值依賴的基礎上咱們引入第四範式的概念
設關係R（X，Y，Z），其中X，Y，Z是成對的、不相交屬性的集合。若存在非平凡多值依賴，則意味着對R中的每一個屬性Ai（i=1,2…n）存在有函數依賴 X->Ai（X必包含鍵）。那麼R∈4NF。
第四範式限制關係模式的屬性之間不容許出現非平凡且非函數依賴的多值依賴。由於對於每個非平凡的多值依賴X->->Y，X都含有鍵，因此X->Y，故4NF所容許的非平凡的多值依賴實際上就是函數依賴。
若關係屬於4NF，則它必屬於BCNF；而屬於BCNF的關係不必定屬於4NF
在上述關係模式 <倉庫管理員，倉庫號，庫存產品號>中，鍵是（倉庫管理員，倉庫號，庫存產品號），倉庫號->->倉庫管理員，倉庫號->->庫存產品號，但倉庫號並非一個鍵，所以該關係不是4NF，而分解成R1(倉庫號,倉庫管理員),R2(倉庫號,庫存產品號)後，雖然仍存在倉庫號->->倉庫管理員，倉庫號->->庫存產品號，但他們是平凡的多值依賴，因此R1∈4NF，R2∈4NF。
若是隻考慮函數依賴，則BCNF的關係模式規範程度已經達到最高
若是考慮多值依賴，那麼4NF的關係模式規範化程度最高
另外還有其餘數據依賴如鏈接依賴，多值依賴是鏈接依賴的一種特殊狀況。在消除4NF關係模式中存在的鏈接依賴後則可進一步達到5NF，這裏再也不贅述。
（1）取原始的1NF關係投影，消去非主屬性對鍵的部分函數依賴，從而產生一組2NF關係。
（2）取2NF關係的投影，消去非主屬性對鍵的傳遞函數依賴，產生一組3NF關係。
（3）取這些3NF的投影，消去決定因素不是鍵的函數依賴。產生一組BCNF關係。
（4）取這些BCNF關係的投影，消去其中不是函數依賴的非平多值依賴，產生一組4NF關係。
規範化程度越高，分解就越細，所得關係的數據冗雜就越小，異常狀況也就越少，但同時也增大了系統對數據檢索的開銷，下降了數據檢索的效率。系統只有對這些細分的關係進行天然鏈接，才能獲取所需的信息，而鏈接操做所需的系統資源和開銷是比較大的，所以，規範化程度越高的關係模式並不是是最好的。
規範化應知足的基本原則是由低到高，逐步規範，權衡利弊，適可而止。一般以知足第三範式爲基本要求。
參考文獻：孟彩霞. 數據庫系統原理與應用[M]. 人民郵電出版社: 2008.