概念
首先規範化是爲了解決什麼問題？
用來改造關係模式，通過分解關係模式來消除其中不合適的數據依賴，以解決插入異常、刪除異常、更新異常和數據冗餘問題
插入異常
刪除異常
更新異常
數據冗餘
函數依賴： 若對於R(U)的任意一個可能的關係r，r中不可能存在兩個元組在X上的屬性值相等， 而在Y上的屬性值不等， 則稱 “X函數確定Y” 或 “Y函數依賴於X”，記作X→Y。也就是說 X 與 Y一一對應的 ，X 與Y 可能是單個屬性，也可能是多個屬性的集合
完全函數依賴在R(U)中，如果X→Y，並且對於X的任何一個真子集X’，都有X’→ Y, 則稱Y對X完全函數依賴
若X→Y，但Y不完全函數依賴於X，則稱Y對X**部分函數依賴**。
傳遞函數依賴在R(U)中，如果X→Y，(Y 不屬於 X，且X不依賴於Y) Y→Z， 則稱Z對X傳遞函數依賴。記爲：X → Z
候選碼： 能唯一決定一條記錄的屬性或者屬性的組合
主碼： 候選碼中選一個就可以作爲主碼
主屬性和非主屬性 包含在任何一個候選碼中的屬性，稱爲主屬性，不包含在任何碼中的屬性叫做非主屬性
全碼 整個屬性組是碼，稱爲全碼
範式的種類：
第一範式(1NF)
第二範式(2NF)
第三範式(3NF)
BC範式(BCNF)
第四範式(4NF)
第五範式(5NF)
一個低一級範式的關係模式，通過模式分解可以轉換爲若干個高一級範式的關係模式的集合，這種過程就叫規範化
詳細講解
例子內容轉載自 博客： http://blog.chinaunix.net/space.php?uid=20466300&do=blog&id=1672908
第一範式： 滿足一個關係模式的所有屬性都是不可分的基本數據項，則稱爲第一範式，第一範式是對關係數據庫的最起碼的要求，不滿足第一範式的數據庫模式不能稱爲關係數據庫，滿足第一範式的關係模式並不一定是一個好的關係模式。
第二範式 滿足第一範式，而且每一個非主屬性完全函數依賴於碼
舉例說明：
假定選課關係表爲SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字爲組合關鍵字(學號, 課程名稱)，因爲存在如下決定關係：
(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
這個數據庫表不滿足第二範式，因爲存在如下決定關係：
(課程名稱) → (學分)
(學號) → (姓名, 年齡)
即存在組合關鍵字中的字段決定非關鍵字的情況。
認知： 如果關鍵字中的任意一種組合都可以唯一決定一條非主屬性的記錄，則滿足第二範式。
比如 如果 (學號) 這個字段對應的 (姓名, 年齡, 成績, 學分) 有多條記錄，則其不滿足第二範式
由於不符合2NF，這個選課關係表會存在如下問題：
(1) 數據冗餘：
同一門課程由n個學生選修，”學分”就重複n-1次；同一個學生選修了m門課程，姓名和年齡就重複了m-1次。
(2) 更新異常：
若調整了某門課程的學分，數據表中所有行的”學分”值都要更新，否則會出現同一門課程學分不同的情況。
(3) 插入異常：
假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有”學號”關鍵字，課程名稱和學分也無法記錄入數據庫。
(4) 刪除異常：
假設一批學生已經完成課程的選修，這些選修記錄就應該從數據庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。
把選課關係表SelectCourse改爲如下三個表：
學生：Student(學號, 姓名, 年齡)；
課程：Course(課程名稱, 學分)；
選課關係：SelectCourse(學號, 課程名稱, 成績)。
這樣的數據庫表是符合第二範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
另外，所有單關鍵字的數據庫表都符合第二範式，因爲不可能存在組合關鍵字。
第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在”A → B → C”的決定關係，則C傳遞函數依賴於A。因此，滿足第三範式的數據庫表應該不存在如下依賴關係：
關鍵字段 → 非關鍵字段x → 非關鍵字段y
假定學生關係表爲Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)，關鍵字爲單一關鍵字”學號”，因爲存在如下決定關係：
(學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話)
這個數據庫是符合2NF的，但是不符合3NF，因爲存在如下決定關係：
(學號) → (所在學院) → (學院地點, 學院電話)
即存在非關鍵字段”學院地點”、”學院電話”對關鍵字段”學號”的傳遞函數依賴。
它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。
把學生關係表分爲如下兩個表：
學生：(學號, 姓名, 年齡, 所在學院)；
學院：(學院, 地點, 電話)。
這樣的數據庫表是符合第三範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。
鮑依斯-科得範式（BCNF）：在第三範式的基礎上，數據庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數依賴和部分函數依賴則符合第三範式。
假設倉庫管理關係表爲StorehouseManage(倉庫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範式的，消除了刪除異常、插入異常和更新異常。
總結
- 範式的目的主要是爲了儘量消除關係數據庫中的更新異常、插入異常、刪除異常、數據冗餘問題
-
1NF
↓ 消除非主屬性對碼的部分函數依賴
2NF
↓ 消除非主屬性對碼的傳遞函數依賴
3NF
↓ 消除主屬性對碼的部分和傳遞函數依賴
BCNF - 不能說規範化程度越高的關係模式就越好，在設計數據庫模式結構時必須對現實世界的實際情況和用戶應用需求作進一步分析，確定一個合適的、能夠反映現實世界的模式，上面的規範化步驟可以在其中任何一步終止
部分內容轉載自 博客： http://blog.chinaunix.net/space.php?uid=20466300&do=blog&id=1672908