《數據庫系統概論》之數據庫設計六步驟（需求、概念、邏輯、物理、實施、運行維護）

---

0.一圖總覽

1.數據庫設計概述及六步驟簡介

數據庫設計是指對於一個給定的應用環境，構造最優的數據庫模式，建立數據庫及其應用系統，使之能夠有效地存儲數據，滿足各種用戶的應用需求。

1. 數據庫設計的特點
   數據庫設計是一項涉及多學科的綜合性技術，又是一項龐大的工程項目，具有如下特點：
   (1) 數據庫建設是硬件、軟件和幹件（技術和管理的界面）的結合。
   (2) 數據庫設計應該和應用系統設計相結合。

2. 數據庫設計方法
   常用的數據庫設計方法如下：
   （1）新奧爾良方法：將數據庫設計分爲若干階段和步驟
   （2）基於 E-R 模型的設計方法：概念設計階段廣泛採用
   （3）基於 3NF 的設計方法：邏輯階段可採用的有效方法
   （4）ODL（Object Definition Language）方法：面向對象的數據庫設計方法
   （5）計算機輔助設計：ORACLE Designer 2000、SYBASE PowerDesigner

3. 數據庫設計的基本步驟
   數據庫設計分爲 6 個階段：
   （1） 需求分析：準確瞭解與分析用戶需求（包括數據與處理）。
   （2）概念結構設計：對用戶需求進行綜合、歸納與抽象，形成一個獨立於具體 DBMS的概念模型。
   （3）邏輯結構設計：將概念結構轉換爲某個 DBMS 所支持的數據模型，並對其進行優化。
   （4）物理結構設計：爲邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。
   （5） 數據庫實施：建立數據庫，編制與調試應用程序，組織數據入庫，並進行試運行。
   （6）數據庫運行和維護：對數據庫系統進行評價、調整與修改。

需求分析和概念設計獨立於任何數據庫管理系統
邏輯設計和物理設計與選用的DBMS密切相關

2.需求分析—步驟一

需求分析是整個數據庫設計過程中最重要的步驟之一，是後繼各階段的基礎。在需求分析階段，從多方面對整個組織進行調查，收集和分析各項應用對信息和處理兩方面的需求。

2.1 收集資料

收集資料是數據庫設計人員和用戶共同完成的任務。確定企業組織的目標，從這些目標導出對數據庫的總體要求。通過調研，確定由計算機完成的功能。

2.2 分析整理

分析的過程是對所收集到的數據進行抽象的過程，產生求解的模型。

2.3 數據流圖

採用數據流圖來描述系統的功能。數據流圖可以形象地描述事務處理與所需數據的關聯，便於用結構化系統方法，自頂向下，逐層分解，步步細化。

2.4 數據字典

對數據流圖中的數據流和加工等進一步定義，從而完整地反映系統需求。
數據字典的用途：
進行詳細的數據收集和數據分析所獲得的主要結果
數據字典的內容：
數據項
數據結構
數據流
數據存儲
處理過程

2.5 用戶確認

需求分析得到的數據流圖和數據字典要返回給用戶，通過反覆完善，最終取得用戶的認可。

3.概念結構設計—步驟二

概念設計階段的目標是產生整體數據庫概念結構，即概念模式。概念模式是整個組織各個用戶關心的信息結構。描述概念結構的有力工具是 E-R 模型。

3.1 E-R 模型

（1）基本 E-R 模型
E-R 模型通過 E-R 圖表示出來。
將所有實體屬性和實體之間的聯繫均描述出來就構成了一個 E-R 圖

（2）基本 E-R 模型的擴展
數據抽象
一般有 3 種抽象：
(1)分類: 它抽象了對象值和型之間“is member of”的語義。例如：“張英”是“學生”實體中的一員。

(2)聚集 :它抽象了對象內部類型和成分之間“is part of”的語義。例如：若干屬性的聚集組成了實體型。

(3)概括 :它抽象了類型之間“is subset of”的語義。

依賴聯繫

在現實世界中，常常有某些實體對於另一些實體具有很強的依賴關係，即一個實體的存在必須以另一實體的存在爲前提。通常把前者稱爲弱實體。
在E-R圖中，用雙線框表示弱實體，用指向弱實體的箭頭表明依賴聯繫。

超類和子類

概括定義了類型之間的一種子集聯繫。
例如：學生是一個實體型，本科生、研究生也是實體型。本科生、研究生均是學生的子集。把學生稱爲超類，本科生、研究生稱爲學生的子類。
在E-R圖中，用雙豎邊的矩形框表示子類，用直線加小圓圈表示超類-子類聯繫。
子類繼承超類上定義的全部屬性，其本身還可包含其他屬性。

3.2 建立 E-R 模型

（1）設計局部 E-R 模型
確定局部結構範圍
定義實體
聯繫定義
屬性分配

（2）設計全局 E-R 模型
確定公共實體類型
局部E-R模型的合併
消除衝突

（3）全局 E-R 模型的優化
實體類型的合併
冗餘屬性的消除
冗餘聯繫的消除

4.邏輯結構設計—步驟三

邏輯結構設計就是把上述概念模型轉換成爲某個具體的數據庫管理系統所支持的數據模型。

4.1 E-R 模型向關係模式的轉換

轉換原則:
（1）每一個實體類型轉換爲一個關係模式，實體的屬性就是關係的屬性，實體的碼就是關係的碼。
（2）聯繫的轉換
① 一般1:1，1:m聯繫不產生新的關係模式，而是將一方實體的碼加入到多方實體對應的關係模式中，聯繫的屬性也一併加入。
②m:n聯繫要產生一個新的關係模式，該關係模式由聯繫涉及實體的碼加上聯繫的屬性（若有）組成。

具體做法：

（1）兩實體間的 1:1 聯繫

一個 1:1 聯繫可以轉換爲一個獨立的關係模式，也可以與任意一端對應的關係模式合併。如果轉換爲一個獨立的關係模式，則與該聯繫相連的各實體的碼以及聯繫本身的屬性均轉換爲關係的屬性，每個實體的碼均是該關係的候選碼。如果與某一端實體對應的關係模式合併，則需要在該關係模式的屬性中加入另一個關係模式的碼和聯繫本身的屬性。可將任一方實體的主碼納入另一方實體對應的關係中，若有，聯繫的屬性也一併納入。

例如，如圖 6.1 所示的 E-R 圖可轉換爲如下關係模式：
工廠（廠號，廠名，地點，姓名，任期）
廠長（姓名，性別，年齡）
或者：
工廠（廠號，廠名，地點）
廠長（姓名，性別，年齡，廠號，任期）

（2）兩實體間的 1:m 聯繫

可將“1”方實體的主碼納入“m”方實體對應的關係中作爲外碼，同時把聯繫的屬性也一併納入“m”方對應的關係中。

例如，如圖 6.2 所示的 E-R 圖轉換爲如下關係模式：
倉庫（倉庫號，地點，面積）
商品（貨號，品名，價格，倉庫號，數量）

（3）同一實體間的 1:m 聯繫

可在這個實體所對應的關係中多設一個屬性，作爲與該實體相聯繫的另一個實體的主碼。

例如，如圖 6.3 所示的 E-R 圖可轉換爲如下關係模式：
職工（工號，姓名，年齡，性別，職稱，工資，領導者工號，民意測驗）

（4）兩實體間的弱實體聯繫

可將被依賴實體的主碼納入弱實體中，作爲弱實體的主碼或主碼中的一部分。

例如，如圖 6.4 所示的 E-R 圖可轉換爲如下關係模式：
職工（工號，姓名，年齡，性別，職稱）
親屬（工號，親屬姓名，親屬關係）

（5）超類和子類的轉換

超類、子類實體都可轉換爲一個關係，並將超類實體的主碼加到子類實體中。

例如，如圖 6.5 所示的 E-R 圖中各個實體的屬性爲：
職員：職工號，姓名，性別，年齡，參加工作時間
飛行員：飛行小時，健康檢查，飛機型號
機械師：學歷，級別，專業職稱
管理員：職務，職稱

該 E-R 圖轉換爲如下關係模式：

職員（職工號，姓名，性別，年齡，參加工作時間）
飛行員（職工號，飛行小時，健康檢查，飛機型號）
機械師（職工號，學歷，級別，專業職稱）
管理員（職工號，職務，職稱）

爲了查詢方便，可在超類實體中增加一個指示器屬性，根據指示器的值直接查詢子類實體表。所以，職員關係又可以爲：
職員（職工號，姓名，性別，年齡，參加工作時間，職員類型）

（6）兩實體間的 m:n 聯繫

必須對“聯繫”單獨建立一個關係，該關係中至少包含被它所聯繫的雙方實體的“主碼”，如果聯繫有屬性，也要納入這個關係中。

例如，如圖 6.6 所示的 E-R 圖轉換爲如下關係模式：
學生（學號，姓名，性別，年齡）
課程（課程號，課程名，學時）
選修（學號，課程號，成績）

（7）同一實體間的 m:n 聯繫

必須爲這個“聯繫”單獨建立一個關係，該關係中至少應包含被它所聯繫的雙方實體的“主碼”，如果聯繫有屬性，也要納入這個關係中。由於這個“聯繫”只涉及一個實體，所以加入的實體的主碼不能同名。

例如，如圖 6.7 所示的 E-R 圖轉換爲如下關係模式：
零部件（代號，名稱，價格）
組裝（代號，組裝件代號，數量）

（8）兩個以上實體間的 m:n 聯繫

必須爲這個“聯繫”單獨建立一個關係，該關係中至少應包含被它所聯繫的各個實體的“主碼”，若是聯繫有屬性，也要納入這個關係中。

例如，如圖 6.8 所示的 E-R 圖可轉換爲如下關係模式：
供應商（供應商號，供應商名，地址）
零件（零件號，零件名，重量）
項目（項目編號，項目名稱，開工日期）
供應（供應商號，項目編號，零件號，零件數）

4.2 關係模式的優化

最核心的就是要遵循數據庫設計的nF範式

應用關係規範化理論對上述產生的關係模式進行優化，具體步驟如下：
（1）確定每個關係模式內部各個屬性之間的數據依賴以及不同關係模式屬性之間的數據依賴。
（2）對各個關係模式之間的數據依賴進行最小化處理，消除冗餘的聯繫。
（3）確定各關係模式的範式等級。
（4）按照需求分析階段得到的處理要求，確定要對哪些模式進行合併或分解。
（5）爲了提高數據操作的效率和存儲空間的利用率，對上述產生的關係模式進行適當的修改、調整和重構。

4.3 設計用戶子模式

全局關係模型設計完成後，還應根據局部應用的需求，結合具體 DBMS 的特點，設計用戶的子模式。

設計子模式時應注意考慮用戶的習慣和方便性，主要包括：
（1）使用更符合用戶習慣的別名。
（2）可以爲不同級別的用戶定義不同的視圖，以保證系統的安全性。
（3）可將經常使用的複雜的查詢定義爲視圖，簡化用戶對系統的使用。

5.物理結構設計—步驟四

數據庫的物理設計是指對一個給定的邏輯數據庫模型選取一個最適合應用環境的物理結構的過程。物理設計通常分爲兩步：

5.1 確定數據庫的物理結構

（1）確定數據的存取方法

• 索引方法的選擇
• 聚簇方法的選擇

（2）確定數據的存儲結構

• 確定數據的存放位置
  基本原則:根據應用情況將易變部分與穩定部分分開存放、存取頻率較高部分與存取頻率較低部分分開存放
• 確定系統配置
  DBMS產品一般都提供了一些存儲分配參數
  同時使用數據庫的用戶數
  同時打開的數據庫對象數
  內存分配參數
  使用的緩衝區長度、個數
  存儲分配參數
  …….

5.2 物理結構進行評價

對時間效率、空間效率、維護開銷和各種用戶要求進行權衡，從多種設計方案中選擇一個較優的方案。

評價方法（完全依賴於所選用的DBMS ）

• 定量估算各種方案
  存儲空間
  存取時間
  維護代價
• 對估算結果進行權衡、比較，選擇出一個較優的合理的物理結構
• 如果該結構不符合用戶需求，則需要修改設計

6.數據庫實施—步驟五

實施階段的工作主要有：

• 建立數據庫結構
• 數據載入
  數據庫結構建立好後，就可以向數據庫中裝載數據了。組織數據入庫是數據庫實施階段最主要的工作。
• 應用程序的編碼和調試
• 數據庫試運行
  功能測試
  實際運行數據庫應用程序，執行對數據庫的各種操作，測試應用程序的功能是否滿足設計要求
  如果不滿足，對應用程序部分則要修改、調整，直到達到設計要求
  性能測試
  測量系統的性能指標，分析是否達到設計目標
  如果測試的結果與設計目標不符，則要返回物理設計階段，重新調整物理結構，修改系統參數，某些情況下甚至要返回邏輯設計階段，修改邏輯結構

7.數據庫運行維護—步驟六

數據庫系統投入正式運行後，對數據庫經常性的維護工作主要由 DBA 完成，包括：

• 數據庫的轉儲和恢復
  在數據庫試運行階段，系統還不穩定，硬、軟件故障隨時都可能發生
  系統的操作人員對新系統還不熟悉，誤操作也不可避免
  因此必須做好數據庫的轉儲和恢復工作，儘量減少對數據庫的破壞
• 數據庫的安全性、完整性控制
• 數據庫性能的監督、分析和改造
• 數據庫的重組與重構
  重組織的目標
  提高系統性能
  重組織的工作
  按原設計要求
  重新安排存儲位置
  回收垃圾
  減少指針鏈
  數據庫的重組織不會改變原設計的數據邏輯結構和物理結構
  數據庫重構造
  根據新環境調整數據庫的模式和內模式
  增加新的數據項
  改變數據項的類型
  改變數據庫的容量
  增加或刪除索引
  修改完整性約束條件

參考：《數據庫系統概論第五版》、《數據庫原理習題與解析第二版》