剛百度百科看了下 目前數據庫范式加起來共有六種了；即第一范式（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外 商品名字一般也會冗余進去 而且這樣設計也是合理的 一般顧客更關心的是下單那個時候的商品名 也行以后商品名會被更改 但下單那一刻 下次顧客自己的訂單列表 顧客只認下單那的商品名 不然會讓人不可理解與錯誤！
所以並不是一定要完全遵守三大范式 但請在做表結構設計時 還是先充分考慮它 除非特殊情況特殊對待