第3章-數據庫設計課件

第3章數據庫設計第3章數據庫設計1第3章數據庫設計ER數據模型3.1EER數據模型3.2邏輯數據庫設計：映射ER/EER模式到關系模式3.3關系模式求精與規(guī)范化3.42第3章數據庫設計ER數據模型3.1EER數據模型3.2邏輯DB應用DB應用定義：一個特定的數據庫，加上實現此數據庫查詢/更新的相關程序。概念設計是成功設計DB應用的一個環(huán)節(jié)。實體-關系模型(Entity-Relationmodel)，簡稱ER模型，是一種非常流行的概念數據模型。EER是基于ER的擴展模型(EnhancedERmodel)ER/EER已被廣泛應用于DB概念設計。它們均以圖形化方式描述和捕獲用戶需求。基于ER/EER進行概念設計的輸出為一組ER/EER圖。基于概念模型的設計，最終都必須變換/轉換到可在DB中實現的邏輯數據模型。借助RDB設計有關規(guī)范理論,不僅可對轉換后的邏輯數據模式進行規(guī)范，而且可對ER/EER圖進行求精。3DB應用DB應用定義：一個特定的數據庫，加上實現此數據庫查詢DB設計的主要階段與過程4DB設計的主要階段與過程4DB設計的基本步驟（1）1.需求分析2.概念DB設計利用需求分析獲得的信息，建立DB數據的一個抽象描述。這一步通常利用ER/EER模型，或其它高級數據概念模型（如UML類圖），來實現。3.邏輯DB設計轉換DB概念設計模式到指定DBMS邏輯模式。由于需求信息本身帶有很大主觀性，故基于需求信息構造的ER/EER圖只能提供數據的一個近似描述。4.模式細化5.物理DB設計6.安全設計5DB設計的基本步驟（1）1.需求分析5DB設計的基本步驟（2）1.需求分析2.概念DB設計3.邏輯DB設計4.模式細化分析關系數據庫模式的關系集，檢查潛在問題并進行優(yōu)化。與需求分析和概念設計的主觀性特點不同，細化可得到強有力的規(guī)范理論支持。5.物理DB設計考慮應用必須支持的一些典型預期負荷,并以此為基礎進一步求精DB設計，確保它能滿足預期的性能要求。這個步驟可能包括為一些表建立索引，或指定聚集存儲方式等。6.安全設計6DB設計的基本步驟（2）1.需求分析63.1ER數據模型3.1.1實體類型、實體集、屬性和鍵3.1.2關系、關系類型和關系集3.1.3ER模型的其他特性73.1ER數據模型3.1.1實體類型、實體集、屬性和鍵ER模型簡介1.構成ER模型的基本概念實體與屬性實體類型、實體集與鍵實體類型：定義了具有相同屬性的實體模式結構，由名和屬性來描述。實體集：具有相同實體類型的所有實體集合。實體類型描述了相同結構實體集的模式或內涵；實體集則描述了實體類型的外延。ER圖中不區(qū)分實體類型和實體集（被視為同義詞）。關系、關系類型和關系集ER模型的其它概念☆ER圖表示規(guī)定實體集：用加矩形外框的名字來表示。屬性名：則用橢圓框起，并用直線與實體集相連。多值屬性：用雙線橢圓框起;復合屬性：用名字后加注結構成份表示;鍵屬性：通過屬性名加下劃線來標識。

☆ER圖表示規(guī)定關系集：用名字外加菱形框表示，并用直線將其與參與實體集的矩形框相連。8ER模型簡介1.構成ER模型的基本概念☆ER圖表示規(guī)定ER圖設計舉例（1）9ER圖設計舉例（1）9ER圖設計舉例（2）10ER圖設計舉例（2）10ER模型的其它概念關系屬性關系集也可以有自己的描述屬性，用來刻畫關系集本身的性質，而不是某個參與實體集的性質。關系約束指與關系集相關的約束，通過約束表達可限制參與關系各實體的可能組合。主要類型：基數詞約束、鍵約束和參與約束。弱實體集指只能附屬其它實體集而存在的實體集。11ER模型的其它概念關系屬性11在ER圖中表達關系基數詞和參與約束12在ER圖中表達關系基數詞和參與約束12弱實體集的幾種ER建模方法（圖3.5)13弱實體集的幾種ER建模方法（圖3.5)133.2EER數據模型3.2.1EER模型核心概念的形式定義3.2.2子類、超類與類層次結構3.2.3特化與泛化3.2.4利用union子類建模3.2.5值集屬性與復合結構屬性的建模表示3.2.6EER與UML類圖比較3.2.7EER作為知識表示模型3.2.8為大型企業(yè)/組織進行DB概念設計143.2EER數據模型3.2.1EER模型核心概念的形式定EER核心概念（1）類指實體的集合或實體集，這包括可對DB應用域實體分組的任何EER模式構造，如實體類(型)、子類、超類和類別。EER中，任何類都允許參與一個關系。子類、超類子類S是一個類，子類中的實體必然是其超類C中實體的一個子集，即有關系：S?C成立超類/子類關系也稱為ISA關系，記做C/S。子類實體除了可以從超類實體中繼承所有的屬性外，還可以有自己專有的屬性和關系。15EER核心概念（1）類15EER核心概念（2）特化特化Z＝{S1,S2,…,Sn}是具有相同超類G的一個子類集合，每個G/Si是一個超類/子類關系。G被稱為泛化實體類型。用“特化”指代由特化過程所獲得的--特化子集。特化的種類（約束）完全特化與部分特化；不相交特化與重疊特化。兩類約束相互獨立，可以組合出四種約束。泛化是特化的逆過程，允許我們忽略多個實體集之間的性質差異，找出它們的共同點－－抽象出超類。特化是概念上的求精，而泛化則是概念上的綜合。顯然，由泛化獲得超類方法，易得到完全特化的子集。16EER核心概念（2）特化特化是概念上的求精，而泛化則是概念上特化及其約束的EER表示17特化及其約束的EER表示17EER核心概念（3）類別(category)類別有時也被稱為union子類。類別T是一個類，它是n個判定超類D1,D2,…,Dn（n>1）并集的一個子集。其形式表示為：T?(D1?D2?…?Dn)union子類的約束完全約束：子類包含了其所有超類并集中的所有成員；部分約束：子類只包含并集的一個子集。18EER核心概念（3）類別(category)18UNION子類及其約束的EER表示（圖3.8）用粗/細區(qū)分完全和部分約束19UNION子類及其約束的EER表示（圖3.8）用粗/細區(qū)分基本ER模型與UML類圖的特性對比20基本ER模型與UML類圖的特性對比20CompanyDB模式的EER表示21CompanyDB模式的EER表示21CompanyDB模式的UML表示22CompanyDB模式的UML表示223.3邏輯數據庫設計:映射ER/EER模式到關系模式3.3.1映射常規(guī)實體集到關系表3.3.2映射關系集到關系表3.3.3映射弱實體集3.3.4映射帶有聚集關系的ER圖3.3.5映射EER擴展結構3.3.6ER模型至關系模型映射小結233.3邏輯數據庫設計:映射ER/EER模式到關系模式3.33.3映射ER/EER模式到關系模式ER/EER模型適合于初始階段、抽象層次較高的DB概念設計。給定一個概念設計模式(ER/EER圖)，現已有一套標準方法可將它們映射到關系DB模式，但這種轉換還只是近似的。DB模式：{一組表}+{約束集}基于SQL-92，我們尚無法捕獲隱含在ER/EER設計中的所有約束。本節(jié)我們將介紹從ER/EER模式創(chuàng)建關系模式的方法和過程。243.3映射ER/EER模式到關系模式ER/EER模型適合映射常規(guī)實體集到關系表一個常規(guī)實體集可直接地映射到一個關系表：將實體集的每個屬性，作為關系表的一個屬性。用SQL-92DDL建表語句基本上可以完全捕獲這些信息，包括域約束和主鍵約束。25映射常規(guī)實體集到關系表一個常規(guī)實體集可直接地映射到一個關系映射關系集到關系表（一）映射含鍵約束的關系集方法1：獨立關系表法映射關系集R到獨立的關系表R’。26映射關系集到關系表（一）映射含鍵約束的關系集26映射關系集到關系表（一）映射含鍵約束的關系集方法1：獨立關系表法方法2：外鍵方法將關系集的相關信息合并到具有鍵約束的參與實體集中（一對多關系的‘一’端）。27映射關系集到關系表（一）映射含鍵約束的關系集27映射關系集到關系表（一）映射含鍵約束的關系集方法1：獨立關系表法方法2：外鍵方法方法3：合并關系法若關系集的所有參與實體集都有鍵約束且都是完全參與。這時，也可合并所有參與實體集到一個關系。（二）在映射關系集時考慮參與約束圖3.9（a）中的Manages，除了鍵約束（每部門至多有一經理）外，還含有一完全參與約束（每部門至少需要有一經理）?？紤]到這一點，Dept_Mgr:ssn應設置NOTNULL。（三）無鍵約束和參與約束的關系集映射對這類關系集，一般只能用獨立關系表法(方法1)進行映射。28映射關系集到關系表（一）映射含鍵約束的關系集28映射弱實體集弱實體集總是參與一對多的二元關系，且有一個鍵約束和完全參與約束。前面討論的映射關系方法2（外鍵法）是一種較理想的轉換方法。但要考慮弱實體中只含有部分鍵這個情況。29映射弱實體集弱實體集總是參與一對多的二元關系，且有一個鍵約映射EER擴展結構－－多值/復合結構屬性關系模式不支持多值屬性，必須為關系模式中的每個多值屬性，分別創(chuàng)建一個獨立的關系。令關系模式為R，MA是R的一個多值屬性，為MA創(chuàng)建的關系表為M。M的屬性應包含R的主鍵屬性k，以便關聯(lián)到R。原關系模式R中可去掉多值屬性MA.令關系模式為R，CA是R的一個復合屬性。對于CA，有兩種建模方法：方法1：將復合屬性的每個結構成份，分別作為一個屬性，加到所屬的關系表中。方法2：為復合屬性CA單獨建立一個關系表。30映射EER擴展結構－－多值/復合結構屬性關系模式不支持多值映射EER擴展結構－－類層次結構映射處理EER圖中的ISA層次結構。假設超類C被特化為m個子類{S1,…,Sm}Attr(C)={k,a1,…,an}，PK(C)=k。方法1：映射超類和每個子類到一個不同的表。31映射EER擴展結構－－類層次結構映射處理EER圖中的ISA映射EER擴展結構－－類層次結構方法1：映射超類和每個子類到一個不同的表。方法2：僅創(chuàng)建子類關系表。為每個子類Si(1≤i≤m)創(chuàng)建一個關系Li，且有屬性Attr(Li)={k,a1,…,an}?{Si的其它專有屬性},PK(Li)=k。該方法只適用于超類完全參與的特化類型。方法3：僅創(chuàng)建含1個類標志屬性的單個關系。方法4：僅創(chuàng)建含m個類標志屬性的單個關系。該方法能適應子類有重疊特化的情況，但會產生大量的null值。32映射EER擴展結構－－類層次結構方法1：映射超類和每個子類映射EER:union子類（1）1）對超類實體集有各自不同鍵的情況在創(chuàng)建與union子類對應的關系表時，通常需要指定一個新的鍵屬性--代理鍵(surrogatekey)。2）對超類實體集有有相同鍵的情況這時，無需使用代理鍵。33映射EER:union子類（1）1）對超類實體集有各自ER模型至關系模型映射小結步驟1：映射常規(guī)實體集。步驟2：映射弱實體集。步驟3：映射ER模式中的關系集。步驟4：映射ER模式中的聚集關系集。步驟5：映射與EER模型相關的擴展結構。34ER模型至關系模型映射小結步驟1：映射常規(guī)實體集。343.4關系模型求精與規(guī)范化3.4.1模式求精問題3.4.2函數依賴3.4.3基本規(guī)范范式3.4.4無損分解與依賴保持分解3.4.5分解與規(guī)范化關系模式3.4.6多值依賴與第四規(guī)范353.4關系模型求精與規(guī)范化3.4.1模式求精問題3.4.1模式求精問題（綜述）模式求精的基本任務是基于分解技術，來處理初始關系模式中存在的問題。信息的冗余存儲是引發(fā)這些問題的根源。雖然分解能刪除冗余，但它也可能導致一些額外的問題，如信息損失或導致某些強制性約束丟失，必須慎重使用。（一）冗余可能引發(fā)問題浪費空間。更新異常。同樣的信息被存儲多份，如某份數據被更新，而其它份信息未做相應更新，就會造成DB數據的不一致。插入異常。如果不附帶冗余存儲一些相關的信息，新的信息可能無法存儲到DB中。刪除異常。刪除某信息時,可能會附帶刪掉一些不希望刪除的信息。363.4.1模式求精問題（綜述）模式求精的基本任務是基于分冗余可能引發(fā)問題舉例考慮Hourly_Emps(ssn,name,lot,rating,hourly_wages,ours_worked)縮寫為Hourly_Emps(SNLRWH)假定小時工資主要取決于員工等級，即給定R值，就可唯一確定W值。這是一個典型的函數依賴約束關系，它會導致存儲冗余，其副作用有多個方面：同等級員工對應的元組中，R/W信息完全相同。同樣的信息被存儲多次，浪費存儲空間。如果刪除了給定R值的所有元組，將丟失這組R/W所隱含的IC約束信息，這是一種刪除異常。無法單獨記錄員工等級與小時工資的R/W關系。這是一種插入異常。

37冗余可能引發(fā)問題舉例考慮Hourly_Emps37（二）利用分解技術消除冗余函數依賴約束(FDs)或其它相近的ICs可被用來識別冗余點，并給出處理冗余的指導性建議。分解技術的核心思想通過將原關系替換（分解）為一組更小關系，來解決冗余問題。

例如，通過將Hourly_Emps分解為如下的兩個小關系，就可以很好消除原有冗余引起的相關問題。Hourly_Emps2(ssn,name,lot,rating,hours_worked)Wages(rating,hourly_wage)38（二）利用分解技術消除冗余函數依賴約束(FDs)或其它相近的（三）分解可能引發(fā)的相關問題分解能很好解決冗余問題，但必須慎重使用，否則可能會帶來其它問題。在使用分解時，須反復提問以下兩個重要問題：我們的確需要分解一個關系嗎？對該問題，已有若干規(guī)范來幫助回答這個問題。一個給定的分解會引起那些其它問題？對該問題，可借助分解的兩個重要特性來幫助回答用無損連接(lossless-join)；依賴保持(dependency-preservasion)39（三）分解可能引發(fā)的相關問題分解能很好解決冗余問題，但必須慎3.4.2函數依賴(functionaldependency,FD)函數依賴，是DB中兩組屬性間存在的一種約束，是一類更廣義的鍵概念約束。其形式定義如下：令R代表一個關系模式，r是R的一個任意合法實例。X和Y是R的兩個非空屬性子集。如果對r中每個元組對t1和t2有t1.X=t2.X，則必有t1.Y=t2.Y。這時，我們就稱Y函數依賴于X，記為：XY。

兩類特殊的函數依賴完全函數依賴與部分函數依賴通常，模式設計者會顯式指定一組函數依賴。常用F表示在關系R上顯式指定的一組{FDs}。403.4.2函數依賴(functionaldependen函數依賴推理（1）在滿足F:{FDs}的所有合法關系實例中，通常還會隱含一些其它可從F推理獲得的函數依賴。例如，對Workers(ssn,name,lot,did,since)顯式FDsFD1:ssndid，FD2:didlot保持隱含FDs通過傳遞推理，不難發(fā)現：在Workers中，FD3:ssnlot也能保持的結論。定義（隱含函數依賴f）給定FDs集F，如果FD:f也能在滿足F的每個關系實例中保持，則稱FD:f是隱含在F中的函數依賴。定義（函數依賴集閉包F+）將包括給定的FDs集F，加上F所隱含的所有f,合稱為F閉包，簡記為F+。41函數依賴推理（1）在滿足F:{FDs}的所有合法關系實例中，函數依賴推理（2）由給定FDs集F，推導或計算出F+的規(guī)則自反規(guī)則IR1：如X?Y，則XY。增廣規(guī)則IR2：如XY，則XZYZ，Z是任意屬性組。傳遞規(guī)則IR3：如果XY,YZ，則XZ。兩增補規(guī)則：合并或加法規(guī)則IR4：如果XY,XZ，則XYZ。分解或投影規(guī)則IR5：如果XYZ，則XY,XZ。定義（平凡函數依賴）如果XY且X?Y，則稱XY是平凡的(trivial)。顯然，利用自反規(guī)則IR1，我們不難由已知的FDs推出所有的平凡依賴關系。42函數依賴推理（2）由給定FDs集F，推導或計算出F+的規(guī)函數依賴推理（3）定義（函數依賴集覆蓋）對于函數依賴集F，如果另一個函數依賴集E中的每個函數依賴同時也在F+中，則稱F覆蓋了E。定義（函數依賴集等價）對于兩個函數依賴集E和F，如果E+=F+，則稱E和F是等價的。定義（函數依賴集最小覆蓋）一個FDs集F的最小覆蓋是滿足以下三個條件的一組FDs集G:G中的每個依賴關系都是規(guī)范的XA形式，這里，A是一個單屬性；閉包F+等價于閉包G+。如果通過刪除G中的一個或多個依賴關系，或刪除G中依賴關系的屬性，得到另一個依賴集H，則必有H+≠G+。43函數依賴推理（3）定義（函數依賴集覆蓋）43計算所有隱含FDs的一個系統(tǒng)方法44計算所有隱含FDs的一個系統(tǒng)方法44尋找函數依賴集F的一個最小覆蓋G45尋找函數依賴集F的一個最小覆蓋G453.4.3基本規(guī)范范式（1）第一范式對于一個關系R，如果它的每個字段只包含不可分割的原子值（即沒有復合值或值集字段），則R滿足第一范式，記為R?1NF。1NF獨立于鍵和函數依賴；關系模型能自然滿足1NF約束。第二范式對于一個關系R，如果它的每個非鍵屬性A都完全依賴于R的某個鍵，則R滿足第二范式，記為R?2NF。463.4.3基本規(guī)范范式（1）第一范式463.4.3基本規(guī)范范式（2）Boyce-Codd范式令R是一關系模式，X和A分別是R的屬性子集。如果對R中保持的每個FD:XA，能至少滿足以下兩條件之一，就稱R滿足Boyce-Codd范式，簡記為R?BCNF。1)A?X，即XA是一個平凡的FD；2)X是一個超鍵?？勺C明：判斷R?BCNF,只需檢查F+中每個非平凡FD左邊是否為超鍵。直觀分析“滿足BCNF”的關系表BCNF能確保關系表在FD信息視角下無冗余。每個元組是“一個實體或一個關系”。每個字段都存儲著無法從其它字段(利用FD)推導出的信息值。BCNF關系中的非平凡FD結構模式473.4.3基本規(guī)范范式（2）Boyce-Codd范式基本規(guī)范范式（3）第三規(guī)范令R是一關系模式，X與A分別是R的屬性子集。如果對R中保持的每個FD:XA，能至少滿足以下三條件之一，就稱R滿足第三范式，簡記為R?3NF。A?X，即XA是一個平凡的FD；X是一個超鍵；A是R的部分鍵。3NF比BCNF多了第三個條件，也允許A是鍵的一部分。顯然，每個BCNF關系肯定是3NF關系48基本規(guī)范范式（3）第三規(guī)范48依賴關系XA違反3NF的兩種主要情形1）X是某鍵K的一個屬性子集。這時，依賴關系XA是部分依賴。這種情形下，存儲‘(X,A)對’是一種冗余情況,R2NF。2）X不是任何鍵K的完全屬性子集。這時，存在依賴鏈KXA，依賴關系XA是傳遞依賴。49依賴關系XA違反3NF的兩種主要情形1）X是某鍵K的一個屬3.4.4無損分解與依賴保持分解1.無損分解無損分解定義令R為一關系模式，F是R上的FDs集將R分解為兩個屬性組X和Y，如果對R的每個滿足F的實例r，滿足πx(r)?πy(r)=r，就稱該分解是無損連接的。無損分解應用將R分解為屬性組R1和R2是無損連接的，當且僅當R1∩R2R1或R1∩R2R2保持。舉例：Hourly_Emps(SNLRWH);FD:RW503.4.4無損分解與依賴保持分解1.無損分解50一個不滿足無損連接的分解示例（圖3.14）51一個不滿足無損連接的分解示例（圖3.14）513.4.4無損分解與依賴保持分解2.依賴保持分解定義（依賴集投影）令關系R被分解為兩個屬性組X和Y,F是R上保持的FDsF在X上的投影(FX):是F+中那些僅包含X中屬性的FDs依賴UV在Fx中，當且僅當U和V中的所有屬性都在X中。定義（依賴保持分解）帶有FDs集F的關系模式R，分解為X和Y兩個屬性組是依賴保持的，當且僅當(FX?FY)+=F+。依賴保持為什么考慮F閉包F+而不是F？523.4.4無損分解與依賴保持分解2.依賴保持分解523.4.5分解與規(guī)范化關系模式1.分解關系到BCNF533.4.5分解與規(guī)范化關系模式1.分解關系到BCNF533.4.5分解與規(guī)范化關系模式2.分解關系到3NF543.4.5分解與規(guī)范化關系模式2.分解關系到3NF54分解到BCNF與分解到3NF的實質差別對一個非BCNF的關系模式，通過無損連接分解，獲得一組滿足BCNF的關系模式總是可能的。但有可能不存在獲得一組BCNF關系的任何依賴保持分解。而將一個非BCNF關系分解為一組3NF關系的無損連接且依賴保持分解，則通?？偸谴嬖诘?。？55分解到BCNF與分解到3NF的實質差別對一個非BCNF的關系 謝謝大家！ 謝謝大家！56第3章數據庫設計第3章數據庫設計57第3章數據庫設計ER數據模型3.1EER數據模型3.2邏輯數據庫設計：映射ER/EER模式到關系模式3.3關系模式求精與規(guī)范化3.458第3章數據庫設計ER數據模型3.1EER數據模型3.2邏輯DB應用DB應用定義：一個特定的數據庫，加上實現此數據庫查詢/更新的相關程序。概念設計是成功設計DB應用的一個環(huán)節(jié)。實體-關系模型(Entity-Relationmodel)，簡稱ER模型，是一種非常流行的概念數據模型。EER是基于ER的擴展模型(EnhancedERmodel)ER/EER已被廣泛應用于DB概念設計。它們均以圖形化方式描述和捕獲用戶需求?；贓R/EER進行概念設計的輸出為一組ER/EER圖。基于概念模型的設計，最終都必須變換/轉換到可在DB中實現的邏輯數據模型。借助RDB設計有關規(guī)范理論,不僅可對轉換后的邏輯數據模式進行規(guī)范，而且可對ER/EER圖進行求精。59DB應用DB應用定義：一個特定的數據庫，加上實現此數據庫查詢DB設計的主要階段與過程60DB設計的主要階段與過程4DB設計的基本步驟（1）1.需求分析2.概念DB設計利用需求分析獲得的信息，建立DB數據的一個抽象描述。這一步通常利用ER/EER模型，或其它高級數據概念模型（如UML類圖），來實現。3.邏輯DB設計轉換DB概念設計模式到指定DBMS邏輯模式。由于需求信息本身帶有很大主觀性，故基于需求信息構造的ER/EER圖只能提供數據的一個近似描述。4.模式細化5.物理DB設計6.安全設計61DB設計的基本步驟（1）1.需求分析5DB設計的基本步驟（2）1.需求分析2.概念DB設計3.邏輯DB設計4.模式細化分析關系數據庫模式的關系集，檢查潛在問題并進行優(yōu)化。與需求分析和概念設計的主觀性特點不同，細化可得到強有力的規(guī)范理論支持。5.物理DB設計考慮應用必須支持的一些典型預期負荷,并以此為基礎進一步求精DB設計，確保它能滿足預期的性能要求。這個步驟可能包括為一些表建立索引，或指定聚集存儲方式等。6.安全設計62DB設計的基本步驟（2）1.需求分析63.1ER數據模型3.1.1實體類型、實體集、屬性和鍵3.1.2關系、關系類型和關系集3.1.3ER模型的其他特性633.1ER數據模型3.1.1實體類型、實體集、屬性和鍵ER模型簡介1.構成ER模型的基本概念實體與屬性實體類型、實體集與鍵實體類型：定義了具有相同屬性的實體模式結構，由名和屬性來描述。實體集：具有相同實體類型的所有實體集合。實體類型描述了相同結構實體集的模式或內涵；實體集則描述了實體類型的外延。ER圖中不區(qū)分實體類型和實體集（被視為同義詞）。關系、關系類型和關系集ER模型的其它概念☆ER圖表示規(guī)定實體集：用加矩形外框的名字來表示。屬性名：則用橢圓框起，并用直線與實體集相連。多值屬性：用雙線橢圓框起;復合屬性：用名字后加注結構成份表示;鍵屬性：通過屬性名加下劃線來標識。

☆ER圖表示規(guī)定關系集：用名字外加菱形框表示，并用直線將其與參與實體集的矩形框相連。64ER模型簡介1.構成ER模型的基本概念☆ER圖表示規(guī)定ER圖設計舉例（1）65ER圖設計舉例（1）9ER圖設計舉例（2）66ER圖設計舉例（2）10ER模型的其它概念關系屬性關系集也可以有自己的描述屬性，用來刻畫關系集本身的性質，而不是某個參與實體集的性質。關系約束指與關系集相關的約束，通過約束表達可限制參與關系各實體的可能組合。主要類型：基數詞約束、鍵約束和參與約束。弱實體集指只能附屬其它實體集而存在的實體集。67ER模型的其它概念關系屬性11在ER圖中表達關系基數詞和參與約束68在ER圖中表達關系基數詞和參與約束12弱實體集的幾種ER建模方法（圖3.5)69弱實體集的幾種ER建模方法（圖3.5)133.2EER數據模型3.2.1EER模型核心概念的形式定義3.2.2子類、超類與類層次結構3.2.3特化與泛化3.2.4利用union子類建模3.2.5值集屬性與復合結構屬性的建模表示3.2.6EER與UML類圖比較3.2.7EER作為知識表示模型3.2.8為大型企業(yè)/組織進行DB概念設計703.2EER數據模型3.2.1EER模型核心概念的形式定EER核心概念（1）類指實體的集合或實體集，這包括可對DB應用域實體分組的任何EER模式構造，如實體類(型)、子類、超類和類別。EER中，任何類都允許參與一個關系。子類、超類子類S是一個類，子類中的實體必然是其超類C中實體的一個子集，即有關系：S?C成立超類/子類關系也稱為ISA關系，記做C/S。子類實體除了可以從超類實體中繼承所有的屬性外，還可以有自己專有的屬性和關系。71EER核心概念（1）類15EER核心概念（2）特化特化Z＝{S1,S2,…,Sn}是具有相同超類G的一個子類集合，每個G/Si是一個超類/子類關系。G被稱為泛化實體類型。用“特化”指代由特化過程所獲得的--特化子集。特化的種類（約束）完全特化與部分特化；不相交特化與重疊特化。兩類約束相互獨立，可以組合出四種約束。泛化是特化的逆過程，允許我們忽略多個實體集之間的性質差異，找出它們的共同點－－抽象出超類。特化是概念上的求精，而泛化則是概念上的綜合。顯然，由泛化獲得超類方法，易得到完全特化的子集。72EER核心概念（2）特化特化是概念上的求精，而泛化則是概念上特化及其約束的EER表示73特化及其約束的EER表示17EER核心概念（3）類別(category)類別有時也被稱為union子類。類別T是一個類，它是n個判定超類D1,D2,…,Dn（n>1）并集的一個子集。其形式表示為：T?(D1?D2?…?Dn)union子類的約束完全約束：子類包含了其所有超類并集中的所有成員；部分約束：子類只包含并集的一個子集。74EER核心概念（3）類別(category)18UNION子類及其約束的EER表示（圖3.8）用粗/細區(qū)分完全和部分約束75UNION子類及其約束的EER表示（圖3.8）用粗/細區(qū)分基本ER模型與UML類圖的特性對比76基本ER模型與UML類圖的特性對比20CompanyDB模式的EER表示77CompanyDB模式的EER表示21CompanyDB模式的UML表示78CompanyDB模式的UML表示223.3邏輯數據庫設計:映射ER/EER模式到關系模式3.3.1映射常規(guī)實體集到關系表3.3.2映射關系集到關系表3.3.3映射弱實體集3.3.4映射帶有聚集關系的ER圖3.3.5映射EER擴展結構3.3.6ER模型至關系模型映射小結793.3邏輯數據庫設計:映射ER/EER模式到關系模式3.33.3映射ER/EER模式到關系模式ER/EER模型適合于初始階段、抽象層次較高的DB概念設計。給定一個概念設計模式(ER/EER圖)，現已有一套標準方法可將它們映射到關系DB模式，但這種轉換還只是近似的。DB模式：{一組表}+{約束集}基于SQL-92，我們尚無法捕獲隱含在ER/EER設計中的所有約束。本節(jié)我們將介紹從ER/EER模式創(chuàng)建關系模式的方法和過程。803.3映射ER/EER模式到關系模式ER/EER模型適合映射常規(guī)實體集到關系表一個常規(guī)實體集可直接地映射到一個關系表：將實體集的每個屬性，作為關系表的一個屬性。用SQL-92DDL建表語句基本上可以完全捕獲這些信息，包括域約束和主鍵約束。81映射常規(guī)實體集到關系表一個常規(guī)實體集可直接地映射到一個關系映射關系集到關系表（一）映射含鍵約束的關系集方法1：獨立關系表法映射關系集R到獨立的關系表R’。82映射關系集到關系表（一）映射含鍵約束的關系集26映射關系集到關系表（一）映射含鍵約束的關系集方法1：獨立關系表法方法2：外鍵方法將關系集的相關信息合并到具有鍵約束的參與實體集中（一對多關系的‘一’端）。83映射關系集到關系表（一）映射含鍵約束的關系集27映射關系集到關系表（一）映射含鍵約束的關系集方法1：獨立關系表法方法2：外鍵方法方法3：合并關系法若關系集的所有參與實體集都有鍵約束且都是完全參與。這時，也可合并所有參與實體集到一個關系。（二）在映射關系集時考慮參與約束圖3.9（a）中的Manages，除了鍵約束（每部門至多有一經理）外，還含有一完全參與約束（每部門至少需要有一經理）?？紤]到這一點，Dept_Mgr:ssn應設置NOTNULL。（三）無鍵約束和參與約束的關系集映射對這類關系集，一般只能用獨立關系表法(方法1)進行映射。84映射關系集到關系表（一）映射含鍵約束的關系集28映射弱實體集弱實體集總是參與一對多的二元關系，且有一個鍵約束和完全參與約束。前面討論的映射關系方法2（外鍵法）是一種較理想的轉換方法。但要考慮弱實體中只含有部分鍵這個情況。85映射弱實體集弱實體集總是參與一對多的二元關系，且有一個鍵約映射EER擴展結構－－多值/復合結構屬性關系模式不支持多值屬性，必須為關系模式中的每個多值屬性，分別創(chuàng)建一個獨立的關系。令關系模式為R，MA是R的一個多值屬性，為MA創(chuàng)建的關系表為M。M的屬性應包含R的主鍵屬性k，以便關聯(lián)到R。原關系模式R中可去掉多值屬性MA.令關系模式為R，CA是R的一個復合屬性。對于CA，有兩種建模方法：方法1：將復合屬性的每個結構成份，分別作為一個屬性，加到所屬的關系表中。方法2：為復合屬性CA單獨建立一個關系表。86映射EER擴展結構－－多值/復合結構屬性關系模式不支持多值映射EER擴展結構－－類層次結構映射處理EER圖中的ISA層次結構。假設超類C被特化為m個子類{S1,…,Sm}Attr(C)={k,a1,…,an}，PK(C)=k。方法1：映射超類和每個子類到一個不同的表。87映射EER擴展結構－－類層次結構映射處理EER圖中的ISA映射EER擴展結構－－類層次結構方法1：映射超類和每個子類到一個不同的表。方法2：僅創(chuàng)建子類關系表。為每個子類Si(1≤i≤m)創(chuàng)建一個關系Li，且有屬性Attr(Li)={k,a1,…,an}?{Si的其它專有屬性},PK(Li)=k。該方法只適用于超類完全參與的特化類型。方法3：僅創(chuàng)建含1個類標志屬性的單個關系。方法4：僅創(chuàng)建含m個類標志屬性的單個關系。該方法能適應子類有重疊特化的情況，但會產生大量的null值。88映射EER擴展結構－－類層次結構方法1：映射超類和每個子類映射EER:union子類（1）1）對超類實體集有各自不同鍵的情況在創(chuàng)建與union子類對應的關系表時，通常需要指定一個新的鍵屬性--代理鍵(surrogatekey)。2）對超類實體集有有相同鍵的情況這時，無需使用代理鍵。89映射EER:union子類（1）1）對超類實體集有各自ER模型至關系模型映射小結步驟1：映射常規(guī)實體集。步驟2：映射弱實體集。步驟3：映射ER模式中的關系集。步驟4：映射ER模式中的聚集關系集。步驟5：映射與EER模型相關的擴展結構。90ER模型至關系模型映射小結步驟1：映射常規(guī)實體集。343.4關系模型求精與規(guī)范化3.4.1模式求精問題3.4.2函數依賴3.4.3基本規(guī)范范式3.4.4無損分解與依賴保持分解3.4.5分解與規(guī)范化關系模式3.4.6多值依賴與第四規(guī)范913.4關系模型求精與規(guī)范化3.4.1模式求精問題3.4.1模式求精問題（綜述）模式求精的基本任務是基于分解技術，來處理初始關系模式中存在的問題。信息的冗余存儲是引發(fā)這些問題的根源。雖然分解能刪除冗余，但它也可能導致一些額外的問題，如信息損失或導致某些強制性約束丟失，必須慎重使用。（一）冗余可能引發(fā)問題浪費空間。更新異常。同樣的信息被存儲多份，如某份數據被更新，而其它份信息未做相應更新，就會造成DB數據的不一致。插入異常。如果不附帶冗余存儲一些相關的信息，新的信息可能無法存儲到DB中。刪除異常。刪除某信息時,可能會附帶刪掉一些不希望刪除的信息。923.4.1模式求精問題（綜述）模式求精的基本任務是基于分冗余可能引發(fā)問題舉例考慮Hourly_Emps(ssn,name,lot,rating,hourly_wages,ours_worked)縮寫為Hourly_Emps(SNLRWH)假定小時工資主要取決于員工等級，即給定R值，就可唯一確定W值。這是一個典型的函數依賴約束關系，它會導致存儲冗余，其副作用有多個方面：同等級員工對應的元組中，R/W信息完全相同。同樣的信息被存儲多次，浪費存儲空間。如果刪除了給定R值的所有元組，將丟失這組R/W所隱含的IC約束信息，這是一種刪除異常。無法單獨記錄員工等級與小時工資的R/W關系。這是一種插入異常。

93冗余可能引發(fā)問題舉例考慮Hourly_Emps37（二）利用分解技術消除冗余函數依賴約束(FDs)或其它相近的ICs可被用來識別冗余點，并給出處理冗余的指導性建議。分解技術的核心思想通過將原關系替換（分解）為一組更小關系，來解決冗余問題。

例如，通過將Hourly_Emps分解為如下的兩個小關系，就可以很好消除原有冗余引起的相關問題。Hourly_Emps2(ssn,name,lot,rating,hours_worked)Wages(rating,hourly_wage)94（二）利用分解技術消除冗余函數依賴約束(FDs)或其它相近的（三）分解可能引發(fā)的相關問題分解能很好解決冗余問題，但必須慎重使用，否則可能會帶來其它問題。在使用分解時，須反復提問以下兩個重要問題：我們的確需要分解一個關系嗎？對該問題，已有若干規(guī)范來幫助回答這個問題。一個給定的分解會引起那些其它問題？對該問題，可借助分解的兩個重要特性來幫助回答用無損連接(lossless-join)；依賴保持(dependency-preservasion)95（三）分解可能引發(fā)的相關問題分解能很好解決冗余問題，但必須慎3.4.2函數依賴(functionaldependency,FD)函數依賴，是DB中兩組屬性間存在的一種約束，是一類更廣義的鍵概念約束。其形式定義如下：令R代表一個關系模式，r是R的一個任意合法實例。X和Y是R的兩個非空屬性子集。如果對r中每個元組對t1和t2有t1.X=t2.X，則必有t1.Y=t2.Y。這時，我們就稱Y函數依賴于X，記為：XY。

兩類特殊的函數依賴完全函數依賴與部分函數依賴通常，模式設計者會顯式指定一組函數依賴。常用F表示在關系R上顯式指定的一組{FDs}。963.4.2函數依賴(functionaldependen函數依賴推理（1）在滿足F:{FDs}的所有合法關系實例中，通常還會隱含一些其它可從F推理獲得的函數依賴。例如，對Workers(ssn,name,lot,did,since)顯式FDsFD1:ssndid，FD2:didlot保持隱含FDs通過傳遞推理，不難發(fā)現：在Workers中，FD3:ssnlot也能保持的結論。定義（隱含函數依賴f）給定FDs集F，如果FD:f也能在滿足F的每個關系實例中保持，則稱FD:f是隱含在F中的函數依賴。定義（函數依賴集閉包F+）將包括給定的FDs集F，加上F所隱含的所有f,合稱為F閉包，簡記為F+。97函數依賴推理（1）在滿足F:{FDs}的所有合法關系實例中，函數依賴推理（2）由給定FDs集F，推導或計算出F+的規(guī)則自反規(guī)則IR1：如X?Y，則XY。增廣規(guī)則IR2：如XY，則XZYZ，Z是任意屬性組。傳遞規(guī)則IR3：如果XY,YZ，則XZ。兩增補規(guī)則：合并或加法規(guī)則IR4：如果XY,XZ，則XYZ。分解或投影規(guī)則IR5：如果XYZ，則XY,XZ。定義（平凡函數依賴）如果XY且X?Y，則稱XY是平凡的(trivial)。顯然，利用自反規(guī)則IR1，我們不難由已知的FDs推出所有的平凡依賴關系。98函數依賴推理（2）由給定FDs集F，推導或計算出F+的規(guī)函數依賴推理（3）定義（函數依賴集覆蓋）對于函數依賴集F，如果另一個函數依賴集E中的每個函數依賴同時也在F+中，則稱F覆蓋了E。定義（函數依賴集等價）對于兩個函數依賴集E和F，如果E+=F+，則稱E和F是等價的。定義（函數依賴集最小覆蓋）一個FDs集F的最小覆蓋是滿足以下三個條件的一組FDs集G:G中的每個依賴關系都是規(guī)范的XA形式，這里，A是一個單屬性；閉包F+等價于閉包G+。如果通過刪除G中的一個或多個依賴關系，或刪除G中依賴關系的屬性，得到另一個依賴集H，則必有H+≠G+。99函數依賴推理（3）定義（函數依賴集覆蓋）43計算所有隱含FDs的一個系統(tǒng)方法100計算所有隱含FDs的一個系統(tǒng)方法44尋找函數依賴集F的一個最小覆