關係型數據庫範式


     設計關係數據庫時,爲了設計出合理的數據庫表結構,須要聽從不一樣的規範要求,這些規範性要求被稱爲範式數據庫

     目前關係數據庫有六種範式:第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯-科德範式(BCNF)、第四範式(4NF)和第五範式(5NF,又稱完美範式)數據庫設計

     各類範式呈遞次規範,越高的範式數據庫冗餘越小。知足高層次範式的一定知足低層次範式,如一個數據庫設計若是符合第二範式,必定也符合第一範式。函數

1、基本概念

     一、實體:現實世界中客觀存在的並能夠相互區分的對象或事物。如"公司"、"項目"、"員工"等。spa

     二、屬性:實體所具備的某一特性。好比"公司名稱"、"公司地址"都是實體"公司"的屬性。設計

     三、:表中能夠惟一肯定一行數據的某個屬性[或者屬性組]。如[員工號]、[員工號績效評定月份]。不一樣的表結構,對應的碼不一樣。下文表(二)中,[員工號績效評定月份]屬性組就是碼。對象

     四、主屬性:包含在任何一個碼中的屬性稱爲主屬性。下文表(二)中,員工號績效評定月份就是主屬性。blog

     五、非主屬性:與主屬性相反,沒有在任何候選碼中出現過,這個屬性就是非主屬性。下文表二中,員工姓名、部門、部門人數、績效就是非主屬性。ci

2、第一範式

     一、概述

     第一範式指的是符合第一範式的關係中的每一個屬性都不可再分開發

     二、實例分析

     下表(一)中,因爲部門信息這個屬性能夠再分爲部門和部門人數這兩個屬性,因此不符合第一範式。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、修改異常:假如張三轉到集成部,爲了保證數據庫中數據的一致性,須要修改兩條條記錄中部門與部門人數的數據,致使修改異常。

3、第二範式

     一、概述

     第二範式是爲了解決第一範式所帶來的問題而設定的規則,它是在第一範式的基礎之上,消除了非主屬性對於碼的部分函數依賴。簡單地說,第二範式要求每一個非主屬性徹底依賴於主鍵,而不是僅依賴於主鍵其中的一部分屬性。

     二、相關概念

     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、修改異常:假如張三轉到集成部,只須要改動對應的部門便可。有改進。

     因此,僅僅符合第二範式的要求,不少狀況下仍是不夠的,爲了能進一步解決這些問題,咱們還須要將符合第二範式要求的表改進爲符合第三範式的要求。而致使這些的緣由是傳遞函數依賴。

3、第三範式

     一、概述

     第三範式是在第二範式的基礎之上,消除非主屬性對於碼的傳遞函數依賴。

     二、實例分析

     在上述例子中,因爲存在員工號與部門人數的傳遞函數依賴,因此須要將表(四)進行再次拆分,拆分後全部表以下:

員工號 績效評定月份 績效
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、修改異常:假如張三轉到集成部,只須要改動對應的部門便可。有改進。

     因此第三範式基本解決了數據冗餘、插入異常、刪除異常、修改異常等問題。

4、其它範式(待補充細化)

     A、BCNF範式

   一、全部非主屬性都徹底函數依賴於每一個候選鍵

   二、全部主屬性都徹底函數依賴於每一個不包含它的候選鍵

   三、沒有任何屬性徹底函數依賴於非候選鍵的任何一組屬性

     B、第四範式

     解決多值依賴問題,要求把同一表內的多對多關係刪除。表示在多對多關係中,實體自己並不存儲關係,而關係都記錄在另外一箇中間關係表中,要選擇倆個多對多實體間的數據,必須經過中間關係表來獲得,實體自己沒有存儲任何與另一個實體的關係的記錄。

     C、第五範式

     也稱投影-鏈接範式,是數據庫規範化的一個級別,以去除多個關係之間的語義相關。一張表知足第五範式當且僅當它的每一個鏈接依賴可由候選鍵推出。

5、總結

     範式就是在數據庫表設計時移除數據冗餘的過程。隨着範式級別的提高,數據冗餘愈來愈少,但數據庫的效率也愈來愈低。

     通常狀況下,數據庫設計知足第三範式便可。

相關文章
相關標籤/搜索