資料庫正規化是資料庫設計中必不可少的知識，沒有對正規化的理解，就無法設計出高效率、優雅的資料庫。甚至設計出錯誤的資料庫。而想要理解並掌握正規化卻並不是那麼容易。教科書中一般以關係代數的方法來解釋資料庫正規化。這樣做雖然能夠十分準確的表達資料庫正規化，但比較抽象，不太直觀，不便於理解，更難以記憶。
　　本文用較為直白的語言介紹正規化，旨在便於理解和記憶，這樣做可能會出現一些不精確的表述。但對於初學者應該是個不錯的入門。我寫下這些的目的主要是為了加強記憶，其實我也比較菜，我希望當我對一些概念生疏的時候，回過頭來看看自己寫的筆記，可以快速地進入狀態。如果你發現其中用錯誤，請指正。
下面開始進入正題：

一、基礎概念
　　要理解正規化，首先必須對知道什麼是關係資料庫，如果你不知道，我可以簡單的不能再簡單的說一下：關係資料庫就是用二維表來儲存資料。表和表之間可以……（省略10W字）。

然後你應該理解以下概念：

實體：現實世界中客觀存在並可以被區別的事物。比如“一個學生”、“一本書”、“一門課”等等。值得強調的是這裡所說的“事物”不僅僅是看得見摸得著的“東西”，它也可以是虛擬的，比如說“老師與學校的關係”。

屬性：教科書上解釋為：“實體所具有的某一特性”，由此可見，屬性一開始是個邏輯概念，比如說，“性別”是“人”的一個屬性。在關係資料庫中，屬性又是個物理概念，屬性可以看作是“表的一列”。

元組：表中的一行就是一個元組

分量：元組的某個屬性值。在一個關係資料庫中，它是一個操作原子，即關係資料庫在做任何操作的時候，屬性是“不可分的”。否則就不是關係資料庫了。

碼：表中可以唯一確定一個元組的某個屬性（或者屬性組），如果這樣的碼有不止一個，那麼大家都叫候選碼，我們從候選碼中挑一個出來做老大，它就叫主碼。

全碼：如果一個碼包含了所有的屬性，這個碼就是全碼。

主屬性：一個屬性只要在任何一個候選碼中出現過，這個屬性就是主屬性。

非主屬性：與上面相反，沒有在任何候選碼中出現過，這個屬性就是非主屬性。

外碼：一個屬性（或屬性組），它不是碼，但是它別的表的碼，它就是外碼。

二、6個正規化
好了，上面已經介紹了我們掌握正規化所需要的全部基礎概念，下面我們就來講正規化。首先要明白，正規化的包含關係。一個數據庫設計如果符合第二正規化，一定也符合第一正規化。如果符合第三正規化，一定也符合第二正規化……

·第一正規化（1NF）：屬性不可分。

在前面已經介紹了屬性值的概念，我們說，它是“不可分的”。而第一正規化要求屬性也不可分。那麼它和屬性值不可分有什麼區別呢？給一個例子：

這個表中，屬性值“分”了。“電話”這個屬性裡對於“小明”屬性值分成了兩個。

這兩種情況都不滿足第一正規化。不滿足第一正規化的資料庫，不是關係資料庫！所以，我們在任何關係資料庫管理系統中，做不出這樣的“表”來。針對上述情況可以做成這樣的表：這個表中，屬性 “分”了。也就是“電話”分為了“手機”和“座機”兩個屬性。

·第二正規化（2NF）：符合1NF，並且，非主屬性完全依賴於碼。（注意是完全依賴不能是部分依賴，設有函式依賴W→A，若存在XW，有X→A成立，那麼稱W→A是區域性依賴，否則就稱W→A是完全函式依賴）

一個學生上一門課，一定是特定某個老師教。所以有（學生，課程）－>老師；

一個學生上一門課，一定在特定某個教室。所以有（學生，課程）－>教室；

一個學生上一門課，他老師的職稱可以確定。所以有（學生，課程）－>老師職稱；

一個學生上一門課，一定是特定某個教材。所以有（學生，課程）－>教材

一個學生上一門課，一定在特定時間。所以有（學生，課程）－>上課時間

因此（學生，課程）是一個碼。

然而，一個課程，一定指定了某個教材，一年級語文肯定用的是《小學語文1》，那麼就有課程－>教材。（學生，課程）是個碼，課程卻決定了教材，這就叫做不完全依賴，或者說部分依賴。出現這樣的情況，就不滿足第二正規化！

有什麼不好嗎？你可以想想：

1、校長要新增加一門課程叫“微積分”，教材是《大學數學》，怎麼辦？學生還沒選課，而學生又是主屬性，主屬性不能空，課程怎麼記錄呢，教材記到哪呢? ……鬱悶了吧?(插入異常)

2、下學期沒學生學一年級語文（上）了，學一年級語文（下）去了，那麼表中將不存在一年級語文（上），也就沒了《小學語文1》。這時候，校長問：一年級語文（上）用的什麼教材啊？……鬱悶了吧?(刪除異常)

3、校長說：一年級語文（上）換教材，換成《大學語文》。有10000個學生選了這門課，改動好大啊！改累死了……鬱悶了吧？（修改/更新異常，在這裡你可能覺得直接把教材《小學語文1》替換成《大學語文》不就可以了，但是替換操作雖然計算機執行速度很快，但是畢竟也要替換10000次，造成了很大的時間開銷）

那應該怎麼解決呢？投影分解，將一個表分解成兩個或若干個表

·第三正規化（3NF）：符合2NF，並且，消除傳遞依賴（也就是每個非主屬性都不傳遞依賴於候選鍵，判斷傳遞函式依賴，指的是如果存在"A → B → C"的決定關係，則C傳遞函式依賴於A。）

上面的“學生上課新表”符合2NF，但是它有傳遞依賴！在哪呢？問題就出在“老師”和“老師職稱”這裡。一個老師一定能確定一個老師職稱。（學生，課程）->老師->職稱。

有什麼問題嗎？想想：

1、老師升級了，變教授了，要改資料庫，表中有N條，改了N次……（修改異常）
2、沒人選這個老師的課了，老師的職稱也沒了記錄……（刪除異常）
3、新來一個老師，還沒分配教什麼課，他的職稱記到哪？……（插入異常）
那應該怎麼解決呢？和上面一樣，投影分解：

·BC正規化（BCNF）：符合3NF，並且，主屬性不依賴於主屬性(也就是不存在任何欄位對任一候選關鍵欄位的傳遞函式依賴)

BC正規化既檢查非主屬性，又檢查主屬性。當只檢查非主屬性時，就成了第三正規化。滿足BC正規化的關係都必然滿足第三正規化。

還可以這麼說：若一個關係達到了第三正規化，並且它只有一個候選碼，或者它的每個候選碼都是單屬性，則該關係自然達到BC正規化。

給你舉個例子：假設倉庫管理關係表 (倉庫ID, 儲存物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以儲存多種物品。

這個資料庫表中存在如下決定關係：

(倉庫ID, 儲存物品ID) →(管理員ID, 數量)

(管理員ID, 儲存物品ID) → (倉庫ID, 數量)

所以，(倉庫ID, 儲存物品ID)和(管理員ID, 儲存物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵欄位為數量，它是符合第三正規化的。但是，由於存在如下決定關係：

(倉庫ID) → (管理員ID)

(管理員ID) → (倉庫ID)

即存在關鍵欄位決定關鍵欄位的情況，所以其不符合BCNF正規化。它會出現如下異常情況：

(1) 刪除異常：

當倉庫被清空後，所有"儲存物品ID"和"數量"資訊被刪除的同時，"倉庫ID"和"管理員ID"資訊也被刪除了。

(2) 插入異常：

當倉庫沒有儲存任何物品時，無法給倉庫分配管理員。

(3) 更新異常：

如果倉庫換了管理員，則表中所有行的管理員ID都要修改。

把倉庫管理關係表分解為二個關係表：

倉庫管理：StorehouseManage(倉庫ID, 管理員ID)；

倉庫：Storehouse(倉庫ID, 儲存物品ID, 數量)。

這樣的資料庫表是符合BCNF正規化的，消除了刪除異常、插入異常和更新異常。

一般，一個數據庫設計符合3NF或BCNF就可以了。在BC正規化以上還有第四正規化、第五正規化。

·第四正規化：要求把同一表內的多對多關係刪除。

·第五正規化：從最終結構重新建立原始結構。

其實資料庫設計正規化這方面重點掌握的就是1NF、2NF、3NF、BCNF

四種正規化之間存在如下關係：

這裡主要區別3NF和BCNF，一句話就是3NF是要滿足不存在非主屬性對候選碼的傳遞函式依賴，BCNF是要滿足不存在任一屬性（包含非主屬性和主屬性）對候選碼的傳遞函式依賴。