第七章：資料庫設計

7.1  資料庫設計概述
 1、資料庫設計
（1）資料庫設計是指對於一個給定的應用環境，構造（設計）優化的資料庫邏輯模式和物理結構，並據此建立資料庫及其應用系統，使之能夠有效地儲存和管理資料，滿足各種使用者的應用需求，包括資訊管理要求和資料操作要求。
（2）資訊管理要求：在資料庫中應該儲存和管理哪些資料物件 。
（3）資料操作要求：對資料物件需要進行哪些操作，如查詢、增、刪、改、統計等操作。 
（4）資料庫設計的目標是為使用者和各種應用系統提供一個資訊基礎設施和高效率的執行環境 。
（5）高效率的執行環境
         資料庫資料的存取效率高
         資料庫儲存空間的利用率高
        資料庫系統執行管理的效率高

7.1.1資料庫設計的特點

7.1.2  資料庫設計方法
1、大型資料庫設計是涉及多學科的綜合性技術，又是一項龐大的工程專案。
2、它要求多方面的知識和技術。主要包括：
      計算機的基礎知識
      軟體工程的原理和方法
      程式設計的方法和技巧
      資料庫的基本知識
      資料庫設計技術
      應用領域的知識
3、規範設計法
      （1）手工設計方法
      （2） 基本思想： 過程迭代和逐步求精
      （3）典型方法：
      新奧爾良（New Orleans）方法
      基於E-R模型的資料庫設計方法
      3NF（第三正規化）的設計方法
      面向物件的資料庫設計方法
      統一建模語言（UML）方法

7.1.3  資料庫設計的基本步驟

1、資料庫設計分6個階段
     需求分析
     概念結構設計
     邏輯結構設計
     物理結構設計
     資料庫實施
     資料庫執行和維護
2、需求分析和概念設計獨立於任何資料庫管理系統

3、邏輯設計和物理設計與選用的資料庫管理系統密切相關

7.1.4 資料庫設計過程中的各級模式
1、資料庫設計不同階段形成的資料庫各級模式
     需求分析階段：綜合各個使用者的應用需求
     概念設計階段： 形成獨立於機器特點，獨立於各個資料庫管理系統產品的概念模式（E-R圖）
     邏輯設計階段：
    （1） 首先將E-R圖轉換成具體的資料庫產品支援的資料模型，如關係模型，形成資料庫邏輯模式
    （2）然後根據使用者處理的要求、安全性的考慮，在基本表的基礎上再建立必要的檢視（View），形成資料的外模式
    物理設計階段：根據資料庫管理系統特點和處理的需要，進行物理儲存安排，建立索引，形成資料庫內模式

7.2  需求分析

需求分析就是分析使用者的要求
是設計資料庫的起點
結果是否準確地反映了使用者的實際要求，將直接影響到後面各個階段的設計，並影響到設計結果是否合理和實用


7.2.1 需求分析的任務
1、詳細調查現實世界要處理的物件（組織、部門、企業等）
2、充分了解原系統（手工系統或計算機系統）工作概況

3、明確使用者的各種需求
4、在此基礎上確定新系統的功能

5、新系統必須充分考慮今後可能的擴充和改變

 6、調查的重點是“資料”和“處理”，獲得使用者對資料庫的要求
（1）資訊要求
使用者需要從資料庫中獲得資訊的內容與性質
由資訊要求可以匯出資料要求，即在資料庫中需要儲存哪些資料
（2）處理要求
使用者要完成的處理功能
對處理效能的要求
（3）安全性與完整性要求
7、確定使用者最終需求的難點
（1）使用者缺少計算機知識，不能準確地表達自己的需求，他們所提出的需求往往不斷地變化。
設計人員缺少使用者的專業知識，不易理解使用者的真正需求，甚至誤解使用者的需求
解決方法
（2）設計人員必須不斷深入地與使用者進行交流，才能逐步確定使用者的實際需求

7.2.2  需求分析的方法
進一步分析和表達使用者需求
1、分析方法
結構化分析方法（Structured Analysis，簡稱SA方法）：
SA方法從最上層的系統組織機構入手
採用自頂向下、逐層分解的方式分析系統
2、對使用者需求進行分析與表達後，需求分析報告必須提交給使用者，徵得使用者的認可

7.2.3  資料字典
1、資料字典是關於資料庫中資料的描述，即元資料，不是資料本身

2、資料字典在需求分析階段建立，在資料庫設計過程中不斷修改、充實、完善

3、資料字典是進行詳細的資料收集和資料分析所獲得的主要結果
4、資料字典的內容
資料項
資料結構
資料流
資料儲存
處理過程

5、 資料項是資料的最小組成單位
6、 若干個資料項可以組成一個數據結構

7、 資料字典通過對資料項和資料結構的定義來描述資料流、資料儲存的邏輯內容

需求分析小結

1、把需求收集和分析作為資料庫設計的第一階段是十分重要的。
2、第一階段收集的基礎資料（用資料字典來表達）是下一步進行概念設計的基礎。
3、強調兩點 
（1）設計人員應充分考慮到可能的擴充和改變，使設計易於更改，系統易於擴充 
（2）必須強呼叫戶的參與


7.3  概念結構設計
7.3.1 概念模型
1、將需求分析得到的使用者需求抽象為資訊結構（即概念模型）的過程就是概念結構設計
2、概念模型的特點
（1）能真實、充分地反映現實世界，是現實世界的一個真實模型。
（2）易於理解，從而可以用它和不熟悉計算機的使用者交換意見。
（3）易於更改，當應用環境和應用要求改變時，容易對概念模型修改和擴充。
（4）易於向關係、網狀、層次等各種資料模型轉換

3、描述概念模型的工具：E-R模型


7.3.2  E-R模型
1. 實體之間的聯絡
（1）兩個實體型之間的聯絡：
①一對一聯絡（1∶1）

如果對於實體集A中的每一個實體，實體集B中至多有一個（也可以沒有）實體與之聯絡，反之亦然，則稱實體集A與實體集B具有一對一聯絡，記為1∶1。
例如，學校裡一個班級只有一個正班長，而一個班長只在一個班中任職，則班級與班長之間具有一對一聯絡。
②一對多聯絡（1∶n）
如果對於實體集A中的每一個實體，實體集B中有n個實體（n≥0）與之聯絡，反之，對於實體集B中的每一個實體，實體集A中至多隻有一個實體與之聯絡，則稱實體集A與實體集B有一對多聯絡，記為1∶n。
例如，一個班級中有若干名學生，而每個學生只在一個班級中學習，則班級與學生之間具有一對多聯絡。
③多對多聯絡（m∶n）
如果對於實體集A中的每一個實體，實體集B中有n個實體（n≥0）與之聯絡，反之，對於實體集B中的每一個實體，實體集A中也有m個實體（m≥0）與之聯絡，則稱實體集A與實體集B具有多對多聯絡，記為m∶n。
例如，一門課程同時有若干個學生選修，而一個學生可以同時選修多門課程，則課程與學生之間具有多對多聯絡。

（2）兩個以上的實體型之間的聯絡
一般地，兩個以上的實體型之間也存在著一對一、一對多、多對多聯絡。
對於課程、教師與參考書3個實體型，如果一門課程可以有若干個教師講授，使用若干本參考書，而每一個教師只講授一門課程，每一本參考書只供一門課程使用，則課程與教師、參考書之間的聯絡是一對多的。
（3）單個實體型內的聯絡
同一個實體集內的各實體之間也可以存在一對一、一對多、多對多的聯絡。
例如，職工實體型內部具有領導與被領導的聯絡，即某一職工（幹部）“領導”若干名職工，而一個職工僅被另外一個職工直接領導，因此這是一對多的聯絡，如圖7.8所示。

聯絡的度：參與聯絡的實體型的數目
2個實體型之間的聯絡度為2，也稱為二元聯絡；
3個實體型之間的聯絡度為3，稱為三元聯絡；
N個實體型之間的聯絡度為N，也稱為N元聯絡

2. E-R圖
E-R圖提供了表示實體型、屬性和聯絡的方法：
實體型：用矩形表示，矩形框內寫明實體名。
屬性：用橢圓形表示，並用無向邊將其與相應的實體型連線起來。

聯絡：用菱形表示，菱形框內寫明聯絡名，並用無向邊分別與有關實體型連線起來，同時在無向邊旁標上聯絡的型別（1∶1，1∶n或m∶n）。
聯絡可以具有屬性


7.3.5    概念結構設計
1. 實體與屬性的劃分原則
（1）為了簡化E-R圖的處置，現實世界的事物能作為屬性對待的，儘量作為屬性對待。
（2）兩條準則：
作為屬性，不能再具有需要描述的性質。屬性必須是不可分的資料項，不能包含其他屬性。
屬性不能與其他實體具有聯絡，即E-R圖中所表示的聯絡是實體之間的聯絡。
2. E-R圖的整合
E-R圖的整合一般需要分兩步：
合併。解決各分E-R圖之間的衝突，將分E-R圖合併起來生成初步E-R圖。
修改和重構。消除不必要的冗餘，生成基本E-R圖。
（1）合併E-R圖，生成初步E-R圖
各個區域性應用所面向的問題不同，各個子系統的E-R圖之間必定會存在許多不一致的地方，稱之為衝突。
子系統E-R圖之間的衝突主要有三類：
①屬性衝突
屬性域衝突，即屬性值的型別、取值範圍或取值集合不同。
屬性取值單位衝突。
②命名衝突
同名異義，即不同意義的物件在不同的區域性應用中具有相同的名字。
異名同義（一義多名），即同一意義的物件在不同的區域性應用中具有不同的名字。
命名衝突 可能發生在實體、聯絡一級上 也可能發生在屬性一級上 通過討論、協商等行政手段加以解決
③結構衝突
同一物件在不同應用中具有不同的抽象。
    解決方法：把屬性變換為實體或把實體變換為屬性，使同一物件具有相同的抽象。
同一實體在不同子系統的E-R圖中所包含的屬性個數和屬性排列次序不完全相同。
    解決方法：使該實體的屬性取各子系統的E-R圖中屬性的並集，再適當調整屬性的次序。
實體間的聯絡在不同的E-R圖中為不同的型別。
    實體E1與E2在一個E-R圖中是多對多聯絡，在另一個E-R圖中是一對多聯絡
    解決方法是根據應用的語義對實體聯絡的型別進行綜合或調整。

（2）消除不必要的冗餘，設計基本E-R圖
所謂冗餘的資料是指可由基本資料匯出的資料，冗餘的聯絡是指可由其他聯絡匯出的聯絡。
消除冗餘主要採用分析方法，即以資料字典和資料流圖為依據，根據資料字典中關於資料項之間邏輯關係的說明來消除冗餘。

3、用規範化理論來消除冗餘
①確定分E-R圖實體之間的資料依賴。
    實體之間一對一、一對多、多對多的聯絡可以用實體碼之間的函式依賴來表示。於是有函式依賴集FL。
    
7.4  邏輯結構設計
邏輯結構設計的任務
把概念結構設計階段設計好的基本E-R圖轉換為與選用資料庫管理系統產品所支援的資料模型相符合的邏輯結構

7.4.1  E-R圖向關係模型的轉換
1、轉換內容
E-R圖由實體型、實體的屬性和實體型之間的聯絡三個要素組成
關係模型的邏輯結構是一組關係模式的集合
將E-R圖轉換為關係模型：將實體型、實體的屬性和實體型之間的聯絡轉化為關係模式
轉換原則
（1）一個實體型轉換為一個關係模式。
    關係的屬性：實體的屬性
    關係的碼：實體的碼
（2）實體型間的聯絡有以下不同情況
 一個1:1聯絡可以轉換為一個獨立的關係模式，也可以與任意一端對應的關係模式合併。
    ① 轉換為一個獨立的關係模式
    關係的屬性：與該聯絡相連的各實體的碼以及聯絡本身的屬性
    關係的候選碼：每個實體的碼均是該關係的候選碼
②與某一端實體對應的關係模式合併
    合併後關係的屬性：加入對應關係的碼和聯絡本身的屬性
    合併後關係的碼：不變
一個1:n聯絡可以轉換為一個獨立的關係模式，也可以與n端對應的關係模式合併。
①轉換為一個獨立的關係模式
    關係的屬性：與該聯絡相連的各實體的碼以及聯絡本身的屬性
    關係的碼：n端實體的碼
②與n端對應的關係模式合併
    合併後關係的屬性：在n端關係中加入1端關係的碼和聯絡本身的屬性
    合併後關係的碼：不變
    可以減少系統中的關係個數，一般情況下更傾向於採用這種方法
一個m:n聯絡轉換為一個關係模式
    關係的屬性：與該聯絡相連的各實體的碼以及聯絡本身的屬性
    關係的碼：各實體碼的組合
三個或三個以上實體間的一個多元聯絡轉換為一個關係模式。
    關係的屬性：與該多元聯絡相連的各實體的碼以及聯絡本身的屬性
    關係的碼：各實體碼的組合

具有相同碼的關係模式可合併
目的：減少系統中的關係個數
合併方法：
    將其中一個關係模式的全部屬性加入到另一個關係模式中
    然後去掉其中的同義屬性（可能同名也可能不同名）
    適當調整屬性的次序


7.4.2  資料模型的優化
1、一般的資料模型還需要向特定資料庫管理系統規定的模型進行轉換。
2、轉換的主要依據是所選用的資料庫管理系統的功能及限制。沒有通用規則。
3、對於關係模型來說，這種轉換通常都比較簡單。
5、資料庫邏輯設計的結果不是唯一的。
6、得到初步資料模型後，還應該適當地修改、調整資料模型的結構，以進一步提高資料庫應用系統的效能，這就是資料模型的優化。
7、關係資料模型的優化通常以規範化理論為指導。
優化資料模型的方法:
（1）確定資料依賴
    按需求分析階段所得到的語義，分別寫出每個關係模式內部各屬性之間的資料依賴以及不同關係模式屬性之間資料依賴。
（2）對於各個關係模式之間的資料依賴進行極小化處理，消除冗餘的聯絡。
（3）按照資料依賴的理論對關係模式進行分析，考察是否存在部分函式依賴、傳遞函式依賴、多值依賴等，確定各關係模式分別屬於第幾正規化。
（4）按照需求分析階段得到的各種應用對資料處理的要求，分析對於這樣的應用環境這些模式是否合適，確定是否要對它們進行合併或分解。

並不是規範化程度越高的關係就越優
    當查詢經常涉及兩個或多個關係模式的屬性時，系統必須經常地進行連線運算
    連線運算的代價是相當高的
    因此在這種情況下，第二正規化甚至第一正規化也許是適合的。

非BCNF的關係模式雖然會存在不同程度的更新異常，但如果在實際應用中對此關係模式只是查詢，並不執行更新操作，就不會產生實際影響。

對於一個具體應用來說，到底規範化進行到什麼程度，需要權衡響應時間和潛在問題兩者的利弊才能決定

（5）對關係模式進行必要分解，提高資料操作效率和儲存空間的利用率。
常用分解方法
    ①水平分解
什麼是水平分解： 把(基本)關係的元組分為若干子集合，定義每個子集合為一個子關係，以提高系統的效率。
如何分解：
     對符合80/20的，把經常被使用的資料（約20%）水平分解出來，形成一個子關係。
     水平分解為若干子關係，使每個事務存取的資料對應一個子關係。
②垂直分解
什麼是垂直分解： 把關係模式R的屬性分解為若干子集合，形成若干子關係模式。
垂直分解的原則： 經常在一起使用的屬性從R中分解出來形成一個子關係模式
垂直分解的優點：可以提高某些事務的效率
垂直分解的缺點： 可能使另一些事務不得不執行連線操作，降低了效率
垂直分解的適用範圍：取決於分解後R上的所有事務的總效率是否得到了提高
進行垂直分解的方法：
簡單情況：直觀分解
複雜情況：用第6章中的模式分解演算法
垂直分解必須不損失關係模式的語義（保持無損連線性和保持函式依賴）
 

7.4.3  設計使用者子模式
1、定義資料庫模式主要是從系統的時間效率、空間效率、易維護等角度出發。
2、定義使用者外模式時應該更注重考慮使用者的習慣與方便。包括三個方面：
（1）使用更符合使用者習慣的別名
合併各分E-R圖曾做了消除命名衝突的工作，以使資料庫系統中同一關係和屬性具有唯一的名字。這在設計資料庫整體結構時是非常必要的。
用檢視機制可以在設計使用者檢視時可以重新定義某些屬性名，使其與使用者習慣一致，以方便使用。
（2）針對不同級別的使用者定義不同的檢視，以保證系統的安全性。
（3）簡化使用者對系統的使用
如果某些區域性應用中經常要使用某些很複雜的查詢，為了方便使用者，可以將這些複雜查詢定義為檢視。


7.5  物理結構設計
1、什麼是資料庫的物理設計：
資料庫在物理裝置上的儲存結構與存取方法稱為資料庫的物理結構，它依賴於選定的資料庫管理系統。
為一個給定的邏輯資料模型選取一個最適合應用要求的物理結構的過程，就是資料庫的物理設計。
2、資料庫物理設計的步驟
（1）確定資料庫的物理結構
    在關係資料庫中主要指存取方法和儲存結構;
（2） 對物理結構進行評價
    評價的重點是時間和空間效率
（3）若 評價結果滿足原設計要求，則可進入到物理實施階段。否則，就需要重新設計或修改物理結構，有時甚至要返回邏輯設計階段修改資料模型。


7.5.1  資料庫物理設計的內容和方法
1、設計物理資料庫結構的準備工作
充分了解應用環境，詳細分析要執行的事務，以獲得選擇物理資料庫設計所需引數。
充分了解所用關係型資料庫管理系統的內部特徵，特別是系統提供的存取方法和儲存結構。
2、選擇物理資料庫設計所需引數
（1）資料庫查詢事務：
    查詢的關係
    查詢條件所涉及的屬性
    連線條件所涉及的屬性
    查詢的投影屬性:
（2）資料更新事務：
    被更新的關係
    每個關係上的更新操作條件所涉及的屬性
    修改操作要改變的屬性值
（3）每個事務在各關係上執行的頻率和效能要求
3、關係資料庫物理設計的內容
為關係模式選擇存取方法（建立存取路徑）
設計關係、索引等資料庫檔案的物理儲存結構

7.5.2  關係模式存取方法選擇
1、資料庫系統是多使用者共享的系統，對同一個關係要建立多條存取路徑才能滿足多使用者的多種應用要求。
2、物理結構設計的任務之一是根據關係資料庫管理系統支援的存取方法確定選擇哪些存取方法。
3、資料庫管理系統常用存取方法
B+樹索引存取方法
3、選擇索引存取方法的主要內容
（1）根據應用要求確定
    對哪些屬性列建立索引
    對哪些屬性列建立組合索引
    對哪些索引要設計為唯一索引
4、選擇索引存取方法的一般規則
（1）如果一個（或一組）屬性經常在查詢條件中出現，
則考慮在這個（或這組）屬性上建立索引（或組合
索引）
（2）如果一個屬性經常作為最大值和最小值等聚集函式
的引數，則考慮在這個屬性上建立索引
（3）如果一個（或一組）屬性經常在連線操作的連線條
件中 出現，則考慮在這個（或這組）屬性上建立索引
（4）關係上定義的索引數過多會帶來較多的額外開銷
維護索引的開銷
查詢索引的開銷

5、選擇Hash存取方法的規則
如果一個關係的屬性主要出現在等值連線條件中或主要出現在等值比較選擇條件中，而且滿足下列兩個條件之一
    該關係的大小可預知，而且不變； 
    該關係的大小動態改變，但所選用的資料庫管理系統提供了動態Hash存取方法。

6、 聚簇存取方法
（1）什麼是聚簇：
為了提高某個屬性（或屬性組）的查詢速度，把這個或這些屬性（稱為聚簇碼）上具有相同值的元組集中存放在連續的物理塊中稱為聚簇。
該屬性（或屬性組）稱為聚簇碼（cluster key）
許多關係型資料庫管理系統都提供了聚簇功能
聚簇存放與聚簇索引的區別
（2）聚簇索引
建立聚簇索引後，基表中資料也需要按指定的聚簇屬性值的升序或降序存放。也即聚簇索引的索引項順序與表中元組的物理順序一致。
在一個基本表上最多隻能建立一個聚簇索引
（3）聚簇索引的適用條件
很少對基表進行增刪操作
很少對其中的變長列進行修改操作 
（4）聚簇的用途
對於某些型別的查詢，可以提高查詢效率
大大提高按聚簇屬性進行查詢的效率
節省儲存空間
    聚簇以後，聚簇碼相同的元組集中在一起了，因而聚簇碼值不必在每個元組中重複儲存，只要在一組中存一次就行了。
（5）聚簇的侷限性
聚簇只能提高某些特定應用的效能
建立與維護聚簇的開銷相當大
    對已有關係建立聚簇，將導致關係中元組的物理儲存位置移動，並使此關係上原有的索引無效，必須重建。
    當一個元組的聚簇碼改變時，該元組的儲存位置也要做相應改變。
（6）聚簇的適用範圍
既適用於單個關係獨立聚簇，也適用於多個關係組合聚簇
當通過聚簇碼進行訪問或連線是該關係的主要應用，與聚簇碼無關的其他訪問很少或者是次要的時，可以使用聚簇 
    尤其當SQL語句中包含有與聚簇碼有關的（ORDER BY, GROUP BY, UNION, DISTINCT）等子句或短語時，使用聚簇特別有利，可以省去或減化對結果集的排序操作
（7）選擇聚簇存取方法
設計候選聚簇
常在一起進行連線操作的關係可以建立組合聚簇
如果一個關係的一組屬性經常出現在相等比較條件中，則該單個關係可建立聚簇；
如果一個關係的一個（或一組）屬性上的值重複率很高，則此單個關係可建立聚簇。
檢查候選聚簇中的關係，取消其中不必要的關係
     從聚簇中刪除經常進行全表掃描的關係
     從聚簇中刪除更新操作遠多於連線操作的關係

     從聚簇中刪除重複出現的關係

當一個關係同時加入多個聚簇時，必須從這多個聚簇方案
（包括不建立聚簇）中選擇一個較優的，即在這個聚簇上
執行各種事務的總代價最小。

 

7.5.3  確定資料庫的儲存結構
1、確定資料庫物理結構主要指確定資料的存放位置和儲存結構，包括：確定關係、索引、聚簇、日誌、備份等的儲存安排和儲存結構，確定系統配置等。
2、確定資料的存放位置和儲存結構要綜合考慮存取時間、儲存空間利用率和維護代價3個方面的因素。
3、影響資料存放位置和儲存結構的因素
硬體環境
應用需求
    存取時間
    儲存空間利用率
    維護代價
這三個方面常常是相互矛盾的
[ 必須進行權衡，選擇一個折中方案]

1. 確定資料的存放位置
基本原則
根據應用情況將
    易變部分與穩定部分分開存放
    經常存取部分與存取頻率較低部分分開存放

2. 確定系統配置
（1）資料庫管理系統一般都提供了一些儲存分配引數
    同時使用資料庫的使用者數
    同時開啟的資料庫物件數
    記憶體分配引數
    緩衝區分配引數（使用的緩衝區長度、個數）
    儲存分配引數 
    物理塊的大小
    物理塊裝填因子
    時間片大小
    資料庫的大小
    鎖的數目等
（2）系統都為這些變數賦予了合理的預設值。
    在進行物理設計時需要根據應用環境確定這些引數值，以使系統性能最優。
（3）在物理設計時對系統配置變數的調整隻是初步的，要根據系統實際執行情況做進一步的調整，以切實改進系統性能。

7.5.4  評價物理結構
1、對資料庫物理設計過程中產生的多種方案進行評價，從中選擇一個較優的方案作為資料庫的物理結構。
2、評價方法
（1）定量估算各種方案
    儲存空間
    存取時間
    維護代價
（2）對估算結果進行權衡、比較，選擇出一個較優的合理的物理結構。



7.6  資料庫的實施和維護
7.6.1 資料的載入和應用程式的除錯
1.資料的載入
（1）資料庫結構建立好後，就可以向資料庫中裝載資料了。組織資料入庫是資料庫實施階段最主要的工作。
（2）資料裝載方法
人工方法
計算機輔助資料入庫
2.應用程式的除錯
（1）資料庫應用程式的設計應該與資料設計並行進行
（2）在組織資料入庫的同時還要除錯應用程式 
（3）應用程式的設計、編碼和除錯的方法、步驟在軟體工程等課程中有詳細講解，這裡就不贅述了 


7.6.2 資料庫的試執行
1、應用程式除錯完成，並且已有一小部分資料入庫後，就可以開始對資料庫系統進行聯合除錯，也稱資料庫的試執行。
2、主要工作包括：
功能測試：實際執行應用程式，執行對資料庫的各種操作，測試應用程式的各種功能。
效能測試：測量系統的效能指標，分析是否符合設計目標。
3、資料庫效能指標的測量
①資料庫物理設計階段在評價資料庫結構估算時間、空間指標時，作了許多簡化和假設，忽略了許多次要因素，因此結果必然很粗糙。
②資料庫試執行則是要實際測量系統的各種效能指標（不僅是時間、空間指標），如果結果不符合設計目標，則需要返回物理設計階段，調整物理結構，修改引數；有時甚至需要返回邏輯設計階段，調整邏輯結構。
3、資料的分期入庫
（1）重新設計物理結構甚至邏輯結構，會導致資料重新入庫
（2）由於資料入庫工作量實在太大，所以可以採用分期輸入資料的方法
    先輸入小批量資料供先期聯合除錯使用
    待試執行基本合格後再輸入大批量資料
    逐步增加資料量，逐步完成執行評價
4、資料庫的轉儲和恢復
在資料庫試執行階段，系統還不穩定，硬、軟體故障隨時都可能發生
系統的操作人員對新系統還不熟悉，誤操作也不可避免
因此必須做好資料庫的轉儲和恢復工作，儘量減少對資料庫的破壞


7.6.3 資料庫的執行和維護
1、在資料庫執行階段，對資料庫經常性的維護工作主要是由資料庫管理員完成的，包括：
（1）資料庫的轉儲和恢復
    資料庫管理員要針對不同的應用要求制定不同的轉儲計劃，定期對資料庫和日誌檔案進行備份。
    一旦發生介質故障，即利用資料庫備份及日誌檔案備份，儘快將資料庫恢復到某種一致性狀態。
（2）資料庫的安全性、完整性控制
初始定義    
    資料庫管理員根據使用者的實際需要授予不同的操作許可權
    根據應用環境定義不同的完整性約束條件
修改定義
    當應用環境發生變化，對安全性的要求也會發生變化，資料庫管理員需要根據實際情況修改原有的安全性控制
    由於應用環境發生變化，資料庫的完整性約束條件也會變化，也需要資料庫管理員不斷修正，以滿足使用者要求

（3） 資料庫效能的監督、分析和改進
在資料庫執行過程中，資料庫管理員必須監督系統執行，對監測資料進行分析，找出改進系統性能的方法。
    利用監測工具獲取系統執行過程中一系列效能引數的值
    通過仔細分析這些資料，判斷當前系統是否處於最佳執行狀態
    如果不是，則需要通過調整某些引數來進一步改進資料庫效能

（4）資料庫的重組織與重構造
資料庫的重組織
為什麼要重組織資料庫：資料庫執行一段時間後，由於記錄的不斷增、刪、改，會使資料庫的物理儲存變壞，從而降低資料庫儲存空間的利用率和資料的存取效率，使資料庫的效能下降。
重組織的形式
全部重組織
部分重組織：只對頻繁增、刪的表進行重組織
重組織的目標：  提高系統性能
重組織的工作：
按原設計要求
    重新安排儲存位置
    回收垃圾
    減少指標鏈
資料庫的重組織不會改變原設計的資料邏輯結構和物理結構
資料庫管理系統一般都提供了供重組織資料庫使用的實用程式，幫助資料庫管理員重新組織資料庫。

資料庫的重構造
為什麼要進行資料庫的重構造：資料庫應用環境發生變化，會導致實體及實體間的聯絡也發生相應的變化，使原有的資料庫設計不能很好地滿足新的需求
    增加新的應用或新的實體
    取消某些已有應用
    改變某些已有應用

資料庫重構造的主要工作
根據新環境調整資料庫的模式和內模式
    增加或刪除某些資料項
    改變資料項的型別
    增加或刪除某個表
    改變資料庫的容量
    增加或刪除某些索引

重構造資料庫的程度是有限的
若應用變化太大，已無法通過重構資料庫來滿足新的需求，或重構資料庫的代價太大，則表明現有資料庫應用系統的生命週期已經結束，應該重新設計新的資料庫應用系統了。


7.7  小結
1、資料庫的設計過程:
需求分析
概念結構設計
邏輯結構設計
物理結構設計
資料庫實施
資料庫執行維護
設計過程中往往還會有許多反覆
2、資料庫各級模式的形成:
需求分析階段：綜合各個使用者的應用需求（現實世界的需求）。
概念設計階段：概念模式（資訊世界模型），用E-R圖來描述。
邏輯設計階段：邏輯模式、外模式。
物理設計階段：內模式。
3、概念結構設計:
E-R模型的基本概念和圖示方法
E-R模型的設計
把E-R模型轉換為關係模型的方法
在邏輯設計階段將E-R圖轉換成具體的資料庫產品支援的資料模型如關係模型，形成資料庫邏輯模式。
然後根據使用者處理的要求，安全性的考慮，在基本表的基礎上再建立必要的檢視，形成資料的外模式
在物理設計階段根據DBMS特點和處理的需要，進行物理儲存安排，設計索引，形成資料庫內模式