下面引用的是百度文庫的解釋，之後是我自己的理解，如果我寫的理解不了可以看下百度文庫的解釋！
百度文庫： 範式簡介編輯 設計關係數據庫時，遵從不同的規範要求，設計出合理的關係型數據庫，這些不同的規範要求被稱爲不同的範式，各種範式呈遞次規範，越高的範式數據庫冗餘越小。 目前關係數據庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。滿足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步滿足更多規範要求的稱爲第二範式（2NF），其餘範式以次類推。一般說來，數據庫只需滿足第三範式(3NF）就行了。 各類範式編輯 第一範式（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的基礎上，任何非主屬性不得傳遞依賴於主屬性。
個人的理解：
第一範式：表裏面的每個屬性都是具有獨立性即獨立的，不能再分爲！
例如下表所示：
這個表所示的是一個購物信息這裏應爲在賣家信息裏面還有兩個屬性可以分開，所以不滿足第一範式，應該分爲下圖所示就滿足第一範式了：
第二範式：如果一個表中存在（在滿足第一範式的情況下）一個主鍵對應多個其他屬性的情況，即一對多的存在，那麼我們就應該把主鍵和屬性分離出來成多個表，分離出來的兩個表是一對多的關係；繼續沿用上面的例子來說；
例：我們可以吧訂單號和買家歸爲一個表，訂單號和賣家歸爲一個表，這樣這兩個表就成了一對多的關係了，這樣看起來條理更清晰，減少冗餘；
這樣一來我們就能減少很多的數據庫的空間，便於查詢沒節約資源
第三範式：即使在滿足第一和第二範式的前提下，我們的數據不會出現冗餘或是數據重複的情況，這樣就滿足了第三範式，繼續我們上面的例子；
例：我們在賣家的表中還可以繼續的分，確保不會出現數據重複的情況；
範式三，簡而言之就是把表忘你認爲最合適的最細化去分，三大範式只是一般設計數據庫的基本理念，可以建立冗餘較小、結構合理的數據庫。如果有特殊情況，當然要特殊對待，數據庫設計最重要的是看需求跟性能，需求>性能>表結構。所以不能一味的去追求範式建立數據庫