|
東西很多 要慢慢看。。大概整合了三篇文章
設計范式（范式,數據庫設計范式,數據庫的設計范式）是符合某一種級別的關系模式的集合。構造數據庫必須遵循一定的規則。在關系數據庫中，這種規則就是范式。關系數據庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系數據庫有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎上進一步滿足更多要求的稱為第二范式（2NF），其余范式以次類推。一般說來，數據庫只需滿足第三范式（3NF）就行了。下面我們舉例介紹第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。 在創建一個數據庫的過程中，范化是將其轉化為一些表的過程，這種方法可以使從數據庫得到的結果更加明確。這樣可能使數據庫產生重復數據，從而導致創建多余的表。范化是在識別數據庫中的數據元素、關系，以及定義所需的表和各表中的項目這些初始工作之后的一個細化的過程。 下面是范化的一個例子 Customer Item purchased Purchase price Thomas Shirt $40 Maria Tennis shoes $35 Evelyn Shirt $40 Pajaro Trousers $25
如果上面這個表用于保存物品的價格，而你想要刪除其中的一個顧客，這時你就必須同時刪除一個價格。范化就是要解決這個問題，你可以將這個表化為兩個表，一個用于存儲每個顧客和他所買物品的信息，另一個用于存儲每件產品和其價格的信息，這樣對其中一個表做添加或刪除操作就不會影響另一個表。 關系數據庫的幾種設計范式介紹 1 第一范式（1NF） 在任何一個關系數據庫中，第一范式（1NF）是對關系模式的基本要求，不滿足第一范式（1NF）的數據庫就不是關系數據庫。 所謂第一范式（1NF）是指數據庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。在第一范式（1NF）中表的每一行只包含一個實例的信息。例如，對于圖3-2 中的員工信息表，不能將員工信息都放在一列中顯示，也不能將其中的兩列或多列在一列中顯示；員工信息表的每一行只表示一個員工的信息，一個員工的信息在表中只出現一次。簡而言之，第一范式就是無重復的列。 2 第二范式（2NF） 第二范式（2NF）是在第一范式（1NF）的基礎上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數據庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。如圖3-2 員工信息表中加上了員工編號（emp_id）列，因為每個員工的員工編號是惟一的，因此每個員工可以被惟一區分。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。 第二范式（2NF）要求實體的屬性完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二范式就是非主屬性必須依賴于整個主關鍵字。 3 第三范式（3NF） 滿足第三范式（3NF）必須先滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么在圖3-2的員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三范式（3NF）也應該構建它，否則就會有大量的數據冗余。簡而言之，第三范式就是屬性不依賴于其它非主屬性。 數據庫設計三大范式應用實例剖析 數據庫的設計范式是數據庫設計所需要滿足的規范，滿足這些規范的數據庫是簡潔的、結構明晰的，同時，不會發生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給數據庫的編程人員制造麻煩，而且面目可憎，可能存儲了大量不需要的冗余信息。 設計范式是不是很難懂呢？非也，大學教材上給我們一堆數學公式我們當然看不懂，也記不住。所以我們很多人就根本不按照范式來設計數據庫。 實質上，設計范式用很形象、很簡潔的話語就能說清楚，道明白。本文將對范式進行通俗地說明，并以筆者曾經設計的一個簡單論壇的數據庫為例來講解怎樣將這些范式應用于實際工程。 范式說明 第一范式（1NF）：數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。 例如，如下的數據庫表是符合第一范式的： 字段1 字段2 字段3 字段4 而這樣的數據庫表是不符合第一范式的： 字段1 字段2 字段3 字段4 字段3.1 字段3.2 很顯然，在當前的任何關系數據庫管理系統（DBMS）中，傻瓜也不可能做出不符合第一范式的數據庫，因為這些DBMS不允許你把數據庫表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一范式的數據庫都是不可能的。 第二范式（2NF）：數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的情況），也即所有非關鍵字段都完全依賴于任意一組候選關鍵字。 假定選課關系表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系： (學號, 課程名稱) → (姓名, 年齡, 成績, 學分) 這個數據庫表不滿足第二范式，因為存在如下決定關系： (課程名稱) → (學分) (學號) → (姓名, 年齡) 即存在組合關鍵字中的字段決定非關鍵字的情況。 由于不符合2NF，這個選課關系表會存在如下問題： (1) 數據冗余： 同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。 (2) 更新異常： 若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。 (3) 插入異常： 假設要開設一門新的課程，暫時還沒有人選修。這樣，由于還沒有"學號"關鍵字，課程名稱和學分也無法記錄入數據庫。 (4) 刪除異常： 假設一批學生已經完成課程的選修，這些選修記錄就應該從數據庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。 把選課關系表SelectCourse改為如下三個表： 學生：Student(學號, 姓名, 年齡)； 課程：Course(課程名稱, 學分)； 選課關系：SelectCourse(學號, 課程名稱, 成績)。 這樣的數據庫表是符合第二范式的， 消除了數據冗余、更新異常、插入異常和刪除異常。 另外，所有單關鍵字的數據庫表都符合第二范式，因為不可能存在組合關鍵字。 第三范式（3NF）：在第二范式的基礎上，數據表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴則符合第三范式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴于A。因此，滿足第三范式的數據庫表應該不存在如下依賴關系： 關鍵字段 → 非關鍵字段x → 非關鍵字段y 假定學生關系表為Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系： (學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話) 這個數據庫是符合2NF的，但是不符合3NF，因為存在如下決定關系： (學號) → (所在學院) → (學院地點, 學院電話) 即存在非關鍵字段"學院地點"、"學院電話"對關鍵字段"學號"的傳遞函數依賴。 它也會存在數據冗余、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。 把學生關系表分為如下兩個表： 學生：(學號, 姓名, 年齡, 所在學院)； 學院：(學院, 地點, 電話)。 這樣的數據庫表是符合第三范式的，消除了數據冗余、更新異常、插入異常和刪除異常。 鮑依斯-科得范式（BCNF）：在第三范式的基礎上，數據庫表中如果不存在任何字段對任一候選關鍵字段的傳遞函數依賴則符合第三范式。 假設倉庫管理關系表為StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個數據庫表中存在如下決定關系： (倉庫ID, 存儲物品ID) →(管理員ID, 數量) (管理員ID, 存儲物品ID) → (倉庫ID, 數量) 所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵字段為數量，它是符合第三范式的。但是，由于存在如下決定關系： (倉庫ID) → (管理員ID) (管理員ID) → (倉庫ID) 即存在關鍵字段決定關鍵字段的情況，所以其不符合BCNF范式。它會出現如下異常情況： (1) 刪除異常： 當倉庫被清空后，所有"存儲物品ID"和"數量"信息被刪除的同時，"倉庫ID"和"管理員ID"信息也被刪除了。 (2) 插入異常： 當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。 (3) 更新異常： 如果倉庫換了管理員，則表中所有行的管理員ID都要修改。 把倉庫管理關系表分解為二個關系表： 倉庫管理：StorehouseManage(倉庫ID, 管理員ID)； 倉庫：Storehouse(倉庫ID, 存儲物品ID, 數量)。 這樣的數據庫表是符合BCNF范式的，消除了刪除異常、插入異常和更新異常。 范式應用 我們來逐步搞定一個論壇的數據庫，有如下信息： （1） 用戶：用戶名，email，主頁，電話，聯系地址 （2） 帖子：發帖標題，發帖內容，回復標題，回復內容 第一次我們將數據庫設計為僅僅存在表： 用戶名 email 主頁 電話 聯系地址 發帖標題 發帖內容 回復標題 回復內容 這個數據庫表符合第一范式，但是沒有任何一組候選關鍵字能決定數據庫表的整行，唯一的關鍵字段用戶名也不能完全決定整個元組。我們需要增加"發帖ID"、"回復ID"字段，即將表修改為： 用戶名 email 主頁 電話 聯系地址 發帖ID 發帖標題 發帖內容 回復ID 回復標題 回復內容 這樣數據表中的關鍵字(用戶名，發帖ID，回復ID)能決定整行： (用戶名,發帖ID,回復ID) → (email,主頁,電話,聯系地址,發帖標題,發帖內容,回復標題,回復內容) 但是，這樣的設計不符合第二范式，因為存在如下決定關系： (用戶名) → (email,主頁,電話,聯系地址) (發帖ID) → (發帖標題,發帖內容) (回復ID) → (回復標題,回復內容) 即非關鍵字段部分函數依賴于候選關鍵字段，很明顯，這個設計會導致大量的數據冗余和操作異常。 我們將數據庫表分解為（帶下劃線的為關鍵字）： （1） 用戶信息：用戶名，email，主頁，電話，聯系地址 （2） 帖子信息：發帖ID，標題，內容 （3） 回復信息：回復ID，標題，內容 （4） 發貼：用戶名，發帖ID （5） 回復：發帖ID，回復ID 這樣的設計是滿足第1、2、3范式和BCNF范式要求的，但是這樣的設計是不是最好的呢？ 不一定。 觀察可知，第4項"發帖"中的"用戶名"和"發帖ID"之間是1：N的關系，因此我們可以把"發帖"合并到第2項的"帖子信息"中；第5項"回復"中的"發帖ID"和"回復ID"之間也是1：N的關系，因此我們可以把"回復"合并到第3項的"回復信息"中。這樣可以一定量地減少數據冗余，新的設計為： （1） 用戶信息：用戶名，email，主頁，電話，聯系地址 （2） 帖子信息：用戶名，發帖ID，標題，內容 （3） 回復信息：發帖ID，回復ID，標題，內容 數據庫表1顯然滿足所有范式的要求； 數據庫表2中存在非關鍵字段"標題"、"內容"對關鍵字段"發帖ID"的部分函數依賴，即不滿足第二范式的要求，但是這一設計并不會導致數據冗余和操作異常； 數據庫表3中也存在非關鍵字段"標題"、"內容"對關鍵字段"回復ID"的部分函數依賴，也不滿足第二范式的要求，但是與數據庫表2相似，這一設計也不會導致數據冗余和操作異常。 由此可以看出，并不一定要強行滿足范式的要求，對于1：N關系，當1的一邊合并到N的那邊后，N的那邊就不再滿足第二范式了，但是這種設計反而比較好！ 對于M：N的關系，不能將M一邊或N一邊合并到另一邊去，這樣會導致不符合范式要求，同時導致操作異常和數據冗余。 對于1：1的關系，我們可以將左邊的1或者右邊的1合并到另一邊去，設計導致不符合范式要求，但是并不會導致操作異常和數據冗余。 結論 滿足范式要求的數據庫設計是結構清晰的，同時可避免數據冗余和操作異常。這并意味著不符合范式要求的設計一定是錯誤的，在數據庫表中存在1：1或1：N關系這種較特殊的情況下，合并導致的不符合范式要求反而是合理的。 理解數據庫范式 系統是短暫的 數據是永恒的 數 據庫范式是數據庫設計中必不可少的知識，沒有對范式的理解，就無法設計出高效率、優雅的數據庫。甚至設計出錯誤的數據庫。而想要理解并掌握范式卻并不是那 么容易。教科書中一般以關系代數的方法來解釋數據庫范式。這樣做雖然能夠十分準確的表達數據庫范式，但比較抽象，不太直觀，不便于理解，更難以記憶。 本 文用較為直白的語言介紹范式，旨在便于理解和記憶，這樣做可能會出現一些不精確的表述。但對于初學者應該是個不錯的入門。我寫下這些的目的主要是為了加強 記憶，其實我也比較菜，我希望當我對一些概念生疏的時候，回過頭來看看自己寫的筆記，可以快速地進入狀態。如果你發現其中用錯誤，請指正。 下面開始進入正題： 一、基礎概念 要理解范式，首先必須對知道什么是關系數據庫，如果你不知道，我可以簡單的不能再簡單的說一下：關系數據庫就是用二維表來保存數據。表和表之間可以……（省略10W字）。 然后你應該理解以下概念： 實體：現實世界中客觀存在并可以被區別的事物。比如“一個學生”、“一本書”、“一門課”等等。值得強調的是這里所說的“事物”不僅僅是看得見摸得著的“東西”，它也可以是虛擬的，不如說“老師與學校的關系”。 屬性：教科書上解釋為：“實體所具有的某一特性”，由此可見，屬性一開始是個邏輯概念，比如說，“性別”是“人”的一個屬性。在關系數據庫中，屬性又是個物理概念，屬性可以看作是“表的一列”。 元組：表中的一行就是一個元組。 分量：元組的某個屬性值。在一個關系數據庫中，它是一個操作原子，即關系數據庫在做任何操作的時候，屬性是“不可分的”。否則就不是關系數據庫了。 碼：表中可以唯一確定一個元組的某個屬性（或者屬性組），如果這樣的碼有不止一個，那么大家都叫候選碼，我們從候選碼中挑一個出來做老大，它就叫主碼。 全碼：如果一個碼包含了所有的屬性，這個碼就是全碼。 主屬性：一個屬性只要在任何一個候選碼中出現過，這個屬性就是主屬性。 非主屬性：與上面相反，沒有在任何候選碼中出現過，這個屬性就是非主屬性。 外碼：一個屬性（或屬性組），它不是碼，但是它別的表的碼，它就是外碼。 二、6個范式 好了，上面已經介紹了我們掌握范式所需要的全部基礎概念，下面我們就來講范式。首先要明白，范式的包含關系。一個數據庫設計如果符合第二范式，一定也符合第一范式。如果符合第三范式，一定也符合第二范式… 第一范式（1NF）：屬性不可分。 在前面我們已經介紹了屬性值的概念，我們說，它是“不可分的”。而第一范式要求屬性也不可分。那么它和屬性值不可分有什么區別呢？給一個例子：
Ps：這個表中，屬性值“分”了。
Ps：這個表中，屬性 “分”了。 這兩種情況都不滿足第一范式。不滿足第一范式的數據庫，不是關系數據庫！所以，我們在任何關系數據庫管理系統中，做不出這樣的“表”來。 第二范式（2NF）：符合1NF，并且，非主屬性完全依賴于碼。 聽起來好像很神秘，其實真的沒什么。 一 個候選碼中的主屬性也可能是好幾個。如果一個主屬性，它不能單獨做為一個候選碼，那么它也不能確定任何一個非主屬性。給一個反例：我們考慮一個小學的教務 管理系統，學生上課指定一個老師，一本教材，一個教室，一個時間，大家都上課去吧，沒有問題。那么數據庫怎么設計？（學生上課表）
一個學生上一門課，一定在特定某個教室。所以有（學生，課程）－>教室 一個學生上一門課，一定是特定某個老師教。所以有（學生，課程）－>老師 一個學生上一門課，他老師的職稱可以確定。所以有（學生，課程）－>老師職稱 一個學生上一門課，一定是特定某個教材。所以有（學生，課程）－>教材 一個學生上一門課，一定在特定時間。所以有（學生，課程）－>上課時間 因此（學生，課程）是一個碼。 然而，一個課程，一定指定了某個教材，一年級語文肯定用的是《小學語文1》，那么就有課程－>教材。（學生，課程）是個碼，課程卻決定了教材，這就叫做不完全依賴，或者說部分依賴。出現這樣的情況，就不滿足第二范式！ 有什么不好嗎？你可以想想： 1、 校長要新增加一門課程叫“微積分”，教材是《大學數學》，怎么辦？學生還沒選課，而學生又是主屬性，主屬性不能空，課程怎么記錄呢，教材記到哪呢? ……郁悶了吧?(插入異常) 2、 下學期沒學生學一年級語文（上）了，學一年級語文（下）去了，那么表中將不存在一年級語文（上），也就沒了《小學語文1》。這時候，校長問：一年級語文（上）用的什么教材啊？……郁悶了吧?(刪除異常) 3、 校長說：一年級語文（上）換教材，換成《大學語文》。有10000個學生選了這么課，改動好大啊！改累死了……郁悶了吧？（修改異常） 那應該怎么解決呢？投影分解，將一個表分解成兩個或若干個表
學生上課表新
課程的表 第三范式（3NF）：符合2NF，并且，消除傳遞依賴 上面的“學生上課表新”符合2NF，可以這樣驗證：兩個主屬性單獨使用，不用確定其它四個非主屬性的任何一個。但是它有傳遞依賴！ 在哪呢？問題就出在“老師”和“老師職稱”這里。一個老師一定能確定一個老師職稱。 有什么問題嗎？想想： 1、 老師升級了，變教授了，要改數據庫，表中有N條，改了N次……（修改異常） 2、 沒人選這個老師的課了，老師的職稱也沒了記錄……（刪除異常） 3、 新來一個老師，還沒分配教什么課，他的職稱記到哪？……（插入異常） 那應該怎么解決呢？和上面一樣，投影分解：
BC范式（BCNF）：符合3NF，并且，主屬性不依賴于主屬性 若關系模式屬于第一范式，且每個屬性都不傳遞依賴于鍵碼，則R屬于BC范式。 通常BC范式的條件有多種等價的表述：每個非平凡依賴的左邊必須包含鍵碼；每個決定因素必須包含鍵碼。 BC范式既檢查非主屬性，又檢查主屬性。當只檢查非主屬性時，就成了第三范式。滿足BC范式的關系都必然滿足第三范式。 還可以這么說：若一個關系達到了第三范式，并且它只有一個候選碼，或者它的每個候選碼都是單屬性，則該關系自然達到BC范式。 一般，一個數據庫設計符合3NF或BCNF就可以了。在BC范式以上還有第四范式、第五范式。 第四范式：要求把同一表內的多對多關系刪除。 第五范式：從最終結構重新建立原始結構。 但在絕大多數應用中不需要設計到這種程度。并且，某些情況下，過于范式化甚至會對數據庫的邏輯可讀性和使用效率起到阻礙。數據庫中一定程度的冗余并不一定是壞事情。如果你對第四范式、第五范式感興趣可以看一看專業教材，從頭學起，并且忘記我說的一切，以免對你產生誤導。
關系模式的范式 主要有4種范式，1NF，2NF，3NF，BCNF，按從左至右的順序一種比一種要求更嚴格。要符合某一種范式必須也滿足它前邊的所有范式。一般項目的數據庫設計達到3NF就可以了，而且可根據具體情況適當增加冗余，不必教條地遵守所謂規范。 簡單而言，1NF就是要求一張表里只放相互關聯的字段，一個字段里只放一條信息，這只是最基本的要求。至于2NF，3NF，BCNF雖然描述的內容不同，但表現在數據特點上很相似，就好比在說不要為了向某廠訂購一批貨記下來，就把的廠的面積、電話等都放在同一張表里，而應該用兩張表，以盡量避免浪費數據存儲空間。因為和同一個廠可能會交易好幾次，但沒必要每次交易都記錄全部的信息。 從范式所允許的函數依賴方面進行比較，四種范式之間的關聯如下圖所示。
以下對每種范式作一一說明。 在關系模式R中的每一個具體關系r中，如果每個屬性值 都是不可再分的最小數據單位，則稱R是第一范式的關系。 例：如職工號，姓名，電話號碼組成一個表（一個人可能有一個辦公室電話 和一個家里電話號碼） 規范成為1NF有三種方法： 關系的第二范式(2NF)定義： 如果關系模式R為1NF，并且R中的每一個非主屬性都完全依賴于R的某個候選關鍵字，則稱R是第二范式的，簡記為2NF。 【例2.40】 設有關系模式R(學號S#,課程號C#,成績G,任課教師TN,教師專長TS)，基于R的函數依賴集F={(S#,C#)→G,C#→TN,TN→TS},判斷R是否為2NF。 解： (1) 容易看出，關系模式R是1NF。因為R符合關系的定義，R的所有屬性值都是不可再分的原子值。 R是否為2NF，應根據2NF的定義來判斷。 首先要確定關系模式R中各屬性間的函數依賴情況。如果沒有直接給出R的函數依賴集，就要按照語義把它確定下來。在本例中，已直接給出基于R的函數依賴集F，我們可使用阿氏推理規則并結合下面介紹的方法，進一步確定R中哪些是主屬性、哪些是非主屬性、侯選關鍵字由哪些屬性構成。 方法① 寫出函數依賴集F中的各個函數依賴以幫助分析。方法①的特點是直接。 F={(S#,C#)→G， C#→TN， TN→TS } 方法② 用有向圖表示屬性間函數依賴，結點表示屬性，方框包含若干個結點表示屬性組合，有向箭頭表示函數依賴。本例的函數依賴圖如圖2.9所示。方法②的特點是直觀。
圖2.9 函數依賴圖例子 方法③ 把關系模式R與函數依賴集F結合起來，屬性組合用下劃線(或上劃線)表示，函數依賴用有向箭頭表示。本例的函數依賴簡圖如圖2.10所示。方法③的特點是簡單。
圖2.10函數依賴簡圖例子 用阿氏推理規則由F可推出：(S#,C#)→{S#,C#,G,TN,TS}，即屬性組合(S#,C#)是R的候選關鍵字(R只有這一個候選鍵)。(S#,C#)的一個值可惟一標識R中的一個元組(并且沒有多余的屬性)。 在R中，S#,C#是主屬性；其余的屬性G,TN,TS為非主屬性。 借助上面的圖，我們可以看到，非主屬性G對鍵是完全依賴：(S#,C#)→G。但非主屬性TN,TS對鍵是部分依賴(他們僅依賴于鍵的真子集C#)。由于R中存在非主屬性對候選鍵的部分依賴，所以關系模式R不是2NF。 R中存在非主屬性對候選鍵的部分依賴，將會引起數據冗余、數據操作異常等問題。可以把關系R無損聯接地分解成兩個2NF的關系模式： ρ={R1,R2}，R1={S#.C#,G},R2={C#,TN,TS}。 【例2.41】選課關系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO為學號， CNO為課程號，GRADEGE 為成績，CREDIT 為學分。 由以上條件，關鍵字為組合關鍵字（SNO，CNO）
在應用中使用以上關系模式有以下問題： a.數據冗余，假設同一門課由40個學生選修，學分就 重復40次。 b.更新異常，若調整了某課程的學分，相應的元組CREDIT值都要更新，有可能會出現同一門課學分不同。 c.插入異常，如計劃開新課，由于沒人選修，沒有學號關鍵字，只能等有人選修才能把課程和學分存入。 d.刪除異常，若學生已經結業，從當前數據庫刪除選修記錄,就會可能連課程號及學分完全從數據庫中刪除，則此門課程及學分記錄無法保存。 原因：非關鍵字屬性CREDIT僅函數依賴于CNO，也就是CREDIT部分依賴組合關鍵字（SNO，CNO）而不是完全依賴。 解決方法：分成兩個關系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新關系包括兩個關系模式，它們之間通過SC1中的外關鍵字CNO相聯系，需要時再進行自然聯接，恢復了原來的關系 關系的第三范式(3NF)定義： 如果關系模式R為2NF，并且R中的每一個非主屬性都不傳遞依賴于R的某個候選關鍵字，則稱R是第三范式的，簡記為3NF。 【例2.42】續上例2.40（R(學號S#,課程號C#,成績G,任課教師TN,教師專長TS)），判斷關系模式R1={S#.C#,G},R2={C#,TN,TS} 是否為3NF。 解： (1) 在關系模式R1={S#,C#,G}，候選關鍵字是(S#,C#)，主屬性是S#,C#，非主屬性是G，函數依賴為(S#,C#)→G。 由于R1中不存在非主屬性對候選關鍵字的傳遞依賴，所以關系模式R1是3NF。 (2) 在關系模式R2={C#,TN,TS}，候選關鍵字是C#，主屬性是C#，非主屬性是TN,TS，函數依賴為C#→TN，TN→TS。由于R2中存在非主屬性對候選關鍵字的傳遞依賴C# TS，所以關系模式R2不是3NF。 可以把關系R2無損聯接地分解成兩個3NF的關系模式： ρ={R3,R4}，R3={C#,TN},R4={TN,TS}。 【例2.43】如（SNO，SNAME，DNO，DNAME，LOCATION） 各屬性分別代表學號，
但這關系有大量的冗余，有關學生所在的幾個屬性DNO，DNAME，LOCATION將重復存儲，插入，刪除和修改時也將產生類似以上例的情況。 關系的Boyce-Codd范式(BCNF)定義： 如果關系模式R為1NF，并且R中的每一個函數依賴X→Y(YÏX),必有X是R的超關鍵字，則稱R是Boyce-Codd范式的，簡記為BCNF。 從BCNF的定義中，可以明顯地得出如下結論： (1) 所有非主屬性對鍵是完全函數依賴； (2) 所有主屬性對不包含它的鍵是完全函數依賴； (3)沒有屬性完全函數依賴于非鍵的任何屬性組合。 與2NF,3NF的定義不同，BCNF的定義直接建立在1NF的基礎上。但實質上BCNF是3NF的改進形式。3NF僅考慮了非主屬性對鍵的依賴情況，BCNF把主屬性對鍵的依賴情況也包括進去。BCNF要求滿足的條件比3NF所要求的更高。如果關系模式R是BCNF的，那么R必定是3NF，反之，則不一定成立。 【例2.43】 續前例2.42（學號S#,課程號C#,成績G,任課教師TN,教師專長TS）,判斷兩個3NF關系模式R3={C#,TN},R4={TN,TS}是否為BCNF。 解：在關系模式R3中有函數依賴C#→TN，決定因素C#是R3的鍵； 在關系模式R4中有函數依賴TN→TS，決定因素TN是R4的鍵； R3,R4都滿足BCNF的定義，所以，這兩個關系模式都是BCNF。 【例2.44】配件管理關系模式 WPE（WNO，PNO，ENO，QNT）分別表倉庫號，配件號，職工號，數量。有以下條件 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
