數(shù)據(jù)庫物理設計第一頁，共九十三頁，編輯于2023年，星期三第六章數(shù)據(jù)庫設計6.1數(shù)據(jù)庫設計概述6.2需求分析6.3概念結構設計6.4邏輯結構設計6.5數(shù)據(jù)庫的物理設計6.6數(shù)據(jù)庫實施6.7數(shù)據(jù)庫運行與維護6.8小結第二頁，共九十三頁，編輯于2023年，星期三6.1數(shù)據(jù)庫設計的步驟（1）目前主要采用以邏輯數(shù)據(jù)庫設計和物理數(shù)據(jù)庫設計為核心的規(guī)范設計方法。邏輯數(shù)據(jù)庫設計-設計全局邏輯結構和每個用戶的局部邏輯結構，將概念結構轉換為某個DBMS支持的數(shù)據(jù)模型并優(yōu)化物理數(shù)據(jù)庫設計-為邏輯數(shù)據(jù)模型選一個最適合應用環(huán)境的物理結構，設計數(shù)據(jù)庫的存儲結構、存取方法及其他實現(xiàn)細節(jié)第三頁，共九十三頁，編輯于2023年，星期三6.1數(shù)據(jù)庫設計的步驟（2）選定參加設計的人員：數(shù)據(jù)庫分析設計人員-核心，自始至終用戶-重要，需求分析(頭)，運行和維護(尾)程序員-編制程序操作員-準備軟硬件環(huán)境第四頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)庫設計過程圖需求分析概念結構設計數(shù)據(jù)庫實施數(shù)據(jù)庫運行和維護邏輯結構設計數(shù)據(jù)庫物理設計第五頁，共九十三頁，編輯于2023年，星期三6.2需求分析

6.2.1任務重點是調查、收集與分析用戶在數(shù)據(jù)管理中的信息要求、處理要求、安全性和完整性要求信息要求-用戶需從庫中獲得信息的內(nèi)容和性質，存儲哪些信息于庫中處理要求-要求完成的功能、響應時間、方式是批處理還是聯(lián)機處理第六頁，共九十三頁，編輯于2023年，星期三6.2需求分析

6.2.1任務

困難在：用戶缺少計算機知識，無法準確表達自己的需求，需求往往不斷變化設計人員缺乏用戶的專業(yè)知識，不易理解甚至誤解用戶的需求。軟硬件技術的出現(xiàn)會使用戶需求發(fā)生變化第七頁，共九十三頁，編輯于2023年，星期三6.2需求分析

6.2.2需求分析的方法（1）調查與初步分析用戶需求需四步：調查組織機構情況：部門組成、職責，為分析信息流程做準備調查各部門業(yè)務活動情況：輸入和使用什么數(shù)據(jù)，如何加工處理這些數(shù)據(jù)，輸出什么信息、到哪里、輸出結果的格式協(xié)助用戶明確對新系統(tǒng)的要求確定新系統(tǒng)邊界，哪些是計算機完成的功能第八頁，共九十三頁，編輯于2023年，星期三6.2需求分析

6.2.2需求分析的方法（2）

常用的調查方法：跟班作業(yè)開調查會-用戶彼此啟發(fā)請專人介紹詢問-專人設計調查表請用戶填寫查閱記錄-與原系統(tǒng)有關的數(shù)據(jù)記錄第九頁，共九十三頁，編輯于2023年，星期三6.2需求分析分析和表達用戶需求的方法主要包括：自頂向下（SA）和自底向上方法自頂向下（SA）方法從最上層的系統(tǒng)組織機構入手，采用逐層分解的方式分析系統(tǒng)，并用數(shù)據(jù)流圖和數(shù)據(jù)字典描述系統(tǒng)用SA方法做需求分析，設計人員需要把任何一個系統(tǒng)都抽象為如下形式第十頁，共九十三頁，編輯于2023年，星期三

數(shù)據(jù)存儲數(shù)據(jù)流數(shù)據(jù)流數(shù)據(jù)來源處理數(shù)據(jù)輸出第十一頁，共九十三頁，編輯于2023年，星期三然后將處理功能分解，不停分解，直至系統(tǒng)工作過程被表達清楚；數(shù)據(jù)也逐級分解，形成若干層次的數(shù)據(jù)流圖。數(shù)據(jù)流圖表達了數(shù)據(jù)和處理過程的關系數(shù)據(jù)借助數(shù)據(jù)字典描述處理過程的處理邏輯借助判定表或判定樹來描述第十二頁，共九十三頁，編輯于2023年，星期三實例：開發(fā)學校管理系統(tǒng)高層數(shù)據(jù)流圖管理信息系統(tǒng)教師管理子系統(tǒng)后勤管理子系統(tǒng)學生管理子系統(tǒng)課程管理學籍管理第十三頁，共九十三頁，編輯于2023年，星期三實例（續(xù)）學生管理子系統(tǒng)的主要功能：學籍管理和課程管理。包括：學生報到、入學、畢業(yè)、上課情況管理。通過詳細的信息流程分析和數(shù)據(jù)收集后，生成該系統(tǒng)的數(shù)據(jù)流圖。見188-189第十四頁，共九十三頁，編輯于2023年，星期三6.3概念結構設計

6.3.1概念結構設計方法與步驟概念結構設計--將需求分析得到的用戶需求抽象為概念模型的過程概念結構獨立于數(shù)據(jù)庫邏輯結構，也獨立于DBMS四類方法：自頂向下自底向上—經(jīng)常采用。即自頂向下進行需求分析，再自底向上設計概念結構。逐步擴張-先定義核心概念，然后向外擴充混合策略第十五頁，共九十三頁，編輯于2023年，星期三6.3.2分E-R圖設計（1）在多層數(shù)據(jù)流圖中選擇一個適當層次的數(shù)據(jù)流圖，讓每一部分對應一個局部應用，因為中層的數(shù)據(jù)流圖能較好地反映系統(tǒng)中各局部應用的子系統(tǒng)組成，所以一般作為分E-R圖的依據(jù)參照數(shù)據(jù)流圖，標定局部應用中的實體、實體的屬性、標識實體的碼，確定實體之間的聯(lián)系及其類型。第十六頁，共九十三頁，編輯于2023年，星期三6.3.2設計分E-R圖（2）現(xiàn)實世界中一組具有共同特性和行為的對象可抽象為一個實體，例，張三、李斯、王五可抽象為學生實體對象的組成成分可抽象為實體的屬性，例，學號、姓名、年級等可抽象為學生實體的屬性，其中學號為標識實體的碼實體與屬性很難劃分界限。例，系是學生實體的屬性，在需要考慮系主任、教師人數(shù)、學生人數(shù)、辦公地點時就需要作為實體了。第十七頁，共九十三頁，編輯于2023年，星期三6.3.2設計分E-R圖（3）屬性和實體區(qū)別的原則：屬性不能再具有需要描述的性質。即為不可再分的數(shù)據(jù)項屬性不能與其他實體具有聯(lián)系。聯(lián)系只能發(fā)生在實體之間。能做屬性對待盡量作屬性。第十八頁，共九十三頁，編輯于2023年，星期三“職稱”分別作為實體和屬性教師教師職稱住房姓名職稱性別性別姓名評定分配第十九頁，共九十三頁，編輯于2023年，星期三學籍管理分E-R圖草圖班主任班級檔案材料學生宿舍教室管理指導歸檔住宿組成上課第二十頁，共九十三頁，編輯于2023年，星期三對學籍管理E-R草圖調整一般，性別應作為學生實體的屬性，本應用中由于宿舍分配與性別有關，依據(jù)準則2-屬性不能與其他實體有聯(lián)系，性別應作為實體對待數(shù)據(jù)存儲“學生登記表”由手工完成，有用部分轉入學生檔案材料中，因此這里不必作為實體。第二十一頁，共九十三頁，編輯于2023年，星期三學籍管理分E-R圖草圖調整后班主任班級檔案材料學生宿舍教室管理指導歸檔住宿組成上課性別擁有第二十二頁，共九十三頁，編輯于2023年，星期三課程管理的E-R圖教室課程教師教科書學生開設教學講授選修成績第二十三頁，共九十三頁，編輯于2023年，星期三6.3.3E-R圖的集成（1）不同設計人員進行局部視圖設計，這導致各分E-R圖之間存在許多不一致的地方，因此著力消除沖突是主要工作與關鍵所在1.屬性沖突-討論協(xié)商解決屬性域沖突：屬性值的類型、取值范圍、取值集合不同屬性取值單位沖突第二十四頁，共九十三頁，編輯于2023年，星期三6.3.3E-R圖的集成（2）2.命名沖突-討論協(xié)商解決同名異義異名同義3.結構沖突同一對象在不同應用中具有不同的抽象-例，“課程”在某一局部應用中當作實體，另一局部應用中當作屬性解決辦法：使同一對象有相同的抽象，遵守前面的屬性原則第二十五頁，共九十三頁，編輯于2023年，星期三6.3.3E-R圖的集成（3）3.結構沖突同一實體在不同E-R圖中所包含的屬性不完全相同，或排列次序不完全相同解決辦法：取分E-R圖的并集，再適當設計屬性的次序實體間聯(lián)系在不同視圖中呈現(xiàn)不同類型解決辦法：根據(jù)應用的語義對實體聯(lián)系的類型進行綜合或調整第二十六頁，共九十三頁，編輯于2023年，星期三學籍管理與課程管理E-R圖的合并存在的沖突：1.班主任也屬于教師，兩圖存在異名同義，統(tǒng)一為教師實體，屬性構成為：教師{職工號，姓名，性別，職稱，優(yōu)秀班主任否}2.班主任改為教師后，教室和學生之間的聯(lián)系為兩類，因為“指導”包含在“教學”中，所以綜合為教學聯(lián)系3.性別在學籍管理為實體，在課程管理中為屬性，合并后只能作為實體，否則無法與宿舍實體發(fā)生聯(lián)系4.二者中學生實體屬性組成及次序都存在差異，應將所有屬性綜合并重新調整次序。第二十七頁，共九十三頁，編輯于2023年，星期三6.3.3E-R圖的修改與重構（1）修改與重構-消除不必要的冗余信息,生成基本E-R圖冗余數(shù)據(jù)-可由基本數(shù)據(jù)導出冗余的實體間聯(lián)系-可由其它聯(lián)系導出冗余信息易破壞數(shù)據(jù)庫的完整性，給數(shù)據(jù)維護增加困難，但有時為了提高某些應用的效率不得不以冗余信息為代價。第二十八頁，共九十三頁，編輯于2023年，星期三6.3.3E-R圖的修改與重構（2）消除冗余主要采用分析方法，例如教師工資單里的實發(fā)工資，可以推算消除冗余還可采用規(guī)范化理論例，學生實體的年齡可由生日推算，屬冗余數(shù)據(jù)教室實體與班級實體的上課聯(lián)系可由教室與課程間的開設聯(lián)系、課程與學生間的選修聯(lián)系、學生與班級之間的組成聯(lián)系推導出來，屬于冗余聯(lián)系學生實體中平均成績可由選修聯(lián)系中的成績屬性推算，但經(jīng)常查詢，為維護數(shù)據(jù)一致性，應設置觸發(fā)器第二十九頁，共九十三頁，編輯于2023年，星期三整體概念結構（總E-RT圖）必須驗證整體概念結構內(nèi)部必須具有一致性整體概念結構能準確反映原來的每個視圖結構整體概念結構能滿足需求分析階段所確定的所有要求第三十頁，共九十三頁，編輯于2023年，星期三6.4邏輯結構設計邏輯結構設計的任務概念結構是各種數(shù)據(jù)模型的共同基礎為了能夠用某一DBMS實現(xiàn)用戶需求，還必須將概念結構進一步轉化為相應的數(shù)據(jù)模型，這正是數(shù)據(jù)庫邏輯結構設計所要完成的任務。第三十一頁，共九十三頁，編輯于2023年，星期三6.4邏輯結構設計邏輯結構設計的步驟將概念結構轉化為一般的關系、網(wǎng)狀、層次模型將轉化來的關系、網(wǎng)狀、層次模型向特定DBMS支持下的數(shù)據(jù)模型轉換對數(shù)據(jù)模型進行優(yōu)化第三十二頁，共九十三頁，編輯于2023年，星期三

邏輯結構設計轉化為一般數(shù)據(jù)模型轉化為特定DBMS支持下的據(jù)模型

優(yōu)化模型概念結構設計數(shù)據(jù)庫物理設計基本E-R圖轉換規(guī)則特定DBMS的特點與限制優(yōu)化方法如規(guī)范化理論邏輯模型第三十三頁，共九十三頁，編輯于2023年，星期三6.4邏輯結構設計6.4.1E-R圖向關系模型的轉換6.4.2向特定DBMS規(guī)定的模型進行轉換6.4.3數(shù)據(jù)模型的優(yōu)化6.4.4設計用戶子模式第三十四頁，共九十三頁，編輯于2023年，星期三6.4.1E-R圖向關系模型的轉換轉換內(nèi)容轉換原則第三十五頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）轉換內(nèi)容E-R圖由實體、實體的屬性和實體之間的聯(lián)系三個要素組成關系模型的邏輯結構是一組關系模式的集合將E-R圖轉換為關系模型：將實體、實體的屬性和實體之間的聯(lián)系轉化為關系模式。第三十六頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）轉換原則⒈一個實體型轉換為一個關系模式。關系的屬性：實體型的屬性關系的碼：實體型的碼例，學生實體可以轉換為如下關系模式：學生（學號，姓名，出生日期，所在系，年級，平均成績）性別、宿舍、班級、檔案材料、教師、課程、教室、教科書等實體都分別轉換為一個關系模式。第三十七頁，共九十三頁，編輯于2023年，星期三

學生學號出生日期年級所在系平均成績姓名第三十八頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）⒉一個m:n聯(lián)系轉換為一個關系模式。關系的屬性：與該聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性關系的碼：各實體碼的組合 例，“選修”聯(lián)系是一個m:n聯(lián)系，可以將它轉換為如下關系模式，其中學號與課程號為關系的組合碼：選修（學號，課程號，成績）第三十九頁，共九十三頁，編輯于2023年，星期三學生選修成績課程學生的碼為學號，課程的碼為課程號，選修的屬性為成績第四十頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）⒊一個1:n聯(lián)系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。1)轉換為一個獨立的關系模式關系的屬性：與該聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性關系的碼：n端實體的碼第四十一頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）⒊一個1:n聯(lián)系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。2)與n端對應的關系模式合并合并后關系的屬性：在n端關系中加入1端關系的碼和聯(lián)系本身的屬性合并后關系的碼：不變可以減少系統(tǒng)中的關系個數(shù)，一般情況下更傾向于采用這種方法第四十二頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）例，“組成”聯(lián)系為1:n聯(lián)系。 將其轉換為關系模式的兩種方法：

1)使其成為一個獨立的關系模式：組成（學號，班級號）（見下頁）

2)將其與學生關系模式合并： 學生（學號，姓名，出生日期，所在系，年級，班級號，平均成績）第四十三頁，共九十三頁，編輯于2023年，星期三班級

1

組成

n

學生學生的碼為學號，班級的碼為班級號，選修的屬性為成績第四十四頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）⒋一個1:1聯(lián)系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。1)轉換為一個獨立的關系模式關系的屬性：與該聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性關系的候選碼：每個實體的碼均是該關系的候選碼第四十五頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）⒋一個1:1聯(lián)系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。2)與某一端對應的關系模式合并合并后關系的屬性：加入對應關系的碼和聯(lián)系本身的屬性合并后關系的碼：不變第四十六頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）例，“管理”聯(lián)系為1:1聯(lián)系，可以有三種轉換方法：（1）轉換為一個獨立的關系模式：

管理（職工號，班級號）或 管理（職工號，班級號）（2）“管理”聯(lián)系與班級關系模式合并，則只需在班級關系中加入教師關系的碼，即職工號： 班級（班級號，學生人數(shù)，職工號）（3）“管理”聯(lián)系與教師關系模式合并，則只需在教師關系中加入班級關系的碼，即班級號： 教師（職工號，姓名，性別，職稱，班級號，是否為優(yōu)秀班主任）第四十七頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）注意：從理論上講，1:1聯(lián)系可以與任意一端對應的關系模式合并。但在一些情況下，與不同的關系模式合并效率會大不一樣。因此究竟應該與哪端的關系模式合并需要依應用的具體情況而定。由于連接操作是最費時的操作，所以一般應以盡量減少連接操作為目標。例如，如果經(jīng)常要查詢某個班級的班主任姓名，則將管理聯(lián)系與教師關系合并更好些。第四十八頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）⒌三個或三個以上實體間的一個多元聯(lián)系轉換為一個關系模式。關系的屬性：與該多元聯(lián)系相連的各實體的碼以及聯(lián)系本身的屬性關系的碼：各實體碼的組合 例，“講授”聯(lián)系是一個三元聯(lián)系，可以將它轉換為如下關系模式，其中課程號、職工號和書號為關系的組合碼：講授（課程號，職工號，書號）第四十九頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）⒍同一實體集的實體間的聯(lián)系，即自聯(lián)系，也可按上述1:1、1:n和m:n三種情況分別處理。 例，如果教師實體集內(nèi)部存在領導與被領導的1:n自聯(lián)系，我們可以將該聯(lián)系與教師實體合并，這時主碼職工號將多次出現(xiàn)，但作用不同，可用不同的屬性名加以區(qū)分：教師：｛職工號，姓名，性別，職稱，系主任｝第五十頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）⒎具有相同碼的關系模式可合并。目的：減少系統(tǒng)中的關系個數(shù)。合并方法：將其中一個關系模式的全部屬性加入到另一個關系模式中，然后去掉其中的同義屬性（可能同名也可能不同名），并適當調整屬性的次序。第五十一頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）例，“擁有”關系模式：擁有（學號，性別）與學生關系模式：學生（學號，姓名，出生日期，所在系，年級，班級號，平均成績）都以學號為碼，可以將它們合并為一個關系模式：學生（學號，姓名，性別，出生日期，所在系，年級，班級號，平均成績）第五十二頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）實例按照上述七條原則，學生管理子系統(tǒng)中的18個實體和聯(lián)系可以轉換為下列關系模型：學生（學號，姓名，性別，出生日期，所在系，年級，班級號，平均成績，檔案號） 性別（性別，宿舍樓）宿舍（宿舍編號，地址，性別，人數(shù)）班級（班級號，學生人數(shù)） 教師（職工號，姓名，性別，職稱，班級號，

是否為優(yōu)秀班主任）

第五十三頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)） 教學（職工號，學號）課程（課程號，課程名，學分，教室號）選修（學號，課程號，成績）教科書（書號，書名，價錢）教室（教室編號，地址，容量）講授（課程號，教師號，書號）檔案材料（檔案號，……）第五十四頁，共九十三頁，編輯于2023年，星期三E-R圖向關系模型的轉換（續(xù)）該關系模型由12個關系模式組成。其中：學生關系模式包含了“擁有”聯(lián)系、“組成”聯(lián)系、“歸檔”聯(lián)系所對應的關系模式教師關系模式包含了“管理”聯(lián)系所對應的關系模式；宿舍關系模式包含了“住宿”聯(lián)系所對應的關系模式；課程關系模式包含了“開設”聯(lián)系所對應的關系模式。第五十五頁，共九十三頁，編輯于2023年，星期三6.4邏輯結構設計6.4.1E-R圖向關系模型的轉換6.4.2向特定DBMS規(guī)定的模型進行轉換6.4.3數(shù)據(jù)模型的優(yōu)化6.4.4設計用戶子模式第五十六頁，共九十三頁，編輯于2023年，星期三6.4.2向特定DBMS規(guī)定的模型進行轉換一般的數(shù)據(jù)模型還需要向特定DBMS規(guī)定的模型進行轉換。轉換的主要依據(jù)是所選用的DBMS的功能及限制。沒有通用規(guī)則。對于關系模型來說，這種轉換通常都比較簡單。第五十七頁，共九十三頁，編輯于2023年，星期三6.4邏輯結構設計6.4.1E-R圖向關系模型的轉換6.4.2向特定DBMS規(guī)定的模型進行轉換6.4.3數(shù)據(jù)模型的優(yōu)化6.4.4設計用戶子模式第五十八頁，共九十三頁，編輯于2023年，星期三6.4.3數(shù)據(jù)模型的優(yōu)化數(shù)據(jù)庫邏輯設計的結果不是唯一的。得到初步數(shù)據(jù)模型后，還應該適當?shù)匦薷?、調整數(shù)據(jù)模型的結構，以進一步提高數(shù)據(jù)庫應用系統(tǒng)的性能，這就是數(shù)據(jù)模型的優(yōu)化。關系數(shù)據(jù)模型的優(yōu)化通常以規(guī)范化理論為指導。第五十九頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）優(yōu)化數(shù)據(jù)模型的方法⒈確定數(shù)據(jù)依賴按需求分析階段所得到的語義，分別寫出每個關系模式內(nèi)部各屬性之間的數(shù)據(jù)依賴以及不同關系模式屬性之間數(shù)據(jù)依賴。

第六十頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）例，課程關系模式內(nèi)部存在下列數(shù)據(jù)依賴：課程號→課程名課程號→學分 課程號→教室號選修關系模式中存在下列數(shù)據(jù)依賴：（學號，課程號）→成績

第六十一頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)） 學生關系模式中存在下列數(shù)據(jù)依賴：學號→姓名學號→性別學號→出生日期學號→所在系 學號→年級學號→班級號學號→平均成績學號→檔案號第六十二頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)） 學生關系模式的學號與選修關系模式的學號之間存在數(shù)據(jù)依賴：學生.學號→選修.學號第六十三頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）⒉對于各個關系模式之間的數(shù)據(jù)依賴進行極小化處理，消除冗余的聯(lián)系。第六十四頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）⒊按照數(shù)據(jù)依賴的理論對關系模式逐一進行分析，考查是否存在部分函數(shù)依賴、傳遞函數(shù)依賴、多值依賴等，確定各關系模式分別屬于第幾范式。例如經(jīng)過分析可知，課程關系模式屬于BC范式。第六十五頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）⒋按照需求分析階段得到的各種應用對數(shù)據(jù)處理的要求，分析對于這樣的應用環(huán)境這些模式是否合適，確定是否要對它們進行合并或分解。第六十六頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）并不是規(guī)范化程度越高的關系就越優(yōu)。當一個應用的查詢中經(jīng)常涉及到兩個或多個關系模式的屬性時，系統(tǒng)必須經(jīng)常地進行聯(lián)接運算，而聯(lián)系運算的代價是相當高的，可以說關系模型低效的主要原因就是做聯(lián)接運算引起的，因此在這種情況下，第二范式甚至第一范式也許是最好的。第六十七頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）非BCNF的關系模式雖然從理論上分析會存在不同程度的更新異常，但如果在實際應用中對此關系模式只是查詢，并不執(zhí)行更新操作，則就不會產(chǎn)生實際影響。對于一個具體應用來說，到底規(guī)范化進行到什么程度，需要權衡響應時間和潛在問題兩者的利弊才能決定。一般說來，第三范式就足夠了。第六十八頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）例：在關系模式學生成績單(學號,英語,數(shù)學,語文,平均成績)

中存在下列函數(shù)依賴：學號→英語學號→數(shù)學學號→語文學號→平均成績

(英語,數(shù)學,語文)→平均成績第六十九頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）顯然有：學號→(英語,數(shù)學,語文)

因此該關系模式中存在傳遞函數(shù)信賴，是2NF關系。雖然平均成績可以由其他屬性推算出來，但如果應用中需要經(jīng)常查詢學生的平均成績，為提高效率，我們?nèi)匀豢杀Ａ粼撊哂鄶?shù)據(jù)，對關系模式不再做進一步分解。第七十頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）⒌按照需求分析階段得到的各種應用對數(shù)據(jù)處理的要求，對關系模式進行必要的分解或合并，以提高數(shù)據(jù)操作的效率和存儲空間的利用率常用分解方法水平分解垂直分解第七十一頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）水平分解什么是水平分解把(基本)關系的元組分為若干子集合，定義每個子集合為一個子關系，以提高系統(tǒng)的效率。第七十二頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）水平分解的適用范圍1.滿足“80/20原則”的應用80/20原則：一個大關系中，經(jīng)常被使用的數(shù)據(jù)只是關系的一部分，約20%把經(jīng)常使用的數(shù)據(jù)分解出來，形成一個子關系，可以減少查詢的數(shù)據(jù)量。第七十三頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）水平分解的適用范圍2.并發(fā)事務經(jīng)常存取不相交的數(shù)據(jù)如果關系R上具有n個事務，而且多數(shù)事務存取的數(shù)據(jù)不相交，則R可分解為少于或等于n個子關系，使每個事務存取的數(shù)據(jù)對應一個關系。第七十四頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）水平分解什么是水平分解把(基本)關系的元組分為若干子集合，定義每個子集合為一個子關系，以提高系統(tǒng)的效率。水平分解的適用范圍滿足“80/20原則”的應用并發(fā)事務經(jīng)常存取不相交的數(shù)據(jù)第七十五頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）滿足“80/20原則”的應用80/20原則：一個大關系中，經(jīng)常被使用的數(shù)據(jù)只是關系的一部分，約20%把經(jīng)常使用的數(shù)據(jù)分解出來，形成一個子關系，可以減少查詢的數(shù)據(jù)量。并發(fā)事務經(jīng)常存取不相交的數(shù)據(jù)如果關系R上具有n個事務，而且多數(shù)事務存取的數(shù)據(jù)不相交，則R可分解為少于或等于n個子關系，使每個事務存取的數(shù)據(jù)對應一個關系。第七十六頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）垂直分解什么是垂直分解把關系模式R的屬性分解為若干子集合，形成若干子關系模式。垂直分解的原則經(jīng)常在一起使用的屬性從R中分解出來形成一個子關系模式。第七十七頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）垂直分解的優(yōu)點可以提高某些事務的效率垂直分解的缺點可能使另一些事務不得不執(zhí)行連接操作，從而降低了效率。第七十八頁，共九十三頁，編輯于2023年，星期三數(shù)據(jù)模型的優(yōu)化（續(xù)）垂直分解的適用范圍取決于分解后R上的所有事務的總效率是否得到了提高。進行垂直分解的方法簡單情況：直觀分解復雜情況：用第五章中的模式分解算法垂直分解必須不損失關系模式的語義(保持無損連接性和保持函數(shù)依賴)。第七十九頁，共九十三頁，編輯于2023年，星期三5.4邏輯結構設計5.4.1E-R圖向關系模型的轉換5.4.2向特定DBMS規(guī)定的模型進行轉換5.4.3數(shù)據(jù)模型的優(yōu)化5.4.4設計用戶子模式第八十頁，共九十三頁，編輯于2023年，星期三5.4.4設計用戶子模式定義數(shù)據(jù)庫模式主要是從系統(tǒng)的時間效率、空間效率、易維護等角度出發(fā)。定義用戶外模式時應該更注重考慮用戶的習慣與方便。包括三個方面：

第八十一頁，共九十三頁，編輯于2023年，星期三設計用戶子模式（續(xù)）(1)使用更符合用戶習慣的別名合并各分E-R圖曾做了消除命名沖突的工作，以使數(shù)據(jù)庫系統(tǒng)中同一關系和屬性具有唯一的名字。這在設計數(shù)據(jù)庫整體結構時是非常必要的。但對于某些局部應用，由于改用了不符合用戶習慣的屬性名，可能會使他們感到不方便，第八十二頁，共九十三頁，編輯于2023年，星期三設計用戶子模式（續(xù)）(1)使用更符合用戶習慣的別名(續(xù))因此在設計用戶的子模式時可以重新定義某些屬性名，使其與用戶習慣一致。當然，為了應用的規(guī)范化，我們也不應該一味地遷就用戶。例：負責學籍管理的用戶習慣于稱教師模式的職工號為教師編號。因此可以定義視圖，在視圖中職工號重定義為教師編號第八十三頁，共九十三頁，編輯于2023年，星期三設計用戶子模式（續(xù)）

(2)針對不同級別的用戶定義不同的外模式，以滿足系統(tǒng)對安全性的要求。第八十四頁，共九十三頁，編輯于2023年，星期三設計用戶子模式（續(xù)）例： 教師