設計關係數據庫時,爲了設計出合理的數據庫表結構,須要聽從不一樣的規範要求,這些規範性要求被稱爲範式。數據庫
目前關係數據庫有六種範式:第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯-科德範式(BCNF)、第四範式(4NF)和第五範式(5NF,又稱完美範式)。數據庫設計
各類範式呈遞次規範,越高的範式數據庫冗餘越小。知足高層次範式的一定知足低層次範式,如一個數據庫設計若是符合第二範式,必定也符合第一範式。函數
一、實體:現實世界中客觀存在的並能夠相互區分的對象或事物。如"公司"、"項目"、"員工"等。spa
二、屬性:實體所具備的某一特性。好比"公司名稱"、"公司地址"都是實體"公司"的屬性。設計
三、碼:表中能夠惟一肯定一行數據的某個屬性[或者屬性組]。如[員工號]、[員工號,績效評定月份]。不一樣的表結構,對應的碼不一樣。下文表(二)中,[員工號,績效評定月份]屬性組就是碼。對象
四、主屬性:包含在任何一個碼中的屬性稱爲主屬性。下文表(二)中,員工號和績效評定月份就是主屬性。blog
五、非主屬性:與主屬性相反,沒有在任何候選碼中出現過,這個屬性就是非主屬性。下文表二中,員工姓名、部門、部門人數、績效就是非主屬性。ci
第一範式指的是符合第一範式的關係中的每一個屬性都不可再分。開發
下表(一)中,因爲部門信息這個屬性能夠再分爲部門和部門人數這兩個屬性,因此不符合第一範式。it
員工號 | 員工姓名 | 部門 | 績效評定月份 | 績效 | |
部門 | 部門人數 | ||||
10001 | 張三 | 開發部 | 30 | 201801 | 90 |
10001 | 張三 | 開發部 | 30 | 201802 | 85 |
10002 | 李四 | 集成部 | 30 | 201801 | 88 |
10002 | 李四 | 集成部 | 30 | 201802 | 87 |
10003 | 王五 | 綜合部 | 5 | 201802 | 89 |
10004 | 馬六 | 綜合部 | 5 | 201802 | 85 |
表(一)
將上表修改爲以下表,就知足第一範式。
員工號 | 員工姓名 | 部門 | 部門人數 | 績效評定月份 | 績效 |
10001 | 張三 | 開發部 | 30 | 201801 | 90 |
10001 | 張三 | 開發部 | 30 | 201802 | 85 |
10002 | 李四 | 集成部 | 30 | 201801 | 88 |
10002 | 李四 | 集成部 | 30 | 201802 | 87 |
10003 | 王五 | 綜合部 | 5 | 201802 | 89 |
10004 | 馬六 | 綜合部 | 5 | 201802 | 85 |
表(二)
第一範式是全部關係型數據庫的最基本要求,只要在關係型數據庫管理系統(RDBMS)中已經存在的數據表,必定是符合第一範式。
A、數據冗餘:如上表中,員工號、員工姓名、部門、部門人數數據重複出現屢次。
B、插入異常:根據三種關係完整性約束中實體完整性的要求,關係中的碼所包含的任意一個屬性都不能爲空,全部屬性的組合也不能重複(能夠簡單的理解爲表的主鍵)。上表中,爲了惟一區分每一條記錄,須要將(員工號,績效評定月份)做爲碼。若是一個新建的部門尚未員工的話,那麼就沒法將部門和部門人數的信息插入到表中,致使插入異常,沒法有效記錄部門的信息。
C、刪除異常:若是將員工相關的記錄都刪除,那麼部門相關的信息也會刪除,致使了刪除異常。
D、修改異常:假如張三轉到集成部,爲了保證數據庫中數據的一致性,須要修改兩條條記錄中部門與部門人數的數據,致使修改異常。
第二範式是爲了解決第一範式所帶來的問題而設定的規則,它是在第一範式的基礎之上,消除了非主屬性對於碼的部分函數依賴。簡單地說,第二範式要求每一個非主屬性徹底依賴於主鍵,而不是僅依賴於主鍵其中的一部分屬性。
A、函數依賴
在一張表中,若是在屬性(或屬性組)X的值肯定的狀況下,一定能肯定屬性Y的值,那麼就能夠說Y函數依賴於X,寫做 X → Y。也就是說,在數據表中,不存在任意兩條記錄,它們在X屬性(或屬性組)上的值相同,而在Y屬性上的值不一樣。
在上表(二)中,存在着如下的函數依賴:
★ 員工號 → 員工姓名
★ 部門 → 部門人數
★ (員工號,績效評定月份) → 績效
如下的函數依賴則不成立:
★ 員工號 → 績效評定月份
★ 員工號 → 績效
B、徹底函數依賴
若是X → Y是一個函數依賴,且對X的任何一個真子集X',都不存在X' → Y,則稱X → Y是一個徹底函數依賴。爲了方便表述,寫做X>>Y(非正式方式)。
在上表中,存在着如下的徹底函數依賴:
★ 員工號>>員工姓名
★ (員工號,績效評定月份)>>績效(員工號對應的績效不肯定,績效評定月份對應的績效也不肯定)
C、部分函數依賴
若是X → Y是一個函數依賴,而且存在X的一個真子集X',使得X' → Y,則稱X → Y是一個部分函數依賴。爲了方便表述,寫做X>Y(非正式方式)。
在上表中,存在着如下的部分函數依賴:
★ (員工號,績效評定月份)>員工姓名
D、傳遞函數依賴
若是X→Y,Y→Z,且Y不屬於X,Y → X不成立,則稱Z傳遞函數依賴於X。爲了方便表述,寫做X>>>Z(非正式方式)。(限定Y不屬於X,Y→X不成立,是由於若是Y屬於X,那麼Z部分函數依賴於X,此時X中存在多餘屬性;若Y → X成立,則有X和Y等價,則關係中沒有必要同時存在X和Y)
在上表中,存在着如下的傳遞函數依賴:
★ 員工號>>>部門人數(員工號 → 部門,部門 → 部門人數)
根據定義,咱們能夠知道:第二範式就是判斷是否存在非主屬性對於碼的部分函數依賴,若是存在,則不知足第二範式。
判斷一個表是否符合第二範式,能夠經過如下步驟進行判斷:
★ 找出表中全部的碼;
★ 根據第一步找出的碼,找出全部的主屬性;
★ 根據主屬性,找出全部的非主屬性;
★ 判斷是否存在非主屬性對於碼的部分函數依賴,由此斷定是否符合第二範式;
咱們根據以上步驟來分析一下上表(二):
★ 該表的碼爲:(員工號,績效評定月份)
★ 該表的主屬性爲:員工號、績效評定月份
★ 該表的非主屬性爲:員工姓名、部門、部門人數、績效
★ 該表的非主屬性對於碼的函數依賴關係以下:
[員工號,績效評定月份] → 績效,徹底函數依賴;
[員工號,績效評定月份]→ 員工姓名,部分函數依賴;由於存在:員工號 → 員工姓名
[員工號,績效評定月份]→ 部門,部分函數依賴;由於存在:員工號 → 部門
[員工號,績效評定月份]→ 部門人數,傳遞函數依賴;由於存在:員工號 → 部門,部門 → 部門人數
因爲存在非主屬性對於碼的部分函數依賴,因此上表不符合第二範式。
爲了符合第二範式的要求,咱們必須消除這些部分函數依賴,將大表拆分紅更多個更小的表。
咱們將上表拆分紅以下的兩個表:
員工號 | 績效評定月份 | 績效 |
10001 | 201801 | 90 |
10001 | 201802 | 85 |
10002 | 201801 | 88 |
10002 | 201802 | 87 |
10003 | 201802 | 89 |
10004 | 201802 | 85 |
表(三)
員工號 | 員工姓名 | 部門 | 部門人數 |
10001 | 張三 | 開發部 | 30 |
10002 | 李四 | 集成部 | 30 |
10003 | 王五 | 綜合部 | 5 |
10004 | 馬六 | 綜合部 | 5 |
表(四)
兩個表的非主屬性對於碼的函數依賴關係以下:
★ [員工號,績效評定月份]→ 績效,徹底函數依賴;
★ 員工號 → 員工姓名,徹底函數依賴;
★ 員工號 → 部門,徹底函數依賴;
★ 員工號 → 部門人數,徹底函數依賴和傳遞函數依賴;由於存在:員工號 → 部門,部門 → 部門人數
因爲兩個表都符合徹底函數依賴,因此兩個表都符合第二範式。
那麼第二範式是否解決了第一範式的不足呢?
A、數據冗餘:除部門人數數據重複外,其他無冗餘。有改進。
B、插入異常:根據三種關係完整性約束中實體完整性的要求,關係中的碼所包含的任意一個屬性都不能爲空,全部屬性的組合也不能重複(能夠簡單的理解爲表的主鍵)。員工-部門表中,爲了惟一區分每一條記錄,須要將員工號做爲碼。若是一個新建的部門尚未員工的話,那麼就沒法將部門和部門人數的信息插入到表中,致使插入異常,沒法記錄部門的信息。無改進。
C、刪除異常:表(四)中,若是將員工相關的記錄都刪除,那麼部門相關的信息也會刪除,致使了刪除異常。無改進。
D、修改異常:假如張三轉到集成部,只須要改動對應的部門便可。有改進。
因此,僅僅符合第二範式的要求,不少狀況下仍是不夠的,爲了能進一步解決這些問題,咱們還須要將符合第二範式要求的表改進爲符合第三範式的要求。而致使這些的緣由是傳遞函數依賴。
第三範式是在第二範式的基礎之上,消除非主屬性對於碼的傳遞函數依賴。
在上述例子中,因爲存在員工號與部門人數的傳遞函數依賴,因此須要將表(四)進行再次拆分,拆分後全部表以下:
員工號 | 績效評定月份 | 績效 |
10001 | 201801 | 90 |
10001 | 201802 | 85 |
10002 | 201801 | 88 |
10002 | 201802 | 87 |
10003 | 201802 | 89 |
10004 | 201802 | 85 |
表(五)
員工號 | 員工姓名 | 部門 |
10001 | 張三 | 開發部 |
10002 | 李四 | 集成部 |
10003 | 王五 | 綜合部 |
10004 | 馬六 | 綜合部 |
表(六)
部門 | 部門人數 |
開發部 | 30 |
集成部 | 30 |
綜合部 | 5 |
表(七)
以上三個表均知足第三範式,那麼第三範式是否解決了第二範式的不足呢?
A、數據冗餘:無冗餘。有改進。
B、插入異常:能夠插入部門信息。有改進。
C、刪除異常:刪除員工信息,部門信息不會刪除。有改進
D、修改異常:假如張三轉到集成部,只須要改動對應的部門便可。有改進。
因此第三範式基本解決了數據冗餘、插入異常、刪除異常、修改異常等問題。
A、BCNF範式
一、全部非主屬性都徹底函數依賴於每一個候選鍵
二、全部主屬性都徹底函數依賴於每一個不包含它的候選鍵
三、沒有任何屬性徹底函數依賴於非候選鍵的任何一組屬性
B、第四範式
解決多值依賴問題,要求把同一表內的多對多關係刪除。表示在多對多關係中,實體自己並不存儲關係,而關係都記錄在另外一箇中間關係表中,要選擇倆個多對多實體間的數據,必須經過中間關係表來獲得,實體自己沒有存儲任何與另一個實體的關係的記錄。
C、第五範式
也稱投影-鏈接範式,是數據庫規範化的一個級別,以去除多個關係之間的語義相關。一張表知足第五範式當且僅當它的每一個鏈接依賴可由候選鍵推出。
範式就是在數據庫表設計時移除數據冗餘的過程。隨着範式級別的提高,數據冗餘愈來愈少,但數據庫的效率也愈來愈低。