第一正規化（1nf）：強調的是列的原子性，即列不能夠再分成其他幾列。
考慮這樣乙個表：【聯絡人】（姓名，性別，**）
如果在實際場景中，乙個聯絡人有家庭**和公司**，那麼這種表結構設計就沒有達到 1nf。要符合 1nf 我們只需把列（**）拆分，即：【聯絡人】（姓名，性別，家庭**，公司**）。1nf 很好辨別，但是 2nf 和 3nf 就容易搞混淆。
◆ 第二正規化（2nf）：首先是 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）和【product】（productid，unitprice，productname）來消除原訂單表中unitprice，productname多次重複的情況。
◆ 第三正規化（3nf）：首先是 2nf，另外非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴。即不能存在：非主鍵列 a 依賴於非主鍵列 b，非主鍵列 b 依賴於主鍵的情況。
考慮乙個訂單表【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：非主鍵列是直接依賴於主鍵，還是直接依賴於非主鍵列。
資料庫的三個正規化
強調列的原子性，即列不能夠再分成其他幾列。考慮有這樣乙個表 聯絡人 姓名 性別 如果在實際場景中，乙個聯絡人有家庭 和公司 那麼這種表結構就不符合1nf，應把 列拆分成家庭 和公司 首先是1nf，另外還有兩部分內容。1.乙個表必須有乙個主鍵。2.不在主鍵裡的列必須依賴主鍵的所有內容，而不能只依賴主鍵...
資料庫三個正規化的原理
1nf,字段不可再分。這個關聯式資料庫強制了，想建立復合的字段也建立不起來。關聯式資料庫出現之前才有這個問題。2nf，主鍵依賴，就是一張表裡面的字段，必須是跟主鍵相關的，不能把無關的資料放進來。主鍵依賴，實質就是，這個資訊如果是物件的屬性，就放進來，否則就不放。3nf，就是不能重複儲存相同的資訊。這...
資料庫入門 三個正規化
我覺得他說的最對 我也來解釋一波，參考 資料庫系統概念 書上一開始講得什麼 組合屬性 多值屬性 都是在講 e r模型和表的區別，就是說e r模型允許存在上述子結構，而表不能，跟第一正規化的解釋沒有直接關係。第一正規化實際的解釋為 關係模式中所有的屬性的域都是原子域。舉幾個反例 存在以上屬性的關係模式...