[TOC] # 簡介 　好了，上面已經介紹了我們掌握范式所需要的全部基礎概念，下面我們就來講范式。 范式可以理解為一種規范等級。 首先要明白，范式的包含關系： >　　一個數據庫設計如果符合第二范式，一定也符合第一范式。如果符合第三范式，一定也符合第二范式… ## **第一范式（1NF）：屬性不可分。** 第一范式的特點： * 有主關鍵字 * 主鍵不能為空 * 主鍵不能重復 * 字段不可以再分 下表是否滿足第一范式? | StudyNo? ? | Name| Sex | Contact | | -- | -- | -- | -- | | 20040901 | john | Male | Email:kkkk@ee.net,phone:222456 | | 20040901 | mary| Female | Email:kkk@fff.net phone:123455 | Ps：這個表中，屬性值“分”了：  Ps：這個表中，屬性值“分”了：  以上表格都是否滿足第一范式？（**不滿足屬性不可分！**） **注意：** 這兩種情況都不滿足第一范式。不滿足第一范式的數據庫，不是關系數據庫！所以，我們在任何關系數據庫管理系統中，做不出這樣的“表”來。 ## **第二范式（2NF）：非主屬性完全依賴于碼。** 定義：如果關系模式R是第一范式的，而且關系中每一個非主屬性不部分依賴于主鍵，稱R是第二范式的。 所以第二范式的主要任務就是滿足第一范式的前提下，消除部分函數依賴。 觀察這個表格是否滿足第二范式： | StudyNo? | Name | Sex? | Email |Phone? | ClassNo??|ClassAddress | | -- | -- | -- | -- | -- | -- | -- | | 01 | john | Male | ?k@ee.net | 222456 | 200401| A樓2單元 | | 02 | mary | Female | kkk@fff.net | 123455 | 200402 | A樓3單元 | 這個表完全滿足于第一范式主鍵由`StudyNo`和`ClassNo`組成，這樣才能定位到指定行，但是，`ClassAddress`部分依賴于關鍵字(`ClassNo-〉ClassAddress`),所以要變為兩個表： 表一： | StudyNo? | Name | Sex? | Email |Phone? | ClassNo??| | -- | -- | -- | -- | -- | -- | -- | | 01 | john | Male | ?k@ee.net | 222456 | 200401| | 02 | mary | Female | kkk@fff.net | 123455 | 200402 | 表二： | ClassNo??|ClassAddress | | -- | -- | | 200401| A樓2單元 | | 200402 | A樓3單元 | ### **再來看一個例子：**  **分析：** 一個學生上一門課，一定在特定某個教室。所以有（學生，課程）－>教室 一個學生上一門課，一定是特定某個老師教。所以有（學生，課程）－>老師 一個學生上一門課，他老師的職稱可以確定。所以有（學生，課程）－>老師 一個學生上一門課，一定是特定某個教材。所以有（學生，課程）－>教材 一個學生上一門課，一定在特定時間。所以有（學生，課程）－>上課時間 因此（學生，課程）是一個碼。 然而，一個課程，一定指定了某個教材，一年級語文肯定用的是《小學語文1》 那么就有課程－>教材。（學生，課程）是個碼，課程卻決定了教材，這就叫 不完全依賴，或者說部分依賴。出現這樣的情況，就不滿足第二范式！ **思考：** 那么，如果我們希望他滿足第二范式，仿照剛才的例子我們應該怎樣做了？ **解決：** 1. 校長要新增加一門課程叫“微積分”，教材是《大學數學》，怎么辦？學生還沒選課，而學生又是主屬性，主屬性不能空，課程怎么記錄呢，教材記到哪呢(插入異常) 2. 下學期沒學生學一年級語文（上）了，學一年級語文（下）去了，那么表中將不存在一年級語文（上），也就沒了《小學語文1》。這時候，校長問：一年級語文（上）用的什么教材啊？……郁悶了吧?(刪除異常) 3. 校長說：一年級語文（上）換教材，換成《大學語文》。有10000個學生選了這么課，改動好大啊！改累死了……郁悶了吧？（修改異常）那應該怎么解決呢？投影分解，將一個表分解成兩個或若干個表。 **解決：**  ## **第三范式（3NF）（不依賴于其它非主屬性[消除傳遞依賴] ）。** | StudyNo | Name | Sex | Email | bounsLevel | bouns | | -- | -- | -- | -- | -- | -- | | 40901 | john | Male | kkkk@ee.net | 良 | $1000 | | 40902 | mary | female | kkk@fff.net | 差 | $600 | 這個完全滿足了第二范式,但是`bounsLevel`和`bouns`存在傳遞依賴。 **解決：** 更改為： 表一： | StudyNo|Name | Sex | Email| bounsNo | | -- | -- | -- | -- | -- | | 20040901 | john | Male | kkkk@ee.net | 1 | | 20040902 | mary | Female | kkk@fff.net | 2 | 表二： | bounsNo | bounsLevel | bouns | | -- | -- | -- | | 1 | 優秀 | $1000 | | 2 | 良 | $600 | ### 再來看一個示例：  有什么問題嗎？ 想想： 1. 老師升級了，變教授了，要改數據庫，表中有N條，改了N次……（修改異常） 2. 沒人選這個老師的課了，老師的職稱也沒了記錄……（刪除異常） 3. 新來一個老師，還沒分配教什么課，他的職稱記到哪？……（插入異常） 那應該怎么解決呢？和上面一樣，投影分解： | 學生 | 課程 | 老師| 教室| 上課時間 | |---- |---|---| -- |---| | 小明 | 小明 | 大寶 | 101 | 14：30 | | 老師 | 老師職稱 | |---- |---|---| | 大寶 | 副教授 | ## BC范式（BCNF）：符合3NF，并且，主屬性不依賴于主屬性 若關系模式屬于第一范式，且每個屬性都不傳遞依賴于鍵碼，則R屬于BC范式。 通常BC范式的條件有多種等價的表述：每個非平凡依賴的左邊必須包含鍵碼；每個決定因素必須包含鍵碼。 BC范式既檢查非主屬性，又檢查主屬性。當只檢查非主屬性時，就成了第三 范式。滿足BC范式的關 系都必然滿足第三范式。 還可以這么說：**若一個關系達到了第三范式，并且它只有一個候選碼，或者它的每個候選碼都是單屬性，則該關系自然達到BC范式。** 一般，一個數據庫設計符合3NF或BCNF就可以了。在BC范式以上還有第四范式、第五范式。 ### 詳解： 如果關系模式R（U，F）的所有屬性（包括主屬性和非主屬性）都不傳遞依賴于R的任何候選關鍵字，那么稱關系R是屬于BCNF的。或是關系模式 R，如果每個決定因素都包含關鍵字（而不是被關鍵字所包含），則RCNF的關系模式。 例：配件管理關系模式 WPE（WNO，PNO，ENO，QNT）分別表倉庫號，配件號，職工號，數量。 有以下條件： * 一個倉庫有多個職工。 * 一個職工僅在一個倉庫工作。 * 每個倉庫里一種型號的配件由專人負責，但一個人可以管理幾種配件。 * 同一種型號的配件可以分放在幾個倉庫中。 分析： 由以上得 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 丟失了, 因而對原來的語義有所破壞。沒有體現出每個倉庫里一種部件由專人負責。有可能出現 一部件由兩個人或兩個以上的人來同時管理。因此，分解之后的關系模式降低了部分完整性約束。 ## *第四范式：* 要求把同一表內的多對多關系刪除。 ## *第五范式：* 從最終結構重新建立原始結構。 > 并且，**某些情況下，過于范式化甚至會對數據庫的邏輯可讀性和使用效率起到阻礙**。數據庫中一定程度的冗余并不一定是壞事情。 **但在絕大多數應用中不需要設計到第四和第五這兩種程度**。如果你對第四范式、第五范式感興趣可以看一看專業教材，從頭學起，并且忘記我說的一切，以免對你產生誤導。