1. 信息系統生命周期

信息系統：在組織機構內用于收集、管理、控制和分發信息的一種資源。
從 20 世紀 70 年代起，數據庫系統已經逐漸代替了基于文件的系統，成為信息系統（Information System，IS）的基礎結構。同時，人們還認識到，和其他的資源一樣，數據也是一種重要的物質資源，理應受到重視。許多企業為此建立了專門的部門或職能單位——數據管理（DA）和數據庫管理（DBA）機構，分別負責管理、控制數據和數據庫。

基于計算機的信息系統包括數據庫、數據庫軟件、應用軟件、計算機硬件，還包括人的使用和開發活動。

數據庫是信息系統的基礎構件，應該從企業的需求這一更加廣泛的角度來考慮數據庫的開發及使用。因此，信息系統的生命周期同支撐它的數據庫系統的生命周期之間有著內在的聯系。典型的信息系統的生命周期包括：規劃、需求收集與分析、系統設計、建立原型關系、系統實現、測試、數據轉換和運行維護。下面將從開發數據庫系統的角度來討論這些階段性工作。不管怎樣，開發數據庫系統時應全面考慮，將其視為開發大型信息系統的一個構件，這點很重要。

本文使用術語 “職能部門” 和 “應用方面” 表示企業內部的特殊活動，比如銷售、人事和庫存管理。

2. 數據庫系統開發生命周期

數據庫系統是信息系統的基礎構件，因此數據庫系統開發生命周期與信息系統生命周期之間有著內在的聯系。數據庫系統開發生命周期的各個階段如下圖所示，每個階段下面的小節編號是本章詳細描述該階段內容的小節的編號。

數據庫系統開發生命周期的各個階段

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

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

3. 數據庫規劃

數據庫規劃：數據庫規劃是一種管理活動，目的是盡可能高效及有效的展開數據庫系統開發生命周期的各個階段。

數據庫規劃必須與組織機構關于信息系統的整體策略結合在一起。構思信息系統策略時，涉及下面三個主要問題：

• 識別企業的規劃、目標以及隨之而定的系統信息需求。
• 評估現有的信息系統，明確其長處與短處。
• 估量 IT 機遇可能帶來的競爭優勢。

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

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

數據庫規劃階段還應建立相關標準，明確數據應該如何收集、確定數據的格式、需要什么樣的文檔以及如何著手進行設計和實現階段的工作。標準的建立和維護是非常耗時的，因為初期的建立和后期的持續維護都需要大量資源。但設計良好的標準是員工培訓和質量控制的基礎，可確保所有工作都符合同一模式，與員工的技能和經驗無關。例如，為了消除數據冗余和數據不一致，我們可以在數據字典中定義數據項命名和規則。任何與數據相關的合理的或來自企業的需求都應記錄在案，例如約束某些類型的數據應為機密級的。

4. 系統定義

系統定義：定義數據庫應用程序的范圍和邊界，以及主要的用戶視圖。

在設計數據庫之前，首先應該確定系統的邊界，定義數據庫系統與信息系統其它構件之間的接口。在考慮系統邊界時，應囊括未來用戶的需求和應用領域可能的延伸。

用戶視圖：從一個特定的角色（如經理或主管）或者特定的企業應用領域（如銷售、人事或庫存管理）的角度來定義數據庫系統的需求。

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

5. 需求收集與分析

需求收集與分析：收集、分析組織機構內需要數據庫系統支持的那部分的信息，并據此確定對新系統的需求。

本階段的活動主要涉及收集與分析組織機構內需要用到數據庫系統的那部分信息。我們可以操用多種技術采集信息，這些技術被稱為 實況發現技術（fact-finding techniques）。針對每個主要用戶視圖（指不同的工作角色或不同的企業應用方面）應采集的信息包括：

• 使用或產生的數據
• 這些數據是如何使用或產生的。
• 對新數據庫系統的其他需求。

通過對所采集信息的分析，可以確定新的數據庫系統的需求（或特性），從而生成新數據庫系統的 需求規格說明書。

需求的收集與分析是數據庫設計的基礎。應收集的信息量需要根據問題本身的特性和企業的運轉模式而定。考慮過細會陷入 分析僵局（paralysis by analysis），無法繼續開展下一步工作；而考慮過粗則可能因為針對錯誤的需求定位而給出錯誤的的解決方案，導致后期不必要的時間和金錢浪費。

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

確定數據庫系統的功能也是本階段的一項關鍵性活動。系統功能的不當（inadequate）或不完全（incomplete）會使用戶感到使用不便，從而導致系統利用率不高，甚至被棄而不用。然而功能過于完善也會導致系統過于復雜，從而難于實現、維護、使用和學習。

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

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

5.1 集中式方法

集中式方法：合并所有用戶視圖的需求，形成對新系統的一組需求。在數據庫設計階段創建一個表示了所有用戶需求的數據模型。

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

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

5.2 視圖集成方法

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

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

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

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

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

下一篇文章將會詳細討論如何處理多個用戶的視圖，并將采用本書描述的方法學，說明如何綜合使用集中式和視圖集成方法，實現 DreamHome 房屋租賃數據庫系統。

6. 數據庫設計

數據庫設計：為企業或單位所需數據庫系統生成設計方案的過程，該設計方案應能支持該數據庫的任務描述和任務目標。

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

6.1 數據庫設計方法

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

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

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

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

6.2 數據建模

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

• 每個用戶對數據的觀點
• 與其物理表現形式無關的數據本身的性質
• 各用戶視圖中數據的使用

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

數據模型的標準

一個理想的數據模型應符合下表所列的標準（Fleming and Von Halle，1989）。但是，有時這些標準相互矛盾，需要進行折中。例如，在試圖追求更好的表現力時，數據模型就會失去簡潔性。

6.3 數據庫設計的階段劃分

數據庫設計分為 概念設計、邏輯設計 和 物理設計 三個階段。

概念數據庫設計：建立概念數據模型的過程，該模型與所有物理因素無關。

數據庫設計的第一階段稱為 概念數據庫設計。在這一階段，將根據用戶需求規格說明書建立概念數據模型。在概念數據庫設計階段，無需考慮實現細節，即概念模型不涉及類似目標 DBMS 軟件的選擇、應用程序的編制、編程語言的選擇、硬件平臺的選擇或其他任何物理實現上的細節問題。

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

邏輯數據庫設計：根據已有的概念數據模型，建立邏輯數據模型，該模型與具體的 DBMS 以及其他物理因素無關。

數據庫設計的第二階段稱為 邏輯數據庫設計，在這一階段，針對建模時關注的企事業部分構建邏輯數據模型。即將前一階段創建的概念數據模型進行細化，然后映射為邏輯數據模型。邏輯數據模型是建立在目標數據庫所支持的數據模型（例如，關系數據模型）基礎之上的。

盡管概念數據模型獨立與物理實現，但是邏輯數據模型卻是在已知目標 DBMS 的基本數據模型的條件下推導出來的。也就是說，進行邏輯數據庫設計時，我們需要知道目標 DBMS 是關系的、網狀的、層次的還是面向對象的。除此之外，將忽略所選 DBMS 的其他特征，尤其是物理細節，如目標 DBMS 支持的存儲結構或者索引，等等。

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

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

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

物理數據庫設計是數據庫設計的最后一個階段。在這一階段，設計人員將確定數據庫的物理實現細節。在邏輯數據庫設計階段已經建立了數據庫的邏輯結構，實現了關系和業務約束的定義。盡管邏輯結構的設計與 DBMS 的選擇無關，但邏輯數據模型的選擇需要與目標 DBMS 支持的數據模型一致，如關系模型、網狀模型或者層次模型。在物理數據庫設計階段，必須首先明確目標 DBMS，因此物理數據庫設計是面向特定的 DBMS 系統的。在這一階段，為了提高性能而做出的一些決策可能會影響邏輯數據庫模型的數據結構的設計，因此在物理數據庫設計和邏輯數據庫設計之間存在迭代。

通常，物理數據庫設計的主要目標就是描述如何物理的實現邏輯數據庫的設計。對于關系模型，物理數據庫設計活動包括：

• 根據邏輯數據模型，物理的創建關系表和完整性約束。
• 確定數據的存儲結構和訪問方式，確保數據庫系統的性能最優。
• 設計安全保護機制。

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

• 設計的內容不同：前者僅涉及做什么，與怎么做無關。
• 執行的時機不同：在決定怎么做之前必須先明確做什么。
• 需要的技術不同：不同階段的建模技術經常為不同的人所擁有。

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

前面我們提到過數據庫系統的三層 ANSI-SPARC 體系結構：外模式、概念模式和內模式。下圖給出了三級模式與概念、邏輯和物理數據庫設計階段的對應關系。在第四部分將逐步詳細描述物理數據庫設計階段所涉及的方法學。

數據建模與 ANSI-SPARC 體系結構

7. DBMS 選型

DBMS 選型：選擇適合的 DBMS 以支持相應的數據庫系統。

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

盡管我們可能不會頻繁的進行 DBMS 的選型，但是當企業的需求擴展或者需要重建現有系統時，將有必要再次對 DBMS 產品進行評估，所選 DBMS 既要能滿足企業眼下所需也要兼顧未來需求的擴展，選型時要在各種成本之間做出權衡，這些成本包括：購買 DBMS 產品的費用、相關軟硬件的開銷、系統重建相關的費用以及員工培訓的開銷。

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

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

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

列出 DBMS 選型時研究考慮的方面看，包括說明調研的目標、范圍和需要完成的任務。該文檔還可以包括評估 DBMS 產品時所需的選型準則（基于用戶需求規格說明書）、初步生成的選型列表、所有必要的約束條件和選型進度表，等等。

列出兩到三個候選 DBMS 產品

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

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

評估候選 DBMS 產品

評估 DBMS 產品的指標很多。出于不同評估目的考慮，可以將多個性能參數成組評估（例如，對數據定義指標組綜合評估），或者單獨考察（例如，金對數據定義指標組中的有效數據類型特性進行評估）。下表將評估 DBMS 產品的指標分為以下幾組：數據定義、物理定義、可訪問性、事務處理、實用工具、應用開發和其他。

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

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

最后，將所有評估指標組，加權后的得分加在一起就得到了某 DBMS 產品的得分。將不同 DBMS 的最后評估得分進行比較，分數最高的產品就是最佳選擇。

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

給出建議選型 DBMS 的報告
數據庫選型的最后一步是記錄下整個選型過程，并提供一份最后結果的說明和建議選擇的 DBMS 產品。

8. 應用程序設計

應用程序設計：完成用戶界面和使用、處理數據庫的應用程序的總體設計。

在數據庫系統開發生命周期示意圖中，可以看到數據庫設計和應用程序設計是并行進行的。大多數情況下，不可能在數據庫設計實現之前就完成應用程序設計。另一方面，數據庫是應用程序設計的支撐，因此，應用程序設計和數據庫設計之間必然存在信息交流。

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

下面介紹應用程序設計兩個方面：事務設計和用戶界面設計。

8.1 事務設計

在討論事務設計前我們先描述一下事務的含義。
事務：由單個用戶或應用程序執行的訪問或修改數據庫的一個或一組動作。

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

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

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

• 事務用到的數據
• 事務的功能特性
• 事務的輸出
• 對于用戶的重要性
• 預期的使用率

事務設計應該在應用程序設計階段的前期進行，以確保數據庫能夠支持所有系統涉及的事務處理。事務主要分為以下三類：檢索型事務、更新型事務和混合型事務。

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

8.2 用戶界面設計指南

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

• 使用有意義的標題
  標題傳達的信息應該清楚、明確，與表單 / 報表所要描述的問題一致。

• 操作指令易于理解
  應盡量使用用戶熟悉的術語向用戶傳達操作指令。之靈信息應該簡短，當需要進一步提示時，應提供幫助窗口。操作指令應使用標準格式且文風一致。

• 字段按邏輯分組和排序
  表單 / 報表中相關的字段應該集中于同一區域，字段的排列順序應符合邏輯并風格一致。

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

• 用熟悉的字段標簽
  字段標簽應該是用戶所熟悉的。比如，若用 “Gender” 代替字段 “Sex”，則可能有些用戶會感到有點糊涂。

• 術語和縮寫應保持一致
  使用用戶熟悉的術語和縮寫，且前后一致。

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

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

• 光標能夠控制自如
  用戶應該能夠自如的在表單 / 報表中移動光標以選擇其操作。光標的控制可以通過控制 Tab 鍵、鍵盤方向鍵以及鼠標實現。

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

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

• 清楚地標記出可選字段
  可選字段應該清楚的標示給用戶?？梢詾樵撟侄芜x擇一個恰當的名稱，或者用某種特定的顏色來顯示這個字段以表明該字段的類型?？蛇x字段應位于必選字段之后。

• 為字段提供說明性信息
  當用戶將光標停留在某個字段上時，應該在屏幕上的特定區域（如狀態欄上）顯示關于該字段的信息。

• 錄入完畢應該出完成信號
  應該讓用戶清楚何時已經完成了表單上所有字段的填寫。但不應自動選擇表單填寫結束，因為用戶可能希望檢查一下錄入的數據。

9. 建立原型系統

在設計過程中，關于系統的初步實現，我們可以選擇完全實現該數據庫系統或者僅僅建立一個原型系統。

建立原型系統：建立數據庫系統的一個工作模型。

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

建立原型系統的策略一般有兩種：需求原型和進化原型。需求原型 利用原型確定數據庫系統的需求，一旦需求明確，該原型系統也就無用了。進化原型 和需求原型目的相同，但最重要的區別在于它并未被拋棄，而是經過進一步開發之后演變為最終的數據庫系統。

10. 實現

實現：數據庫和應用程序設計的物理實現。

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

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

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

11. 數據轉換與加載

數據轉換與加載：將已有的數據轉移到新數據庫中，將原有的應用移植到新數據庫上運行。

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

12. 測試

測試：運行數據庫系統，試圖找出錯誤。

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

當數據庫設計一樣，用戶也應參與測試過程。理想的測試環境應該是一個單獨的硬件系統機器上的測試用數據庫，但實際上這通常是不可能的。如果使用真實數據進行測試，就必須做好備份，以防錯誤的發生。

除此之外，還應對系統的可用性進行測試，理想狀況下，還應參照可用性規范對其作出評估?？捎眯缘臏y試準則包括（Sommerville，2002）：

• 易學性：新用戶能夠熟練操作該系統需花費多少時間？
• 性能：系統響應時間與用戶工作實際匹配得怎么樣？
• 魯棒性：系統對用戶操作錯誤的容錯能力怎樣？
• 可恢復性：系統從用戶錯誤中恢復的能力怎樣？
• 適應性：系統與單一的工作模式綁定的有多緊？

上述準則的評測還可以在系統生命周期的其他階段進行。測試結束以后，數據庫系統開發工作就宣告結束，即將交付給用戶使用。

13. 運行維護

運行維護：在系統安裝以后，繼續對系統實時監控和維護的過程。

在前面的階段中，數據庫系統已經完全實現并經過測試。現在系統進入維護階段，這一階段包括以下的活動：

• 監控系統的性能。如果性能低于可以接受的水平，則必須調整或重組數據庫。
• 維護系統，必要時升級數據庫系統。通過生命周期前面各階段的努力，新的需求融入了數據庫系統。

一旦數據庫系統開始全面運行，隨之就要對其展開密切監控，以確?？山邮艿南到y性能。DBMS 通常提供許多實用工具來輔助數據庫管理，其中包括數據加載工具和系統監控工具。系統監控工具可以提供的信息包括數據庫的使用情況、加鎖效率（包括已發生的死鎖個數等）和查詢執行策略。數據庫管理員（DBA）利用這些信息進行系統的調優，例如，創建索引、改變存儲結構、合并或分割表以提高查詢速度。

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

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

14. CASE 工具

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

• 存儲關于數據庫系統數據的相關信息的數據字典。
• 支持數據分析的設計工具。
• 支持企業數據模型、概念數據模型和邏輯數據模型開發的工具。
• 建立原型系統的工具。

CASE 工具可分為三類：上層 CASE（Upper-CASE）工具、底層 CASE（Lower-CASE）工具和集成 CASE（Integrated-CASE）工具。上層 CASE 工具支持數據庫系統生命周期的前期工作——從數據庫規劃到數據庫設計。底層 CASE 工具支持數據庫系統生命周期的后期工作——從實現、測試到運行維護。集成 CASE 工具支持數據庫系統生命周期的全部階段的工作，因此兼具上層 CASE 和底層 CASE 工具的全部功能。

使用 CASE 工具的優點

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

對于提高生產率，CASE 工具在以下各個方面都具有優越性：

• 標準化。CASE 工具有助于強化軟件項目開發過程的標準化或者組織內部工作流程的標準化。CASE 工具有助于生成可復用的標準測試組件，以簡化維護工作并提高生產率。

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

• 支持標準化方法。結構化技術使得圖表的使用具有重要意義，而圖表的手工繪制和維護是相當困難的，CASE 工具簡化了這一過程，能夠生成正確且更為通用的文檔。

• 一致性。由于存儲在數據字典中的信息之間存在著內在的聯系，因此可以利用 CASE 工具進行一致性的檢查。

• 自動化。一些 CASE 工具可以自動的將設計規格說明書轉換為可執行代碼。這樣不僅可以減少系統開發的工作量，還可以消除編碼過程中出現的錯誤。