六章數(shù)據(jù)庫設計六章數(shù)據(jù)庫設計主要章節(jié)6.1概述6.2需求分析6.3概念結構設計6.4邏輯結構設計6.5物理結構設計6.6數(shù)據(jù)庫的實現(xiàn)6.7數(shù)據(jù)庫的運行與維護主要章節(jié)最新六章數(shù)據(jù)庫設計課件最新六章數(shù)據(jù)庫設計課件最新六章數(shù)據(jù)庫設計課件最新六章數(shù)據(jù)庫設計課件最新六章數(shù)據(jù)庫設計課件最新六章數(shù)據(jù)庫設計課件數(shù)據(jù)庫設計目標和方法數(shù)據(jù)庫設計方法

⑴生命周期法生命周期（Lifecycle）法就是將整個數(shù)據(jù)庫應用系統(tǒng)的開發(fā)過程分解成若干個階段，并對每個階段的目標、任務、方法作出規(guī)定，使整個數(shù)據(jù)庫應用系統(tǒng)的開發(fā)過程具有合理的組織和科學的秩序。階段劃分：系統(tǒng)分析、系統(tǒng)設計、系統(tǒng)實施、系統(tǒng)運行與維護。主要遵循的原則：①用戶參與的原則。②先邏輯、后物理的原則。③自頂向下的原則。④工作成果描述標準化原則。數(shù)據(jù)庫設計目標和方法數(shù)據(jù)庫設計方法需求分析系統(tǒng)設計

系統(tǒng)實施運行維護

生命周期法確定開發(fā)的總目標,計劃開發(fā)的軟件系統(tǒng)功能、性能、可靠性及接口等方面的設想。并提供一個可做為設計基礎的系統(tǒng)規(guī)格說明書，包括對軟、硬件環(huán)境的需求和一整套完整的數(shù)據(jù)流圖。

把需求分析階段所確定的功能細化。主要工作是設計模塊結構圖和系統(tǒng)的數(shù)據(jù)結構。

以某一個或幾種特定的程序設計語言表達上一階段確定的各模塊控制流程。編制時應遵循結構化程序設計。并對已編制好的程序進行單元調試（分調），整體調試（聯(lián)調）和系統(tǒng)測試（驗收）。

是整個生存期中時間最長的階段，重點是將系統(tǒng)付諸使用，同時解決開發(fā)過程中遺留問題，改正和改善性能.數(shù)據(jù)庫設計目標和方法需求分析系統(tǒng)設計系統(tǒng)實施運行維護生命周期法確定開發(fā)的總數(shù)據(jù)庫設計目標和方法⑵快速原型法快速原型（RapidPrototyping）法的基本思想是在初步了解用戶的基本要求后，開發(fā)人員先建立一個他們認為符合用戶要求的模式系統(tǒng)交付用戶檢驗，由于模型是可以執(zhí)行的，所以為用戶提供了獲得感性認識的機會。優(yōu)點：用戶可以測試具體實例，直接觀察一個實際系統(tǒng)。有利于準確地定義出用戶需求，降低系統(tǒng)開發(fā)風險。適用于中小規(guī)模系統(tǒng)的開發(fā)。缺點：具有為用戶需求快速生成軟件的工具和環(huán)境。數(shù)據(jù)庫設計目標和方法⑵快速原型法數(shù)據(jù)庫設計目標和方法⑶面向對象法面向對象（ObjectOriented，簡稱OO）法是針對面向過程提出的，是區(qū)別于傳統(tǒng)的結構化方法的一種新方法、新思路，是一種基于數(shù)據(jù)抽象的類的組合的自底向上的開發(fā)方法?；静襟E：①標識對象和定義類；②組織類間關系；③在類層中構造框架；④建立可復用的類庫和系統(tǒng)總框架。數(shù)據(jù)庫設計目標和方法⑶面向對象法數(shù)據(jù)庫設計目標和方法面向對象法主要有以下四個特征：(1)對象是有關數(shù)據(jù)和操作的封裝體，突破了傳統(tǒng)的將數(shù)據(jù)與操作分離的模式，較好地實現(xiàn)了數(shù)據(jù)抽象。(2)面向對象法的繼承性體現(xiàn)了概念分離抽象。在對象繼承結構上，下層對象繼承上層對象的特征（屬性和操作），因而便于軟件系統(tǒng)的演化和功能擴充。(3)面向對象法用消息將對象動態(tài)連接在一起。與結構化方法中的模塊調用不同，面向對象法采用了靈活的消息傳遞方式，便于在概念上體現(xiàn)并行和分布式結構。(4)面向對象法具有封裝性。對象將其實現(xiàn)細節(jié)封裝在它的內部，因此無論是對象功能的完善擴充還是對象實現(xiàn)的修改，影響僅限于該對象內部而不會對外界產(chǎn)生影響，這就保證了軟件系統(tǒng)的可復用性和可維護性。數(shù)據(jù)庫設計目標和方法面向對象法主要有以下四個特征：數(shù)據(jù)庫設計的基本步驟運行和維護

實現(xiàn)

物理設計邏輯設計概念設計需求分析對用戶提出的各種要求加以分析，對各種原始數(shù)據(jù)加以綜合、整理，是形成最終設計目標的首要階段，也是整個數(shù)據(jù)庫設計過程中最困難的階段。

概念結構設計是對用戶需求進行進一步抽象、歸納，并形成獨立于DBMS和有關軟、硬件的概念數(shù)據(jù)模型的設計過程，這是對現(xiàn)實世界中具體數(shù)據(jù)的首次抽象，實現(xiàn)了從現(xiàn)實世界到信息世界的轉化過程。

邏輯結構設計是將概念結構轉化為某個DBMS所支持的數(shù)據(jù)模型，并進行優(yōu)化的設計過程。由于邏輯結構設計是一個基于具體DBMS的實現(xiàn)過程，所以選擇什么樣的數(shù)據(jù)模型尤為重要，其次是數(shù)據(jù)模型的優(yōu)化。

物理結構設計是將邏輯結構設計階段所產(chǎn)生的邏輯數(shù)據(jù)模型，轉換為某一計算機系統(tǒng)所支持的數(shù)據(jù)庫物理結構的實現(xiàn)過程。數(shù)據(jù)庫實施階段，即數(shù)據(jù)庫調試、試運行階段。一旦數(shù)據(jù)庫物理結構形成，就可以用已選定的DBMS來定義、描述相應的數(shù)據(jù)庫結構，裝入相應的數(shù)據(jù)，以生成完整的數(shù)據(jù)庫。數(shù)據(jù)庫實施階段結束，標志著數(shù)據(jù)庫系統(tǒng)投入正常運行工作的開始。數(shù)據(jù)庫運行及維護的過程，是一個調整、修改和不斷完善的運行過程。數(shù)據(jù)庫設計的基本步驟運行和維護實現(xiàn)物理設計邏輯設計概念設6.2需求分析6.2需求分析6.2需求分析主要內容需求分析的任務需求分析的步驟6.2需求分析主要內容需求分析的任務需求分析階段任務是對系統(tǒng)的整個應用情況作全面的、詳細的調查，確定企業(yè)組織的目標，收集支持系統(tǒng)總的設計目標的基礎數(shù)據(jù)和對這些數(shù)據(jù)的要求，確定用戶的需求，并把這些要求寫成用戶和數(shù)據(jù)庫設計者都能夠接受的文檔。需求分析中調查分析的方法很多，通常的辦法是對不同層次的企業(yè)管理人員進行個人訪問，內容包括業(yè)務處理和企業(yè)組織中的各種數(shù)據(jù)。訪問的結果應該包括數(shù)據(jù)的流程、過程之間的接口以及訪問者和職員兩方面對流程和接口語義上的核對說明和結論。對于某些特殊的目標和數(shù)據(jù)庫的要求，可以從企業(yè)組織中的最高層機構得到。設計人員還應該了解系統(tǒng)將來要發(fā)生的變化，收集未來應用所涉及的數(shù)據(jù)，充分考慮到系統(tǒng)可能的擴充和變動，使系統(tǒng)設計更符合未來發(fā)展的趨向，并且易于改動，以減少系統(tǒng)維護的代價。需求分析的任務需求分析階段任務是對系統(tǒng)的整個應用情況作全面的這一階段的任務如圖總體信息需求定義了未來系統(tǒng)用到的所有信息，描述了數(shù)據(jù)之間本質上和概念上的聯(lián)系，描述了實體、屬性、組合及聯(lián)系的性質。這一階段的結果是“需求說明書”，其主要內容是系統(tǒng)的數(shù)據(jù)流圖和數(shù)據(jù)字典。需求說明書應是一份既切合實際，又具有遠見的文檔，是一個描述新系統(tǒng)的輪廓圖。需求分析的任務總體信息需求處理需求第1步：需求分析這一階段的任務如圖需求分析的任務總體信息需求處理需求第1步：需求分析的步驟⑴分析用戶活動，產(chǎn)生用戶活動圖。 這一步主要了解用戶當前的業(yè)務活動和職能，搞清其處理流程（即業(yè)務流程）。如果一個處理流程比較復雜，就要把這個處理流程分解成若干個子處理流程，使每個處理流程功能明確、界面清楚，分析之后畫出用戶活動圖（即用戶的業(yè)務流程圖）。⑵確定系統(tǒng)范圍，產(chǎn)生系統(tǒng)范圍圖。 這一步是確定系統(tǒng)的邊界。在和用戶經(jīng)過充分討論的基礎上，確定計算機所能進行數(shù)據(jù)處理的范圍，確定哪些工作由人工完成，哪些工作由計算機系統(tǒng)完成，即確定人機界面。⑶分析用戶活動所涉及的數(shù)據(jù)，產(chǎn)生數(shù)據(jù)流圖。 深入分析用戶的業(yè)務處理，以數(shù)據(jù)流圖形式表示出數(shù)據(jù)的流向和對數(shù)據(jù)所進行的加工。需求分析的步驟⑴分析用戶活動，產(chǎn)生用戶活動圖。需求分析的步驟教師原始輸入輸入處理成績登錄輸出處理教務處輸入格式化輸出輸出格式化成績文件數(shù)據(jù)流圖（DataFlowDiagram，簡記為DFD）： 是從“數(shù)據(jù)”和“對數(shù)據(jù)的加工”兩方面表達數(shù)據(jù)處理系統(tǒng)工作過程的一種圖形表示法。特點 具有直觀、易于被用戶和軟件人員雙方都能理解的一種表達系統(tǒng)功能的描述方式。DFD有四個基本成分：數(shù)據(jù)流（用箭頭表示）加工或處理（用圓圈表示）文件（用雙線段表示）外部實體（數(shù)據(jù)流的源點或終點，用方框表示）需求分析的步驟教師原始輸入輸入成績輸出教務處輸入格式化輸出輸需求分析的步驟DFD可作為自頂向下逐步細化時描述對象的工具。頂層的每一個圓圈（加工處理）都可以進一步細化為第二層；第二層的每一個圓圈又可以進一步細化為第三層……；直到最底層的每一個圓圈已表示一個最基本的處理動作為止。DFD可以形象地表示數(shù)據(jù)流與各業(yè)務活動的關系，它是需求分析的工具和分析結果的描述手段。例6.1在選課業(yè)務的處理流程中，假設開發(fā)人員收集到以下數(shù)據(jù)：學生基本信息表、課程表、選課單、選課情況一覽表、成績單等。通過分析，確認學生基本信息表、課程表、選課單是輸入選課系統(tǒng)的原始數(shù)據(jù)，而選課情況一覽表以及成績單等是選課系統(tǒng)最終需要輸出的數(shù)據(jù)，如下圖所示。需求分析的步驟DFD可作為自頂向下逐步細化時描述對象的工具。需求分析的步驟系統(tǒng)原始數(shù)據(jù)輸入學生選課系統(tǒng)學生基本信息學生選課信息課程成績課程信息個人成績單選課情況一覽表某課程成績單系統(tǒng)輸出數(shù)據(jù)學生選課系統(tǒng)是如何對系統(tǒng)的原始數(shù)據(jù)進行處理最后得到系統(tǒng)的輸出數(shù)據(jù)呢？下面圖給出了學生選課系統(tǒng)的整個數(shù)據(jù)流圖，它是前面圖的進一步分解和細化。數(shù)據(jù)流圖是一種從數(shù)據(jù)的角度描述數(shù)據(jù)作為輸入進入系統(tǒng)，經(jīng)受若干加工處理，或者合并，或者分解，或者存儲，最后輸出的整個過程。需求分析的步驟系統(tǒng)原始數(shù)據(jù)輸入學生學生基本信息學生選課信息課需求分析的步驟課程信息學生基本信息個人成績單選課情況一覽表某課程成績單查詢結果查詢結果查詢結果系統(tǒng)原始數(shù)據(jù)系統(tǒng)輸出數(shù)據(jù)學生基本信息課程信息學生選課信息學生信息錄入選課信息錄入成績錄入查詢個人所有課程成績課程信息錄入查詢課程的選課情況查詢某門課程的所有成績學生選課系統(tǒng)的0層數(shù)據(jù)流圖

需求分析的步驟課程信息學生基本信息個人成績單選課情況一覽表某需求分析的步驟⑷分析系統(tǒng)數(shù)據(jù)，產(chǎn)生數(shù)據(jù)字典。 數(shù)據(jù)字典提供了對數(shù)據(jù)庫數(shù)據(jù)描述的集中管理，它的功能是存儲和檢索各種數(shù)據(jù)描述（稱為元數(shù)據(jù)Metadata），如敘述性的數(shù)據(jù)定義等，并且為DBA提供有關的報告。數(shù)據(jù)字典中通常包括：數(shù)據(jù)項數(shù)據(jù)結構數(shù)據(jù)流數(shù)據(jù)存儲加工過程需求分析的步驟⑷分析系統(tǒng)數(shù)據(jù)，產(chǎn)生數(shù)據(jù)字典。

例6.2在上圖中有一個數(shù)據(jù)流查詢個人所有課程成績，每個人的成績單有一個數(shù)據(jù)項為學生的學號SNO。在數(shù)據(jù)字典中對此數(shù)據(jù)項如下描述。數(shù)據(jù)項名：SNO說明：標識一名學生類型：CHAR(9)長度：9別名：學生學號取值范圍：000000000～999999999需求分析的步驟①數(shù)據(jù)項

數(shù)據(jù)項是數(shù)據(jù)的最小單位，對數(shù)據(jù)項的描述，通常包括數(shù)據(jù)項名、含義、別名、類型、長度、取值范圍以及與其他數(shù)據(jù)項的邏輯關系。例6.2在上圖中有一個數(shù)據(jù)流查詢個人所有課程需求分析的步驟②數(shù)據(jù)結構數(shù)據(jù)結構反映了數(shù)據(jù)之間的組合關系。一個數(shù)據(jù)結構可以由若干個數(shù)據(jù)項組成，也可以由若干個數(shù)據(jù)結構組成，或由若干個數(shù)據(jù)項和數(shù)據(jù)結構混合而成。它包括數(shù)據(jù)結構名、含義及組成該數(shù)據(jù)結構的數(shù)據(jù)項名或數(shù)據(jù)結構名。需求分析的步驟②數(shù)據(jù)結構需求分析的步驟數(shù)據(jù)流名：個人成績查詢說明：學生可以根據(jù)所學專業(yè)、班級號、學生姓名、課程名稱來查詢個人成績來源：學生選課信息去向：輸出到個人成績單數(shù)據(jù)結構：個人成績查詢所學專業(yè)班級號學生姓名課程名稱③數(shù)據(jù)流數(shù)據(jù)流可以是數(shù)據(jù)項，也可以是數(shù)據(jù)結構，表示某一加工處理過程的輸入或輸出數(shù)據(jù)。對數(shù)據(jù)流的描述應包括數(shù)據(jù)流名、說明、流出的加工名、流入的加工名以及組成該數(shù)據(jù)流的數(shù)據(jù)結構或數(shù)據(jù)項。例6.3在上圖中成績查詢是一個數(shù)據(jù)流，在數(shù)據(jù)字典中可作如下描述。需求分析的步驟數(shù)據(jù)流名：個人成績查詢③數(shù)據(jù)流需求分析的步驟數(shù)據(jù)存儲名：課程說明：對每門課程的名稱、學分、先行課程號和摘要的描述輸出數(shù)據(jù)流：課程介紹數(shù)據(jù)描述：課程號、課程名、學分數(shù)、先行課程號、摘要數(shù)量：每年328種存取方式：隨機存取④數(shù)據(jù)存儲數(shù)據(jù)存儲是處理過程中要存儲的數(shù)據(jù)，它可以是手工憑證、手工文檔或計算機文檔。對數(shù)據(jù)存儲的描述應包括：數(shù)據(jù)存儲名、說明、輸入數(shù)據(jù)流、輸出數(shù)據(jù)流、數(shù)據(jù)量（每次存取多少數(shù)據(jù)）、存取頻度（單位時間內存取次數(shù)）和存取方式（是批處理，還是聯(lián)機處理；是檢索，還是更新；是順序存取，還是隨機存?。＠?.4上圖中課程是個數(shù)據(jù)存儲，在數(shù)據(jù)字典中可對其作如下描述。需求分析的步驟數(shù)據(jù)存儲名：課程④數(shù)據(jù)存儲需求分析的步驟處理過程：確定選課名單說

明：對選某門課程的每一個學生，根據(jù)已選修課程確定其是否可選該課程。再根據(jù)學生選課的人數(shù)選擇適當?shù)慕淌?，制定選課單。輸入：學生選課、可選課程、已選課程輸出：選課單程序提要：a．對所選課程在選課表中查找其是否已選此課程；b．若未選過此課程，則在選課表中查找是否已選此課程的先行課程；c．若a、b都滿足，則在選課表中增加一條選課記錄；d．處理完全部學生的選課后，形成選課單。

⑤加工過程對加工處理的描述包括加工過程名、說明、輸入數(shù)據(jù)流、輸出數(shù)據(jù)流，并簡要說明處理工作、頻度要求、數(shù)據(jù)量及響應時間等。需求分析的步驟處理過程：確定選課名單⑤加工過程6.3概念設計6.3概念設計6.3概念設計主要內容概念結構設計任務和ER模型的特點概念結構設計的基本方法概念結構設計的主要步驟局部ER模型的設計全局ER模型的設計概念結構設計實例6.3概念設計主要內容概念結構設計任務和ER模型的特點數(shù)據(jù)庫的概念結構設計是整個數(shù)據(jù)庫設計的關鍵階段，其主要任務是通過對用戶需求進行綜合、歸納與抽象，形成一個獨立于具體DBMS的概念模式。實體-聯(lián)系（EntityRela-tionship，ER）模型具有以下特點：⑴能真實、充分地反映現(xiàn)實世界，包括事物和事物之間的聯(lián)系，并能滿足用戶對數(shù)據(jù)的處理要求；⑵易于理解?？梢岳盟谠O計人員、編程人員以及最終用戶之間進行交流，使得用戶能夠積極參與，保證數(shù)據(jù)庫設計的成功；⑶易于更改。當應用環(huán)境和應用要求發(fā)生改變時，容易對模式進行修改和擴充；⑷易于向關系、網(wǎng)狀、層次等各種數(shù)據(jù)模型轉換。概念結構設計任務和ER模型的特點數(shù)據(jù)庫的概念結構設計是整個概念結構設計的基本方法⑴自底向上的設計方法：也稱為屬性綜合法。這種方法的基本點是將前面需求分析中收集到的數(shù)據(jù)元素作為基本輸入，通過對這些元素的分析，把它們綜合成相應的實體或聯(lián)系。適合范圍較小單位的、較為簡單的設計對象不適合于中等規(guī)模以上的設計對象概念結構設計的基本方法⑴自底向上的設計方法：概念結構設計的基本方法⑵自頂向下的設計方法：從分析組織的事務活動開始，按下面步驟進行：首先識別用戶所關心的實體及實體間的聯(lián)系，建立一個初步的數(shù)據(jù)模型框架；然后再以逐步求精的方式加上必需的描述屬性形成一個完整的局部ER模型；最后再將這些局部ER模型集成為一個統(tǒng)一的全局ER模型。概念結構設計的基本方法⑵自頂向下的設計方法：概念結構設計的主要步驟⑴進行數(shù)據(jù)抽象，設計局部概念模式 局部用戶的信息需求是構造全局概念模式的基礎。在建立局部概念結構時，常常要對需求分析的結果進行細化、補充和修改，如有的數(shù)據(jù)項要分為若干子項，有的數(shù)據(jù)定義要重新核實等。⑵將局部概念模式綜合成全局概念模式

綜合各局部概念結構就可得到反映所有用戶需求的全局概念結構。在綜合過程中，主要處理各局部模式對各種對象定義的不一致問題，包括同名異義、異名同義和同一事物在不同模式中被抽象為不同類型的對象（例如，有的作為實體，有的又作為屬性）等問題。把各個局部結構合并，還會產(chǎn)生冗余問題，或導致對信息需求的再調整與分析，以確定確切的含義。⑶評審

消除了所有沖突后，就可把全局結構提交評審。評審分為用戶評審與DBA及應用開發(fā)人員評審兩部分。概念結構設計的主要步驟⑴進行數(shù)據(jù)抽象，設計局部概念模式局部ER模型的設計1.確定局部結構范圍設計局部ER模型時，首先需要根據(jù)系統(tǒng)的具體情況，在多層的數(shù)據(jù)流圖中選擇一個適當層次的數(shù)據(jù)流圖，讓這組圖中每一部分對應一個局部應用，然后以這一層次的數(shù)據(jù)流圖為出發(fā)點，設計局部ER圖。在確定局部ER模型的設計范圍時，有兩條原則可供參考：⑴把那些關系最密切的若干功能所涉及到的數(shù)據(jù)盡可能地包含在一個局部ER模型內；⑵一個局部ER模型中所包含的實體數(shù)不能太多，以免過于復雜，不便理解和管理。局部ER模型的設計1.確定局部結構范圍局部ER模型設計的流程圖如下：局部ER模型的設計需求分析結果確定局部ER模型范圍實體定義聯(lián)系定義屬性分配還有局部結構待分析無進入全局ER模型設計有局部ER模型設局部ER模型的設計需求分析結果確定局部ER模型需求分析結果確定局部結構范圍實體定義聯(lián)系定義屬性分配還有局部結構待分析有無進入全局ER模式設計局部ER模式設計流程圖范圍的劃分要自然，易于管理；范圍的大小要適度。太小了，會造成局部結構過多，設計過程繁瑣，綜合困難；太大了，則容易造成內部結構復雜，不便分析

范圍之間的界面要清晰，相互影響要小采用人們習慣的劃分；避免冗余，在一個局部結構中，對一個對象只取一種抽象形式，不要重復；依據(jù)用戶的信息處理需求

確定屬性的原則：屬性應該是不可再分解的語義單位；實體與屬性之間的關系只能是1:N的；不同實體類型的屬性之間應無直接關聯(lián)關系。

屬性分配的原則：當多個實體類型用到同一屬性時，一般把屬性分配給那些使用頻率最高的實體類型，或分配給實體值少的實體類型。有些屬性不宜歸屬于任一實體類型，只說明實體之間聯(lián)系的特性

局部ER模型的設計需求分析結果確定局部結構范圍實體定義聯(lián)系定義屬性分配還有局部下面以學校的教務管理信息系統(tǒng)為例來說明局部概念結構設計范圍的確定。教務管理信息系統(tǒng)的頂層數(shù)據(jù)流圖如下圖所示。教務管理信息系統(tǒng)學生學籍數(shù)據(jù)課程數(shù)據(jù)選課數(shù)據(jù)成績數(shù)據(jù)學籍變動表課程表選課一覽表成績單局部ER模型的設計下面圖給出了教務管理信息系統(tǒng)的0層數(shù)據(jù)流圖，該圖描述了教務管理信息系統(tǒng)的組成部分以及各部分的輸入和輸出數(shù)據(jù)。下面以學校的教務管理信息系統(tǒng)為例來說明局部概念結構設計范圍的局部ER模型的設計課程管理22成績管理44學生基本信息課程表課程數(shù)據(jù)成績單成績數(shù)據(jù)選課一覽表選課管理3學生基本信息課程信息選課信息學籍變動表學生學籍數(shù)據(jù)學生學籍管理1選課數(shù)據(jù)局部ER模型的設計課程管理22成績管理44學生基本信息課程表局部ER模型的設計2.確定實體及實體的主鍵⑴確定實體實體（Entity）是一個數(shù)據(jù)對象，指應用中可以區(qū)別的客觀存在的事物，如人、部門、表格、物體、項目等。同一類實體構成實體集（EntitySet）。ER模型中的實體往往是指實體集。學生選課子系統(tǒng)局部應用中，學生是一個實體，學生張平、李玲是學生實體中的兩個實例。課程是一個實體，操作系統(tǒng)、數(shù)據(jù)庫原理及應用是課程實體中的兩個實例。課程管理子系統(tǒng)的局部應用中，課程是一個實體，每門課程是課程實體中的一個實例。上課的教師是一個實體，每位上課的教師都是教師實體中的一個實例。成績管理子系統(tǒng)的局部應用中，學生是一個實體。一個學生，選修一門課程并參加了考試，就會有這門課程的成績。因此，可以把成績視為選課聯(lián)系的一個屬性。局部ER模型的設計2.確定實體及實體的主鍵局部ER模型的設計⑵確定實體的主鍵

主鍵是確定實體的唯一標志。學生實體的主鍵是學號；課程實體的主鍵是課程號；教師實體的主鍵是教師號；局部ER模型的設計⑵確定實體的主鍵局部ER模型的設計⑶區(qū)分實體與屬性的一般原則：實體一般需要描述信息，而屬性不需要。例如，學生需要描述屬性（學號、姓名、性別、出生年月等），所以學生是實體。而性別不需要描述屬性，所以性別是屬性。多值的屬性可考慮作為實體。例如，教師的職務是一個多值的屬性，即一個教師可能擔任多個職務。此時職務可考慮作為一個獨立的實體，否則數(shù)據(jù)庫表中就會出現(xiàn)大量空值。局部ER模型的設計⑶區(qū)分實體與屬性的一般原則：局部ER模型的設計⑷實體與屬性是相對而言的。同一事物，在一種應用環(huán)境中作為“屬性”，在另一種應用環(huán)境中就必須作為“實體”。例如，學校中的系，在某種應用環(huán)境中，它只是作為“學生”實體的一個屬性，表明一個學生屬于哪個系；而在另一種環(huán)境中，由于需要考慮一個系的系主任、教師人數(shù)、學生人數(shù)、辦公地點等，這時系就需要作為實體了。局部ER模型的設計⑷實體與屬性是相對而言的。局部ER模型的設計3.定義實體間的聯(lián)系聯(lián)系是實體集之間關系的抽象表示，即對現(xiàn)實世界中事物之間關系的描述。如教師實體集與學生實體集間的“講授”聯(lián)系，公司實體集與職工實體集之間的“聘任”聯(lián)系等。在局部ER圖設計時，需要對已識別出的實體確定不同實體間的聯(lián)系是屬于什么類型的聯(lián)系，是二元聯(lián)系還是多元聯(lián)系？局部ER模型的設計3.定義實體間的聯(lián)系局部ER模型的設計⑴一對一（1:1）聯(lián)系若兩個實體集中的每一個實體至多和另一個實體集中的一個實體有聯(lián)系，則稱兩個實體集具有1:1的聯(lián)系。⑵一對多（1:N）聯(lián)系設有兩個實體集，若第一個實體集中每個實體與第二個實體集中多（大于1）個實體相聯(lián)系，而第二個實體中的每個實體至多和第一個實體集中的一個實體有聯(lián)系，則稱第一個實體集與第二個實體集是一對多的聯(lián)系，記為1:N。⑶多對多（M:N）聯(lián)系若兩個實體集中的每一個實體都和另一個實體集中多（大于1）個實體有聯(lián)系，則稱這兩個實體集是多對多的聯(lián)系，記為M:N。局部ER模型的設計⑴一對一（1:1）聯(lián)系局部ER模型的設計技術員技術參與1掌握工程使用N111N冗余聯(lián)系定義實體聯(lián)系時應注意：①消除冗余聯(lián)系。在確定聯(lián)系類型時，應注意防止出現(xiàn)冗余聯(lián)系（即可以從其他聯(lián)系導出的聯(lián)系）。假定每一個技術員必須參加一個工程；每個工程有多個技術員參加；每個工程必須使用一種技術。由于聯(lián)系具有傳遞性，因此，隱含了每一個技術員必須掌握一種技術。該問題設計到三個實體，即技術員、工程以及技術。局部ER模型的設計技術員技術參與1掌握工程使用N111N冗余局部ER模型的設計②正確鑒別二元及多元聯(lián)系。在局部ER圖設計中，不同實體間應建立二元還是多元聯(lián)系，應該根據(jù)問題說明來確定。問題1：任何一個供應商可向任何一個顧客供應任何一種零件。在這個問題中，給定一個供應商，不能夠確定該供應商向哪個顧客供應了哪種零件。給定一個顧客，也不能夠確定該顧客是向哪個供應商購買了哪種零件。同樣，給定一個零件，也不能確定哪個顧客在哪個供應商處購買的。如果想知道哪一個供應商向哪一個顧客提供了哪一種零件，則必須構建一個三元聯(lián)系，且供應商、顧客以及零件三個實體之間的聯(lián)系是多對多的。供應商零件供-顧-零顧客NPM局部ER模型的設計②正確鑒別二元及多元聯(lián)系。供應商零件供-局部ER模型的設計問題2：任何一個供應商可向任何一個顧客供應零件，但每個顧客訂購的零件是一定的。在這個問題中，同樣地，給定一個供應商，卻不能確定向哪個顧客供應零件；給定一個顧客，也不能確定向哪個供應商購買零件。但是，顧客確定了，該顧客所購買的零件就可以確定。因此，供應商和顧客之間是二元的多對多聯(lián)系；而零件和顧客之間是二元的一對多聯(lián)系。只有供應商和顧客確定了，才能確定一個供應聯(lián)系值；而顧客確定了，可以有一個唯一的零件值。供應商顧客供應MN零件購買M1局部ER模型的設計問題2：任何一個供應商可向任何一個顧客供應

問題3：任何一個供應商可向任何一個顧客提供零件，但某個供應商對某個顧客供應的零件是確定的。這個問題表示，當供應商和顧客確定了，供應商供應給顧客的零件也就確定了。對此只需定義一個二元聯(lián)系，而零件則可作為供應聯(lián)系的一個屬性。由以上討論可知，對于多個實體，是否應該定義成一個多元聯(lián)系的問題，不可一概而論，應該具體問題做具體分析，所定義的模式要能夠確切地表達問題的語義。局部ER模型的設計M供應商顧客供應N問題3：任何一個供應商可向任何一個顧客提供零件，但某個供應局部ER模型的設計學院系擁有N包含教職工11N③防止存在語義上的缺陷。主要原因是定義聯(lián)系時沒有弄清問題的語義，定義的結構無法提供所需要的信息。例如，一個學院擁有多名教教師以及一個學院包含多個系。問題1：如果給定一個職工號，并查詢該職工屬于哪一個系，那么由下圖可以確定該職工是哪一個學院的，但不能確定屬于該學院的哪一個系。局部ER模型的設計學院系擁有N包含教職工11N③防止存在語解決上述問題的方法是對ER圖作適當變換。局部ER模型的設計系教職工擁有1包含學院N1N系與教職工之間直接發(fā)生聯(lián)系，而且是一對多聯(lián)系。現(xiàn)在，給定一個職工號就可以確定該職工屬于哪一個系。解決上述問題的方法是對ER圖作適當變換。局部ER模型的設計問題2：如果某些教職工不屬于任何系而是直屬于學院的，那么就不能提供這方面的信息。因此這種結構仍缺乏語義信息。解決的方法是增加一個聯(lián)系（如增加學院─教職工間的“直屬”聯(lián)系），為直屬學院的教職工提供一個路徑。通過添加新的聯(lián)系解決了一些語義問題，但對有些情況，增加新的聯(lián)系會帶來新的語義問題。局部ER模型的設計系教職工擁有1包含學院N1N直屬添加“直屬”聯(lián)系問題2：如果某些教職工不屬于任何系而是直屬于學院的，那么就不局部ER模型的設計教師學生指導N工程參加MN職工號T001T002學號ST001ST002工程號P001P002指導參加具體事例為：這個實例中無法得到關于哪位教師指導哪個學生參加哪項工程的信息（如教師T001和T002指導學生ST001參加工程P001和P002）。改進的一種方法是再增加一個教師對工程的“服務”聯(lián)系。問題3：假定每個學生可在多名教師指導下參加多項工程。每位教師可指導多名學生，但只允許一位教師指導一個學生參加一項工程，而不允許多位教師指導一名學生參加某項工程。局部ER模型的設計教師學生指導N工程參加MN職工號學號工程號局部ER模型的設計學生工程指導N參加教師MMN服務添加“服務”聯(lián)系MN參加服務指導職工號T001T002學號ST001ST002工程號P001P002局部ER模型的設計學生工程指導N參加教師MMN服務添加“服務局部ER模型的設計學生工程教-學-工教師NPM三元聯(lián)系ER圖添加了“服務”聯(lián)系后的結構能夠確切地提供如下信息：職工號為T001的教師指導學號為ST001的學生參加工程號為P001的工程。職工號為T002的教師指導學號為ST002的學生參加工程號為P001的工程。但是，從上圖卻無法確定職工號為T002的教師指導學號為ST001的學生究竟參加了那一項工程?？梢?，有時增加了一個新的聯(lián)系雖然可以化解原來的語義問題，卻又產(chǎn)生了新的語義問題。解決該問題的方法是將教師、學生以及工程三個實體間的聯(lián)系定義成一個三元聯(lián)系。局部ER模型的設計學生工程教-學-工教師NPM局部ER模型的設計職工號+學號+工程號T001+ST001+P001T001+ST002+P002T002+ST001+P002T002+ST002+P001學號ST001ST002職工號T001T002工程號P001P002局部ER模型的設計學號職工號工程號局部ER模型的設計4.給實體及聯(lián)系加上描述屬性

為局部視圖中的每個實體和聯(lián)系加上所有必需的其他描述屬性。在需求分析階段，已收集了所有的數(shù)據(jù)對象。除了主鍵屬性外，還需將其他屬性分配給有關的實體或聯(lián)系。為使這種分配更合理，必須研究屬性之間的函數(shù)依賴關系并考慮其他一些準則，而這些不易于一般用戶理解。因此在概念結構設計階段，應該避免涉及這類問題，而主要應從用戶需求的概念上去識別實體或聯(lián)系應該有哪些描述屬性。例如，“學生”實體的描述屬性除了“學號”以外，還需要“姓名”、“性別”、“出生年月”、“家庭地址”、“入學時間”、“系別”、“專業(yè)”等屬性；而“課程”實體的描述屬性除了“課程號”屬性以外，還需要“課程名”、“學時數(shù)”、“學分”、“開設學期”、“課程類型”（必修或選修）等屬性。局部ER模型的設計4.給實體及聯(lián)系加上描述屬性聯(lián)系本身也可以有描述屬性。局部ER模型的設計學生學號姓名…專業(yè)課程課程號課程名課程類型…選修MN成績聯(lián)系本身也可以有描述屬性。局部ER模型的設計學生學號姓名…局部ER模型的設計教師職務姓名教師號出生日期工資獎金教師不變信息姓名教師號出生日期教師變動信息職務工資獎金教師號5.ER模型的操作

在數(shù)據(jù)庫設計過程中，常常要對ER圖進行種種變化。這種變化稱為ER模型的操作，包括實體類型、聯(lián)系類型和屬性的分裂、合并、增刪等。例6.6分裂方式有水平分裂和垂直分裂兩種。把教師分裂成男教師與女教師兩個實體類型，這是水平分裂。也可把教師中經(jīng)常變化的屬性組成一個實體類型，而把固定不變的屬性組成另一個實體類型，這是垂直分裂。局部ER模型的設計教師職務姓名教師號出生日期工資獎金教師不變局部ER模型的設計教師課程擔任MN教師課程主講輔導1MNN聯(lián)系類型分裂。下圖是教師擔任教學任務的ER圖，而“擔任”聯(lián)系類型可以分裂為“主講”和“輔導”兩個新的聯(lián)系類型。局部ER模型的設計教師課程擔任MN教師課程主講輔導1MNN聯(lián)局部ER模型的設計產(chǎn)品銷售產(chǎn)品號銷售量產(chǎn)品生產(chǎn)產(chǎn)品號產(chǎn)量產(chǎn)品產(chǎn)品號產(chǎn)量銷售量合并是分裂操作的逆過程。例如，有一個“產(chǎn)品銷售”實體，其屬性有“產(chǎn)品號”和“銷售額”，另一個“產(chǎn)品生產(chǎn)”實體，其屬性有“產(chǎn)品號”和“產(chǎn)量”，把它們合并操作如以下圖。局部ER模型的設計產(chǎn)品銷售產(chǎn)品號銷售量產(chǎn)品生產(chǎn)產(chǎn)品號產(chǎn)量產(chǎn)品局部ER模型的設計(a)(b)AA-CB-CBCAA-B-CBC但必須注意，對于聯(lián)系的合并，其類型必須是定義在相同的實體類型組合中，否則是不合法的合并，下圖所示的合并就是不合法的合并。局部ER模型的設計(a)(b)AA-CB-CBCAA-B-C局部ER模型的設計例6.7在人事管理系統(tǒng)中，社會關系的存在是以職工的存在為前提，即社會關系對于職工具有依賴聯(lián)系。又如商業(yè)應用系統(tǒng)中，顧客地址與顧客之間也有類似的聯(lián)系(一般顧客可以有若干個聯(lián)系地址)。1N職工具有社會關系1N顧客通訊地址6.弱實體與弱聯(lián)系

在現(xiàn)實世界中，有時某些實體對于另一些實體具有很強的依賴聯(lián)系，例如一個實體的存在必須以另一實體的存在為前提。一個實體對于另一些實體具有很強的依賴聯(lián)系，而且該實體主鍵的部分或全部從其依賴實體中獲得，稱該實體為弱實體。在ER模型中，弱實體用雙線矩形框表示。與弱實體的聯(lián)系，稱為弱聯(lián)系，用雙線菱形框表示。局部ER模型的設計例6.7在人事管理系統(tǒng)中，社會關系的存在局部ER模型的設計7.子類和超類子類和超類的概念最先出現(xiàn)在面向對象技術中。在現(xiàn)實世界中，實體類型之間可能存在著抽象與具體的聯(lián)系。譬如學校人事系統(tǒng)中有人員、教師、學生、本科生和研究生等實體類型。這些概念之間，“人員”是比“教師”、“學生”更為抽象，而“教師”、“學生”是比“人員”更為具體的概念。當?shù)蛯由陷^具體的實體類型表達了與之聯(lián)系的較高層上的更為一般實體類型的特殊情況時，就稱較高層上實體類型為超類型（supertype），簡稱超類；較低層上實體類型為子類型（subtype），簡稱子類。局部ER模型的設計7.子類和超類局部ER模型的設計子類和超類性質：子類與超類之間具有繼承性特點，即子類實體繼承超類實體的所有屬性。但子類實體本身還可以包含比超類實體更多的屬性。繼承性是通過子類實體和超類實體具有相同的實體標識符實現(xiàn)的。局部ER模型的設計子類和超類局部ER模型的設計教師本科生研究生人員學生在ER圖中，超類以兩端雙線的矩形框表示，并用加圈的弧線與其子類相連，子類本身仍用普通矩形框表示。例如學校人事管理系統(tǒng)中實體之間的聯(lián)系可用圖表示。相鄰的上層實體稱為超類實體，下層實體稱為子類實體。譬如“學生”是“人員”的子類實體，但又是“本科生”和“研究生”的超類實體。局部ER模型的設計教師本科生研究生人員學生在ER圖中，超類以全局ER模型設計全局ER模型設計全局ER模型的設計流程無局部ER模式確定公共實體類型合并兩個局部ER模式檢查并消除沖突還有未合并的局部模式有還有沖突嗎有屬性沖突：如，重量單位有的用公斤，有的用克。

結構沖突：同一對象在不同應用中的不同抽象；同一實體在不同局部ER圖中屬性的個數(shù)或次序不同；實體之間的聯(lián)系在不同的局部ER圖中呈現(xiàn)不同的類型

命名沖突：屬性名、實體名、聯(lián)系名之間存在同名異義或異名同義沖突全局ER模型的設計流程無局部ER模式確定公共實體類型合并兩全局ER模型的設計所有局部ER模型都設計好后，接下來就是把它們綜合成單一的全局概念結構。1.確定公共實體類型確定各局部結構中的公共實體類型。當系統(tǒng)較大時，可能有很多局部模式，這些局部ER模型是由不同的設計人員確定的，問題有：同一現(xiàn)實世界的對象可能給予不同的描述，有的作為實體類型，有的又作為聯(lián)系類型或屬性。實體類型名和鍵也可能不同。處理方法：根據(jù)實體類型名和鍵來認定公共實體類型。把同名實體類型作為公共實體類型的一類候選。把具有相同鍵的實體類型作為公共實體類型候選。全局ER模型的設計所有局部ER模型都設計好后，接下來就是把它全局ER模型的設計2.局部ER模型的合并合并的順序有時會影響處理效率和結果。合并原則是：首先進行兩兩合并；先合并那些現(xiàn)實世界中有聯(lián)系的局部結構；合并從公共實體類型開始，最后再加入獨立的局部結構。進行兩兩合并是為了減少合并工作的復雜性；合并原則是為了使合并結果的規(guī)模盡可能小。全局ER模型的設計2.局部ER模型的合并全局ER模型的設計3.消除沖突

局部ER模型之間的不一致的地方，稱之為沖突。⑴屬性沖突屬性域的沖突，即屬性值的類型、取值范圍或取值集合不同。例如，重量單位有的用公斤，有的用克。全局ER模型的設計3.消除沖突全局ER模型的設計⑵結構沖突同一對象在不同應用中的不同抽象，類型有：①如職工，在某個應用中為實體，而在另一應用中為屬性。②同一實體在不同局部ER圖中屬性組成不同，包括屬性個數(shù)、次序等。③實體之間的聯(lián)系在不同的局部ER圖中呈現(xiàn)不同的類型。如實體E1與E2在某一應用中是多對多聯(lián)系，而在另一應用中是一對多聯(lián)系；又如在某一應用中實體E1與E2發(fā)生聯(lián)系，而在另一應用中，實體E1、E2、E3三者之間有聯(lián)系等等。全局ER模型的設計⑵結構沖突全局ER模型的設計結構沖突解決方法：對于同一對象在不同的局部ER模型中產(chǎn)生不同的抽象，其解決方式是：把屬性變?yōu)閷嶓w或把實體變?yōu)閷傩?，使同一對象具有相同的抽象。對于同一個實體在不同ER模型中屬性組成不同，其解決方式為：取兩個分ER模型屬性的并，作為合并后的該實體屬性。對于實體間的相同聯(lián)系呈現(xiàn)的不同的類型，其解決方式為：根據(jù)具體應用的語義，對實體鍵的聯(lián)系作適當?shù)木C合或調整。全局ER模型的設計結構沖突解決方法：例6.8在教務管理信息系統(tǒng)中的系，在某一局部ER模型中為學生實體的屬性，而在另一局部ER模型中為一個單獨的實體，其實學生和系之間存在從屬關系，應該調整、合并為如圖所示。全局ER模型的設計系名稱聯(lián)系電話系主任所在地點編號姓名所在系所學專業(yè)學號學生性別屬于1N例6.8在教務管理信息系統(tǒng)中的系，在某一局部ER模型中為學全局ER模型的設計（a）姓名所在系所學專業(yè)學號學生性別學生籍貫政治面貌家庭住址姓名（b）(c)家庭住址姓名所在系所學專業(yè)學號學生性別籍貫政治面貌例6.9在教務管理信息系統(tǒng)中的學生實體，在某一局部ER模型由學號、姓名、性別、所在系、所學專業(yè)組成，其ER模型如圖(a)所示。而在另一局部ER模型則由姓名、政治面貌、籍貫、家庭住址組成，其ER模型如圖(b)所示，合并后如圖(c)所示。全局ER模型的設計（a）姓名所在系所學專業(yè)學號學生性別學生籍例6.10在工程管理系統(tǒng)中，產(chǎn)品與零件之間的多對多聯(lián)系如圖（a）所示。產(chǎn)品、零件和供應商三者實體間多對多聯(lián)系如圖（b）所示。因為它們的語義不同，所以不具有包含關系。將它們綜合起來合并成如圖的ER模型。(a)產(chǎn)品數(shù)量組成零件MN供應商產(chǎn)品數(shù)量供應零件MNP(b)組成(c)MN供應數(shù)量組成數(shù)量供應商產(chǎn)品零件組成NMP全局ER模型的設計例6.10在工程管理系統(tǒng)中，產(chǎn)品與零件之間的多對多聯(lián)系如全局ER模型的設計設計全局ER模型的目的不在于把若于局部ER模型形式上合并為一個ER模型，而在于消除沖突，使之成為能夠被全系統(tǒng)中所有用戶共同理解和接受的統(tǒng)一的概念模式。⑶命名沖突包括屬性名、實體名、聯(lián)系名之間的沖突。同名異義，即不同意義的對象具有相同的名字；異名同義，即同一意義的對象具有不同的名字。屬性沖突和命名沖突通常采用討論、協(xié)商等行政手段解決，結構沖突則要認真分析后才能解決。全局ER模型的設計設計全局ER模型的目的不在于把若于全局ER模型的設計4.全局模式的優(yōu)化在得到全局ER模型后，為了提高數(shù)據(jù)庫系統(tǒng)的效率，還應進一步依據(jù)處理需求對ER模型進行優(yōu)化。一個好的全局ER模型，除能準確、全面地反映用戶功能需求外，還應滿足下列條件：實體類型的個數(shù)盡可能少；實體類型所含屬性個數(shù)盡可能少；實體類型間無冗余聯(lián)系。這些條件不是絕對的，要視具體的信息需求與處理需求而定。全局ER模型的設計4.全局模式的優(yōu)化全局ER模型的設計全局ER模型的優(yōu)化原則：⑴相關實體類型的合并這里的合并不是前面的“公共實體類型”的合并，而是指相關實體類型的合并。一般在權衡利弊后可以把1:1聯(lián)系的兩個實體類型合并。具有相同鍵的實體類型常常是從不同角度刻畫現(xiàn)實世界，如果經(jīng)常需要同時處理這些實體類型，那么也有必要合并成一個實體類型。但這時可能會產(chǎn)生大量空值，因此，要對存儲代價、查詢效率進行權衡。全局ER模型的設計全局ER模型的優(yōu)化原則：全局ER模型的設計⑵冗余屬性的消除在綜合成全局ER模型后，可能產(chǎn)生全局范圍內的冗余屬性。例如，在教育統(tǒng)計數(shù)據(jù)庫的設計中，一個局部結構含有高校畢業(yè)生數(shù)、招生數(shù)、在校學生數(shù)和預計畢業(yè)生數(shù)；另一局部結構中含有在校學生數(shù)、分年級在校學生數(shù)、各專業(yè)在校學生數(shù)和各專業(yè)的預計畢業(yè)生數(shù)。各局部結構自身都無冗余，但綜合成一個全局ER模型時，在校學生數(shù)即成為冗余屬性，應予消除。一般同一非鍵的屬性出現(xiàn)在幾個實體類型中，或者一個屬性值可從其他屬性值導出，此時，應把這些冗余的屬性從全局模式中去掉。冗余屬性消除與否，也取決于它對存儲空間、訪問效率和維護代價的影響。有時為了兼顧訪問效率，有意保留冗余屬性。全局ER模型的設計⑵冗余屬性的消除全局ER模型的設計⑶冗余聯(lián)系的消除在全局模式中可能存在有冗余的聯(lián)系，通常利用規(guī)范化理論中函數(shù)依賴的概念消除冗余聯(lián)系。把所有局部ER模型綜合成最終的全局概念結構應滿足如下要求：全局概念結構內部必須具有一致性，不再存在各種沖突；全局概念結構能準確地反映原各局部視圖結構，包括屬性、實體及實體間的聯(lián)系；全局概念結構能滿足需求分析階段所確定的所有需求。全局概念結構最終還應該提交給用戶，征求用戶和有關人員的意見，進行評審、修改和調整，最后確定的全局概念結構為數(shù)據(jù)庫的邏輯設計提供依據(jù)。全局ER模型的設計⑶冗余聯(lián)系的消除概念結構設計實例實例1教務管理信息系統(tǒng)的全局ER圖。教務管理信息系統(tǒng)（簡化的）全局ER圖是由學生學籍管理ER圖、學生選課ER圖、課程管理ER圖以及成績管理ER圖組成。根據(jù)本章前面討論的局部ER圖，教務管理信息系統(tǒng)的全局ER圖模式如圖所示。學籍變動學號…變動日期專業(yè)學生學號…課程號課程…變動日期獎金教師號教師…講課成績M選課N11變動概念結構設計實例實例1教務管理信息系統(tǒng)的全局ER圖。概念結構設計實例實例2某廠產(chǎn)品生產(chǎn)及庫存綜合管理系統(tǒng)的概念結構設計。根據(jù)概念結構設計的步驟，先進行局部概念結構設計，然后再對各個局部概念進行綜合。⑴局部概念結構設計①確定局部概念結構的設計范圍。為討論簡單起見，對該綜合管理系統(tǒng)進行了簡化，只討論產(chǎn)品的設計、生產(chǎn)和存儲。②識別實體與實體的主鍵。產(chǎn)品及庫存綜合管理系統(tǒng)識別出的實體應有以下幾種：產(chǎn)品（主鍵：產(chǎn)品號或編號）、零件（主鍵：零件號）、材料（主鍵：材料名）、倉庫（主鍵：倉庫號）。③定義實體間的聯(lián)系。在技術部門的設計中，“產(chǎn)品”實體由“零件”實體組成，“零件”實體和“材料”實體通過消耗發(fā)生聯(lián)系，而且都是多對多聯(lián)系。可得技術部門局部模式圖，如下圖所示。概念結構設計實例實例2某廠產(chǎn)品生產(chǎn)及庫存綜合管理系統(tǒng)的概在生產(chǎn)部門的生產(chǎn)中，“產(chǎn)品”實體與“材料”實體通過“使用”聯(lián)系在一起，而且是多對多聯(lián)系?？傻蒙a(chǎn)部門局部ER模型，如下圖所示。概念結構設計實例產(chǎn)品零件組成MN材料消耗MN產(chǎn)品材料使用MN在材料庫存中，“材料”實體與“倉庫”實體通過“存放”聯(lián)系在一起。而且是多對多聯(lián)系。可得工廠材料庫存局部ER模型，如圖所示。

材料倉庫存放MN④給實體及聯(lián)系加上描述屬性給實體和聯(lián)系加上描述屬性應根據(jù)具體的應用需求而定，本書的實例內容是簡化的，在具體的系統(tǒng)設計中根據(jù)需求分析來確定。如下圖(a)、(b)、(c)分別是技術部門的ER圖、生產(chǎn)部門的ER圖、材料庫存管理的ER圖。在生產(chǎn)部門的生產(chǎn)中，“產(chǎn)品”實體與“材料”實體通過“使用”聯(lián)概念結構設計實例耗用量組成產(chǎn)品性能參數(shù)產(chǎn)品號零件零件號規(guī)格材料材料名消耗零件數(shù)(a)使用量使用產(chǎn)品編號價格庫存量材料材料名價格倉庫號(b）(c）存放量存放材料編號價格材料名庫存量倉庫號倉庫面積地點概念結構設計實例耗用量組成產(chǎn)品性能參數(shù)產(chǎn)品號零件零件號規(guī)格材概念結構設計實例⑵全局概念結構設計①沖突問題屬性域沖突：屬性值的類型、取值范圍或取值集合不相同等。該例中沒有涉及具體企業(yè)應用對象和實際數(shù)據(jù)，在實際應用時，可通過各部門或不同應用設計人員間相互討論、協(xié)商的方式加以解決。命名沖突：分析產(chǎn)品實體在兩個不同應用中的屬性描述，這里編號就是產(chǎn)品號，將兩個不同應用部門關于該屬性的名稱統(tǒng)一稱為產(chǎn)品號。結構沖突：顯然，倉庫對象在兩個局部應用中具有不同的抽象，在生產(chǎn)部門作為材料實體的屬性，而在倉庫管理的局部ER模型中它是一個單獨的實體，為使同一對象倉庫具有相同的抽象，必須在合并時把倉庫統(tǒng)一作為實體加以處理。本例中的另一個結構沖突，是產(chǎn)品實體在兩個分ER模型中屬性組成部分不同的問題，取分ER模型產(chǎn)品實體屬性的并，然后統(tǒng)一屬性名稱，形成對產(chǎn)品實體新的描述，如下圖所示。概念結構設計實例⑵全局概念結構設計在解決上述有關沖突后，綜合各局部ER模型可形成如下圖所示初步的全局ER模型。概念結構設計實例產(chǎn)品性能參數(shù)產(chǎn)品號+編號產(chǎn)品價格產(chǎn)品性能參數(shù)產(chǎn)品號價格合并在解決上述有關沖突后，綜合各局部ER模型可形成如下圖所示初步概念結構設計實例耗用量存放存放量倉庫號倉庫地點面積使用量產(chǎn)品性能參數(shù)產(chǎn)品號價格使用零件零件號消耗規(guī)格材料材料名編號庫存量價格組成零件數(shù)MMNN1N概念結構設計實例耗用量存放存放量倉庫號倉庫地點面積使用量產(chǎn)品②冗余問題。分析該ER模型的數(shù)量屬性可知，該初步ER模型存在著存放量、庫存量、使用量等屬性的冗余問題。消除這些冗余后，我們可以得到下圖所示的基本ER模型。概念結構設計實例存放量產(chǎn)品性能參數(shù)產(chǎn)品號價格組成零件數(shù)存放倉庫號倉庫地點面積耗用量零件零件號消耗規(guī)格材料材料名編號價格MN1N②冗余問題。分析該ER模型的數(shù)量屬性可知，該初步ER模型存在概念結構設計實例目前我們所產(chǎn)生的ER模型，僅僅是某企業(yè)工廠生產(chǎn)及材料庫存管理的一個基本概念模式，它表示了用戶的數(shù)據(jù)處理要求，是溝通用戶需求和系統(tǒng)設計的橋梁。要想把它確定下來作為最終概念模式，設計者還應提交給用戶，并與用戶反復討論、研究，同時征求用戶和有關人員的意見，進行評審、修改和優(yōu)化等工作，在用戶確認這一模式已正確無誤地反映了他們的需求后，才能作為最終的數(shù)據(jù)庫概念結構，進入下一階段的數(shù)據(jù)庫設計工作。概念結構設計實例目前我們所產(chǎn)生的ER模型，僅僅是某企業(yè)工廠生概念結構設計實例實例分析：某大學教務管理系統(tǒng)中包含三個部分：教師管理子系統(tǒng)；學籍管理子系統(tǒng)；課程管理子系統(tǒng)。在綜合過程中：學籍管理中的班主任和導師實際上也屬于教師，可以將其與課程管理中的“教師”實體合并；教師管理子系統(tǒng)中的實體項目“負責人”也屬于“教師”，所以也可以合并。注意：這里盡管實體可以合并，但聯(lián)系依然存在。概念結構設計實例實例分析：局部模式現(xiàn)有的教學管理系統(tǒng)初步分析系統(tǒng)的對象根據(jù)服務種類分析教師子模塊……局部ER圖局部模式現(xiàn)有的教學初步分析系統(tǒng)的對象根據(jù)服務種類分析教師子模其他局部模式

現(xiàn)有的教學管理系統(tǒng)初步分析系統(tǒng)的對象根據(jù)服務種類分析學生子模塊……圖5.21學籍管理局部應用的分E-R圖導師班級學生組成管理班主任檔案材料宿舍住宿歸檔指導系有參加學會1N111NNN11NMN1具有社會關系1N局部ER圖其他局部模式

現(xiàn)有的教學初步分析系統(tǒng)的對象根據(jù)服務種類分析學其他局部模式現(xiàn)有的教學管理系統(tǒng)初步分析系統(tǒng)的對象根據(jù)服務種類分析課程子模塊……局部ER圖圖5.22課程管理局部應用分E-R圖1教室M1教科書教師擔任課程系開設N1學生選修NMN上課PN其他局部模式現(xiàn)有的教學初步分析系統(tǒng)的對象根據(jù)服務種類分析課程例子：三個局部ER圖合并成一個ER圖1圖5.24合并后的教學管理E-R圖1N1P1N1N1N1MMNNNN社會關系具有1NNM1系聘用承接項目參加設置院長學院主管NN111教師評定職稱分配工作量111N檔案材料歸檔參加學會1宿舍住宿教科書擔任指導課程選修教室上課有1班級學生組成N開設N管理11教師管理11合并后的教學管理ER圖例子：三個局部ER圖合并成一個ER圖1圖5.24合并后的教6.4邏輯結構設計6.4邏輯結構設計主要內容ER模型向關系模型的轉換關系模式的優(yōu)化主要內容ER模型向關系模型的轉換6.4.1邏輯結構設計概念結構設計的結果是得到一個與DBMS無關的概念模式。而邏輯設計的目的是把概念結構設計階段設計好的全局ER模型轉換成與選用的具體機器上的DBMS所支持的數(shù)據(jù)模式相符合的邏輯結構（包括數(shù)據(jù)庫模式和外模式）。邏輯結構設計可以運用關系數(shù)據(jù)庫模式設計理論使設計過程形式化地進行，并且結果可以驗證。關系數(shù)據(jù)庫的邏輯結構設計的過程如右圖所示。處理需求ER模型DBMS特征從ER模型導出初始數(shù)據(jù)庫模式關系模式規(guī)范化模式評價是否需要修正模式修正用DBMS語法描述進入物理設計階段是否6.4.1邏輯結構設計概念結構設計的結果是得到一個與DBMSER模型向關系模式的轉換將ER模型轉換為關系模式實際上就是要將實體、實體的屬性和實體間的聯(lián)系轉換為關系模式的過程。其原則是:1.實體類型的轉換將每個實體類型轉換成一個關系模式，實體的屬性即為關系的屬性，實體標識符即為關系模式的鍵。2.聯(lián)系類型的轉換聯(lián)系類型轉換成關系模式是根據(jù)不同的情況做不同的處理。ER模型向關系模式的轉換將ER模型轉換為關系模式實際上就是要ER模型向關系模式的轉換⑴實體間的聯(lián)系是1:1的可以在兩個實體類型轉換成的兩個關系模式中的任意一個關系模式的屬性中加入另一個關系模式的鍵和聯(lián)系類型的屬性。例如某學校管理中的實體“校長”與“學?！敝g存在著1:1的聯(lián)系，在將其轉化為關系模式時，“校長”與“學校”各為一個關系模式。如果用戶經(jīng)常要在查詢學校信息時同時查詢其校長信息，那么可在學校模式中加入校長名和任職年月，其關系模式設計如下（加下劃線者為主鍵，加波浪線者為外鍵）：學校關系模式（學校名，地址，電話，校長名，任職年月）校長關系模式（校長名，年齡，性別，職稱）ER模型向關系模式的轉換⑴實體間的聯(lián)系是1:1的ER模型向關系模式的轉換⑵實體間的聯(lián)系是1:N的則在N端實體類型轉換成的關系模式中加入1端實體類型轉換成的關系模式的鍵和聯(lián)系類型的屬性。例如某學校管理中的實體“系”與“教師”之間存在著1:N的聯(lián)系，其轉換成的關系模式如下：系關系模式（系編號，系名，電話，系主任）教師關系模式（教師編號，姓名，年齡，性別，職稱，系編號，聘用年月）ER模型向關系模式的轉換⑵實體間的聯(lián)系是1:N的ER模型向關系模式的轉換⑶弱實體若實體間的聯(lián)系是1:N的，而且在N端實體類型為弱實體，轉換成的關系模式中將1端實體類型（父表）的鍵作為外鍵放在N端的弱實體（子表）中。弱實體的主鍵由父表的主鍵與弱實體本身的候選鍵組成。也可以為弱實體建立新的獨立的標識符ID。例如某學校管理中的實體“學生”與弱實體“社會關系”之間存在著1:N的聯(lián)系，其ER圖如下圖所示。ER模型向關系模式的轉換⑶弱實體ER模型向關系模式的轉換1N學生具有社會關系班號姓名所在系學生編號年齡性別家庭住址姓名年齡稱呼政治面貌工作單位轉換成的關系模式如下：學生關系模式（學生編號，姓名，年齡，性別，家庭住址，所在系，班號）社會關系模式（學生編號，稱呼，姓名，年齡，政治面貌，工作單位）ER模型向關系模式的轉換1N學生具有社會關系班號姓名所在系學ER模型向關系模式的轉換MN選修學生班號姓名所在系學生編號年齡性別家庭住址開課系編號開課學期課程課程名課程編號課程性質學分數(shù)先行課成績⑷實體間的聯(lián)系是M:N的將聯(lián)系類型也轉換成關系模式，其屬性為兩端實體類型的鍵加上聯(lián)系類型的屬性，而鍵為兩端實體鍵的組合。例如某學校管理中的實體“學生”與“課程”之間存在著M:N的聯(lián)系，其ER圖如圖所示。ER模型向關系模式的轉換MN選修學生班號姓名所在系學生編號年ER模型向關系模式的轉換轉換成的關系模式如下：學生關系模式（學生編號，姓名，年齡，性別，家庭地址，所在系，班號）課程關系模式（課程編號，課程名，課程性質，學分數(shù)，先行課，開課學期，開課系編號）選修關系模式（學生編號，課程編號，成績）ER模型向關系模式的轉換轉換成的關系模式如下：3.超類和子類的轉換

將超類和子類各轉換成一個關系模式，在子類轉換成的關系模式（子表）中加入超類轉換成關系模式（父表）的鍵，從而實現(xiàn)父表與子表的聯(lián)系。由于父表與子表的主鍵相同，所以子表的主鍵也是外鍵。

下圖為學校人事管理系統(tǒng)中的人員、教師、學生、本科生、研究生的繼承性層次聯(lián)系圖。，教師本科生研究生人員學生這個結構轉換成的關系模式如下：

人員（身份證號，姓名，年齡，性別）教師（身份證號，教師編號，職稱）學生（身份證號，學號，系別，專業(yè)）本科生（身份證號，入學年份）研究生（身份證號，研究方向，導師姓名）ER模型向關系模式的轉換3.超類和子類的轉換下圖為學校人事管理系統(tǒng)中的人員、教6.4.2關系模式的優(yōu)化在關系數(shù)據(jù)庫的邏輯設計中，先是利用ER模型向關系模式轉換規(guī)則初步得到一組關系模式集后，還應該再適當?shù)匦薷?、調整關系模式的結構，以進一步提高數(shù)據(jù)庫應用系統(tǒng)的性能，這個過程稱為關系模式的優(yōu)化。6.4.2關系模式的優(yōu)化在關系數(shù)據(jù)庫的邏輯設計中，先是利用E關系模式的優(yōu)化優(yōu)化關系模式的方法：

⑴確定函數(shù)依賴根據(jù)需求分析階段所得到的數(shù)據(jù)的語義，分別寫出每個關系模式內部各屬性之間的函數(shù)依賴以及不同關系模式屬性之間函數(shù)依賴。例如，學生關系模式內部存在下列函數(shù)依賴：學號→姓名，學號→性別，學號→出生年月，學號→所在系，學號→班級，…。課程關系模式內部存在下列函數(shù)依賴：課程號→課程名，課程號→學時數(shù)，課程號→學分，課程號→開設學期，…。選修關系模式中存在下列函數(shù)依賴：學號，課程號）→成績學生關系模式的學號與選修關系模式的學號之間存在函數(shù)依賴：學生.學號→選修.學號關系模式的優(yōu)化優(yōu)化關系模式的方法：關系模式的優(yōu)化⑵可用實體候選鍵之間的函數(shù)依賴來表示不同實體間的一對一、一對多、多對多的聯(lián)系，然后對函數(shù)依賴進行最小化處理，消除冗余的聯(lián)系。⑶根據(jù)規(guī)范化理論對關系模式逐一進行分析，檢查是否存在部分函數(shù)依賴、傳遞函數(shù)依賴等，確定各關系模式分別屬于第幾范式。⑷根據(jù)需求分析階段得到的各種應用及對數(shù)據(jù)處理的要求，分析所在的應用環(huán)境中這些關系模式是否合適，確定是否要對它們進行合并或分解。關系模式的優(yōu)化⑵可用實體候選鍵之間的函數(shù)依賴來表示不同實體關系模式的優(yōu)化關于關系模式的規(guī)范化問題，做如下兩點說明：并不是規(guī)范化程度越高的關系就越好。當一個應用的查詢中經(jīng)常涉及到兩個或多個關系模式的屬性時，系統(tǒng)必須經(jīng)常地進行連接運算，而連接運算的代價是相當高的，可以說關系模式操作低效的主要原因就是做連接運算引起的。在這種情況下，第二范式甚至第一范式也許是最好的。如果一個關系模式在實際應用中只是提供查詢，并不提供更新操作，或者很少提供更新操作，此時不會存在更新異常問題或更新異常不是主要問題，可以不對關系模式進行分解。關系模式的優(yōu)化關于關系模式的規(guī)范化問題，做如下兩點說明：關系模式的優(yōu)化例如，在關系模式學生成績單（學號，英語，數(shù)學，語文，平均成績）中存在下列函數(shù)依賴：學號→英語，學號→數(shù)學，學號→語文，學號→平均成績，（英語，數(shù)學，語文）→平均成績根據(jù)合并規(guī)則可得：學號→(英語，數(shù)學，語文)因此，“學號→平均成績”是傳遞函數(shù)依賴。由于關系模式中存在傳遞函數(shù)依賴，所以是2NF關系。雖然平均成績可以由其他屬性推算出來，但如果應用中需要經(jīng)常查詢學生的平均成績，為了提高查詢效率，關系模式中仍然可保留該冗余數(shù)據(jù)，對關系模式不再做進一步分解。對于一個具體應用來說，規(guī)范化應進行到什么程度，需要根據(jù)具體情況而定。一般來說，關系模式達到第三范式就能獲得比較滿意的效果。關系模式的優(yōu)化例如，在關系模式學生成績單（學號，英語，數(shù)學，關系模式的優(yōu)化⑸對關系模式進行必要的分解，以提高數(shù)據(jù)操作的效率和存儲空間的利用率。常用的分解方法有兩種：水平分解和垂直分解。①水平分解。所謂水平分解是指把一個關系模式R中的元組分為若干子集合，定義每個子集合為一個子關系，以提高系統(tǒng)的效率。例如有一個產(chǎn)品關系模式，其中包含有出口產(chǎn)品和內銷產(chǎn)品兩類數(shù)據(jù)。由于不同的應用對應不同的產(chǎn)品，如一個應用只對應進口產(chǎn)品，而另一個應用只對應內銷產(chǎn)品。因此，可將產(chǎn)品關系模式進行水平分解，分解為兩個關系模式，一個存放出口產(chǎn)品數(shù)據(jù)，另一個存放內銷產(chǎn)品數(shù)據(jù)。產(chǎn)品號產(chǎn)品名型號規(guī)格………………………產(chǎn)品號產(chǎn)品名型號規(guī)格………………………出口產(chǎn)品內銷產(chǎn)品關系模式的優(yōu)化⑸對關系模式進行必要的分解，以提高數(shù)據(jù)操作的關系模式的優(yōu)化②垂直分解。所謂垂直分解是把一個關系模式R的屬性分解為若干子集合，形成若干子關系模式。例如有一個職工關系模式，其中含有“職工號”、“職工名”、“性別”、“職務”、“職稱”、“出生日期”、“地址”、“郵編”、“電話”、“所在部門”等描述屬性。如果應用中經(jīng)常存取的數(shù)據(jù)是職工號、職工名、性別、職務以及職稱，而其他數(shù)據(jù)很少使用，則可以對職工關系模式進行垂直分解，即分解為兩個關系模式，一個存放經(jīng)常使用的數(shù)據(jù)，另一個存放不常使用的數(shù)據(jù)。職工號職工名性別職務……………………………職工號出生日期地址郵編……………………………職工1職工2關系模式的優(yōu)化②垂直分解。所謂垂直分解是把一個關系模式R的關系模式的優(yōu)化垂直分解的原則為：凡是經(jīng)常在一起使用的屬性從R中分解出來形成一個子關系模式，這樣也可以提高數(shù)據(jù)操作的效率。垂直分解的好處是可以提高某些事務的效率；不足之處是可能會使得另一些事務不得不執(zhí)行連接操作，從而降低效率。是否需要垂直分解，取決于分解后R上的所有事務的總效率是否得到了提高。垂直分解的方法可以采用簡單的直觀分解，也可以用關系模式分解算法進行分解。需要注意的是，垂直分解必須以不損失關系模式的語義（保持無損連接性和保持函數(shù)依賴性）為前提。關系模式的優(yōu)化垂直分解的原則為：凡是經(jīng)常在一起使用的屬性從R關系模式的優(yōu)化例6.11假設有一個選課關系：選修課程（學號，姓名，年齡，課程名稱，成績，學分）。請分析該關系屬于第幾范式？如果應用中需要常常對選修課程關系進行增、刪、改操作，該關系存在什么問題？并對其設計進行優(yōu)化。解：由于每個學生可能選修多門課程，而每門課程對應一個成績。因此，該關系的候選關鍵字為（學號，課程名稱）。根據(jù)數(shù)據(jù)的語義，該關系上存在的函數(shù)依賴集為：（學號，課程名稱）→（姓名，年齡，成績，學分），課程名稱→學分，學號→（姓名，年齡）。由于（學號，課程名稱）→（姓名，年齡），而（學號，課程名稱）的子集“學號”也能函數(shù)確定一個學生的姓名和年齡，即學號→（姓名，年齡）。該關系存在非主屬性對候選鍵的部分函數(shù)依賴，因此，選修課程關系屬于第一范式，且存在以下問題：關系模式的優(yōu)化例6.11假設有一個選課關系：選修課程（學號關系模式的優(yōu)化⑴數(shù)據(jù)冗余：如果同一門課程由多個學生選修，“學分”就會重復多次；如果同一個學生選修了多門課程，該學生的姓名和年齡就會重復多次。⑵更新異常：若調整了某門課程的學分，則數(shù)據(jù)表中該門課程所有行的“學分”值都要更新，否則會出現(xiàn)同一門課程學分不同的情況．⑶插入異常：假定要開設一門新的課程，暫時還沒有人選修。此時，由于候選鍵中“學號”沒有值，所以課程名稱和學分也無法插入數(shù)據(jù)庫。⑷刪除異常：假設有一批學生已經(jīng)完成課程的選修，這些選修記錄就應該從選修課程數(shù)據(jù)表中刪除。但與此同時，課程名稱和學分信息也有可能被刪除。由于選修課程關系中的數(shù)據(jù)需要經(jīng)常更新，所以必須解決上述可能出現(xiàn)的操作異常。通過對關系進行分解，可將選修課程關系分解為以下三個表：關系模式的優(yōu)化⑴數(shù)據(jù)冗余：如果同一門課程由多個學生選修，關系模式的優(yōu)化學生（學號，姓名，年齡）課程（課程名稱，學分）選課（學號，課程名稱，成績）其中，學生關系上的候選鍵為“學號”，函數(shù)依賴集為：{學號→姓名，學號→年齡}由于不存在非主屬性對候選鍵的部分函數(shù)依賴和傳遞函數(shù)依賴，因此，學生關系屬于第三范式。課程關系上的候選鍵為“課程名稱”，函數(shù)依賴為：課程名稱→學分由于不存在非主屬性對候選鍵的部分函數(shù)依賴和傳遞函數(shù)依賴，因此，課程關系也屬于第三范式。關系模式的優(yōu)化學生（學號，姓名，年齡）關系模式的優(yōu)化選課關系上的候選鍵為{學號，課程名稱}，函數(shù)依賴為：{學號，課程名稱}→成績由于不存在非主屬性對候選鍵的部分函數(shù)依賴和傳遞函數(shù)依賴，因此，選課關系也屬于第三范式。如果需要增加、刪除以及修改學生信息，則只需對學生關系進行操作。如果需要增加、刪除以及修改課程信息，則只需對課程關系進行操作。如果需要增加、刪除以及選課信息，則只需對選課關系進行操作。另外，如果應用中的查詢常常是統(tǒng)計學生的選課情況，則分解后帶來的自然連接操作很少。因此，這樣的設計是合理的。以上通過對關系選修課程的分解，各關系上的函數(shù)依賴集以及不同關系模式之間的函數(shù)依賴已是最小函數(shù)依賴集，并且消除了數(shù)據(jù)冗余和操作異常。因此，關系模式得到了優(yōu)化。關系模式的優(yōu)化選課關系上的候選鍵為{學號，課程名稱}，6.5物理結構設計6.5物理結構設計物理結構設計物理設計過程示意圖不滿意數(shù)據(jù)庫模式操作模式存儲設備特征DBMS特征物理結構設計是否需要修正結束滿意對于給定的基本數(shù)據(jù)模式選取一個最適合應用環(huán)境的物理結構的過程，稱為物理結構設計。數(shù)據(jù)庫的物理結構主要指數(shù)據(jù)庫的存儲記錄格式、存儲記錄安排和存取方法。顯然，數(shù)據(jù)庫的物理設計是完全依賴于給定的硬件環(huán)境和數(shù)據(jù)庫產(chǎn)品的。數(shù)據(jù)庫的物理設計示意圖如下圖所示。物理結構設計物理設計過程示意圖不滿意數(shù)據(jù)庫模式物理結構設計物理設計的步驟：

⑴存儲記錄結構設計：包括記錄的組成、數(shù)據(jù)項的類型、長度，以及邏輯記錄到存儲記錄的映射。⑵確定數(shù)據(jù)存放位置：可以把經(jīng)常同時被訪問的數(shù)據(jù)組合在一起，“記錄聚簇（Clus-Ter）”技術能滿足這個要求。⑶存取方法的設計：存取路徑分為主存取路徑與輔存取路徑，前者用于主鍵檢索，后者用于輔助鍵檢索。⑷完整性和安全性考慮：設計者應在完整性、安全性、有效性和效率方面進行分析，作出權衡。⑸程序設計：在邏輯數(shù)據(jù)庫結構確定后，應用程序設計就應當隨之開始。物理數(shù)據(jù)獨立性的目的是消除由于物理結構的改變而引起對應用程序的修改。當物理獨立性未得到保證時，可能會發(fā)生對程序的修改。物理結構設計物理設計的步驟：6.6數(shù)據(jù)庫的實現(xiàn)6.6數(shù)據(jù)庫的實現(xiàn)6.6數(shù)據(jù)庫的實現(xiàn)根據(jù)邏輯設計和物理設計的結果，在計算機系統(tǒng)上建立起實際數(shù)據(jù)庫結構、裝入數(shù)據(jù)、測試和試運行的過程稱為數(shù)據(jù)庫的實現(xiàn)階段。數(shù)據(jù)庫的實現(xiàn)階段主要有三項工作：

⑴建立實際數(shù)據(jù)庫結構。對描述邏輯設計和物理設計結果的程序（即“源模式”）經(jīng)DBMS編譯成目標模式和執(zhí)行后建立了實際的數(shù)據(jù)庫結構。⑵裝入試驗數(shù)據(jù)對應用程序進行調試。試驗數(shù)據(jù)可以是實際數(shù)據(jù)，也可由手工生成或用隨機數(shù)發(fā)生器生成。應使測試數(shù)據(jù)盡可能覆蓋現(xiàn)實世界的各種情況。⑶裝入實際數(shù)據(jù)，進入試運行狀態(tài)。測試系統(tǒng)的性能指標，是否符