原則：
規範化的目的是乙份資料只儲存在乙個地方。
根據上面的原則來理解3種正規化：
第一正規化：
列的原子性；
保證行的唯一性---乙份資料只儲存在乙個地方。
第二正規化：非屬性鍵與主鍵的關係
1.滿足第一正規化
2.非鍵屬性依賴於整體主鍵，而不是非鍵屬性僅僅依賴於主鍵中的某個部分。即：無部分依賴:
違反第二正規化就是存在部分依賴（非鍵屬性僅僅依賴於主鍵中的某個部分）。
違反第二正規化這有點像：
在乙個由諸多長老全部舉手表才能表決的組織裡，你卻只聽乙個或個別長老的話，這可是壞了規矩的。
例如，如下的關係就違背了第二正規化：
關係名：personpet（人寵物）
主鍵：pesonid 、petid
非鍵屬性：pesonname、petname、pettype
違背第二正規化：pesonname只依賴於pesonid
petname只依賴於petid
舉個例子，違反了第二正規化儲存的資料的樣子：
pesonid petid pesonname petname
1 1 人才1 寵物1
2 2 人才2 寵物2
3 1 人才3 寵物1
在現實生活中，人和寵物的關係是多對多的關係，即：
1個人可以有0、1、1以上個寵物
1個寵物可以屬於0（如流浪狗）、1（單身it男）、1個以上（一對情侶）個人
我們從上表因為違反第二正規化而儲存的資料違反規範化的原則：
規範化的目的是乙份資料只儲存在乙個地方。
即：petid為1的寵物，在儲存資料的時候，被複製了多次，存放的不同的地方。
這樣會對資料的增、刪、改。會有什麼影響：
增:1.通常來說，當需要對單個事物（單個人、單個寵物）進行處理，而不是處理他們之間關係時，
因為沒有專門為「人」這個實體建立了的表（如:person表）為了增加乙個人，不得不在personpet（人寵物表）中新增人
的相關資訊，而在「寵物」相關的列輸入無意義的值。
在單獨查詢人（不查詢寵物）的時，不得不額外去除掉那些來自寵物相關資訊。
2.只要乙個人有多個寵物,這個人的資訊將被多次複製。同樣：
3.只要乙個寵物屬於多個人，這個寵物的資訊也將被多少複製。
刪：當需要對單個事物（單個人、單個寵物）進行處理，而不是處理他們之間關係時，對刪除的影響：
如果pesonid為1和3（這對情侶可能同時出現車禍）的人都沒，要刪除這兩個人，儲存的資料就是這樣的：
pesonid petid pesonname petname
null 1 null 寵物1
2 2 人才2 寵物2
null 1 null 寵物1
可以看到這樣的設計基本廢掉了。
改：資料同步問題， 例如：通過主鍵（pesonid ，petid）=（1,1）修改 petname的值「寵物1」為「寵物007」，如果在程式設計時沒有
注意同步
pesonid petid pesonname petname
3 1 人才3 寵物1
那麼就破壞了資料。
第三正規化：非屬性鍵之間的關係
1.滿足第二正規化
2.非屬性鍵不依賴於非屬性鍵，即：不存在傳遞依賴。
違反第三正規化這有點像：
在朝廷中有個皇帝（主鍵）就夠了，有人結黨私營，搞小團體，聽命於乙個小頭目（非屬性鍵依賴於非屬性鍵），也是壞了規矩的。
book表
主鍵：bookisbnnunmber
非屬性鍵：title
price
publishname
publishcity
這個表滿足了第二正規化.
但是違反了第三正規化：
非屬性鍵publishcity依賴於非屬性鍵publishname。
違反了第三正規化將導致如下問題，例如下面違反了第三正規化的表儲存的資料：
bookisbnnunmber title price publishname publishcity
1001 《我是人才》 63.1 人才出版社 地球村
1002 《我是蠢材》 87.2 人才出版社 地球村
按常規，我們都是通過「主鍵」去唯一定位要修改的資料,所以，用如下sql語句：
update adb.book
set publishcity='月亮城'
where bookisbnnunmber=『1001』;
執行以上sql後，表中的資料如下：
bookisbnnunmber title price publishname publishcity
1001 《我是人才》 63.1 人才出版社 月亮城
1002 《我是蠢材》 87.2 人才出版社 地球村
這就產生了資料同步的問題，資料在更新時被破壞了。
publishname publishcity
人才出版社 月亮城
人才出版社 地球村
由於違反了第三正規化（非屬性鍵publishcity依賴於非屬性鍵publishname），
我們就得寫額外的處理去更新所有列的publishname
update adb.book
set publishcity='月亮城'
where publishcity='地球村' and publishname='人才出版社'
這樣，說明一點，違反第三正規化，為了更細資料時，避免非屬性鍵之間依賴產生的資料同步問題，不得不
進行而不處理資料同步問題，但是這額外的同步資料操作很容易被忘記，
更糟糕的是，系統的關係會隨著時間的關係不斷變化，你也將越來越頭痛。
關聯式資料庫的規範化
文章分類 資料庫 一 函式依賴 在資料庫中，函式依賴是最基本 最重要的一種依賴。在資料庫中，屬性值之間會發生聯絡，這類聯絡稱為函式依賴。設有屬性集u上的關係模式r u x,y是u的子集，若對於任乙個關係r中的任一元組在x中的屬性值確定後，則在y中的屬性值必確定，則稱y依賴於x。二 正規化和規範化方法...
關聯式資料庫規範化總結
最近本人在準備軟考，所以不得不拿起大一大二時的書本，再次複習一遍。在做軟考的試題中遇到了幾個常遇到的問題，在這裡就討論一下關係型資料庫規範化的問題。關係型資料庫設計的理論核心是資料間的函式依賴問題，衡量的標準是關係規範化的程度及分解的無損連線和保持函式的依賴性。函式依賴是最重要的資料依賴。函式依賴又...
關聯式資料庫規範化總結
最近本人在準備軟考，所以不得不拿起大一大二時的書本，再次複習一遍。在做軟考的試題中遇到了幾個常遇到的問題，在這裡就討論一下關係型 資料庫規範化的問題。關係型資料庫設計的理論核心是資料間的函式依賴問題，衡量的標準是關係規範化的程度及分解的無損連線和保持函式的依賴性。函式依賴是最重要的資料依賴。函式依賴...