邏輯結構設計的任務
把概念結構設計階段設計好的基本E-R圖轉換為與選用DBMS產品所支持的數據模型相符合的邏輯結構
邏輯結構設計的步驟
將概念結構轉化為一般的關系、網狀、層次模型
將轉換來的關系、網狀、層次模型向特定DBMS支持下的數據模型轉換
對數據模型進行優化
E-R圖向關系模型的轉換要解決的問題
如何將實體型和實體間的聯系轉換為關系模式
如何確定這些關系模式的屬性和碼
轉換內容
將E-R圖轉換為關系模型：將實體、實體的屬性和實體之間的聯系轉換為關系模式。
實體型間的聯系有以下不同情況 ：
(1)一個1:1聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合並。
轉換為一個獨立的關系模式
與某一端實體對應的關系模式合並(2)一個1:n聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合並。
轉換為一個獨立的關系模式
與n端對應的關系模式合並(3) 一個m:n聯系轉換為一個關系模式。
例，“選修”聯系是一個m:n聯系，可以將它轉換為如下關系模式，其中學號與課程號為關系的組合碼：
選修（學號，課程號，成績）教師（教師號，姓名，職稱）
主鍵：教師號
課程（課程號，課程名稱，教師號，教材）
主鍵：課程號 外鍵：教師號
學生（學號，姓名，性別，教師號）
主鍵：學號 外鍵：教師號
選課（學號，課程號， 成績）
主鍵：（學號，課程號）
外鍵 1：學號，外鍵 2：課程號
(4)三個或三個以上實體間的一個多元聯系轉換為一個關系模式。
例，“講授”聯系是一個三元聯系，可以將它轉換為如下關系模式，其中課程號、職工號和書號為關系的組合碼：
講授（課程號，職工號，書號）
(5)具有相同碼的關系模式可合並
目的：減少系統中的關系個數
合並方法：將其中一個關系模式的全部屬性加入到另一個關系模式中，然後去掉其中的同義屬性（可能同名也可能不同名），並適當調整屬性的次序注意：
從理論上講，1:1聯系可以與任意一端對應的關系模式合並
但在一些情況下，與不同的關系模式合並效率會大不一樣。因此究竟應該與哪端的關系模式合並需要依應用的具體情況而定。
由於連接操作是最費時的操作，所以一般應以盡量減少連接操作為目標。
例如，如果經常要查詢某個班級的班主任姓名，則將管理聯系與教師關系合並更好些。
[例] 把圖7.30中虛線上部的E-R圖轉換為關系模型
部門實體對應的關系模式
部門（部門號，部門名，經理的職工號，…）
此關系模式已包含了聯系“領導”所對應的關系模式
經理的職工號是關系的候選碼
職工實體對應的關系模式
職工（職工號、部門號，職工名，職務，…）
該關系模式已包含了聯系“屬於”所對應的關系模式 [例] 把圖7.30中虛線上部的E-R圖轉換為關系模型（續）
產品實體對應的關系模式
產品（產品號，產品名，產品組長的職工號，…）
供應商實體對應的關系模式
供應商（供應商號，姓名，…）
零件實體對應的關系模式
零件（零件號，零件名，…）
[例] 把圖7.30中虛線上部的E-R圖轉換為關系模型（續）
聯系“參加”所對應的關系模式
職工工作（職工號，產品號，工作天數，…）
聯系“供應”所對應的關系模式
供應（產品號，供應商號，零件號，供應量）
得到初步數據模型後，還應該適當地修改、調整數據模型的結構，以進一步提高數據庫應用系統的性能，這就是數據模型的優化
關系數據模型的優化通常以規范化理論為指導
優化數據模型的方法
確定數據依賴
按需求分析階段所得到的語義，分別寫出每個關系模式內部各屬性之間的數據依賴以及不同關系模式屬性之間數據依賴
消除 冗余的聯系
對於各個關系模式之間的數據依賴進行極小化處理，消除 冗余的聯系。
確定所屬范式
按照數據依賴的理論對關系模式逐一進行分析
考查是否存在部分函數依賴、傳遞函數依賴、多值依賴等
確定各關系模式分別屬於第幾范式
按照需求分析階段得到的各種應用對數據處理的要求，分析對於這樣的應用環境這些模式是否合適，
確定是否要對它們進行合並或分解。
注意：並不是規范化程度越高的關系就越優，一般說來，第三范式就足夠了
例：在關系模式
學生成績單(學號,英語,數學,語文,平均成績)
中存在下列函數依賴：
學號→英語
學號→數學
學號→語文
學號→平均成績
(英語, 數學, 語文)→平均成績
顯然有：
學號→(英語,數學,語文)
因此該關系模式中存在傳遞函數信賴，是2NF關系
雖然平均成績可以由其他屬性推算出來，但如果應用中需要經常查詢學生的平均成績，為提高效率，仍然可保留該冗余數據，對關系模式不再做進一步分解
按照需求分析階段得到的各種應用對數據處理的要求，對關系模式進行必要的分解，以提高數據操作的效率和存儲空間的利用率
常用分解方法
水平分解
垂直分解
水平分解
什麼是水平分解
把(基本)關系的元組分為若干子集合，定義每個子集合為一個子關系，以提高系統的效率
水平分解的適用范圍
滿足“80/20原則”的應用
並發事務經常存取不相交的數據
垂直分解
什麼是垂直分解
把關系模式R的屬性分解為若干子集合，形成若干子關系模式
垂直分解的適用范圍
取決於分解後R上的所有事務的總效率是否得到了提高
定義用戶外模式時應該注重的問題
包括三個方面：
(1) 使用更符合用戶習慣的別名
(2) 針對不同級別的用戶定義不同的View ，以 滿足系統對安全性的要求。
(3) 簡化用戶對系統的使用
[例] 關系模式產品（產品號，產品名，規格，單價，生產車間，生產負責人，產品成本，產品合格率，質量等級），可以在產品關系上建立兩個視圖：
為一般顧客建立視圖：
產品1（產品號，產品名，規格，單價）
為產品銷售部門建立視圖：
產品2（產品號，產品名，規格，單價，車間，生產負責人）
顧客視圖中只包含允許顧客查詢的屬性
銷售部門視圖中只包含允許銷售部門查詢的屬性
生產領導部門則可以查詢全部產品數據
可以防止用戶非法訪問不允許他們查詢的數據，保證系統的安全性
任務
將概念結構轉化為具體的數據模型
邏輯結構設計的步驟
將概念結構轉化為一般的關系、網狀、層次模型
將轉化來的關系、網狀、層次模型向特定DBMS支持下的數據模型轉換
對數據模型進行優化
設計用戶子模式
E-R圖向關系模型的轉換內容
E-R圖向關系模型的轉換原則
優化數據模型的方法
1. 確定數據依賴
2. 對於各個關系模式之間的數據依賴進行極小化處理，消除冗余的聯系。
3. 確定各關系模式分別屬於第幾范式。
4. 分析對於應用環境這些模式是否合適，確定是否要對它們進行合並或分解。
5. 對關系模式進行必要的分解或合並
設計用戶子模式
1. 使用更符合用戶習慣的別名
2. 針對不同級別的用戶定義不同的外模式，以滿足系統對安全性的要求。
3. 簡化用戶對系統的使用
