【数据库系统开发的生命周期】

数据库系统开发生命周期

阶段	主要活动
数据库规划	规划如何尽可能高效和有效地实现生命周期的各个阶段
系统定义	确定数据库系统的范围和边界，包括主要用户的视图、用户和应用领域
需求收集与分析	收集与分析数据库系统的需求
数据库设计	完成数据库的概念设计、逻辑设计和物理设计
DBMS选型	选择一个合适的DBMS
应用程序设计	完成用户界面和数据库应用程序的总体设计
建立原型系统（可选）	建立可运行的数据库系统模型，使得设计人员和用户能够通过可视化的界面对最终系统的外观和功能进行评估
数据转换与加载	将旧系统中的数据导入新系统，若可能，将应用程序移植到新的数据库上运行。
测试	运行系统找出错误，并验证系统实现是否与用户需求一致
运行维护	数据库系统完全实现后，对系统进行持续性的监控和维护。必要时，重新进行生命周期各阶段的活动，使得系统能够整合新的需求。

1.数据库的规划

数据库规划必须与组织机构关于信息系统的整体策略结合在一起。构思信息系统策略时，涉及下面三个主要问题：

• 识别企业的规划、目标以及随之而定的信息系统需求。

• 评估现有的信息系统，明确其长处与短处。

• 估量IT机遇可能带来的竞争优势。

    数据库规划中:1.清晰定义项目的任务描述（mission statement）。任务描述定义了数据库系统的主要目标，通常由项目主管或负责人撰写。任务描述有助于明晰项目目标，找到切实可行之路，从而高效及有效地实现数据库系统的设计开发。2.是确定任务目标（mission objective）。每个任务目标都应当和一个数据库系统必须支持的功能相对应。我们假设如果数据库系统支持所有的任务目标，那么任务描述也就实现了。任务描述和任务目标可能还包括一些额外的信息，通常包括工作量、所需资源和资金。数据库规划阶段还应建立相关标准，明确数据应该如何收集、确定数据的格式、需要什么样的文档以及如何着手进行设计和实现阶段的工作。标准的建立和维护是非常耗时的，因为初期的建立和后期的持续维护都需要大量资源。但设计良好的标准是员工培训和质量控制的基础，可确保所有工作都符合同一模式，与员工的技能和经验无关。例如，为了消除数据冗余和数据不一致，我们可以在数据字典中定义数据项命名的规则。任何与数据相关的合理的或来自企业的需求都应记录在案，例如约束某些类型的数据应为机密级的。
  

2.系统的定义

2.1系统定义

在设计数据库之前，首先应该确定系统的边界，定义数据库系统与信息系统其他构件之间的接口。在考虑系统边界时，应囊括未来用户的需求和应用领域可能的延伸。

2.2用户视图

3.需求收集与分析

主要设计收集与分析组织机构内需要用到数据库系统的那部分信息，可以采用多种技术采集信息，这些技术称为实况发现技术。针对每个主要用户视图（指不同的工作角色或不同的企业应用方面）应采集的信息包括：

• 使用或产生的数据
• 这些数据是如何使用或产生的
• 对新数据库系统的其他要求

通过对采集信息的分析，可以确定新的数据库系统的需求（或特性），从而生成新数据系统的需求规格说明书。
需求收集与分析是数据库设计的基础，应收集的信息量需要根据问题本身的特性和企业的运转模式而定。
收集的信息可能缺乏良好的结构和形式，因此需将其转换为结构良好的需求描述，可采用需求规范化技术包括：结构化分析和设计（Structured Analysis and Design, SAD）;数据流图（Data Foe Diagrams,DFD）；带有文档辅助说明的分层输入处理输出图（Hierarchical Input Process Output,HIPO）。随后的极端及辅助软件工程（CASE）工具能够进行自动化的检测，确保续期的完整性和一致性。统一建模语言（Unified Model Language,UML）对需求与设计活动的支持。
收集的方法：

• 集中式方法：当各用户视图的需求存在明显重叠并且数据库系统不是非常复杂时，建议采用集中式方法。

• 视图集成方法：能够分割系统需求，更有利于需求的额收集与分析一级后续工作的进行。

• 这两种方法的组合：复杂的数据库系统。

4.数据库设计

4.1数据库设计方法

自下而上（bottom-up）:适用于设计属性较少的简单数据库设计。通过分析属性之间的关联，将它们分别组合成代表实体类型和实体类型之前联系的关系。规范化时，首先确定所属属性，然后基于属性之间的函数依赖将熟悉你聚集成规范化的关系。

**自上而下(top-down)：**适用复杂数据库。建模初始，数据模型仅包含少量的高层实体一级实体之前的联系。实体联系模型首先确定数据库系统所包含的实体和实体之间的关系。

4.2数据建模

4.2.1数据建模的目的
主要有2个。1.有助设计人员对数据含义（语义）的理解。2.有助于设计人员与用户之间的交流。通过数据建模可以正确的理解：

• 每个用户对数据的观点
• 与其物理表现形式无关的数据本身的性质
• 各用户视图中数据的使用

4.2.2建立理想数据模型的标准

结构有效性	与企业定义和组织信息的方式一致
结构有效性	与企业定义和组织信息的方式一致
简洁性	容易被信息系统领域的专业人员或非专业人员理解
表现力	能够区分不同的数据，以及数据之间的联系和约束
没有冗余	排除无关信息，特别是不重复表达信息
共享性	并不限于特定的应用或技术，因此可广泛使用
可扩展性	可以扩展支持新的需求，并且尽可能不影响现有用户的使用
完整性	与企业使用和管理信息的方式一致
图表化表示	能够易于理解的图表符号表示模型

4.3数据库设计的阶段划分

4.3.1概念数据库设计
建立概念数据库模型的过程，该模型与所有物理因素无关。无需考虑实现细节，即概念模型不涉及类似目标DBMS软件的选择，应用程序的编制、编程语言的选择，硬件平台的选择或其他任何物理实现上的细节问题。在概念设计过程中，模型被不断测试，修改直至满足用户的需求。
4.3.2逻辑数据库设计
根据已有的概念数据模型，建立逻辑数据模型，该模型与具体的 DBMS以及其他物理因素无关。
进行逻辑数据库设计时，我们需要知道目标DBMS是关系的、网状的、层次的还是面向对象的。除此之外，将忽略所选 DBMS的其他特征，尤其是物理细节，如目标 DBMS 支持的存储结构或者索引，等等。
在这一阶段，我们引人规范化技术来验证逻辑数据模型的正确性。规范化可以保证由数据模型导出的关系没有数据冗余，而数据冗余则可能会引起更新异常。
4.3.3物理数据库设计
产生数据库在辅存上的实现描述的过程。物理数据库设计定义了基础关系、文件组织方式和能够提高数据访问效率的索引，以及所有的完整性约束和安全措施。
尽管逻辑结构的设计与DBMS 的选择无关，但逻辑数据模型的选择需要与目标 DBMS 支持的数据模型一致，如关系模型、网状模型或者层次模型。在物理数据库设计阶段，必须首先明确目标 DBMS，因此物理数据库设计是面向特定的DBMS系统的。在这一阶段，为了提高性能而做出的一些决策可能会影响逻辑数据模型的数据结构的设计，因此在物理数据库设计和逻辑数据库设计之间存在迭代。
通常，物理数据库设计的主要目标就是描述如何物理地实现逻辑数据库的设计。对于关系模型，物理数据库设计活动包括:

• 根据逻辑数据模型，物理地创建关系表和完整性约束。
• 确定数据的存储结构和访问方式，确保数据库系统的性能最优。
• 设计安全保护机制。

对于大型系统，理想情况是将概念和逻辑数据库设计同物理数据库设计分离开来，主要有三个原因:

• 设计的内容不同:前者仅涉及做什么，与怎么做无关。
• 执行的时机不同:在决定怎么做之前必须先明确做什么。
• 需要的技术不同:不同阶段的建模技术经常为不同的人所拥有。

5.DBMS选型

如果系统开发之初并未指定 DBMS，那么DBMS 选型比较适宜的时机是在概念数据设计之后，且在逻辑数据库设计之前。

然而，如果已经收集到足够多的与统需求相关的信息，如系统性能、数据库的易重组性、安全性和完整性约束等需求,那DBMS的选型可以在逻辑数据库设计之前的任何时间进行。
所选DBMS 既要满足企业眼下所需兼顾未来需求的扩展，选型时要在各种成本之间做出权衡，这些成本包括:购买DBMS品的费用、相关软硬件的开销、系统重建相关的费用以及员工培训的开销。

5.1确定DBMS选型考虑的方面

包括说明调研的目标、范围和需要完成的任务。

该文档还可以包括评估DBMS产品时所需的选型准则(基于用户需求规格说明书)、初步生成的选型列表、所有必要的约束条件和选型进度表，等等。

5.2列出两到三个候选DBMS产品

那些被认为是成事“关键”的准则可用于筛选出 DBMS 候选产品列表，以供后期评估使用。

1. 是否考虑某一DBMS 依赖于系统开发预算、
2. 开发商的技术支持的程度
3. 与其他软件的兼容性
4. 有无特殊的硬件支撑环境要求等等。
5. 通过接触该产品已有用户还可以收集到额外的有用信息:供应商实际的技术支持能力，该产品如何支持特殊的应用是否在某些硬件平台上运行会比在其他平台上运行产生重多的问题。
6. 还可以参考基准测试benchmark)结果对DBMS 产品进行性能比较。经过对DBMS 产品的功能和特性的初步调研后，可以确定两到三个候选DBMS。
7. 万维网(World Wide
   Web)是一个非常好的信息资源，可以利用万维网甄选潜在的候选DBMS。例如，DBMS杂志的网站(www.intelligententerprise.com)提供了一个关于DBMS产品的综合索引。产品供应商的网站也会提供关于
   DBMS 产品的有用信息。

#5.3评估候选DBMS产品

出于不同评估目的考虑，可以将多个性能参数成组评估(例如，对数据定义指标组综合评估)，或者单独考察(例如，仅对数据定义指标组中的有效数据类型特性进行评估)。表将评估 DBMS 产品的指标分为以下几组:数据定义、物理定义、可访问性、事务处理、实用工具、应用开发和其他。

数据定义	物理定义
强制定义主关键字	可用文件结构
外部关键字规范	文件结构维护
可用的数据类型	易重组性
数据类型的可扩展性	索引
域说明	变长字段/记录
易于重构	数据压缩
完整性控制	加密程序
视图机制	内存需求
数据字典	储存需求
数据独立性
基本数据模型
模式演化

可访问性	事务处理
支持多种查询语言:遵从 SQL2/SQL:2011/0DMG	备份和恢复例程 检查点机制
提供3GL接口	日志机制
支持多用户	并发粒度
安全性	死锁解决策略
-访问控制	高级事务模型
-授权机制	并行查询处理
实用工具	应用开发
性能监测	4GL/5GL 工具
调优	CASE 工具
数据导人7导出	图形化操作界面 (Windows 能力)
用户监视	存储过程、触发器和规则
数据库管理支持	Web 开发工具

其他
可升级性	与其他 DBMS 和系统的互操作性
厂商稳定性	Web集成
用户基础	数据复制工具
培训和用户支持	分布式能力
文档	可移植性
要求的操作系统	要求的硬件
在线帮助	面向对象的能力
所用标准	体系结构(支持二或三层客户/服务器模式)
版本管理	性能
可扩展的查询优化	事务吞吐量
可伸缩性	最大用户并发数
对报表和分析工具的支持	对XML和Web 服务的支持

一个更加实用的方法是:根据这些指标或指标组在系统中的重要性，将其赋予不同的权重，用最后得到的综合权值来比较。

5.4给出建议选型DBMS的报告

数据库选型的最后一步是记录下整个选型过程，并提供一份最后结果的说明和建议选择的DBMS产品。

6.应用程序设计

完成用户界面和使用、处理数据库的应用程序的总体设计。

必须确保用户需求规格说明书中提到的所有功能都要在数据库系统的应用程序设计中体现出来，这将涉及到访问数据库的应用程序的设计和数据库事务的设计(即数据库访问方式)。除了设计如何实现需求的功能外，还应为数据库系统设计一个合适的用户界面。用户界面应该以用户友好的方式提供信息。用户界面设计的重要性常常被忽略，或者直到设计阶段的后期才着手考虑。然而，我们应该认识到界面可能是系统最重要的组件之一。如果界面容易学习、易于使用、简单明了、容错性强，则用户就能更好地利用系统提供的信息。

#6.1事务设计

事务：由单个用户或应用程序执行的访问或修改数据库的一个或一组动作。

事务设计的目的是把数据库所需事务的高层特性确定下来并形成文档。这些特性包括

• 事务用到的数据
• 事务的功能特性
• 事务的输出
• 对于用户的重要性
• 预期的使用率

事务设计应该在应用程序设计阶段的前期进行，以确保数据库能够支持所有系统涉及的事务处理。事务主要分为以下三类:检索型事务、更新型事务和混合型事务。
检索型事务：检索型事务主要用于数据检索，并将这些数据显示在屏幕上或生成报表。例如，查询并显示某一指定编号的房屋的详细信息。
更新型事务：更新型事务用于实现记录的插入、删除或修改。例如，在数据库中插入某一新的房屋的信息。
混合型事务：该类型事务的操作包括了数据的检索和更新。例如，查询并显示某一指定编号的房屋的详细信息并更新其月租金。

6.2用户界面设计

在显示表单或报表之前，首先要对其外观和布局进行设计。表列出了在设计表单和报表时应遵循的一些原则(Shneiderman，1992)。
表单/报表设计时应遵循的原则

• 使用有意义的标题
• 操作指令易于理解
• 字段按逻辑分组和排序
• 表单/报表的布局视觉性强
• 用熟悉的字段标签
• 术语和缩写应保持一致
• 配色统一
• 数据录人字段应具有明显的边界并预留足够的空间，
• 光标能够控制自如
• 易于纠正录入错误(包括单个字符和整个字段的录入错误)
• 对不可接受的值给出错误信息
• 清楚地标记出可选字段
• 为字段提供说明性信息
• 录入完毕应给出完成信号

7.建立原型系统（可选）

建立原型系统的策略一般有两种: 需求原型和进化原型。需求原型利用原型确定数案系统的需求、一旦需求明确，该原型系统也就无用了。进化原型和需求原型目的相同,但重要的区别在于它并未被抛弃，而是经过进一步开发之后演变为最终的数据库系统

8.实现

数据库和应用程序设计的物理实现。

建立物理的数据库可以利用所选DBMS的数据定义语言(DDL来实现，也可以利用图形用户接口实现，图形用户接口提供了相同的功能却隐藏了底层DDL语句。DDL语句用于创建数据库的结构并生成一些空的数据库文件。已经确定的用户视图也要在这一阶段定义。
应用程序的开发可以采用第三代语言(3GL)或第四代语言(4GL)。应用程序中关于数据库事务处理的部分，则由目标DBMS的数据操作语言(DML)实现，DML语言将被嵌入某一宿主语言，如 Visual Basic(VB)、VB.net、Python、Delphi、C、C++、C#、JavaCOBOL、FORTRAN、Ada 或者 Pascal。此外，还要实现应用程序设计中出现的其他组件如菜单、数据录人表单和报表等。目标 DBMS可能还拥有可用于应用程序快速开发的第四代工具，这些工具包括非过程化的查询语言、报表生成器、表单生成器和应用程序生成器。
系统的安全性和完整性控制也要在这一阶段实现。某些控制可使用 DDL 来实现,而其他的则可能需要利用 DBMS 提供的实用工具或操作系统来实现。

9.数据转换与加载

将已有的数据转移到新数据库中，将原有的应用移植到新数据库上运行。
DBMS都具有在新的数据库中加载原有数据库文件的实用工具。完成这一操作时需要明确要加载的源文件以及目标数据库，并且 DBMS 能够自动地转换源文件的数据格式以满足新数据库文件格式的要求。数据移植就绪以后，开发人员就有可能将原有系统中的应用程序移植到新系统中。

10.测试

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

测试并不能证明没有故障，它只能显露出软件中存在故障。如果测试成功，测试结果将会揭示出应用程序甚至数据库结构中存在的错误。测试的第二个好处是可以验证数据库和应用程序是否按照需求规格说明书中的要求工作，及其是否能够满足系统性能要求。另外，测试阶段收集的测试数据又为衡量软件可靠性和软件质量提供了依据。
与数据库设计一样，用户也应参与测试过程。理想的测试环境应该是一个单独的硬件系统及其上的测试用数据库，但实际上这通常是不可能的。如果使用真实数据进行测试，就必须做好备份，以防错误的发生。
除此之外，还应对系统的可用性进行测试，理想状况下，还应参照可用性规范对其做出评估。可用性的测试准则包括(Sommerville，2002):

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

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

11.运行维护

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

现在系统进人维护阶段，这一阶段包括以下的活动:
监控系统的性能：如果性能低于可以接受的水平，则必须调整或重组数据库。。维护系统，必要时升级数据库系统。通过生命周期前面各阶段的努力，新的需求融人了数据库系统。
一旦数据库系统开始全面运行，随之就要对其展开密切监控，以确保可接受的系统性能。DBMS 通常提供许多实用工具来辅助数据库管理，其中包括数据加载工具和系统监控工具。系统监控工具可以提供的信息包括数据库的使用情况、加锁效率(包括已发生的死锁个数等)和查询执行策略。数据库管理员 (DBA)利用这些信息进行系统调优，例如，创建索引、改变存储结构、合并或分割表以提高查询速度。
对系统的监控贯穿于数据库系统的整个运行期间，使得数据库能够及时得到重组以满足不断变化的需求。反过来，这些需求上的变化又能够为系统的演进以及未来可能需要的资源提供信息。这种相互作用加上对提出的新应用的认知，使得 DBA 能够集中精力进行数据库对系统的监控贯穿于数据库系统的整个运行期间，规划或提请上级注意调整规划。如果 DBMS 乏相关的工具。DBA 既可以自行开发，也购买第三方适用的工具。
当新的数据库应用程序投人使用后，在一段时期内，用户可能同时并行使用新、旧统。考虑到新系统可能会出现难以预料的问题，并行使用两套系统能够保证当前系统运行正确性。应该定期对新、旧系统就数据一致性问题进行检验。只有当两个系统总是能产生致的结果时，旧系统才可以停用。

12.CASE工具

从广义上说，任何一种能够支持软件工程的工具都是CASE工具。

数据管理员和数据库管理员需要合适且高效的工具，以保证数据库系统开发活动尽可能有效且高效。CASE 对数据库系统开发活动的支持包括:

• 存储关于数据库系统数据的相关信息的数据字典。
• 支持数据分析的设计工具。
• 支持企业数据模型、概念数据模型和逻辑数据模型开发的工具
• 建立原型系统的工具。

上层CASE：支持数据库系统生命周期的前期工作一一从数据库规划到数据库设计。
底层CASE：支持数据库系统生命周期的后期工作一-从实现、测试到运行维护。
集成CASE：支持数据库系统生命周期的全部阶段的工作，因此兼具上层 CASE 和底层CASE 工具的全部功能。
CASE工具的优点
使用合适的CASE工具应该能够提高数据库系统开发的生产率。“生产率”的含义包括开发过程的效率和所开发系统的有效性。效率是指成本，即实现数据库系统的时间和经费开销。CASE 工具通过对系统开发提供相应支持并使开发过程自动化来提高开发效率。有效性是指系统对用户需求的满足程度。在追求更高的生产率时，提高开发过程的有效性可能比提高效率更为重要。
对于提高生产率，CASE 工具在以下各个方面都具有优越性:
标准化：CASE工具有助于强化软件项目开发过程的标准化或者组织内部工作流程的标准化。CASE 工具有助于生成可复用的标准测试组件，以简化维护工作并提高生产率。
集成化：CASE工具将所有信息均保存在仓库(repository) 或数据字典中。因此，利用CASE 工具就可以将从数据库系统生命周期各阶段收集到的数据存储起来，并且通过数据之间的关联来保证系统各部分的集成性。这样一个组织机构的信息系统就不再是由一些独立的、无关的部分组成。
支持标准化方法：结构化技术使得图表的使用具有重要意义，而图表的手工绘制和维护是相当困难的，CASE 工具简化了这一过程，能够生成正确且更为通用的文档。
一致性：由于存储在数据字典中的信息之间存在着内在的联系，因此可以利用CASE 工具进行一致性的检查。
自动化：一些CASE工具可以自动地将设计规格说明书转换为可执行代码。这样不仅可以减少系统开发的工作量，还可以消除编码过程中出现的错误。