數據庫設計三范式

定義

• 按照《數據庫系統概論》中的定義，范式是“符合某一種級別的關系模式的集合，表示一個關系內部各屬性之間的聯系的合理化程度”。簡單來說，范式就是一張數據表中符合某種設計標準的級別。打個比方：電器的能耗級別有1級，2級，3級等等。符合高一級范式的設計，必定符合低一級范式。
  ji

第一范式

• 符合1NF的關系中的每個屬性都不可再分。
• 不符合第一范式的例子：

  學號	姓名	聯系方式
  001	張三	zhangsan001@aa.com,15331231
  002	李四	lisi002@aa.com,1231313

  表1
  • 聯系方式這個屬性包含了郵箱和電話號碼，是可以拆分開的
• 如果我們要設計上面的數據表，應該是如下的形式

  學號	姓名	郵箱	電話號碼
  001	張三	zhangsan001@aa.com	15331231
  002	李四	lisi002@aa.com	1231313

  表2
• 1NF設計可能存在的問題：
  • 數據冗余過大
  • 插入異常
  • 修改異常
  • 刪除異常
• 例如下面的這個數據表

  學號	姓名	系名	系主任	課程名稱	分數
  11001	張三	計算機	王五	數據結構	90
  11001	張三	計算機	王五	C語言	80
  11001	張三	計算機	王五	操作系統	90
  12002	李四	經濟	趙六	高等數學	80
  12002	李四	經濟	趙六	大學英語	90
  12002	李四	經濟	趙六	微觀經濟學	85

  表3
• 這個數據表存在幾個問題:
  • 數據冗余過大
    • 每一名學生的學號、姓名、系名、系主任這些數據重復多次。每個系與對應的系主任的數據也重復多次
  • 插入異常
    • 假如學校新開了一個系，但是暫時還沒有招收任何學生，那么是無法存儲系名與系主任信息的
  • 刪除異常
    • 假如某個系中所有學生的記錄都刪除，那么系與系主任的數據也隨之消失了(一個系所有學生都沒有了，并不表示這個系就沒有了)
  • 修改異常
    • 假如某個學生轉系了，那么需要修改多條記錄中系與系主任的數據來保證數據庫的一致性

第2范式

• 因為僅僅符合1NF范式的數據表設計中存在問題，所以我們需要提高標準，去掉導致上述問題的因素，使其符合更高一級的范式。
• 2NF在1NF的基礎之上，消除了非主屬性對于碼的部分函數依賴。

幾個定義

函數依賴

• 若在一張表中，在屬性（或屬性組）X的值確定的情況下，必定能確定屬性Y的值，那么就可以說Y函數依賴于X，寫作 X → Y。也就是說，在一張數據表中，不存在任意兩條記錄，它們在X屬性（或屬性組）上的值相同，而在Y屬性上的值不同。
• 例如，對于表3中的數據，找不到任何一條記錄，它們的學號相同而對應的姓名不同。所以我們可以說姓名函數依賴于學號，寫作 學號 → 姓名。
  但是反過來，因為可能出現同名的學生，所以有可能不同的兩條學生記錄，它們在姓名上的值相同，但對應的學號不同，所以我們不能說學號函數依賴于姓名。
• 表中其他的函數依賴關系還有如：
  • 系名 → 系主任
  • 學號 → 系主任
  • （學號，課名） → 分數

完全函數依賴

• 在一張表中，若 X → Y，且對于 X 的任何一個真子集（假如屬性組 X 包含超過一個屬性的話），X ' → Y 不成立，那么我們稱 Y 對于 X 完全函數依賴
• 例如 （學號，課名） → 分數

部分函數依賴

• 假如 Y 函數依賴于 X，但同時 Y 并不完全函數依賴于 X，那么我們就稱 Y 部分函數依賴于 X
• 例如（學號，課名） P→ 姓名

傳遞函數依賴

• 假如 Z 函數依賴于 Y，且 Y 函數依賴于 X，那么就稱 Z 傳遞函數依賴于 X

碼

• 設 K 為某表中的一個屬性或屬性組，若除 K 之外的所有屬性都完全函數依賴于 K），那么我們稱 K 為候選碼，簡稱為碼。
• 可以理解為：假如當 K 確定的情況下，該表除 K 之外的所有屬性的值也就隨之確定，那么 K 就是碼。一張表中可以有超過一個碼。（實際應用中為了方便，通常選擇其中的一個碼作為主碼(主鍵)）
• 例如：
  對于表3，（學號、課名）這個屬性組就是碼。該表中有且僅有這一個碼。（假設所有課沒有重名的情況）

• 回過頭來看表3的設計。 根據2NF的定義，判斷的依據實際上就是看數據表中是否存在非主屬性對于碼的部分函數依賴。若存在，則數據表最高只符合1NF的要求，若不存在，則符合2NF的要求。判斷的方法是：

  • 第一步：找出數據表中所有的碼。
    • 表3的碼只有一個： （學號、課名）
  • 第二步：根據第一步所得到的碼，找出所有的主屬性。
    • 主屬性有兩個： 1. 學號 2.課名
  • 第三步：數據表中，除去所有的主屬性，剩下的就都是非主屬性了。
    • 非主屬性有四個：姓名、系名、系主任、分數
  • 第四步：查看是否存在非主屬性對碼的部分函數依賴。
    • 對于（學號，課名） → 姓名，有 學號 → 姓名，存在非主屬性 姓名 對碼（學號，課名）的部分函數依賴。
    • 對于（學號，課名） → 系名，有 學號 → 系名，存在非主屬性 系名 對碼（學號，課名）的部分函數依賴。
    • 對于（學號，課名） → 系主任，有 學號 → 系主任，存在非主屬性 對碼（學號，課名）的部分函數依賴。

• 如何消除這些部分函數依賴？

  • 可以通過將大數據表拆分成兩個或者更多個更小的數據表
  • 例如將表3拆分為課程表（學號，課名，分數）與學生表（學號，姓名，系名，系主任）
  • 課程表

    學號	課程名稱	分數
    11001	數據結構	90
    11001	C語言	80
    11001	操作系統	90
    12002	高等數學	80
    12002	大學英語	90
    12002	微觀經濟學	85

  • 學生表
    學號 | 姓名 | 系名 | 系主任 |
    ---|---| ---| ---| ---| ---|
    11001 | 張三 | 計算機 | 王五 |
    12002 | 李四 | 經濟 | 趙六 |
    表4

• 這樣的改進是否有效？

  • 數據冗余過大
    • 學生的姓名、系名與系主任，不再像之前一樣重復那么多次了 --- 有改進
  • 插入異常
    • 因為學生表的碼是學號，不能為空，所以無法操作 --- 無改進
  • 刪除異常
    • 假如某個系中所有學生的記錄都刪除，那么系與系主任的數據也隨之消失了 --- 無改進
  • 修改異常
    • 假如某個學生轉系了，只需要修改這名學生對應的系名即可 --- 有改進

• 僅僅符合2NF的要求，很多情況下還是不夠的，而出現問題的原因，在于仍然存在非主屬性系主任對于 碼 學號的傳遞函數依賴。

第三范式（3NF）

• 3NF在2NF的基礎之上，消除了非主屬性對于碼的傳遞函數依賴。
• 在表4的課程表中，主碼為（學號，課名），主屬性為學號和課名，非主屬性只有一個分數，不可能存在傳遞函數依賴，所以選課表的設計，符合3NF的要求。
• 在表4的學生表中，主碼為學號，主屬性為學號，非主屬性為姓名、系名和系主任。因為 學號 → 系名，同時 系名 → 系主任，所以存在非主屬性系主任對于碼學號的傳遞函數依賴。
• 知道了為什么會有傳遞函數依賴，那我們就可以通過拆分數據表來解決這個問題：
  • 課程表

    學號	課程名稱	分數
    11001	數據結構	90
    11001	C語言	80
    11001	操作系統	90
    12002	高等數學	80
    12002	大學英語	90
    12002	微觀經濟學	85

  • 學生表
    學號 | 姓名 | 系名 |
    ---|---| ---| ---| ---|
    11001 | 張三 | 計算機 |
    12002 | 李四 | 經濟 |
  • 系
    系名 | 系主任 |
    ---| ---| ---|
    計算機 | 王五 |
    經濟 | 趙六 |
• 這樣的改進是否有效？
  • 數據冗余過大
    • 數據冗余更少了 --- 有改進
  • 插入異常
    • 因為系表與學生表目前是獨立的兩張表，所以不影響 --- 有改進
  • 刪除異常
    • 信息不會丟失 --- 有改進
  • 修改異常
    • 同2NF

結論

符合3NF要求的數據庫設計，基本上解決了數據冗余過大，插入異常，修改異常，刪除異常的問題。在實際中，為了應對業務中的需要，往往不會嚴格地遵循3NF范式，具體的使用場景還是要具體來分析。