在資料庫設計的範例使用三時間，我一直認為它是第一個未完成ER畫畫。然後匯出關係模型，否合理，but not！
我們在一開始畫ER圖的時候。就應當和三正規化聯絡起來，將錯誤消滅在源頭。為了能最早的檢驗出錯誤。我們就要對ER圖轉換成關係模式的演算法和三正規化是怎樣消除冗餘，避免衝突有深刻的瞭解，才幹知道怎樣最早發現錯誤。
本文主要以機房收費系統資料庫設計中的一些東西為例，結合三正規化概念。簡述下三正規化。
一，1NF
定義:
假設關係模式R的每一個關係r的屬性值都是不可分的原子值，那麼稱R是第一正規化。
簡單來說。第一正規化要求屬性不可再分。來看一個比較常見的樣例：
比如，在機房收費系統中，比方我們會遇到日期時間是該寫成一個屬性還是分開寫呢？這時候我們就要依據第一正規化來做出一個推斷了，由於第一正規化要求屬性值不可再分，所以我們應該這樣：
二，2NF
定義：
假設關係模式R是1NF，且每一個非主屬性全然函式依賴於候選鍵。那麼稱R是第二正規化。
要明確第二正規化，首先要明確什麼是全然函式依賴？
全然函式依賴：
在R（U）中，假設X→Y，而且對於X的不論什麼一個子集x,都有x→不成立。則稱Y對X全然函式依賴。
如圖，（X1。X2）→Y,而且，X1→Y不成立。X2→Y不成立。
可是，假設在全然函式依賴中，若X→Y，但Y不全然函式依賴於X。則稱Y對X部分函式依賴。
比如，如圖。此時。X1→成立，則Y部分依賴於X1X2;
綜上，我們能夠得出，要滿足第二正規化，就要讓每個非主鍵屬性全然依賴於主鍵。
比如。我們在機房收費系統設計資料庫的時候，對於學生表可能有過這種設計，最開始的時候，我們為了查詢方便，把學生表和卡表這樣做：
可是當我們再次重構資料庫的時候。我們就要依據三正規化來推斷下了。
比如，卡內金額依賴於主鍵學號和卡號，而卡內金額也依賴於卡號，這裡就不滿足2NF了,我們就要將兩張表拆開。
三，3NF
定義:
R滿足1NF。且每一個非主屬性都不傳遞依賴R的候選鍵，則稱實體E時第三正規化。
什麼是非主屬性傳遞碼？
如圖所看到的，為傳遞函式依賴的示意圖：
比如，
還是上面那張表，我們在這裡選的是學號作為主鍵，則表中有：
學號→卡號→卡內金額，此時出現了傳遞依賴。
分析：
2NF和3NF，不管是出現部分依賴還是出現傳遞依賴，都是要將關係模式進行分解，追究產生錯誤的根源，感覺還是E-R圖沒有畫好的緣故。
小結：
1NF將屬性拆成了原子值。2NF和3NF都是為了消除冗餘和異常問題；
所以，三正規化有兩個作用：一是能夠衡量一個資料庫的好壞。二是能夠作為資料庫設計的一個基本原則。
版權宣告：本文部落格原創文章，部落格，未經同意，不得轉載。