第二章數據庫設計

Yusn_cu第2章數據庫設計2.1數據庫設計概述什么是數據庫設計？廣義的講是數據庫及其應用系統的設計，即設計整個的數據庫應用系統。俠義的講是設計數據庫本身。具體地說，是指對于一個給定的應用環境，構造最優的數據庫模式，建立數據庫及其應用系統，使之能有效的存儲數據，滿足用戶的信息要求和處理要求。第2章數據庫設計數據庫設計基本任務：根據給定應用領域的信息需求、處理需求和數據庫支撐環境，設計出數據模式(包括外模式、模式、內模式)。信息需求：數據及其結構----靜態要求。處理需求：數據處理----動態要求。第2章數據庫設計認識抽象信息世界－概念數據模型機器世界－DBMS支持的數據模型轉換現實世界第2章數據庫設計數據庫系統的生命周期數據庫系統的開發是一項軟件工程，開發過程應遵循軟件工程的一般原則和方法。軟件工程：是開發、運行、維護和修正軟件的一種系統方法。軟件生命周期：（1）可行性研究；（2）需求分析；（3）設計；（4）編碼與實現；（5）測試；（6）運行維護；

第2章數據庫設計處理需求DBMS特征總體信息需求物理設計概念設計邏輯設計規劃需求描述和分析硬件和OS特征物理數據庫結構需求說明書信息結構（獨立于硬件、軟件）邏輯數據庫結構（DBMS能處理的）應用程序說明書物理實現數據庫的設計步驟使用、維護數據庫第2章數據庫設計數據庫的設計步驟需求收集和分析用戶關心什么用戶要什么結果設計概念結構設計邏輯結構設計物理結構物理實現運行和維護第2章數據庫設計數據庫的設計步驟需求收集和分析設計概念結構存什么關系（聯系）如何ODL或E/R圖，是各種數據模型的共同基礎設計邏輯結構設計物理結構物理實現運行和維護第2章數據庫設計數據庫的設計步驟需求收集和分析設計概念結構設計邏輯結構用什么數據模型數據庫的模式（databaseschema）用戶子模式設計物理結構物理實現運行和維護第2章數據庫設計數據庫的設計步驟需求收集和分析設計概念結構設計邏輯結構設計物理結構數據怎么存儲和存取根據DBMS產品、環境特點物理實現運行和維護第2章數據庫設計數據庫的設計步驟需求收集和分析設計概念結構設計邏輯結構設計物理結構物理實現運行DDL裝入測試數據應用程序運行和維護第2章數據庫設計數據庫的設計步驟需求收集和分析設計概念結構設計邏輯結構設計物理結構物理實現運行和維護調整修改第2章數據庫設計2.2需求分析需求分析的任務：調查、收集、分析用戶對數據庫的要求信息要求需存儲的數據處理要求要完成的功能、響應時間、處理方式等安全性與完整性要求用戶管理、數據管理、數據一致性等第2章數據庫設計調查用戶需求的步驟調查組織機構情況調查各部門的業務活動情況熟悉業務活動，明確新系統的各種要求確定新系統的邊界(需計算機化的部分)第2章數據庫設計調查用戶需求的方法跟班作業開調查會請專人介紹詢問填寫調查表查閱原系統的工作記錄第2章數據庫設計抽象需求分析的方法結構化分析(SA)方法自頂向下、逐層分解形成需求文檔、數據字典(DD)及多層數據流圖(DFD)數據來源數據存儲數據輸出處理某一層次的抽象圖第2章數據庫設計以學校管理信息系統為例第2章數據庫設計第2章數據庫設計2.3概念結構設計概念結構將在需求分析階段得到的應用需求抽象為信息世界的結構，常用E-R模型來描述獨立于機器概念結構的特點真實充分地反映客觀世界易于理解易于更改易于轉換成為數據模型第2章數據庫設計概念結構設計的方法自頂向下首先定義全局概念結構的框架，然后逐步細化自底向上首先定義各局部應用的概念結構，然后集成逐步擴張首先定義最重要的核心概念結構，然后向外擴充混合策略首先用自頂向下策略設計全局概念結構的框架，再集成用自底向上策略設計的各局部概念結構第2章數據庫設計學生課程選修學號姓名性別系名課號課名學分成績mnE-R圖第2章數據庫設計數據抽象數據抽象抽象出對客觀世界中的概念、對象的本質特性用于在需求分析階段將收集到的數據進行分類、組織(聚集)，從而形成實體、實體的屬性，標識實體的碼，確定實體間的聯系類型，以便設計相應的E-R圖三類數據抽象機制分類（Classification）聚集（Aggregation）概括（Generalization）第2章數據庫設計數據抽象機制之一分類（Classification）將一類具有共同特性和行為的對象定義為一種某類型，在E-R模型中的實體型就是這種抽象，如學生，課程抽象了對象的值和型之間“ismemberof”語義學生“ismemberof”張英王平趙寧實體型課程“ismemberof”C語言數據庫操作系統實體型第2章數據庫設計數據抽象機制之二聚集（Aggregation）定義某類型的組成成分，對應E-R模型中實體的屬性抽象了對象類型和其成分之間的“ispartof”語義學生學號姓名專業班級倉庫號面積主任倉庫姓名年齡性別工資“ispartof”實體型屬性第2章數據庫設計數據抽象機制之三概括（Generalization）定義類型之間的子集聯系，形成超(父)類、子類抽象了類型之間“issubsetof”語義概括的重要性質：繼承，即子類集成超類的所有抽象是E-R模型的抽象機制的擴充學生本科生研究生概括的E-R表示“issubsetof”超類子類學號,姓名,性別,年齡專業，綜合排名導師，研究方向第2章數據庫設計局部E-R模型的設計步驟

需求分析結果確定局部結構的范圍還有局部結構要設計？全局E-R模型的設計有無設計局部E-R模型確定局部結構的實體定義局部結構的屬性定義局部結構的聯系第2章數據庫設計設計實體與屬性的區分實體與屬性采用以下三個原則進行區分：原子性原則：實體需要進一步描述，屬性則不具有描述性。屬性必須是不可分的數據項。依賴性原則：屬性僅單向依賴于某個實體，并且不能與其它實體具有聯系。一致性原則：一個實體的若干屬性之間存在著內在的關聯性與一致性，如學生實體的屬性，分別獨立表示實體的某種獨特個性，并在總體上協調一致，相互配合，構成一個完整的整體。第2章數據庫設計局部設計概念實例例子中，學籍管理局部應用中主要涉及的實體包括學生、宿舍、檔案材料、班級、班主任。那么，這些實體之間的聯系又是怎樣的呢？宿舍與學生之間是1:n的聯系。班級與學生之間也是1:n的聯系。由于班主任同時還要教課，因此班主任與學生之間存在指導聯系，班主任與學生之間是1:n的聯系。學生和他自己的檔案材料之間，班級與班主任之間都是1:1的聯系。第2章數據庫設計學籍管理局部應用分E-R圖班主任歸檔材料宿舍班級學生指導歸檔住宿組成管理1111111nnn第2章數據庫設計學生：｛學號，姓名，出生日期，……｝檔案材料：｛檔案號，……｝班級：｛班級號，學生人數｝班主任：｛職工號，姓名，性別，是否為優秀班主任｝宿舍：｛宿舍編號，地址，人數｝第2章數據庫設計學生教科書課程教室教師教學講授開設選修課程管理局部應用分E-R圖mm11nnn1n成績第2章數據庫設計學生：｛姓名，學號，性別，年齡，所在系，年級，平均成績｝

課程：｛課程號，課程名，學分｝

教師：｛職工號，姓名，性別，職稱｝

教科書:｛書號，書名，價錢｝

教室：｛教室編號，地址，容量｝第2章數據庫設計局部概念設計綜合為全局概念設計將局部概念設計綜合為全局概念設計的過程稱為視圖集成。第2章數據庫設計合并原則是兩兩合并，先合并有聯系的局部結構，再加入獨立的局部結構，這樣可以減小合并的復雜度并使合并結果的規模盡可能小。屬性沖突－屬性域的沖突(類型、范圍）及單位沖突結構沖突－同一信息有的作為實體，有的作為聯系命名沖突－同名異義，異名同義（實體，屬性，聯系）優化全局概念結構使實體個數盡可能少，所含屬性盡可能少，聯系無冗余。局部ER模式確定公共實體類合并兩個局部ER圖檢查并消除沖突還有未合并的局部模式？有還有沖突？無優化評審有根據實體名，碼等來確定，為合并打基礎無第2章數據庫設計1班主任歸檔材料宿舍班級學生指導歸檔住宿組成管理111111nnn教科書課程教室教師教學講授開設選修mm11nnn1n成績第2章數據庫設計消除兩個分E-R圖存在的沖突：班主任實際上也屬于教師，應將學籍管理中的班主任實體與課程管理中的教師實體統一稱為教師：教師：｛職工號，姓名，性別，職稱，是否為優秀班主任｝(2)將班主任改為教師后，教師與學生之間的聯系在兩個局部視圖中呈現兩種不同的類型，一種是學籍管理中教師與學生之間的指導聯系，一種是課程管理中教師與學生之間的教學聯系，由于指導聯系實際上可以包含在教學聯系之中，因此可以將這兩種聯系綜合為教學聯系。(3)在兩個局部E-R圖中，學生實體屬性組成及次序都存在差異，應將所有屬性綜合，并重新調整次序。假設調整結果為：學生：｛學號，姓名，出生日期，年齡，所在系，年級，平均成績｝第2章數據庫設計消除冗余數據和冗余聯系：學生實體中的年齡屬性可以由出生日期推算出來，屬于冗余數據，應該去掉。學生：｛學號，姓名，出生日期，所在系，年級，平均成績｝(2)學生實體中的平均成績可以從選修聯系中的成績屬性中推算出來，但如果應用中需要經常查詢某個學生的平均成績，每次都進行這種計算效率就會太低，因此為提高效率，可以考慮保留該冗余數據，但是為了維護數據一致性應該定義一個觸發器來保證學生的平均成績等于該學生各科成績的平均值。第2章數據庫設計進行修改和重構后生成的基本E-R圖班級教室開設教師教科書學生課程宿舍檔案材料住宿歸檔教學講授選修管理1n11111111組成nnmnmnn第2章數據庫設計2.4邏輯結構設計就是把概念結構設計階段設計好的基本E-R圖轉換為與選用DBMS產品所支持的數據模型相符合的邏輯結構。分三步進行： (1)初始關系模式設計； (2)關系模式規范化； (3)模式的評價與改進。第2章數據庫設計處理需求從ER圖導出初始數據庫模式關系模式規范化模式評價：滿足用戶要求保持函數依賴和無損連接是否需要修正？否進入物理設計是ER模型DBMS特性關系數據庫的邏輯設計第2章數據庫設計1.初始關系模式設計E-R圖是由實體、實體的屬性和實體之間的聯系三個要素組成的。將E-R圖轉換為關系模型實際上就是要將實體、實體的屬性和實體之間的聯系轉化為關系模式。這種轉換一般遵循如下原則：第2章數據庫設計a.實體型的轉換一個實體型轉換為一個關系模式。實體的屬性就是關系模式的屬性，實體的標識符(碼)就是關系模式的候選碼。例如，學生實體可以轉換為如下關系模式，其中學號為學生關系的碼：學生（學號，姓名，出生日期，所在系，年級，平均成績）第2章數據庫設計b.聯系的轉換（1）一個1:1聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。例如在我們的例子中，“管理”聯系為1:1聯系，管理（職工號，班級號）班級：｛班級號，學生人數，職工號｝教師：｛職工號，姓名，性別，職稱，班級號，是否為優秀班主任｝第2章數據庫設計（2）一個1:n聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。例如，“組成”聯系為1:n聯系，將其轉換為關系模式一種方法是使其成為一個獨立的關系模式：組成（學號，班級號）

學生（學號，姓名，出生日期，所在系，年級，班級號，平均成績）第2章數據庫設計（3）一個m:n聯系轉換為一個關系模式。與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。而關系的碼為各實體碼的組合。例如，“選修”聯系是一個m：n聯系，可以將它轉換為如下關系模式，其中學號與課程號為關系的組合碼：選修（學號，課程號，成績）第2章數據庫設計（4）三個或三個以上實體間的一個多元聯系轉換為一個關系模式。與該多元聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。而關系的碼為各實體碼的組合。例如，“講授”聯系是一個三元聯系，可以將它轉換為如下關系模式，其中課程號、教師號和書號為關系的組合碼：講授（課程號，教師號，書號）第2章數據庫設計（5）同一實體集的實體間的聯系，即自聯系，也可按上述1:1、1:n和m:n三種情況分別處理。例如，如果教師實體集內部存在領導與被領導的1:n自聯系，我們可以將該聯系與教師實體合并，這時主碼職工號將多次出現，但作用不同，可用不同的屬性名加以區分，比如在合并后的關系模式中，主碼仍為職工號，再增設一個“系主任”屬性，存放相應系主任的職工號。教師：｛職工號，姓名，性別，職稱，系主任｝第2章數據庫設計學生管理子系統中的16個實體和聯系可以轉換為下列關系模型：

學生（學號，姓名，性別，出生日期，所在系，年級，班級號，宿舍編號，平均成績，檔案號）宿舍（宿舍編號，地址，性別，人數）班級（班級號，學生人數）教師（職工號，姓名，性別，職稱，班級號，是否為優秀班主任）課程（課程號，課程名，學分，教室號）教科書（書號，書名，價錢）教室（教室編號，地址，容量）檔案材料（檔案號，……）

教學（職工號，學號）

選修（學號，課程號，成績）

講授（教師號，課程號，書號）第2章數據庫設計如公司部門管理系統的E-R圖及其轉換成的關系模式部門項目職工電話包括承擔n1n1辦公室號，面積項目號，預算費參與mn辦公室包含1n包括n1職務承擔11部門號，預算費，領導人職工號電話號碼，說明職工號，姓名，辦公電話擔任時期，工資分擔任務

部門(部門號，部門預算費，領導人職工號)

職工(職工號，姓名，辦公電話，部門號)

辦公室(辦公室號，面積，部門號)

項目(項目號，項目預算費，部門號)

電話(電話號碼，說明，辦公室號)

項目承擔情況(職工號，項目號，分擔任務)

職務(職工號，職務，擔任時期，工資)第2章數據庫設計2.數據模型的規范化確定數據依賴對各個關系模式之間的數據依賴進行極小化處理，消除冗余按照數據依賴的理論對關系模式逐一分析，確定各關系模式屬于第幾范式按用戶需求分析這些模式是否合適，是否需合并或分解對關系模式進行必要的分解，提高數據操作效率和存儲空間利用率第2章數據庫設計合并如果有若干個關系模式具有相同的主鍵，并且對這些關系模式的處理主要是查詢操作，而且經常是多關系的查詢，那么可對這些關系模式按照組合使用頻率進行合并。這樣便可以減少聯接操作而提高查詢效率。第2章數據庫設計分解水平分解：有學生關系（學號，姓名，類別……），其中類別包括大專生、本科生和研究生。如果多數查詢一次只涉及其中的一類學生，就應該把整個學生關系水平分割為大專生、本科生和研究生三個關系。垂直分解：例如，有教師關系（教師號，姓名，性別，年齡，職稱，工資，崗位津貼，住址，電話），如果經常查詢的僅是前六項，而后三項很少使用，則可以將教師關系進行垂直分割，第2章數據庫設計3.設計用戶子模式定義數據庫模式主要是從系統的時間效率、空間效率、易維護等角度出發。由于用戶外模式與模式是獨立的，因此我們在定義用戶外模式時應該更注重考慮用戶的習慣與方便。包括：(1)使用更符合用戶習慣的別名(2)針對不同級別的用戶定義不同的外模式，以滿足系統對安全性的要求。(3)簡化用戶對系統的使用第2章數據庫設計2.5數據庫的物理設計對已經確定的邏輯數據庫結構利用DBMS所提供的方法、技術，以較優的存儲結構、數據存取路徑、合理的數據存放位置以及存儲分配，設計出一個高效的、可實現的物理數據庫結構。數據庫的物理設計通常分為兩步：確定數據庫的物理結構，在關系數據庫中主要指存取方法和存儲結構；對物理結構進行評價，評價的重點是時間和空間效率第2章數據庫設計1.確定數據庫的物理結構確定需要存儲的數據對象如關系、索引、聚簇、日志、備份等確定數據的存放位置如區分穩定數據和易變數據、經常存取部分和不常存取部分、機密數據和普通數據等，分開存放確定數據的存儲結構如順序結構、隨機結構、鏈表結構、樹狀結構等確定數據的存取方法如索引(如B樹、B+樹、R樹等)、聚簇、HASH法等確定系統配置如同時使用數據庫的最大用戶數、同時打開的數據庫對象數、內存分配參數、緩沖區分配參數、存儲分配參數、物理塊大小、物理塊裝填因子、時間片大小、數據庫大小、鎖的數目等第2章數據庫設計索引的選擇主鍵及外鍵之上一般都可以分別建立索引。以查詢為主的關系表盡可能多的建立索引對于等值連接，而且滿足條件的元組較少的查詢可以考慮建立索引。有些查詢可以從索引中直接得到結果，不必訪問數據塊，這種查詢可以建立索引，如查詢某屬性的MIN,MAX,AVG,SUM和COUNT等函數值，可以在該屬性上建立索引，查詢時，按照屬性索引得順序掃描直接得到結果.第2章數據庫設計2.評價物理結構由于在物理設計過程中需考慮的因素很多，包括時間和空間效率、維護代價和用戶的要求等等，對這些因素進行權衡后，可能會產生多種物理設計方案。該階段需對各種可能的設計方案進行評價，評價的重點是系統的時間和空間效率，并從多個方案中選出較優的物理結構。第2章數據庫設計7.6數據庫的實施數據庫實施的工作內容用DDL定義數據庫結構組織數據入庫編制與調試應用程序數據庫試運行第2章數據庫設計數據庫實施定義數據庫結構數據裝載數據庫試運