第一正規化（1NF）

定義：資料庫表的每一列都是不可分割的原子資料項，而不能是集合，陣列，記錄等非原子資料項。如果實體中的某個屬性有多個值時，必須拆分為不同的屬性。

說明：E-R模型允許實體集和聯絡集具有某些程度的子結構，比如多值屬性（一個教師有多個電話號碼）、組合屬性（包含多個子屬性，比如地址包含城市和街道等）。我們在將E-R模型轉換成表時，對於這些子結構的一般處理規則是：多值屬性用多個元組來儲存；組合屬性中的每個子屬性作為單獨的屬性，也就是表中的單獨列。這個一般處理規則其實也是在滿足第一正規化的約束。

舉例：設計如下Instructor1這張表來儲存大學教師資訊，每位教師包括教師ID、名字、身份證ID，身份證過期時間、家庭地址、配偶名字、配偶單位這些資訊，教師ID是這張表的主鍵。

Instructor1

問題：上面這張表並不滿足第一正規化，因為Adress這個屬性其實包含了城市和街道兩個子屬性，應該拆分成獨立的屬性。將其改進後滿足第一正規化：

Instructor2

第二正規化（2NF）

定義：滿足第一正規化前提，第二正規化（2NF）要求實體的所有非主鍵屬性完全依賴於每一個候選主鍵。所以只有當存在多個主鍵的時候，才會發生不符合第二正規化的情況。比如有兩個候選主鍵時，不能存在這樣的屬性，它只依賴於其中一個主鍵，這就是不符合第二正規化。

舉例：Instructor2雖然滿足第一正規化，但是並不滿足第二正規化，因為教師ID和身份證ID都是候選主鍵，但是身份證過期時間這個屬性只依賴於身份證ID這個屬性，為滿足第二正規化應該將教師身份證資訊應該用單獨的表來儲存。

Instructor3

Card1

第三正規化（3NF）

定義：滿足第二正規化前提，屬性不能傳遞依賴於主鍵屬性。如果某一屬性依賴於其他非主鍵屬性，而其他非主鍵屬性又依賴於主鍵，那麼這個屬性就是間接依賴於主鍵，這被稱作傳遞依賴於主鍵屬性，即不滿足第三正規化。

舉例：Instructor3雖然滿足第二正規化，但是因為配偶單位（Partner_Comp）這個屬性依賴於配偶名字（Partner_name）屬性，配偶名字屬性又依賴於主鍵屬性教師ID，即配偶單位屬性傳遞依賴於主鍵教師ID，所以不滿足第三正規化。改進後的版本滿足第三正規化：

Instructor4

Partner1

Card1

資料庫關係（表）設計一般需要滿足第三正規化。另一方面，這三大正規化只是一般設計資料庫的基本理念，可以建立冗餘較小、結構合理的資料庫。如果有特殊情況，當然要特殊對待，資料庫設計最重要的是看需求跟效能，需求>效能>表結構。所以不能一味的去追求正規化建立資料庫。