MySQL:從四個問題到數據庫規範化理論

一、前言

在關係數據庫的邏輯設計中,針對一個具體的問題,應該如何構造一個合適於它的關係模式,即應該構造幾個關係,每個關係由哪些屬性組成?

二、數據模式存在的問題

2.1 例子

我們設計的數據模式可能會出現什麼問題?我們通過設計一個教務系統來了解一下

  • 涉及的對象
    學號、所在系、系主任姓名、課程號和成績
  • 語義:
    1、一個繫有若干個學生,但是一個學生只屬於一個系
    2、一個系只有一個系主任
    3、一個學生可以選修多門課程,每門課程有若干學生選修
    4、每個學生所學的每門課程都有一個成績

我們設計的關係模式:學生表(學號,所在系,系主任姓名,課程號,成績)

學號 所在系 系主任姓名 課程號 成績
S1 計算機系 張三 C1 90
S2 計算機系 張三 C1 95
S3 計算機系 張三 C2 90
S4 數學系 王五 C3 90
S5 數學系 王五 C4 90
S6 數學系 王五 C4 90
S7 物理系 李四 C7 90

2.2 問題

通過觀察這個表我們可以發現,這個數據模式存在如下的四個問題:

數據冗餘:數據冗餘太大,浪費存儲空間。通過觀察我們發現系主任姓名重複出現。

更新異常:數據冗餘,更新數據時,維護數據完整性代價大,如果某系更換系主任,系統必須修改與該系學生有關的每一個元組

插入異常:該插入的數據插不進去,如果新成立一個人工智能系,但是還沒有招生,我們就無法把這個系及其系主任的信息插入表中

刪除異常:不該刪除的信息也被刪除了,如果某個系的學生全部畢業了,我們在刪除該系學生信息的時候也把該系和及其系主任的信息刪除了

2.3 什麼是好的數據模式

一個好的關係模式不會發生插入異常、刪除異常、更新異常,同時數據冗餘應儘可能少。如果設計好的關係模式呢?這就要用到數據庫的規範化理論了。

三、數據庫的規範化理論

3.1 關係模式

關係的描述稱爲關係模式(Relation Schema)它可以形式化地表示爲:R(U,D,dom,F)

  • R爲關係名
  • U爲組成該關係的屬性名集合
  • D爲屬性組U中屬性所來自的域
  • dom爲屬性向域的映象集合
  • F爲屬性間數據的依賴關係集合。

通常簡記爲:R(U)R(A1,A2,…,An)
其中R爲關係名,U爲屬性名集合,A1,A2,…,An爲各屬性名。
簡單來說,表的關係模式就是對錶的結構的描述。

3.2 函數依賴

  • 函數依賴:
    設X,Y是關係R的兩個屬性集合,當任何時刻R中的任意兩個元組中的X屬性值相同時,則它們的Y屬性值也相同,則稱X函數決定Y,或Y函數依賴於X。

  • 平凡函數依賴
    當關系中屬性集合Y是屬性集合X的子集時(Y⊆X),存在函數依賴X→Y,即一組屬性函數決定它的所有子集,這種函數依賴稱爲平凡函數依賴。

  • 非平凡函數依賴
    當關系中屬性集合Y不是屬性集合X的子集時,存在函數依賴X→Y,則稱這種函數依賴爲非平凡函數依賴。

  • 完全函數依賴
    設X,Y是關係R的兩個屬性集合,X’是X的真子集,存在X→Y,但對每一個X’都有X’!→Y,則稱Y完全函數依賴於X。

  • 部分函數依賴
    設X,Y是關係R的兩個屬性集合,存在X→Y,若X’是X的真子集,存在X’→Y,則稱Y部分函數依賴於X。

  • 傳遞函數依賴
    設X,Y,Z是關係R中互不相同的屬性集合,存在X→Y(Y !→X),Y→Z,則稱Z傳遞函數依賴於X。

3.3 候選碼、超碼、主碼、主屬性、非主屬性、全碼

設K爲關係模式R<U,F>中的屬性或屬性組。

  • 若U完全函數依賴於K,則K稱爲R的一個候選碼(候選鍵)
  • 若U部分函數依賴於K,則K稱爲R的一個超碼
  • 若關係模式R中有多個候選碼,則選定其中的一個作爲主碼
  • 包含在任何一個候選碼中的屬性,稱爲主屬性
  • 不包含在任何碼中的屬性稱爲非主屬性或非碼屬性
  • 整個屬性組是候選碼,稱爲全碼

3.4 範式

1NF

如果一個關係模式R的所有屬性都是不可分的基本數據項,則稱其滿足1NF。
在任何一個關係數據庫中,第一範式是對關係模式的基本要求,不滿足第一範式的數據庫就不是關係數據庫。

2NF

若R滿足1NF,並且每個非主屬性都完全函數依賴於R的候選碼,則稱R滿足2NF。

3NF

若R滿足1NF,並且每個非主屬性既不部分依賴於R的候選碼,也不傳遞依賴於候選碼,則稱R滿足3NF

BCNF

若R滿足1NF,並且每個屬性(包括主屬性和非主屬性)既不部分依賴於R的候選碼,也不傳遞依賴於候選碼,則稱R滿足BCNF

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章