正規化：英文名稱是 normal form，它是英國人 e.f.codd（關聯式資料庫的老祖宗）在上個世紀70年代提出關聯式資料庫模型後總結出來的，正規化是關聯式資料庫理論的基礎，也是我們在設計資料庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種正規化，依次是：1nf，2nf，3nf，bcnf，4nf，5nf，dknf，6nf。通常所用到的只是前三個正規化，即：第一正規化（1nf），第二正規化（2nf），第三正規化（3nf）。下面就簡單介紹下這三個正規化。
強調的是列的原子性，即列不能夠再分成其他幾列。
考慮這樣乙個表：【聯絡人】（姓名，性別，**）
如果在實際場景中，乙個聯絡人有家庭**和公司**，那麼這種表結構設計就沒有達到 1nf。要符合 1nf 我們只需把列（**）拆分，即：【聯絡人】（姓名，性別，家庭**，公司**）。1nf 很好辨別，但是 2nf 和 3nf 就容易搞混淆。
首先是 1nf，另外包含兩部分內容，一是表必須有乙個主鍵；二是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。
考慮乙個訂單明細表：【orderdetail】（orderid，productid，unitprice，discount，quantity，productname）。
因為我們知道在乙個訂單中可以訂購多種產品，所以單單乙個 orderid 是不足以成為主鍵的，主鍵應該是（orderid，productid）。顯而易見 discount（折扣），quantity（數量）完全依賴（取決）於主鍵（oderid，productid），而 unitprice，productname 只依賴於 productid。所以 orderdetail 表不符合 2nf。不符合 2nf 的設計容易產生冗餘資料。
可以把【orderdetail】表拆分為
【orderdetail】（orderid，productid，discount，quantity）首先是 2nf，另外非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴。即不能存在：非主鍵列 a 依賴於非主鍵列 b，非主鍵列 b 依賴於主鍵的情況。【product】（productid，unitprice，productname）來消除原訂單表中unitprice，productname多次重複的情況。
考慮乙個訂單表【order】（orderid，orderdate，customerid，customername，customeraddr，customercity）主鍵是（orderid）。
其中 orderdate，customerid，customername(顧客名字)，customeraddr(顧客位址)，customercity (顧客城市)等非主鍵列都完全依賴於主鍵（orderid），所以符合 2nf。不過問題是 customername，customeraddr，customercity 直接依賴的是 customerid（非主鍵列），而不是直接依賴於主鍵，它是通過傳遞才依賴於主鍵，所以不符合 3nf。
通過拆分【order】為【order】（orderid，orderdate，customerid）
【customer】（customerid，customername，customeraddr，customercity）從而達到 3nf。
第二正規化（2nf）和第三正規化（3nf）的概念很容易混淆，區分它們的關鍵點在於，2nf：非主鍵列是否完全依賴於主鍵，還是依賴於主鍵的一部分；3nf：非主鍵列是直接依賴於主鍵，還是直接依賴於非主鍵列。
通俗講解資料庫三大正規化
第一正規化 就是屬性不可分割。屬性是什麼？就是表中的字段。不可分割的意思就按字面理解就是最小單位，不能再分成更小單位了。這個字段只能是乙個值，不能被拆分成多個字段，否則的話，它就是可分割的，就不符合一正規化。不過能不能分割並沒有絕對的答案，看需求，也就是看你的設計目標而定。舉例 學生資訊組成學生資訊...
詳解資料庫設計三大正規化
為了建立冗餘較小 結構合理的資料庫，設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計乙個結構合理的關係型資料庫，必須滿足一定的正規化。在實際開發中最為常見的設計正規化有三個 1 第一正規化 確保每列保持原子性 第一正規化是最基本的正規化...
簡單理解資料庫三大正規化
書上講了好多，歸結起來3句話 1nf 字段不可分 2nf 有主鍵，非主鍵字段依賴主鍵 3nf 非主鍵字段不能相互依賴 解釋 1nf 原子性 字段不可再分,否則就不是關聯式資料庫 2nf 唯一性 乙個表只說明乙個事物 3nf 每列都與主鍵有直接關係，不存在傳遞依賴 不符合第一正規化的例子 關聯式資料庫...