第一范式(1NF)
數據表的每一列都要保持它的原子特性，也就是列不能再被分割。
這張表就不符合第一范式規定的原子性，不符合關系型數據庫的基本要求，在關系型數據庫中創建這個表的操作就不能成功。不得不將數據表設計為如下形式。
第二范式(2NF)
概率：屬性必須完全依賴於主鍵。
下滿這張表不符合第二范式的要求。
缺點
- 表中的第一行數據都存儲了系名、系主任,數據的冗余太大
- 如果有一個新的系還沒有開始找到學生，那么不能講該系的信息添加到數據表中去，從數據表中看不到該系的存在
- 如果將某個系的學生信息全部刪除，那么這個系在數據表里也就不存在了，但這個系還存在。
- 如果某個人要轉系，那么為了保證數據庫中數據的一致性，需要修改三條記錄中系與系主任的數據
依賴
在數據表中，屬性（屬性組）X確定的情況下，能完全退出來屬性Y完全依賴於X。
完全依賴
完全依賴是針對於屬性組來說，當一組屬性X能推出來Y的時候就說Y完全依賴於X。
部分依賴
一組屬性X中的其中一個或幾個屬性能推出Y就說Y部分依賴於X。
結論:當一個第一范式的候選碼只有一個屬性的時候，那它就是第二范式(2NF)
候選碼
當一個屬性或者屬性組確定的情況下，這張表的其余所有屬性就能確定下來，這個屬性或者屬性組就叫做或候選碼。
一張表可以有多個候選碼
一般只選一個候選碼作為主鍵
從表中找到兩個屬性：學號和課程
學號可以推出姓名、系名、系主任。
課程可以推出成績。
將它們兩個設置為聯合主鍵
存在的部分依賴
- 姓名對學號存在部分依賴
- 系名對學號存在部分依賴
- 系主任對學號存在部分依賴
- 這顯然不符合第二范式的要求，做出修改：
表一中分數完全依賴於學號和課程的屬性
表二中姓名、系名、系主任完全依賴於學號的屬性
第二范式消除了第一范式的部分依賴
第三范式(3NF)
概念:所有的非主屬性不依賴於其他的非主屬性
傳遞函數依賴
設X,Y,Z是關系R中互不相同的屬性集合，存在X→Y(Y !→X),Y→Z，則稱Z傳遞函數依賴於X。
在改進后的學生表中：
主屬性：學號
非主屬性：姓名、系名、系主任
知道系名可以推出系主任，所以非主屬性系主任對主屬性學號存在傳遞函數依賴，這不符合非主屬性不依賴於其它的非主屬性的設計要求。將該數據表改進如下：
第三范式消除了第二范式的傳遞函數依賴
BC 范式
主屬性不能對候選碼存在部分函數依賴或者傳遞函數依賴
這張表不存在部分函數依賴於傳遞函數依賴，屬於第三范式
表中的依賴關系
- 倉庫名—————>管理員
- 管理員—————>倉庫名
- 物品名—————>數量
主屬性：倉庫名、管理員、物品名
非主屬性：數量
存在的問題
- 先新添加一個倉庫，但尚未存放任何物品，不可以為該倉庫指派管理員，因為物品名也是主屬性，根據實體完整性的要求，主屬性不能為空
- 某倉庫被清空后，該倉庫的信息也被清空
- 當需要更新倉庫管理員，該倉庫存放了多少物品，就要修改多少條信息。
在這個問題中就是存在了主屬性對於候選碼的部分依賴，也就是倉庫名對於管理員和物品名的部分依賴。
修改為
倉庫（倉庫名，管理員）
庫存（倉庫名、物品數、數量）
范式的目的
- 減小數據的冗余性
- 提高效率