-
引言
關系型數據庫是現在廣泛應用的數據庫類型，對關系型數據庫的設計就是對數據進行組織化和結構化的過程。對於小規模的數據庫我們處理起來還是比較輕松地，但是隨着數據庫規模的擴大我們將發現用戶操控數據庫的SQL語句將變得笨拙、復雜。更糟糕的是很有可能導致數據不完整，不准確。所以我們有必要將數據設計的更加符合規范。
怎樣使我們的數據庫更加規范呢，前人總結了三個范式（其實一共有五個，但是一般的數據庫只需滿足三個就已經很高效了。）
-
主要內容：
注意：斜體字部分為邏輯性語言，不容易理解，但很准確；粗體字部分為通俗語言，容易理解，但有失准確。
l 第一范式（1NF）：數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。
換句話說：能分就分，分到不能分為止！
例1：
原表1
上表中“地點”字段中的值就不符合第一范式。正確的做法應該是把大地點和小地點分開，保持每列的原子性，即不可分割性，如下表：
修改后的表
l 第二范式（2NF）：在滿足第一范式的基礎上，數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的情況），也即所有非關鍵字段都完全依賴於任意一組候選關鍵字。（另外，所有單關鍵字的數據庫表都符合第二范式，因為不可能存在組合關鍵字。）
也就是說：
1、 盡可能的使用單關鍵字吧！
2、 每個表只表述一個事，別傻乎乎的把所有信息都放到一個表里！
例2：
原表2
上表滿足第一范式，即每個字段具有不可再分性。但是不滿足第二范式。從表可以看出組合關鍵字為（學號，課程名稱），但表中“學分”完全依賴“課程名稱”，而“姓名”和“年齡”完全依賴“學號”。也就是說在這一張表里描述了兩個事情：學生信息、課程信息。
這樣的后果是
(1) 數據冗余：同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。
(2) 更新異常：若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。
(3) 插入異常：假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入數據庫。
(4) 刪除異常：假設一批學生已經完成課程的選修，這些選修記錄就應該從數據庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。
修改后如下：
學生表
課程表
成績表
l 第三范式（3NF）：在第二范式的基礎上，數據表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴則符合第三范式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴於A。也就是說表中的字段和主鍵直接對應不依靠其他的中間字段。
說白了：決定某字段值的必須是主鍵！
例3：
原表3
可以看出表中的學院地點依賴於學院，學院依賴於學號，學院電話同理。所以這不符合第三范式，這樣的結果同樣會造成上述不良后果
(1) 數據冗余：同一個“學院”由n個學生，“學院地點”和“學院電話”就重復n-1次。
(2) 更新異常：若調整了某學院的地點，數據表中所有有關行的“學院地點”值都要更新，否則會出現同一學院但是地點卻不同的情況。
(3) 插入異常：假設要增加一個新學院，暫時還沒有人報考。這樣，由於還沒有“學號”關鍵字，相關數據將無法記錄入數據庫。
(4) 刪除異常：假設一批學生已經畢業，這些學生信息記錄就應該從數據庫表中刪除。但是，與此同時，學院、學院地點和學院電話信息也被刪除了。很顯然，這也會導致插入異常。
修改后如下：
學生表
學院表
結束語：通過運用三個范式可以使你的數據庫更加准確、高效。但是在關系數據庫中，還有多值依賴，聯接依賴的問題，從而提出了第四范式，第五范式等更高一級的規范化要求，那些我們以后再談。
