設計關係資料庫時，遵從不同的規範要求，設計出合理的關係型資料庫，這些不同的規範要求被稱為不同的正規化，各種正規化呈遞次規範，越高的正規化資料庫冗餘越小。

目前關係資料庫有六種正規化：第一正規化（1NF）、第二正規化（2NF）、第三正規化（3NF）、巴斯-科德正規化（BCNF）、第四正規化(4NF）和第五正規化（5NF，又稱完美正規化）。

正規化簡介           

設計關係資料庫時，遵從不同的規範要求，設計出合理的關係型資料庫，這些不同的規範要求被稱為不同的正規化，各種正規化呈遞次規範，越高的正規化資料庫冗餘越小。

目前關係資料庫有六種正規化：第一正規化（1NF）、第二正規化（2NF）、第三正規化（3NF）、巴斯-科德正規化（BCNF）、

第四正規化(4NF）和第五正規化（5NF，又稱完美正規化）。滿足最低要求的正規化是第一正規化（1NF）。在第一正規化的基礎上進一步滿足更多規範要求的稱為第二正規化（2NF），其餘正規化以次類推。一般說來，資料庫只需滿足第三正規化(3NF）就行了。

各類正規化

第一正規化（1NF）

定義：如果關係R 中所有屬性的值域都是單純域，那麼關係模式R是第一正規化的。

存在非主屬性對碼的部分依賴關係 R(A,B,C)  AB是碼  C是非主屬性 B-->C B決定C C部分依賴於B。

所謂第一正規化（1NF）是指在關係模型中，對域新增的一個規範要求，所有的域都應該是原子性的，即資料庫表的每一列都是不可分割的原子資料項

，而不能是集合，陣列，記錄等非原子資料項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一正規化（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一正規化就是無重複的域。

說明：在任何一個關係資料庫中，第一正規化（1NF）是對關係模式的設計基本要求，一般設計中都必須滿足第一正規化（1NF）。不過有些關係模型中突破了1NF的限制，這種稱為非1NF的關係模型。換句話說，是否必須滿足1NF的最低要求，主要依賴於所使用的關係模型。

第一正規化（1NF）：強調的是列的原子性，即列不能夠再分成其他幾列。  考慮這樣一個表：【聯絡人】（姓名，性別，電話）  如果在實際場景中，一個聯絡人有家庭電話和公司電話，那麼這種表結構設計就沒有達到 1NF。要符合 1NF 我們只需把列（電話）拆分，即：【聯絡人】（姓名，性別，家庭電話，公司電話）。

符合第一模式的特點就有：

1)有主關鍵字，

2)主鍵不能為空，

3)主鍵不能重複,

4)欄位不可以再分。

第二正規化（2NF）

定義：如果關係模式R是第一正規化的，而且關係中每一個非主屬性不部分依賴於主鍵，稱R是第二正規化的。

存在非主屬性對碼的傳遞性依賴 R(A,B,C) A是碼 A -->B ,B-->C。

在1NF的基礎上，非碼屬性必須完全依賴於候選碼（在1NF基礎上消除非主屬性對主碼的部分函式依賴）

第二正規化（2NF）是在第一正規化（1NF）的基礎上建立起來的，即滿足第二正規化（2NF）必須先滿足第一正規化（1NF）。第二正規化（2NF）要求資料庫表中的每個例項或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。例如在員工表中的身份證號碼即可實現每個一員工的區分，該身份證號碼即為候選鍵，任何一個候選鍵都可以被選作主鍵。在找不到候選鍵時，可額外增加屬性以實現區分，如果在員工關係中，沒有對其身份證號進行儲存，而姓名可能會在資料庫執行的某個時間重複，無法區分出實體時，設計闢如ID等不重複的編號以實現區分，被新增的編號或ID選作主鍵。（該主鍵的新增是在ER設計時新增，不是建庫時隨意新增）

第二正規化（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上一個列，以儲存各個例項的唯一標識。簡而言之，第二正規化就是在第一正規化的基礎上屬性完全依賴於主鍵。

所以第二正規化的主要任務就是滿足第一正規化的前提下，消除部分函式依賴。

StudyNo   |   Name   |   Sex   |         Email         |      Phone    |    ClassNo   |   ClassAddress

01                  john        Male       [email protected]com     18922211456      001           科技樓204

02                  mary      famale    yyy@qq.com        18811123455      002            圖書館301

這個表完全滿足於第一正規化，主鍵由StudyNo和ClassNo組成，這樣才能定位到指定行。但是,ClassAddress部分依賴於關鍵字(ClassNo-〉ClassAddress)，所以要變為兩個表。

表一

StudyNo   |   Name   |   Sex   |         Email         |      Phone    |    ClassNo  

01                  john        Male       [email protected]com     18922211456      001           

02                  mary      famale    yyy@qq.com        18811123455      002           

表二

 ClassNo  | ClassAddress

 001       科技樓204

 002       圖書館301

第三正規化（3NF）

在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）

第三正規化（3NF）是第二正規化（2NF）的一個子集，即滿足第三正規化（3NF）必須滿足第二正規化（2NF）。簡而言之，第三正規化（3NF）要求一個關係中不包含已在其它關係已包含的非主關鍵字資訊。例如，存在一個部門資訊表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等資訊。那麼在員工資訊表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的資訊再加入員工資訊表中。如果不存在部門資訊表，則根據第三正規化（3NF）也應該構建它，否則就會有大量的資料冗餘。簡而言之，第三正規化就是屬性不依賴於其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。

不存在非主屬性對碼的傳遞性依賴以及部分性依賴 ： StudyNo   |   Name   |   Sex   |      Email         |      bounsLevel   |     bouns

20040901      john         Male       [email protected]com   優                       $80000

20040902     mary         famale    yyy@qq.com     良                       $6000

這個完全滿足了第二正規化,但是bounsLevel和bouns存在傳遞依賴，更改為：

StudyNo   |   Name   |   Sex   |      Email         |      bouunsNo

20040901      john         Male       [email protected]com     1

20040902     mary        famale    yyy@qq.com       2

bounsNo   |   bounsLevel   |   bouns

1                   優                  $80000

 2                 良                   $6000

這裡我比較喜歡用bounsNo作為主鍵，基於兩個原因

1）不要用字元作為主鍵。可能有人說：如果我的等級一開始就用數值就代替呢？

2）但是如果等級名稱更改了，不叫 1，2 ，3或優、良，這樣就可以方便更改，所以我一般優先使用與業務無關的欄位作為關鍵字。

一般滿足前三個正規化就可以避免資料冗餘。

巴斯-科德正規化（BCNF）

Boyce-Codd Normal Form（巴斯-科德正規化）

在3NF基礎上，任何非主屬性不能對主鍵子集依賴（在3NF基礎上消除對主碼子集的依賴）

巴斯-科德正規化（BCNF）是第三正規化（3NF）的一個子集，即滿足巴斯-科德正規化（BCNF）必須滿足第三正規化（3NF）。通常情況下，巴斯-科德正規化被認為沒有新的設計規範加入，只是對第二正規化與第三正規化中設計規範要求更強，因而被認為是修正第三正規化，也就是說，它事實上是對第三正規化的修正，使資料庫冗餘度更小。這也是BCNF不被稱為第四正規化的原因。某些書上，根據正規化要求的遞增性將其稱之為第四正規化是不規範，也是更讓人不容易理解的地方。而真正的第四正規化，則是在設計規範中添加了對多值及依賴的要求。

定義：關係模式R<U,F>∈1FNF,若X→Y且Y不是X的子集時X必含有碼，則R<U,F>∈BCNF。也就是說，關係模式R<U,F>中，若每一個決定因素都包含碼，則R<U,F>∈BCNF。

由BCNF的定義可以得到結論，一個滿足BCNF的關係模式有：

-所有非主屬性對每一個碼都是完全函式依賴。

-所有主屬性對每一個不包含它的碼也是完全函式依賴。

-沒有任何屬性完全函式依賴於非碼的任何一組屬性。

若R∈BCNF，按定義排除了任何屬性對碼的傳遞依賴與部分依賴，所以R∈3NF。 [1]

一般關係型資料庫設計中，達到BCNF就可以了！

其他正規化應用例項

下面以一個學校的學生系統為例分析說明，這幾個正規化的應用。

第一正規化（1NF）

資料庫表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本型別構成，包括整型、實數、字元型、邏輯型、日期型等。在當前的任何關係資料庫管理系統（DBMS）中，傻瓜也不可能做出不符合第一正規化的資料庫，因為這些DBMS不允許你把資料庫表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一正規化的資料庫都是不可能的。

首先我們確定一下要設計的內容包括那些。學號、學生姓名、年齡、性別、課程名稱、課程學分、系別、學科成績，系辦地址、系辦電話等資訊。為了簡單我們暫時只考慮這些欄位資訊。我們對於這些資訊，所關心的問題有如下幾個方面。

學生有那些基本資訊？

學生選了那些課，成績是什麼？

每個課的學分是多少？

學生屬於那個系，系的基本資訊是什麼？

第二正規化（2NF）

首先我們考慮，把所有這些資訊放到一個表中（學號，學生姓名、年齡、性別、課程、課程學分、系別、學科成績，系辦地址、系辦電話）下面存在如下的依賴關係。

(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)

問題分析

姓名和年齡不依於課程，即不完全依賴於主屬性因此不滿足第二正規化的要求，會產生如下問題：

資料冗餘：同一門課程由n個學生選修，"學分"就重複n-1次；同一個學生選修了m門課程，姓名和年齡就重複了m-1次。

更新異常：

1）若調整了某門課程的學分，資料表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。

2）假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫。

刪除異常 ：假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫表中刪除。但是，與此同時，課程名稱和學分資訊也被刪除了。很顯然，這也會導致插入異常。

解決方案

把選課關係表SelectCourse改為如下三個表：

學生：Student（學號，姓名，年齡，性別，系別，系辦地址、系辦電話）；

課程：Course（課程名稱,學分）；

選課關係：SelectCourse（學號，課程名稱，成績）。

第三正規化（3NF）

接著看上面的學生表Student（學號，姓名，年齡，性別，系別，系辦地址、系辦電話），關鍵字為單一關鍵字"學號"，因為存在如下決定關係：

（學號）→ （姓名，年齡，性別，系別，系辦地址、系辦電話

但是還存在下面的決定關係：

（學號） → (系別）→（系辦地點，系辦電話）

即存在非關鍵欄位"系辦地點"、"系辦電話"對關鍵欄位"學號"的傳遞函式依賴。

它也會存在資料冗餘、更新異常、插入異常和刪除異常的情況。

根據第三正規化把學生關係表分為如下兩個表就可以滿足第三正規化了：

學生：（學號，姓名，年齡，性別，系別）；

系別：（系別，系辦地址、系辦電話）。

上面的資料庫表就是符合I，Ⅱ，Ⅲ正規化的，消除了資料冗餘、更新異常、插入異常和刪除異常。