一： 引言
作爲一個數據庫的學習者，搞懂關係數據庫的三大範式是很有用的。然而教科書上有關數據庫範式的介紹都是採用學術性的定義，語法羞澀，讓人難懂，故寫下自己對數據庫範式的理解，給初學者提供幫助，也備日後查看。
本文不介紹規範化程度高於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：一般以消耗存儲空間來換取效率。