热门问题
时间线
聊天
视角

第三正規化

要求所有非主鍵都只和候選鍵有關聯的資料庫正規化形式 来自维基百科,自由的百科全书

Remove ads

第三正規化(3NF)是資料庫正規化所使用的正規形式,要求所有非主鍵屬性都只和候選鍵有相關性,也就是說非主鍵屬性之間應該是獨立無關的。

如果再對第三正規化做進一步加強就成了BC正規化,強調的重點在於「資料間的關係是奠基在主鍵上、以整個主鍵為考量、而且除了主鍵之外不考慮其他因素」。

正規定義

令:

  • 表一個關係;
  • 表維持 所需的一組函數相依
  • 屬性的子集合
  • 的一個屬性

最早由埃德加·科德在1971年給出的第三正規化定義為[1]

  • 關係R(表)滿足第二正規化 (2NF);
  • R的每個非鍵屬性是R的每個候選鍵的非傳遞相依。

Carlo Zaniolo於1982年給出的一個等價定義為[2][3]

如果對於 這種型式的函數相依而言,下列敘述任一為真的話,則可以稱 符合第三正規化:

  • ;也就是說 明顯函數相依
  • 超鍵
  • 候選鍵的一部份

任何一個具有部份相依性或是轉移相依性的關係都違反了第三正規化。

Remove ads

範例

以下面這個定義機械元件的關係為例:

更多資訊 元件編號 (主鍵), 製造商名稱 ...

本例中製造商地址很明顯地不該被列在這個關係裡面,因為和元件本身比起來,製造商地址應該和製造商比較有關係;正確的做法應該是把獨立出新的資料表:

更多資訊 製造商名稱 (主鍵), 製造商地址 ...

然後把原本的資料表改成這樣:

更多資訊 元件編號 (主鍵), 製造商名稱 ...

先前那個資料表的問題在於每提到一次製造商名稱就要多存一次它的地址,而這就不符合第三正規化的原則。

下面提供了另一個例子:

更多資訊 訂單編號(Order Number) (主鍵), 客戶名稱 (Customer Name) ...

在本例中,非主鍵欄位完全相依於主鍵訂單編號,也就是說唯一的訂單編號能導出唯一非主鍵欄位值,符合第二正規化。第三正規化要求非主鍵欄位之間不能有相依關係,顯然本例中小計相依於非主鍵欄位「單價」和「數量」,不符合第三正規化。小計不應該放在這個資料表裡面,只要把單價乘上數量就可以得到小計了;如果想要符合第三正規化的話,就把小計拿掉 (不過在做查詢時, SELECT Order.Total FROM Order 需改成 SELECT UnitPrice * Quantity FROM Order )。

更多資訊 訂單編號(Order Number) (主鍵), 客戶名稱 (Customer Name) ...
Remove ads

參考文獻

外部連結

Loading related searches...

Wikiwand - on

Seamless Wikipedia browsing. On steroids.

Remove ads