| 按：資料庫的範式設計是為了優化關系資料庫的關系模式，便于減少資料備援以及沖突。 而範式是建立在函數依賴的基礎上的。 要看懂這個還有一個基礎是要明白主碼，主屬性和非主屬性的概念。 不同階段的範式是一個不斷的優化關系模式的過程，其實就是限制條件不斷更新，關系模式不斷精化的過程。 不過随着範式的提高，關系模式的數量也會增加（對于個别表精化了，被剔除的關系隻能形成新的關系模式），如果多個關系之間進行連接配接或并的操作的話，對資料庫的性能會産生影響。 綜合考慮一般精化至3NF即可。 高階段的範式是在低階段範式的基礎上，加入新的限制條件形成的。是以滿足高範式的一定滿足比其低的範式。 第一範式是确定模式是符合關系關系模式的要求，即确立某關系屬于關系模式。 第二範式是消除了非主屬性對主碼的部分函數依賴。 第三範式是消除了非主屬性的傳遞函數依賴。 *3NF去除了非主屬性對主鍵的部分函數依賴和傳遞函數依賴* BCNF是消除了所有屬性的傳遞函數依賴。 *BC範式既檢查非主屬性，又檢查主屬性。當隻檢查非主屬性時，就成了第三範式。滿足BC範式的關系都必然滿足第三範式* 第四範式取消了多值依賴。 第五範式取消了連接配接依賴。 *嚴格的說上述兩種依賴，不屬于函數依賴的範疇，可以自己參考相關書籍了解* 由于現在沒有時間深入說，就把之間的關系說清就好了，反正也不難了解，再看看書就明白了^_^ 文中的例子是彙總于網絡文章的，謝謝原作者了。 函數依賴 部分函數依賴------- 完全函數依賴：在一個關系中，若某個非主屬性資料項依賴于全部關鍵字稱之為完全函數依賴。 如果非主屬性B函數依賴于構成某個候選關鍵字的一組主屬性A，而不函數依賴于A的任何一個真子集，則稱B完全函數依賴于A；反之，則稱B部分函數依賴于A。 傳遞函數依賴----------- 非平凡依賴----------- 在關系模式R(U)中，對于U的子集X和Y， 如果X→Y，但Y ? X，則稱X→Y是非平凡的函數依賴 若X→Y，但Y ? X, 則稱X→Y是平凡的函數依賴 例：在關系SC(Sno, Cno, Grade)中， 非平凡函數依賴： (Sno, Cno) → Grade 平凡函數依賴： (Sno, Cno) → Sno (Sno, Cno) → Cno 多值依賴 見下“範式”部分，針對第四範式，第四範式就是為了取消多值依賴 連接配接依賴 見下“範式”部分，針對的是第五範式 ---------------------------------------------------------------------------- 首先要明白，範式的包含關系。一個資料庫設計如果符合第二範式，一定也符合第一範式。如果符合第三範式，一定也符合第二範式… 範式 --------------------------------------------------------------------------- 第一範式 定義：如果關系R 中所有屬性的值域都是單純域，那麼關系模式R是第一範式的 那麼符合第一模式的特點就有 1)有主關鍵字 2)主鍵不能為空， 3)主鍵不能重複, 4)字段不可以再分 例如： 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 這兩種情況都不滿足第一範式。不滿足第一範式的資料庫，不是關系資料庫！是以，我們在任何關系資料庫管理系統中，做不出這樣的“表”來。 在任何一個關系資料庫中，第一範式（1NF）是對關系模式的基本要求，不滿足第一範式（1NF）的資料庫就不是關系資料庫。 所謂第一範式（1NF）是指資料庫表的每一列都是不可分割的基本資料項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。如果出現重複的屬性，就可能需要定義一個新的實體，新的實體由重複的屬性構成，新實體與原實體之間為一對多關系。在第一範式（1NF）中表的每一行隻包含一個執行個體的資訊。例如，對于圖3-2 中的員工資訊表，不能将員工資訊都放在一列中顯示，也不能将其中的兩列或多列在一列中顯示；員工資訊表的每一行隻表示一個員工的資訊，一個員工的資訊在表中隻出現一次。簡而言之，第一範式就是無重複的列。 ------------------------------------------------------------------------------------------ 第二範式： 定義：如果關系模式R是第一範式的，而且關系中每一個非主屬性不部分依賴于主鍵，稱R是第二範式的。 是以第二範式的主要任務就是 滿足第一範式的前提下，消除部分函數依賴。 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 這個表完全滿足于第一範式, 主鍵由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 （學生上課表） 學生 課程 老師 老師職稱 教材 教室 上課時間 小明 一年級國文（上） 大寶 副教授 《國小國文1》 101 14：30 一個學生上一門課，一定在特定某個教室。是以有（學生，課程）－>教室 一個學生上一門課，一定是特定某個老師教。是以有（學生，課程）－>老師 一個學生上一門課，他老師的職稱可以确定。是以有（學生，課程）－>老師職稱 一個學生上一門課，一定是特定某個教材。是以有（學生，課程）－>教材 一個學生上一門課，一定在特定時間。是以有（學生，課程）－>上課時間 是以（學生，課程）是一個碼。 然而，一個課程，一定指定了某個教材，一年級國文肯定用的是《國小國文1》，那麼就有課程－>教材。（學生，課程）是個碼，課程卻決定了教材，這就叫做不完全依賴，或者說部分依賴。出現這樣的情況，就不滿足第二範式！ 有什麼不好嗎？你可以想想： 1、 校長要新增加一門課程叫“微積分”，教材是《大學數學》，怎麼辦？學生還沒選課，而學生又是主屬性，主屬性不能空，課程怎麼記錄呢，教材記到哪呢? ……郁悶了吧?(插入異常) 2、 下學期沒學生學一年級國文（上）了，學一年級國文（下）去了，那麼表中将不存在一年級國文（上），也就沒了《國小國文1》。這時候，校長問：一年級國文（上）用的什麼教材啊？……郁悶了吧?(删除異常) 3、 校長說：一年級國文（上）換教材，換成《大學國文》。有10000個學生選了這麼課，改動好大啊！改累死了……郁悶了吧？（修改異常） 那應該怎麼解決呢？投影分解，将一個表分解成兩個或若幹個表 學生 課程 老師 老師職稱 教室 課時間 小明 一年級國文（上） 大寶 副教授 101 14：30 學生上課表新 課程 教材 一年級國文（上） 《國小國文1》 課程的表 第二範式（2NF）要求實體的屬性完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體 -------------------------------------------------------------------------------- 第三範式： 滿足第二範式的前提下，消除傳遞依賴。 例: StudyNo | Name | Sex | Email | bounsLevel | bouns 20040901 john Male [email protected] 優秀 $1000 20040902 mary famale [email protected] 良 $600 這個完全滿足了第二範式,但是bounsLevel和bouns存在傳遞依賴 更改為： StudyNo | Name | Sex | Email 20040901 john Male [email protected] 20040902 mary famale [email protected] bounsLevel | bouns 優秀 $1000 良 $600 上面的“學生上課表新”符合2NF，可以這樣驗證：兩個主屬性單獨使用，不用确定其它四個非主屬性的任何一個。但是它有傳遞依賴！ 在哪呢？問題就出在“老師”和“老師職稱”這裡。一個老師一定能确定一個老師職稱。 有什麼問題嗎？想想： 1、 老師更新了，變教授了，要改資料庫，表中有N條，改了N次……（修改異常） 2、 沒人選這個老師的課了，老師的職稱也沒了記錄……（删除異常） 3、 新來一個老師，還沒配置設定教什麼課，他的職稱記到哪？……（插入異常） 那應該怎麼解決呢？和上面一樣，投影分解： 學生 課程 老師 教室 上課時間 小明 一年級國文（上） 大寶 101 14：30 老師 老師職稱 大寶 副教授 ---------------------------------------------------------------------- BC範式（BCNF）：符合3NF，并且，主屬性不依賴于主屬性 若關系模式屬于第一範式，且每個屬性都不傳遞依賴于鍵碼，則R屬于BC範式。 通常BC範式的條件有多種等價的表述：每個非平凡依賴的左邊必須包含鍵碼；每個決定因素必須包含鍵碼。 BC範式既檢查非主屬性，又檢查主屬性。當隻檢查非主屬性時，就成了第三範式。滿足BC範式的關系都必然滿足第三範式。 還可以這麼說：若一個關系達到了第三範式，并且它隻有一個候選碼，或者它的每個候選碼都是單屬性，則該關系自然達到BC範式。 3NF去除了非主屬性對主鍵的部分函數依賴和傳遞函數依賴。一般滿足3NF的關系模式已能消除備援和各種異常現象，獲得較滿意的效果，但無論2NF還是3NF都沒有涉及主屬性間的函數依賴，是以有時仍會引起一些問題。由此我們引入BC範式(BCNF，Boyeet和Codd提出)，通常認為BCNF是第三範式的改進。 BC範式的定義：如果關系模式R∈1NF，且R中每一個決定因素都是候選鍵，則R是滿足BC範式的關系，記作R∈BCNF。 當一個關系模式R∈BCNF，則在函數依賴範疇裡，已實作了分離，消除了插入、删除的異常。 ---------------------------------------------------------------------- 第四範式： 主要任務：滿足第三範式的前提下，消除多值依賴 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 第四範式是BC範式的推廣，是針對有多值依賴的關系模式所定義的規範化形式。 定義：關系模式R∈1NF，X、Y是Ｕ的非空子集， ，Z=U-X-Y也非空。此時若X→→Y，則X必包含R的主鍵，稱Ｒ是第四範式的，記作：R∈4NF。 反例：下表表示關系R4(sbm,cz#,sccj)。 裝置名(sbm) 廠站代碼(czdm) 生産廠家(sccj) 引風機 101 匈牙利 引風機 101 沈陽風機廠 引風機 101 成都電力機械廠 引風機 102 沈陽風機廠 分析上表，對sbm的一個值，不論sccj取什麼值，總有一組确定的cz#與之對應，是以有：sbm→→cz#，同樣分析有sbm→→sccj。這說明R4不滿足4NF，此種關系模式有資料備援和修改量大等弊端。可用分解法消除不滿足4NF的非平凡多值依賴。解決辦法：把R4分解為R41(sbm,cz#)，R42(sbm,sccj)。 ----------------------------------------------------------------- 第五範式： 定義: 如果關系模式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 前面我們提高範式等級的辦法是分解，把一個關系用投影來代替，這些投影一般都能通過連接配接得到原來的關系。但有一種關系不能無損分解成兩個投影，而能分解成三個以上的投影。如下圖中，關系ABC可分解成兩個投影AB和BC(或AC和BC)。AB與BC在上連接配接得ABC2；ABC2與AC再連接配接得ABC3。顯然關系ABC2中比關系ABC多出一進制組(a2,b1,c2)，稱之為寄生元組。ABC2與AC連接配接，得關系ABC3，和原關系相同。是以關系ABC具有連接配接依賴JD*(A,B,C)。  資料庫基礎：資料庫範式 定義: 如果關系模式R中的每一個連接配接依賴, 都是由R的候選鍵所蘊含, 稱R是第五範式的,記作:R∈5NF 附注：範式及函數依賴部分的文字都是從網上摘抄下來的，因為沒有檢查，如果有不對的地方請留言，我來修改~ 看了這篇文字，對資料庫範式應該就會有比較全面的了解了，歡迎留言讨論 此外，對于第四和第五範式，由于涉及到的兩個依賴嚴格來說不屬于函數依賴也比較難了解，可以參考其他書。不過這兩個範式用的比較少，看不懂對實際工作影響也不是很大了。 | 
![[轉]九大排序算法——C語言實作及詳解[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)