數據庫三大範式詳解

剛百度百科看了下  目前數據庫範式加起來共有六種了；即第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。越日後數據庫的冗餘就越小。

先來看第一範式：看下百度百科定義:

所謂 第一範式（1NF）是指在 關係模型中，對於添加的一個規範要求，全部的域都應該是原子性的，即數據庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分爲不一樣的屬性。在符合第一範式（1NF）表中的每一個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重複的域。

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

我批註一下我我的的理解：所謂全部域都是原子表示每一個列不能再拆分。

好比有這樣的一張表

ID  | 用戶姓名| sex| age|所在區域...

這樣一張用戶表 很簡單的幾個列名  但若是一開始這樣設計實際上是不符合第一範式的。由於區域這個字段，其實很是籠統  詳細分話其實還能夠分 省  市  區  甚至街道。因此這樣的表設計不符合第一範式

 

第二範式:

再看百科的定義:

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

第二範式（2NF）是在第一範式（1NF）的基礎上創建起來的，即知足第二範式（2NF）必須先知足第一範式（1NF）。第二範式（2NF） 要求數據庫表中的每一個實例或記錄必須能夠被惟一地區分。選取一個能區分每一個實體的屬性或屬性組，做爲實體的惟一標識。例如在員工表中的身份證號碼便可實現每一個一員工的區分，該身份證號碼即爲候選鍵，任何一個候選鍵均可以被選做主鍵。在找不到候選鍵時，可額外增長屬性以實現區分，若是在員工關係中，沒有對其身份證號進行存儲，而姓名可能會在數據庫運行的某個時間重複，沒法區分出實體時，設計闢如ID等不重複的編號以實現區分，被添加的編號或ID選做主鍵。（該主鍵的添加是在ER設計時添加，不是建庫時隨意添加）

第二範式（2NF）要求實體的屬性徹底依賴於主關鍵字。所謂徹底依賴是指不能存在僅依賴主關鍵字一部分的屬性，若是存在，那麼這個屬性和主關鍵字的這一部分應該分離出來造成一個新的實體，新實體與原實體之間是一對多的關係。爲實現區分一般須要爲表加上一個列，以存儲各個實例的惟一標識。簡而言之， 第二範式就是在第一範式的基礎上屬性徹底依賴於主鍵

 

說明：這個第一範式是在第一範式的基礎上才成立的 ，這個是前提。第二這個範式明確了 數據庫表中的記錄必須有一個惟一標識的屬性用來區分記錄。【因此數據不能出現冗餘，重複！！！】

先看下以下表結構設計 ：

ID|訂單編號|房間號|聯繫人|聯繫人手機|聯繫人電話號碼

根據業務  這裏有一種狀況 若是一我的同時預訂了幾個房間  那麼從記錄結果的角度來說 可能存在數據冗餘 即一我的訂購了多個房間後 顯示多個相同的姓名 手機號  電話號碼信息，因此通常作法是將聯繫人，聯繫人手機，聯繫人號碼單獨獨立出去，主表以一個聯繫人ID做爲與另外一張外鍵表關聯。

上述例子中若是根據百科的理解實際上是這張表中沒有一個能區分惟一的屬性，一我的能夠同時訂N個房間，訂單號 房間號 都會不一樣，但聯繫人相關信息確是惟一的 因此這裏須要創建一個候選鍵，至於該鍵相關的其餘屬性均可以分離出去作到屬性徹底依賴主鍵。

 

第三範式:

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

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

這個範式強調 字段不能有傳遞性設計。好比 文中講的  

員工ID|員工其餘信息。。。|部門ID|部門名稱|部門簡介

這張表員工ID及員工相關信息加上部門ID實際上是一個總體  若是此時加上部門ID以後的信息 就違反了屬性依賴於其餘非主屬性的狀況 應該單獨分離。目的仍是作到數據儘可能不冗餘

 

 

實際狀況是適當的冗餘是在所不免的。好比訂單類型的表  其實 除了購買商品ID外 商品名字通常也會冗餘進去  並且這樣設計也是合理的  通常顧客更關心的是下單那個時候的商品名  也行之後商品名會被更改 但下單那一刻 下次顧客本身的訂單列表  顧客只認下單那的商品名  否則會讓人不可理解與錯誤！

 

因此並非必定要徹底遵照三大範式  但請在作表結構設計時 仍是先充分考慮它  除非特殊狀況特殊對待