目錄

總體設計過程
需求分析
概念結構設計
邏輯結構設計
數據庫物理設計
數據庫實施
數據庫運行和維護

總體設計過程

數據庫設計步驟:

設計描述:

數據庫設計不同階段形成的數據庫各級模式:

數據庫設計的特點:

需求分析

分析和表達用戶需求:

• 首先把任何一個系統都抽象為:

  

• 分解處理功能和數據:
  • 分解處理功能:
    • 將處理功能的具體內容分解為若幹子功能
  • 分解數據:
    • 處理功能逐步分解同時,逐級分解所用數據,形成若幹層次的數據流圖
  • 表達方法:
    • 處理邏輯：用判定表或判定樹來描述
    • 數據：用數據字典來描述
• 將分析結果再次提交給用戶,征得用戶的認可

任務:

• 通過調查,收集與分析數據,獲得用戶對數據要求:
  • 信息要求:
    • 指用戶需要從數據庫中獲得信息的內容與性質,再由信息要求導出數據要求
  • 處理要求:
    • 值用戶要完成什麽處理功能,對初一響應時間有什麽要求,處理方式是批處理還是聯機處理
  • 安全性與完整性要求

需求分析過程:

數據流圖:

• 符號說明:

  

• 例子:

  

數據字典:

• 與數據流圖的區別
  • 數據流圖 -- 表達了數據和處理的關系
  • 數據字典 -- 則是系統中各類數據描述的集合

• 組成:

• 數據項:
  • 形式:

    • 數據項描述 ={ 數據項名, 數據項含義說明, 別名, 數據類型, 長度, 取值範圍, 取值含義, 其他數據項的邏輯關系, 數據項之間的聯系 }

  • 例子:數據項,以“學號”為例：
    • 數據項：　學號
    • 含義說明：唯一標識每個學生
    • 別名：　　學生編號
    • 類型：　　字符型
    • 長度：　　8
    • 取值範圍：00000000至99999999
    • 取值含義：前兩位標別該學生所在年級, 後六位按順序編號
• 數據結構:
  • 形式:
    • 數據結構描述 ={ 數據結構名, 含義說明, 組成: { 數據項或數據結構 } }
  • 例子:數據結構,以“學生”為例學生”是該系統中的一個核心數據結構：
    • 數據結構：　學生
    • 含義說明：　是學籍管理子系統的主體數據結構, 定義了一個學生的有關信息
    • 組成：　　　學號,姓名,性別,年齡,所在系,年級
• 數據流:
  • 形式:
    • 數據流描述 ={ 數據流名, 說明, 數據流來源, 數據流去向, 組成: {數據結構}, 平均流量, 高峰期流量 }
  • 例子數據流,“體檢結果”可如下描述：
    • 數據流：　　體檢結果
    • 說明：　　　學生參加體格檢查的最終結果
    • 數據流來源：體檢
    • 數據流去向：批準
    • 組成：　　　……
    • 平均流量
      ：　……
    • 高峰期流量：……
• 數據存儲:
  • 形式:
    • 數據存儲描述 ={ 數據存儲名, 說明, 編號, 輸入的數據流, 輸出的數據流, 組成: {數據結構}, 數據量, 存取頻度, 存取方式 }
  • 例子:數據存儲,“學生登記表”可如下描述：
    • 數據存儲：　學生登記表
    • 說明：記錄學生的基本情況
    • 流入數據流：……
    • 流出數據流：……
    • 組成：　　　……
    • 數據量：　　每年3000張
    • 存取方式：　隨機存取
• 處理過程:
  • 形式:
    • 處理過程描述 ={ 處理過程名, 說明, 輸入:{ 數據流 }, 輸出: {數據流}, 處理: { 處理過程 }}
  • 例子:處理過程“分配宿舍”可如下描述：
    • 處理過程：分配宿舍
    • 說明：　　為所有新生分配學生宿舍
    • 輸入：　　學生,宿舍
    • 輸出：　　宿舍安排
    • 處理：　　在新生報到後,為所有新生分配學生宿舍. 要求同一間宿舍只能安排同一性別的學生, 同一個學生只能安排在一個宿舍中. 每個學生的居住面積不小於3平方米. 安排新生宿舍其處理時間應不超過15分鐘

概念結構設計

特點:

• 能真實、充分地反映現實世界
• 易於理解
• 易於更改
• 易於向關系、網狀、層次等各種數據模型轉換

四類方法:

• 自頂向下:
  • 定義:
    • 即首先定義全局概念結構的框架,然後逐步細化
  • 圖解:

    

• 自底向上:
  • 定義:
    • 即首先定義個局部應用的概念結構,然後將他們集合起來,得到全局概念
  • 步驟:
    • 第1步：抽象數據並設計局部視圖
    • 第2步：集成局部視圖,得到全局概念結構
  • 圖解:

    

• 逐步擴展:
  • 定義:
    • 首先定義最重要的核心概念結構,然後向外擴充,以滾球的方法逐步生成其他概念結構,直至總體概念結構
  • 圖解:

    

• 混合策略:
  • 定義:
    • 即將自頂向下和自底向上相結合,用自頂向下策略設計一個全局概念結構框架,以它為骨架集成由底向上策略中設計的個局部概念結構
  • 圖解:

    

三種常用抽象:

• 分類（Classification）:
  • 定義某一類概念作為現實世界中一組對象的類型
  • 抽象了對象值和型之間的“is member of”的語義
  • 圖例:

    

• 聚集（Aggregation）:
  • 定義某一類型的組成成分
  • 抽象了對象內部類型和成分之間“is part of”的語義
  • 復雜的聚集,某一類型的成分仍是一個聚集
  • 圖例:

    

• 概括（Generalization）:
  • 定義類型之間的一種子集聯系
  • 抽象了類型之間的“is subset of”的語義
  • 繼承性:

    

E-R圖:

• 任務:
  • 將各局部應用涉及的數據分別從數據字典中抽取出來
  • 參照數據流圖,標定各局部應用中的實體、實體的屬性、標識實體的碼
  • 確定實體之間的聯系及其類型（1:1,1:n,m:n）
• 兩條準則:
  • 屬性不能再具有需要描述的性質.即屬性必須是不可分的數據項,不能再由另一些屬性組成
  • 屬性不能與其他實體具有聯系.聯系只發生在實體之間

視圖集成:

• 分類:
  • 一次集成 一次集成多個分E-R圖
  • 通常用於局部視圖比較簡單時
• 逐步集成:
  • 用累加的方式一次集成兩個分E-R圖
• 圖解:

  

• 沖突:
  • 兩類屬性沖突:
    • 屬性域沖突:
      • 屬性值的類型
      • 取值範圍
      • 取值集合不同
    • 屬性取值單位沖突
  • 兩類命名:
    • 沖突 同名異義： 不同意義的對象在不同的局部應用中具有相同的名字
    • 異名同義（一義多名）： 同一意義的對象在不同的局部應用中具有不同的名字
  • 三類結構沖突:
    • 同一對象在不同應用中具有不同的抽象
    • 同一實體在不同分E-R圖中所包含的屬性個數和屬性排列次序不完全相同
    • 實體之間的聯系在不同局部視圖中呈現不同的類型
• 基本任務:
  • 消除不必要的冗余,設計生成基本E-R圖
• 步驟:
  • 合並分E-R圖,生成初步E-R圖:
    • 消除沖突
    • 屬性沖突
    • 命名沖突
    • 結構沖突
  • 修改與重構:
    • 消除不必要的冗余,設計生成基本E-R圖
    • 分析方法
    • 規範化理論

驗證概念結構:

• 整體概念結構內部必須具有一致性,不存在互相矛盾的表達
• 整體概念結構能準確地反映原來的每個視圖結構,包括屬性、實體及實體間的聯系
• 整體概念結構能滿足需要分析階段所確定的所有要求

邏輯結構設計

E-R圖與關系模型轉換:

• 轉換內容:
  • 將實體、實體的屬性和實體之間的聯系轉換為關系模式
• 轉換原則:
  • 一個實體轉換為一個關系模式
  • 實體的屬性即為關系的屬性
  • 實體的碼即為關系的碼

E-R圖實體型間的聯系有以下不同情況:

• 一個1:1聯系可以轉換為一個獨立的關系模式,也可以與任意一端對應的關系模式合並:
  • 轉換為一個獨立的關系模式
  • 與某一端實體對應的關系模式合並
• 一個1:n聯系可以轉換為一個獨立的關系模式,也可以與n端對應的關系模式合並:
  • 轉換為一個獨立的關系模式
  • 與n端對應的關系模式合並
• 一個m:n聯系轉換為一個關系模式
• 三個或三個以上實體間的一個多元聯系轉換為一個關系模式
• 具有相同碼的關系模式可合並:
  • 目的：減少系統中的關系個數
  • 合並方法： 將其中一個關系模式的全部屬性加入到另一個關系模式中,然後去掉其中的同義屬性（可能同名也可能不同名）,並適當調整屬性的次序

優化數據模型方法:

• 確定數據依賴
• 對於各個關系模式之間的數據依賴進行極小化處理,消除冗余的聯系.
• 確定各關系模式分別屬於第幾範式.
• 分析對於應用環境這些模式是否合適,確定是否要對它們進行合並或分解.
• 對關系模式進行必要的分解或合並

設計用戶子模式:

• 使用更符合用戶習慣的別名
• 針對不同級別的用戶定義不同的外模式,以滿足系統對安全性的要求.
• 簡化用戶對系統的使用

任務:

• 將概念結構轉化為具體的數據模型
• 邏輯結構設計的步驟
• 將概念結構轉化為一般的關系、網狀、層次模型
• 將轉化來的關系、網狀、層次模型向特定DBMS支持下的數據模型轉換
• 對數據模型進行優化
• 設計用戶子模式

邏輯結構設計時3個步驟:

數據庫物理設計

步驟:

• 確定數據庫的物理結構,在關系數據庫中主要指存取方法和存儲結構
• 對物理結構進行評價,評價的重點是時間和空間效率

索引存取:

• 選擇索引存取方法的一般規則:
  • 如果一個(一組)屬性經常在查詢條件中出現,則考慮在這個(這組)屬性上建立索引(組合索引)
  • 如果一個屬性經常作為最大值和最小值等聚集函數的參數,則考慮在這個屬性上建立索引
  • 如果一個(或一組)屬性經常在連接操作的連接條件中出現,則考慮在這個(或這組)屬性上建立索引
• 關系上定義的索引數過多會帶來較多的額外開銷:
  • 維護索引的開銷
  • 查找索引的開銷

聚簇:

• 用途:
  • 大大提高按聚簇碼進行查詢的效率
  • 節省存儲空間
• 局限性:
  • 聚簇只能提高某些特定應用的性能
  • 建立與維護聚簇的開銷相當大
• 適用範圍:
  • 既適用於單個關系獨立聚簇,也適用於多個關系組合聚簇
  • 當通過聚簇碼進行訪問或連接是該關系的主要應用,與聚簇碼無關的其他訪問很少或者是次要的時,可以使用聚簇

數據庫實施

數據裝載方法:

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

主要工作:

• 功能測試:實際運行數據庫應用程序,執行對數據庫的各種操作,測試應用程序的功能是否滿足設計要求,如果不滿足,對應用程序部分則要修改、調整,直到達到設計要求
• 性能測試:測量系統的性能指標,分析是否達到設計目標,如果測試的結果與設計目標不符,則要返回物理設計階段,重新調整物理結構,修改系統參數,某些情況下甚至要返回邏輯設計階段,修改邏輯結構

強調兩點:

• 分期分批組織數據入庫
  • 重新設計物理結構甚至邏輯結構,會導致數據重新入庫.
  • 先輸入小批量數據供調試用:
    • 待試運行基本合格後再大批量輸入數據
    • 逐步增加數據量,逐步完成運行評價
  • 由於數據入庫工作量實在太大,費時、費力,所以應分期分批地組織數據入庫
• 數據庫的轉儲和恢復
  • 在數據庫試運行階段,系統還不穩定,硬、軟件故障隨時都可能發生
  • 系統的操作人員對新系統還不熟悉,誤操作也不可避免
  • 因此必須做好數據庫的轉儲和恢復工作,盡量減少對數據庫的破壞

數據庫運行和維護

DBA維護數據庫工作:

• 數據庫的轉儲和恢復
• 數據庫的安全性、完整性控制
• 數據庫性能的監督、分析和改進
• 數據庫的重組織和重構造

重組織:

• 形式:
  • 全部重組織
  • 部分重組織(只對頻繁增、刪的表進行重組織)
• 目標:
  • 提高系統性能
• 工作:
  • 按原設計要求:
    • 重新安排存儲位置
    • 回收垃圾
    • 減少指針鏈
  • 數據庫的重組織不會改變原設計的數據邏輯結構和物理結構

重構造:

• 根據新環境調整數據庫的模式和內模式:
  • 增加新的數據項
  • 改變數據項的類型
  • 改變數據庫的容量
  • 增加或刪除索引
  • 修改完整性約束條件

SQL筆記 --- 數據庫設計步驟(轉)