範式簡介
數據庫技術是計算機和信息科學中發展最迅速的重要領域之一，它的應用和研究範圍不斷擴大，已經成為開發各種信息系統的重要工具，它的廣泛使用，已使計算機應用深入到社會的各個領域。滿足這些規範的數據庫是簡潔的、結構明晰的，同時，不會發生插入(insert)、删除(delete)和更新(update)操作異常。反之則是亂七八糟，不僅給數據庫的編程人員制造麻煩，而且面目可憎，可能存儲了大量不需要的冗餘信息。
關系數據庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規範要求的稱為第二範式（2NF），其餘範式以次類推。一般來說，數據庫隻需滿足第三範式(3NF）就行了。
各類範式
1、第一範式（1NF）：
所謂第一範式（1NF）是指在關系模型中，對于添加的一個規範要求，所有的域都應該是原子性的，即數據庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一範式（1NF）表中的每個域值隻能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重複的域。
說明：在任何一個關系數據庫中，第一範式（1NF）是對關系模式的設計基本要求，一般設計中都必須滿足第一範式（1NF）。不過有些關系模型中突破了1NF的限制，這種稱為非1NF的關系模型。換句話說，是否必須滿足1NF的最低要求，主要依賴于所使用的關系模型。
2、第二範式（2NF）
在1NF的基礎上，非碼屬性必須完全依賴于候選碼（在1NF基礎上消除非主屬性對主碼的部分函數依賴）
第二範式（2NF）是在第一範式（1NF）的基礎上建立起來的，即滿足第二範式（2NF）必須先滿足第一範式（1NF）。第二範式（2NF）要求數據庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一标識。例如在員工表中的身份證号碼即可實現每個一員工的區分，該身份證号碼即為候選鍵，任何一個候選鍵都可以被選作主鍵。在找不到候選鍵時，可額外增加屬性以實現區分，如果在員工關系中，沒有對其身份證号進行存儲，而姓名可能會在數據庫運行的某個時間重複，無法區分出實體時，設計辟如ID等不重複的編号以實現區分，被添加的編号或ID選作主鍵。（該主鍵的添加是在ER設計時添加，不是建庫時随意添加）
第二範式（2NF）要求實體的屬性完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一标識。簡而言之，第二範式就是在第一範式的基礎上屬性完全依賴于主鍵。
3、第三範式（3NF）
在2NF基礎上，任何非主屬性不依賴于其它非主屬性（在2NF基礎上消除傳遞依賴）
第三範式（3NF）是第二範式（2NF）的一個子集，即滿足第三範式（3NF）必須滿足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編号（dept_id）、部門名稱、部門簡介等信息。那麼在員工信息表中列出部門編号後就不能再将部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三範式（3NF）也應該構建它，否則就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴于其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴于主屬性。
4、巴斯-科德範式（BCNF）
Boyce-Codd Normal Form（巴斯-科德範式）
在3NF基礎上，任何非主屬性不能對主鍵子集依賴（在3NF基礎上消除對主碼子集的依賴）
巴斯-科德範式（BCNF）是第三範式（3NF）的一個子集，即滿足巴斯-科德範式（BCNF）必須滿足第三範式（3NF）。通常情況下，巴斯-科德範式被認為沒有新的設計規範加入，隻是對第二範式與第三範式中設計規範要求更強，因而被認為是修正第三範式，也就是說，它事實上是對第三範式的修正，使數據庫冗餘度更小。這也是BCNF不被稱為第四範式的原因。某些書上，根據範式要求的遞增性将其稱之為第四範式是不規範，也是更讓人不容易理解的地方。而真正的第四範式，則是在設計規範中添加了對多值及依賴的要求。
目的原則
規範化目的是使結構更合理，消除存儲異常，使數據冗餘盡量小。便于插入、删除和更新。
遵從概念單一化“一事一地”原則，即一個關系模式描述一個實體或實體間的一種聯系。規範的實質就是概念的單一化。
一個關系模式接着分解可以得到不同關系模式集合，也就是說分解方法不是惟一的。最小冗餘的要求必須以分解後的數據庫能夠表達原來數據庫所有信息為前提來實現。其根本目标是節省存儲空問，避免數據不一緻性，提高對關系的操作效率，同時滿足應用需求。實際上，并不一定要求全部模式都達到BCNF不可。有時故意保留部分冗餘可能更方便數據查詢。尤其對于那些更新頻度不高，查詢頻度極高的數據庫系統更是如此。
反範式
規範化的優點是明顯的，它避免了大量的數據冗餘，節省了存儲空間，保持了數據的一緻性。當一個庫裡的數據經常發生變化時，達到3NF的庫可以使用戶不必在超過兩個以上的地方更改同一個值。那麼是不是隻要把所有的表都規範為3NF後，數據庫的設計就是最優的呢?這可不一定。範式越高意味着表的劃分更細，一個數據庫中需要的表也就越多，用戶不得不将原本相關聯的數據分攤到多個表中。當用戶同時需要這些數據時隻能采用連接表的形式将數據重新合并在一起。同時把多個表聯接在一起的花費是巨大的，尤其是當需要連接的兩張或者多張表數據非常龐大的時候，表連接操作幾乎是一個噩夢，這嚴重地降低了系統運行性能。
