Oracle資料庫設計第三範式

標籤：

一、資料庫設計範式及其意義和不足

資料庫的設計範式是資料庫設計所需要滿足的規範，資料庫的正常化是最佳化表的結構和最佳化把資料群組織到表中的方式，這樣使資料更明確，更簡潔。實踐中，通常把一個資料庫分成兩個或多個表並定義表之間的關係以做到資料隔離，添加、刪除和修改某個欄位只需要在一個表中進行，接著可以通過定義的關係傳遞到資料庫中剩餘的表中（和分層思想的意義所在很相似）。這樣我們可以消除很多錯誤或垃圾資料出現的機會並減輕更新資訊所必要的工作量。

 

目前，主要有六種範式：第一範式、第二範式、第三範式、BC範式、第四範式和第五範式。滿足最低要求的叫第一範式，簡稱1NF。在第一範式基礎上進一步滿足一些要求的為第二範式，簡稱2NF。其餘依此類推

 

事物往往具有多面性，設計範式也會帶來一定的麻煩：操作困難，因為需要聯絡多個表才能得到所需要資料，而且範式越高效能就會越差。所以使用多高的範式需要權衡利弊，一般在項目中，使用到第三範式也就足夠了，效能好而且方便管理資料。

 

二、下面我們來舉例介紹一下資料庫設計三範式

說明：執行個體採用《學校機房收費系統》的“學生資訊表”，“學生上下機記錄表”的部分欄位

 

1、第一範式1NF

定義：資料庫表中的欄位都是單一屬性的，不可再分。

簡單的說，每一個屬性都是原子項，不可分割。

 

1NF是關係模式應具備的最起碼的條件，如果資料庫設計不能滿足第一範式，就不稱為關係型資料庫。也就是說，只要是關係型資料庫，就一定滿足第一範式。

 

我們先來看一張不符合1NF的表1-1

CardNo	StudentNo	StudentName	Sex	Department	CardCash	UserID	UserLevel	Time
001	021101	小明	男	教育學院，心理系，1班	100	Operator	操作員	2011/10/03，09：00

 

之所以說這張表不符合1NF，是因為Department和Time欄位可以再分，所以應該更改為表1-2：

CardNo	StudentNo	StudentName	Sex	Academy	Major	class	CardCash	UserID	UserLevel	Date	Time
001	021101	小明	男	教育學院	心理系	1	100	Operator	操作員	2011/10/03	09:00

 

2、第二範式2NF

定義：資料庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴，即符合第二範式。

 

《註：什麼是函數依賴,詳見百度百科（http://baike.baidu.com/view/40008.htm）。

如果一個表中某一個欄位A的值是由另外一個欄位或一組欄位B的值來確定的，就稱為A函數依賴於B。》

2NF可以減少插入異常，刪除異常和修改異常。

 

簡單的說，一方面，第二範式肯定要滿足第一範式，否則就沒有必要談第二範式。

另一方面，當某張表中的非主鍵資訊不是由整個主鍵函數來決定時，即存在依賴於該表中不是主鍵的部分或者依賴於主鍵一部分的部分時，通常會違反2NF。

 

我們再來看上面的滿足1NF的表1-2

CardNo	StudentNo	StudentName	Sex	Academy	Major	class	CardCash	UserID	UserLevel	Date	Time
001	021101	小明	男	教育學院	心理系	1	100	Operator	操作員	2011/10/03	09:00

 

我們看到，在這張表中，通過CardNo和StudentNo就可以確定StudentName，Sex，Academy，Major，class，CardCash，UserID，Date，Time。所以可以把CardNo和StudentNo的組合作為主鍵。

但是，我們發現CardCash並不完全依賴於CardNo和StudentNo，僅僅通過CardNo就可以確定CardCash，因為一張卡，一定會有卡內金額。這就造成了部分依賴。出現這種情況，就不滿足第二範式。

修改為：

 

 

我們再來看另一個例子，學生上下機記錄表，會更明顯些。表2-1

CardNo

StudentNo

StudentName

Sex

Department

Major

class

OnDate

OnTime

OffDate

OffTime

ConsumeTime

ConsumeMoney

001

0211

小明

男

教育學院

心理系

1

2011/10/14

09:00

2011/10/14

10:00

1

2

 

我們看到，在這張表中，StudentName,Sex,Department，Major，class都是直接依賴於StudentNo，而不依賴與表中的其他欄位，這樣的設計也不符合2NF非主鍵資訊不是由整個主鍵函數來決定時。

 

我們可以把1-2和2-1最佳化為：

3-1

StudentNo	CardNo	UserID	UserLevel	Date	Time
021101	001	Operator	操作員	2011/10/03	09:00

3-2

CardNo	CardCash
001	98

3-3

CardNo	OnDate	OnTime	OffDate	OffTime	ConsumeTime	ConsumeMoney
001	2011/10/14	09:00	2011/10/14	10:00	1	2

3-4

StudentNo	StudentName	Sex	Academy	Major	class
021101	小明	男	教育學院	心理系	1

 

 

3、第三範式3NF

定義：在第二範式的基礎上，資料表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴則符合3NF。

 

我們來看上例中最佳化後的表3-1

StudentNo	CardNo	UserID	UserLevel	Date	Time
021101	001	Operator	操作員	2011/10/03	09:00

 

在表中，一個UserID能確定一個UserLevel。這樣，UserID依賴於StudentNo和CardNo，而UserLevel又依賴於UserID，這就導致了傳遞依賴，3NF就是消除這種依賴。

 

我們把3-1進行最佳化得到：

4-1

StudentNo	CardNo	UserID	Date	Time
021101	001	Operator	2011/10/03	09:00

4-2

UserID	UserLevel
Operator	操作員

 

 

我們看到，第三範式規則尋找以消除沒有直接依賴於第一範式和第二範式形成的表的主鍵的屬性。我們為沒有與表的主鍵關聯的所有資訊建立了一張新表。每張新表儲存了來自源表的資訊和它們所依賴的主鍵。

 

三、總結

資料庫設計正常化能讓我們更好地適應變化，使你能夠改變商務規則、需求和資料而不需要重新構造整個系統。

 

 

 

 

 

 

Oracle資料庫設計第三範式