數據庫設計步驟

時間 2019-11-08

標籤數據庫設計步驟欄目 SQL 简体版

原文原文鏈接

SQL筆記 --- 數據庫設計步驟

轉自：http://www.cnblogs.com/kzloser/archive/2012/07/13/2589652.html#a2

整體設計過程

數據庫設計步驟:數據庫

設計描述:安全

數據庫設計不一樣階段造成的數據庫各級模式:數據結構

數據庫設計的特色:框架

需求分析

分析和表達用戶需求:數據庫設計

首先把任何一個系統都抽象爲:
分解處理功能和數據:
- 分解處理功能:
  - 將處理功能的具體內容分解爲若干子功能
- 分解數據:
  - 處理功能逐步分解同時,逐級分解所用數據,造成若干層次的數據流圖
- 表達方法:
  - 處理邏輯：用斷定表或斷定樹來描述
  - 數據：用數據字典來描述
將分析結果再次提交給用戶,徵得用戶的承認

任務:函數

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

需求分析過程:post

數據流圖:性能

符號說明:
例子:

數據字典:

與數據流圖的區別
- 數據流圖 -- 表達了數據和處理的關係
- 數據字典 -- 則是系統中各種數據描述的集合
組成:
數據項:
- 形式:
  - 數據項描述 ={ 數據項名, 數據項含義說明, 別名, 數據類型, 長度, 取值範圍, 取值含義, 其餘數據項的邏輯關係, 數據項之間的聯繫 }測試
- 例子:數據項,以「學號」爲例：
  - 數據項：　學號
  - 含義說明：惟一標識每一個學生
  - 別名：　　學生編號
  - 類型：　　字符型
  - 長度：　　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個步驟:

數據庫物理設計

步驟:

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

索引存取:

選擇索引存取方法的通常規則:
- 若是一個(一組)屬性常常在查詢條件中出現,則考慮在這個(這組)屬性上創建索引(組合索引)
- 若是一個屬性常常做爲最大值和最小值等彙集函數的參數,則考慮在這個屬性上創建索引
- 若是一個(或一組)屬性常常在鏈接操做的鏈接條件中出現,則考慮在這個(或這組)屬性上創建索引
關係上定義的索引數過多會帶來較多的額外開銷:
- 維護索引的開銷
- 查找索引的開銷

聚簇:

用途:
- 大大提升按聚簇碼進行查詢的效率
- 節省存儲空間
侷限性:
- 聚簇只能提升某些特定應用的性能
- 創建與維護聚簇的開銷至關大
適用範圍:
- 既適用於單個關係獨立聚簇,也適用於多個關係組合聚簇
- 當經過聚簇碼進行訪問或鏈接是該關係的主要應用,與聚簇碼無關的其餘訪問不多或者是次要的時,可使用聚簇

數據庫實施

數據裝載方法:

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

主要工做:

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

強調兩點:

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