MySQL三大範式

第一範式(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 範式
主屬性不能對候選碼存在部分函數依賴或者傳遞函數依賴

這張表不存在部分函數依賴於傳遞函數依賴，屬於第三範式
表中的依賴關係

• 倉庫名—————>管理員
• 管理員—————>倉庫名
• 物品名—————>數量

主屬性：倉庫名、管理員、物品名
非主屬性：數量
存在的問題

• 先新添加一個倉庫，但還沒有存聽任何物品，不能夠爲該倉庫指派管理員，由於物品名也是主屬性，根據實體完整性的要求，主屬性不能爲空
• 某倉庫被清空後，該倉庫的信息也被清空
• 當須要更新倉庫管理員，該倉庫存放了多少物品，就要修改多少條信息。
  在這個問題中就是存在了主屬性對於候選碼的部分依賴，也就是倉庫名對於管理員和物品名的部分依賴。
  修改成
  倉庫（倉庫名，管理員）
  庫存（倉庫名、物品數、數量）

範式的目的

• 減少數據的冗餘性
• 提升效率