一： 引言
作為一個數據庫的學習者，搞懂關系數據庫的三大范式是很有用的。然而教科書上有關數據庫范式的介紹都是采用學術性的定義，語法羞澀，讓人難懂，故寫下自己對數據庫范式的理解，給初學者提供幫助，也備日后查看。
本文不介紹規范化程度高於3NF的范式，因為其在實際應用中基本不會用到，原因也是很明顯的（查詢代價變大），因此，對於很多大型復雜的系統，其數據庫設計都沒有遵循所謂的范式，這也是為什么會出現所謂的逆規范化，好了，進入正題吧。
二： 范式介紹
a：第零范式
第零范式就是指沒有使用任何范式的設計，其添加數據的行為非常詭異，看看下表便知：
假設一個學生學習了三門課程，每門課程都有成績，那么，采用第零范式的設計將會是如下情況
表a_0
這樣的話，會使得往表中添加數據變得非常麻煩，每次添加一個新的數據，都要添加相應的字段，而且，因為表中其他的記錄可能不需要這么多字段，因此會浪費
很多空間。如表a_1所示。
表a_1
由此可以看出，不對數據庫任用任何范式是非常愚蠢的，因為不僅會產生大量無用的表字段，而且會使得表結構非常難以維護。由此，引出第一范式的介紹
b: 第一范式
第一范式就是在第零范式的基礎上進行的改進，網上有很多人認為，所謂第一范式就是指表中的所有字段都是原子的、不可再分的，我個人認為此種理解也是正確的，原因不解釋，我對第一范式的理解是，將
第零范式中重復的字段抽取出來，作為表的數據，從而形成一個穩定的、冗余數據少得表結構。
由此，可以得出符合第一范式的表結構應該是：
此時，表的結構變得穩定了，而且表中的冗余信息相對第零范式也少了很多。可是，第一范式只是關系數據庫設計的最低滿足的范式，第一范式中仍然有很多的冗余信息，由此，需要引入第二范 式。
c: 第二范式
第二范式是滿足屬性對主鍵是完全函數依賴的，因此，滿足第二范式的表當然也是滿足第一范式的，第二范式的目的就是消除表中的部分依賴。
這里，有幾個概念要解釋下，
1： 完全函數依賴
設有屬性集K和P，若K中的所有屬性共同能夠推出P中的任意屬性，且對於K的任何真子集，都不能推出P中的任意屬性，則成K完全函數依賴P。
2： 部分函數依賴
與上相似，只是，K中存在真子集使得，該子集能推出p中任意屬性。
概念性的東西，往往都難懂，舉個例子，方便大家理解：
假如有一張學生成績表，包含如下屬性(學生Id，課程Id，課程分數，學生名字)，其中，主鍵為(學生id，課程id)，表中的數據如下：
那么，此時這張表的設計就不滿足第二范式， 因為 主鍵(學生id，課程id) 能夠唯一確定學生的姓名，因此，不滿足屬性完全函數依賴主鍵，因此不是第二范式。
從上面的表數據易知，不滿足第二范式的表至少有以下幾個缺點：
1：數據重復，浪費空間，因為每存一條記錄，都要存學生的名字，這樣就是得存在大量重復的數據。
2: 插入異常，若學生還沒有成績，那么這個學生就沒有名字。
3： 更新異常，刪除異常等
解決方法：
將student_name字段放入學生表中，即消除表中的部分依賴。
d: 第三范式
第三范式是指在滿足第二范式的情況下，消除表中的傳遞依賴。
所謂傳遞依賴，就是指x-->y,y-->z,那么可以得到y-->z.
傳遞依賴常發生在主鍵、外鍵、外鍵相關的屬性上，例如，假設有這樣的表
學生表(學生id，學生姓名，院系id，院系名) ，此處主鍵為（學生id），外鍵為(院系id)
院系表(院系id，院長名稱)，主鍵為 （院系id）
很明顯，此處存在傳遞依賴，因為 學生id 可以唯一確定 院系id，而 院系id 可以唯一確定 院系名。
表中的數據如下
從上面的表數據易知，不滿足第三范式的表至少有以下幾個缺點：
1 ： 數據重復，浪費空間，因為學生表每存一條記錄，都會記錄住院系的名字，存在大量的重復數據。
2： 插入異常，若新建一個院系，而該院系沒有學生的話，該院系就沒有名字。
3： 更新異常，刪除異常等
三： 數據庫設計的經驗
1: 表的數目不要太多，一般20-30張就夠了。如果表的數目太多，則可以考慮采用同化操作，即將大體相同的實體放入到一張表中。
2：當數據庫中的信息非常龐大時，不要使用外鍵(逆規范化)，因為由此可能帶來非常大的性能損失。
3：一般以消耗存儲空間來換取效率。
原創，轉載請標明來自：http://www.cnblogs.com/ulli/archive/2012/02/26/2367910.html