数据库理论 范式

第一范式（1NF）：

每一条记录的每条属性都只能有一个值

例：

挑食列表（不符合1NF）人不喜歡的食物JimLiver, Goat's cheeseAliceBroccoliNormanPheasant, Liver, Peas挑食列表（符合）人不喜歡的食物JimLiverJimGoat's cheeseAliceBroccoliNormanPheasantNormanLiverNormanPeas

第二范式（2NF）：

1、符合第一范式

  2、消除部分依赖

例：

有一個資料表記錄了設備元件的資訊，如下所示：

元件來源（符合1NF，不符合2NF）元件 ID (主鍵)供應商 ID (主鍵)供應商名稱價格供應商住址652Stylized Parts59.99VA732Stylized Parts20.00VA651ACME Industries69.99CA

這個資料表的每個值都是單一值，所以它符合第一正規化。因為同一個元件有可能由不同的供應商提供，所以得把元件 ID 和供應商 ID 合在一起組成一個主鍵。

主鍵和價格之間的關係很正確：同一個元件在不同供應商有可能會有不同的報價，所以價格確實和主鍵完全相關(完全依赖)。

另一方面，供應商的名稱和住址就只和供應商 ID 有關(部分依赖)，這不符合第二正規化的原則。

拆分后：

供應商（符合2NF）供應商 ID (主鍵)名稱住址1ACME IndustriesCA2Stylized PartsVA元件來源（符合2NF）元件 ID (主鍵)供應商 ID (主鍵)價格65259.9973220.0065169.99

第三范式（3NF）：

1、符合第二范式

2、消除传递依赖

例：

訂單 (Order)訂單編號 (Order Number)
(主鍵)客戶名稱 (Customer Name)單價 (Unit Price)數量 (Quantity)小計 (Total)1000David$35.003$105.001001Jim$25.002$50.001002Bob$25.003$75.00

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

訂單 (Order)訂單編號 (Order Number)
(主鍵)客戶名稱 (Customer Name)單價 (Unit Price)數量 (Quantity)1000David$35.0031001Jim$25.0021002Bob$25.003

[编辑]

BC范式（BCNF）：

1、符合第三范式

2、第三范式允许A是主属性（第三范式中不存在非主属性被另一个非主属性决定），而在BCNF中，任何属性（包括非主属性和主属性）都不能被非主属性所决定。

Property_id#(主键)County_nameLot#Area

其中依赖关系如下： Property_id#->{County_name,Lot#,Area}; {County_name,Lot#}->{Property_id#,Area}; Area->County_name; 很明显最后一个依赖违反了BC范式的要求，Area不是关系模式R的主键，而依赖于它的County_name是能够决定其他属性的主属性。故应当规范化为：

Property_id#(主键)County_nameLot#

Area(主键)County_name

参考文献：

http://zh.wikipedia.org/wiki/%E6%95%B0%E6%8D%AE%E5%BA%93%E8%A7%84%E8%8C%83%E5%8C%96