數據庫范式的提出是為了對關系數據庫中的數據進行規范而提出的一個概念，第一范式，第二范式，第三范式這三個范式逐漸對數據進行細分，意思就是指屬於這三種范式之一的關系數據庫的數據相互之間的依賴關系越來越清晰明了。下面對三種范式進行詳細的講解。
第一范式（1NF）：屬於第一范式的數據庫的表的列（屬性）是不能再進一步拆分的。如
| 學號 | 課程 |
| 2014212797 | 軟件技術基礎 高數 |
很顯然，這個表格的第二列是可以在細分的，所以不屬於第一范式。第一范式是數據庫數據的最低要求，不滿足第一范式的的“數據庫”不能稱為關系數據庫，在非規范化數據去掉組合項。
| 學號 | 課程 |
| 2014212797 | 軟件技術基礎 |
| 2014212798 | 高數 |
第一范式會出現數據冗余、插入、刪除異常現象。（比如上面表格中學號的重復現象）
第二范式（2NF）:首先得滿足第一范式的條件，並且表中必須要有一個主鍵，同時不屬於主鍵的屬性（意思是主鍵可以是幾個屬性）必須完全依賴於主鍵（這句話有點繞，好好理解下），即設置好某個表的屬性后可以根據這個主鍵檢索得到唯一的一個屬性，而不能得到幾個結果。如果出現的部分依賴的屬性則應當將該屬性與主鍵的依賴部分單獨分離出來，單獨建立一個表。第二范式的任務就是在滿足第一范式的條件下消除部分函數依賴。
學號 | 姓名 | 郵箱 | 課程號 | 課程地址
2323 lf ddd 123 345
2323 lj dsd 345 3789
顯然這個表屬於第一范式，主鍵（由學號與課程地址）能定位到唯一一行。但是課程地址部分依賴於課程號，與學號無聯系，所以該數據庫不屬於第二范式。所以需要講部分依賴的主鍵與屬性單獨建立一個表。原表變為兩個表：
學號 | 姓名 | 郵箱 | 課程號
2323 lf ddd 123
2323 lj dsd 345
課程號 | 課程地址
123 34
345 3789
不符合第二范式的數據庫容易產生數據冗余
第三范式（3NF）：首先滿足第二范式，同時不能存在傳遞性依賴。即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。
簡而言之，第三范式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么在的員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三范式（3NF）也應該構建它，否則就會有大量的數據冗余。簡而言之，第三范式就是屬性不依賴於其它非主屬性。
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male kkkk@ee.net 優秀 $1000
20040902 mary famale kkk@fff.net 良 $600
這個完全滿足了第二范式,但是bounsLevel和bouns存在傳遞依賴
更改為：
StudyNo | Name | Sex | Email | bouunsNo
20040901 john Male kkkk@ee.net 1
20040902 mary famale kkk@fff.net 2
bounsNo | bounsLevel | bouns
1 優秀 $1000
2 良 $600
表中bounsNo作為主鍵
一般符合第三范式的關系數據庫能夠避免數據冗余的情況。
本文參考了一下幾篇博文：
http://blog.csdn.net/sunzhenhua0608/article/details/16850053
http://blog.csdn.net/famousdt/article/details/6921622
學生管理系統：http://www.cnblogs.com/nx520zj/archive/2013/05/29/3105725.html