資料庫表的設計規範
資料庫設計三大正規化
為什麼要談及正規化？
這也是為了資料庫設計做準備，對於表設計而言，我們需求何種程度的設計，這完全取決你資料的規模，好比你建房子，要是建個一兩層，基本上不需要什麼設計，直接開工就行，要是建個這樣的房子還找設計公司的話，這無疑是大材小用，浪費；但是，對建一座大廈來說，不做規劃，不請教不諮詢設計公司，後果難以想象了。當然，為了設計結構合理的資料庫，必須遵循一定的規則，在關係資料庫中這種規則就稱為正規化，正規化是符合某一種設計要求的總結
1.第一正規化（1NF）無重複列
通俗理解：列不可分
在任何一個關係資料庫中，滿足第一正規化是關係資料庫的基本要求。
如果資料庫表中的所有欄位值都是不可再分解的原子值，即無重複列，就說明該資料庫表滿足第一正規化。
注意的是：第一正規化的合理邏輯通常是根據實際需求來定的。比如某些資料庫系統中需要用到“地址”這個屬性，本來直接將“地址”屬性設計成一個數據庫表的欄位就行（表一所示）。但是如果系統經常會訪問“地址”屬性中的“城市”部分，那麼就非要將“地址”這個屬性重新拆分為省份、城市、詳細地址等多個部分進行儲存，這樣在對地址中某一部分操作的時候將非常方便（表二所示）。這樣設計才算滿足了資料庫的第一正規化。
2.第二正規化（2NF）屬性完全依賴於主鍵
通俗理解：不能部分依賴。即，候選碼是組合鍵時（聯合主鍵），非主屬性要完全依賴於組合鍵，而不能依賴於組合鍵的部分屬性。
換句話來說就是一個表中的資料只能儲存一種且必須與主鍵相關。
第二正規化是在第一正規化的基礎上建立起來的。第二正規化需要確保資料表中的每一列和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵）。
下表所示快遞單號與商品編號為聯合主鍵，但是在該表中商品名稱，數量，價格（單價）並不是與聯合主鍵直接關聯，所以不符合第二正規化。
然而，把上表進行拆分，得到下列表，這樣就完全符合第二正規化設計要求。
3.第三正規化（3NF）屬性不能傳遞依賴於主鍵（減少資料冗餘，這樣就可以通過主外來鍵進行表之間連線）
通俗理解:不能存在傳遞依賴。 除了主鍵外，其他欄位必須依賴主鍵
傳遞依賴：如果某一屬性依賴於其他非主屬性，而其他非主屬性又依賴於主鍵，那麼這個屬性間接依賴於主鍵，這稱為依賴傳遞於主屬性
滿足第三正規化必須先滿足第二正規化，第三正規化要求一個數據資料庫表中不包含已在其他表中已包含的非關鍵字資訊，資料表如果不存在非關鍵字屬性對任一候選關鍵欄位的傳遞依賴則符合第三正規化
因為上表的玩具車與玩具槍屬於兒子，因此不符合第三正規化，對上表進行拆分
