#### 1. 什么是設計范式 ---- 設計表的依據，按照范式設計出來的表，不會出現數據的冗余 數據庫的設計范式是數據庫設計所需要滿足的規范，滿足這些規范的數據庫是簡潔的、結構清晰的；反之則是亂七八糟，不僅會給開發人員制造麻煩，而且還可能存儲了大量不需要的冗余數據 不僅僅只有三大范式，還有第四范式、第五范式、第六范式等，通常來講，滿足三大范式就基本足夠 項目的數據庫設計并不一定要完全滿足于三大范式，有些時候我們會適量的冗余讓 query 盡量減少 join #### 2. 三大范式 ---- **第一范式（1 NF）：要求屬性（列）具有原子性，即每列都是不可再分解的數據** 雖然第一范式要求各列保存原子性，不能再分解，但是這種要求是和我們的需求相關聯的，不拆分也行；如果要考慮可擴展性，那么就進行拆分吧。如下表所示，沒有根據城市篩選用戶的需求，可以這樣存儲城市數據 | id | name | address | | ------------ | ------------ | ------------ | | 1 | 張三 | 河南省開封市蘭考縣 | | 2 | 李四 | 廣東省深圳市福田區 | 對 address 進行拆分，使其具有原子性（原子性：指不可再分解的意思） | id | name | province | city | area | | ------------ | ------------ | ------------ | ------------ | ------------ | | 1 | 張三 | 河南省 | 開封市 | 蘭考縣 | | 2 | 李四 | 廣東省 | 深圳市 | 福田區 | **第二范式（2 NF）：建立在第一范式基礎上，除主鍵外的每一列都必須完全依賴于主鍵** 如果要出現不完全依賴主鍵，只可能發生在聯合主鍵的情況下 第二范式是對記錄的唯一性約束，要求有唯一性標識，即實體的唯一性，如下所示：即可 name 和 address 完全一致，但是主鍵值是不一樣的，這樣就實現了數據的唯一性 | id | name | address | | ------------ | ------------ | ------------ | | 1 | 張三 | 河南省開封市蘭考縣 | | 2 | 張三 | 河南省開封市蘭考縣 | **第三范式（3 NF）：建立在第二范式基礎上，對字段冗余性的約束，它要求字段沒有冗余** 假設員工的薪資水平由崗位決定，也就是 salary 由 job 決定，和人員（name）無關 員工表： | id | name | job | salary | | ------------ | ------------ | ------------ | ------------ | | 1 | 張三 | Web 前端開發工程師 | 5000 | | 2 | 李四 | PHP 后端開發工程師 | 8000 | | 3 | 王五 | PHP 后端開發工程師 | 8000 | 那么，我們將遵循第三范式將員工表拆分為兩張表，如下所示 員工表： | id | name | job_id | | ------------ | ------------ | ------------ | | 1 | 張三 | 100 | | 2 | 李四 | 101 | | 3 | 王五 | 101 | 薪資表： | id | name | salary | | ------------ | ------------ | ------------ | | 100 | Web 前端開發工程師 | 5000 | | 101 | 后端開發工程師 | 8000 |