這篇文章簡單介紹一下資料庫的1nf正規化、2nf正規化、3nf正規化。
1nf正規化要求資料庫中不能有可以繼續拆分的列，使資料庫滿足1nf正規化要求的方法是拆分列。例項如下：
姓名**
張三手機：18000001111，固話：010-99001100
這樣一張表不滿足1nf的要求，因為**那一列顯然可以拆分為多個列，拆分之後如下：
姓名手機
固定**
張三18000001111
010-99001100
1nf 通常很難違背，現代dbms列是最小單位，除非故意，否則不可能設計出違背1nf的資料表
2nf通俗的說就是有主鍵的同時沒有部分依賴，部分依賴指的是一些非主屬性依賴於主鍵的一部分，而不是主鍵的全部，使資料庫滿足2nf的方法是拆分表。例項如下：
學號課程號
課程名稱
成績01
01作業系統
99這個表的主鍵是學號和課程號（學號，課程號），而課程名稱只依賴於課程號，是部分依賴於主鍵的，不滿足2nf，主鍵和依賴情況如下：
主鍵（學號，課程號）
依賴（學號，課程號）–>成績，課程號–>課程名稱，第二個是部分依賴
需要進行拆分
1 課程表
課程號課程名稱
01作業系統
2 選課表
學號課程號
成績01
0199
這樣以上兩個表的的主鍵和依賴如下，則不存在部分依賴：
1 課程表
課程號是主鍵，依賴為 課程號–>課程名稱
2 選課表
（課程號，學號）是主鍵，依賴為（學號，課程號）–> 成績
3nf 是在2nf的基礎上消除傳遞依賴的情況，例如以下資料表，滿足2nf，但存在傳遞依賴，不滿足3nf
學號姓名
班號班級名稱
120101
張三1201
計科1班
上表不滿足3nf，下面是主鍵和依賴：
主鍵：學號
依賴：學號–>姓名，學號–>班號，學號–>班級名稱，但是其中的學號–>班級名稱是傳遞依賴，因為班級名稱依賴於班號，所以實際的依賴情況是學號–>班號–>班級名稱，產生了傳遞依賴，進行如下拆分即可去掉依賴
1 學生表
學號姓名
班號120101
張三1201
2 班級表
班號班級名稱
1201
計科1班
1nf 列不可再分
判斷2nf m-n 型關係中摻雜了m或n所屬的表的一些資料（選課（學生-課程）摻雜了課程名稱）
判斷3nf 1-n 型關係中摻雜了m或n所屬的表的一些資料（學生（班級-學生）摻雜了班級名稱）
是「符合某一種級別的關係模式的集合，表示乙個關係內部各屬性之間的聯絡的合理化程度」。在進入正規化的講解前，需要先了解5個概念：「函式依賴」、「完全函式依賴」、「傳遞函式依賴」「碼」、「非主屬性」。
可以這麼理解（但並不是特別嚴格的定義）：若在一張表中，在屬性（或屬性組）x的值確定的情況下，必定能確定屬性y的值，那麼就可以說y函式依賴於x，寫作 x → y。也就是說，在資料表中，不存在任意兩條記錄，它們在x屬性（或屬性組）上的值相同，而在y屬性上的值不同。這也就是「函式依賴」名字的由來，類似於函式關係 y = f(x)，在x的值確定的情況下，y的值一定是確定的。
在一張表中，若 x → y，且對於 x 的任何乙個真子集（假如屬性組 x 包含超過乙個屬性的話），x 』 → y 不成立，那麼我們稱 y 對於 x 完全函式依賴，記作x f→ y
例如：學號 f→ 姓名
（學號，課名） f→ 分數 （注：因為同乙個的學號對應的分數不確定，同乙個課名對應的分數也不確定）
反之為部分函式依賴，記作x p→ y
例如：（學號，課名） p→ 姓名 （注：因為僅由學號就可以確定姓名）
傳遞函式依賴：
假如 z 函式依賴於 y，且 y 函式依賴於 x (在『y不包含於x，且 x 不函式依賴於 y』這個前提下），那麼就稱 z 傳遞函式依賴於 x ，記作 x t→ z
碼：設 k 為某錶中的乙個屬性或屬性組，若除 k 之外的所有屬性都完全函式依賴於 k（這個「完全」不要漏了），那麼我們稱 k 為候選碼，簡稱為碼。在實際中通常可以理解為：假如當 k 確定的情況下，該錶除 k 之外的所有屬性的值也就隨之確定，那麼 k 就是碼。一張表中可以有超過乙個碼。（實際應用中為了方便，通常選擇其中的乙個碼作為主碼）
包含在任何乙個碼中的屬性稱為主屬性，反之則為非主屬性。
全碼：如果乙個碼包含了所有的屬性，這個碼就是全碼。
主屬性：乙個屬性只要在任何乙個候選碼中出現過，這個屬性就是主屬性。
非主屬性：與上面相反，沒有在任何候選碼中出現過，這個屬性就是非主屬性。
外碼：乙個屬性（或屬性組），它不是碼，但是它別的表的碼，它就是外碼。
候選碼： 若關係中的某一屬性或屬性組的值能唯一的標識乙個元組，而其任何真子集都不能再標識，則稱該屬性組為（超級碼）候選碼。
資料庫設計正規化
目前關聯式資料庫有六種正規化 第一正規化 1nf 第二正規化 2nf 第三正規化 3nf 第四正規化 4nf 第五正規化 5nf 和第六正規化 6nf 滿足最低要求的正規化是第一正規化 1nf 在第一正規化的基礎上進一步滿足更多要求的稱為第二正規化 2nf 其餘正規化以次類推。一般說來，資料庫只需滿...
資料庫設計正規化
前言 為什麼要寫這篇文章呢，從去年年底開始，就和很多做技術的朋友交流過，從資料庫設計到資料庫架構各個方面的內容。有一些朋友執著於orm，執著於所謂的資料庫設計，卻忘記了一切技術是要為業務服務這個基石。當然這文章裡也有一些自己的理解，想向大家表達。正規化是什麼 正規化是符合某一種級別的關係模式的集合。...
資料庫正規化設計
在軟體開發過程中，資料庫的設計是非常重要的。可以說，良好的資料庫設計，是對使用者需求的理解的精準定位。它不僅能夠使得軟體開發起來非常便捷，而且還能夠使軟體系統高效執行，同時，為日後的維護或者更換資料庫提供便利。在最近開發系統的過程中，感覺收穫最大的也是關於資料庫的操作。最初開發機房收費系統的時候，由...