1. 信息系統(tǒng)生命周期

信息系統(tǒng)：在組織機(jī)構(gòu)內(nèi)用于收集、管理、控制和分發(fā)信息的一種資源。
從 20 世紀(jì) 70 年代起，數(shù)據(jù)庫系統(tǒng)已經(jīng)逐漸代替了基于文件的系統(tǒng)，成為信息系統(tǒng)（Information System，IS）的基礎(chǔ)結(jié)構(gòu)。同時，人們還認(rèn)識到，和其他的資源一樣，數(shù)據(jù)也是一種重要的物質(zhì)資源，理應(yīng)受到重視。許多企業(yè)為此建立了專門的部門或職能單位——數(shù)據(jù)管理（DA）和數(shù)據(jù)庫管理（DBA）機(jī)構(gòu)，分別負(fù)責(zé)管理、控制數(shù)據(jù)和數(shù)據(jù)庫。

基于計算機(jī)的信息系統(tǒng)包括數(shù)據(jù)庫、數(shù)據(jù)庫軟件、應(yīng)用軟件、計算機(jī)硬件，還包括人的使用和開發(fā)活動。

數(shù)據(jù)庫是信息系統(tǒng)的基礎(chǔ)構(gòu)件，應(yīng)該從企業(yè)的需求這一更加廣泛的角度來考慮數(shù)據(jù)庫的開發(fā)及使用。因此，信息系統(tǒng)的生命周期同支撐它的數(shù)據(jù)庫系統(tǒng)的生命周期之間有著內(nèi)在的聯(lián)系。典型的信息系統(tǒng)的生命周期包括：規(guī)劃、需求收集與分析、系統(tǒng)設(shè)計、建立原型關(guān)系、系統(tǒng)實(shí)現(xiàn)、測試、數(shù)據(jù)轉(zhuǎn)換和運(yùn)行維護(hù)。下面將從開發(fā)數(shù)據(jù)庫系統(tǒng)的角度來討論這些階段性工作。不管怎樣，開發(fā)數(shù)據(jù)庫系統(tǒng)時應(yīng)全面考慮，將其視為開發(fā)大型信息系統(tǒng)的一個構(gòu)件，這點(diǎn)很重要。

本文使用術(shù)語 “職能部門” 和 “應(yīng)用方面” 表示企業(yè)內(nèi)部的特殊活動，比如銷售、人事和庫存管理。

2. 數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期

數(shù)據(jù)庫系統(tǒng)是信息系統(tǒng)的基礎(chǔ)構(gòu)件，因此數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期與信息系統(tǒng)生命周期之間有著內(nèi)在的聯(lián)系。數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期的各個階段如下圖所示，每個階段下面的小節(jié)編號是本章詳細(xì)描述該階段內(nèi)容的小節(jié)的編號。

數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期的各個階段

我們應(yīng)該認(rèn)識到數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期的各個階段并沒有非常嚴(yán)格的順序，而是通過 反饋環(huán)（feedback loop）在各個階段之間反復(fù)迭代。例如，在數(shù)據(jù)庫設(shè)計時遇到的問題，可能需要回退到需求收集與分析階段。幾乎在所有的階段之間都存在反饋環(huán)，上圖只是顯示了其中一些比較明顯的反饋環(huán)。

對于只有少量用戶的小型數(shù)據(jù)庫系統(tǒng)來說，生命周期的活動并不復(fù)雜。然而，對于一個需要支持成千上萬個用戶的數(shù)百種查詢和應(yīng)用的大、中型系統(tǒng)來說，系統(tǒng)的生命周期就會變得非常復(fù)雜。本文主要關(guān)注開發(fā)大、中型數(shù)據(jù)庫系統(tǒng)的相關(guān)活動。下表概述了數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期各個階段的主要活動。

3. 數(shù)據(jù)庫規(guī)劃

數(shù)據(jù)庫規(guī)劃：數(shù)據(jù)庫規(guī)劃是一種管理活動，目的是盡可能高效及有效的展開數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期的各個階段。

數(shù)據(jù)庫規(guī)劃必須與組織機(jī)構(gòu)關(guān)于信息系統(tǒng)的整體策略結(jié)合在一起。構(gòu)思信息系統(tǒng)策略時，涉及下面三個主要問題：

• 識別企業(yè)的規(guī)劃、目標(biāo)以及隨之而定的系統(tǒng)信息需求。
• 評估現(xiàn)有的信息系統(tǒng)，明確其長處與短處。
• 估量 IT 機(jī)遇可能帶來的競爭優(yōu)勢。

解決這些問題的方法學(xué)超出了本文的討論范圍，如果感興趣可以參閱文獻(xiàn) Robson（1977）和 Codle and Yeates（2007）。

數(shù)據(jù)庫規(guī)劃中重要的第一步是清晰定義項(xiàng)目的 任務(wù)描述（mission statement）。任務(wù)描述定義了數(shù)據(jù)庫系統(tǒng)的主要目標(biāo)，通常由項(xiàng)目主管或負(fù)責(zé)人撰寫。任務(wù)描述有助于清晰項(xiàng)目目標(biāo)，找到切實(shí)可行之路，從而高效及有效地實(shí)現(xiàn)數(shù)據(jù)庫系統(tǒng)的設(shè)計開發(fā)。第二步是確定 任務(wù)目標(biāo)（mission objective）。每個任務(wù)目標(biāo)都應(yīng)當(dāng)和一個數(shù)據(jù)庫系統(tǒng)必須支持的功能相對應(yīng)。我們假設(shè)如果數(shù)據(jù)庫系統(tǒng)支持所有的任務(wù)目標(biāo)，那么任務(wù)描述也就實(shí)現(xiàn)了。任務(wù)描述和任務(wù)目標(biāo)可能還包括一些額外的信息，通常包括工作量、所需資源和資金。下一篇中會以 DreamHome 數(shù)據(jù)庫系統(tǒng)為例，示范如何生成任務(wù)描述和任務(wù)目標(biāo)。

數(shù)據(jù)庫規(guī)劃階段還應(yīng)建立相關(guān)標(biāo)準(zhǔn)，明確數(shù)據(jù)應(yīng)該如何收集、確定數(shù)據(jù)的格式、需要什么樣的文檔以及如何著手進(jìn)行設(shè)計和實(shí)現(xiàn)階段的工作。標(biāo)準(zhǔn)的建立和維護(hù)是非常耗時的，因?yàn)槌跗诘慕⒑秃笃诘某掷m(xù)維護(hù)都需要大量資源。但設(shè)計良好的標(biāo)準(zhǔn)是員工培訓(xùn)和質(zhì)量控制的基礎(chǔ)，可確保所有工作都符合同一模式，與員工的技能和經(jīng)驗(yàn)無關(guān)。例如，為了消除數(shù)據(jù)冗余和數(shù)據(jù)不一致，我們可以在數(shù)據(jù)字典中定義數(shù)據(jù)項(xiàng)命名和規(guī)則。任何與數(shù)據(jù)相關(guān)的合理的或來自企業(yè)的需求都應(yīng)記錄在案，例如約束某些類型的數(shù)據(jù)應(yīng)為機(jī)密級的。

4. 系統(tǒng)定義

系統(tǒng)定義：定義數(shù)據(jù)庫應(yīng)用程序的范圍和邊界，以及主要的用戶視圖。

在設(shè)計數(shù)據(jù)庫之前，首先應(yīng)該確定系統(tǒng)的邊界，定義數(shù)據(jù)庫系統(tǒng)與信息系統(tǒng)其它構(gòu)件之間的接口。在考慮系統(tǒng)邊界時，應(yīng)囊括未來用戶的需求和應(yīng)用領(lǐng)域可能的延伸。

用戶視圖：從一個特定的角色（如經(jīng)理或主管）或者特定的企業(yè)應(yīng)用領(lǐng)域（如銷售、人事或庫存管理）的角度來定義數(shù)據(jù)庫系統(tǒng)的需求。

一個數(shù)據(jù)庫系統(tǒng)可能擁有一個或多個用戶視圖。在需求收集分析階段，用戶視圖能夠確保系統(tǒng)不會遺漏主要用戶的需求，因此確定用戶視圖是開發(fā)數(shù)據(jù)庫系統(tǒng)的重要組成部分。通過對用戶視圖的分解可以將需求分解成易于管理的部件，從而有助于復(fù)雜數(shù)據(jù)庫系統(tǒng)的開發(fā)。用戶視圖所表達(dá)的需求之間可能相互獨(dú)立，也可能相互重疊。

5. 需求收集與分析

需求收集與分析：收集、分析組織機(jī)構(gòu)內(nèi)需要數(shù)據(jù)庫系統(tǒng)支持的那部分的信息，并據(jù)此確定對新系統(tǒng)的需求。

本階段的活動主要涉及收集與分析組織機(jī)構(gòu)內(nèi)需要用到數(shù)據(jù)庫系統(tǒng)的那部分信息。我們可以操用多種技術(shù)采集信息，這些技術(shù)被稱為 實(shí)況發(fā)現(xiàn)技術(shù)（fact-finding techniques）。針對每個主要用戶視圖（指不同的工作角色或不同的企業(yè)應(yīng)用方面）應(yīng)采集的信息包括：

• 使用或產(chǎn)生的數(shù)據(jù)
• 這些數(shù)據(jù)是如何使用或產(chǎn)生的。
• 對新數(shù)據(jù)庫系統(tǒng)的其他需求。

通過對所采集信息的分析，可以確定新的數(shù)據(jù)庫系統(tǒng)的需求（或特性），從而生成新數(shù)據(jù)庫系統(tǒng)的 需求規(guī)格說明書。

需求的收集與分析是數(shù)據(jù)庫設(shè)計的基礎(chǔ)。應(yīng)收集的信息量需要根據(jù)問題本身的特性和企業(yè)的運(yùn)轉(zhuǎn)模式而定。考慮過細(xì)會陷入 分析僵局（paralysis by analysis），無法繼續(xù)開展下一步工作；而考慮過粗則可能因?yàn)獒槍﹀e誤的需求定位而給出錯誤的的解決方案，導(dǎo)致后期不必要的時間和金錢浪費(fèi)。

收集的信息可能缺乏良好的結(jié)構(gòu)和形式，因此需要將其轉(zhuǎn)換為結(jié)構(gòu)化良好的需求描述，可以采用的 需求規(guī)范化技術(shù) 包括：結(jié)構(gòu)化分析和設(shè)計（Structured Analysis and Design, SAD）；數(shù)據(jù)流圖（Data Flow Diagrams，DFD）；帶有文檔輔助說明的分層輸入處理輸出圖（Hierarchical Input Process Output，HIPO）。隨后將看到，計算機(jī)輔助軟件工程（CASE）工具能夠進(jìn)行自動化的檢測，確保需求的完整性和一致性。后續(xù)的文章中還將討論統(tǒng)一建模語言（Unified Model Language，UML）對需求分析與設(shè)計活動的支持。

確定數(shù)據(jù)庫系統(tǒng)的功能也是本階段的一項(xiàng)關(guān)鍵性活動。系統(tǒng)功能的不當(dāng)（inadequate）或不完全（incomplete）會使用戶感到使用不便，從而導(dǎo)致系統(tǒng)利用率不高，甚至被棄而不用。然而功能過于完善也會導(dǎo)致系統(tǒng)過于復(fù)雜，從而難于實(shí)現(xiàn)、維護(hù)、使用和學(xué)習(xí)。

需求收集與分析階段要解決的另外一個重要問題是如何處理多個用戶視圖。通常有三種主要的方法：

• 集中式 方法
• 視圖集成 方法
• 這兩種方法的組合

5.1 集中式方法

集中式方法：合并所有用戶視圖的需求，形成對新系統(tǒng)的一組需求。在數(shù)據(jù)庫設(shè)計階段創(chuàng)建一個表示了所有用戶需求的數(shù)據(jù)模型。

集中式（或稱 one-shot）方法將不同用戶視圖的需求匯總到一張需求表中，并為這個用戶視圖的并集命名以說明它覆蓋了所有被歸并用戶視圖的應(yīng)用方面。在數(shù)據(jù)庫設(shè)計階段建立的全局?jǐn)?shù)據(jù)模型，即表示了所有視圖。全局?jǐn)?shù)據(jù)模型由圖和形式化描述用戶需求的文檔組成。一般來說，當(dāng)各用戶視圖的需求存在明顯重疊并且數(shù)據(jù)庫系統(tǒng)不是非常復(fù)雜時，建議采用集中式方法。

集中式方法處理多個用戶視圖

5.2 視圖集成方法

視圖集成方法：每個用戶視圖的需求都獨(dú)立列出。在數(shù)據(jù)庫設(shè)計階段，首先針對每個用戶視圖的需求建立各自的數(shù)據(jù)模型，然后再加以整合。

視圖集成方法在需求收集與分析階段將各個用戶視圖的需求視為相互獨(dú)立的，并不加以整合，而在數(shù)據(jù)庫設(shè)計階段，首先為每個用戶視圖建立一個數(shù)據(jù)模型，該數(shù)據(jù)模型僅對應(yīng)于一個用戶視圖（或所有用戶視圖的一個子集），稱為 局部數(shù)據(jù)模型（local data model）。

采用視圖集成方法處理多個用戶視圖

每個局部數(shù)據(jù)模型都由圖和形式化描述需求的文檔組成，其中，需求只是數(shù)據(jù)庫中一個或多個（而不是全部）用戶視圖的。在之后的數(shù)據(jù)庫設(shè)計階段，局部數(shù)據(jù)模型被合并生成一個代表所有用戶需求的 全局?jǐn)?shù)據(jù)模型（global data model）。視圖集成方法如上圖所示。。通常，當(dāng)用戶視圖之間存在明顯區(qū)別并且數(shù)據(jù)庫局系統(tǒng)足夠復(fù)雜時，可以使用這種方法。事實(shí)證明，視圖集成方法能夠分割系統(tǒng)需求，分割之后更有利于需求的收集與分析以及后續(xù)工作的進(jìn)行。

對于一些復(fù)雜的數(shù)據(jù)庫系統(tǒng)來說，更為合適的方法也許是兩者的結(jié)合，即綜合使用集中式和視圖集成式兩種方法來處理多個用戶的視圖。例如，我們可以首先使用集中式的方法將兩個或多個用戶的視圖匯集成一個總的需求，并且將其轉(zhuǎn)化為局部邏輯數(shù)據(jù)模型，然后使用視圖集成化方法將該局部邏輯數(shù)據(jù)模型與其他的局部邏輯數(shù)據(jù)模型集成為全局邏輯數(shù)據(jù)模型。在這種情況下，每一個局部邏輯數(shù)據(jù)模型都對應(yīng)著部分用戶視圖的需求，最終生成的全局邏輯數(shù)據(jù)模型表達(dá)了數(shù)據(jù)庫系統(tǒng)所有用戶視圖的需求。

下一篇文章將會詳細(xì)討論如何處理多個用戶的視圖，并將采用本書描述的方法學(xué)，說明如何綜合使用集中式和視圖集成方法，實(shí)現(xiàn) DreamHome 房屋租賃數(shù)據(jù)庫系統(tǒng)。

6. 數(shù)據(jù)庫設(shè)計

數(shù)據(jù)庫設(shè)計：為企業(yè)或單位所需數(shù)據(jù)庫系統(tǒng)生成設(shè)計方案的過程，該設(shè)計方案應(yīng)能支持該數(shù)據(jù)庫的任務(wù)描述和任務(wù)目標(biāo)。

本節(jié)將概述數(shù)據(jù)庫設(shè)計的主要方法，數(shù)據(jù)建模在數(shù)據(jù)庫設(shè)計中的目的和用法，以及數(shù)據(jù)庫設(shè)計的三個階段——概念數(shù)據(jù)庫設(shè)計、邏輯數(shù)據(jù)庫設(shè)計和物理數(shù)據(jù)庫設(shè)計。

6.1 數(shù)據(jù)庫設(shè)計方法

數(shù)據(jù)庫設(shè)計可以采用的方法主要有兩種：“自下而上（bottom-up）” 和 “自上而下（top-down）”。自下而上方法從底層的屬性（指實(shí)體和聯(lián)系的屬性）入手，通過分析屬性之間的關(guān)聯(lián)，將它們分別組合成代表實(shí)體類型和實(shí)體類型之間聯(lián)系的關(guān)系。在專題的第四部分還將討論規(guī)范化過程，該過程代表了一種數(shù)據(jù)庫設(shè)計中的自下而上的方法。規(guī)范化時，首先確定所需屬性，然后基于屬性之間的函數(shù)依賴將屬性聚集成規(guī)范化的關(guān)系。

自下而上的方法適用于涉及屬性相對較少的簡單數(shù)據(jù)庫的設(shè)計。對于包含了大量屬性的復(fù)雜數(shù)據(jù)庫來說，由于很難完全建立起所有屬性之間的函數(shù)依賴，也就很難根據(jù)屬性生成規(guī)范化的關(guān)系，因此自下而上的方法不再適用。復(fù)雜數(shù)據(jù)庫的概念數(shù)據(jù)模型和邏輯數(shù)據(jù)模型可能包含成百上千個屬性，因此需要一種能夠簡化設(shè)計過程的方法。而且，對于復(fù)雜數(shù)據(jù)庫來說，在定義數(shù)據(jù)需求的初始階段，很難馬上確定所有的屬性。

對于復(fù)雜數(shù)據(jù)庫，一種更好的策略是采用 自上而下 的方法：建模初始，數(shù)據(jù)模型僅包含少量的高層實(shí)體以及實(shí)體之間的聯(lián)系，然后連續(xù)使用自上而下的方法細(xì)化模型，進(jìn)一步確定底層的實(shí)體、實(shí)體之間的聯(lián)系以及相關(guān)屬性。我們可以使用實(shí)體 - 聯(lián)系（Entity-Relation，ER）模型的概念來說明自上而下的方法。實(shí)體聯(lián)系模型首先確定數(shù)據(jù)庫系統(tǒng)所包含的實(shí)體和實(shí)體之間的聯(lián)系。例如，在 DreanHome 的示例中，我們可以首先建立實(shí)體 PrivateOwner 和 PropertyForRent，然后確定這兩個實(shí)體之間的聯(lián)系 PrivateOwner Owns PropertyForRent，最后提取這兩個實(shí)體所包括的屬性（這里僅列出部分屬性）—— PrivateOwner 包含了 ownerNo、name 和 address 三個屬性，PropertyuForRent 則擁有 propertyNo 和 address 兩個屬性。后面將會詳細(xì)討論如何使用 ER 模型建立高層數(shù)據(jù)模型。

除此之外，數(shù)據(jù)庫設(shè)計方法還包括 由內(nèi)而外（inside-out） 以及多種方法相結(jié)合的混合策略。由內(nèi)而外的設(shè)計方法與自下而上方法類似，區(qū)別在于：由內(nèi)而外首先建立主要實(shí)體的集合，然后向外擴(kuò)展，確定與已建立實(shí)體相關(guān)的其他實(shí)體、聯(lián)系和屬性。混合策略 則將數(shù)據(jù)模型分割=為可組裝的構(gòu)件，對不同的構(gòu)件即可以使用自下而上的方法也可以選擇自上而下的方法。

6.2 數(shù)據(jù)建模

數(shù)據(jù)建模的目的主要有兩個，一個是有助于設(shè)計人員對數(shù)據(jù)含義（語義）的理解，而是有助于設(shè)計人員與用戶之間的交流。數(shù)據(jù)建模要求回答關(guān)于實(shí)體、聯(lián)系、屬性的問題。為此，設(shè)計人員需要找出企業(yè)數(shù)據(jù)的原本的語義，無論他們是否出現(xiàn)在形式化的數(shù)據(jù)模型中。實(shí)體、聯(lián)系和屬性是描述企業(yè)信息的基石，但是對設(shè)計人員來說可能一直很難理解它們的含義，直到他們被正確的記錄在文檔中。數(shù)據(jù)模型有助于我們對數(shù)據(jù)含義的理解，因此通過數(shù)據(jù)建模可以確保我們能夠正確理解：

• 每個用戶對數(shù)據(jù)的觀點(diǎn)
• 與其物理表現(xiàn)形式無關(guān)的數(shù)據(jù)本身的性質(zhì)
• 各用戶視圖中數(shù)據(jù)的使用

數(shù)據(jù)模型可以用來表達(dá)設(shè)計人員對企業(yè)信息需求的理解，如果雙方都熟悉模型中使用的符號，數(shù)據(jù)模型就可以幫助用戶的設(shè)計人員進(jìn)行交流。企業(yè)也在逐步規(guī)范著建模數(shù)據(jù)的方式：選擇一種特定的數(shù)據(jù)建模方法并且貫穿整個數(shù)據(jù)庫項(xiàng)目的開發(fā)過程。數(shù)據(jù)庫設(shè)計中最常用的，即本書采用的高層數(shù)據(jù)模型是 ER 模型。

數(shù)據(jù)模型的標(biāo)準(zhǔn)

一個理想的數(shù)據(jù)模型應(yīng)符合下表所列的標(biāo)準(zhǔn)（Fleming and Von Halle，1989）。但是，有時這些標(biāo)準(zhǔn)相互矛盾，需要進(jìn)行折中。例如，在試圖追求更好的表現(xiàn)力時，數(shù)據(jù)模型就會失去簡潔性。

6.3 數(shù)據(jù)庫設(shè)計的階段劃分

數(shù)據(jù)庫設(shè)計分為 概念設(shè)計、邏輯設(shè)計 和 物理設(shè)計 三個階段。

概念數(shù)據(jù)庫設(shè)計：建立概念數(shù)據(jù)模型的過程，該模型與所有物理因素?zé)o關(guān)。

數(shù)據(jù)庫設(shè)計的第一階段稱為 概念數(shù)據(jù)庫設(shè)計。在這一階段，將根據(jù)用戶需求規(guī)格說明書建立概念數(shù)據(jù)模型。在概念數(shù)據(jù)庫設(shè)計階段，無需考慮實(shí)現(xiàn)細(xì)節(jié)，即概念模型不涉及類似目標(biāo) DBMS 軟件的選擇、應(yīng)用程序的編制、編程語言的選擇、硬件平臺的選擇或其他任何物理實(shí)現(xiàn)上的細(xì)節(jié)問題。

在建立概念數(shù)據(jù)模型的整個過程中，模型被不斷測試、修改直至滿足用戶的需求。概念數(shù)據(jù)模型是基礎(chǔ)，是下一階段——邏輯數(shù)據(jù)庫設(shè)計的信息來源

邏輯數(shù)據(jù)庫設(shè)計：根據(jù)已有的概念數(shù)據(jù)模型，建立邏輯數(shù)據(jù)模型，該模型與具體的 DBMS 以及其他物理因素?zé)o關(guān)。

數(shù)據(jù)庫設(shè)計的第二階段稱為 邏輯數(shù)據(jù)庫設(shè)計，在這一階段，針對建模時關(guān)注的企事業(yè)部分構(gòu)建邏輯數(shù)據(jù)模型。即將前一階段創(chuàng)建的概念數(shù)據(jù)模型進(jìn)行細(xì)化，然后映射為邏輯數(shù)據(jù)模型。邏輯數(shù)據(jù)模型是建立在目標(biāo)數(shù)據(jù)庫所支持的數(shù)據(jù)模型（例如，關(guān)系數(shù)據(jù)模型）基礎(chǔ)之上的。

盡管概念數(shù)據(jù)模型獨(dú)立與物理實(shí)現(xiàn)，但是邏輯數(shù)據(jù)模型卻是在已知目標(biāo) DBMS 的基本數(shù)據(jù)模型的條件下推導(dǎo)出來的。也就是說，進(jìn)行邏輯數(shù)據(jù)庫設(shè)計時，我們需要知道目標(biāo) DBMS 是關(guān)系的、網(wǎng)狀的、層次的還是面向?qū)ο蟮摹３酥猓瑢⒑雎运x DBMS 的其他特征，尤其是物理細(xì)節(jié)，如目標(biāo) DBMS 支持的存儲結(jié)構(gòu)或者索引，等等。

在建立邏輯數(shù)據(jù)模型的整個過程中，也將不斷的對模型進(jìn)行測試、修改直至滿足用戶的需求。這一階段，我們引入 規(guī)范化 技術(shù)來驗(yàn)證邏輯數(shù)據(jù)模型的正確性。規(guī)范化可以保證由數(shù)據(jù)模型導(dǎo)出的關(guān)系沒有數(shù)據(jù)冗余，而數(shù)據(jù)冗余則可能會引起更新異常。在規(guī)范化部分將會指出數(shù)據(jù)冗余帶來的問題，并詳述規(guī)范化過程。另外，邏輯數(shù)據(jù)模型還應(yīng)完全支持由用戶說明的事務(wù)。

邏輯數(shù)據(jù)模型又是下一階段的信息來源，為物理數(shù)據(jù)庫設(shè)計人員進(jìn)行權(quán)衡考慮提供了便利，權(quán)衡考慮對有效的數(shù)據(jù)庫設(shè)計是十分重要的。邏輯數(shù)據(jù)模型在數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期的運(yùn)行維護(hù)階段也擔(dān)當(dāng)著重要的角色。對數(shù)據(jù)模型的正確維護(hù)和及時更新能夠使數(shù)據(jù)庫很好的適應(yīng)未來的變化，使得以后對應(yīng)用程序和數(shù)據(jù)的修改都能夠在數(shù)據(jù)庫中得到正確而有效地體現(xiàn)。

物理數(shù)據(jù)庫設(shè)計：產(chǎn)生數(shù)據(jù)庫在輔存上的實(shí)現(xiàn)描述的過程。物理數(shù)據(jù)庫設(shè)計定義了基礎(chǔ)關(guān)系、文件組織方式和能夠提高數(shù)據(jù)訪問效率的索引，以及所有的完整性約束和安全措施。

物理數(shù)據(jù)庫設(shè)計是數(shù)據(jù)庫設(shè)計的最后一個階段。在這一階段，設(shè)計人員將確定數(shù)據(jù)庫的物理實(shí)現(xiàn)細(xì)節(jié)。在邏輯數(shù)據(jù)庫設(shè)計階段已經(jīng)建立了數(shù)據(jù)庫的邏輯結(jié)構(gòu)，實(shí)現(xiàn)了關(guān)系和業(yè)務(wù)約束的定義。盡管邏輯結(jié)構(gòu)的設(shè)計與 DBMS 的選擇無關(guān)，但邏輯數(shù)據(jù)模型的選擇需要與目標(biāo) DBMS 支持的數(shù)據(jù)模型一致，如關(guān)系模型、網(wǎng)狀模型或者層次模型。在物理數(shù)據(jù)庫設(shè)計階段，必須首先明確目標(biāo) DBMS，因此物理數(shù)據(jù)庫設(shè)計是面向特定的 DBMS 系統(tǒng)的。在這一階段，為了提高性能而做出的一些決策可能會影響邏輯數(shù)據(jù)庫模型的數(shù)據(jù)結(jié)構(gòu)的設(shè)計，因此在物理數(shù)據(jù)庫設(shè)計和邏輯數(shù)據(jù)庫設(shè)計之間存在迭代。

通常，物理數(shù)據(jù)庫設(shè)計的主要目標(biāo)就是描述如何物理的實(shí)現(xiàn)邏輯數(shù)據(jù)庫的設(shè)計。對于關(guān)系模型，物理數(shù)據(jù)庫設(shè)計活動包括：

• 根據(jù)邏輯數(shù)據(jù)模型，物理的創(chuàng)建關(guān)系表和完整性約束。
• 確定數(shù)據(jù)的存儲結(jié)構(gòu)和訪問方式，確保數(shù)據(jù)庫系統(tǒng)的性能最優(yōu)。
• 設(shè)計安全保護(hù)機(jī)制。

對于大型系統(tǒng)，理想情況是將概念和邏輯數(shù)據(jù)庫設(shè)計同物理數(shù)據(jù)庫設(shè)計分離開來，主要有三個原因：

• 設(shè)計的內(nèi)容不同：前者僅涉及做什么，與怎么做無關(guān)。
• 執(zhí)行的時機(jī)不同：在決定怎么做之前必須先明確做什么。
• 需要的技術(shù)不同：不同階段的建模技術(shù)經(jīng)常為不同的人所擁有。

數(shù)據(jù)庫設(shè)計是一個反復(fù)迭代的過程，雖然有一個起點(diǎn)，但細(xì)化的過程卻幾乎沒有終點(diǎn)。細(xì)化應(yīng)當(dāng)被看作學(xué)習(xí)過程。隨著設(shè)計人員對企業(yè)運(yùn)作和數(shù)據(jù)含義的進(jìn)一步理解，新的信息將被反映在數(shù)據(jù)模型中，這種改變也會引起對模型其他部分的修改。特別是，概念數(shù)據(jù)庫設(shè)計和邏輯數(shù)據(jù)庫設(shè)計是一個系統(tǒng)能否成功的決定性因素，如果設(shè)計不是企業(yè)的真實(shí)表示，那么將很難定義出所有要求的用戶視圖，也很難維護(hù)數(shù)據(jù)庫的完整性。同樣可以證明，定義數(shù)據(jù)庫的物理實(shí)現(xiàn)和維持可接受的系統(tǒng)性能也會很困難。另一方面，好的數(shù)據(jù)庫設(shè)計應(yīng)該能夠根據(jù)需求變化作出相應(yīng)的調(diào)整，這也是好的數(shù)據(jù)庫設(shè)計的一個標(biāo)志。因此，為了得到一個盡可能好的數(shù)據(jù)庫設(shè)計方案，花費(fèi)必要的時間和精力是值得的。

前面我們提到過數(shù)據(jù)庫系統(tǒng)的三層 ANSI-SPARC 體系結(jié)構(gòu)：外模式、概念模式和內(nèi)模式。下圖給出了三級模式與概念、邏輯和物理數(shù)據(jù)庫設(shè)計階段的對應(yīng)關(guān)系。在第四部分將逐步詳細(xì)描述物理數(shù)據(jù)庫設(shè)計階段所涉及的方法學(xué)。

數(shù)據(jù)建模與 ANSI-SPARC 體系結(jié)構(gòu)

7. DBMS 選型

DBMS 選型：選擇適合的 DBMS 以支持相應(yīng)的數(shù)據(jù)庫系統(tǒng)。

如果系統(tǒng)開發(fā)支出并未指定 DBMS，那么 DBMS 選型比較適宜的時機(jī)是在概念數(shù)據(jù)庫設(shè)計之后，且在邏輯數(shù)據(jù)庫設(shè)計之前。然而，如果已經(jīng)收集到足夠多的與系統(tǒng)需求相關(guān)的信息，如系統(tǒng)性能、數(shù)據(jù)庫的易重組性、安全性和完整性約束等需求，那么 DBMS 選型可以在邏輯數(shù)據(jù)庫設(shè)計之前的任何時間進(jìn)行。

盡管我們可能不會頻繁的進(jìn)行 DBMS 的選型，但是當(dāng)企業(yè)的需求擴(kuò)展或者需要重建現(xiàn)有系統(tǒng)時，將有必要再次對 DBMS 產(chǎn)品進(jìn)行評估，所選 DBMS 既要能滿足企業(yè)眼下所需也要兼顧未來需求的擴(kuò)展，選型時要在各種成本之間做出權(quán)衡，這些成本包括：購買 DBMS 產(chǎn)品的費(fèi)用、相關(guān)軟硬件的開銷、系統(tǒng)重建相關(guān)的費(fèi)用以及員工培訓(xùn)的開銷。

選型時，我們可以簡單地將 DBMS 的特性與系統(tǒng)需求加以比較， 選型過程應(yīng)確保計劃周密，并且所選 DBMS 要能真正讓企業(yè)受益。在下一節(jié)中將描述一種選擇 “最適宜” DBMS 的典型方法。下面列出了 DBMS 選型的主要步驟：

• 確定研究考慮的方面
• 列出兩到三個候選 DBMS 產(chǎn)品
• 評估這些候選產(chǎn)品
• 給出建議選型產(chǎn)品的報告

確定 DBMS 選型時研究考慮的方面

列出 DBMS 選型時研究考慮的方面看，包括說明調(diào)研的目標(biāo)、范圍和需要完成的任務(wù)。該文檔還可以包括評估 DBMS 產(chǎn)品時所需的選型準(zhǔn)則（基于用戶需求規(guī)格說明書）、初步生成的選型列表、所有必要的約束條件和選型進(jìn)度表，等等。

列出兩到三個候選 DBMS 產(chǎn)品

那些被認(rèn)為是成事 “關(guān)鍵” 的準(zhǔn)則可用于篩選出 DBMS 候選產(chǎn)品列表，以供后期評估使用。例如，是否考慮某一 DBMS 依賴于系統(tǒng)開發(fā)預(yù)算、開發(fā)商的技術(shù)支持的程度、與其他軟件的兼容性、有無特殊的硬件支撐環(huán)境要求，等等。另外，通過接觸該產(chǎn)品已有的用戶，還可以收集到額外的有用信息：供應(yīng)商實(shí)際的技術(shù)支持能力，該產(chǎn)品如何支持特殊的應(yīng)用，是否在某些硬件平臺上運(yùn)行會比在其他平臺上運(yùn)行產(chǎn)生更多的問題。還可以參考基準(zhǔn)測試（benchmark）結(jié)果對 DBMS 產(chǎn)品進(jìn)行性能比較。經(jīng)過對 DBMS 產(chǎn)品的功能和特性的初步調(diào)研后，可以確定兩到三個候選 DBMS。

萬維網(wǎng)（World Wide Web）是一個非常好的信息資源，可以利用萬維網(wǎng)甄選潛在的候選 DBMS。例如，DBMS 雜志的網(wǎng)站（www.intelligententerprise.com）提供了一個關(guān)于 DBMS 產(chǎn)品的總和索引。產(chǎn)品供應(yīng)商的網(wǎng)站也會提供關(guān)于 DBMS 產(chǎn)品有用的信息。

評估候選 DBMS 產(chǎn)品

評估 DBMS 產(chǎn)品的指標(biāo)很多。出于不同評估目的考慮，可以將多個性能參數(shù)成組評估（例如，對數(shù)據(jù)定義指標(biāo)組綜合評估），或者單獨(dú)考察（例如，金對數(shù)據(jù)定義指標(biāo)組中的有效數(shù)據(jù)類型特性進(jìn)行評估）。下表將評估 DBMS 產(chǎn)品的指標(biāo)分為以下幾組：數(shù)據(jù)定義、物理定義、可訪問性、事務(wù)處理、實(shí)用工具、應(yīng)用開發(fā)和其他。

如果對這些指標(biāo)只是簡單地用好或是不好來進(jìn)行評價，那么很難在 DBMS 產(chǎn)品之間進(jìn)行比較。一個更加實(shí)用的方法是：根據(jù)這些指標(biāo)或指標(biāo)組在系統(tǒng)中的重要性，將其賦予不同的權(quán)重，用最后得到的綜合權(quán)值來比較。表 10-5 顯示了如何使用這種方法對某 DBMS 產(chǎn)品的物理定義指標(biāo)進(jìn)行分析。首先評估每個指標(biāo)的等級值，用一個不超過 10 的數(shù)表示，每個指標(biāo)在組內(nèi)都有一個用小于 1 的數(shù)值表示的權(quán)重，表示相對于同組其他指標(biāo)的重要性。計算該指標(biāo)的最后得分需要將其等級與權(quán)重相乘。例如，下表中，“易重組性” 的等級 4，權(quán)重為 0.25，評估得分是 1.0。在表中，該指標(biāo)權(quán)重最高，說明在此次評估中它是最重要的因素。“易重組性” 的權(quán)重是 “數(shù)據(jù)壓縮” 的 5 倍，“數(shù)據(jù)壓縮” 的權(quán)重最低，僅為 0.05.而 “內(nèi)存需求” 和 “存儲需求” 的權(quán)重都是 0.00，說明在評估中根本不考慮這些指標(biāo)對系統(tǒng)的影響。

將各指標(biāo)評估后的得分加在一起，就得到該組的得分。而該組又有一個權(quán)重，用來表示在此次評估中該組相對于其他指標(biāo)組的重要性。例如，在上表中，物理定義組的總分是 5.75，而 5.75 的權(quán)重為 0.25。

最后，將所有評估指標(biāo)組，加權(quán)后的得分加在一起就得到了某 DBMS 產(chǎn)品的得分。將不同 DBMS 的最后評估得分進(jìn)行比較，分?jǐn)?shù)最高的產(chǎn)品就是最佳選擇。

除此之外，我們還可以采用由 DBMS 廠商演示其產(chǎn)品或者對該產(chǎn)品進(jìn)行內(nèi)部（in-house）測試的方法來進(jìn)行評估。采用內(nèi)部評測時，需要為候選 DBMS 搭建測試平臺。測試每個候選產(chǎn)品滿足用戶提出的數(shù)據(jù)庫系統(tǒng)需求的程度。在 www.tpc.org 上可以找到由事務(wù)處理委員會（Transaction Processing Council）公布的基準(zhǔn)測試報告。

給出建議選型 DBMS 的報告
數(shù)據(jù)庫選型的最后一步是記錄下整個選型過程，并提供一份最后結(jié)果的說明和建議選擇的 DBMS 產(chǎn)品。

8. 應(yīng)用程序設(shè)計

應(yīng)用程序設(shè)計：完成用戶界面和使用、處理數(shù)據(jù)庫的應(yīng)用程序的總體設(shè)計。

在數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期示意圖中，可以看到數(shù)據(jù)庫設(shè)計和應(yīng)用程序設(shè)計是并行進(jìn)行的。大多數(shù)情況下，不可能在數(shù)據(jù)庫設(shè)計實(shí)現(xiàn)之前就完成應(yīng)用程序設(shè)計。另一方面，數(shù)據(jù)庫是應(yīng)用程序設(shè)計的支撐，因此，應(yīng)用程序設(shè)計和數(shù)據(jù)庫設(shè)計之間必然存在信息交流。

我們必須確保用戶需求規(guī)格說明書中提到的所有功能都要在數(shù)據(jù)庫系統(tǒng)的應(yīng)用程序設(shè)計中體現(xiàn)出來，這將涉及到訪問數(shù)據(jù)庫的應(yīng)用程序的設(shè)計和數(shù)據(jù)庫事務(wù)的設(shè)計（即數(shù)據(jù)庫訪問方式）。除了設(shè)計如何實(shí)現(xiàn)需求的功能外，還應(yīng)為數(shù)據(jù)庫系統(tǒng)設(shè)計一個合適的用戶界面。用戶界面應(yīng)該以用戶友好的方式提供信息。用戶界面設(shè)計的重要性常常被忽略，或者直到設(shè)計階段的后期才著手考慮。然而，我們應(yīng)該認(rèn)識到界面可能是系統(tǒng)最重要的組件之一。如果界面容易學(xué)習(xí)、易于使用、簡單明了、容錯性強(qiáng)，則用戶就能更好的利用系統(tǒng)提供的信息。相反，如果界面完全不具備上述特點(diǎn)，則毫無疑問，用戶在使用該系統(tǒng)時一定會遇到麻煩。

下面介紹應(yīng)用程序設(shè)計兩個方面：事務(wù)設(shè)計和用戶界面設(shè)計。

8.1 事務(wù)設(shè)計

在討論事務(wù)設(shè)計前我們先描述一下事務(wù)的含義。
事務(wù)：由單個用戶或應(yīng)用程序執(zhí)行的訪問或修改數(shù)據(jù)庫的一個或一組動作。

事務(wù)是 “現(xiàn)實(shí)世界” 中事件的表示，例如，登記待出租的房屋、增加一名新員工、注冊一名新客戶或出租一處房屋。運(yùn)用事務(wù)能夠確保數(shù)據(jù)庫中的數(shù)據(jù)同現(xiàn)實(shí)世界的情況保持一致，并能夠提供用戶所需的信息。

一個事務(wù)可能由幾個操作組成，如資金轉(zhuǎn)賬就是由幾個操作組成的。然而，從用戶的角度來看，這些操作不過是完成了一個任務(wù)。從 DBMS 的角度看，事務(wù)是將數(shù)據(jù)庫從一個一致狀態(tài)轉(zhuǎn)換到另一個一致狀態(tài)。DBMS 應(yīng)保證數(shù)據(jù)庫的一致性，即使出現(xiàn)故障也應(yīng)如此。DBMS 還應(yīng)保證一旦某個事物完成，事務(wù)的操作結(jié)果將永久的保存在數(shù)據(jù)庫中，不會丟失或回退（執(zhí)行另一事務(wù)來替換第一個事務(wù)操作的效果）。如果由于某種原因事務(wù)不能完成，DBMS 要保證能夠回退該事務(wù)所作的任何操作，消除其對數(shù)據(jù)庫的影響。在銀行交易中，如果資金已從貸方賬戶貸出，但在尚未劃入借方賬戶前這個事務(wù)失敗了，那么 DBMS 將撤銷這次交易。如果將貸方貸出與借方借入操作定義為兩個單獨(dú)的事務(wù)，那么一旦貸方事務(wù)完成，則不允許撤銷該變更（即使此時并未執(zhí)行另一事務(wù)借入貸出的金額）。

事務(wù)設(shè)計的目的是把數(shù)據(jù)庫所需事務(wù)的高層特性確定下來并形成文檔。這些特性包括：

• 事務(wù)用到的數(shù)據(jù)
• 事務(wù)的功能特性
• 事務(wù)的輸出
• 對于用戶的重要性
• 預(yù)期的使用率

事務(wù)設(shè)計應(yīng)該在應(yīng)用程序設(shè)計階段的前期進(jìn)行，以確保數(shù)據(jù)庫能夠支持所有系統(tǒng)涉及的事務(wù)處理。事務(wù)主要分為以下三類：檢索型事務(wù)、更新型事務(wù)和混合型事務(wù)。

• 檢索型事務(wù)：檢索型事務(wù)主要用于數(shù)據(jù)檢索，并將這些數(shù)據(jù)顯示在屏幕上或生成報表。例如，查詢并顯示某一指定編號的的房屋的詳細(xì)信息。
• 更新型事務(wù)：更新型事務(wù)用于實(shí)現(xiàn)記錄的插入、刪除或修改。例如，在數(shù)據(jù)庫中插入某一新的房屋的信息。
• 混合型事務(wù)：該類型事務(wù)的操作包括了數(shù)據(jù)的檢索和更新。例如，查詢并顯示某已制定編號的房屋的詳細(xì)信息并更新其月租金。

8.2 用戶界面設(shè)計指南

在顯示表單或報表之前，首先要對其外觀和布局進(jìn)行設(shè)計。下面列出了在設(shè)計表單和報表時應(yīng)遵循的一些原則（Shneiderman，1992）。

• 使用有意義的標(biāo)題
  標(biāo)題傳達(dá)的信息應(yīng)該清楚、明確，與表單 / 報表所要描述的問題一致。

• 操作指令易于理解
  應(yīng)盡量使用用戶熟悉的術(shù)語向用戶傳達(dá)操作指令。之靈信息應(yīng)該簡短，當(dāng)需要進(jìn)一步提示時，應(yīng)提供幫助窗口。操作指令應(yīng)使用標(biāo)準(zhǔn)格式且文風(fēng)一致。

• 字段按邏輯分組和排序
  表單 / 報表中相關(guān)的字段應(yīng)該集中于同一區(qū)域，字段的排列順序應(yīng)符合邏輯并風(fēng)格一致。

• 表單 / 報表的布局視覺性強(qiáng)
  表單 / 報表應(yīng)該呈現(xiàn)給用戶一個視覺吸引力強(qiáng)的界面。字段或字段組之間應(yīng)布局均衡，不應(yīng)存在字段過于密集或過于分散的區(qū)域。字段或字段組之間應(yīng)該間隔均勻。合適的話，字段之間應(yīng)該垂直對齊或水平對齊。若物理（紙質(zhì)）表單 / 報表已經(jīng)存在，則兩者布局應(yīng)一致。

• 用熟悉的字段標(biāo)簽
  字段標(biāo)簽應(yīng)該是用戶所熟悉的。比如，若用 “Gender” 代替字段 “Sex”，則可能有些用戶會感到有點(diǎn)糊涂。

• 術(shù)語和縮寫應(yīng)保持一致
  使用用戶熟悉的術(shù)語和縮寫，且前后一致。

• 配色統(tǒng)一
  色彩的使用可以增強(qiáng)表單 / 報表的視覺效果，突出顯示重要的字段或信息。為了達(dá)到這個目的，配色必須風(fēng)格統(tǒng)一并且意義明確。例如，在某一表單上，背景色為白色的字段表示該字段為數(shù)據(jù)錄入字段，而具有藍(lán)色背景的字段僅為數(shù)據(jù)輸出字段。

• 數(shù)據(jù)錄入字段應(yīng)具有明顯的邊界并預(yù)留足夠的空間
  用戶會留意到每個錄入字段的可用空間，這樣用戶就會在輸入數(shù)值之前考慮合適的數(shù)據(jù)錄入格式。

• 光標(biāo)能夠控制自如
  用戶應(yīng)該能夠自如的在表單 / 報表中移動光標(biāo)以選擇其操作。光標(biāo)的控制可以通過控制 Tab 鍵、鍵盤方向鍵以及鼠標(biāo)實(shí)現(xiàn)。

• 易于糾正錄入錯誤（包括單個字符和整個字段的錄入錯誤）
  用戶應(yīng)該能夠容易地改變字段已錄入的數(shù)值。可以簡單的使用 Backspace 鍵修改或者重新輸入。

• 對不可接受的值給出錯誤信息
  當(dāng)用戶試圖向字段中輸入不正確的數(shù)據(jù)時，應(yīng)該能顯示錯誤的信息，以提示用戶錯誤的類型和允許錄入的數(shù)值。

• 清楚地標(biāo)記出可選字段
  可選字段應(yīng)該清楚的標(biāo)示給用戶。可以為該字段選擇一個恰當(dāng)?shù)拿Q，或者用某種特定的顏色來顯示這個字段以表明該字段的類型。可選字段應(yīng)位于必選字段之后。

• 為字段提供說明性信息
  當(dāng)用戶將光標(biāo)停留在某個字段上時，應(yīng)該在屏幕上的特定區(qū)域（如狀態(tài)欄上）顯示關(guān)于該字段的信息。

• 錄入完畢應(yīng)該出完成信號
  應(yīng)該讓用戶清楚何時已經(jīng)完成了表單上所有字段的填寫。但不應(yīng)自動選擇表單填寫結(jié)束，因?yàn)橛脩艨赡芟Ｍ麢z查一下錄入的數(shù)據(jù)。

9. 建立原型系統(tǒng)

在設(shè)計過程中，關(guān)于系統(tǒng)的初步實(shí)現(xiàn)，我們可以選擇完全實(shí)現(xiàn)該數(shù)據(jù)庫系統(tǒng)或者僅僅建立一個原型系統(tǒng)。

建立原型系統(tǒng)：建立數(shù)據(jù)庫系統(tǒng)的一個工作模型。

原型只是一個工作模型，通常并未實(shí)現(xiàn)最終系統(tǒng)所需要具備的所有特性和功能。建立數(shù)據(jù)庫原型系統(tǒng)的主要目的是，通過分析用戶對原型系統(tǒng)的使用情況來確定系統(tǒng)所提供的功能是否完備，甚至有可能的話，用戶在使用原型系統(tǒng)的過程中，還可以提出改進(jìn)建議甚至新的功能需求。通過開發(fā)原型系統(tǒng)，可以在很大程度上幫助用戶和系統(tǒng)開發(fā)人員進(jìn)行溝通，明確用戶需求，還能夠評價系統(tǒng)設(shè)計的可行性。建立原型系統(tǒng)應(yīng)該具備的特點(diǎn)是：相對整個系統(tǒng)開發(fā)來說費(fèi)用不高并且所需時間較短。

建立原型系統(tǒng)的策略一般有兩種：需求原型和進(jìn)化原型。需求原型 利用原型確定數(shù)據(jù)庫系統(tǒng)的需求，一旦需求明確，該原型系統(tǒng)也就無用了。進(jìn)化原型 和需求原型目的相同，但最重要的區(qū)別在于它并未被拋棄，而是經(jīng)過進(jìn)一步開發(fā)之后演變?yōu)樽罱K的數(shù)據(jù)庫系統(tǒng)。

10. 實(shí)現(xiàn)

實(shí)現(xiàn)：數(shù)據(jù)庫和應(yīng)用程序設(shè)計的物理實(shí)現(xiàn)。

在設(shè)計階段的工作完成后（可能涉及原型系統(tǒng)的建立），我們面臨的是數(shù)據(jù)庫設(shè)計和應(yīng)用程序設(shè)計的物理實(shí)現(xiàn)。建立物理的數(shù)據(jù)庫可以利用所選 DBMS 的數(shù)據(jù)定義語言（DDL）來實(shí)現(xiàn)，也可以利用圖形用戶接口實(shí)現(xiàn)，圖形用戶接口提供了相同的功能卻隱藏了底層的 DDL 語句。DDL 語句用于創(chuàng)建數(shù)據(jù)庫的結(jié)構(gòu)并生成一些空的數(shù)據(jù)庫文件。已經(jīng)確定的用戶視圖也要在這一階段定義。

應(yīng)用程序的開發(fā)可以采用第三代語言（3GL）或第四代語言（4GL）。應(yīng)用程序中關(guān)于數(shù)據(jù)庫事務(wù)處理的部分，則由目標(biāo) DBMS 的數(shù)據(jù)操作語言（DML）實(shí)現(xiàn)，DML 語言將被嵌入某一宿主語言，如 Visual Basic（VB）、VB.net、Python、Delphi、C、C++、C#、Java、COBOL、FORTRAN、Ada 或者 Pascal。此外，還要實(shí)現(xiàn)應(yīng)用程序設(shè)計中出現(xiàn)的其他組件，如菜單、數(shù)據(jù)錄入表單和報表等。目標(biāo) DBMS 可能還擁有可用于應(yīng)用程序快速開發(fā)的第四代工具，這些工具包括非過程化的查詢語言、報表生成器、表單生成器和應(yīng)用程序生成器。

系統(tǒng)的安全性和完整性控制也要在這一階段實(shí)現(xiàn)。某些控制可使用 DDL 來實(shí)現(xiàn)，而其他的則可能需要利用 DBMS 提供的實(shí)用工具或操作系統(tǒng)來實(shí)現(xiàn)。注意，正如前面說的那樣 SQL 既是 DDL 也是 DML。

11. 數(shù)據(jù)轉(zhuǎn)換與加載

數(shù)據(jù)轉(zhuǎn)換與加載：將已有的數(shù)據(jù)轉(zhuǎn)移到新數(shù)據(jù)庫中，將原有的應(yīng)用移植到新數(shù)據(jù)庫上運(yùn)行。

只有當(dāng)舊的數(shù)據(jù)庫系統(tǒng)被新的系統(tǒng)替換時，才需要進(jìn)行數(shù)據(jù)轉(zhuǎn)換與加載。目前，大多 DBMS 都具有在新的數(shù)據(jù)庫中加載原有數(shù)據(jù)庫文件的實(shí)用工具。完成這一操作時需要明確要加載的原文件以及目標(biāo)數(shù)據(jù)庫，并且 DBMS 能夠自動的轉(zhuǎn)換源文件的數(shù)據(jù)格式以滿足新數(shù)據(jù)庫文件格式的要求。數(shù)據(jù)移植就緒以后，開發(fā)人員就有可能將原有系統(tǒng)中的應(yīng)用程序移植到新的系統(tǒng)中。當(dāng)需要進(jìn)行數(shù)據(jù)轉(zhuǎn)換與加載時，我們應(yīng)當(dāng)周密計劃，以確保系統(tǒng)全部功能的平滑移植。

12. 測試

測試：運(yùn)行數(shù)據(jù)庫系統(tǒng)，試圖找出錯誤。

在實(shí)際使用前，數(shù)據(jù)庫系統(tǒng)應(yīng)該經(jīng)過完全測試。測試過程需要有嚴(yán)密的測試策略和真是的測試數(shù)據(jù)保證，這樣整個測試過程才能既系統(tǒng)又嚴(yán)謹(jǐn)。注意，我們并未提及通常意義上測試的定義，即視測試為證明無故障的過程。實(shí)際上，測試并不能證明沒有故障，它只能顯露出軟件中存在的故障。如果測試成功，測試結(jié)果將會揭示出應(yīng)用程序甚至數(shù)據(jù)庫結(jié)構(gòu)中存在的錯誤。測試的第二個好處是可以驗(yàn)證數(shù)據(jù)庫和應(yīng)用程序是否按照需求規(guī)格說明書中的要求工作及其是否能夠滿足系統(tǒng)性能的要求。另外，測試階段收集的測試數(shù)據(jù)又為衡量軟件可靠性和軟件質(zhì)量提供的依據(jù)。

當(dāng)數(shù)據(jù)庫設(shè)計一樣，用戶也應(yīng)參與測試過程。理想的測試環(huán)境應(yīng)該是一個單獨(dú)的硬件系統(tǒng)機(jī)器上的測試用數(shù)據(jù)庫，但實(shí)際上這通常是不可能的。如果使用真實(shí)數(shù)據(jù)進(jìn)行測試，就必須做好備份，以防錯誤的發(fā)生。

除此之外，還應(yīng)對系統(tǒng)的可用性進(jìn)行測試，理想狀況下，還應(yīng)參照可用性規(guī)范對其作出評估。可用性的測試準(zhǔn)則包括（Sommerville，2002）：

• 易學(xué)性：新用戶能夠熟練操作該系統(tǒng)需花費(fèi)多少時間？
• 性能：系統(tǒng)響應(yīng)時間與用戶工作實(shí)際匹配得怎么樣？
• 魯棒性：系統(tǒng)對用戶操作錯誤的容錯能力怎樣？
• 可恢復(fù)性：系統(tǒng)從用戶錯誤中恢復(fù)的能力怎樣？
• 適應(yīng)性：系統(tǒng)與單一的工作模式綁定的有多緊？

上述準(zhǔn)則的評測還可以在系統(tǒng)生命周期的其他階段進(jìn)行。測試結(jié)束以后，數(shù)據(jù)庫系統(tǒng)開發(fā)工作就宣告結(jié)束，即將交付給用戶使用。

13. 運(yùn)行維護(hù)

運(yùn)行維護(hù)：在系統(tǒng)安裝以后，繼續(xù)對系統(tǒng)實(shí)時監(jiān)控和維護(hù)的過程。

在前面的階段中，數(shù)據(jù)庫系統(tǒng)已經(jīng)完全實(shí)現(xiàn)并經(jīng)過測試。現(xiàn)在系統(tǒng)進(jìn)入維護(hù)階段，這一階段包括以下的活動：

• 監(jiān)控系統(tǒng)的性能。如果性能低于可以接受的水平，則必須調(diào)整或重組數(shù)據(jù)庫。
• 維護(hù)系統(tǒng)，必要時升級數(shù)據(jù)庫系統(tǒng)。通過生命周期前面各階段的努力，新的需求融入了數(shù)據(jù)庫系統(tǒng)。

一旦數(shù)據(jù)庫系統(tǒng)開始全面運(yùn)行，隨之就要對其展開密切監(jiān)控，以確保可接受的系統(tǒng)性能。DBMS 通常提供許多實(shí)用工具來輔助數(shù)據(jù)庫管理，其中包括數(shù)據(jù)加載工具和系統(tǒng)監(jiān)控工具。系統(tǒng)監(jiān)控工具可以提供的信息包括數(shù)據(jù)庫的使用情況、加鎖效率（包括已發(fā)生的死鎖個數(shù)等）和查詢執(zhí)行策略。數(shù)據(jù)庫管理員（DBA）利用這些信息進(jìn)行系統(tǒng)的調(diào)優(yōu)，例如，創(chuàng)建索引、改變存儲結(jié)構(gòu)、合并或分割表以提高查詢速度。

對系統(tǒng)的監(jiān)控貫穿于數(shù)據(jù)庫系統(tǒng)的整個運(yùn)行期間，使得數(shù)據(jù)庫能夠及時得到重組以滿足不斷變化的需求。反過來，這些需求上的變化又能夠?yàn)橄到y(tǒng)的演進(jìn)以及未來可能需要的資源提供信息。這種相互作用加上對提出的新應(yīng)用的認(rèn)識，使得 DBA 能夠集中精力進(jìn)行數(shù)據(jù)庫規(guī)劃或提請上級注意調(diào)整規(guī)劃。如果 DBMS 缺乏相關(guān)的工具，DBA 既可以自行開發(fā)，也可購買第三方適用的工具。

當(dāng)心的數(shù)據(jù)庫應(yīng)用程序投入使用后，在一段時期內(nèi)，用戶可能同時并行使用新、舊系統(tǒng)。考慮到新系統(tǒng)可能會出現(xiàn)難以預(yù)料的問題，并行使用兩套系統(tǒng)能夠保證當(dāng)前系統(tǒng)運(yùn)行的正確性。應(yīng)該定期對新、舊系統(tǒng)就數(shù)據(jù)一致性問題進(jìn)行檢驗(yàn)。只有當(dāng)兩個系統(tǒng)總是能產(chǎn)生一致的結(jié)果時，舊系統(tǒng)才可以停用。如果系統(tǒng)的換代過于倉促，最終可能帶來災(zāi)難性的后果。不考慮前面提到的舊系統(tǒng)可能停用的假設(shè)，可能會存在對兩個系統(tǒng)同時進(jìn)行維護(hù)的情形。

14. CASE 工具

在數(shù)據(jù)庫系統(tǒng)開發(fā)生命周期的第一個階段，也就是數(shù)據(jù)庫規(guī)劃階段，可能還會設(shè)計計算機(jī)輔助軟件工程（CASE）工具的選擇問題。從廣義上說，任何一種能夠支持軟件工程的工具都是 CASE 工具。數(shù)據(jù)管理員和數(shù)據(jù)庫管理員需要合適且高效的工具，以保證數(shù)據(jù)庫系統(tǒng)的開發(fā)活動盡可能有效且高效。CASE 對數(shù)據(jù)庫系統(tǒng)開發(fā)活動的支持包括：

• 存儲關(guān)于數(shù)據(jù)庫系統(tǒng)數(shù)據(jù)的相關(guān)信息的數(shù)據(jù)字典。
• 支持?jǐn)?shù)據(jù)分析的設(shè)計工具。
• 支持企業(yè)數(shù)據(jù)模型、概念數(shù)據(jù)模型和邏輯數(shù)據(jù)模型開發(fā)的工具。
• 建立原型系統(tǒng)的工具。

CASE 工具可分為三類：上層 CASE（Upper-CASE）工具、底層 CASE（Lower-CASE）工具和集成 CASE（Integrated-CASE）工具。上層 CASE 工具支持?jǐn)?shù)據(jù)庫系統(tǒng)生命周期的前期工作——從數(shù)據(jù)庫規(guī)劃到數(shù)據(jù)庫設(shè)計。底層 CASE 工具支持?jǐn)?shù)據(jù)庫系統(tǒng)生命周期的后期工作——從實(shí)現(xiàn)、測試到運(yùn)行維護(hù)。集成 CASE 工具支持?jǐn)?shù)據(jù)庫系統(tǒng)生命周期的全部階段的工作，因此兼具上層 CASE 和底層 CASE 工具的全部功能。

使用 CASE 工具的優(yōu)點(diǎn)

使用合適的 CASE 工具應(yīng)該能夠提高數(shù)據(jù)庫系統(tǒng)開發(fā)的生產(chǎn)率。“生產(chǎn)率” 的含義包括開發(fā)過程的效率和所開發(fā)系統(tǒng)的有效性。效率 是指成本，即實(shí)現(xiàn)數(shù)據(jù)庫系統(tǒng)的時間和經(jīng)費(fèi)開銷。CASE 工具通過對系統(tǒng)開發(fā)提供相應(yīng)支持并使開發(fā)過程自動化來提高開發(fā)效率。有效性 是指系統(tǒng)對用戶需求的滿足程度。在追求更高的生產(chǎn)率時，提高開發(fā)過程的有效性可能比提高效率更為重要。例如，開發(fā)人員無視最終產(chǎn)品是否為用戶所想要的產(chǎn)品而盲目追求開發(fā)過程的極端高效并非明智之舉。也就是說，有效性同最終產(chǎn)品的質(zhì)量密切相關(guān)。由于計算機(jī)比人更勝任某些特殊的工作，如一致性檢查，因此 CASE 工具的確可用來提高開發(fā)過程中某些工作的有效性。

對于提高生產(chǎn)率，CASE 工具在以下各個方面都具有優(yōu)越性：

• 標(biāo)準(zhǔn)化。CASE 工具有助于強(qiáng)化軟件項(xiàng)目開發(fā)過程的標(biāo)準(zhǔn)化或者組織內(nèi)部工作流程的標(biāo)準(zhǔn)化。CASE 工具有助于生成可復(fù)用的標(biāo)準(zhǔn)測試組件，以簡化維護(hù)工作并提高生產(chǎn)率。

• 集成化。CASE 工具將所有的信息均保存在倉庫（respository）或數(shù)據(jù)字典中。因此，利用 CASE 工具就可以將從數(shù)據(jù)庫系統(tǒng)生命周期各階段收集到的數(shù)據(jù)存儲起來，并且通過數(shù)據(jù)之間的關(guān)聯(lián)來保證系統(tǒng)各部分的集成性。這樣一個組織機(jī)構(gòu)的信息系統(tǒng)就不再是由一些獨(dú)立的、無關(guān)的部分組成。

• 支持標(biāo)準(zhǔn)化方法。結(jié)構(gòu)化技術(shù)使得圖表的使用具有重要意義，而圖表的手工繪制和維護(hù)是相當(dāng)困難的，CASE 工具簡化了這一過程，能夠生成正確且更為通用的文檔。

• 一致性。由于存儲在數(shù)據(jù)字典中的信息之間存在著內(nèi)在的聯(lián)系，因此可以利用 CASE 工具進(jìn)行一致性的檢查。

• 自動化。一些 CASE 工具可以自動的將設(shè)計規(guī)格說明書轉(zhuǎn)換為可執(zhí)行代碼。這樣不僅可以減少系統(tǒng)開發(fā)的工作量，還可以消除編碼過程中出現(xiàn)的錯誤。