數據庫（第一范式，第二范式，第三范式）
范式：英文名稱是 Normal Form，它是英國人 E.F.Codd（關系數據庫的老祖宗）在上個世紀70年代提出關系數據庫模型后總結出來的，范式是關系數據庫理論的基礎，也是我們在設計數據庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三個范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。
下面就簡單介紹下這三個范式。
第一范式（1NF）
強調的是列的原子性，即列不能夠再分成其他幾列。
考慮這樣一個表：【聯系人】（姓名，性別，電話）
如果在實際場景中，一個聯系人有家庭電話和公司電話，那么這種表結構設計就沒有達到 1NF。要符合 1NF 我們只需把列（電話）拆分，即：【聯系人】（姓名，性別，家庭電話，公司電話）。1NF 很好辨別，但是 2NF 和 3NF 就容易搞混淆。
說明：在任何一個關系數據庫中，第一范式（1NF）是對關系模式的設計基本要求，一般設計中都必須滿足第一范式（1NF）。不過有些關系模型中突破了1NF的限制，這種稱為非1NF的關系模型。換句話說，是否必須滿足1NF的最低要求，主要依賴於所使用的關系模型。
第二范式（2NF）
首先是 1NF，另外包含兩部分內容，一是表必須有一個主鍵；二是沒有包含在主鍵中的列必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。
考慮一個訂單明細表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。
因為我們知道在一個訂單中可以訂購多種產品，所以單單一個 OrderID 是不足以成為主鍵的，主鍵應該是（OrderID，ProductID）。顯而易見 Discount（折扣），Quantity（數量）完全依賴（取決）於主鍵（OderID，ProductID），而 UnitPrice，ProductName 只依賴於 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的設計容易產生冗余數據。
可以把【OrderDetail】表拆分為【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）來消除原訂單表中UnitPrice，ProductName多次重復的情況。
第二范式（2NF）要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二范式就是在第一范式的基礎上屬性完全依賴於主鍵。
第三范式（3NF）
在1NF基礎上，任何非主屬性不依賴於其它非主屬性[在2NF基礎上消除傳遞依賴]。
第三范式（3NF）是第二范式（2NF）的一個子集，即滿足第三范式（3NF）必須滿足第二范式（2NF）。
首先是 2NF，另外非主鍵列必須直接依賴於主鍵，不能存在傳遞依賴。即不能存在：非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。 考慮一個訂單表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主鍵是（OrderID）。
其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主鍵列都完全依賴於主鍵（OrderID），所以符合 2NF。不過問題是 CustomerName，CustomerAddr，CustomerCity 直接依賴的是 CustomerID（非主鍵列），而不是直接依賴於主鍵，它是通過傳遞才依賴於主鍵，所以不符合 3NF。
通過拆分【Order】為【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）從而達到 3NF。
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，區分它們的關鍵點在於，2NF：非主鍵列是否完全依賴於主鍵，還是依賴於主鍵的一部分；3NF：非主鍵列是直接依賴於主鍵，還是直接依賴於非主鍵列。