數據庫系統概論——第七章數據庫設計

一、數據庫設計概述

1. 數據庫設計的特點

（1）數據庫建設的基本規律
三分技術，七分管理，十二分基礎數據
管理：數據庫建設項目管理、企業的業務管理
基礎數據：數據的收集、整理、組織和更新。
（2）結構設計和行爲設計相結合
結構設計：即數據設計
行爲設計：即處理設計
傳統的軟件工程：重視行爲設計
早期的數據庫：重視結構設計

2. 數據庫設計的方法
（1）手工試湊法
（2）規範設計方法（手工設計方法）
基本思想：過程迭代和逐步求精
1）新奧爾良（New Orleans）方法
2）基於E-R模型的數據庫設計方法
3）3NF（第三範式）的設計方法
4）面向對象的數據庫設計方法
5）統一建模語言（UML）方法

3. 數據庫設計的基本步驟
（1）數據庫設計分爲6個階段
需求分析
概念結構設計
邏輯結構設計
物理結構設計
數據庫實施
數據庫運行和維護

設計一個完善的數據庫應用系統往往是上述6個階段的不斷反覆
這個設計步驟既是數據庫設計的過程，也包括了數據庫應用系統的設計過程

需求分析和概念設計獨立於任何數據庫管理系統
邏輯設計和物理設計與選用的數據庫管理系統密切相關

（2）參加人員
①系統分析員和數據庫設計人員
②數據庫管理員和用戶代表
③應用開發人員（程序員和操作員）

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

（1）需求分析階段：
綜合各個用戶的應用需求
（2）概念設計階段:
形成獨立於機器特點，獨立於各個數據庫管理系統產品的概念模型（E-R圖）
（3）邏輯設計階段：
①首先將E-R圖轉換成具體的數據庫產品支持的數據模型，如關係模型，形成數據庫邏輯模式
②然後根據用戶處理的要求、安全性的考慮，在基礎表的基礎上再建立必要的視圖view，形成外模式
（4）物理設計階段：
根據數據庫管理系統的特點和處理的需要，形成物理存儲安排，建立索引，形成數據庫的內模式

二、需求分析
1. 需求分析的任務
就是分析用戶的要求
調查的重點是“數據”和“處理”，獲得用戶對數據庫的要求
（1）信息要求
用戶需要從數據庫中獲得信息的內容與性質
由信息要求可以導出數據要求，即在數據庫中需要存儲哪些數據
（2）處理要求
用戶要完成的處理功能
對處理性能的要求
（3）安全性與完整性要求

2. 需求分析的方法
調查清楚用戶的實際需求並進行初步分析
與用戶達成共識
分析與表達這些需求
（1）調查用戶需求的步驟
①調查組織機構情況
②調查各部門的業務活動情況
③協助用戶明確對新系統的各種要求，包括信息要求、處理要求、完全性與完整性要求
④確定新系統的邊界

（2）常用的調出方法
①跟班作業
②開調查會
③請專人介紹
④詢問
⑤設計調查表請用戶填寫
⑥查閱記錄
（3）分析方法
結構化分析方法（SA）
SA方法從最上層的系統組織機構入手
採用自頂向下、逐層分解的方式分析系統
（4）對用戶需求進行分析與表達後，需求分析報告必須提交給用戶，徵得用戶的認可

3. 數據字典（不是關係數據庫管理系統的那個數據數據字典）
（1）數據字典是關於數據庫中數據的描述，即元數據，不是數據本身
（2）數據字典在需求分析階段建立，在數據庫設計過程中不斷修改、充實、完善
（3）數據字典是進行詳細的數據收集和數據分析所獲得的主要結果
（4）數據字典的內容
①數據項
②數據結構
③數據流
④數據存儲
⑤處理過程
1）數據項是數據的最小組成單位，是不可再分的

數據項描述={數據項名,數據項含義說明,別名,
數據類型,長度,取值範圍,取值含義,
與其他數據項的邏輯關係,
數據項之間的聯繫}
“取值範圍”、“與其他數據項的邏輯關係”定義了數據的完整性約束條件，是設計數據檢驗功能的依據
可以用關係規範化理論爲指導，用數據依賴的概念分析和表示數據項之間的聯繫

2）數據結構
數據結構反映了數據之間的組合關係。
一個數據結構可以由若干個數據項組成，也可以由若干個數據結構組成，或由若干個數據項和數據結構混合組成。
數據結構描述=
{數據結構名，含義說明，組成:{數據項或數據結構}}

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

3）數據流
數據流是數據結構在系統內傳輸的路徑。
對數據流的描述
　數據流描述={數據流名,說明,數據流來源,
數據流去向,組成:{數據結構},
平均流量,高峯期流量}

數據流來源：說明該數據流來自哪個過程
數據流去向：說明該數據流將到哪個過程去
平均流量：在單位時間（每天、每週、每月等）裏的傳輸次數
高峯期流量：在高峯時期的數據流量

4）數據存儲
數據存儲是數據結構停留或保存的地方，也是數據流的來源和去向之一。
對數據存儲的描述
　數據存儲描述={數據存儲名,說明,編號,輸
入的數據流 ,輸出的數據流,
組成:{數據結構},數據量,
存取頻度,存取方式}

存取頻度：每小時、每天或每週存取次數，每次存取的數據量等信息
存取方法：批處理 / 聯機處理；檢索 / 更新；順序檢索 / 隨機檢索
輸入的數據流：數據來源
輸出的數據流：數據去向

5）處理過程
處理過程的具體處理邏輯一般用判定表或判定樹來描述。數據字典中只需要描述處理過程的說明性信息

處理過程說明性信息的描述
處理過程描述={處理過程名,說明,輸入:{數據流},
輸出:{數據流},處理:{簡要說明}}

簡要說明：說明該處理過程的功能及處理要求
功能：該處理過程用來做什麼
處理要求：處理頻度要求，如單位時間裏處理多少事務，多少數據量、響應時間要求等
處理要求是後面物理設計的輸入及性能評價的標準

第一階段收集的基礎數據（用數據字典來表達）是下一步進行概念設計的基礎。

三、概念結構設計

1. 概念模型
將需求分析得到的用戶需求抽象爲信息結構（即概念模型）的過程就是概念結構設計

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

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個實體型，如果一門課程可以有若干個教師講授，使用若干本參考書，而每一個教師只講授一門課程，每一本參考書只供一門課程使用，則課程與教師、參考書之間的聯繫是一對多的，如圖7.7(a)所示。

3）單個實體型內的聯繫
例如，職工實體型內部具有領導與被領導的聯繫，即某一職工（幹部）“領導”若干名職工，而一個職工僅被另外一個職工直接領導，因此這是一對多的聯繫，如圖

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

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

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

例子：

某個工廠物資管理的概念模型。物資管理涉及的實體有：
①倉庫：屬性有倉庫號、面積、電話號碼
②零件：屬性有零件號、名稱、規格、單價、描述
③供應商：屬性有供應商號、姓名、地址、電話號碼、賬號
④項目：屬性有項目號、預算、開工日期
⑤職工：屬性有職工號、姓名、年齡、職稱

這些實體之間的聯繫如下： 
 ①一個倉庫可以存放多種零件，一種零件可以存放在多個倉庫中，因此倉庫和零件具有多對多的聯繫。用庫存量來表示某種零件在某個倉庫中的數量。
② 一個倉庫有多個職工當倉庫保管員，一個職工只能在一 個倉庫工作，因此倉庫和職工之間是一對多的聯繫。
③職工之間具有領導與被領導關係。即倉庫主任領導若
④保管員，因此職工實體型中具有一對多的聯繫。
死供應商、項目和零件三者之間具有多對多的聯繫。即一 個供應商可以供給若干項目多種零件，每個項目可以使用不同供應商供應的零件，每種零件可由不同供應商供 給。

5. 概念結構設計
（1）實體與屬性的劃分原則
①作爲屬性，不能再具有需要描述的性質。屬性必須是不可分的數據項，不能包含其他屬性。
②屬性不能與其他實體具有聯繫，即E-R圖中所表示的聯繫是實體之間的聯繫。

例題：
銷售管理子系統E-R圖的設計。

該子系統的主要功能是：
①處理顧客和銷售員送來的訂單
②工廠是根據訂貨安排生產的
③交出貨物同時開出發票
④收到顧客付款後，根據發票存根和信貸情況進行應收款處理

解答：
（1）每張訂單由訂單號、若干頭信息和訂單細節組成。訂單細節又有訂貨的零件號、數量等來描述。按照準則（2），訂單細節就不能作訂單的屬性處理而應該上升爲實體。一張訂單可以訂若干產品，所以訂單與訂單細節兩個實體之間是1∶n的聯繫。
（2）原訂單和產品的聯繫實際上是訂單細節和產品的聯繫。每條訂貨細節對應一個產品描述，訂單處理時從中獲得當前單價、產品重量等信息。
（3）工廠對大宗訂貨給予優惠。每種產品都規定了不同訂貨數量的折扣，應增加一個“折扣規則”實體存放這些信息，而不應把它們放在產品實體中。

最後得到銷售管理子系統E-R圖如圖所示。

（2）E-R圖的集成
1）集成步驟：

①合併。解決各分E-R圖之間的衝突**，將分E-R圖合併起來生成初步E-R圖。**
a）衝突：各個局部應用所面向的問題不同，各個子系統的E-R圖之間必定會存在許多不一致的地方，稱之爲衝突。

b）子系統E-R圖之間的衝突主要有三類
屬性衝突

😊屬性域衝突，即屬性值的類型、取值範圍或取值集合不同。
😊屬性取值單位衝突。

eg：零件號，有的部門把它定義爲整數，有的部門把它定義爲字符型。
eg：年齡，某些部門以出生日期形式表示職工的年齡，而另一些部門用整數表示職工的年齡。
eg：零件的重量有的以公斤爲單位，有的以斤爲單位，有的以克爲單位。

命名衝突

😊同名異義，即不同意義的對象在局部應用中具有相同的名字
😊異名同義：即同一意義的對象在不同的局部應用中具有不同的名字。
😊命名衝突：通過談論、協商等行政手段加以解決

結構衝突

😊同一對象在不同應用中具有不同的抽象。
對象在某一局部應用中被當做實體，而在另一局部應用中則被當作屬性。
解決方法：把屬性變換爲實體或把實體變換爲屬性，使同一對象具有相同的抽象。
😊同一實體在不同子系統的E-R圖中所包含的屬性個數和屬性排列次序不完全相同。
解決方法：使該實體的屬性取各子系統的E-R圖中屬性的並集，再適當調整屬性的次序。
😊實體間的聯繫在不同的E-R圖中爲不同的類型實體E1與E2在一個E-R圖中是多對多聯繫，在另一個E-R圖中是一對多聯繫
解決方法：根據應用的語義對實體聯繫的類型進行綜合或調整。

②修改和重構。消除不必要的冗餘。生成基礎E-R圖。
冗餘：
冗餘數據：可由基本數據導出的數據
冗餘聯繫：可有其他聯繫導出的聯繫
消除冗餘方法：分析方法，即以數據字典和數據流圖爲依據，根據數據字典中關於數據項之間邏輯關係的說明來消除冗餘。

用規範化理論消除冗餘
1）確定分E-R圖實體之間的數據依賴
實體之間一對一、一對多、多對多的聯繫可以用實體碼之間的函數依賴來表示。於是有函數依賴集FL。

例如：

圖中：
部門和職工之間一對多的聯繫：職工號→部門號
職工和產品之間多對多的聯繫：職工號，產品號）→工作天數等

2）求FL的最小覆蓋GL，差集爲 D=FL-GL。逐一考察D中的函數依賴，確定是否是冗餘的聯繫，若是，就把它去掉。
注意：冗餘聯繫一定在D中，而D中的聯繫不一定是冗餘的；當實體之間存在多種聯繫時，要將實體之間的聯繫在形式上加以區別。

❤異名同義，項目和產品含義相同。某個項目實質上是指某個產品的生產。統一用產品作實體名。

❤工廠物資管理中職工與倉庫的工作關係已包含在勞動人事管理的部門與職工之間的聯繫之中，所以可以取消。
❤職工之間領導與被領導關係可由部門與職工（經理）之間的領導關係、部門與職工之間的從屬關係兩者導出，所以也可以取消。

四、邏輯結構設計

任務：把概念結構設計階段設計好的基本E-R圖轉換爲與選用數據庫管理系統產品所支持的數據模型相符合的邏輯結構

1. E-R圖向關係模型的轉換
（1）轉換內容
E-R圖：由實體型、實體的屬性和實體型之間的聯繫三個要素組成。
關係模型的邏輯結構：一組關係模式的集合
所以，將E-R圖轉換爲關係模型：將實體型、實體的屬性和實體型之間的聯繫轉化爲關係模式

（2）😊😊😊轉換原則😊😊😊（重點）
1）一個實體性轉換爲一個關係模式
關係的屬性：實體的屬性
關係的碼：實體的碼
2）實體型之間的聯繫有以下不同情況
①1:1聯繫
可以轉換爲一個獨立的關係模式，也可以與任意一端對應的關係模式合併。
a.轉換爲一個獨立的關係模式
關係的屬性：與該聯繫相連的各實體的碼以及聯繫本身的屬性。
關係的候選碼：與該聯繫相連的各實體的碼。
b.與某一端實體對應的關係模式合併
合併後關係的屬性：加入對應關係的碼和聯繫本身的屬性
合併後關係的碼：不變
②1:n聯繫
可以轉換爲一個獨立的關係模式，也可以與n端對應的關係模式合併
a.轉換爲一個獨立的關係模式
關係的屬性：與該聯繫相連的各實體的碼以及聯繫本身的屬性
關係的碼：n端實體的碼
b.與n端對應的關係模式合併（可以減少系統中的關係數，一般更傾向於這種方法）
合併後關係的屬性：在n端關係中加入1端關係的碼和聯繫本身的屬性
合併後關係的碼：不變
③m:n聯繫
轉換爲一個關係模式
關係的屬性：與該聯繫相連的各實體的碼以及聯繫本身的屬性
關係的碼：各實體碼的組合
④三個或三個以上實體間的一個多元聯繫
轉換爲一個關係模式。
關係的屬性：與該多元聯繫相連的各實體的碼以及聯繫本身的屬性
關係的碼：各實體碼的組合
⑤具有相同碼的關係模式可合併
目的：減少系統中的關係個數
合併方法：
將其中一個關係模式的全部屬性加入到另一個關係模式中；然後去掉其中的同義屬性（可能同名也可能不同名；適當調整屬性的次序。

例題：

部門（部門號，部門名，經理的職工號，…）
職工（職工號、部門號，職工名，職務，…）
產品（產品號，產品名，產品組長的職工號，…）
供應商（供應商號，姓名，…）
零件（零件號，零件名，…）
職工工作（職工號，產品號，工作天數，…）
供應（產品號，供應商號，零件號，供應量）

2. 數據模型的優化
數據庫邏輯設計的結果不是唯一的。
關係數據模型的優化通常以規範化理論爲指導。
優化數據模型的方法:
（1）確定數據依賴
每個關係模式內部各屬性之間的數據依賴
不同關係模式屬性之間數據依賴。
（2）對於各個關係模式之間的數據依賴進行極小化處理，消除冗餘的聯繫。
（3）按照數據依賴的理論對關係模式進行分析，考察是否存在部分函數依賴、傳遞函數依賴、多值依賴等，確定各關係模式分別屬於第幾範式。
（4）按照需求分析階段得到的各種應用對數據處理的要求，分析對於這樣的應用環境這些模式是否合適，確定是否要對它們進行合併或分解。

注意：並不是規範化程度越高的關係就越優

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

（5）對關係模式進行必要分解，提高數據操作效率和存儲空間的利用率。
常用分解方法：1）水平分解 2）垂直分解

3. 設計用戶子模式
定義數據庫模式主要是從系統的時間效率、空間效率、易維護等角度出發。
定義用戶外模式時應該更注重考慮用戶的習慣與方便。包括三個方面：
（1）使用更符合用戶習慣的別名
（2）針對不同級別的用戶定義不同的視圖，以保證系統的安全性
（3）簡化用戶對系統的使用
如果某些局部應用中經常要使用某些很複雜的查詢，爲了方便用戶，可以將這些複雜查詢定義爲視圖。

五、物理結構設計

1. 什麼是物理結構？
數據庫在物理設備上的①存儲結構②存取方法
2. 什麼是數據庫的物理設計？
爲一個給定的邏輯數據模型選取一個最適合應用要求的物理結構的過程
3. 數據庫物理設計的步驟
（1）確定數據庫的物理結構
存取方法和存儲結構
（2）對物理結構進行評價
（3）若評價結果滿足原設計要求，則可進入到物理實施階段。否則，就需要重新設計或修改物理結構，有時甚至要返回邏輯設計階段修改數據模型。
4. 數據庫物理設計的內容和方法
（1）準備工作
瞭解應用環境 + 分析要運行的事務——>獲得選擇物理數據庫設計所需參數
瞭解所用關係型數據庫管理系統的內部特徵（系統提供的存取方法和存儲結構）
（2）選擇物理數據庫設計所需參數
數據庫查詢事務
數據更新事務
每個事務在各關係上運行的頻率和性能要求
（3）關係數據庫設計的內容
爲關係模式選擇存取方法（建立存取路徑）
設計關係、索引等數據庫文件的物理存儲結構

5. 關係模式存取方法的選擇
數據庫系統是多用戶共享的系統，對同一個關係要建立多條存取路徑才能滿足多用戶的多種應用要求。
物理結構設計的任務之一是根據關係數據庫管理系統支持的存取方法確定選擇哪些存取方法。

數據庫管理系統常用的存取方法
①B+樹索引存取方法
②Hash索引存取方法
③聚簇存取方法

（1）B+樹索引存取方法的選擇

選擇索引存取方法的主要內容
①根據應用要求確定
●對哪些屬性列建立索引
●對哪些屬性列建立組合索引
●對哪些索引要設計爲唯一索引
②選擇索引存取方法的一般規則
●如果一個（或一組）屬性經常在查詢條件中出現，
則考慮在這個（或這組）屬性上建立索引（或組合
索引）
●如果一個屬性經常作爲最大值和最小值等聚集函數
的參數，則考慮在這個屬性上建立索引
●如果一個（或一組）屬性經常在連接操作的連接條
件中出現，則考慮在這個（或這組）屬性上建立索
引
③關係上定義的索引數過多會帶來較多的額外開銷
維護索引的開銷、查找索引的開銷

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

（3）聚簇存取方法的選擇
什麼是聚簇？？？
爲了提高某個屬性（或屬性組）的查詢速度，把這個或這些屬性（稱爲聚簇碼）上具有相同值的元組集中存放在連續的物理塊中稱爲聚簇。

注意：
●建立聚簇索引後，基表中數據也需要按指定的聚簇屬性值的升序或降序存放。即聚簇索引的索引項順序與表中元組的物理順序一致。
●在一個基本表上最多只能建立一個聚簇索引

聚簇索引的適用條件？？？
●很少對基表進行增刪操作
●很少對其中的變長列進行修改操作

聚簇的用途？？？
●大大提高按聚簇屬性進行查詢的效率

●解決存儲空間
聚簇以後，聚簇碼相同的元組集中在一起了，因而聚簇碼值不必在每個元組中重複存儲，只要在一組中存一次就行了。

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

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

選擇聚簇存取方法？？？
●設計候選聚簇
①常在一起進行連接操作的關係可以建立組合聚簇
②如果一個關係的一組屬性經常出現在相等比較條件中，則該單個關係可建立聚簇；
③如果一個關係的一個（或一組）屬性上的值重複率很高，則此單個關係可建立聚簇。
●檢查候選聚簇中的關係，取消其中不必要的關係
①從聚簇中刪除經常進行全表掃描的關係
②從聚簇中刪除更新操作遠多於連接操作的關係
③從聚簇中刪除重複出現的關係

6. 確定數據庫的存儲結構

（1）確定數據庫存放位置
1）確定數據庫物理結構主要指確定數據的存放位置和存儲結構，包括：確定關係、索引、聚簇、日誌、備份等的存儲安排和存儲結構，確定系統配置等。
2）影響數據存放位置和存儲結構的因素
①硬件環境
②應用需求
●存取時間
●存儲空間利用率
●維護代價
這三個方面常常是相互矛盾的，必須進行權衡，選擇一個折中方案
3）基本原則
●易變部分與穩定部分分開存放
●經常存取部分與存取頻率較低部分分開存放
eg：可以將比較大的表分別放在兩個磁盤上，以加快存取速度，這在多用戶環境下特別有效。
eg：可以將日誌文件與數據庫對象（表、索引等）放在不同的磁盤以改進系統的性能。

（2）確定系統配置

在進行物理設計時需要根據應用環境確定這些參數值，以使系統性能最優。
在物理設計時對系統配置變量的調整隻是初步的，要根據系統實際運行情況做進一步的調整，以切實改進系統性能。

7. 評價物理結構
（1）評價方法
1）定量估算各種方案
存儲空間
存取時間
維護代價
2）對估算結果進行權衡、比較，選擇出一個較優的合理的物理結構。

六、數據庫的實施和維護

1. 數據的載入和應用程序的調試
數據庫結構建立好後，就可以向數據庫中裝載數據了。組織數據入庫是數據庫實施階段最主要的工作。
（1）數據裝載方法
人工方法
計算機輔助數據入庫
（2）應用程序的調試
數據庫應用程序的設計應該與數據設計並行進行
在組織數據入庫的同時還要調試應用程序

2. 數據庫的試運行
（1）數據庫的試運行：應用程序調試完成，並且已有一小部分數據入庫後，就可以開始對數據庫系統進行聯合調試，也稱數據庫的試運行。
（2）主要工作：
1）功能測試
2）性能測試
（3）數據庫性能指標的測量
數據庫試運行則是要實際測量系統的各種性能指標（不僅是時間、空間指標），如果結果不符合設計目標，則需要返回物理設計階段，調整物理結構，修改參數；有時甚至需要返回邏輯設計階段，調整邏輯結構。
（4）數據的分期入庫
重新設計物理結構甚至邏輯結構，會導致數據重新入庫
由於數據入庫工作量實在太大，所以可以採用分期輸入數據的方法
（5）數據庫的轉儲和恢復
在數據庫試運行階段，系統還不穩定，硬、軟件故障隨時都可能發生，系統的操作人員對新系統還不熟悉，誤操作也不可避免，因此必須做好數據庫的轉儲和恢復工作，儘量減少對數據庫的破壞

3. 數據庫的運行和維護
在數據庫運行階段，對數據庫經常性的維護工作主要是由數據庫管理員完成的。
包括：
（1）數據庫的轉儲和恢復
（2）數據庫的安全性、完整性控制
●初始定義：數據庫管理員根據用戶的實際需要授予不同的操作權限（安全性）；根據應用環境定義不同的完整性約束條件（完整性）
●修改定義：當應用環境發生變化，對安全性的要求也會發生變化，數據庫管理員需要根據實際情況修改原有的安全性控制；由於應用環境發生變化，數據庫的完整性約束條件也會變化，也需要數據庫管理員不斷修正，以滿足用戶要求
（3）數據庫性能的監督、分析和改進
在數據庫運行過程中，數據庫管理員必須監督系統運行，對監測數據進行分析，找出改進系統性能的方法。
（4）數據庫的重組織與重構造
1）爲什麼要重組織數據庫？？？
數據庫運行一段時間後，由於記錄的不斷增、刪、改，會使數據庫的物理存儲變壞，從而降低數據庫存儲空間的利用率和數據的存取效率，使數據庫的性能下降。
2）重組織的形式？？？
全部重組織
部分重組織：只對頻繁增、刪的表進行重組織
3）重組織目標？？
提高系統性能
4）重新組織的工作？？？
①按原設計要求，重新安排存儲位置；回收垃圾；減少指針鏈
②數據庫的重組織不會改變原設計的數據邏輯結構和物理結構

5）爲什麼要進行數據庫的重構造？？？
數據庫應用環境發生變化，會導致實體及實體間的聯繫也發生相應的變化，使原有的數據庫設計不能很好地滿足新的需求
①增減新的應用或新的實體
②取消某些已有應用
③改變某些已有應用
6）數據庫衝構造的主要工作？？？
①根據新環境調整數據庫的模式和內模式
增加或刪除某些數據項
改變數據項的類型
增加或刪除某個表
改變數據庫的容量
增加或刪除某些索引
7）重構造數據庫的程度是有限的
若應用變化太大，已無法通過重構數據庫來滿足新的需求，或重構數據庫的代價太大，則表明現有數據庫應用系統的生命週期已經結束，應該重新設計新的數據庫應用系統了。

七、小結