原子性。表的元組不可再拆分成更小的元組。
非主鍵必須完全依賴主鍵，而不是僅僅依賴主鍵的一部分。
舉個例子，美國銷售軍火的時候，對每一樣**，根據國家或地區的不同而給出不同的**。建個表看看:
create table weapon_price
( wp_id unsigned int not null auto_increment, -- **編號
cs_id unsigned int not null , -- 消費者 id
wp_price unsigned int not null, -- ****, 根據**買主的不同而不同
cs_name varchar(40) not null -- 消費者的稱呼，例如 台灣/菲律賓/南韓
);
weapon_price 用於描述**的**，**根據(**，消費者)的不同而不同。對於此表 (wp_id,cs_id) 是其主鍵。其中 wp_price 是完全依賴於 (wp_id,cs_id) 的，而 cs_name 則只依賴於 cs_id ，即只依賴於主鍵的一部分。
這種情況導致的問題是什麼呢？
增：造成冗餘。cs_name 重複出現，如果有許多**的買主都是台灣，那麼 cs_name 就會在這張表中出現很多次，造成浪費。
刪：無查：無
如何應對呢？
把 cs_name 挪到別的表裡，本來嗎，學過資料庫的人都知道，可以建乙個 consumer 表，其中含 (cs_id,cs_name) 兩個元組。
滿足第二正規化並且每個元組都不傳遞依賴於主鍵列。
create table province
( pr_id unsigned int not null auto_increment, -- 主鍵
pr_name varchar(20) not null, -- 省份名, 完全依賴於主鍵, pr_id 定了, pr_name 就定了
primary key(pr_id)
);create table city
( ct_id unsigned int not null auto_increment, -- 主鍵
ct_name varchar(20) not null, -- 完全依賴於主鍵，ct_id 定了，ct_name 就定了
pr_id unsigned int not null , -- 完全依賴於主鍵，ct_id 定了，就可以確定 pr_id
pr_name varchar(20) not null, -- 完全依賴於主鍵，ct_id 定了，就可以確定 pr_name
primary key(ct_id),
foreign key(pr_id) references province(pr_id) on delete cascade
);
上述的這兩張表都滿足第二正規化，不過，注意到 city 表中的 pr_name 元組雖然完全依賴於 ct_id , 但是它是通過 pr_id 傳遞依賴於 ct_id 的。
傳遞依賴的壞處：
增：明顯 pr_name 出現冗餘。
刪：無改：改動 province 表的 pr_name 元組，也要同時修改 city 表中的 pr_name 。一不小心就出問題。
查：無
平時小打小鬧似乎用不上正規化，因為設計出來的表總是自然而然地滿足正規化的要求。不過，對於正規化，還是"理解"萬歲吧~
資料庫的三個正規化
強調列的原子性，即列不能夠再分成其他幾列。考慮有這樣乙個表 聯絡人 姓名 性別 如果在實際場景中，乙個聯絡人有家庭 和公司 那麼這種表結構就不符合1nf，應把 列拆分成家庭 和公司 首先是1nf，另外還有兩部分內容。1.乙個表必須有乙個主鍵。2.不在主鍵裡的列必須依賴主鍵的所有內容，而不能只依賴主鍵...
資料庫入門 三個正規化
我覺得他說的最對 我也來解釋一波，參考 資料庫系統概念 書上一開始講得什麼 組合屬性 多值屬性 都是在講 e r模型和表的區別，就是說e r模型允許存在上述子結構，而表不能，跟第一正規化的解釋沒有直接關係。第一正規化實際的解釋為 關係模式中所有的屬性的域都是原子域。舉幾個反例 存在以上屬性的關係模式...
資料庫表三個正規化
通俗地理解三個正規化 通俗地理解是夠用的理解，並不是最科學最準確的理解 第一正規化 1nf是對屬性的原子性約束，要求屬性具有原子性，不可再分解 第二正規化 2nf是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性 同一表中消除部分依賴 第三正規化 3nf是對字段冗餘性的約束，即任何字段不能由其...