数据库理论 范式

第一范式（1NF）：

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

例：

挑食列表（ 不符合1NF）

人	不喜歡的食物
Jim	Liver, Goat's cheese
Alice	Broccoli
Norman	Pheasant, Liver, Peas

挑食列表（符合）

人	不喜歡的食物
Jim	Liver
Jim	Goat's cheese
Alice	Broccoli
Norman	Pheasant
Norman	Liver
Norman	Peas

第二范式（2NF）：

1、符合第一范式

  2、消除部分依赖

例：

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

元件來源（ 符合1NF，不符合2NF）

元件 ID (主鍵)	供應商 ID (主鍵)	供應商名稱	價格	供應商住址
65	2	Stylized Parts	59.99	VA
73	2	Stylized Parts	20.00	VA
65	1	ACME Industries	69.99	CA

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

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

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

拆分后：

供應商（符合2NF）

供應商 ID (主鍵)	名稱	住址
1	ACME Industries	CA
2	Stylized Parts	VA

元件來源（符合2NF）

元件 ID (主鍵)	供應商 ID (主鍵)	價格
65	2	59.99
73	2	20.00
65	1	69.99

第三范式（3NF）：

1、符合第二范式

2、消除传递依赖

例：

訂單 (Order)

訂單編號 (Order Number) (主鍵)	客戶名稱 (Customer Name)	單價 (Unit Price)	數量 (Quantity)	小計 (Total)
1000	David	$35.00	3	$105.00
1001	Jim	$25.00	2	$50.00
1002	Bob	$25.00	3	$75.00

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

訂單 (Order)

訂單編號 (Order Number) (主鍵)	客戶名稱 (Customer Name)	單價 (Unit Price)	數量 (Quantity)
1000	David	$35.00	3
1001	Jim	$25.00	2
1002	Bob	$25.00	3

[编辑]

BC范式（BCNF）：

1、符合第三范式

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

Property_id#(主键)	County_name	Lot#	Area

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

Property_id#(主键)	County_name	Lot#

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