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。在表中，该指标权重最高，说明在此次评估中它是最重要的因素。“易重组性” 的权重是 “数据压缩” 的 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 键修改或者重新输入。

• 对不可接受的值给出错误信息
  当用户试图向字段中输入不正确的数据时，应该能显示错误的信息，以提示用户错误的类型和允许录入的数值。

• 清楚地标记出可选字段
  可选字段应该清楚的标示给用户。可以为该字段选择一个恰当的名称，或者用某种特定的颜色来显示这个字段以表明该字段的类型。可选字段应位于必选字段之后。

• 为字段提供说明性信息
  当用户将光标停留在某个字段上时，应该在屏幕上的特定区域（如状态栏上）显示关于该字段的信息。

• 录入完毕应该出完成信号
  应该让用户清楚何时已经完成了表单上所有字段的填写。但不应自动选择表单填写结束，因为用户可能希望检查一下录入的数据。

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. 测试

测试：运行数据库系统，试图找出错误。

在实际使用前，数据库系统应该经过完全测试。测试过程需要有严密的测试策略和真是的测试数据保证，这样整个测试过程才能既系统又严谨。注意，我们并未提及通常意义上测试的定义，即视测试为证明无故障的过程。实际上，测试并不能证明没有故障，它只能显露出软件中存在的故障。如果测试成功，测试结果将会揭示出应用程序甚至数据库结构中存在的错误。测试的第二个好处是可以验证数据库和应用程序是否按照需求规格说明书中的要求工作及其是否能够满足系统性能的要求。另外，测试阶段收集的测试数据又为衡量软件可靠性和软件质量提供的依据。

当数据库设计一样，用户也应参与测试过程。理想的测试环境应该是一个单独的硬件系统机器上的测试用数据库，但实际上这通常是不可能的。如果使用真实数据进行测试，就必须做好备份，以防错误的发生。

除此之外，还应对系统的可用性进行测试，理想状况下，还应参照可用性规范对其作出评估。可用性的测试准则包括（Sommerville，2002）：

• 易学性：新用户能够熟练操作该系统需花费多少时间？
• 性能：系统响应时间与用户工作实际匹配得怎么样？
• 鲁棒性：系统对用户操作错误的容错能力怎样？
• 可恢复性：系统从用户错误中恢复的能力怎样？
• 适应性：系统与单一的工作模式绑定的有多紧？

上述准则的评测还可以在系统生命周期的其他阶段进行。测试结束以后，数据库系统开发工作就宣告结束，即将交付给用户使用。

13. 运行维护

运行维护：在系统安装以后，继续对系统实时监控和维护的过程。

在前面的阶段中，数据库系统已经完全实现并经过测试。现在系统进入维护阶段，这一阶段包括以下的活动：

• 监控系统的性能。如果性能低于可以接受的水平，则必须调整或重组数据库。
• 维护系统，必要时升级数据库系统。通过生命周期前面各阶段的努力，新的需求融入了数据库系统。

一旦数据库系统开始全面运行，随之就要对其展开密切监控，以确保可接受的系统性能。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 工具应该能够提高数据库系统开发的生产率。“生产率” 的含义包括开发过程的效率和所开发系统的有效性。效率 是指成本，即实现数据库系统的时间和经费开销。CASE 工具通过对系统开发提供相应支持并使开发过程自动化来提高开发效率。有效性 是指系统对用户需求的满足程度。在追求更高的生产率时，提高开发过程的有效性可能比提高效率更为重要。例如，开发人员无视最终产品是否为用户所想要的产品而盲目追求开发过程的极端高效并非明智之举。也就是说，有效性同最终产品的质量密切相关。由于计算机比人更胜任某些特殊的工作，如一致性检查，因此 CASE 工具的确可用来提高开发过程中某些工作的有效性。

对于提高生产率，CASE 工具在以下各个方面都具有优越性：

• 标准化。CASE 工具有助于强化软件项目开发过程的标准化或者组织内部工作流程的标准化。CASE 工具有助于生成可复用的标准测试组件，以简化维护工作并提高生产率。

• 集成化。CASE 工具将所有的信息均保存在仓库（respository）或数据字典中。因此，利用 CASE 工具就可以将从数据库系统生命周期各阶段收集到的数据存储起来，并且通过数据之间的关联来保证系统各部分的集成性。这样一个组织机构的信息系统就不再是由一些独立的、无关的部分组成。

• 支持标准化方法。结构化技术使得图表的使用具有重要意义，而图表的手工绘制和维护是相当困难的，CASE 工具简化了这一过程，能够生成正确且更为通用的文档。

• 一致性。由于存储在数据字典中的信息之间存在着内在的联系，因此可以利用 CASE 工具进行一致性的检查。

• 自动化。一些 CASE 工具可以自动的将设计规格说明书转换为可执行代码。这样不仅可以减少系统开发的工作量，还可以消除编码过程中出现的错误。