關系數據庫中的關系必須滿足一定的要求。滿足不同程度要求的為不同范式。數據庫的設計范式是數據庫設計所需要滿足的規范。只有理解數據庫的設計范式，才能設計出高效率、優雅的數據庫，否則可能會設計出錯誤的數據庫.

目前，主要有六種范式：第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。滿足最低要求的叫第一范式，簡稱1NF。在第一范式基礎上進一步滿足一些要求的為第二范式，簡稱2NF。其余依此類推。

范式可以避免數據冗余，減少數據庫的空間，減輕維護數據完整性的麻煩，但是操作困難，因為需要聯系多個表才能得到所需要數據，而且范式越高性能就會越差。要權衡是否使用更高范式是比較麻煩的，一般在項目中，用得最多的也就是第三范式，我認為使用到第三范式也就足夠了，性能好而且方便管理數據。

函數依賴,如果一個表中某一個字段Y的值是由另外一個字段或一組字段X的值來確定的，就稱為Y函數依賴于X。?

第一范式(1NF)
定義：如果關系模式R的每個關系r的屬性都是不可分的數據項，那么就稱R是第一范式的模式。
簡單的說，每一個屬性都是原子項，不可分割。
1NF是關系模式應具備的最起碼的條件，如果數據庫設計不能滿足第一范式，就不稱為關系型數據庫。關系數據庫設計研究的關系規范化是在1NF之上進行的。

例如(學生信息表)：
學生編號　　姓名　　性別　　聯系方式
20080901　　張三　　男　　　email:zs@126.com,phone:88886666
20080902　　李四　　女　　　email:ls@126.com,phone:66668888

以上的表就不符合，第一范式：聯系方式字段可以再分，所以變更為正確的是：

學生編號　　姓名　　性別　　電子郵件　　　電話
20080901　　張三　　男　　　zs@126.com　　88886666
20080902　　李四　　女　　　ls@126.com　　66668888

第二范式（2NF）
定義：如果關系模式R是1NF，且每個非主屬性 完全函數依賴(往后看) 于候選鍵，那么就稱R是第二范式。
簡單的說，第二范式要滿足以下的條件：首先要滿足第一范式，其次每個非主屬性要完全函數依賴與候選鍵，或者是主鍵。也就是說，每個非主屬性是由整個主鍵函數決定的，而不能由主鍵的一部分來決定。

例如(學生選課表):
學生　　　　課程　　　教師　　　　教師職稱　　教材　　　　　　　　　教室　　上課時間
李四　　　　Spring　　張老師　　　java講師　　《Spring深入淺出》　?。常埃薄?8:00
張三　　　　Struts　　楊老師　　　java講師　　《Struts in Action》?。常埃病?3:30

這里通過（學生，課程）可以確定教師、教師職稱，教材，教室和上課時間，所以可以把（學生，課程）作為主鍵。但是，教材并不完全依賴于（學生，課程），只拿出課程就可以確定教材，因為一個課程，一定指定了某個教材。這就叫不完全依賴，或者部分依賴。出現這種情況，就不滿足第二范式。

修改后，選課表：
學生　　　　課程　　　教師　　　　教師職稱　　教室　　上課時間
李四　　　　Spring　　張老師　　　java講師　?。常埃薄?8:00
張三　　　　Struts　　楊老師　　　java講師　?。常埃病?3:30

課程表：
課程　　　教材　　　　　　　　
Spring　　《Spring深入淺出》　
Struts　　《Struts in Action》

所以，第二范式可以說是消除部分依賴。第二范式可以減少插入異常，刪除異常和修改異常。

第三范式（3NF）
定義：如果關系模式R是2NF，且關系模式R（U，F）中的所有非主屬性對任何候選關鍵字都不存在傳遞依賴，則稱關系R是屬于第三范式。?
簡單的說，第三范式要滿足以下的條件：首先要滿足第二范式，其次非主屬性之間不存在函數依賴。由于滿足了第二范式，表示每個非主屬性都函數依賴于主鍵。如果非主屬性之間存在了函數依賴，就會存在傳遞依賴，這樣就不滿足第三范式。

上例中修改后的選課表中，一個教師能確定一個教師職稱。這樣，教師依賴于（學生，課程），而教師職稱又依賴于教師，這叫傳遞依賴。 第三范式就是要消除傳遞依賴。

修改后，選課表：

學生　　　　課程　　　教師　　　　教室　　上課時間
李四　　　　Spring　　張老師　　?。常埃薄?8:00
張三　　　　Struts　　楊老師　　?。常埃病?3:30

教師表：
教師　　　　教師職稱
張老師　　　java講師
楊老師　　　java講師

這樣，新教師的職稱在沒被選課的時候也有地方存了，沒人選這個教師的課的時候教師的職稱也不至于被刪除，修改教師職稱時只修改教師表就可以了。

簡單的說，
第一范式就是原子性，字段不可再分割；
第二范式就是完全依賴，沒有部分依賴；
第三范式就是沒有傳遞依賴。

關系數據庫之 三個范式