數據庫從入門到精通：戳我

數據庫設計概念

• 數據庫設計是指對于一個給定的應用環境，構造（設計）優化的數據庫邏輯模式和物理結構， 并據此建立數據庫及其應用系統，使之能夠有效地存儲和管理數據，滿足各種用戶的應用需求，包括信息管理要求和數據操作要求。
• 目標：為用戶和各種應用系統提供一個信息基礎設施和高效率的運行環境。

一、數據庫設計的特點
數據庫建設的基本規律
三分技術，七分管理，十二分基礎數據
管理

• 數據庫建設項目管理
• 企業（即應用部門）的業務管理

基礎數據

• 收集、入庫
• 更新新的數據

結構（數據）設計和行為（處理）設計相結合。將數據庫結構設計和數據處理設計密切結合

二、數據庫設計方法

• 手工與經驗相結合方法
  設計質量與設計人員的經驗和水平有直接關系
  數據庫運行一段時間后常常不同程度地發現各種問 題，增加了維護代價
• 規范設計法
  基本思想：過程迭代和逐步求精
• 新奧爾良（New Orleans）方法
  將數據庫設計分為若干階段和步驟
• 基于E-R模型的數據庫設計方法
  概念設計階段廣泛采用
• 3NF（第三范式）的設計方法
  邏輯階段可采用的有效方法
• CASE即Computer Aided Software Engineering， 中文意思是計算機輔助軟件工程。CASE是一組 工具和方法的集合，可以輔助軟件開發生命周期 各階段進行軟件開發。
  ORACLE Designer
  SYBASE PowerDesigner

三、數據庫設計的基本步驟
（一）數據庫設計的準備工作：選定參加設計的人
1.系統分析人員、數據庫設計人員（核心人員）
自始至終參與數據庫設計，其水平決定了數據庫系統的質量

• 用戶和數據庫管理員
  主要參加需求分析和數據庫的運行維護
  3.應用開發人員（程序員和操作員）
  在系統實施階段參與進來，負責編制程序和準備軟硬件環境
  （二）數據庫設計的過程
  1.需求分析階段
• 準確了解與分析用戶需求（包括數據與處理）
• 最困難、最耗費時間的一步
  2.概念結構設計階段
• 整個數據庫設計的關鍵
• 通過對用戶需求進行綜合、歸納與抽象，形 成一個獨立于具體DBMS的概念模型

需求分析和概念設計獨立于任何數據庫管理系統

3.邏輯結構設計階段

• 將概念結構轉換為某個DBMS所支持的數據模型
• 對其進行優化

4.數據庫物理設計階段

• 為邏輯數據模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）

邏輯設計和物理設計與選用的DBMS密切相關
5.數據庫實施階段
運用DBMS提供的數據庫語言（如SQL）及 宿主語言，根據邏輯設計和物理設計的結果

• 建立數據庫
• 編制與調試應用程序
• 組織數據入庫
• 進行試運行

6.數據庫運行和維護階段

• 數據庫應用系統經過試運行后即可投入正式運行
• 在數據庫系統運行過程中必須不斷地對其進行評價、調整與修改

設計特點

• 把數據庫設計和對數據庫中數據處理的設計緊密結合起來
• 將這兩個方面的需求分析、抽象、設計、實現在各個階段同時進行，相互參照，相互補充，以完善兩方面的設計

數據庫設計過程中的各級模式的形成過程

• 需求分析階段
  綜合各個用戶的應用需求
• 概念設計階段
  形成獨立于機器特點，獨立于各個 DBMS產品的概念模式(E-R圖)
• 邏輯設計階段
  首先將E-R圖轉換成具體的數據庫產品支 持的數據模型，如關系模型，形成數據庫 邏輯模式
  然后根據用戶處理的要求、安全性的考慮， 在基本表的基礎上再建立必要的視圖 (View)，形成數據的外模式
• 物理設計階段
  根據DBMS特點和處理的需要，進行物理 存儲安排，建立索引，形成數據庫內模式

需求分析

一、需求分析的任務

• 詳細調查現實世界要處理的對象（組織、部門、企業等）
• 充分了解原系統（手工系統或計算機系統）
• 明確用戶的各種需求
• 確定新系統的功能
• 充分考慮今后可能的擴充和改變(不能僅僅按當前應用 需求來設計數據庫)

調查的重點是“數據”和“處理”，獲得用戶對數據庫要求。

需求分析的重點：

• 信息要求
  用戶需要從數據庫中獲得信息的內容與性質
  由用戶的信息要求可以導出數據要求，即在數據 庫中需要存儲哪些數據
• 處理要求
  對處理功能的要求
  對處理的響應時間的要求
  對處理方式的要求(批處理 / 聯機處理)
• 新系統的功能必須能夠滿足用戶的信息要求、處理 要求、安全性與完整性要求

需求分析難點：

• 確定用戶最終需求
  用戶缺少計算機知識
  設計人員缺少用戶的專業知識
• 解決方法
  設計人員必須不斷深入地與用戶進行交流

二、需求分析的方法

1. 調查與初步分析用戶需求
⑴ 調查組織機構情況

• 組織部門的組成情況
• 各部門的職責等

⑵ 調查各部門的業務活動情況。調查重點之一。

• 各個部門輸入和使用什么數據
• 如何加工處理這些數據
• 輸出什么信息
• 輸出到什么部門
• 輸出結果的格式是什么
  ⑶ 在熟悉業務活動的基礎上，協助用戶明確對新系統 的各種要求。調查重點之二。
• 信息要求
• 處理要求
• 完全性與完整性要求
  ⑷ 對前面調查的結果進行初步分析
  確定新系統的邊界
• 確定哪些功能由計算機完成或將來準備讓計算機完成
• 確定哪些活動由人工完成 由計算機完成的功能就是新系統應該實現的功能。

2.常用調查方法
⑴跟班作業

• 通過親身參加業務工作了解業務活動的情況
• 能比較準確地理解用戶的需求，但比較耗時

⑵開調查會

• 通過與用戶座談來了解業務活動情況及用戶需求

⑶請專人介紹

⑷詢問

• 對某些調查中的問題，可以找專人詢問

⑸設計調查表請用戶填寫

• 如果調查表設計合理，則很有效，且易于為用戶接受

⑹查閱記錄

• 查閱與原系統有關的數據記錄

3.進一步分析和表達用戶需求
結構化分析方法（Structured Analysis，簡 稱SA方法）

• 從最上層的系統組織機構入手
• 自頂向下、逐層分解分析系統
• 數據流圖和數據字典描述系統

1）首先把任何一個系統都抽象為：

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

三、數據字典
數據字典的用途是各類數據描述的集合
進行詳細的數據收集和數據分析所獲得的主要結果
數據字典的內容
1.數據項
數據項是不可再分的數據單位
對數據項的描述

數據項描述＝ ｛數據項名，數據項含義說明，別名， 數據類型，長度，取值范圍，取值含義， 與其他數據項的邏輯關系， 數據項之間的聯系 ｝

2.數據結構
數據結構反映了數據之間的組合關系。
一個數據結構可以由若干個數據項組成，也可以由若 干個數據結構組成，或由若干個數據項和數據結構混 合組成。
對數據結構的描述

數據結構描述＝ ｛數據結構名，含義說明， 組成:｛數據項或數據結構｝｝

3.數據流

• 數據流是數據結構在系統內傳輸的路徑。
• 對數據流的描述

數據流描述＝ ｛ 數據流名，說明，數據流來源， 數據流去向，組成:｛數據結構｝， 平均流量，高峰期流量｝

4.數據存儲

• 數據存儲是數據結構停留或保存的地方，也是數 據流的來源和去向之一。
• 對數據存儲的描述

數據存儲描述＝ ｛數據存儲名，說明，編號， 輸入的數據流 ，輸出的數據流 ， 組成:｛數據結構｝，數據量， 存取頻度， 存取方式｝

5.處理過程

• 具體處理邏輯一般用判定表或判定樹來描述
• 處理過程說明性信息的描述

處理過程描述＝ ｛處理過程名，說明，輸入:｛數據流｝，輸出:｛數據流｝，處理:｛簡要說明｝｝

數據字典

• 數據字典是關于數據庫中數據的描述，是元數據， 而不是數據本身
• 數據字典在需求分析階段建立，在數據庫設計過程 中不斷修改、充實、完善

概念結構設計

一、概念結構

• 將需求分析得到的用戶需求抽象為信息結構即概念模型的過程就是概念結構設計
• 概念結構是各種數據模型的共同基礎，它比數據模型更獨立于機器、更抽象，從而更加穩定
• 概念結構設計是整個數據庫設計的關鍵

描述概念模型的工具：E-R模型
二、概念結構設計的方法與步驟
設計概念結構的四類方法

• 自頂向下
  首先定義全局概念結構的框架，然后逐步細化
  
• 自底向上
  首先定義各局部應用的概念結構，然后將它們集成 起來，得到全局概念結構
  
• 逐步擴張
  首先定義最重要的核心概念結構，然后向外擴充，以滾雪球的方式逐步生成其他概念結構，直至總體概念結構
  
• 混合策略
  將自頂向下和自底向上相結合，用自頂 向下策略設計一個全局概念結構的框架， 以它為骨架集成由自底向上策略中設計的各局部概念結構。
  自頂向下地進行需求分析
  自底向上地設計概念結構
  
  自底向上設計概念結構的步驟
  第1步：抽象數據并設計局部視圖
  第2步：集成局部視圖，得到全局概念結構
  
  三、數據抽象與局部視圖設計
  1.數據抽象
  抽象是對實際的人、物、事和概念中抽取 所關心的共同特性，忽略非本質的細節， 并把這些特性用各種概念精確地加以描述。
  概念結構是對現實世界的一種抽象
  三種常用抽象：
• 分類（Classification）
  定義某一類概念作為現實世界中一組對象的類型
  抽象了對象值和型之間的“is member of”的語義
• 聚集（Aggregation）
  定義某一類型的組成成分
  抽象了對象內部類型和成分之間“is part of”的語義
  復雜的聚集，某一類型的成分仍是一個聚集
• 概括（Generalization）
  定義類型之間的一種子集聯系
  抽象了類型之間的“is subset of”的語義
  繼承性

2.局部視圖設計
設計分E-R圖的步驟:
1）選擇局部應用

• 在多層的數據流圖中選擇一個適當層次的數據流圖，作為設計分E-R圖的出發點
• 通常以中層數據流圖作為設計分E-R圖的依據

2）逐一設計分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圖的主要工作與關鍵
  合理消除各分E-R圖的沖突

沖突
1.屬性沖突

• 屬性域沖突
  屬性值的類型
  取值范圍
  取值集合不同
• 屬性取值單位沖突

2.命名沖突

• 同名異義：不同意義的對象在不同的局部應用中 具有相同的名字
• 異名同義（一義多名）：同一意義的對象在不同 的局部應用中具有不同的名字

3.結構沖突

• 同一對象在不同應用中具有不同的抽象
• 同一實體在不同局部視圖中所包含的屬性不 完全相同，或者屬性的排列次序不完全相同。
  產生原因：不同的局部應用關心的是該實 體的不同側面。
  解決方法：使該實體的屬性取各分E-R圖 中屬性的并集，再適當設計屬性的次序。
• 實體之間的聯系在不同局部視圖中呈現不同的類型
  解決方法：根據應用語義對實體聯系的類型 進行綜合或調整。

消除不必要的冗余，設計基本E-R圖
1.冗余

• 冗余的數據是指可由基本數據導出的數據；
  冗余的聯系是指可由其他聯系導出的聯系
• 冗余數據和冗余聯系容易破壞數據庫的完整性，給 數據庫維護增加困難
• 并不是所有的冗余數據與冗余聯系都必須加以消除， 有時為了提高某些應用的效率，不得不以冗余信息作為代價。
• 設計數據庫概念結構時，哪些冗余信息必須消除，哪些冗余信息允許存在，需要根據用戶的整體需求來確定。
• 消除不必要的冗余后的初步E-R圖稱為基本E- R圖。

2.消除冗余的方法

• 分析方法
  以數據字典和數據流圖為依據
  根據數據字典中關于數據項之間的邏輯關系 的說明來消除冗余。
  如果是為了提高效率，人為地保留了一些冗 余數據，則應把數據字典中數據關聯的說明 作為完整性約束條件。
  一種更好的方法是把冗余數據定義在視圖中
• 規范化理論
  函數依賴的概念提供了消除冗余聯系的形式 化工具

方法：

確定分E-R圖實體之間的數據依賴 ，并用實體碼之間的函數依賴表示。

求FL的最小覆蓋GL ，差集為D = FL-GL。逐一考察D中的函數依賴，確定是否是冗余的聯系，若 是，就把它去掉
(1) 冗余的聯系一定在D中，而D中的聯系不一定是冗余的；
(2) 當實體之間存在多種聯系時要將實體之間的聯系在形式上加以區分。

驗證整體概念結構：
視圖集成后形成一個整體的數據庫概念結構，對該 整體概念結構還必須進行進一步驗證，確保它能夠 滿足下列條件：

• 整體概念結構內部必須具有一致性，不存在互相矛盾的表達
• 整體概念結構能準確地反映原來的每個視圖結構，包括屬性、實體及實體間的聯系
• 整體概念結構能滿足需求分析階段所確定的所有要求
• 整體概念結構最終還應該提交給用戶，征求用戶和有關人員的意見，進行評審、修改和優化，然后把它確定下來，作為數據庫的概念結構，作為進一步設計數據庫的依據

邏輯結構設計

邏輯結構設計的任務

• 把概念結構設計階段設計好的基本E-R圖轉換為與選 用DBMS產品所支持的數據模型相符合的邏輯結構

邏輯結構設計的步驟

• 將概念結構轉化為一般的關系、網狀、層次模型
• 將轉換來的關系、網狀、層次模型向特定DBMS支持 下的數據模型轉換
• 對數據模型進行優化

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

一、E-R圖向關系模型的轉換
1.轉換內容

• E-R圖向關系模型的轉換要解決的問題
  如何將實體型和實體間的聯系轉換為關系模式
  如何確定這些關系模式的屬性和碼
• 轉換內容
  將E-R圖轉換為關系模型：將實體、實體的屬性和 實體之間的聯系轉換為關系模式。
• 實體型間的聯系有以下不同情況 ：
  (1)一個1:1聯系可以轉換為一個獨立的關系模式， 也可以與任意一端對應的關系模式合并。
  轉換為一個獨立的關系模式；
  與某一端實體對應的關系模式合并。
  (2)一個1:n聯系可以轉換為一個獨立的關系模式， 也可以與n端對應的關系模式合并。
  轉換為一個獨立的關系模式；
  與n端對應的關系模式合并。
  (3) 一個m:n聯系轉換為一個關系模式。
  (4)三個或三個以上實體間的一個多元聯系轉換為一個關系模式。
  (5)具有相同碼的關系模式可合并
  目的：減少系統中的關系個數
  合并方法：將其中一個關系模式的全部屬性加入到另一個關系模式中，然后去掉其中的同義屬性（可能同名也可能 不同名），并適當調整屬性的次序

注意：

• 從理論上講，1:1聯系可以與任意一端對應的關系模式合并
• 但在一些情況下，與不同的關系模式合并效率會大不 一樣。因此究竟應該與哪端的關系模式合并需要依應 用的具體情況而定。
• 由于連接操作是最費時的操作，所以一般應以盡量減少連接操作為目標。

二、數據模型的優化

• 得到初步數據模型后，還應該適當地修改、調 整數據模型的結構，以進一步提高數據庫應用 系統的性能，這就是數據模型的優化
• 關系數據模型的優化通常以規范化理論為指導

1.優化模型方法

• 確定數據依賴
  按需求分析階段所得到的語義，分別寫出每個關系模式內 部各屬性之間的數據依賴以及不同關系模式屬性之間數據 依賴
• 消除冗余的聯系
  對于各個關系模式之間的數據依賴進行極小化處理，消除 冗余的聯系。
• 確定所屬范式
  按照數據依賴的理論對關系模式逐一進行分析
  考查是否存在部分函數依賴、傳遞函數依賴、多值依賴等
  確定各關系模式分別屬于第幾范式
• 按照需求分析階段得到的各種應用對數據處理的要求，分析對于這樣的應用環境這些模式是否合適，確定是否要對它們進行合并或分解。
  并不是規范化程度越高的關系就越優，一般說來，第三范式就足夠了
• 按照需求分析階段得到的各種應用對數據處理的要求， 對關系模式進行必要的分解，以提高數據操作的效率和存儲空間的利用率。常用分解方法：
  水平分解：把(基本)關系的元組分為若干子集合，定義每個子集合為一個子關系，以提高系統的效率。
  適用范圍：滿足“80/20原則”的應用；并發事務經常存取不相交的數據
  垂直分解：把關系模式R的屬性分解為若干子集合，形成若干子關系模式。
  使用范圍：取決于分解后R上的所有事務的總效率是否得到了提高

三、設計用戶子模式
注重的問題
(1) 使用更符合用戶習慣的別名
(2) 針對不同級別的用戶定義不同的View，以滿足系統對安全性的要求。
(3) 簡化用戶對系統的使用

數據庫的物理設計

數據庫的物理設計

• 數據庫在物理設備上的存儲結構與存取方法稱為數據 庫的物理結構，它依賴于選定的數據庫管理系統
• 為一個給定的邏輯數據模型選取一個最適合應用環境 的物理結構的過程，就是數據庫的物理設計

數據庫物理設計的步驟

• 確定數據庫的物理結構，在關系數據庫中主要指存取方法 和存儲結構
• 對物理結構進行評價，評價的重點是時間和空間效率
  如果評價結果滿足原設計要求，則可進入到物理實施階段， 否則，就需要重新設計或修改物理結構，有時甚至要返回 邏輯設計階段修改數據模型
  
  一、數據庫物理設計的內容和方法
  設計物理數據庫結構的準備工作
• 對要運行的事務進行詳細分析，獲得選擇物理數據庫設計所需參數
• 充分了解所用RDBMS的內部特征，特別是系統提 的存取方法和存儲結構

選擇物理數據庫設計所需參數

• 數據庫查詢事務
  查詢的關系
  查詢條件所涉及的屬性
  連接條件所涉及的屬性
  查詢的投影屬性
• 數據更新事務
  被更新的關系
  每個關系上的更新操作條件所涉及的屬性
  修改操作要改變的屬性值
• 每個事務在各關系上運行的頻率和性能要求

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

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

1.關系模式存取方法選擇

• 數據庫系統是多用戶共享的系統，對同一個關系要建立多條存取路徑才能滿足多用戶的多種應用要求
• 物理設計的任務之一就是要確定選擇哪些存取方法，即建立哪些存取路徑

DBMS常用存取方法

• 索引方法
  目前主要是B+樹索引方法
  經典存取方法，使用最普遍
• 聚簇（Cluster）方法
• HASH方法

根據應用要求確定

• 對哪些屬性列建立索引
• 對哪些屬性列建立組合索引
• 對哪些索引要設計為唯一索引

選擇索引存取方法的一般規則

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

關系上定義的索引數過多會帶來較多的額外開銷

• 維護索引的開銷
• 查找索引的開銷

2.聚簇存取方法的選擇
聚簇
為了提高某個屬性（或屬性組）的查詢速度，把這個或這些屬性（稱為聚簇碼）上具有相同值的元組集中存放在連續的物理塊稱為聚簇
聚簇的用途

• 大大提高按聚簇碼進行查詢的效率
• 節省存儲空間
  聚簇以后，聚簇碼相同的元組集中在一起了，因而 聚簇碼值不必在每個元組中重復存儲，只要在一組 中存一次就行了

聚簇的局限性

• 聚簇只能提高某些特定應用的性能
• 建立與維護聚簇的開銷相當大
  對已有關系建立聚簇，將導致關系中元組移動其物理存儲位置，并使此關系上原有的索引無效，必須重建
  當一個元組的聚簇碼改變時，該元組的存儲位置也要做相應移動

聚簇的適用范圍

• 既適用于單個關系獨立聚簇，也適用于多個關系組合聚簇。
• 當通過聚簇碼進行訪問或連接是該關系的主要應用， 與聚簇碼無關的其他訪問很少或者是次要的時候，可 以使用聚簇。

設計候選聚簇

• 對經常在一起進行連接操作的關系可以建立聚簇
• 如果一個關系的一組屬性經常出現在相等比較條件中，則 該單個關系可建立聚簇
• 如果一個關系的一個(或一組)屬性上的值重復率很高，則 此單個關系可建立聚簇。即對應每個聚簇碼值的平均元組 數不太少。太少了，聚簇的效果不明顯

優化聚簇設計

• 從聚簇中刪除經常進行全表掃描的關系；
• 從聚簇中刪除更新操作遠多于連接操作的關系；
• 不同的聚簇中可能包含相同的關系，一個關系可以 在某一個聚簇中，但不能同時加入多個聚簇
  從這多個聚簇方案(包括不建立聚簇)中選擇一個較優的，即 在這個聚簇上運行各種事務的總代價最小

3.HASH存取方法的選擇
選擇HASH存取方法的規則
當一個關系滿足下列兩個條件時，可以選擇HASH存 取方法

• 該關系的屬性主要出現在等值連接條件中或主要 出現在相等比較選擇條件中
• 該關系的大小可預知，而且不變； 或該關系的大小動態改變，但所選用的DBMS提供了 動態HASH存取方法

三、確定數據庫的存儲結構
確定數據庫物理結構的內容
1. 確定數據的存放位置和存儲結構

• 關系
• 索引
• 聚簇
• 日志
• 備份

確定數據存放位置和存儲結構的因素

• 存取時間
• 存儲空間利用率
• 維護代價

基本原則：
根據應用情況將

• 易變部分與穩定部分分開存放
• 存取頻率較高部分與存取頻率較低部分，分開存放

2. 確定系統配置
DBMS產品一般都提供了一些存儲分配參數

• 同時使用數據庫的用戶數
• 同時打開的數據庫對象數
• 內存分配參數
• 使用的緩沖區長度、個數
• 存儲分配參數

四、評價物理結構

• 評價內容
  對數據庫物理設計過程中產生的多種方案進行細致的評價，從中選擇一個較優的方案作為數據庫的物理結構
• 評價方法（完全依賴于所選用的DBMS ）
  定量估算各種方案：存儲空間；存取時間；維護代價
  對估算結果進行權衡、比較，選擇出一個較優的合 理的物理結構
  如果該結構不符合用戶需求，則需要修改設計

數據庫的實施和維護

一、數據的載入和應用程序的調試
數據的載入

• 數據庫結構建立好后，就可以向數據庫中裝載數據了。 組織數據入庫是數據庫實施階段最主要的工作。
• 數據裝載方法
  人工方法
  計算機輔助數據入庫

應用程序的編碼和調試

• 數據庫應用程序的設計應該與數據設計并行進行
• 在組織數據入庫的同時還要調試應用程序

二、數據庫的試運行
在原有系統的數據有一小部分已輸入數據庫后，就可以開始 對數據庫系統進行聯合調試，稱為數據庫的試運行
數據庫試運行主要工作包括：
1）功能測試

• 實際運行數據庫應用程序，執行對數據庫的各種操作，測試應 用程序的功能是否滿足設計要求
• 如果不滿足，對應用程序部分則要修改、調整，直到達到設計 要求

2）性能測試

• 測量系統的性能指標，分析是否達到設計目標
• 如果測試的結果與設計目標不符，則要返回物理設計階段，重 新調整物理結構，修改系統參數，某些情況下甚至要返回邏輯 設計階段，修改邏輯結構

分期分批組織數據入庫

• 重新設計物理結構甚至邏輯結構，會導致數據重 新入庫。
• 由于數據入庫工作量實在太大，費時、費力，所 以應分期分批地組織數據入庫
• 先輸入小批量數據供調試用
  待試運行基本合格后再大批量輸入數據
  逐步增加數據量，逐步完成運行評價

數據庫的轉儲和恢復

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

三、數據庫的運行和維護

• 數據庫試運行合格后，數據庫即可投入正式運行。
• 數據庫投入運行標志著開發任務的基本完成和維護工 作的開始
• 對數據庫設計進行評價、調整、修改等維護工作是一 個長期的任務，也是設計工作的繼續和提高
  應用環境在不斷變化
  數據庫運行過程中物理存儲會不斷變化

在數據庫運行階段，對數據庫經常性的維護 工作主要是由DBA完成的，包括：
1 . 數據庫的轉儲和恢復
2 . 數據庫的安全性、完整性控制
3 . 數據庫性能的監督、分析和改進
4 . 數據庫的重組織和重構造

重組織的形式：

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

重組織的目標：

• 提高系統性能

重組織的工作：

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

數據庫重構造：
根據新環境調整數據庫的模式和內模式

• 增加新的數據項
• 改變數據項的類型
• 改變數據庫的容量
• 增加或刪除索引
• 修改完整性約束條件

總結

以上是生活随笔為你收集整理的『数据库』怎样设计一个数据库的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。