為了建立冗餘較小、結構合理的資料庫，設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計一個結構合理的關係型資料庫，必須滿足一定的正規化。

在實際開發中通常滿足第三正規化即可：

下圖是我對三正規化的簡單理解:

        第一正規化（1NF）：要求關係模式R的所有屬性都是不可分的基本資料項，指資料庫表的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。

例如：比如某些資料庫系統中需要用到“地址”這個屬性，本來直接將“地址”屬性設計成一個數據庫表的欄位就行。但是如果系統經常會訪問

使用者資訊表

上表所示的使用者資訊遵循了第一正規化的要求，這樣在對使用者使用城市進行分類的時候就非常方便，也提高了資料庫的效能。

        第二正規化（2NF）是在第一正規化（1NF）的基礎上建立起來的，即滿足第二正規化（2NF）必須先滿足第一正規化（1NF）。第二正規化（2NF）首先要求資料庫表中首先必須有主鍵。為實現區分通常需要為表加上一個列，以儲存各個例項的唯一標識。其次要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性

，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。採用投影分解法將一個1NF的關係分解為多個2NF的關係，可以在一定程度上減輕原1NF關係中存在的插入異常、刪除異常、資料冗餘度大、修改複雜等問題。

        比如要設計一個訂單資訊表，因為訂單中可能會有多種商品，所以要將訂單編號和商品編號作為資料庫表的聯合主鍵，如下表所示。

訂單資訊表

        這樣就產生一個問題：這個表中是以訂單編號和商品編號作為聯合主鍵。這樣在該表中商品名稱、單位、商品價格等資訊不與該表的主鍵相關，而僅僅是與商品編號相關。所以在這裡違反了第二正規化的設計原則。

而如果把這個訂單資訊表進行拆分，把商品資訊分離到另一個表中，就非常完美了。如下面這兩個所示。

訂單資訊表

商品資訊表

這樣設計，在很大程度上減小了資料庫的冗餘。如果要獲取訂單的商品資訊，使用商品編號到商品資訊表中查詢即可。

        第三正規化3NF是第二正規化（2NF）的一個子集，即滿足第三正規化必須滿足第二正規化。第三正規化需要確保資料表中的每一列資料都和主鍵直接相關，而不能間接相關，即任何非主屬性不得傳遞依賴於主屬性。簡而言之，就是要求一個關係中不包含已在其它關係已包含的非主關鍵字資訊。（不滿足時常採用投影分解法解決）

        比如在設計一個訂單資料表的時候，可以將客戶編號作為一個外來鍵和訂單表建立相應的關係。而不可以在訂單表中新增關於客戶其它資訊(比如姓名、所屬公司等)的欄位。如下面這兩個表所示的設計就是一個滿足第三正規化的資料庫表。

訂單資訊表

客戶資訊表

        這樣在查詢訂單資訊的時候，就可以使用客戶編號來引用客戶資訊表中的記錄，也不必在訂單資訊表中多次輸入客戶資訊的內容，減小了資料冗餘。