《《數(shù)據(jù)庫設計》PPT課件.ppt》由會員分享，可在線閱讀，更多相關《《數(shù)據(jù)庫設計》PPT課件.ppt（55頁珍藏版）》請在裝配圖網(wǎng)上搜索。

第1部分數(shù)據(jù)庫系統(tǒng)基礎第3章數(shù)據(jù)庫設計 高級數(shù)據(jù)庫系統(tǒng)及其應用 第3章數(shù)據(jù)庫設計 ER數(shù)據(jù)模型 3 1 EER數(shù)據(jù)模型 3 2 邏輯數(shù)據(jù)庫設計 映射ER EER模式到關系模式 3 3 關系模式求精與規(guī)范化 3 4 DB應用 DB應用定義 一個特定的數(shù)據(jù)庫 加上實現(xiàn)此數(shù)據(jù)庫查詢 更新的相關程序 概念設計是成功設計DB應用的一個環(huán)節(jié) 實體 關系模型 Entity Relationmodel 簡稱ER模型 是一種非常流行的概念數(shù)據(jù)模型 EER是基于ER的擴展模型 EnhancedERmodel ER EER已被廣泛應用于DB概念設計 它們均以圖形化方式描述和捕獲用戶需求 基于ER EER進行概念設計的輸出為一組ER EER圖 基于概念模型的設計 最終都必須變換 轉換到可在DB中實現(xiàn)的邏輯數(shù)據(jù)模型 借助RDB設計有關規(guī)范理論 不僅可對轉換后的邏輯數(shù)據(jù)模式進行規(guī)范 而且可對ER EER圖進行求精 DB設計的主要階段與過程 DB設計的基本步驟 1 1 需求分析2 概念DB設計利用需求分析獲得的信息 建立DB數(shù)據(jù)的一個抽象描述 這一步通常利用ER EER模型 或其它高級數(shù)據(jù)概念模型 如UML類圖 來實現(xiàn) 3 邏輯DB設計轉換DB概念設計模式到指定DBMS邏輯模式 由于需求信息本身帶有很大主觀性 故基于需求信息構造的ER EER圖只能提供數(shù)據(jù)的一個近似描述 4 模式細化5 物理DB設計6 安全設計 DB設計的基本步驟 2 1 需求分析2 概念DB設計3 邏輯DB設計4 模式細化分析關系數(shù)據(jù)庫模式的關系集 檢查潛在問題并進行優(yōu)化 與需求分析和概念設計的主觀性特點不同 細化可得到強有力的規(guī)范理論支持 5 物理DB設計考慮應用必須支持的一些典型預期負荷 并以此為基礎進一步求精DB設計 確保它能滿足預期的性能要求 這個步驟可能包括為一些表建立索引 或指定聚集存儲方式等 6 安全設計 3 1ER數(shù)據(jù)模型 3 1 1實體類型 實體集 屬性和鍵 3 1 2關系 關系類型和關系集 3 1 3ER模型的其他特性 ER模型簡介 1 構成ER模型的基本概念實體與屬性實體類型 實體集與鍵實體類型 定義了具有相同屬性的實體模式結構 由名和屬性來描述 實體集 具有相同實體類型的所有實體集合 實體類型描述了相同結構實體集的模式或內(nèi)涵 實體集則描述了實體類型的外延 ER圖中不區(qū)分實體類型和實體集 被視為同義詞 關系 關系類型和關系集ER模型的其它概念 ER圖表示規(guī)定實體集 用加矩形外框的名字來表示 屬性名 則用橢圓框起 并用直線與實體集相連 多值屬性 用雙線橢圓框起 復合屬性 用名字后加注結構成份表示 鍵屬性 通過屬性名加下劃線來標識 ER圖表示規(guī)定關系集 用名字外加菱形框表示 并用直線將其與參與實體集的矩形框相連 ER圖設計舉例 1 ER圖設計舉例 2 ER模型的其它概念 關系屬性關系集也可以有自己的描述屬性 用來刻畫關系集本身的性質 而不是某個參與實體集的性質 關系約束指與關系集相關的約束 通過約束表達可限制參與關系各實體的可能組合 主要類型 基數(shù)詞約束 鍵約束和參與約束 弱實體集指只能附屬其它實體集而存在的實體集 在ER圖中表達關系基數(shù)詞和參與約束 弱實體集的幾種ER建模方法 圖3 5 3 2EER數(shù)據(jù)模型 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概念設計 EER核心概念 1 類指實體的集合或實體集 這包括可對DB應用域實體分組的任何EER模式構造 如實體類 型 子類 超類和類別 EER中 任何類都允許參與一個關系 子類 超類子類S是一個類 子類中的實體必然是其超類C中實體的一個子集 即有關系 S C成立超類 子類關系也稱為ISA關系 記做C S 子類實體除了可以從超類實體中繼承所有的屬性外 還可以有自己專有的屬性和關系 EER核心概念 2 特化特化Z S1 S2 Sn 是具有相同超類G的一個子類集合 每個G Si是一個超類 子類關系 G被稱為泛化實體類型 用 特化 指代由特化過程所獲得的 特化子集 特化的種類 約束 完全特化與部分特化 不相交特化與重疊特化 兩類約束相互獨立 可以組合出四種約束 泛化是特化的逆過程 允許我們忽略多個實體集之間的性質差異 找出它們的共同點 抽象出超類 特化是概念上的求精 而泛化則是概念上的綜合 顯然 由泛化獲得超類方法 易得到完全特化的子集 特化及其約束的EER表示 EER核心概念 3 類別 category 類別有時也被稱為union子類 類別T是一個類 它是n個判定超類D1 D2 Dn n 1 并集的一個子集 其形式表示為 T D1 D2 Dn union子類的約束完全約束 子類包含了其所有超類并集中的所有成員 部分約束 子類只包含并集的一個子集 UNION子類及其約束的EER表示 圖3 8 基本ER模型與UML類圖的特性對比 CompanyDB模式的EER表示 CompanyDB模式的UML表示 3 3邏輯數(shù)據(jù)庫設計 映射ER EER模式到關系模式 3 3 1映射常規(guī)實體集到關系表 3 3 2映射關系集到關系表 3 3 3映射弱實體集 3 3 4映射帶有聚集關系的ER圖 3 3 5映射EER擴展結構 3 3 6ER模型至關系模型映射小結 3 3映射ER EER模式到關系模式 ER EER模型適合于初始階段 抽象層次較高的DB概念設計 給定一個概念設計模式 ER EER圖 現(xiàn)已有一套標準方法可將它們映射到關系DB模式 但這種轉換還只是近似的 DB模式 一組表 約束集 基于SQL 92 我們尚無法捕獲隱含在ER EER設計中的所有約束 本節(jié)我們將介紹從ER EER模式創(chuàng)建關系模式的方法和過程 映射常規(guī)實體集到關系表 一個常規(guī)實體集可直接地映射到一個關系表 將實體集的每個屬性 作為關系表的一個屬性 用SQL 92DDL建表語句基本上可以完全捕獲這些信息 包括域約束和主鍵約束 映射關系集到關系表 一 映射含鍵約束的關系集方法1 獨立關系表法映射關系集R到獨立的關系表R 映射關系集到關系表 一 映射含鍵約束的關系集方法1 獨立關系表法方法2 外鍵方法將關系集的相關信息合并到具有鍵約束的參與實體集中 一對多關系的 一 端 映射關系集到關系表 一 映射含鍵約束的關系集方法1 獨立關系表法方法2 外鍵方法方法3 合并關系法若關系集的所有參與實體集都有鍵約束且都是完全參與 這時 也可合并所有參與實體集到一個關系 二 在映射關系集時考慮參與約束圖3 9 a 中的Manages 除了鍵約束 每部門至多有一經(jīng)理 外 還含有一完全參與約束 每部門至少需要有一經(jīng)理 考慮到這一點 Dept Mgr ssn應設置NOTNULL 三 無鍵約束和參與約束的關系集映射對這類關系集 一般只能用獨立關系表法 方法1 進行映射 映射弱實體集 弱實體集總是參與一對多的二元關系 且有一個鍵約束和完全參與約束 前面討論的映射關系方法2 外鍵法 是一種較理想的轉換方法 但要考慮弱實體中只含有部分鍵這個情況 映射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單獨建立一個關系表 映射EER擴展結構 類層次結構 映射處理EER圖中的ISA層次結構 假設超類C被特化為m個子類 S1 Sm Attr C k a1 an PK C k 方法1 映射超類和每個子類到一個不同的表 映射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個類標志屬性的單個關系 該方法能適應子類有重疊特化的情況 但會產(chǎn)生大量的null值 映射EER union子類 1 1 對超類實體集有各自不同鍵的情況在創(chuàng)建與union子類對應的關系表時 通常需要指定一個新的鍵屬性 代理鍵 surrogatekey 2 對超類實體集有有相同鍵的情況這時 無需使用代理鍵 ER模型至關系模型映射小結 步驟1 映射常規(guī)實體集 步驟2 映射弱實體集 步驟3 映射ER模式中的關系集 步驟4 映射ER模式中的聚集關系集 步驟5 映射與EER模型相關的擴展結構 3 4關系模型求精與規(guī)范化 3 4 1模式求精問題 3 4 2函數(shù)依賴 3 4 3基本規(guī)范范式 3 4 4無損分解與依賴保持分解 3 4 5分解與規(guī)范化關系模式 3 4 6多值依賴與第四規(guī)范 3 4 1模式求精問題 綜述 模式求精的基本任務是基于分解技術 來處理初始關系模式中存在的問題 信息的冗余存儲是引發(fā)這些問題的根源 雖然分解能刪除冗余 但它也可能導致一些額外的問題 如信息損失或導致某些強制性約束丟失 必須慎重使用 一 冗余可能引發(fā)問題浪費空間 更新異常 同樣的信息被存儲多份 如某份數(shù)據(jù)被更新 而其它份信息未做相應更新 就會造成DB數(shù)據(jù)的不一致 插入異常 如果不附帶冗余存儲一些相關的信息 新的信息可能無法存儲到DB中 刪除異常 刪除某信息時 可能會附帶刪掉一些不希望刪除的信息 冗余可能引發(fā)問題舉例 考慮Hourly Emps ssn name lot rating hourly wages ours worked 縮寫為Hourly Emps SNLRWH 假定小時工資主要取決于員工等級 即給定R值 就可唯一確定W值 這是一個典型的函數(shù)依賴約束關系 它會導致存儲冗余 其副作用有多個方面 同等級員工對應的元組中 R W信息完全相同 同樣的信息被存儲多次 浪費存儲空間 如果刪除了給定R值的所有元組 將丟失這組R W所隱含的IC約束信息 這是一種刪除異常 無法單獨記錄員工等級與小時工資的R W關系 這是一種插入異常 二 利用分解技術消除冗余 函數(shù)依賴約束 FDs 或其它相近的ICs可被用來識別冗余點 并給出處理冗余的指導性建議 分解技術的核心思想通過將原關系替換 分解 為一組更小關系 來解決冗余問題 例如 通過將Hourly Emps分解為如下的兩個小關系 就可以很好消除原有冗余引起的相關問題 Hourly Emps2 ssn name lot rating hours worked Wages rating hourly wage 三 分解可能引發(fā)的相關問題 分解能很好解決冗余問題 但必須慎重使用 否則可能會帶來其它問題 在使用分解時 須反復提問以下兩個重要問題 我們的確需要分解一個關系嗎 對該問題 已有若干規(guī)范來幫助回答這個問題 一個給定的分解會引起那些其它問題 對該問題 可借助分解的兩個重要特性來幫助回答用無損連接 lossless join 依賴保持 dependency preservasion 3 4 2函數(shù)依賴 functionaldependency FD 函數(shù)依賴 是DB中兩組屬性間存在的一種約束 是一類更廣義的鍵概念約束 其形式定義如下 令R代表一個關系模式 r是R的一個任意合法實例 X和Y是R的兩個非空屬性子集 如果對r中每個元組對t1和t2有t1 X t2 X 則必有t1 Y t2 Y 這時 我們就稱Y函數(shù)依賴于X 記為 X Y 兩類特殊的函數(shù)依賴完全函數(shù)依賴與部分函數(shù)依賴通常 模式設計者會顯式指定一組函數(shù)依賴 常用F表示在關系R上顯式指定的一組 FDs 函數(shù)依賴推理 1 在滿足F FDs 的所有合法關系實例中 通常還會隱含一些其它可從F推理獲得的函數(shù)依賴 例如 對Workers ssn name lot did since 顯式FDsFD1 ssn did FD2 did lot保持隱含F(xiàn)Ds通過傳遞推理 不難發(fā)現(xiàn) 在Workers中 FD3 ssn lot也能保持的結論 定義 隱含函數(shù)依賴f 給定FDs集F 如果FD f也能在滿足F的每個關系實例中保持 則稱FD f是隱含在F中的函數(shù)依賴 定義 函數(shù)依賴集閉包F 將包括給定的FDs集F 加上F所隱含的所有f 合稱為F閉包 簡記為F 函數(shù)依賴推理 2 由給定FDs集F 推導或計算出F 的規(guī)則自反規(guī)則IR1 如X Y 則X Y 增廣規(guī)則IR2 如X Y 則XZ YZ Z是任意屬性組 傳遞規(guī)則IR3 如果X Y Y Z 則X Z 兩增補規(guī)則 合并或加法規(guī)則IR4 如果X Y X Z 則X YZ 分解或投影規(guī)則IR5 如果X YZ 則X Y X Z 定義 平凡函數(shù)依賴 如果X Y且X Y 則稱X Y是平凡的 trivial 顯然 利用自反規(guī)則IR1 我們不難由已知的FDs推出所有的平凡依賴關系 函數(shù)依賴推理 3 定義 函數(shù)依賴集覆蓋 對于函數(shù)依賴集F 如果另一個函數(shù)依賴集E中的每個函數(shù)依賴同時也在F 中 則稱F覆蓋了E 定義 函數(shù)依賴集等價 對于兩個函數(shù)依賴集E和F 如果E F 則稱E和F是等價的 定義 函數(shù)依賴集最小覆蓋 一個FDs集F的最小覆蓋是滿足以下三個條件的一組FDs集G G中的每個依賴關系都是規(guī)范的X A形式 這里 A是一個單屬性 閉包F 等價于閉包G 如果通過刪除G中的一個或多個依賴關系 或刪除G中依賴關系的屬性 得到另一個依賴集H 則必有H G 計算所有隱含F(xiàn)Ds的一個系統(tǒng)方法 尋找函數(shù)依賴集F的一個最小覆蓋G 3 4 3基本規(guī)范范式 1 第一范式對于一個關系R 如果它的每個字段只包含不可分割的原子值 即沒有復合值或值集字段 則R滿足第一范式 記為R 1NF 1NF獨立于鍵和函數(shù)依賴 關系模型能自然滿足1NF約束 第二范式對于一個關系R 如果它的每個非鍵屬性A都完全依賴于R的某個鍵 則R滿足第二范式 記為R 2NF 3 4 3基本規(guī)范范式 2 Boyce Codd范式令R是一關系模式 X和A分別是R的屬性子集 如果對R中保持的每個FD X A 能至少滿足以下兩條件之一 就稱R滿足Boyce Codd范式 簡記為R BCNF 1 A X 即X A是一個平凡的FD 2 X是一個超鍵 可證明 判斷R BCNF 只需檢查F 中每個非平凡FD左邊是否為超鍵 直觀分析 滿足BCNF 的關系表BCNF能確保關系表在FD信息視角下無冗余 每個元組是 一個實體或一個關系 每個字段都存儲著無法從其它字段 利用FD 推導出的信息值 基本規(guī)范范式 3 第三規(guī)范令R是一關系模式 X與A分別是R的屬性子集 如果對R中保持的每個FD X A 能至少滿足以下三條件之一 就稱R滿足第三范式 簡記為R 3NF A X 即X A是一個平凡的FD X是一個超鍵 A是R的部分鍵 3NF比BCNF多了第三個條件 也允許A是鍵的一部分 顯然 每個BCNF關系肯定是3NF關系 依賴關系X A違反3NF的兩種主要情形 1 X是某鍵K的一個屬性子集 這時 依賴關系X A是部分依賴 這種情形下 存儲 X A 對 是一種冗余情況 R 2NF 2 X不是任何鍵K的完全屬性子集 這時 存在依賴鏈K X A 依賴關系X A是傳遞依賴 3 4 4無損分解與依賴保持分解 1 無損分解無損分解定義令R為一關系模式 F是R上的FDs集將R分解為兩個屬性組X和Y 如果對R的每個滿足F的實例r 滿足 x r y r r 就稱該分解是無損連接的 無損分解應用將R分解為屬性組R1和R2是無損連接的 當且僅當R1 R2 R1或R1 R2 R2保持 舉例 Hourly Emps SNLRWH FD R W 一個不滿足無損連接的分解示例 圖3 14 3 4 4無損分解與依賴保持分解 2 依賴保持分解定義 依賴集投影 令關系R被分解為兩個屬性組X和Y F是R上保持的FDsF在X上的投影 FX 是F 中那些僅包含X中屬性的FDs依賴U V在Fx中 當且僅當U和V中的所有屬性都在X中 定義 依賴保持分解 帶有FDs集F的關系模式R 分解為X和Y兩個屬性組是依賴保持的 當且僅當 FX FY F 依賴保持為什么考慮F閉包F 而不是F 3 4 5分解與規(guī)范化關系模式 1 分解關系到BCNF 3 4 5分解與規(guī)范化關系模式 2 分解關系到3NF 分解到BCNF與分解到3NF的實質差別 對一個非BCNF的關系模式 通過無損連接分解 獲得一組滿足BCNF的關系模式總是可能的 但有可能不存在獲得一組BCNF關系的任何依賴保持分解 而將一個非BCNF關系分解為一組3NF關系的無損連接且依賴保持分解 則通?？偸谴嬖诘?