數據庫的邏輯結構設計和物理設計

概念結構設計

概念結構

概念模型
將需求分析得到的用戶需求抽象為信息結構（即概念模型）的過程就是概念結構設計。

**概念模型的特點**

1. 能真實、充分地反映現實世界，是現實世界的一個真實模型。
2. 易於理解，從而可以用它和不熟悉計算機的用戶交換 意見。
3. 易於更改，當應用環境和應用要求改變時，容易對概念模型修改和擴充。
4. 易於向關系、網狀、層次等各種數據模型轉換

描述概念模型的工具
E-R模型

E-R模型

實體之間的聯系
（1）兩個實體型之間的聯系：

• 一對一聯系（1∶1）
  學校里一個班級只有一個正班長，而一個班長只在一個班中任職，則班級與班長之間具有一對一聯系。

• 一對多聯系（1∶n）
  一個班級中有若干名學生，而每個學生只在一個班級中學習，則班級與學生之間具有一對多聯系。

• 多對多聯系（m∶n）
  一門課程同時有若干個學生選修，而一個學生可以同時選修多門課程，則課程與學生之間具有多對多聯系。

（2）一般的，單個實體型 and 兩個以上的實體型之間也存在着一對一、一對多、多對多聯系。

聯系的度：參與聯系的實體型的數目
2個實體型之間的聯系度為2，也稱為二元聯系；
3個實體型之間的聯系度為3，稱為三元聯系；
N個實體型之間的聯系度為N，也稱為N元聯系

E-R圖 E提供了表示實體型、屬性和聯系的方法：

1. 實體型：用矩形表示，矩形框內寫明實體名。

2. 屬性：用橢圓形表示，並用無向邊將其與相應的實體型連接起來。
   例如，學生實體具有學號、姓名、性別、出生年份、系、入學時間等屬性，用E-R圖表示如圖
   

3. 聯系：用菱形表示，菱形框內寫明聯系名，並用無向邊分別與有關實體型連接起來，同時在無向邊旁標上聯系的類型（1∶1，1∶n或m∶n）。
   聯系可以具有屬性
   

概念結構設計

實體與屬性的划分原則：
為了簡化E-R圖的處置，現實世界的事物能作為屬性對待的，盡量作為屬性對待。
兩條准則：

1. 作為屬性，不能再具有需要描述的性質。屬性必須是不可分的數據項，不能包含其他屬性。
2. 屬性不能與其他實體具有聯系，即E-R圖中所表示的聯系是實體之間的聯系。

例: 職工是一個實體，職工號、姓名、年齡是職工的屬性。
職稱如果沒有與工資、福利掛鈎，根據准則1,則可以作為職工實體的屬性
如果不同的職稱有不同的工資、住房標准和不同的附加福利，則職稱作為一個實體更恰當

E-R圖的集成

E-R圖的集成一般需要分兩步

1. 合並。解決各分E-R圖之間的沖突，將分E-R圖合並起來生成初步E-R圖。
2. 修改和重構。消除不必要的冗余，生成基本E-R圖。

（1）合並E-R圖，生成初步E-R圖
各個局部應用所面向的問題不同，各個子系統的E-R圖之間必定會存在許多不一致的地方，稱之為沖突。

子系統E-R圖之間的沖突主要有三類：

• 屬性沖突

• • 屬性域沖突，即屬性值的類型、取值范圍或取值集合不同。
    例如零件號，有的部門把它定義為整數，有的部門把它定義為字符型。
• • 屬性取值單位沖突。
    例如，零件的重量有的以公斤為單位，有的以斤為單位，有的以克為單位

• 命名沖突

• • 同名異義，即不同意義的對象在不同的局部應用中具有相同的名字。
• • 異名同義（一義多名），即同一意義的對象在不同的局部應用中具有不同的名字。
    如對科研項目，財務科稱為項目，科研處稱為課題，生產管理處稱為工程。
• • 命名沖突
    可能發生在實體、聯系一級上，也可能發生在屬性一級上
    通過討論、協商等行政手段加以解決

• 結構沖突

• • 同一對象在不同應用中具有不同的抽象。
    例如，職工在某一局部應用中被當作實體，而在另一局部應用中則被當作屬性。
    解決方法：把屬性變換為實體或把實體變換為屬性，使同一對象具有相同的抽象。
• • 同一實體在不同子系統的E-R圖中所包含的屬性個數和屬性排列次序不完全相同。
    解決方法：使該實體的屬性取各子系統的E-R圖中屬性的並集，再適當調整屬性的次序。
• • 實體間的聯系在不同的E-R圖中為不同的類型。
    實體E1與E2在一個E-R圖中是多對多聯系，在另一個E-R圖中是一對多聯系
    解決方法是根據應用的語義對實體聯系的類型進行綜合或調整。

（2）消除不必要的冗余，設計基本E-R圖
冗余的數據： 能由基本數據導出的數據，
冗余的聯系： 能由其他聯系導出的聯系。
注意：
並不是所有的冗余數據與冗余聯系都必須加以消除，有時為了提高效率，不得不以冗余信息作為代價。

消除冗余方法：

1. 分析方法（主要采用）
   即以數據字典和數據流圖為依據，根據數據字典中關於數據項之間邏輯關系的說明來消除冗余。

2. 用規范化理論來消除冗余

• • 確定分E-R圖實體之間的數據依賴。
    實體之間一對一、一對多、多對多的聯系可以用實體碼之間的函數依賴來表示。於是有函數依賴集FL。
• • 求FL的最小覆蓋GL，差集為 D=FL-GL。
    逐一考察D中的函數依賴，確定是否是冗余的聯系，若是，就把它去掉。

由於規范化理論受到泛關系假設的限制，應注意下面兩個問題：
冗余的聯系一定在D中，而D中的聯系不一定是冗余的；
當實體之間存在多種聯系時，要將實體之間的聯系在形式上加以區分。

邏輯結構設計

邏輯結構設計的任務
把概念結構設計階段設計好的基本E-R圖轉換為與選用數據庫管理系統產品所支持的數據模型相符合的邏輯結構。

對於我們來說就是指：將E-R圖轉換為關系模式

轉換內容
E-R圖由實體型、實體的屬性和實體型之間的聯系三個要素組成。
關系模型的邏輯結構是一組關系模式的集合。
將E-R圖轉換為關系模型就是指：將實體型、實體的屬性和實體型之間的聯系轉化為關系模式

轉換原則：

一個實體型轉換為一個關系模式。
關系的屬性：實體的屬性
關系的碼：實體的碼

實體型間的聯系有以下不同情況

1. 一個1:1聯系可以轉換為一個獨立的關系模式，也可以與任意一端對應的關系模式合並。
   ① 轉換為一個獨立的關系模式
   關系的屬性：與該聯系相連的各實體的碼以及聯系本身的屬性
   關系的候選碼：每個實體的碼均是該關系的候選碼
   ②與某一端實體對應的關系模式合並
   合並后關系的屬性：加入對應關系的碼和聯系本身的屬性
   合並后關系的碼：不變

2. 一個1:n聯系可以轉換為一個獨立的關系模式，也可以與n端對應的關系模式合並。
   ①轉換為一個獨立的關系模式
   關系的屬性：與該聯系相連的各實體的碼以及聯系本身的屬性
   關系的碼：n端實體的碼
   ②與n端對應的關系模式合並
   合並后關系的屬性：在n端關系中加入1端關系的碼和聯系本身的屬性
   合並后關系的碼：不變
   可以減少系統中的關系個數，一般情況下更傾向於采用合並

3. 一個m:n聯系只能轉換為一個關系模式
   關系的屬性：與該聯系相連的各實體的碼以及聯系本身的屬性
   關系的碼：各實體碼的組合

4. 三個或三個以上實體間的一個多元聯系轉換為一個關系模式。
   關系的屬性：與該多元聯系相連的各實體的碼以及聯系本身的屬性
   關系的碼：各實體碼的組合

5. 具有相同碼的關系模式可合並
   目的：減少系統中的關系個數
   合並方法：
   1將其中一個關系模式的全部屬性加入到另一個關系模式中
   2然后去掉其中的同義屬性（可能同名也可能不同名）
   3適當調整屬性的次序

舉例：

可以將部門壓縮到職工
可以將領導壓縮到部門
參加n：m所以必須獨立
負責：可以將職工壓縮到產品中
供應：n：m:p 必須獨立

壓縮后：5個關系變為
5個實體+2個關系

優化數據模型的方法:

數據庫邏輯設計的結果不是唯一的。
優化數據模式就是指： 從一范式優化到到更高的范式優化。

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

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

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

4. 按照需求分析階段得到的各種應用對數據處理的要求，分析對於這樣的應用環境這些模式是否合適，確定是否要對它們進行合並或分解。
   注意： 並不是規范化程度越高的關系就越優
   非BCNF的關系模式雖然會存在不同程度的更新異常，但如果在實際應用中對此關系模式只是查詢，並不執行更新操作，就不會產生實際影響。

5. 對關系模式進行必要分解，提高數據操作效率和存儲空間的利用率。

常用分解方法

1. 水平分解
   把(基本)關系的元組分為若干子集合，定義每個子集合為一個子關系，以提高系統的效率。
   實際中：
   對符合80/20的，把經常被使用的數據（約20%）水平分解出來，形成一個子關系。
   水平分解為若干子關系，使每個事務存取的數據對應一個子關系。

2. 垂直分解
   概念： 把關系模式R的屬性分解為若干子集合，形成若干子關系模式。
   分解原則 經常在一起使用的屬性從R中分解出來形成一個子關系模式
   優點
   可以提高某些事務的效率
   缺點
   可能使另一些事務不得不執行連接操作，降低了效率
   分解要求：
   垂直分解必須不損失關系模式的語義（保持無損連接性和保持函數依賴）

設計用戶子模式(視圖)

1. 使用更符合用戶習慣的別名
2. 針對不同級別的用戶定義不同的視圖，以保證系統的安全性。
3. 簡化用戶對系統的使用

• 如果某些局部應用中經常要使用某些很復雜的查詢，為了方便用戶，可以將這些復雜查詢定義為視圖。

物理結構設計

數據庫的物理結構
數據庫在物理設備上的存儲結構與存取方法。它依賴於選定的數據庫管理系統。
設計目標：
為一個給定的邏輯數據模型選取一個最適合應用要求的物理結構的過程。

關系數據庫物理設計的內容

1. 為關系模式選擇存取方法（建立存取路徑）
2. 設計關系、索引等數據庫文件的物理存儲結構

存取方法選擇

常用存取方法

1. B+樹索引存取方法
   選擇索引存取方法的一般規則

• • 如果一個（或一組）屬性經常在查詢條件中出現，則考慮在這個（或這組）屬性上建立索（或組合索引）
• • 如果一個屬性經常作為最大值和最小值等聚集函數的參數，則考慮在這個屬性上建立索引
• • 如果一個（或一組）屬性經常在連接操作的連接條件中 出現，則考慮在這個（或這組）性上建立索引

2. Hash索引存取方法
   優點：等值查詢速度max
   缺點：范圍查找太慢，不允許出現兩個相同值。
   選擇Hash存取方法的規則

• • 如果一個關系的屬性主要出現在等值連接條件中或主要出現在等值比較選擇條件中，- - - 而且滿足下列兩個條件之一
    該關系的大小可預知，而且不變；
    該關系的大小動態改變，但所選用的數據庫管理系統提供了動態Hash存取方法。

3. 聚簇存取方法
   解釋： 為了提高某個屬性（或屬性組）的查詢速度，把這個或這些屬性（稱為聚簇碼）上具有相同值的元組集中存放在連續的物理塊中稱為聚簇。
   缺點： 一個表只能建立一個，后期維護成本高。
   優點： 某些場景可以提高速度，節省存儲空間（減少聚簇碼的存儲）
   適用條件
   很少對基表進行增刪操作
   很少對其中的變長列進行修改操作

確定數據庫的存儲結構

確定數據庫物理結構主要指確定數據的存放位置和存儲結構。
包括：確定關系、索引、聚簇、日志、備份等的存儲安排和存儲結構，確定系統配置等。
考慮因素：
綜合考慮存取時間、存儲空間利用率和維護代價3個方面的因素。

1.確定數據的存放位置

基本原則
根據應用情況將
易變部分與穩定部分分開存放
經常存取部分與存取頻率較低部分分開存放
例
可以將比較大的表分別放在兩個磁盤上，以加快存取速度，這在多用戶環境下特別有效。
可以將日志文件與數據庫對象（表、索引等）放在不同的磁盤以改進系統的性能。

2. 確定系統配置
   數據庫管理系統一般都提供了一些存儲分配參數（如緩沖區大小等等）
   在進行物理設計時需要根據應用環境確定這些參數值，以使系統性能最優。
   在物理設計時對系統配置變量的調整只是初步的，要根據系統實際運行情況做進一步的調整，以切實改進系統性能。

評價物理結構

評價方法

1. 定量估算各種方案
   存儲空間
   存取時間
   維護代價

2. 對估算結果進行權衡、比較，選擇出一個較優的合理的物理結構。

數據庫的實施和維護

數據的載入

數據庫結構建立好后，就可以向數據庫中裝載數據了。
組織數據入庫是數據庫實施階段最主要的工作。

數據裝載方法
人工方法
計算機輔助數據入庫

應用程序的調試

在組織數據入庫的同時還要調試應用程序。

數據庫應用程序的設計應該與數據設計並行進行。

數據庫的試運行

應用程序調試完成，並且已有一小部分數據入庫后，就可以開始對數據庫系統進行聯合調試，也稱數據庫的試運行。

主要工作包括：
功能測試：實際運行應用程序，執行對數據庫的各種操作，測試應用程序的各種功能。
性能測試：測量系統的性能指標，分析是否符合設計目標。

數據的分期入庫
原因：
重新設計物理結構甚至邏輯結構，會導致數據重新入庫
由於數據入庫工作量實在太大，所以可以采用分期輸入數據的方法

先輸入小批量數據供先期聯合調試使用，待試運行基本合格后再輸入大批量數據，逐步增加數據量，逐步完成運行評價。

數據庫的轉儲和恢復
在數據庫試運行階段，系統還不穩定，硬、軟件故障隨時都可能發生。
系統的操作人員對新系統還不熟悉，誤操作也不可避免
因此必須做好數據庫的轉儲和恢復工作，盡量減少對數據庫的破壞

數據庫的運行和維護

在數據庫運行階段，對數據庫經常性的維護工作主要是由數據庫管理員完成的，包括：

1. 數據庫的轉儲和恢復
   數據庫管理員要針對不同的應用要求制定不同的轉儲計划，定期對數據庫和日志文件進行備份。
   一旦發生介質故障，即利用數據庫備份及日志文件備份，盡快將數據庫恢復到某種一致性狀態。

2. 數據庫的安全性、完整性控制
   初始定義
   數據庫管理員根據用戶的實際需要授予不同的操作權限
   根據應用環境定義不同的完整性約束條件
   修改定義
   當應用環境發生變化，對安全性的要求也會發生變化，數據庫管理員需要根據實際情況修改原有的安全性控制
   由於應用環境發生變化，數據庫的完整性約束條件也會變化，也需要數據庫管理員不斷修正，以滿足用戶要求

3. 數據庫性能的監督、分析和改進
   在數據庫運行過程中，數據庫管理員必須監督系統運行，對監測數據進行分析，找出改進系統性能的方法。
   利用監測工具獲取系統運行過程中一系列性能參數的值
   通過仔細分析這些數據，判斷當前系統是否處於最佳運行狀態
   如果不是，則需要通過調整某些參數來進一步改進數據庫性能

4. 數據庫的重組織與重構造

（1）數據庫的重組織
重組原因：
數據庫運行一段時間后，由於記錄的不斷增、刪、改，會使數據庫的物理存儲變壞，從而降低數據庫存儲空間的利用率和數據的存取效率，使數據庫的性能下降。

重組織的形式

• 全部重組織
• 部分重組織
  只對頻繁增、刪的表進行重組織

重組織的目標
提高系統性能

重組織的工作

• 按原設計要求
  重新安排存儲位置
  回收垃圾
  減少指針鏈
• 數據庫的重組織不會改變原設計的數據邏輯結構和物理結構

數據庫管理系統一般都提供了供重組織數據庫使用的實用程序，幫助數據庫管理員重新組織數據庫。

（2）數據庫的重構造
重構造原因
數據庫應用環境發生變化，會導致實體及實體間的聯系也發生相應的變化，使原有的數據庫設計不能很好地滿足新的需求。

數據庫重構造的主要工作
根據新環境調整數據庫的模式和內模式
增加或刪除某些數據項
改變數據項的類型
增加或刪除某個表
改變數據庫的容量
增加或刪除某些索引

注意：
重構造數據庫的程度是有限的
若應用變化太大，已無法通過重構數據庫來滿足新的需求，或重構數據庫的代價太大，則表明現有數據庫應用系統的生命周期已經結束，應該重新設計新的數據庫應用系統了。

小結

數據庫的設計過程

1. 需求分析
   綜合各個用戶的應用需求（現實世界的需求）。

2. 概念結構設計
   概念模式（信息世界模型），用E-R圖來描述。

3. 邏輯結構設計
   在邏輯設計階段將E-R圖轉換成具體的數據庫產品支持的數據模型如關系模型，形成數據庫邏輯模式。
   然后根據用戶處理的要求，安全性的考慮，在基本表的基礎上再建立必要的視圖，形成數據的外模式

4. 物理結構設計
   在物理設計階段根據DBMS特點和處理的需要，進行物理存儲安排，設計索引，形成數據庫內模式

5. 數據庫實施

6. 數據庫運行維護