親愛的盆友們~又是新的一年，你，準備好新的學習計劃了嗎~？是讀書100本，還是考上5個證？嘛~不管怎麼說，角落裏那一堆蒙塵的計劃表好像在昭示着這仍然是一個充滿朝氣又艱難的9102年呢！總之，先把#技本功#進修班報了再說吧~何以暴富，唯有學習！
-2019年第3期-
夫子說
數據庫的庫表設計是數據庫開發階段的基礎，合理的結構和關係將會大大提升以後數據庫的運行性能；而表設計要遵循範式規則，除了比較常見和通用的三大範式外，還有BCNF、4NF、5NF...甚至更高的範式，但是也不是範式越高越好，有時候也需要逆範式化設計表。今天，就重點講一講解析範式（1NF-4NF）。
1NF
1、1NF的定義
關係數據庫中的關係是要滿足一定要求的，滿足不同程度要求的爲不同的範式。滿足最低要求是第一範式(1NF)，1NF的定義如下：
1NF：關係中的每一個分量必須是一個不可分的數據項。
通俗地說，第一範式就是表中不允許有小表的存在。比如，對於如下的員工表，就不屬於第一範式：
上表中，出現了屬性薪資又被分爲基本工資和補貼兩個子屬性，就好像表中又分割了一個小表，這就不屬於第一範式。如果將基本工資和補貼合併，那麼該表符合1NF。
2、1NF存在的問題
1NF是最低一級的範式，範式程度不高，存在很多的問題。比如用一個單一的關係模式學生來描述學校的教務系統：
學生(學號,學生姓名,所在系,系主任姓名,課程號,成績)
學生表
假如選定學號爲主鍵，這個表滿足第一範式，但是存在如下問題：
● 數據冗餘：
一個繫有很多的學生，同一個系的學生的系主任是相同的，所以系主任名會重複出現。
● 更新複雜：
當一個系換了一個系主任後，對應的這個表必須修改與該系學生有關的每個元組。
● 插入異常：
如果一個系剛成立，沒有任何學生，那麼這個無法把這個系的信息插入表中。
● 刪除異常：
如果一個系的學生都畢業了，那麼在刪除該系學生信息時，這個系的信息也丟了。
2NF
1、2NF的定義
2NF的定義：如果關係R屬於1NF，且每一個非主屬性完全函數依賴於任何一個候選碼，則R屬於2NF。
通俗地說，2NF就是在1NF的基礎上，表中的每一個非主屬性不會依賴複合主鍵中的某一個列。
按照定義，上面的學生表就不滿足2NF，因爲學號不能完全確定課程號和成績(每個學生可以選多門課)。將學生表分解爲：學生(學號,學生姓名,系編號)，系(系編號,系名,系主任)，選課(學號,課程號,成績)。每張表均屬於2NF。
新定義一張表：銷售表(產品id,地區id,價格,產品名)，同一個產品在不同地區價格不同。這個表就不屬於2NF，因爲非主屬性產品名不是完全函數依賴於主鍵，而是完全依賴於產品id，即表中存在非主屬性對主鍵的部分依賴。將銷售表分解：產品(產品id,產品名)，銷售表(產品id,地區id,價格)。每張表均屬於2NF。
2、2NF存在的問題
下面舉例說明2NF存在的相應問題。
對於公司裏的員工管理，每個員工只能屬於一個部門，每個部門可以有多個員工，定義如下關係模式：
員工管理表(員工id,員工名,所屬部門id,部門經理);
對應的表：
在的問題：
● 刪除異常：
如果某個部門的人都跳槽了，那麼在刪除這些員工的同時也丟失了這個部門的信息。
● 修改複雜：
如果一個員工換了一個部門，不但要修改所屬部門，還要修改部門經理這個屬性列。
● 插入異常：
如果公司新成立了一個部門，但是目前沒有招收員工，那麼這個部門信息也無法插入到這個表中，因爲沒有主鍵。
3NF
1、3NF的定義
3NF的嚴格定義如下：
關係模式R屬於1NF，若R中不存在這樣的碼X，屬性組Y及非主屬性Z，使得X函數確定Y、Y函數確定Z成立，Y不能函數確定X，則稱R是屬於3範式的。
通俗地說，就是在滿足1NF的基礎上，表中不存在非主屬性對碼的傳遞依賴。也就是說表中非主屬性不會間接地依賴於碼。
如上面的員工管理表就不屬於3NF，因爲非主屬性部門經理依賴於所屬部門，所屬部門依賴於員工id，即部門經理傳遞依賴於員工id。將員工管理表分解：員工管理(員工id,員工名,部門名)，部門(部門名,部門經理)。則每張表均屬於3NF。
2、3NF存在的問題
現在有這樣的一個場景：對於一個工程(ENO)的實施，每個工程需要多個零件，每個供應商(SNO)只生產一個零件(PNO)且受工廠規模所限只能同時供應一個工程，每個工程使用的同一個零件都來自同一個生產商。
定義關係模式：SPE(SNO,PNO,ENO)。
表中存在如下函數依賴：
(ENO,PNO)→SNO
(ENO,SNO)→PNO
SNO→PNO
SPE是屬於3NF的，因爲根據定義，表中不存在非主屬性對碼的傳遞依賴和部分依賴。但是這張表存在如下的問題：
● 插入異常：
如果有一個新的工廠建立了，但是這家工廠還沒有接到任何訂單，那麼無法將這個工廠信息插入到SPE中，因爲缺少了主屬性ENO。
● 刪除異常：
如果某個供應商只給一個工程提供零件，現在這個工程不再需要這個零件了。那麼PNO就要刪除，而PNO是主屬性，整個元組都被刪除了，這樣就丟失了一個供應商信息。
BCNF
1、BCNF的定義
BCNF比3NF更進一步，可以認爲是擴充的3NF，其定義如下：
關係模式R屬於1NF，若X函數確定Y(且X不包含Y)時X必含有碼，則R屬於BCNF。
翻譯成人話，就是在第一範式的基礎上，若關係R中的每一個決定因素都必含有碼，則關係R屬於BCNF。
很顯然，上面的SPE表不屬於BCNF，因爲SPE中存在一個決定因素SNO，SNO不含有碼。將SPE表分解：SP(SNO,PNO)，SE(SNO,ENO)。則每張表均屬於BCNF。
2、BCNF存在的問題
仍以上面的工程實施場景爲例：假設每個供應商可以生產多個零件，可以供應給多個工程，一個工程需要多個零件，但同一個工程的同一個零件必須來自同一個供應商。
那麼關係SPE(SNO,PNO,ENO)對應的表數據可能是如下：
此時表SPE存在如下的函數依賴：
(PNO,ENO)→SNO
根據BCNF的定義，此時表SPE屬於BCNF。但是這樣的關係模式仍具有不好的地方：數據冗餘度太大。假如供應商S3生產了n個零件，每個零件供應給m個工程，那麼顯然S3要在表中重複m*n次。
4NF
1、4NF的定義
4NF嚴格定義如下：
關係模式R屬於1NF，對於R中的每一個非平凡多值依賴X→→Y(X不包含Y)，X都含有碼，則R屬於4NF。
通俗地說，對於有三個屬性的表，給定屬性A一個值，剩餘兩個列之間不存在多對多的關係。例如，在上面的SPE表中，給定SNO=S1，PNO和ENO之間很明顯存在多對多的關係，故上表是不屬於4NF的。
根據4NF的定義可知，4NF所允許的非平凡的多值依賴實際上就是函數依賴，4NF就是消除表中的非平凡多值依賴關係。
2、4NF存在的問題
一般地，4NF屬於規範程度比較高的範式了。但是考慮到連接依賴的話，4NF中也仍存在數據冗餘，插入、修改、刪除異常等問題。如果消除了4NF中的連接依賴，則達到了5NF的關係模式；5NF範式化已經很高了，實際工作中很少會遇到這麼高的範式表，這裏就不再敘述了。
範式的相關總結
如果只考慮函數依賴，那麼BCNF範式最徹底，已消除插入和刪除的異常。而3NF的不徹底性表現在表中可能存在主屬性對碼的部分依賴和傳遞依賴。
如果考慮到多值依賴，那麼4NF範式是規範程度最高的。但4NF中可能存在連接依賴的關係，而5NF可以消除連接依賴。
在數據庫中，有時並不是規範化程度越高越好，有時候也需要逆範式化設計表。因爲範式越高，產生的表就越多，一個簡單的查詢需求就可能涉及到多張表的關聯，影響查詢效率。一般地，數據庫中的表都在3NF。