2、第二範式2NF數據庫
定義:數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴,即符合第二範式。函數
簡單的說就是不要字段冗餘優化
《注:什麼是函數依賴,詳見百度百科(http://baike.baidu.com/view/40008.htm)。spa
若是一個表中某一個字段A的值是由另一個字段或一組字段B的值來肯定的,就稱爲A函數依賴於B。》設計
2NF能夠減小插入異常,刪除異常和修改異常。htm
簡單的說,一方面,第二範式確定要知足第一範式,不然就沒有必要談第二範式。blog
另外一方面,當某張表中的非主鍵信息不是由整個主鍵函數來決定時,即存在依賴於該表中不是主鍵的部分或者依賴於主鍵一部分的部分時,一般會違反2NF。ci
咱們再來看上面的知足1NF的表1-2get
CardNotable |
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 |
----------------------------------------
第二範式
每一行的數據只能與其中一列相關,即一行數據只作一件事。只要數據列中出現數據重複,就要把表拆分開來。
一我的同時訂幾個房間,就會出來一個訂單號多條數據,這樣子聯繫人都是重複的,就會形成數據冗餘。咱們應該把他拆開來。
這樣便實現啦一條數據作一件事,不摻雜複雜的關係邏輯。同時對錶數據的更新維護也更易操做。
----------------------------------------
2.第二範式(確保表中的每列都和主鍵相關)
第二範式在第一範式的基礎之上更進一層。第二範式須要確保數據庫表中的每一列都和主鍵相關,而不能只與主鍵的某一部分相關(主要針對聯合主鍵而言)。也就是說在一個數據庫表中,一個表中只能保存一種數據,不能夠把多種數據保存在同一張數據庫表中。
好比要設計一個訂單信息表,由於訂單中可能會有多種商品,因此要將訂單編號和商品編號做爲數據庫表的聯合主鍵,以下表所示。
訂單信息表
這樣就產生一個問題:這個表中是以訂單編號和商品編號做爲聯合主鍵。這樣在該表中商品名稱、單位、商品價格等信息不與該表的主鍵相關,而僅僅是與商品編號相關。因此在這裏違反了第二範式的設計原則。
而若是把這個訂單信息表進行拆分,把商品信息分離到另外一個表中,把訂單項目表也分離到另外一個表中,就很是完美了。以下所示。
這樣設計,在很大程度上減少了數據庫的冗餘。若是要獲取訂單的商品信息,使用商品編號到商品信息表中查詢便可。