數據庫范式1NF 2NF 3NF BCNF(實例）

??? 設計范式（范式,數據庫設計范式,數據庫的設計范式）是符合某一種級別的關系模式的集合。構造數據庫必須遵循一定的規則。在關系數據庫中，這種規則就是范式。關系數據庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系數據庫有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎上進一步滿足更多要求的稱為第二范式（2NF），其余范式以次類推。一般說來，數據庫只需滿足第三范式（3NF）就行了。下面我們舉例介紹第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

關系數據庫的幾種設計范式介紹

1 第一范式（1NF）: 數據庫表的每一列都是不可分割的基本數據項

??? 在任何一個關系數據庫中，第一范式（1NF）是對關系模式的基本要求，不滿足第一范式（1NF）的數據庫就不是關系數據庫。
??? 所謂第一范式（1NF）是指數據庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值。

2 第二范式（2NF）：數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴

??? 第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如圖3-2 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。
第二范式（2NF）要求實體的屬性完全依賴于主關鍵字 。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性。

3 第三范式（3NF）：數據庫表中不包含已在其它表中已包含的非主關鍵字信息

第三范式首先一定是一個第二范式

數據庫表是符合第二范式的， 消除了數據冗余、更新異常、插入異常和刪除異常。?

數據庫表是符合第三范式的，消除了數據冗余、更新異常、插入異常和刪除異常。

??? 我們來逐步搞定一個論壇的數據庫，有如下信息：
??? （1） 用戶：用戶名，email，主頁，電話，聯系地址
??? （2） 帖子：發帖標題，發帖內容，回復標題，回復內容

??? 第一次我們將數據庫設計為僅僅存在表：
??? 用戶名 email 主頁 電話 聯系地址 發帖標題 發帖內容 回復標題 回復內容
??? 這個數據庫表符合第一范式，但是沒有任何一組候選關鍵字能決定數據庫表的整行，唯一的關鍵字段用戶名也不能完全決定整個元組。我們需要增加"發帖ID"、"回復ID"字段，即將表修改為：
??? 用戶名 email 主頁 電話 聯系地址 發帖ID 發帖標題 發帖內容 回復ID 回復標題 回復內容?
??? 這樣數據表中的關鍵字(用戶名，發帖ID，回復ID)能決定整行：
??? (用戶名,發帖ID,回復ID) → (email,主頁,電話,聯系地址,發帖標題,發帖內容,回復標題,回復內容)
??? 但是，這樣的設計不符合第二范式，因為存在如下決定關系：
??? (用戶名) → (email,主頁,電話,聯系地址)
??? (發帖ID) → (發帖標題,發帖內容)
??? (回復ID) → (回復標題,回復內容)
??? 即非關鍵字段部分函數依賴于候選關鍵字段，很明顯，這個設計會導致大量的數據冗余和操作異常。

我們將數據庫表分解為（帶下劃線的為關鍵字）：
（1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：發帖ID，標題，內容
（3） 回復信息：回復ID，標題，內容
（4） 發貼：用戶名，發帖ID
（5） 回復：發帖ID，回復ID

??? 這樣的設計是滿足第1、2、3范式和BCNF范式要求的，但是這樣的設計是不是最好的呢？
不一定。

??? 觀察可知，第4項"發帖"中的"用戶名"和"發帖ID"之間是1：N的關系，因此我們可以把"發帖"合并到第2項的"帖子信息"中；第5項"回復"中的"發帖ID"和"回復ID"之間也是1：N的關系，因此我們可以把"回復"合并到第3項的"回復信息"中。這樣可以一定量地減少數據冗余，新的設計為：
（1） 用戶信息：用戶名，email，主頁，電話，聯系地址
（2） 帖子信息：用戶名，發帖ID，標題，內容
（3） 回復信息：發帖ID，回復ID，標題，內容

??? 數據庫表1顯然滿足所有范式的要求；

??? 數據庫表2中存在非關鍵字“標題”、“內容”對關鍵字段“發帖ID”的部分函數依賴，即不滿足第二范式的要求，但是這一設計并不會導致數據冗余和操作異常；

??? 數據庫表3中也存在非關鍵字段"標題"、"內容"對關鍵字段"回復ID"的部分函數依賴，也不滿足第二范式的要求，但是與數據庫表2相似，這一設計也不會導致數據冗余和操作異常。

??? 由此可以看出，并不一定要強行滿足范式的要求，對于1：N關系，當1的一邊合并到N的那邊后，N的那邊就不再滿足第二范式了，但是這種設計反而比較好！

??? 對于M：N的關系，不能將M一邊或N一邊合并到另一邊去，這樣會導致不符合范式要求，同時導致操作異常和數據冗余。

??? 對于1：1的關系，我們可以將左邊的1或者右邊的1合并到另一邊去，設計導致不符合范式要求，但是并不會導致操作異常和數據冗余。

結論

??? 滿足范式要求的數據庫設計是結構清晰的，同時可避免數據冗余和操作異常。這并意味著不符合范式要求的設計一定是錯誤的，在數據庫表中存在1：1或1：N關系這種較特殊的情況下，合并導致的不符合范式要求反而是合理的。

??? 在我們設計數據庫的時候，一定要時刻考慮范式的要求。

?

數據庫的范式：1NF,2NF,3NF