三正規化是資料庫的規範化的內容，所謂的資料庫三正規化通俗的講就是設計資料庫表所應該遵守的一套規範，如果不遵守就會造成設計的資料庫不規範，出現資料庫字段冗餘，資料的查詢，插入等操作等問題。注意：資料庫不僅僅只有三正規化（1nf/2nf/3nf），還有bcnf、4nf、5nf…，不過在實際的資料庫設計時，遵守前三個正規化就足夠了。再向下就會造成設計的資料庫產生過多不必要的約束。
第一正規化：資料庫表中的每一列都不可再分，也就是原子性解釋：如下表所示，可以看到，列部門崗位是不滿足原子性的要求的。所謂原子就是最小的。不能再把它進行劃分了。在部門崗位中，是可以進行劃分為部門和崗位的。
修改後的表：
第二正規化的另一種表述方式是：兩張表要通過外來鍵關聯，不儲存冗餘字段。注意：如果不是聯合主鍵（兩個字段共同充當表的主鍵），不存在不遵守第二正規化的問題。
解釋：如下表：
直接看這個表可能第一感覺就是沒毛病。但是當乙個表**現聯合主鍵時，我們就需要進行詳細的分析了。
「訂單詳情表」使用「訂單編號」和「產品編號」作為聯合主鍵。此時「產品**」、 「產品數量」都和聯合主鍵整體相關，但 「訂單金額」和「下單時間」 只和聯合主鍵中的「訂單編號」相關，和「產品編號」無關。所以只關聯了主鍵中的部分字段，不滿足第二正規化。
修改表如下：把「訂單金額」和「下單時間」移到訂單表就符合第二正規化了。
上面表中的「部門名稱」和「員工編號」的關係是「員工編號」→「部門編號」 →「部門名稱」，不是直接相關。此時會帶來下列問題：
1.資料冗餘：「部門名稱」多次重複出現。
2.插入異常：組建乙個新部門時沒有員工資訊，也就無法單獨插入部門資訊。就算強行插入部門資訊，員工表中沒有員工資訊的記錄同樣是非法記錄。
3.刪除異常：刪除員工資訊會連帶刪除部門資訊導致部門資訊意外丟失。
4.更新異常：哪怕只修改乙個部門的名稱也要更新多條員工記錄。
正確的方式：把上表拆分成兩張表，以外鍵形式關聯
三大正規化是設計資料庫表結構的規則約束，但是在實際開發中允許區域性變通。
如何變通呢？比如為了快速查詢到關聯資料可能會允許冗餘欄位的存在。例如在員工表 中儲存部門名稱雖然違背第三正規化，但是免去了對部門表的關聯查詢。
根據業務功能設計資料庫表1).看得見的字段能夠從需求文件或原型頁面上直接看到的資料都需要設計對應的資料庫表、欄位來儲存。例如設計乙個登入介面的功能。設計表需要有賬號、密碼。
2).看不見的字段
除了能夠直接從需求文件中看到的字段，實際開發中往往還會包含一 些其他欄位來儲存其他相關資料。 例如主鍵、建立賬戶時間。
3).冗餘字段
為了避免建表時考慮不周有所遺漏，到後期再修改表結構非常麻煩， 所以有時會設定一些額外的冗餘字段備用。
資料庫三大正規化解釋
正規化 英文名稱是 normal form，它是英國人 e.f.codd 關聯式資料庫的老祖宗 在上個世紀70年代提出關聯式資料庫模型後總結出來的，正規化是關聯式資料庫理論的基礎，也是我們在設計資料庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種正規化，依次是 1nf，2nf，3nf，b...
資料庫三大正規化通俗解釋
標準資料庫三大正規化描述 1 第一正規化 1nf 如果關係模式 r 它的每個屬性分量都是乙個不可分割的資料項，則稱 r 符合第一規範，記 r 1nf 2 第二正規化 2nf 若 r 1nf 且每個非主屬性完全依賴於碼，則稱 r 2nf 常見的違反 把兩個或多個實體集放在乙個關係模式中 引起的問題 存...
資料庫設計 三正規化 解釋 舉例
1nf 字段不可分 2nf 有主鍵，非主鍵字段依賴主鍵 3nf 非主鍵字段不能相互依賴 解釋 1nf 原子性 字段不可再分,否則就不是關聯式資料庫 2nf 唯一性 乙個表只說明乙個事物 3nf 每列都與主鍵有直接關係，不存在傳遞依賴 不符合第一正規化的例子 關聯式資料庫中create不出這樣的表 表...