在大學的時候就已經對資料庫正規化的概念有所耳聞，但是一直是僅僅知道有這麼乙個概念。最近參加資料庫系統工程師的考試，結合自己的工程經驗，終於對資料庫規範化理論有了一知半解。
本文試圖從工程化的角度，用大白話去解釋資料庫規範化的結論，如果有不嚴謹之處，敬請指正。我不會去詳細介紹每個正規化的嚴格定義，重複別人的結論沒有意義；也不會去解釋為什麼是這個結論，因為我這種俗人已經沒辦法理解那些神仙證明了！
第一正規化(1nf)
這個很容易理解，就4個字，原子屬性。如果你的關係模式連1nf都不滿足，那就是有各種物件巢狀了，這種情況選擇乙個nosql資料庫可能更合適。
第二正規化(2nf)
在1nf基礎上，每乙個非主屬性完全依賴於碼（主鍵）。
概念解釋：
1、非主屬性：在某關係模式的一組屬性中，如果乙個屬性有可能被選中作為主鍵（包括多主鍵的其中乙個），它就是主屬性，否則就是非主屬性。
2、依賴：依賴和決定是一對，符號表示x→y，我們可以說x決定y或y依賴於x，例如身份證號與姓名的關係即為：身份證號→姓名。注意要把x和y當做集合來看待，而不是單一屬性！由此可以引申出一些概念：x→y且y是x的子集，就是平凡的函式依賴（工程實踐中很少見），否則就是非平凡的函式依賴。如果x的任何真子集都不能決定y，那麼y對x就是完全函式依賴，否則就是部分函式依賴。
理解了上述的概念2nf也就很容易理解了。很多關係模式中的碼往往是乙個屬性集合，只有它的所有非主屬性對碼都是完全函式依賴，這個關係模型才符合2nf。下面這個例子就是不符合2nf的：
工作經歷（公司id，身份證號，姓名，開始時間，結束時間）
關係「工作經歷」的碼是，這裡面的「身份證號→姓名」顯然就是部分函式依賴關係，因此不符合2nf。
第三正規化(3nf)
在2nf基礎上，不存在非主屬性對碼的傳遞函式依賴。
概念解釋：
1、傳遞函式依賴：若x→y，y→z，則x→z成立，z對x是傳遞函式依賴。非常簡單的概念。
因此3nf也並不難理解，乙個不符合3nf的典型例子就是使用者管理的場景，在設計開發使用者管理模組的過程中，展示使用者往往需要同時展示使用者所屬的組織機構，這時如果設計使用者關係如下：
使用者（使用者id，姓名，機構id，機構名稱）
主鍵為「使用者id」，存在傳遞函式依賴：使用者id→機構id→機構名稱，顯然不符合3nf。
巴克斯正規化（bcnf）
在3nf的基礎上，消除了主屬性對碼的部分函式依賴和傳遞函式依賴。
說白了，就是把2nf和3nf留下的坑給填上了，因為2nf和3nf說的都是非主屬性和碼之間的依賴關係，bcnf則把主屬性也加入到相應的約束之中，可以說，在滿足bcnf的關係中，部分函式依賴和傳遞函式依賴是完全不存在的。因此從函式依賴的角度來說，bcnf就是規範化程度最高的關係模式！
在工程實踐中，傳統的資訊系統資料庫設計會要求滿足3nf，而且我們習慣於用自增序列或uuid去生成單一的主鍵，因此我們設計的資料庫一般都是符合bcnf的。
第四正規化(4nf)
屬性間不允許有非平凡且非函式依賴的多值依賴。
我查閱了一些資料和案例，發現資料上的描述很枯燥晦澀，而案例的描述又語焉不詳，為了徹底理解4nf，此處採用官方定義與案例結合的方式。下面的多值依賴定義是官方定義。
概念解釋：
1、多值依賴：
設r(u)是屬性集u上的乙個關係模式。x，y，z是u的子集,並且z=u-x-y。關係模式r(u)中多值依賴x→→y成立，當且僅當對r(u)的任一關係r,給定的一對(x，z)值有一組y的值，這組值僅僅決定於x值而與z值無關。
上述的定義簡單理解就是屬性之間存在多對多關係。但是之前我一直不明白的是為什麼要引入乙個看似無關的z，實際上z的作用就是判斷這個多值依賴是不是平凡的。
若x→→y，而z為空集，則稱x→→y為平凡的多值依賴；若z不為空，則稱其為非平凡的多值依賴。
我們現在構建如下場景：公司安排招聘面試，同乙個職位可以屬於多個部門，同乙個部門擁有多個職位，面試官由員工擔任，同乙個面試官可以負責多個職位的面試，乙個職位也可以由多個面試官參與面試。得到如下關係模式（3屬性主鍵）：
面試安排（職位編碼，部門編碼，面試官工號）
此時設x=，y=，z=；
顯然存在x→→y，而z不為空集，因此這個多值依賴是非平凡的；函式依賴要求y的值是被x的乙個或一組值唯一確定的，x→y只是x→→y的乙個特例，因此x→→y是非函式依賴的多值依賴。x→→y這個依賴關係是非平凡且非函式依賴的多值依賴，所以關係模式「面試安排」不符合4nf。同理，x→→z也是非平凡且非函式依賴的多值依賴。
對關係模式「面試安排」進行符合4nf的分解為：
面試安排1（職位編碼，面試官工號）面試安排2（職位編碼，部門編碼）
則上述兩個關係模式中的多值依賴退化成了平凡的多值依賴（因為第三方的z變成了空集），也就滿足了4nf的定義。
還可以對照4nf的官方定義對比：
4nf定義：關係模式r∈1nf，如果對於r的每個非平凡多值依賴x→→y（y 不包含於x），x必含有碼，則r∈4nf。
對於x必含有碼，也就是說主鍵是它的子集這個要求似乎很難達到了，因此實際工作中我們大多數情況下都致力於消除非平凡的多值依賴，讓它退化成平凡多值依賴也就脫離了4nf的限制了。
有人提出乙個簡單的判斷4nf的方法就是，對於乙個有3個屬性的表，給定其中某屬性乙個值，另外兩個屬性對應的兩列沒有多對多關係，那就是4nf。這個方法用於快速判斷4nf還是很可取的。
第五正規化(5nf)
總結：
在傳統的資訊系統的構建過程中，資料庫的正規化標準越高，對應的資料冗餘度就越低，但是系統的關聯關係會更加複雜。正規化的選擇實際上就是資料冗餘度與系統複雜度之間的平衡。從經驗上來說，選擇3nf或bcnf可能是實踐的最優解了，但即使如此，依然給應用程式的開發帶來了很大的麻煩，當你需要獲取業務資料時，往往需要編寫大量的連線查詢的sql語句。其實資料庫的設計應該提供一套完整的解決方案，應該具備配套的檢視、儲存過程、觸發器以及外來鍵的刪除更新級聯等以減輕應用開發人員的負擔，而非只是完成建表就萬事大吉。
最後，作為技術人員，一定不要完全放棄編碼，就像戰士永遠不要放下手中的劍。保持手感，保持對技術的敏感，不斷思考總結，一定會有量變到質變的那一天。
總結 關係型資料庫規範化
關係型資料的關係模式是乙個五元組 r u,d,dom,f r 關係名 u 屬性名的集合，即屬性組 d u中屬性所來自的域 相同型別的值的集合 dom 屬性 u 到域 d 的對映 f 屬性組u上的一組資料依賴。由於d和dom對模式設計關係不大，本文把關係模式化簡成為乙個三元組，即 r u,f 設r u...
關聯式資料庫的規範化
文章分類 資料庫 一 函式依賴 在資料庫中，函式依賴是最基本 最重要的一種依賴。在資料庫中，屬性值之間會發生聯絡，這類聯絡稱為函式依賴。設有屬性集u上的關係模式r u x,y是u的子集，若對於任乙個關係r中的任一元組在x中的屬性值確定後，則在y中的屬性值必確定，則稱y依賴於x。二 正規化和規範化方法...
關係資料 規範化的理解
原則 規範化的目的是乙份資料只儲存在乙個地方。根據上面的原則來理解3種正規化 第一正規化 列的原子性 保證行的唯一性 乙份資料只儲存在乙個地方。第二正規化 非屬性鍵與主鍵的關係 1.滿足第一正規化 2.非鍵屬性依賴於整體主鍵，而不是非鍵屬性僅僅依賴於主鍵中的某個部分。即 無部分依賴 違反第二正規化就...