數據庫原理與設計第4章數據庫設計數據庫設計概述

需求分析概念結構設計邏輯結構設計物理結構設計數據庫實施與維護數據庫建模工具第5章數據庫設計數據庫設計任務

數據庫設計是指對于給定的應用環境，構造最優的數據模式，建立數據庫及其應用系統，使之能有效地存儲數據，滿足用戶的信息需求和處理需求。即把現實世界中的數據，根據應用處理的要求，合理組織，滿足各種用戶的應用需求，包括信息管理要求和數據操作要求。數據庫設計與應用環境結合非常緊密，因此設計一個好的數據庫并不是一件簡單的事情。設計人員除了需要掌握數據庫與軟件的基礎知識，還需要掌握應用領域的專業知識。一般的計算機專業人員掌握數據庫與軟件的基礎知識，但缺乏應用領域知識。而用戶雖然具有豐富的應用領域知識，卻沒有相關的計算機基礎。設計人員常常是根據經驗進行數據庫設計，缺乏和用戶的溝通，這樣設計出來的數據庫存在很大的隱患，如數據模型不能準確反映用戶的實際情況，不能方便進行數據庫應用程序的開發。因此數據庫設計需要遵循一定的理論指導，采用規范的設計方法，根據用戶的需求，進行分析、歸納、抽象，設計出符合實際情況的數據模型，選擇一種符合要求的數據庫管理系統，最終實現對數據模型及數據的管理。數據庫設計方法

新奧爾良方法基于E-R模型的數據庫設計方法基于3NF的數據庫設計方法計算機輔助數據庫設計方法ODL方法數據庫設計的步驟1．需求分析獲取用戶需求，了解相關領域的業務知識，包括應用系統的應用環境和功能要求、具體業務處理方式等。2．概念結構設計歸納與抽象需求分析階段的分析結果，進行必要的，形成獨立于具體DBMS的概念結構。3．邏輯結構設計將概念結構轉換為某個具體DBMS所支持的數據模型，并進行優化。4．物理結構設計物理結構設計階段為邏輯模型選取合適的物理結構。5．數據庫實施根據邏輯結構，創建數據庫。編寫應用程序和SQL程序，組織數據遷移，進行試運行。6．數據庫運行和維護數據庫運行階段需要不斷維護，分析數據庫性能，調整性能參數。對數據庫的運行數據進行備份、恢復和處理等。需求分析需求分析就是分析用戶的需要與要求，確定系統必須完成哪些工作，對系統提出完整、準確、清晰、具體的要求。

調查現實世界要處理的對象（組織、部門、企業等）了解業務處理、處理的流程用戶希望數據庫應用程序的功能了解用戶對系統的信息要求、處理要求以及安全性與完整性要求、處理的響應時間需求分析的方法①親自參與業務活動，了解業務處理的基本情況。②請專人介紹。③通過與用戶座談、詢問等方式來解決疑問。④設計調查表請用戶填寫。⑤查閱記錄。⑥學習文件。⑦使用舊系統。數據流圖與數據字典數據流是數據在系統內的傳輸途徑，數據流圖從數據傳遞和加工的角度，以圖形的方式刻畫數據流從輸入到輸出的變換過程。數據流圖是結構化系統分析的主要工具，它去掉了具體的組織機構、工作場所、物質流等，僅反映信息和數據存儲、流動、使用以及加工的情況。數據字典是各類數據描述的集合。通常包括數據項、數據結構、數據流、數據存儲、處理過程和外部實體等6個部分。數據字典通過對數據項和數據結構的定義來描述數據流、數據存儲的邏輯內容。數據流圖基本元素數據流圖的基本元素包括數據流、加工、數據存取文件、輸入數據的源點和輸出數據的匯點4類。

數據流圖（2）繪制數據流圖時，應先找出系統的數據源點與匯點及對應的輸出數據流與輸入數據流，然后從輸入數據流（即系統的源點）出發，按照系統的邏輯需要，逐步畫出系列邏輯加工，直到所需的輸出數據流（即系統的匯點），形成數據流的封閉。數據流圖中常見的加工關系分層數據流圖較復雜的實際問題中，僅用一個數據流圖很難表達數據處理過程和數據加工情況，需要按照問題的層次結構逐步分解，并以分層的數據流圖反映這種結構關系。首先確定頂層數據流圖，把整個數據處理過程暫且看成一個加工，它的輸入數據和輸出數據實際上反映了系統與外界環境的接口，這就是頂層數據流圖。在頂層數據流圖的基礎上進一步細化。形成第一層數據流圖，繼續分解，可得到第二層數據流圖。如此細化直到清晰地表達整個數據加工系統的真實情況。

分層數據流圖（2）畫數據流圖的步驟和原則①

頂層數據流圖上的數據流必須封閉在外部實體之間。②

每個加工至少有一個輸入數據流和一個輸出數據流。③

在數據流圖中，需按層給加工進行編號。編號應表明該加工處在哪一層，以及與上下層的父圖與子圖的對應關系。④

任何一個數據流子圖必須與它上一層的一個加工對應，兩者的輸入數據流和輸出數據流必須一致，即父圖與子圖平衡。⑤

圖上每個元素都必須有名字。一般來說數據流和數據文件的名字應當表明流動的數據是什么，加工的名字應當表明做什么事情。⑥

數據流圖中不可夾帶控制流。

數據字典（1）數據項數據項是數據的最小組成單位，若干個數據項可以組成一個數據結構。數據項描述={數據項名，數據項含義說明，別名，數據類型，長度，取值范圍，取值含義，與其他數據項的邏輯關系}（2）數據結構數據結構反映了數據之間的組合關系。一個數據結構可以由若干個數據項組成，也可以由若干個數據結構組成（嵌套數據結構），或由若干個數據項和數據結構混合組成。數據結構描述={數據結構名，含義說明，組成：{數據項或數據結構}}}（3）數據流數據流是數據結構在系統內的傳輸路徑。數據流描述={數據流名，說明，數據流來源，數據流去向，組成：{數據結構}，平均流量，高峰期流量}一般說來，數據字典應包括數據項、數據結構、數據流、數據存儲、處理過程、外部實體等六類元素。數據字典（2）

（4）數據存儲數據存儲是數據結構停留或保存的地方。：數據存儲描述={數據存儲名，說明，編號，流入的數據流，流出的數據流，組成：{數據結構}，數據量，存取方式}（5）處理過程處理過程應描述處理邏輯的功能，詳細地描述其輸入輸出的數據流以及這些數據的基本轉換路徑和策略說明性信息。處理過程描述={處理過程名，編號，說明，輸入：{數據流}，輸出：{數據流}，處理：{簡要說明}}（6）外部實體外部實體是系統的“人—機”界面，系統的數據流由外部實體流入，經過加工處理之后，向外部實體流出。外部實體描述={外部實體的名稱，編號，輸入：{數據流}，輸出：{數據流}}學籍管理需求分析功能序號功能名稱功

能

說

明1學生管理登記學生的基本信息（姓名、性別、班級等），并提供查詢功能2課程管理登記課程基本情況（課程名稱、開課學期、課程類型、學分等），提供查詢3教師管理登記教師基本情況（姓名、年齡、性別、學歷等），提供查詢統計4成績管理登記學生各門課程的考試成績、提供查詢、統計功能5授課管理登記教師講授課程、授課地點、和授課學期，提供查詢功能6編碼維護維護系統中使用的編碼（如職稱編碼、學院編碼、班級編碼等）分析設計頂層數據流圖學籍管理的1層數據流圖

細化成績管理細化成績錄入制定整理數據字典分析成績錄入數據流圖，該數據流圖涉及學生名單、學號姓名、選定刪除的學號姓名、選定修改的學號姓名等數據流，同時涉及學生信息、考試成績等數據存儲，包括班級學生名單查詢、班級學生名單顯示、增加學生成績、修改成績、刪除成績、成績查詢等處理過程。

概念結構設計概念結構設計有以下特點：（1）能真實、充分地反映現實世界，包括現實世界中實體及實體之間的聯系。（2）易于修改。當應用環境和應用要求改變時，概念模型可以很容易地作相應調整。（3）易于理解。用概念模型與不熟悉計算機的用戶交換意見，用戶不必知道DBMS的技術細節，用戶能積極參與是數據庫設計成功的關鍵。（4）易于向關系、網狀、層次等各種數據模型轉換。（5）概念模型不受具體的DBMS的限制，獨立于數據庫邏輯結構，因此更穩定。概念結構設計的方法概念結構設計可以采用自頂向下、自底向上、逐步擴張、混合策略等方法。自頂向下在定義全局概念結構框架的基礎上逐步細化；自底向上先定義各局部應用的概念結構，然后進行集成，得到全局概念結構；逐步擴張在定義核心概念結構的基礎上，逐步向外擴充，生成其他概念結構，直至得到總體概念結構；混合策略采用自頂向下和自底向上的結合，自頂向下地設計一個全局概念結構，自底向上地設計各局部概念結構，在全局概念結構的基礎上進行局部概念集成。一般可以先抽象并設計局部視圖，然后集成局部視圖，形成全局的E-R圖。概念模型概念模型與信息的3個世界概念模型的表示方法（1）概念模型的其表示方法很多，其中最為常用的是P.P.S.Chen于1976年提出的實體—聯系方法（Entity-RelationshipApproach）。該方法用E-R圖來描述現實世界的概念模型。（1）實體（Entity）（2）屬性（Attribute）（3）碼（Key）（4）域（Domain）（5）實體型（EntityType）（6）實體間的聯系（Relationship）概念模型的表示方法（2）兩個實體型之間的聯系可以分為以下3類：一對一聯系（1∶1）、一對多聯系（1∶n）、多對多聯系（m∶n）數據抽象與局部視圖設計（2）需求分析階段會產生不同層次的數據流圖，這些數據流圖是進行概念結構設計的基礎。高層的數據流圖能反映系統的概貌，但包含的信息不足以描述系統的詳細情況，中層的數據流圖能較好地反映系統中各局部應用的子系統的詳細情況，因此中層數據流圖經常作為設計分E-R圖的依據。每個局部應用都對應了一組數據流圖與數據字典。將數據從數據字典中抽取出來，參照數據流圖，確定局部應用中的實體、實體的屬性、實體的碼，確定實體之間的聯系及其類型

確定實體及屬性①

屬性必須是不可分的數據項，不能包含其他屬性。②

屬性不能與其他實體具有聯系，與其他實體有聯系的屬性一般應按照實體處理。符合上述兩條特性的事物一般作為屬性對待。視圖集成依據不同的局部應用數據流圖設計的分E-R圖，進行視圖集成，將所有的分E-R圖綜合成一個系統的總E-R圖。一般說來，視圖的集成可以有兩種方式。①

多個分E-R圖一次集成。②

逐步集成，用累加的方式一次集成兩個分E-R圖。其中第1種方法比較復雜，實現起來難度較大。第2種方法每次只集成兩個分E-R圖，可以降低復雜度。視圖集成時需要進行分E-R圖的合并、修改、重構，解決各分E-R圖之間的沖突，消除不必要的冗余，形成基本E-R圖。

視圖集成（2）1．解決沖突，合并分E-R圖，形成初步E-R圖。

分E-R圖之間存在的不一致稱為沖突，各分E-R圖之間的沖突主要有3類屬性沖突命名沖突結構沖突2．消除不必要的冗余，設計基本E-R圖。

分E-R圖經過合并生成的是初步E-R圖，這種E-R圖中可能會存在冗余，還需要對其進行消除冗余處理。冗余包括兩種情況，數據冗余和聯系冗余，其中冗余數據是可由基本數據導出的數據，冗余聯系是指可由其他聯系導出的聯系。學籍管理概念結構設計1．數據抽象、確定實體及其屬性與碼2．確定實體間關系，設計分E-R圖3．合并分E-R圖，消除冗余，設計基本E-R圖。邏輯結構設計概念結構獨立于DBMS，需要將概念結構進一步轉化為與特定DBMS產品所支持的數據模型相符合的邏輯結構。DBMS產品可以支持關系、網狀、層次三種模型中的某一種，目前大多數應用系統都選用支持關系模型的DBMS。設計邏輯結構時首先要將概念結構轉化為關系模型，然后對數據模型進行優化。關系模型的邏輯結構是一組關系模式的集合，E-R圖則是由實體、實體屬性和實體之間的聯系3個要素組成的。所以將E-R圖轉換為關系模型實際上就是將實體、實體屬性和實體之間的聯系轉化為關系模式，并確定關系模式的屬性和碼。將實體轉換為關系模式一般將E-R圖中的實體轉化為一個關系模式。實體的屬性轉化為關系的屬性，實體的碼就是關系的碼。學生（學號，姓名，性別，出生日期）有時為了減少關系模式的數量，如果實體之間存在很大的相似性，而且數據量不大，可以考慮將這些實體轉化為一個統一的關系模式，該關系模式具有其他實體的屬性。為了區別不同的實體，可以增加實體類型的屬性。如：學歷、職稱、課程類型編碼等實體具有類似的屬性，即編碼和描述，而且這類維護信息不會很多，因此可以將學歷和職稱實體合并為以下編碼關系模式：（編碼，編碼類型，編碼描述）。

將實體間的聯系轉化成關系模式（1）1∶1的聯系

1∶1的聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。如果轉換為一個獨立的關系模式，則與該1∶1聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，每個實體的碼都可以是該關系模式的候選碼。如果與某一端對應的關系模式合并，則需要在該關系模式的屬性中加入另一個關系模式的碼和聯系本身的屬性。例如，教師與班級的“管理”聯系為1∶1聯系可以將其轉換為一個獨立的關系模型：管理（教師編號，班級編號）也可以將“管理”聯系與教師或班級的關系模式合并，如將“管理”聯系與班級模式合并為：班級（班級編號，班級名稱，教師編號）也可以將“管理”聯系與教師關系模式合并將實體間的聯系轉化成關系模式（2）

（2）1∶n的聯系

1∶n的聯系可以轉換為一個獨立的關系模式可以與n端對應的關系模式合并。如果轉換為一個獨立的關系模式，則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，而關系的碼為n端實體的碼。例如，學院與班級的“隸屬”聯系為1∶n聯系，一種方法是使其轉換為一個獨立的關系模式：隸屬（班級編號，學院編號）另一種方法是將其與班級關系模式合并，這時班級關系模式為：班級（班級編號、班級名稱、學院編號）將實體間的聯系轉化成關系模式（3）（3）m∶n的聯系m∶n聯系轉換為一個關系模式，與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性，關系的碼為各實體碼的組合。例如，“選課”聯系是一個m∶n聯系，可以將其轉化為一個關系模式：選課（學號，課程編號，成績）碼是學號與課程編號的組合。

關系模式的操作異常學籍管理數據庫，其關系模式SMD如下SMD（SNo，SName，SAge，CLno，MN，CNo，Score）（SNo，CNo）屬性的組合能唯一標識一個元組，所以（SNo，CNo）是該關系模式的主碼，但在進行數據庫的操作時，會出現以下幾方面的問題。SNoSNameSAgeCLnoMNCNoScore03001李剛22030001趙亦000056203001李剛22030001趙亦000087903005郝枚22030002李平000056303005郝枚22030002李平000088503005郝枚22030002李平000095403005郝枚22030002李平000067903007梁棟23030003李平000058103007梁棟23030003李平00008關系模式的操作異常(2)（1）數據冗余。每個班級編號和班主任名字的存儲次數等于該班的學生人數乘以每個學生選修的課程門數，同時學生的姓名、年齡也都要重復存儲多次，數據的冗余度很大，浪費了存儲空間。（2）插入異常。如果某個新班暫無學生注冊，則關于班級信息和班主任的信息無法插入到數據庫中。因為在這個關系模式中，（SNo，CNo）是主碼，根據關系的實體完整性約束，主碼的值不能為空，而這時沒有學生，SNo和CNo均無值，因此不能進行插入操作。另外，如果某個學生尚未選課，即CNo未知，實體完整性約束還規定，主碼的值不能部分為空，同樣也不能進行插入操作。關系模式的操作異常(3)（3）刪除異常。當某班學生全部畢業時，要刪除全部學生的記錄，這時班級編號、班主任也隨之刪除，而現實中這個班的班主任依然存在，但在數據庫中卻無法找到相應的信息。另外，如果某個學生本學期只選修一門課程00005，當他不再選修該課程時，本應該只刪去課程信息00005，但00005是主關系鍵的一部分，為保證實體體完整性，必須將整個元組一起刪掉，這樣，有關該學生的其他信息也隨之丟失。（4）更新異常。如果某學生改名，則該學生的所有記錄要要逐一修改SName的值；又如某班更換班主任，則屬于該班的學生記錄都要修改班主任的內容，稍有不慎，就有可能漏改某些記錄，這就會造成數據的不一致，破壞了數據的完整性。一個好的關系模式應該具備4個條件盡可能少的數據冗余；沒有插入異常；沒有刪除異常；沒有更新異常。函數依賴Y=X+5確定的映象關系Example1：R{Sno，Sname，Sdept}F={Sno→Sname，Sno→Sdept}Example2：R{Sno，Sdept，Mname，Cname，Grade}F={Sno→Sdept，Sdept→Mname，（Sno，Cname）→Grade}基本概念1、函數依賴定義：設R（U）是一個關系模式，U是R的屬性集合，X和Y是U的子集，對于R（U）的任何一個可能的關系r，如果r中不存在兩個元組，它們在X上的屬性值相同，而在Y上的屬性值不同，則稱“X函數確定Y”或“Y函數依賴于X”，記作X→Y。說明

a、函數依賴是指R的所有關系實例均要滿足的條件。b、函數依賴是語義范疇的概念。

c、數據庫設計者可對現實世界作強制規定。d、若X→Y，則X叫決定因素（決定因素集）e、若X→Y，且Y→X，則記為X←→Y。2、平凡函數依賴與非平凡函數依賴

X→Y，但Y不是X的子集，則X→Y是非平凡函數依賴。

X→Y，但Y是X的子集，則X→Y是平凡函數依賴。基本概念(2)3、完全函數依賴和部分函依賴設有關系模式R（U），U是屬性全集，X和Y是U的子集，如果X→Y，并且對于X的任何一個真子集X'，都有X'Y，則稱Y對X完全函數依賴（FullFunctionalDependency），記作XY。如果對X的某個真子集X'，都有X'→Y，則稱Y對X部分函數依賴（PartialFunctionalDependency），記作XY。

Example：Student（Sno，Sname，Sdept，Sage）SC（Sno，Cno，Grade）４、傳遞函數依賴在關系模式R（U）中，U是屬性全集，X、Y和Z是U的子集，若X→Y，（Y?X），YX，而Y→Z，則稱Z對X傳遞函數依賴（TransitiveFunctionalDependency），記作XY。如果Y→X，則X←→Y，這時稱Z對X直接函數依賴，而不是傳遞函數依賴。Example：Student（Sno，Sid，Sage）基本概念(3)5、碼設K為R（U，F）中的屬性或屬性組合，若KU則K為R的侯選碼。若侯選碼多于一個，則選定其中的一個為主碼（Primarykey）。包含在任何一個侯選碼中的屬性，叫做主屬性。不包含在任何中的屬性稱為非主屬性或非碼屬性。最簡單的情況，單個屬性是碼。最極端的情況是，整個屬性組是碼，稱為全碼。如：S（SNO，SDEPT，SAGE）SC（SNO，CNO，G）R（P，W，A），屬性P表示演奏者，W表示作品，A表示聽眾模式存在問題分析數據冗余規范化理論正是用來改造關系更新異常模式，通過分解關系模來消除其插入異常中不合適的數據依賴，使之成為刪除異常一個“好”模式分解后：

S（SNO，SDEPT，SNO→SDEPT）

SG（SNO，CNAME，G，（SNO，CNAME）→G）

DEPT（SDEPT，MNAME，SDEPT→MNAME）范式一、1NF（數據項不可再分）二、2NF（不允許有非主屬性對碼的部分依賴）三、3NF（不允許有非主屬性對碼的傳遞依賴）四、BCNF（不允許有主屬性對碼的部分依賴）多值依賴

例：TEACH（C，T，B），其中C表示課程，教師T，參考書B，關系如下數學鄧軍數學分析陳思高等代數微分方程物理李平普通物理王強光學原理劉明分析：1、是否屬于BCNF2、數據冗余度

3、增加操作、刪除操作、修改操作

4、原因（B和T的取值毫無關系）定義：設R（U）是一個屬性集U上的一個關系模式，X，Y，Z是U的子集，并且Z=U-X-Y，多值依賴X→→Y成立當且僅當對R的任一關系r，r在（X，Z）上的每個值對應一組Y的值，這組值僅僅決定于X值而與Y的值無關.若X→→Y，而Z=?，則稱X→→Y為平凡的多值依賴。否則為非平凡的多值依賴。4NF1、定義關系模式R<U，F>?1NF，如果對于R的每個非平凡多值依賴X→→Y（Y?X），X都含有候選碼，則R?4NF。例：Y=X+5Y=ARCSINX關系模式的規范化一、基本思想規范化實際上是概念的單一化。二、基本步驟

1NF-2NF-3NF-BCNF-4NF-5NF三、關系模式的分解保證分解后的關系模式與原關系模式等價。關系模式的規范化（2）例：SL（SNO，SDEPT，SLOC）

SNO→SDEPTSDEPT→SLOCSNO→SLOCSNOSDEPTSLOC9500195002950039500495005CSISMAISPHABCBB分解方法1、第一種分解方法

SL分解為三個關系SN（SNO），SD（SDEPT），

SO（SLOC）2、第二種分解方法

NL（SNO，SLOC）

DL（SDEPT，SLOC）SNOSLOC9500195002950039500495005ABCBBSDEPTSLOCCSISMAPHABCB第三種分解方法ND（SNO，SDEPT）NL（SNO，SLOC）SNOSDEPT9500195002950039500495005CSISMAISPHSNOSLOC9500195002950039500495005ABCBB關系模式的規范化（3）四、無損連接性五、保持函數依賴的分解第四種分解方法：ND（SNO，SDEPT）

DL（SDEPT，SLOC）六、判斷關系模式等價的三個標準七、常識

1、保持無損連接，一定能達到4NF。

2、保持函數依賴，一定能達到3NF，但不一定能達到BCNF。

3、既保持無損連接，又保持函數依賴，一定能達到3NF，但不一定能達到BCNF。規范化小結關系模式規范化的基本步驟

1NF ↓消除非主屬性對碼的部分函數依賴消除決定屬性2NF集非碼的非平↓消除非主屬性對碼的傳遞函數依賴凡函數依賴3NF ↓消除主屬性對碼的部分和傳遞函數依賴

BCNF

數據模型的優化完成E-R圖向關系數據模型的轉換之后，還需要對數據模型進行優化，修改、調整數據模型的結構，提高數據庫的性能。①

確定數據依賴。按需求分析階段得到的語義，分別寫出每個關系模式內部各屬性之間的數據依賴以及不同關系模式屬性之間的數據依賴。②

對于各個關系模式之間的數據依賴進行極小化處理，消除冗余的聯系。③

按照數據依賴的理論對關系模式逐一進行分析，考查是否存在部分函數依賴、傳遞函數依賴、多值依賴等，確定各關系模式分別屬于第幾范式。④

按照需求分析階段得到的信息要求和處理要求，分析這些模式是否滿足這些要求，確定是否要對某些模式進行合并或分解。并不是規范化程度越高的關系就越優。當一個應用的查詢中經常涉及兩個或多個關系模式的屬性時，系統必須經常地進行連接運算，而連接運算的代價是相當高的，因此在這種情況下，2NF甚至1NF也許是最好的。設計用戶子模式（1）使用更符合用戶習慣的別名視圖集成時，為了減少異義同名的沖突，規范了一些名稱。規范后的名稱與局部用戶的習慣不一致，將影響用戶的工作。設計用戶的子模式時可以重新定義某些屬性名，使其與用戶習慣一致。（2）針對不同級別的用戶定義不同的視圖不同的用戶關心的實體及其屬性不同，對這些實體與屬性的訪問權限也不同。例如學生允許查看課程的開設情況和任課教師的學歷、職稱等屬性，但是沒有權利查看教師的籍貫、工資等屬性。為了滿足系統安全性要求，需要針對不同級別的用戶定義不同的視圖。（3）簡化用戶對系統的使用某些局部應用中經常要使用一些很復雜的查詢，為了方便用戶，可以將這些復雜查詢定義為視圖，用戶每次只對定義好的視圖進行查詢，方便用戶使用系統。

實例——學籍管理邏輯結構設計（1）1．數據模型（1）將實體轉化為關系模型將學生實體轉換為學生關系（學號，姓名，性別，出生日期）將班級實體轉換為班級關系（班級編號、班級名稱）將學院實體轉換為班級關系（學院編號、學院名稱）將課程實體轉換為課程關系（課程編號、課程名稱、課程介紹、開設學期、總學時、學分、先修課程）將課程類型實體轉換為課程類型關系（課程類型碼、類型說明）將教師實體轉換為教師關系（教師編號、姓名、性別、出生日期、參加工作日期）將職稱實體轉換為職稱關系（職稱編碼、職稱）實例——學籍管理邏輯結構設計（2）（2）將聯系轉化為關系模型①將1∶1的聯系轉化為關系模式。教師與班級的“管理”聯系為1∶1聯系，可以使用下面任一種方法轉換。 將其轉換為一個獨立的關系模型管理（教師編號，班級編號），其中教師編號是教師關系的碼，班級編號是班級關系的碼。教師編號與班級編號都可以是管理關系的候選碼，此處選擇教師編號作為管理關系的碼。 將管理聯系合并到班級關系模式中在班級關系模式中加入教師關系的碼——教師編號，形成如下關系模式：班級（班級編號，班級名稱，教師編號）。 將管理聯系合并到教師關系模式中在教師關系中加入班級關系的碼——班級編號，形成如下關系模式：教師（教師編號、姓名、性別、出生日期、參加工作日期、班級編號）。實例——學籍管理邏輯結構設計（3）②將1∶n的聯系轉化為關系模式。 學院與班級的“隸屬”聯系學院與班級的“隸屬”聯系?？梢允褂孟旅嫒我环N方法轉換成關系模式。一種方法是使其轉換為一個獨立的關系模式：隸屬（班級編號，學院編號），其中班級編號為“隸屬”關系的碼。另一種方法是將其與班級關系模式合并，這時班級關系模式修改為：班級（班級編號、班級名稱、學院編號），其中班級關系模式的碼仍為班級編號。后一種方式是常用的轉換方法，下面的1∶n的聯系都采用將聯系與n端對應的關系模式合并的方法。 教師與學院的“就職”聯系將“就職”聯系與教師關系合并，教師關系模式變為：教師（教師編號、姓名、性別、出生日期、參加工作日期、學院編號） 教師與職稱的“聘任”聯系將“聘任”聯系與教師關系合并，教師關系模式變為：教師（教師編號、姓名、性別、出生日期、參加工作日期、學院編號、職稱編碼） 課程與課程類型的“屬于”聯系將課程與課程類型的“屬于”聯系與課程關系合并，課程關系模式變為：課程（課程編號、課程名稱、課程介紹、開設學期、總學時、學分、先修課程、課程類型編碼） 學生與班級“所在”聯系將學生與班級“所在”聯系與學生關系合并，學生關系模式變為：學生（學號，姓名，性別，出生日期、班級編號）實例——學籍管理邏輯結構設計（4）③將m∶n的聯系轉化為關系模式。學生與課程的“選課”聯系將“選課”轉化為一個關系模式：選課（學號，課程編號，選修學期），碼是學號與課程編號的組合。教師與課程的“授課”聯系將“授課”轉化為一個關系模式：授課（教師編號，課程編號，授課學期、授課地點），碼是教師編號與課程編號的組合。實例——學籍管理邏輯結構設計（5）2．用戶子模式

為了方便查詢教師的教學情況，根據需要建立如下子模式：教師基本信息（教師編號，姓名，性別，學歷，職稱）課程開設情況（課程編號，課程名稱，課程簡介，教師編號，歷屆成績，及格率）

為學籍管理人員建立如下子模式：學生基本情況（學號，姓名，性別，年齡，籍貫，班級，學院，獲取總學分）授課效果（課程編號，選修學期，平均成績）

為學生建立如下子模式：考試通過基本情況（學號，姓名，班級，課程名稱，成績）

為教師建立如下子模式：選修學生情況（課程編號，學號，姓名，班級，學院，平均成績）授課效果（課程編號，選修學期，平均成績）物理結構設計數據庫是存儲在物理設備上的，數據庫在物理設備上的存儲結構與存取方法稱為數據庫的物理結構，物理結構依賴于給定的DBMS和計算機系統。邏輯數據庫設計工作完成后，需要為給定的邏輯數據模型選取一個適合應用環境的物理結構，對物理結構進行時間（執行效率）和空間效率的評價。數據庫物理設計的任務是對給定的邏輯數據模型選取適合應用環境的物理結構，即在邏輯設計的基礎上，為每個關系模式選擇合適的存儲結構和存取方法，使數據庫的事務能夠高效率地運行。

數據庫物理設計階段主要包括以下4個過程。①

分析影響物理數據庫設計的因素。②

為關系模式選擇存取方法。③

設計關系、索引等數據庫文件的物理存儲結構。④

評價物理結構。

物理結構設計（2）在進行數據庫物理設計時需要注意以下問題。①確定數據的存儲結構。需考慮存取時間、空間效率和維護代價間的平衡。如在引入冗余數據以加快存取速度時應兼顧系統的空間效率。②選擇合適的存取路徑。例如，確定應該為哪些關系模式建立索引，索引關鍵字是什么等。③確定數據的存放位置。例如，確定數據存放在一個磁盤上還是多個磁盤上，什么數據該存放在高速存儲器上，什么應存放在低速存儲器上等。④確定存取分布。許多DBMS都提供了一些存儲分配參數供設計者使用。例如，緩沖區的大小和個數、塊的長度、塊因子的大小等。設計者必須規定其中的一些參數設置。分析影響數據庫物理設計的因素

（1）與數據庫查詢事務有關的因素 查詢的關系 查詢條件所涉及的屬性 連接條件所涉及的屬性 查詢的投影屬性（2）與數據庫更新事務有關的因素

被更新的關系

每個關系更新操作的類型

刪除和修改操作條件所涉及的屬性

修改操作要改變的屬性值（3）每個事務在各個關系上運行的頻率和時間約束

關系模式存取方法選擇DBMS一般都提供多種存取方式：

索引（index）

HASH

HASH方法是用HASH函數存儲和存取關系記錄的方法。具體地講是，指定某個關系上的—個（組）屬性A作為HASH碼，對該HASH碼定義一個函數（稱為HASH函數），關系記錄的存儲地址由HASH（a）來決定，a是該記錄在屬性A上的值。聚簇（cluster）為了提高某個屬性（或屬性組）的查詢速度，把這個或這些屬性（稱為聚簇碼）上具有相同值的元組集中存放在連續的物理塊上，這種方法稱為聚簇。聚簇方法可以大大提高按聚簇碼進行查詢的效率。關系模式存取方法選擇（2）（1）索引方法根據實際需要確定對哪些關系的哪些屬性列建立索引、組合索引或唯一索引。是否需要建立索引，可以考慮以下原則。①如果一個（組）屬性經常作為查詢條件，可以考慮建立索引（組合索引）。②如果一個（組）屬性經常使用聚集函數，可以考慮建立索引。③如果一個（組）屬性經常需要作為連接條件，可以考慮建立索引。由于系統維護索引是需要一定的空間的，而且數據表內容發生變化時系統也需要重新維護索引。因此索引并不是越多越好，設計時需要根據具體情況來建立。如果一個關系的更新頻率很高，這個關系上就不要定義的太多的索引。關系模式存取方法選擇（3）（2）HASH方法如果一個關系的屬性主要出現在等連接條件中或相等比較的選擇條件中，是否選擇HASH存取方法的原則如下。①一個關系的大小可預知，而且不變，則此關系可以選擇HASH存取方法。②如果DBMS支持動態HASH存取方式，即使關系大小動態可變，也可以采用HASH存取方法。關系模式存取方法選擇（3）聚簇方法需要建立多少個聚簇，每個聚簇中包括哪些關系，可以參考以下原則。①

經常在一起進行連接操作的關系可以建立聚簇。②

如果一個關系的一組屬性經常出現在相等比較條件中，則該單個關系可以建立聚簇。③

如果一個關系的一個（組）屬性上的值重復率很高，則此關系可以建立聚簇。④

一個數據庫可以建立多個聚簇，一個關系只能加入一個聚簇。如果出現下列情況，建議不要建立聚簇。①

經常需要進行全表掃描的關系。②

更新操作頻率高于訪問和連接操作的關系。確定系統配置

DBMS產品一般都提供了一些存儲分配參數，供設計人員和數據庫管理員對數據庫進行物理優化。初始情況下，系統都為這些變量賦予了合理的缺省值。但是這些值不一定適合每一種應用環境，在進行物理設計時，需要重新對這些變量賦值以改善系統的性能。通常情況下，這些配置變量包括：同時使用數據庫的用戶數，同時打開的數據庫對象數，使用的緩沖區長度、個數，時間片大小、數據庫的大小，裝填因子，鎖的數目等，這些參數值影響存取時間和存儲空間的分配，在物理設計時就要根據應用環境確定這些參數值，以使系統性能最優。在物理設計時對系統配置變量的調整只是初步的，在系統運行時還要根據系統實際運行情況做進一步的調整，以期切實改進系統性能。

評價物理結構物理設計過程中需考慮時間和空間效率、維護代價和用戶的要求等，對這些因素考慮的側重點不同會產生多種物理設計方案。因此，數據庫的物理結構應全面權衡這幾個因素，對各種可能的設計方案進行評價，評價的重點是系統的時間和空間效率，并從多個方案中選出較優的物理結構。

數據庫實施與維護完成數據庫物理設計之后，就可以根據邏輯結構和物理結構設計，采用符合DBMS提供的數據定義語言，建立數據庫和數據庫對象。數據定義語言可以通過手工編寫腳本，也可以使用建模工具（如PowerDesigner）根據邏輯結構和物理結構設計自動生成。數據庫建立之后，可以組織數據入庫。經過調試、試運行之后可以正式運行。正式運行時，還需要不斷進行維護。

數據庫試運行

數據庫運行與維護

創建數據庫根據邏輯結構和物理結構設計，使用DBMS提供的命令，創建數據庫、建立數據庫中所包含的各種數據對象，包括表、視圖、索引、觸發器等。這部分的工作可以用CREATEDATABASE、CREATETABLE、CREATEVIEW等命令手工編寫。這些SQL語句一般都需要保存形成建立數據庫的腳本，一方面方便修改調式，另一方面可以在不同時間或計算機上多次創建數據庫。數據庫創建腳本也可以使用如PowerDesigner等CSAE工具生成。組織數據入庫（1）手工（紙質）數據用戶以前沒有使用任何計算機系統協助業務工作，所有的數據都存儲在一些報表、檔案、憑證、單據、臺賬中。組織這類數據入庫的工作非常艱辛。一方面需要用戶按照數據庫要求配合整理手工數據，確保手工數據的正確性、一致性、完整性。另一方面需