在實際開發中通常滿足第三正規化即可：
下圖是我對三正規化的簡單理解:
第一正規化（1nf）：要求關係模式
r的所有屬性都是不可分的基本資料項
，指資料庫表的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。
例如：比如某些資料庫系統中需要用到「位址」這個屬性，本來直接將「位址」屬性設計成乙個資料庫表的字段就行。但是如果系統經常會訪問「位址」屬性中的「城市」部分，那麼就非要將「位址」這個屬性重新拆分為省份、城市、詳細位址等多個部分進行儲存，這樣在對位址中某一部分操作的時候將非常方便。這樣設計才算滿足了資料庫的第一正規化，如下表所示。
使用者資訊表
編號
姓名
性別
年齡
聯絡**
省份
城市
詳細位址1
張紅欣 男
26 0378-23459876 河南
開封朝陽區新華路23號 2
李四平 女
320751-65432584 廣州
廣東白雲區天明路148號 3
劉志國 男
210371-87659852 河南
鄭州二七區大學路198號 4
郭小明 女
270371-62556789 河南
鄭州新鄭市薛店北街218號
上表所示的使用者資訊遵循了第一正規化的要求，這樣在對使用者使用城市進行分類的時候就非常方便，也提高了資料庫的效能。
比如要設計乙個訂單資訊表，因為訂單中可能會有多種商品，所以要將訂單編號和商品編號作為資料庫表的聯合主鍵，如下表所示。
訂單資訊表
訂單編號
商品編號
商品名稱
數量
單位
商品**
001 1
挖掘機 1
臺 1200000￥
002 2
衝擊鑽 8
個230￥
003 3
鏟車 2
輛980000￥
這樣就產生乙個問題：這個表中是以訂單編號和商品編號作為聯合主鍵。這樣在該表中商品名稱、單位、商品**等資訊不與該錶的主鍵相關，而僅僅是與商品編號相關。所以在這裡違反了第二正規化的設計原則。
而如果把這個訂單資訊表進行拆分，把商品資訊分離到另乙個表中，就非常完美了。如下面這兩個所示。
訂單資訊表
訂單編號
商品編號
數量
001 1
1 002 2
8 003 3
2 商品資訊表
商品編號
商品名稱
單位
商品**1
挖掘機 臺
1200000￥ 2
衝擊鑽 個
230￥ 3
鏟車 輛
980000￥
這樣設計，在很大程度上減小了資料庫的冗餘。如果要獲取訂單的商品資訊，使用商品編號到商品資訊表中查詢即可。
比如在設計乙個訂單資料表的時候，可以將客戶編號作為乙個外來鍵和訂單表建立相應的關係。而不可以在訂單表中新增關於客戶其它資訊(比如姓名、所屬公司等)的字段。如下面這兩個表所示的設計就是乙個滿足第三正規化的資料庫表。
訂單資訊表
訂單編號
訂單專案
負責人
業務員
訂單數量
客戶編號
001
挖掘機 劉明
李東明 1臺
1 002
衝擊鑽 李剛
霍新峰 8個
2 003 鏟車
郭新一
艾美麗 2輛
1 客戶資訊表
客戶編號
客戶名稱
所屬公司
****1
李聰 五一建設
13253661015 2
劉新明個體經營
13285746958
這樣在查詢訂單資訊的時候，就可以使用客戶編號來引用客戶資訊表中的記錄，也不必在訂單資訊表中多次輸入客戶資訊的內容，減小了資料冗餘。
資料庫三正規化理解
1.第一正規化 1nf 資料庫列不可再分，即資料庫的字段不可再下分，如進貨包含有單價和數量那麼資料庫設計時應設計為兩列 進貨數量 進貨單價 2.第二正規化 2nf 資料庫表中的每個例項或行必須可以被唯一的區分，且非主屬性需要完全依賴於主鍵，如果存在不依賴於主鍵的屬性，這些屬性應該分離出來形成乙個新的...
資料庫 三正規化理解
第一正規化 原子性，每乙個字段不可再分 每一字段資訊應該能分就分，分到不可再分為止 例如 第二正規化 唯一性，不可以把多種資料儲存在同一張表中，即一張表只能儲存 一種 資料。表內資料各管各的，不能互相影響 不符合第二正規化的表 學號,姓名,年齡,課程名稱,成績,學分 可能會存在問題 正確做法 學生 ...
資料庫三正規化理解
在談資料庫正規化之前，我們要明白一些關於資料庫的基本概念，具體有一下幾個 元組 tuple 是關聯式資料庫中的基本概念，關係是一張表，表中的每行即資料庫中的一條記錄，就是乙個元組，每列就是乙個屬性。超鍵 super key 能夠唯一決定乙個元組的屬性集合。可以是乙個屬性也可以是多個屬性，都叫做超鍵。...