http://blog.csdn.net/famousdt/article/details/6921622數據庫
範式:英文名稱是 Normal Form,它是英國人 E.F.Codd(關係數據庫的老祖宗)在上個世紀70年代提出關係數據庫模型後總結出來的,範式是關係數據庫理論的基礎,也是咱們在設計數據庫結構過程當中所要遵循的規則和指導方法。函數
目前有跡可尋的共有8種範式,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。spa
一般所用到的只是前三個範式,即:第一範式(1NF),第二範式(2NF),第三範式(3NF)。下面就簡單介紹下這三個範式。.net
◆ 第一範式(1NF):強調的是列的原子性,即列不可以再分紅其餘幾列。 設計
考慮這樣一個表:【聯繫人】(姓名,性別,電話)
若是在實際場景中,一個聯繫人有家庭電話和公司電話,那麼這種表結構設計就沒有達到 1NF。要符合 1NF 咱們只需把列(電話)拆分,即:【聯繫人】(姓名,性別,家庭電話,公司電話)。1NF 很好辨別,可是 2NF 和 3NF 就容易搞混淆。 orm
◆ 第二範式(2NF):數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴(部分函數依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的狀況),也即全部非關鍵字段都徹底依賴於任意一組候選關鍵字。blog
首先是 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屢次重複的狀況。 產品
假定選課關係表爲SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分),關鍵字爲組合關鍵字(學號, 課程名稱),由於存在以下決定關係:(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
這個數據庫表不知足第二範式,由於存在以下決定關係:(課程名稱) → (學分) (學號) → (姓名, 年齡)
即存在組合關鍵字中的字段決定非關鍵字的狀況。
因爲不符合2NF,這個選課關係表會存在以下問題:
(1) 數據冗餘:
同一門課程由n個學生選修,"學分"就重複n-1次;同一個學生選修了m門課程,姓名和年齡就重複了m-1次。
(2) 更新異常:
若調整了某門課程的學分,數據表中全部行的"學分"值都要更新,不然會出現同一門課程學分不一樣的狀況。
(3) 插入異常:
假設要開設一門新的課程,暫時尚未人選修。這樣,因爲尚未"學號"關鍵字,課程名稱和學分也沒法記錄入數據庫。
(4) 刪除異常:
假設一批學生已經完成課程的選修,這些選修記錄就應該從數據庫表中刪除。可是,與此同時,課程名稱和學分信息也被刪除了。很顯然,這也會致使插入異常。
把選課關係表SelectCourse改成以下三個表:
學生:Student(學號, 姓名, 年齡);課程:Course(課程名稱, 學分);選課關係:SelectCourse(學號, 課程名稱, 成績)。
這樣的數據庫表是符合第二範式的, 消除了數據冗餘、更新異常、插入異常和刪除異常。
另外,全部單關鍵字的數據庫表都符合第二範式,由於不可能存在組合關鍵字。it
◆ 第三範式(3NF):在第二範式的基礎上,數據表中若是不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴,則符合第三範式。(非主鍵列必須直接依賴於主鍵,不能存在傳遞依賴。)即不能存在:非主鍵列 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:非主鍵列是直接依賴於主鍵,仍是直接依賴於非主鍵列。
◆ BCNF(鮑依斯-科得範式):設關係模式R<U,F>∈1NF,若是對於R的每一個函數依賴X→Y,若Y不屬於X,則X必含有候選碼,那麼R∈BCNF。
知足BCNF的條件:
假設倉庫管理關係表爲StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量),且有一個管理員只在一個倉庫工做;一個倉庫能夠存儲多種物品。
這個數據庫表中存在以下決定關係:(倉庫ID, 存儲物品ID) →(管理員ID, 數量) (管理員ID, 存儲物品ID) → (倉庫ID, 數量)
因此,(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字,表中的惟一非關鍵字段爲數量,它是符合第三範式的。
可是,因爲存在以下決定關係:(倉庫ID) → (管理員ID) (管理員ID) → (倉庫ID)
即存在關鍵字段決定關鍵字段的狀況,因此其不符合BCNF範式。
它會出現以下異常情況:
(1) 刪除異常:
當倉庫被清空後,全部"存儲物品ID"和"數量"信息被刪除的同時,"倉庫ID"和"管理員ID"信息也被刪除了。
(2) 插入異常:
當倉庫沒有存儲任何物品時,沒法給倉庫分配管理員。
(3) 更新異常:
若是倉庫換了管理員,則表中全部行的管理員ID都要修改。
把倉庫管理關係表分解爲二個關係表:
倉庫管理:StorehouseManage(倉庫ID, 管理員ID);倉庫:Storehouse(倉庫ID, 存儲物品ID, 數量)。
這樣的數據庫表是符合BCNF範式的,消除了刪除異常、插入異常和更新異常。
◆ 第四範式(4NF):
設R(U)是一個屬性集合U上的一個關係模式,X, Y, 和Z是U的子集,而且Z=U-X-Y,多值依賴X->->Y成立當且僅當對R的任一個關係r,r在(X,Z)上的每一個值對應一組Y的值,這組值僅僅決定於X值而與Z值無關。
若X->->Y,而Z=空集,則稱X->->Y爲平凡的多值依賴。不然,稱X->->Y爲非平凡的多值依賴。
能夠看出,若是把上面的一組改成一個,那麼多值依賴就變成了函數依賴。固然一個值組成的組也是組,因此說,函數依賴是多值依賴的特殊狀況。
例:
以下表:
課程C 教師T 參考書B
數學 鄧軍 數學分析
數學 鄧軍 高等代數
數學 鄧軍 微分方程
表中,U = C+T+B,(C,T)肯定一組B,可是這組B其實與T無關,僅由C肯定,因此(C,T)->->B。又由於T不是空集,因此(C,T)->->B爲非平凡多值依賴。
要想消除多值依賴,能夠分解爲:(C,T), (C,B)
表1:
課程C 教師T
數學 鄧軍
表2:
課程C 參考書B
數學 數學分析
數學 高等代數
數學 微分方程