一、第一范式
1NF是對屬性的原子性，要求屬性具有原子性，不可再分解；
表：字段1、 字段2(字段2.1、字段2.2)、字段3 ......
如學生（學號，姓名，性別，出生年月日），如果認為最后一列還可以再分成（出生年，出生月，出生日），它就不是一范式了，否則就是；
二、第二范式
2NF是對記錄的唯一性，要求記錄有唯一標識，即實體的唯一性，即不存在部分依賴；
表：學號、課程號、姓名、學分;
這個表明顯說明了兩個事務(wù):學生信息, 課程信息;由于非主鍵字段必須依賴主鍵，這里學分依賴課程號，姓名依賴與學號，所以不符合二范式。
可能會存在問題：
數(shù)據(jù)冗余:，每條記錄都含有相同信息；刪除異常：刪除所有學生成績，就把課程信息全刪除了；插入異常：學生未選課，無法記錄進數(shù)據(jù)庫；更新異常：調(diào)整課程學分，所有行都調(diào)整。
正確做法:
學生：Student(學號, 姓名)；
課程：Course(課程號, 學分)；
選課關(guān)系：StudentCourse(學號, 課程號, 成績)。
三、第三范式
3NF是對字段的冗余性，要求任何字段不能由其他字段派生出來，它要求字段沒有冗余，即不存在傳遞依賴；
表: 學號, 姓名, 年齡, 學院名稱, 學院電話
因為存在依賴傳遞: (學號) → (學生)→(所在學院) → (學院電話) 。
可能會存在問題：
數(shù)據(jù)冗余:有重復值；更新異常：有重復的冗余信息，修改時需要同時修改多條記錄，否則會出現(xiàn)數(shù)據(jù)不一致的情況 。
正確做法：
學生：(學號, 姓名, 年齡, 所在學院)；
學院：(學院, 電話)。
區(qū)別
一、含義不同：
第二范式（2NF）：關(guān)系模式R屬于第一范式，且每個非主屬性都完全函數(shù)依賴于鍵碼。
第三范式（3NF）：關(guān)系模式R屬于第一范式，且每個非主屬性都不偉遞領(lǐng)帶于鍵碼。
二、內(nèi)容不同：
第二范式（2NF）：首先是 1NF，另外包含兩部分內(nèi)容，一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴于主鍵，而不能只依賴于主鍵的一部分。
第三范式（3NF）：首先是 2NF，另外非主鍵列必須直接依賴于主鍵，不能存在傳遞依賴。即不能存在：非主鍵列 A 依賴于非主鍵列 B，非主鍵列 B 依賴于主鍵的情況。
四、反范式化
一般說來，數(shù)據(jù)庫只需滿足第三范式（3NF）就行了。
沒有冗余的數(shù)據(jù)庫設(shè)計可以做到。但是，沒有冗余的數(shù)據(jù)庫未必是最好的數(shù)據(jù)庫，有時為了提高運行效率，就必須降低范式標準，適當保留冗余數(shù)據(jù)。具體做法是：在概念數(shù)據(jù)模型設(shè)計時遵守第三范式，降低范式標準的工作放到物理數(shù)據(jù)模型設(shè)計時考慮。降低范式就是增加字段，允許冗余，達到以空間換時間的目的。
〖例〗：如訂單表，“金額”這個字段的存在，表明該表的設(shè)計不滿足第三范式，因為“金額”可以由“單價”乘以“數(shù)量”得到，說明“金額”是冗余字段。但是，增加“金額”這個冗余字段，可以提高查詢統(tǒng)計的速度，這就是以空間換時間的作法。
在Rose 2002中，規(guī)定列有兩種類型：數(shù)據(jù)列和計算列?！敖痤~”這樣的列被稱為“計算列”，而“單價”和“數(shù)量”這樣的列被稱為“數(shù)據(jù)列”。
一、范式
范式的英文名稱是Normal Form，它是英國人E.F.Codd（關(guān)系數(shù)據(jù)庫的老祖宗）在上個世紀70年代提出關(guān)系數(shù)據(jù)庫模型后總結(jié)出來的。范式是關(guān)系數(shù)據(jù)庫理論的基礎(chǔ)，也是我們在設(shè)計數(shù)據(jù)庫結(jié)構(gòu)過程中所要遵循的規(guī)則和指導方法。目前有跡可尋的共有8種范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三個范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。
第一范式（1NF）
第一范式其實是關(guān)系型數(shù)據(jù)庫的基礎(chǔ)，即任何關(guān)系型數(shù)據(jù)庫都是符合第一范式的。簡單的將第一范式就是每一行的各個數(shù)據(jù)都是不可分割的，同一列中不能有多個值，如果出現(xiàn)重復的屬性就需要定義一個新的尸實體。
下面數(shù)據(jù)庫便不符合第一范式：
| 1 2 3 4 5 6 |
|
上面描述的數(shù)據(jù)所表達的意思是，Mike在Tencent工作，而John同時在ByteDance和Tencent工作（假設(shè)這是可能的）。但是這種表達方式并不符合第一范式，即列的數(shù)據(jù)必須是不可分的，要滿足第一范式，必須是下面的這種形式：
| 1 2 3 4 5 6 7 |
|
第二范式（2NF）
首先，一個數(shù)據(jù)庫要滿足第二范式必須要先滿足第一范式。
我們先看一個表格：
| 1 2 3 4 5 6 7 8 |
|
這個表描述了被雇傭者，工作部門和領(lǐng)導的關(guān)系。這個表所表示的關(guān)系在現(xiàn)實生活中是完全可能存在的，現(xiàn)在讓我們考慮一個問題，如果Brown接任Accounting部門的領(lǐng)導，我們需要怎樣對表進行修改？這個問題將會變得非常麻煩，因為我們會發(fā)現(xiàn)數(shù)據(jù)都耦合在一起了，你很難找到一個很好的能唯一確定每一行的判斷條件來執(zhí)行你的UPDATE語句。而我們把能夠唯一表示數(shù)據(jù)庫中表的一行的數(shù)據(jù)成為這個表的主鍵。 因此，沒有主鍵的表是不符合第二范式的，也就是說符合第二范式的表需要規(guī)定主鍵。
因此我們?yōu)榱耸股厦娴谋矸系诙妒?，需要將它拆分為兩個表：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
在這兩個表中，第一個表的主鍵為employee，第二個表的主鍵為department。在這種情況下，完成上面的問題就顯得非常簡單了。
第三范式（3NF）
一個關(guān)系型數(shù)據(jù)庫要滿足第三范式必須要先滿足第二范式。
將第三范式前，我們同樣先看兩個表：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
上面的兩個表格的主鍵分別為studentid和subjectid，很顯然兩個表都符合第二范式。
但是我們會發(fā)現(xiàn)這兩個表有重復冗余的數(shù)據(jù)score。因此第三范式就是要消除冗余的數(shù)據(jù)，具體到上面的情況，就是兩個表只有一個能夠存在score這一列數(shù)據(jù)。那么怎么將這兩個表聯(lián)系起來呢，這里就出現(xiàn)了外鍵。如果兩個表中有冗余重復的列，而且這個表中的一個非主鍵列在另一個表中是主鍵，那么我們?yōu)榱讼哂嗔锌梢园堰@個非主鍵列作為聯(lián)系兩個表的橋梁，也就是外鍵。 通過觀察可以發(fā)現(xiàn)，studentid在第一個表中是主鍵，在第二個表中是非主鍵，所以他就是第二個表的外鍵。因此上述情況我們有了以下符合第三范式的寫法：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
可以發(fā)現(xiàn)在設(shè)定了外鍵之后，第一個表即使刪除了score列，也可以通過studentid在第二個表中查找到相應(yīng)的score的值，這樣即消除了數(shù)據(jù)的冗余，又不會影響查找，滿足第三范式。
二、范式的優(yōu)點和缺點
范式的優(yōu)點
- 范式化的更新操作通常要比反范式化要快。
- 當數(shù)據(jù)較好地范式化時，就只有很少或者沒有重復的數(shù)據(jù)，所以只需要修改更少的數(shù)據(jù)。
- 范式化的表通常都比較小，可以更好的放在內(nèi)存中，所以執(zhí)行操作會更快。
- 很少有多余的數(shù)據(jù)意味著檢索列表數(shù)據(jù)時更少需要DISTINCT或者GROUP BY語句。
范式的缺點
- 范式化的缺點就是通常需要關(guān)聯(lián)。稍微復雜一些的查詢語句在符合范式的數(shù)據(jù)庫上都可能需要至少一次關(guān)聯(lián)，也許更多，這不但代價昂貴，也可能使一些索引策略無效。
