資料庫原理之第一正規化、第二正規化、第三正規化

tian1982tian發表於2011-04-30

      資料庫原理之第一正規化、第二正規化、第三正規化

正規化:英文名稱是 Normal Form,它是英國人 E.F.Codd(關聯式資料庫的老祖宗)在上個世紀70年代提出關聯式資料庫模型後總結出來的,正規化是關聯式資料庫理論的基礎,也是我們在設計資料庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種正規化,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。通常所用到的只是前三個正規化,即:第一正規化(1NF),第二正規化(2NF),第三正規化(3NF)。下面就簡單介紹下這三個正規化。
 
◆ 第一正規化(1NF):
強調的是列的原子性,即列不能夠再分成其他幾列。
考慮這樣一個表:
【聯絡人】(姓名,性別,電話)
如果在實際場景中,一個聯絡人有家庭電話和公司電話,那麼這種表結構設計就沒有達到 1NF。要符合 1NF 我們只需把列(電話)拆分,即:
【聯絡人】(姓名,性別,家庭電話,公司電話,...電話)。
1NF 很好辨別,但是 2NF 和 3NF 就容易搞混淆。

◆ 第二正規化(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多次重複的情況。

◆ 第三正規化(3NF):
首先是 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:非主鍵列是直接依賴於主鍵,還是直接依賴於非主鍵列。
原文:http://space.itpub.net/25264937/viewspace-692207#xspace-tracks

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/16400082/viewspace-694148/,如需轉載,請註明出處,否則將追究法律責任。

相關文章