亚洲免费在线-亚洲免费在线播放-亚洲免费在线观看-亚洲免费在线观看视频-亚洲免费在线看-亚洲免费在线视频

理解數據庫的幾種鍵和幾個范式

系統 1813 0

[原創] 基礎中的基礎(三):理解數據庫的幾種鍵和幾個范式

?

  在上學的時候,數據庫是一門讓我比較頭大的課程。記得當時教材上凈是一些晦澀難懂的語言,沒有充足的實例來幫助理解。前一陣子在看《網絡游戲服務器端編程》的過程中,突然對數據庫范式有了一些感覺,在此總結一下,分享給大家。作者純菜鳥,即使總結這些基礎知識也難免有錯,希望給位大牛不吝賜教,謝謝!

鍵(關系鍵)以及數據庫范式都是關系數據庫的概念。所謂關系鍵,指的是一個表中的一個(或一組)屬性,用來 標識該表的每一行 與另一個表產生聯系

  數據庫的”范式“,指的是 設計數據庫的規則 。按照一定的規則設計出數據庫的表和關系,能夠避免在一些情況下的查詢出錯,并具有良好的結構。 總的來說,隨著范式等級的提高, 數據表屬性之間的依賴關系越來越小,數據冗余越來越低。 但同時,數據關系變得更加復雜,訪問一個具體數據的關系層次增加。 所以像設計模式一樣,不應盲目追求范式等級,應根據具體需求來選擇范式。

?

  我們先來看一下幾種常見的數據庫關系鍵:

1、 超鍵(super key) :能夠 唯一標識 一條記錄的屬性或屬性集。

    • 標識性:一個數據表的所有記錄都具有不同的超鍵
    • 非空性:不能為空

2、候選鍵( candidate key :能夠 唯一標識 一條記錄的 最小屬性集

    • 標識性:一個數據表的所有記錄都具有不同的候選鍵
    • 最小性:候選鍵的 任何子集 都不能唯一標識一個記錄
    • 非空性:不能為空
    • 候選鍵是 沒有多余屬性 的超鍵

3、主鍵(主碼、primary key) 某個 能夠 唯一標識 一條記錄的 最小屬性集

    • 唯一性:一個數據表只能有一個主鍵
    • 標識性:一個數據表的所有記錄都具有不同的主鍵取值
    • 非空性:不能為空
    • 選取某個候選鍵為主鍵

4、 外鍵(foreign key) :子數據表中出現的 父數據表的主鍵 ,稱為子數據表的外鍵。

5、代理鍵 :當不適合用任何一個候選鍵作為主鍵時(如數據太長等),添加一個沒有實際意義的鍵作為主鍵,這個鍵就是代理鍵。(如常用的序號1、2、3)

6、自然鍵 :自然生活中唯一能夠標識一條記錄的鍵(如身份證)

?

  下面就來看一下常見的幾種關系數據庫范式吧。

?

一、第一范式(1NF)

  要求:

  •   每一個屬性都不能再分割 ,都是原子項。

  第一范式是關系型數據表的基本要求,但是如何判斷一個屬性能否再分割呢?這沒有統一的標準,需要 依照需求確定 。比如,我們要設計一個網絡游戲后臺所用的數據庫,其中有一個數據表,記錄有關于擊殺怪物所獲得的金錢:

編號

怪物名

掉落金錢

1

巨熊

100

?  這個表格看上去并沒有什么問題。每一個屬性項都是”不可分割“的,所以符合第一范式。但是,如果我們希望把玩家擊殺怪物之后獲得的金錢分成兩部分,一部分是固定收益,另一部分是一個隨機的浮動收益(比如和玩家幸運值有關)。則這張表格中的”掉落金錢“項就不是”不可分割“了,也就不符合第一范式了。如果有這種需求,我們就可以把”掉落金錢“分割為”固定金錢“和”浮動金錢“兩部分。如下所示:

編號

怪物名

固定金錢

浮動金錢

1

巨熊

80

20

  這樣分割之后,使得每一項都不能再分割,從而使得數據表滿足第一范式。?

  滿足第一范式的數據表有什么好處呢?

  1. 1NF保證了數據庫的每一列都是不同的。每一列的數據彼此沒有任何交集。
  2. 這樣做首先 減少了數據的冗余,節省存儲空間 。如果不滿足第一范式,一些數據項有可能包含相同的”子項“,造成存儲空間的浪費。
  3. 其次,每一列沒有重復的數據意味著 不需要考慮數據更新的同步問題 。不用擔心在一列中更新了數據,還要在另一列做相應修改。
  4. 另外,每一列的數據不可再分, 在某些情況下 少了數據訪問的層數,提高數據訪問速度。

?

二、第二范式(2NF)

  要求:

  • 滿足第一范式
  • 非主鍵屬性均完全依賴于主鍵

?   非主鍵屬性和主鍵可以有什么關系?1、完全依賴。2、部分依賴。3、不依賴(沒關系)。顯然第三種情況下,這個屬性就不應該放在這張數據表中。所以2NF要求非主鍵屬性完全依賴于主鍵,就是在 消除非主鍵屬性對主鍵的 部分函數依賴。 既然是部分函數依賴,暗含著說主鍵是一個復合鍵(由多個屬性組成的鍵)。如果某個非主鍵屬性只和主鍵中的一部分有關(部分函數依賴),則不符合第二范式。舉例,網絡游戲的用戶數據表:

玩家用戶名

角色名

角色職業

上次登錄時間

?Alice

superman

wizard

2013-11-4?

  如果我們的游戲允許一個玩家擁有多個角色,則在這張表中“玩家用戶名”和“角色名”構成復合主鍵,唯一標識一條記錄。表中的“角色職業”,與玩家用戶名和角色名均相關,為完全依賴于主鍵。而“上次登錄時間”僅和“玩家用戶名”相關,而與角色名無關。所以“上次登錄時間” 部分函數依賴于主鍵。 本關系不符合2NF。

  要將上表轉換為符合2NF的結構也很簡單,只要把部分函數依賴的部分抽出來,組成新的表即可。如下所示:

玩家用戶名

角色名

角色職業

Alice

superman

wizard

?

玩家用戶名

上次登錄時間

Alice

2013-11-4

  符合2NF能給我們帶來什么好處呢?2NF消除了屬性對主鍵的部分函數依賴。

  首先, 2NF可以在一定程度上消除冗余,節省存儲空間。

  如果存在部分函數依賴,則可能存在數據冗余。在多條記錄中,主鍵中的某一個屬性可能是一樣的,而如果有其他數據項函數依賴于這個不變的屬性,則這些數據項也將是一樣的。比如在上面例子中,在修改之前的表中,如果有多個角色名對應一個玩家用戶名,則會有多條數據。它們具有一樣的用戶名和不同的角色名。由于上次登錄時間僅依賴于玩家用戶名,所以在這多條記錄中,上次登錄時間也都是相同的,造成了冗余。

  其次, 2NF 簡化了表的邏輯關系 ,使得表的結構更加清晰。

?

三、第三范式(3NF)

  要求:

  • 滿足第一、二范式
  • 所有非主鍵屬性之間沒有函數依賴關系

  3NF在2NF的基礎上, 進一步消除 非主鍵屬性之間 的函數依賴關系 。實質上,也是消除非主鍵屬性中的傳遞依賴。更進一步地說,如果兩個數據表有關系。那么這兩個數據表中的非主鍵屬性必須是不同的。如果存在一個非主鍵屬性A,存在于兩張表中。則在某張表中,A依賴于外鍵,從而不符合3NF。比如網絡游戲中拍賣行的數據,可以按照下面的表格進行存儲:

玩家姓名

物品名

單價

數量

總金額

Alice

治療藥劑

50

10

500

  在這個表格中,“總金額”項可以通過“單價”和“數量”運算得出,存在函數依賴關系,不滿足3NF。

  要將這個表格修改為滿足3NF的要求,只需要從表中刪除“總金額”即可。在另外一些情況中,可以將函數依賴關系涉及到的項單獨抽出來組成新的表,需要具體情況具體分析。

  3NF的優點很明顯, 可以減少數據冗余,節省存儲空間。 既然存在函數依賴,某些數據項就能夠通過其他數據項計算得出,很可能存在數據冗余。值得注意的是,在一些情況下, 存在這種數據冗余的表格是有意義的 。如果在表格中存儲著某些運算的結果,我們在使用這些結果時就不用進行運算了,節省了運算時間,是一種“空間換時間”的做法。從這里也可以看出,應用范式并不能夠保證最好的效果,需要根據應用需求進行合理取舍。

??

四、BC范式(boyce-codd范式,BCNF)

  要求:

  • 滿足1NF、2NF、3NF?
  • 所有屬性(包含主鍵屬性和非鍵主屬性)都 不傳遞依賴于任何候選鍵

  BC范式在3NF的基礎上,要求主鍵屬性也不能傳遞依賴于任何候選鍵。當主鍵是復合鍵是,主鍵的某個屬性可能會依賴于某個候選鍵。此時,關系能夠符合3NF,因為并不是“非主鍵”屬性依賴于某個非主鍵屬性。但此關系并不符合BC范式。例如,在以房間為組織方式的游戲中,我們記錄某個玩家、房間和房主的關系。

房主ID

房間ID

玩家ID

Alice

123

Bob

  表中的依賴關系有:

  1. (玩家ID,房間ID)-> 房主ID
  2. 房主ID -> 房間ID
  3. (玩家ID,房主ID)-> 房間ID

  同時,表中的候選鍵有(玩家ID,房間ID)、(玩家ID,房主ID)。比如,我們選擇主鍵為(玩家ID,房間ID),那么,房間ID就是主鍵的一個屬性。而在依賴關系2中,房間ID依賴于房主ID,房主ID是候選鍵(玩家ID,房主ID)的一個屬性。那么,首先, 由于房間ID不是候選鍵屬性,所以此表并沒有違反3NF。 但是由于房間ID和房主ID存在依賴關系,所以滿足“ 主鍵屬性傳遞依賴于某個候選鍵 ”的條件,所以此表不符合BC范式。

  要把上表修改為滿足BC范式的形式,只要把它進行合理拆分即可。

房間ID

玩家ID

123

Bob

?

房間ID

房主ID

123

Alice

?  BC范式的好處是 進一步消除了表中的依賴關系,減少了冗余 。例如在上例中,如果我們采用未修改的版本,如果想要存儲一個10個玩家(不含房主)的房間,就需要10條這樣的記錄才可以。

??

五、第四范式

  要求:

  • 滿足1NF、2NF、3NF
  • 表中不能包含一個實體的兩個或多個多值屬性

  所謂多值屬性,指的是 某個屬性可以包含多個值 。這個屬性的(多個)取值,被另一個屬性決定。也就是說,一旦確定了某個屬性,另一個屬性的多個取值就一起確定了。第四范式在第三范式的基礎上, 消除多值依賴 。所謂多值依賴,指的是一組值(多值屬性)依賴于另一個屬性。函數依賴是一對一的關系,多值依賴是一對多的關系。這個理解起來我感覺有點別扭,可能我的理解也有偏差,說出來和大家一起探討一下。

  比如,我們要在數據庫中保存玩家的角色技能信息,這里我們允許一個玩家具有多個角色,一個角色具有多個技能:

?

玩家ID

角色名

技能

Alice

superman

Fire ball

  首先,這個表只有一個候選鍵(玩家ID、角色名、技能)。所以肯定符合3NF。進一步觀察一下,玩家ID是一個單值屬性。角色名就是一個多值屬性了,因為一個玩家ID可以對應多個角色名。角色名在表中看起來是一項,這是由于受制于具體數據庫提供的功能。邏輯上,我們拿到一個玩家ID,可以確定的是,這個玩家具有某些角色,是一個一對多的關系,是多值依賴。角色名是一個多值屬性。同樣的,一個角色也對應著多個技能,這也是多值依賴。技能也是一個多值屬性。顯然,這個表并不符合4NF。

  這個表有什么問題呢?

  首先, 數據冗余大 ,如果一個玩家有好幾個具有Fire Ball技能的角色,這個技能項就要重復保存幾次。

  其次, 增、刪、改都比較復雜 ,比如我們要刪除Fire Ball技能,那么,我們要刪除這個玩家所有具有Fire Ball技能的表項。

  要將上表修改為符合4NF的表,只需要將多值依賴進行合理映射即可:

玩家ID

角色名

Alice

superman

?

角色名

技能

superman

Fire ball

  這兩個表都符合4NF。

  可以看出,4NF的使用可以 降低數據冗余,并且減少數據處理復雜度

??

六、第五范式

要求:

  • 滿足1NF、2NF、3NF、4NF
  • 如果將表中的多元關系分解一個一個的二元關系,一定會丟失信息

  第五范式在4NF的基礎上, 進一步消除依賴 。第五范式的要求明,如果不用這個表就不能正確說明數據之間的聯系。所以符合5NF的表已經沒有任何多余依賴的存在了。所以第五范式是一個比較理想的范式。比如我們存儲玩家對戰和其發生地點:

玩家1

玩家2

對戰地點

Alice

Lisa

競技場1

Alice

Bob

競技場2

Bob

Lisa

競技場1

  現在,我們把它拆分成三個二元關系:

玩家1

玩家2

Alice

Lisa

Alice

Bob

Bob

Lisa

?

玩家1

對戰地點

Alice

競技場1

Alice

競技場2

Bob

競技場1

?

玩家2

對戰地點

Lisa

競技場1

Bob

競技場2

Lisa

競技場1

?

  單獨看這三個子表,我們可以得出以下結論:

  1. Alice和Bob對戰過
  2. Alice在競技場1和競技場2都進行過對戰
  3. Bob在競技場1和競技場2都進行過對戰(結合第二、三個表)

?

  從這三個獨立的結論,我們無法得知Alice和Bob究竟在那個競技場進行的對戰,也就是發生了信息丟失。所以上邊那個表是符合5NF的。

?

  好了,6個范式都看完啦,簡單總結一下:

范式等級

說明

1NF

每一列都是原子項,不可分割

2NF

非主鍵屬性均完全依賴于主屬性,消除部分依賴

3NF

所有非主鍵屬性之間沒有依賴關系,消除傳遞依賴

BCNF

所有屬性均不傳遞依賴于任何候選鍵

4NF

表中不包含超過一個多值屬性,消除多值依賴

5NF

將表拆分為二元關系,一定會損失信息

?

?

  感謝您看到這里!希望對您有一點幫助,歡迎批評和討論! ^_^

?

  其他博客:

基礎中的基礎(二):C/C++ 中 const 修飾符用法總結

基礎中的基礎(一):簡單排序算法總結(附代碼)

?
?

理解數據庫的幾種鍵和幾個范式


更多文章、技術交流、商務合作、聯系博主

微信掃碼或搜索:z360901061

微信掃一掃加我為好友

QQ號聯系: 360901061

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。

【本文對您有幫助就好】

您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描上面二維碼支持博主2元、5元、10元、自定義金額等您想捐的金額吧,站長會非常 感謝您的哦!!!

發表我的評論
最新評論 總共0條評論
主站蜘蛛池模板: 一级片在线观看视频 | 欧美久久一区二区三区 | 欧美日本另类xxx乱大交 | 四虎影业| 激情综合网婷婷 | 888米奇色狠狠俺去啦 | 国产福利视频一区 | 精品乱人伦一区二区 | 欧美日韩在线高清 | 欧美区一区二区三 | 久久精品这里热有精品 | 69精品久久久久 | 日韩欧美一区二区在线 | 狠狠久久久久久亚洲综合网 | 亚洲一片| 国产亚洲精品一区久久 | 四虎成人免费网站在线 | 欧美综合一区二区三区 | 亚洲免费高清 | 欧美性影院 | 日本中文字幕在线观看视频 | 日本a在线视频 | 色国产在线 | 久久精品成人免费看 | 激情久久久久久久久久久 | 久久88色综合色鬼 | 黄色在线观看网站 | 欧美精品国产 | 香蕉久久综合精品首页 | 成人夜色香网站在线观看 | 亚洲特级aaaaaa毛片 | 黄色免费看网站 | 欧美日韩中文字幕在线 | 日本一级毛片2021免费 | 福利午夜影院 | 欧美成人免费大片888 | 91中文字幕在线视频 | 天天干天天舔天天操 | 午夜体验 | 国产精品久久久久影院色 | 福利在线观看视频 |