數據庫知識複習
範式：英文名稱是 Normal Form，它是英國人 E.F.Codd（關係數據庫的老祖宗）在上個世紀70年代提出關係數據庫模型後總結出來的，範式是關係數據庫理論的基礎，也是我們在設計數據庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種範式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三個範式，即：第一範式（1NF），第二範式（2NF），第三範式（3NF）。下面就簡單介紹下這三個範式。
第一範式（ 1NF ）： 字段具有 原子性 , 不可再分 。所有關係型數據庫系統都滿足第一範式）數據庫表中的字段都是單一屬性的，不可再分。例如，姓名字段，其中的姓和名必須作爲一個整體，無法區分哪部分是姓，哪部分是名，如果要區分出姓和名，必須設計成兩個獨立的字段。考慮這樣一個表：【聯繫人】（姓名，性別，電話）
如果在實際場景中，一個聯繫人有家庭電話和公司電話，那麼這種表結構設計就沒有達到 1NF。要符合 1NF 我們只需把列（電話）拆分，即：【聯繫人】（姓名，性別，家庭電話，公司電話）。
第二範式（ 2NF ）： 第二範式（ 2NF ）是在 第一範式（ 1NF ）的基礎上 建立起來的，即滿足第二範式（ 2NF ）必須先滿足第一範式（ 1NF ）。要求 數據庫表中的每個實例或行必須可以被惟一地區分 。通常需要爲表加上一個列，以存儲各個實例的惟一標識。這個惟一屬性列被稱爲 主關鍵字或主鍵 。
第二範式（ 2NF ）要求 實體的屬性完全依賴於主關鍵字 。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關係。爲實現區分通常需要爲表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是非主屬性非部分依賴於主關鍵字。考慮一個訂單明細表：【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多次重複的情況。
第三範式的要求如下： 滿足第三範式（ 3NF ） 必須先滿足第二範式（ 2NF ） 。簡而言之，第三範式（ 3NF ）要求一個數據庫表中 不包含 已在其它表中 已包含的非主關鍵字信息 。所以第三範式具有如下特徵：
1 ，每一列只有一個值
2 ，每一行都能區分。
3 ，每一個表都 不包含其他表已經包含 的非主關鍵字信息。
例如，帖子表中只能出現發帖人的 id ，而不能出現發帖人的 id ，還同時出現發帖人姓名，否則，只要出現同一發帖人 id 的所有記錄，它們中的姓名部分都必須嚴格保持一致，這就是 數據冗餘 。
考慮一個訂單表【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：非主鍵列是直接依賴於主鍵，還是直接依賴於非主鍵列。