資料庫三正規化解析
三正規化解析：
第一正規化：資料庫的列必須是原子的，不能通過邏輯再拆分。
比如你設計的一個表的列是這樣的：
| 姓名年齡 | 班級學號 | 性別愛好 |
|---|---|---|
| 張三21 | 三班2002002 | 男足球 |
這樣用起來就需要你邏輯拆分，而且還沒辦法跟其他表做關聯查詢。所以違反了第一正規化。
第二正規化：在滿足第一正規化的基礎上，你設計的表的非主屬性元素，要都完全依賴與表的每一個候選主屬性。
比如你又設計了一個表：
| 商品編碼 | 商品名稱 | 商品價格 | 訂單號 | 訂單日期 |
|---|---|---|---|---|
| 1 | 牙刷110 | 2 | 111 | 一月 |
| 2 | 滑鼠246 | 4 | 111 | 二月 |
| 3 | 飯盒653 | 5 | 222 | 三月 |
這個表總體來看，主屬性是商品編碼，因為表中多數字段都是在描述商品，但是後續的訂單日期，就與商品關聯不是很大了，包括訂單號，如果這是描述商品的表，最好也是獨立出去，拆成訂單表，再通過中間表，描述兩者之間的關聯，才是符合第二正規化的。
第三正規化：在滿足第一正規化的基礎上，一個表的非主屬性不能出現在另一個表中。
比如：
商品表：
| 商品編碼 | 商品名稱 |
|---|---|
| 1 | 牙刷110 |
訂單表：
| 訂單編碼 | 訂單日期 |
|---|---|
| 111 | 一月 |
訂單商品關聯表：
| 訂單編號 | 商品編碼 | 商品名稱 |
|---|---|---|
| 111 | 1 | 牙刷110 |
可以看到訂單商品關聯表中商品名稱是冗餘的，這種冗餘在查詢上看不出來來什麼，但是一旦有場景需要修改商品名稱，則需要你想起來所有冗餘了這個欄位的表，而往往實際應用中，很難注意到冗餘欄位被修改的情況，這樣就把資料染髒了。
說明：
規範化目的是使結構更合理，消除儲存異常，使資料冗餘儘量小。便於插入、刪除和更新。遵從概念單一化“一事一地”原則，即一個關係模式描述一個實體或實體間的一種聯絡。規範的實質就是概念的單一化。
一個關係模式接著分解可以得到不同關係模式集合，也就是說分解方法不是惟一的。最小冗餘的要求必須以分解後的資料庫能夠表達原來資料庫所有資訊為前提來實現。
其根本目標是節省儲存空問，避免資料不一致性，提高對關係的操作效率，同時滿足應用需求。實際上，並不一定要求全部模式都達到正規化不可。有時故意保留部分冗餘可能更方便資料查詢。尤其對於那些更新頻度不高，查詢頻度極高的資料庫系統更是如此。
比如有些國標字典項，國家更新這些標準的概率很小，你在主表中存了編碼，前端展示名稱，就可以把這些名稱冗餘在主表中，省的每次都連表查詢。