第一范式（1NF）
所謂第一范式（1NF）是指在關系模型中，對域添加的一個規范要求，所有的域都應該是原子性的，即數據庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分為不同的屬性。在符合第一范式（1NF）表中的每個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一范式就是無重復的域。
說明：在任何一個關系數據庫中，第一范式（1NF）是對關系模式的設計基本要求，一般設計中都必須滿足第一范式（1NF）。不過有些關系模型中突破了1NF的限制，這種稱為非1NF的關系模型。換句話說，是否必須滿足1NF的最低要求，主要依賴於所使用的關系模型。
第二范式（2NF）
在1NF的基礎上，非碼屬性必須完全依賴於候選碼（在1NF基礎上消除非主屬性對主碼的部分函數依賴。
第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實例或記錄必須可以被唯一地區分。選取一個能區分每個實體的屬性或屬性組，作為實體的唯一標識。例如在員工表中的身份證號碼即可實現每個一員工的區分，該身份證號碼即為候選鍵，任何一個候選鍵都可以被選作主鍵。在找不到候選鍵時，可額外增加屬性以實現區分，如果在員工關系中，沒有對其身份證號進行存儲，而姓名可能會在數據庫運行的某個時間重復，無法區分出實體時，設計辟如ID等不重復的編號以實現區分，被添加的編號或ID選作主鍵。（該主鍵的添加是在ER設計時添加，不是建庫時隨意添加）
第二范式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵<字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。
簡而言之，第二范式就是在第一范式的基礎上屬性完全依賴於主鍵。
第三范式（3NF）
在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）
第三范式（3NF）是第二范式（2NF）的一個子集，即滿足第三范式（3NF）必須滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。
例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么在員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三范式（3NF）也應該構建它，否則就會有大量的數據冗余。
簡而言之，第三范式就是屬性不依賴於其它非主屬性，也就是在滿足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。
總結和實例描述
第一范式：字段的原子性：簡單來說就是每一個字段不能分割出其他的屬性
確保每列的原子性
如果每列(或者每個屬性)都是不可再分的最小數據單元(也稱為最小的原子單元)，則滿足第一范式.
例如:顧客表(姓名、編號、地址、……)其中"地址"列還可以細分為國家、省、市、區等。
第二范式：保證主鍵的唯一性，屬性完全依賴於主鍵
在第一范式的基礎上更進一層,目標是確保表中的每列都和主鍵相關
如果一個關系滿足第一范式,並且除了主鍵以外的其它列,都依賴於該主鍵,則滿足第二范式.
例如:訂單表(訂單編號、產品編號、定購日期、價格、……)，"訂單編號"為主鍵，"產品編號"和主鍵列沒有直接的關系，即"產品編號"列不依賴於主鍵列，應刪除該列。
第三范式：消除傳遞依賴，保證每個屬性都直接依賴於主鍵
在第二范式的基礎上更進一層,目標是確保每列都和主鍵列直接相關,而不是間接相關
如果一個關系滿足第二范式,並且除了主鍵以外的其它列都不依賴於主鍵列，則滿足第三范式。
為了理解第三范式，需要根據Armstrong公里之一定義傳遞依賴。假設A、B和C是關系R的三個屬性，如果A-〉B且B-〉C，則從這些函數依賴中，可以得出A-〉C， 如上所述，依賴A-〉C是傳遞依賴。