規範地設計關係數據庫必須遵照的三大範式！

• 規範化的目的
• 基本概念
• 主鍵的選擇
• 表結構設計的原則
• 常見疑慮

*數據庫就是產品的地基，地基打很差，這個產品時刻都有潛在的危險。

1、規範化的目的

• 良好的數據庫設計：
  節省數據的存儲空間
  可以保證數據的完整性
• 糟糕的數據庫設計：
  數據冗餘、存儲空間浪費
  數據刪除、更新和插入的異常
  帶來系統軟bug

2、基本概念

主碼：也叫主鍵，能惟一地肯定一條記錄；是表中的屬性或屬性組；（惟一且不可更改【如：身份證號】）
候選碼：也叫候選鍵，能夠做爲主碼的碼；
主屬性：包含在任一候選鍵中的屬性；
實體：客觀存在的能夠被描述的事物（用戶，課程等）。

例1：設有關係模式SC（Sno,Sname,Cno（課程號）,Credit（學分）,Grade）,其中主鍵爲（Sno,Cno）
Sno -> Sname 姓名徹底函數依賴於學號；
(Sno,Cno)->Sname 姓名部分函數依賴於學號和課程號；
(Sno,Cno)-> Grade 成績徹底函數依賴於學號和課程號。

例2：設有關係模式S(Sno,Sname,Sdept(所在系),Dep_master(系主任)),主鍵爲Sno
Sno->Sdept 所在系徹底函數依賴於學號；
Sdept->Dept_master 系主任徹底函數依賴於所在系；
所以：Sno->Dept_master 系主任傳遞函數依賴於學號。

3、主鍵的選擇

一、人工鍵：實體的非天然屬性
二、天然鍵：實體自己的屬性

4、表結構設計的原則

天然二維表

首先，通過一系列對需求的提煉，整理出來的表，稱爲天然二維表。

第一範式（1NF）

消除天然表中屬性的非原子性後，就知足1NF。

第二範式（2NF）

消除非主屬性對碼的部分函數依賴。

第三範式（3NF）

消除非主屬性對碼的傳遞函數依賴。

BC範式*

消除主屬性對碼的部分和傳遞函數依賴。

第四範式（4NF）

消除不是由候選碼蘊含的非平凡的多值依賴。

第五範式（5NF）

消除不是由候選碼蘊含的鏈接依賴。

5、常見疑慮

一、每一個表均可以設置惟一且不可更改的自增id爲主鍵，爲何還要費勁選主鍵？

• 若是表中已經存在惟一且不可更改的字段，就不必再使用一個自增主鍵，浪費存儲空間
• 導入舊數據時，可能會ID重複，致使導入失敗
• 防止注入式攻擊（get請求）