標籤：sql 需要 規則 編號 取值 來源 響應 階段 計算
目錄
總體設計過程
需求分析
概念結構設計
邏輯結構設計
資料庫實體設計
資料庫實施
資料庫運行和維護
總體設計過程
資料庫設計步驟:
設計描述:
資料庫設計不同階段形成的資料庫各級模式:
資料庫設計的特點:
需求分析
分析和表達使用者需求:
- 首先把任何一個系統都抽象為:
- 分解處理功能和資料:
- 分解處理功能:
- 分解資料:
- 處理功能逐步分解同時,逐級分解所用資料,形成若干層次的資料流圖
- 表達方法:
- 處理邏輯：用判定表或判定樹來描述
- 資料：用資料字典來描述
- 將分析結果再次提交給使用者,徵得使用者的認可
任務:
- 通過調查,收集與分析資料,獲得使用者對資料要求:
- 資訊要求:
- 指使用者需要從資料庫中獲得資訊的內容與性質,再由資訊要求匯出資料要求
- 處理要求:
- 值使用者要完成什麼處理功能,對初一回應時間有什麼要求,處理方式是批處理還是聯機處理
- 安全性與完整性要求
需求分析過程:
資料流圖:
資料字典:
- 與資料流圖的區別
- 資料流圖 -- 表達了資料和處理的關係
- 資料字典 -- 則是系統中各類資料描述的集合
- 組成:
- 資料項目:
- 形式:
資料項目描述 ={ 資料項目名, 資料項目含義說明, 別名, 資料類型, 長度, 取值範圍, 取值含義, 其他資料項目的邏輯關係, 資料項目之間的聯絡 }
- 例子:資料項目,以“學號”為例：
- 資料項目： 學號
- 含義說明：唯一標識每個學生
- 別名： 學生編號
- 類型： 字元型
- 長度： 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圖實體型間的聯絡有以下不同情況:
- 一個1:1聯絡可以轉換為一個獨立的關係模式,也可以與任意一端對應的關係模式合并:
- 轉換為一個獨立的關係模式
- 與某一端實體對應的關係模式合并
- 一個1:n聯絡可以轉換為一個獨立的關係模式,也可以與n端對應的關係模式合并:
- 轉換為一個獨立的關係模式
- 與n端對應的關係模式合并
- 一個m:n聯絡轉換為一個關係模式
- 三個或三個以上實體間的一個多元聯絡轉換為一個關係模式
- 具有相同碼的關係模式可合并:
- 目的：減少系統中的關係個數
- 合并方法： 將其中一個關係模式的全部屬性加入到另一個關係模式中,然後去掉其中的同義屬性（可能同名也可能不同名）,並適當調整屬性的次序
最佳化資料模型方法:
- 確定資料依賴
- 對於各個關係模式之間的資料依賴進行極小化處理,消除冗餘的聯絡.
- 確定各關係模式分別屬於第幾範式.
- 分析對於應用環境這些模式是否合適,確定是否要對它們進行合并或分解.
- 對關係模式進行必要的分解或合并
設計使用者子模式:
- 使用更符合使用者習慣的別名
- 針對不同層級的使用者定義不同的外模式,以滿足系統對安全性的要求.
- 簡化使用者對系統的使用
任務:
- 將概念結構轉化為具體的資料模型
- 邏輯結構設計的步驟
- 將概念結構轉化為一般的關係、網狀、層次模型
- 將轉化來的關係、網狀、層次模型向特定DBMS支援下的資料模型轉換
- 對資料模型進行最佳化
- 設計使用者子模式
邏輯結構設計時3個步驟:
資料庫實體設計
步驟:
- 確定資料庫的物理結構,在關聯式資料庫中主要指存取方法和儲存結構
- 對物理結構進行評價,評價的重點是時間和空間效率
索引存取:
- 選擇索引存取方法的一般規則:
- 如果一個(一組)屬性經常在查詢條件中出現,則考慮在這個(這組)屬性上建立索引(複合式索引)
- 如果一個屬性經常作為最大值和最小值等聚集合函式的參數,則考慮在這個屬性上建立索引
- 如果一個(或一組)屬性經常在串連操作的串連條件中出現,則考慮在這個(或這組)屬性上建立索引
- 關係上定義的索引數過多會帶來較多的額外開銷:
聚簇:
- 用途:
- 局限性:
- 聚簇只能提高某些特定應用的效能
- 建立與維護聚簇的開銷相當大
- 適用範圍:
- 既適用於單個關係獨立聚簇,也適用於多個關係組合聚簇
- 當通過聚簇碼進行訪問或串連是該關係的主要應用,與聚簇碼無關的其他訪問很少或者是次要的時,可以使用聚簇
資料庫實施
資料裝載方法:
主要工作:
- 功能測試:實際運行資料庫應用程式,執行對資料庫的各種操作,測試應用程式的功能是否滿足設計要求,如果不滿足,對應用程式部分則要修改、調整,直到達到設計要求
- 效能測試:測量系統的效能指標,分析是否達到設計目標,如果測試的結果與設計目標不符,則要返回實體設計階段,重新調整物理結構,修改系統參數,某些情況下甚至要返回邏輯設計階段,修改邏輯結構
強調兩點:
- 分期分批組織資料入庫
- 重新設計物理結構甚至邏輯結構,會導致資料重新入庫.
- 先輸入小批量資料供調試用:
- 待試運行基本合格後再大批量輸入資料
- 逐步增加資料量,逐步完成運行評價
- 由於資料入庫工作量實在太大,費時、費力,所以應分期分批地組織資料入庫
- 資料庫的轉儲和恢複
- 在資料庫試運行階段,系統還不穩定,硬、軟體故障隨時都可能發生
- 系統的操作人員對新系統還不熟悉,誤操作也不可避免
- 因此必須做好資料庫的轉儲和恢複工作,盡量減少對資料庫的破壞
資料庫運行和維護
DBA維護資料庫工作:
- 資料庫的轉儲和恢複
- 資料庫的安全性、完整性控制
- 資料庫效能的監督、分析和改進
- 資料庫的重組織和重構造
重組織:
- 形式:
- 全部重組織
- 部分重組織(只對頻繁增、刪的表進行重組織)
- 目標:
- 工作:
- 按原設計要求:
- 資料庫的重組織不會改變原設計的資料邏輯結構和物理結構
重構造:
- 根據新環境調整資料庫的模式和內模式:
- 增加新的資料項目
- 改變資料項目的類型
- 改變資料庫的容量
- 增加或刪除索引
- 修改完整性條件約束條件
SQL筆記 --- 資料庫設計步驟(轉)
