數(shù)據庫邏輯設計

1、數(shù)據庫設計,邏輯結構設計,邏輯結構設計,邏輯結構設計的任務 概念結構是各種數(shù)據模型的共同基礎 為了能夠用某一DBMS實現(xiàn)用戶需求，還必須將概念結構進一步轉化為相應的數(shù)據模型，這正是數(shù)據庫邏輯結構設計所要完成的任務。,邏輯結構設計,邏輯結構設計的步驟 將概念結構轉化為關系、網狀、層次或其他數(shù)據結構模型 將得到的關系、網狀、層次模型向特定DBMS支持下的數(shù)據模型轉換 對數(shù)據模型進行優(yōu)化,邏輯結構設計,邏輯結構設計,E-R圖向關系模型的轉換 向特定DBMS的模型進行轉換 數(shù)據模型的優(yōu)化 設計用戶子模式,E-R圖向關系模型轉換,轉換內容 轉換原則,E-R圖向關系模型的轉換（續(xù)）,轉換內容 E-R圖 由

2、實體、實體的屬性和實體之間的聯(lián)系三個要素組成 關系模型的邏輯結構 一組關系模式的集合 將E-R圖轉換為關系模型 將實體、實體的屬性和實體之間的聯(lián)系轉化為關系模式。,E-R圖向關系模型的轉換（續(xù)）,轉換原則 （ 一個實體型轉換為一個關系模式。） 關系的屬性：實體型的屬性 關系的鍵：實體型的鍵 例，學生實體可以轉換為如下關系模式： 學生（學號，姓名，出生日期，所在系， 年級，平均成績） 性別、宿舍、班級、檔案材料、教師、課程、教室、教科書都分別轉換為一個關系模式。,學生,學號,出生 日期,年級,所在系,平均 成績,姓名,E-R圖向關系模型的轉換（續(xù)）,轉換原則 一個m:n聯(lián)系轉換為一個關系模式。

3、關系的屬性：與該聯(lián)系相連的各實體的鍵以及聯(lián)系本身的屬性 關系的鍵：各實體鍵的組合 例，“選修”聯(lián)系是一個m:n聯(lián)系，可以將它轉換為如下關系模式，其中學號與課程號為關系的組合鍵： 選修（學號，課程號，成績）,E-R圖向關系模型的轉換（續(xù)）,轉換原則 一個1:n聯(lián)系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。 1) 轉換為一個獨立的關系模式 關系的屬性：與該聯(lián)系相連的各實體的鍵以及聯(lián)系本身的屬性 關系的鍵：n端實體的鍵,E-R圖向關系模型的轉換（續(xù)）,轉換原則 一個1:n聯(lián)系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合并。 2) 與n端對應的關系模式合并 合并后關系

4、的屬性：在n端關系中加入1端關系的鍵和聯(lián)系本身的屬性 合并后關系的鍵：不變 可以減少系統(tǒng)中的關系個數(shù)，一般情況下更傾向于采用這種方法,E-R圖向關系模型的轉換（續(xù)）,例，“組成”聯(lián)系為1:n聯(lián)系。 將其轉換為關系模式的兩種方法： 1)使其成為一個獨立的關系模式： 組成（學號，班級號） 2)將其與學生關系模式合并： 學生（學號，姓名，出生日期，所在系，年級，班級號，平均成績）,E-R圖向關系模型的轉換（續(xù)）,轉換原則 一個1:1聯(lián)系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。 1) 轉換為一個獨立的關系模式 關系的屬性：與該聯(lián)系相連的各實體的鍵以及聯(lián)系本身的屬性 關系的候選

5、鍵：每個實體的鍵均是該關系的候選碼,E-R圖向關系模型的轉換（續(xù)）,轉換原則 一個1:1聯(lián)系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合并。 2) 與某一端對應的關系模式合并 合并后關系的屬性：加入對應關系的鍵和聯(lián)系本身的屬性 合并后關系的鍵：不變,E-R圖向關系模型的轉換（續(xù)）,例，“管理”聯(lián)系為1:1聯(lián)系，可以有三種轉換方法： （1）轉換為一個獨立的關系模式： 管理（職工號，班級號） 或管理（職工號，班級號）,E-R圖向關系模型的轉換（續(xù)）,（2）“管理”聯(lián)系與班級關系模式合并，則只需在班級關系中加入教師關系的碼，即職工號： 班級（班級號，學生人數(shù)，職工號）,E-R圖向關

6、系模型的轉換（續(xù)）,（3）“管理”聯(lián)系與教師關系模式合并，則只需在教師關系中加入班級關系的碼，即班級號： 教師（職工號，姓名，性別，職稱，班級號， 是否為優(yōu)秀班主任）,E-R圖向關系模型的轉換（續(xù)）,注意： 從理論上講，1:1聯(lián)系可以與任意一端對應的關系模式合并。 但在一些情況下，與不同的關系模式合并效率會大不一樣。因此究竟應該與哪端的關系模式合并需要依應用的具體情況而定。,new,E-R圖向關系模型的轉換（續(xù)）,由于連接操作是最費時的操作，所以一般應以盡量減少連接操作為目標。 例如，如果經常要查詢某個班級的班主任姓名，則將管理聯(lián)系與教師關系合并更好些。,E-R圖向關系模型的轉換（續(xù)）,轉換原

7、則 三個或三個以上實體間的一個多元聯(lián)系轉換為一個關系模式。 關系的屬性：與該多元聯(lián)系相連的各實體的鍵以及聯(lián)系本身的屬性 關系的鍵：各實體鍵的組合,E-R圖向關系模型的轉換（續(xù)）,例，“講授”聯(lián)系是一個三元聯(lián)系，可以將它轉換為如下關系模式，其中課程號、職工號和書號為關系的組合鍵： 講授（課程號，職工號，書號）,E-R圖向關系模型的轉換（續(xù)）,轉換原則 同一實體集的實體間的聯(lián)系，即自聯(lián)系，也可按上述1:1、1:n和m:n三種情況分別處理。 例，教師實體集內部存在領導與被領導的1:n自聯(lián)系，可以將該聯(lián)系與教師實體合并，這時主鍵職工號將多次出現(xiàn)，但作用不同，可用不同的屬性名加以區(qū)分： 教師：職工號，姓

8、名，性別，職稱，系主任,new,E-R圖向關系模型的轉換（續(xù)）, 具有相同鍵的關系模式可合并。 目的：減少系統(tǒng)中的關系個數(shù)。 合并方法：將其中一個關系模式的全部屬性加入到另一個關系模式中，然后去掉其中的同義屬性（可能同名也可能不同名），并適當調整屬性的次序。,E-R圖向關系模型的轉換（續(xù)）,例，“擁有”關系模式： 擁有（學號，性別） 與學生關系模式： 學生（學號，姓名，出生日期，所在系，年級， 班級號，平均成績） 都以學號為碼，可以將它們合并為一個關系模式： 學生（學號，姓名，性別，出生日期，所在系， 年級，班級號，平均成績）,E-R圖向關系模型的轉換（續(xù)）,實例 按照上述七條原則，學生管理子

9、系統(tǒng)中的18個實體和聯(lián)系可以轉換為下列關系模型： 學生（學號，姓名，性別，出生日期，所在系，年級，班級號，平均成績，檔案號） 性別（性別，宿舍樓）,E-R圖向關系模型的轉換（續(xù)）,宿舍（宿舍編號，地址，性別，人數(shù)） 班級（班級號，學生人數(shù)） 教師（職工號，姓名，性別，職稱，班級號，是否為優(yōu)秀班主任）,E-R圖向關系模型的轉換（續(xù)）,教學（職工號，學號） 課程（課程號，課程名，學分，教室號） 選修（學號，課程號，成績） 教科書（書號，書名，價錢） 教室（教室編號，地址，容量） 講授（課程號，教師號，書號） 檔案材料（檔案號，）,E-R圖向關系模型的轉換（續(xù)）,該關系模型由12個關系模式組成 學生

10、關系模式包含了“擁有”聯(lián)系、“組成”聯(lián)系、“歸檔”聯(lián)系所對應的關系模式 教師關系模式包含了“管理”聯(lián)系所對應的關系模式； 宿舍關系模式包含了“住宿”聯(lián)系所對應的關系模式； 課程關系模式包含了“開設”聯(lián)系所對應的關系模式。,邏輯結構設計,E-R圖向關系模型的轉換 向特定DBMS規(guī)定的模型進行轉換 數(shù)據模型的優(yōu)化 設計用戶子模式,向特定DBMS模型進行轉換,一般的數(shù)據模型還需要向特定DBMS規(guī)定的模型進行轉換。 轉換的主要依據是所選用的DBMS的功能及限制。沒有通用規(guī)則,對于關系模型來說，這種轉換通常都比較簡單。,邏輯結構設計,E-R圖向關系模型的轉換 向特定DBMS規(guī)定的模型進行轉換 數(shù)據模型的

11、優(yōu)化 設計用戶子模式,數(shù)據模型的優(yōu)化,數(shù)據庫邏輯設計的結果不是唯一的。 得到初步數(shù)據模型后，還應該適當?shù)匦薷?、調整數(shù)據模型的結構，以進一步提高數(shù)據庫應用系統(tǒng)的性能，這就是數(shù)據模型的優(yōu)化。 關系數(shù)據模型的優(yōu)化通常以規(guī)范化理論為指導。,數(shù)據模型的優(yōu)化（續(xù)）,優(yōu)化數(shù)據模型的方法 確定數(shù)據依賴 按需求分析階段所得到的語義，分別寫出每個關系模式內部各屬性之間的數(shù)據依賴以及不同關系模式屬性之間數(shù)據依賴。,數(shù)據模型的優(yōu)化（續(xù)）,例，課程關系模式內部存在下列數(shù)據依賴： 課程號課程名 課程號學分 課程號教室號 選修關系模式中存在下列數(shù)據依賴： （學號，課程號）成績,數(shù)據模型的優(yōu)化（續(xù)）,學生關系模式中存在下列數(shù)

12、據依賴： 學號姓名 學號性別 學號出生日期 學號所在系 學號年級 學號班級號 學號平均成績 學號檔案號,數(shù)據模型的優(yōu)化（續(xù)）,學生關系模式的學號與選修關系模式的學號之間存在數(shù)據依賴： 學生.學號選修.學號,數(shù)據模型的優(yōu)化（續(xù)）, 對于各個關系模式之間的數(shù)據依賴進行極小化處理，消除冗余的聯(lián)系。,數(shù)據模型的優(yōu)化（續(xù)）, 按照數(shù)據依賴的理論對關系模式逐一進行分析，考查是否存在部分函數(shù)依賴、傳遞函數(shù)依賴、多值依賴等，確定各關系模式分別屬于第幾范式。 例如經過分析可知，課程關系模式屬于BC范式。,數(shù)據模型的優(yōu)化（續(xù)）, 按照需求分析階段得到的各種應用對數(shù)據處理的要求，分析對于這樣的應用環(huán)境這些模式是否合

13、適，確定是否需要對它們進行合并或分解。（通常多采用這個方法利用DD和DFD來分析冗余并消除之）,數(shù)據模型的優(yōu)化（續(xù)）,并不是規(guī)范化程度越高的關系就越優(yōu)。 當一個應用的查詢中經常涉及到兩個或多個關系模式的屬性時，系統(tǒng)必須經常地進行聯(lián)接運算，而聯(lián)系運算的代價是相當高的，可以說關系模型低效的主要原因就是做聯(lián)接運算引起的，因此在這種情況下，第二范式甚至第一范式也許是最好的。,數(shù)據模型的優(yōu)化（續(xù)）,非BCNF的關系模式雖然從理論上分析會存在不同程度的更新異常，但如果在實際應用中對此關系模式只是查詢，并不執(zhí)行更新操作，則就不會產生實際影響。 對于一個具體應用來說，到底規(guī)范化進行到什么程度，需要權衡響應時間

14、和潛在問題兩者的利弊才能決定。一般說來，第三范式就足夠了。,數(shù)據模型的優(yōu)化（續(xù)）,例：在關系模式 學生成績單(學號,英語,數(shù)學,語文,平均成績) 中存在下列函數(shù)依賴： 學號英語 學號數(shù)學 學號語文 學號平均成績 (英語, 數(shù)學, 語文)平均成績,數(shù)據模型的優(yōu)化（續(xù)）,顯然有： 學號(英語,數(shù)學,語文) 因此該關系模式中存在傳遞函數(shù)信賴，是2NF關系。 雖然平均成績可以由其他屬性推算出來，但如果應用中需要經常查詢學生的平均成績，為提高效率，我們仍然可保留該冗余數(shù)據，對關系模式不再做進一步分解。,數(shù)據模型的優(yōu)化（續(xù)）, 按照需求分析階段得到的各種應用對數(shù)據處理的要求，對關系模式進行必要的分解或合并

15、，以提高數(shù)據操作的效率和存儲空間的利用率 常用分解方法 水平分解 垂直分解,數(shù)據模型的優(yōu)化（續(xù)）,水平分解 把(基本)關系的元組分為若干子集合，定義每個子集合為一個子關系，以提高系統(tǒng)的效率。,數(shù)據模型的優(yōu)化（續(xù)）,水平分解的適用范圍 滿足“80/20原則”的應用 80/20原則：一個大關系中，經常被使用的數(shù)據只是關系的一部分，約20% 把經常使用的數(shù)據分解出來，形成一個子關系，可以減少查詢的數(shù)據量。,數(shù)據模型的優(yōu)化（續(xù)）,水平分解的適用范圍 并發(fā)事務經常存取不相交的數(shù)據 如果關系R上具有n個事務，而且多數(shù)事務存取的數(shù)據不相交，則R可分解為少于或等于n個子關系，使每個事務存取的數(shù)據對應一個關系。

16、,數(shù)據模型的優(yōu)化（續(xù)）,垂直分解 什么是垂直分解 把關系模式R的屬性分解為若干子集合，形成若干子關系模式。 垂直分解的原則 經常在一起使用的屬性從R中分解出來形成一個子關系模式。,數(shù)據模型的優(yōu)化（續(xù)）,垂直分解的優(yōu)點 可以提高某些事務的效率 垂直分解的缺點 可能使另一些事務不得不執(zhí)行連接操作，從而降低了效率。,數(shù)據模型的優(yōu)化（續(xù)）,垂直分解的適用范圍 取決于分解后R上的所有事務的總效率是否得到了提高。 進行垂直分解的方法 簡單情況：直觀分解 復雜情況：模式分解算法 垂直分解必須不損失關系模式的語義(保持無損連接性和保持函數(shù)依賴)。,邏輯結構設計,E-R圖向關系模型的轉換 向特定DBMS規(guī)定的模

17、型進行轉換 數(shù)據模型的優(yōu)化 設計用戶子模式,設計用戶子模式,定義數(shù)據庫模式主要是從系統(tǒng)的時間效率、空間效率、易維護等角度出發(fā)。 定義用戶外模式時應該更注重考慮用戶的習慣與方便。包括三個方面：,設計用戶子模式（續(xù)）,(1) 使用更符合用戶習慣的別名 合并各分E-R圖曾做了消除命名沖突的工作，以使數(shù)據庫系統(tǒng)中同一關系和屬性具有唯一的名字。這在設計數(shù)據庫整體結構時是非常必要的。 但對于某些局部應用，由于改用了不符合用戶習慣的屬性名，可能會使他們感到不方便，,設計用戶子模式（續(xù)）,(1) 使用更符合用戶習慣的別名(續(xù)) 在設計用戶的子模式時可以重新定義某些屬性名，使其與用戶習慣一致。 為了應用的規(guī)范化

18、，我們也不應該一味地遷就用戶。 例：負責學籍管理的用戶習慣于稱教師模式的職工號為教師編號。因此可以定義視圖，在視圖中職工號重定義為教師編號,設計用戶子模式（續(xù)）,(2) 針對不同級別的用戶定義不同的外模式，以滿足系統(tǒng)對安全性的要求。 例：教師關系模式中包括職工號、姓名、性別、出生日期、婚姻狀況、學歷、學位、政治面貌、職稱、職務、工資、工齡、教學效果等屬性。,設計用戶子模式（續(xù)）,學籍管理應用只能查詢教師的職工號、姓名、性別、職稱數(shù)據； 課程管理應用只能查詢教師的職工號、姓名、性別、學歷、學位、職稱、教學效果數(shù)據； 教師管理應用則可以查詢教師的全部數(shù)據。,設計用戶子模式（續(xù)）,定義兩個外模式： 教師_學籍管理(職工號，姓名，性別，職稱) 教師_課程管理(工號，姓名，性別，學歷，學位，職稱，教學效果),設計用戶子模式（續(xù)）,授權學籍管理應用只能訪問教師_學籍管理視圖 授權課程管理應用只能訪問教師_課程管理視圖 授權教師管理應用能訪問教師表 這樣就可以防止用戶非法訪問本來不允許他們查詢的數(shù)據，保證了系統(tǒng)的安全性。,設計用戶子模式（續(xù)）,(3) 簡化用戶對系統(tǒng)的使用 如果某些局部應用中經常要使用某些很復雜的查詢，為了方便用戶，可以將這些復雜查詢定義為視圖。,邏輯結構設計小結,任務 將概念結構轉化為具體的數(shù)據模型