Database一些概念

[b]數據庫範式：[/b]
1NF：如果關係R 中所有屬性的值域都是單純域，那麼關係模式R是第一範式的
那麼符合第一模式的特點就有 [color=red]有主關鍵字且不能爲空,不能重複；字段是atomic不可以再分[/color]
例如：
StudyNo | Name | Sex | Contact
20040901 john Male Email:[email protected],phone:222456
20040901 mary famale email:[email protected] phone:123455
以上的表就不符合，第一範式：主鍵重複(實際中數據庫不允許重複的)，而且Contact字段可以再分,所以變更爲正確的是
StudyNo | Name | Sex | Email | Phone
20040901 john Male [email protected] 222456
20040902 mary famale [email protected] 123455
很顯然，在當前的database中，不可能做出不符合1NF的數據庫，因爲這些DBMS不允許你把數據庫表的一列再分成二列或多列。

2NF：如果關係模式R是1NF的，而且關係中每一個非主屬性不部分依賴於主鍵，稱R是2NF的。所以第二範式的主要任務就是 [color=red]滿足1NF的前提下，消除部分函數依賴[/color]。
StudyNo | Name | Sex | Email | Phone | ClassNo| ClassAddress
01 john Male [email protected] 222456 200401 A樓2
01 mary famale [email protected] 123455 200402 A樓3
這個表完全滿足於1NF,主鍵由StudyNo和ClassNo組成，這樣才能定位到指定行
但是,存在決定關係：
ClassNo --> ClassAddress
StudyNo --> Name Sex Email Phone
即存在組合關鍵字中的字段決定非關鍵字的情況.由於不符合2NF，表會存在如下問題：
數據冗餘：同一門課程由n個學生選修，ClassAddress就重複n-1次；同一個學生選修了m門課程，Name Sex Email Phone也重複了m-1次。
更新異常：若調整了class的address，數據表中所有行ClassAddress都要更新，否則會出現同一門課程address不同的情況。
插入異常：假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有StudyNo關鍵字，ClassNo和ClassAddress也無法記錄入數據庫。
刪除異常：假設一批學生已經完成課程的選修，這些選修記錄就應該從數據庫表中刪除。但是，與此同時，ClassNo和ClassAddress也被刪除了.
表一
StudyNo | Name | Sex | Email | Phone | ClassNo
01 john Male [email protected] 222456 200401
01 mary famale [email protected] 123455 200402
表二
ClassNo | ClassAddress
200401 A樓2
200402 A樓3
很明顯，如果是單主鍵的表，也肯定是符合2NF的。

3NF：滿足2NF的前提下，消除傳遞依賴。所謂傳遞依賴，指的是如果存在"A → B → C"的決定關係，則C傳遞函數依賴於A。因此，滿足3NF的數據庫表應該不存在如下依賴關係：
關鍵字段 → 非關鍵字段x → 非關鍵字段y
例:
StudyNo | Name | Sex | Email | bounsLevel | bouns
20040901 john Male [email protected] 優秀 $1000
20040902 mary famale [email protected] 良 $600
這個完全滿足了2NF,但是bounsLevel和bouns存在傳遞依賴.StudyNo --> bounsLevel --> bouns.即存在非關鍵字段bounsLevel\bouns對關鍵字段StudyNo的傳遞函數依賴.
更改爲：
表一
StudyNo | Name | Sex | Email | bouunsNo
20040901 john Male [email protected] 1
20040902 mary famale [email protected] 2
表二
bounsNo | bounsLevel | bouns
1 優秀 $1000
2 良 $600
這裏我比較喜歡用bounsNo作爲主鍵，
基於兩個原因
1）不要用字符作爲主鍵。可能有人說：如果我的等級一開始就用數值就代替呢？
2）但是如果等級名稱更改了，不叫 1，2 ，3或優、良，這樣就可以方便更改，所以我一般優先使用與業務無關的字段作爲關鍵字。
一般滿足前三個範式就可以避免數據冗餘。

BCNF:鮑依斯-科得範式.在3NF的基礎上，數據庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數依賴則符合BCNF.
例：配件管理關係模式 WPE（WNO，PNO，ENO，QNT）分別表倉庫號，配件號，職工號，數量。有以下條件
a.一個倉庫有多個職工。
b.一個職工僅在一個倉庫工作。
c.每個倉庫裏一種型號的配件由專人負責，但一個人可以管理幾種配件。
d.同一種型號的配件可以分放在幾個倉庫中。
分析：由以上得 PNO 不能確定QNT，由組合屬性（WNO，PNO）來決定，存在函數依賴（WNO，PNO） -> ENO。由於每個倉庫裏的一種配件由專人負責，而一個人可以管理幾種配件，所以有組合屬性（WNO，PNO）才能確定負責人，有（WNO，PNO）-> ENO。因爲 一個職工僅在一個倉庫工作，有ENO -> WNO。由於每個倉庫裏的一種配件由專人負責，而一個職工僅在一個倉庫工作，有 （ENO，PNO）-> QNT。
找一下候選關鍵字，因爲（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此 （WNO，PNO）可以決定整個元組，是一個候選關鍵字。根據ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能決定整個元組，爲另一個候選關鍵字。屬性ENO，WNO，PNO 均爲主屬性，只有一個非主屬性QNT。它對任何一個候選關鍵字都是完全函數依賴的，並且是直接依賴，所以該關係模式是3NF。
分析一下主屬性。因爲ENO->WNO，主屬性ENO是WNO的決定因素，但是它本身不是關鍵字，只是組合關鍵字的一部分。這就造成主屬性WNO對另外一個候選關鍵字（ENO，PNO）的部 分依賴，因爲（ENO，PNO）-> ENO但反過來不成立，而P->WNO，故（ENO，PNO）-> WNO 也是傳遞依賴。
雖然沒有非主屬性對候選關鍵遼的傳遞依賴，但存在主屬性對候選關鍵字的傳遞依賴，同樣也會帶來麻煩。如一個新職工分配到倉庫工作，但暫時處於實習階段，沒有獨立負責對某些配件的管理任務。由於缺少關鍵字的一部分PNO而無法插入到該關係中去。又如某個人改成不管配件了去負責安全，則在刪除配件的同時該職工也會被刪除。
解決辦法：分成管理EP（ENO，PNO，QNT），關鍵字是（ENO，PNO）工作EW（ENO，WNO）其關鍵字是ENO
缺點：分解後函數依賴的保持性較差。如此例中，由於分解,函數依賴（WNO，PNO）-> ENO 丟失了, 因而對原來的語義有所破壞。沒有體現出每個倉庫裏一種部件由專人負責。有可能出現 一部件由兩個人或兩個以上的人來同時管理。因此，分解之後的關係模式降低了部分完整性約束。

4NF：滿足3NF的前提下，消除多值依賴
product | agent | factory
Car A1 F1
Bus A1 F2
Car A2 F2
在這裏，Car的定位，必須由 agent 和 Factory才能得到（所以主鍵由agent和factory組成）,可以通過 product依賴了agent和factory兩個屬性
所以正確的是
表1 表2：
product | agent factory | product
Car A1 F1 Car
Bus A1 F2 Car
Car A2 F2 Bus

5NF：如果關係模式R中的每一個連接依賴, 都是由R的候選鍵所蘊含, 稱R是第五範式的
看到定義，就知道是要消除連接依賴,並且必須保證數據完整
例子
A | B | C
a1 b1 c1
a2 b1 c2
a1 b2 c1
a2 b2 c2
如果要定位到特定行，必須三個屬性都爲關鍵字。
所以關係要變爲 三個關係，分別是A 和B,B和C ，C和A
如下：
表1 表2 表3
A | B B | C C | A
a1 b1 b1 c1 c1 a1
a1 b2 b1 c2 c1 a2

[b]連接：[/b]
假設存在2個表：
一個book的基本信息表:
[img]http://dl.iteye.com/upload/attachment/228706/a1cc8d2d-0111-313e-81af-cb6df0b9741d.png[/img]
一個租書人的信息表：
[img]http://dl.iteye.com/upload/attachment/228690/8e4dcaec-ba21-39dd-9760-880f31c51297.png[/img]

1.right join/right outer join
[img]http://dl.iteye.com/upload/attachment/228708/d52deba5-0d24-34c4-9705-36c5c563b0bb.png[/img]
我們以左邊book表爲準，則tenant中的記錄只有當其bookID在book中存在時纔會顯示出來，tenant中的BOOKID 16 17在book表沒有對應記錄，所以顯示爲NULL.
[img]http://dl.iteye.com/upload/attachment/228710/423d9e72-59ba-327b-b96d-7d6a182760c1.png[/img]

2.right join/right outer join
[img]http://dl.iteye.com/upload/attachment/228712/57120bb5-dda1-3620-81fc-1bde5ee8107e.png[/img]
我們以右邊tenant表爲準，則左表book中的記錄只有當其ID在右邊tenant中存在時纔會顯示出來，左邊中ID爲5.6因爲在tenant中沒有相應記錄，所以顯示爲NULL.
[img]http://dl.iteye.com/upload/attachment/228716/11279e3b-b6a8-3dd2-a1ab-6a1a23a9a9a2.png[/img]

3.inner join/join;它爲返回同時存在於book 和tenant中的記錄.
[img]http://dl.iteye.com/upload/attachment/228718/6fd91cb9-62dc-302e-8337-8a0f4170127b.png[/img]
[img]http://dl.iteye.com/upload/attachment/228720/92e07464-7874-39e6-a4ed-45684fc6795c.png[/img]

4.cross join
[img]http://dl.iteye.com/upload/attachment/228724/26a0cd1f-30dd-3888-99bb-27ef53632359.png[/img]