1
第 13章 数据库应用系统的开发方法
?结构化生命周期方法
?快速原型方法
?面向对象设计方法
?!!!!!
?客户 /服务器应用规划综述
2
结构化生命周期方法
?确定系统需求；
?系统开发；
?系统安装配置；
?系统运行；
?系统切换 。
1.系统调查及可行性分析 ；
2.系统分析（需求分析） ；
3.概要设计（总体设计） ；
4.详细设计（模块设计） ；
5.系统实现（编程） ；
6.系统调试与试运行（测试） ；
7.系统运行、评价与维护（运行） 。
3
开发的进度安排
?规划, 需求分析和设计约占 1/3；
?编程实现约占 1/6；
?测试约占 1/2。
4
系统调查和可行性分析
?这一阶段的任务是初步了解信息系统用户
的组织机构、业务范畴以及新系统的目标，
并且做出可行性分析，包括经济可行性、
技术可行性和使用可行性。
5
需求分析和信息采集
?准确、全面地采集 信息是数据库应用规划
和设计的必不可少的重要组成部分，要想
确保在数据库应用开发的各个阶段所做出
的重要决定都是明智和正确的，那么做好
这一步的工作就更加至关重要。
6
总体设计
?这一步的主要任务是把用户的信息要求统
一到一个整体的逻辑结构或概念模式中，
此结构能表达用户的要求，并且独立于任
何硬件和数据库管理系统。这一步，从应
用程序的角度来讲，要完成子系统的划分
和功能模块的划分；从数据库的角度来讲
要完成概念模型的设计。
7
详细设计
?这一步同样是包括数据库设计和应用程序
设计两大部分。对数据库设计要根据具体
的数据库管理系统设计数据库、设计关系、
考虑数据的完整性、考虑数据的安全和备
份策略等。对应用程序设计要给出功能模
块说明，考虑实施方法，设计存储过程等。
8
编程
?它根据上一步的设计结果进行具体实施，
建立数据库并装入原始数据，建立存储过
程，编写和调试应用程序代码等。
9
调试与试运行
?一般在编程阶段都做了局部测试，现在各
个子系统、各个模块要进行联合调试和测
试，并试运行。在试运行阶段要广泛听取
用户的意见，并根据运行效果进行评估，
修改系统的错误、改进系统的性能。
10
交给用户使用
?最后一步是将系统交给用户使用，在使用
的过程中可能还会出现新的问题，甚至提
出新的需求，所以还要不断对系统进行评
价和维护。数据库系统的维护不是一朝一
夕的事，只要数据库系统存在，就要不断
进行评价、调整、修改，直至数据库生命
周期结束，或完全重新设计为止。
11
快速原型方法
?所谓“原型”可以看作是“企业作业原型”
或“软件功能原型”，它基本反映了最终
系统的基本功能和基本特征，依此可以快
速开发一个可以演示的系统，用户可以在
这个原型系统中得到启发，发现存在的问
题，提出新的要求，并和开发人员一起修
正和发展原型。如此反复进行，最后形成
用户满意的系统。
12
快速原型开发方法可以分为四个步骤：
?系统基本需求的确定；
?对原型的功能选择；
?原型的构造与试用；
?原型的修改和完善。
13
面向对象方法
?面向对象（ Object Oriented） 方法的思想源
于面向对象程序设计。面向对象的分析方
法是从现实世界抽象出对象及发生在对象
上的事件，从而建立起数据对象和处理操
作之间的联系。而利用面向对象的开发工
具去实现面向对象的模型是一件很自然的
转换过程。
14
面向对象的分析和设计方法
?系统分析
?系统设计
?系统实施
15
系统分析
?和结构化生命周期法一样，在面向对象开发方法
过程中需求分析阶段的主要任务也是确定用户的
需求，面向对象的分析方法以现实世界的对象为
基础，注重现实世界对象的数据特征和行为特征，
虽然它在表述对象的数据需求和操作需求方面是
很自然的，但却没有想象的那么简单，还是需要
一定的经验，因为现实世界中的客观对象是五花
八门的，所以有时利用面向对象方法进行抽象可
能会有一定的困难。
16
系统分析
?抽象对象的过程可以由上向下，也可以由
下向上。所谓由上向下，就是首先抽象出
整个问题域中的所有对象，并以对象为基
础分析对象的数据需求和操作需求，然后
给出问题和解决问题过程的准确描述；而
所谓由下向上则是首先描述各个问题和解
决问题的过程，并从各个问题中抽象出对
象，然后将同类对象进行合并。
17
系统分析
?需求模型化是面向对象方法中最常用的方
法之一，它通过对需要解决的实际问题建
立业务模型来抽取对象、描述对象，从而
将用户的需求准确地表达出来。一般包括
对象模型, 动态行为模型 和 用界面模型 等。
18
对象模型
?对象模型是整个面向对象方法的基础，它
是整个系统的抽象，其中要描述用户需求
中的各个对象，及其对象的属性、可能处
于的各种状态以及可能的继承、集合等，
还要包括各个对象之间的相互关系等。
19
动态行为模型
?动态行为模型主要用来描述系统的一些动
态特征，如定义可能的系统事件和各实体
对各种事件的响应等。
20
用界面模型
?用户界面模型显然用来描述用户使用和操
作应用系统的界面，包括界面的外观和各
种具体的操作功能等，它可以使客户对未
来的系统首先建立一个感官的认识。
21
系统设计
?概要设计
?概要设计也称作总体设计，所以这一阶段的任
务是要将用户的需求统一到一个总体的逻辑结
构和概念模式中，要描述出与对象模型对应的
所有类，要描述类之间的相互关系和继承关系
等；同时要将动态行为模型中的操作、事件和
对事件的响应等体现在类中；在这个阶段还要
确定整个应用系统的结构框架和输入输出接口
等。
22
系统设计
?详细设计
?确定系统的具体实施方法。要对每个类进行细化、分
析、验证，要确定每个类的属性，要确定每个对象可
能出现的各种状态，要确定每个类将要支持的方法，
要确定每个方法的功能、参数和返回值等。
?在设计类时要充分考虑类的封装性、继承性和多态性。
要明确规定类和类内成员的访问权限；要充分分析类
之间的关系，特别是继承关系，使软件可重用性得到
充分体现；要仔细、严格设计和验证各种方法和函数，
保证系统描述的一致性。
23
系统实施
?通过选择一种合适的面向对象的开发工具
（如 PowerBuilder） 具体开发和实现经过仔
细设计的应用系统。在编程实现工作过程
中，肯定会发现在分析和设计阶段隐藏的
问题，这时则要及时地返回相关步骤进行
调整。
24
可能会失败！
25
认识问题
有些系统集成公司在项目的网络、硬件、系统软件等
方面都很有经验，也很成功，但当他们为用户开发软件时，
往往开始也踌躇满志，在经过一段时间后就显得力不从心
了，结果搞的焦头烂额。其原因是这些系统集成公司多是
一些硬件商或软件商的代理，对产品很了解，但是他们缺
少系统分析人员，对数据库项目的开发认识不足、了解甚
少，并且普遍轻视系统分析和系统设计工作，结果很难收
场，最后以失败告终。
26
方法问题
国内各种教科书对结构化生命周期方法介绍较多，这
种方法比较规范，国外成功的例子也很多。这种方法对需
求分析的结果要求很高，按规定需求分析所产生的系统说
明书将作为系统开发的技术合同，以后的工作按部就班地
进行就可以了。
如果照搬结构化生命周期方法开发国内的数据库项目
，多数情况下都不现实，往往按照技术合同开发的系统并
不是用户所需要的系统，其原因我们已经在前文中说明了
。结果是用户对开发的系统不认可、不验收；开发方以技
术合同为证指责用户。如果双方都不让步，则只能以失败
告终。
27
工具问题
有一些开发单位或开发人员，对数据库项目开发了解
甚少，经常称自己采用的是“快速原形方法”，但结果却
不快。程序是一条条编出来的，开发人员需要经常修改程
序和数据库结构，甚至推倒重来。这里面，一方面是忽视
了前期的分析和设计工作，没有构造出准确的原型；另一
方面是没有掌握快速的开发工具，靠手工完成大部分程序
。
由于缺少对开发数据库项目的整体认识，盲目采用
所谓快速原型方法，结果反而不快，搞的自己狼狈不堪。
28
管理问题
有些单位对开发一些简单的系统还可以胜任，在开发
大系统时，各独立的子系统也分别能正确运行。但是，这
些子系统却不能协同工作，数据共享差。另外，各子系统
的界面风格可能也相差甚远。之所以会这样，主要是项目
负责人或开发单位缺乏对整个项目的有效管理，开发人员
之间也缺乏有效的沟通和交流
29
数据库设计
?概念模型设计
?逻辑数据库设计
?规范化理论的应用
?物理数据库设计
30
概念模型设计
?概念模型设计是不依赖于任何数据库管理系统的，
它是对用户信息需求的归纳。概念设计的结果得
到的是数据库的概念结构，或称概念数据模型，
由于它是从现实世界的角度进行的抽象和描述，
所以与具体的硬件环境和软件环境均无关。
31
概念模型设计
?概念模型的设计或描述工具是 E-R图
?确定实体；
?确定实体的属性；
?确定实体的标识属性（关键字）；
?确定实体间的联系和联系类型；
?确定实现实体间联系的属性（外部关键字或连
接属性）；
?画出表示概念模型的 E-R图；
?确定属性间的依赖关系。
32
概念模型设计
?设计局部 E-R图
?将 局部 E-R图合并成全局 E-R图
?在不同的局部 E-R图中，表示相同事物的实体名和属性
名要统一，在合并 E-R图前先做此统一工作，要消除同
名异义和同义异名，这样可以有效避免不一致性和冗余。
?如果两个有相同意义的实体在一个局部 E-R图中存在着
一种联系，而在另一个局部 E-R图中存在着另一种不同
的联系，那么在合并时这两种联系都要保留下来，即在
两个实体之间，可能存在着两种不同的联系。
33
概念模型设计
?对合并后得到的整体概念数据模型进行必
要的审核和验证，以保证它的正确性和可
用性。审核或验证工作包括：
?整体概念模型内部必须具有一致性，不能有相
互矛盾的表述；
?整体概念模型必须能够准确反映原来的每个局
部模型的结构，包括实体、属性和联系等；
?整体概念模型必须能够满足需求分析阶段所确
定的所有要求，这一条实际蕴涵了以上两条。
34
逻辑数据库设计
?概念数据库设计是独立于数据库管理系统的，而
逻辑数据库设计却与具体的数据库管理系统有关。
?在逻辑数据库阶段首先要考虑实现数据库的数据
库管理系统所支持的数据模型是什么。
?在逻辑数据库设计阶段，我们首先将概念数据模
型转换为关系数据模型，即将 E-R图中的实体和
联系转换为关系模式。
?对关系数据库来说，逻辑数据库设计的结果是一
组关系模式，接着要应用关系规范理论对这些关
系模式进行规范化处理。
35
逻辑数据库设计阶段应该考虑
?确定各个关系模式的主关键字，考虑实体
完整性；
?确定各个关系模式的外部关键字，考虑参
照完整性；
?确定各个关系模式中属性的约束、规则和
默认值，考虑域完整性；
?根据用户需求设计视图；
?考虑安全方案和用户使用权限等。
36
规范化理论的应用
?运用规范化的标准（ 3NF,BCNF,4NF）
来检验目前所得到的关系模式是否达到了
规范化的要求，并对没有达到规范化要求
的关系模式进行模式分解。
37
物理数据库设计
?物理数据库设计的内容是设计数据库的存储结构
和物理实现方法。
?关系数据库的物理设计一般包括：
?估算数据库的数据存储量
?安排数据库的存储
?设计索引
?设计备份策略
38
数据库设计工具 PowerDesigner
?概念数据模型 （ Conceptual Data Model）
?物理数据模型 （ Physical Data Model）
?面向对象模型 （ Object-Oriented Model）
?业务处理模型 （ Business Process Model）
PowerDesigner的 数据库设计功能
39
概念数据模型设计
?概念数据模型建模工具，简称 CDM。 概念
数据模型由现实世界的数据对象构成，描
述系统的整体逻辑结构，它提供一种对企
业或商业活动中的数据进行形式化描述的
手段。
40
物理数据模型设计
?物理数据模型建模工具，简称 PDM。 物理
数据模型详细描述数据库的物理实现，需
要包括数据库实际物理实现的所有细节，
以及数据存取和数据存储的约束机制等。
41
面向对象模型
?面向对象模型建模工具，该工具可以建立与 UML
（ 统一建模语言）密切相关的面向对象模型，支
持：
?用例图（ Use case diagram）
?序列图（ Sequence diagram）
?类图（ Class diagram）
?构件图（ Component diagram）
?活动图（ Activity diagram）
?等 ……
42
业务处理模型
?业务处理模型建模工具 。 业务处理模型是
一种描述业务伙伴间业务逻辑和规则的概
念模型 。 该 模 型 使 用 图 说 明 处 理
（ Processes）, 数据流 （ Flows）, 消息
（ Messages） 和协作协议 （ Collaboration
Protocols） 之间的相互作用和关系 。
43
PowerDesigner的数据库设计功能
?概念数据模型（ CDM） 和物理数据模型（ PDM） 统称
为 DataArchitect,可以完成如下工作：
?可以使用 E-R图建立概念数据模型（ CDM）；
?可以针对特定的数据库管理系统生成物理数据模型（ PDM）；
?可以定制 PDM,以适应物理和性能上的考虑；
?可以生成目标数据库管理系统的建立数据库的脚本 (Script)；
?可以生成参照完整性触发器（如果目标数据库支持）；
?可以定制和打印模型的文档报告；
?可以对已经存在的数据库和应用实施逆向工程；
?可以为 PDM对象定义扩展属性。
44
使用 DataArchitect设计数据库的处理流程
?首先设计概念数据模型；
?接着由概念数据模型（ CDM） 生成初步的物理数
据模型（ PDM）；
?然后在生成的物理数据模型中完成物理数据库设
计；
?最后生成创建目标数据库的脚本甚至可以直接创
建目标数据库。
45
DataArchitect还可以完成逆向工程
?首先连接到目标数据库；
?接着由目标数据库生成物理数据模型；
?然后由物理数据模型生成概念数据模型。
46
概念数据库设计
?建立概念数据模型的常规操作包括：
?定义实体；
?定义实体的属性；
?定义联系。
47
用 CDM设计的概念模型
?疑问：
?连接属性？
?联系符号？
48
物理数据库设计
?在物理数据模型中可以定义如下内容：
?指定目标数据库；
?定义表；
?定义关键字；
?定义视图；
?定义列；
?定义域；
?定义约束规则；
?定义索引；
?定义触发器；
?定义参照联系；
?定义扩展属性。
49
根据 CDM生成的 PDM
50
建立数据库
?可以从物理数据模型可以生成创建目标数
据库的脚本文件（扩展名为,SQL的 SQL命
令文件）；
?也可以直接从物理数据模型创建目标数据
库。
51
客户 /服务器应用规划综述
? 可以量化的需求分析
? 性能需求
? 并发需求
? 数据分布需求
? 恢复需求
? 安全问题
? 系统需求
52
可以量化的需求分析（ 1）
站点的数量：
1.整个应用系统是否需要有一个中心服务器？
2.是否需要多台服务器？若是，是按部门划分还是按地理区域划分？
3.下一级服务器是否需要向上一级服务器传送 汇总数据？
4.各站点 间的需求是否会不一致？
事务的数量：
1.应用系统的事务有哪些？
2.每一个事务的复杂程度如何？
3.每一个事务的执行频率如何？
4.事务的峰值 会在每天的固定时间出现吗？
5.比较大且复杂的事务可以分解为数个小而简单的事务吗？
53
可以量化的需求分析（ 2）
数据特征：
⒈动态与静态数据
⒉数据的增长
⒊历史数据
用户的数量：
1.一共有多少用户？
2.在同一时刻最多会有多少用户连接到服务器？
3.这些用户执行事务的分布情况如何？会很集中吗？
4.用户是按照地理因素或部门因素平均分布的吗？
54
性能需求
事务的速度：
1.更新数据库的哪些事务是最复杂的？
2.复杂的事务可以分解为数个较简单的事务吗？
3.从 业务规则来看，哪些事务是最重要的？
4.哪些事务必须有最快的响应时间？
5.每类事务的时间峰值会发生在什么时间？
6.每类事务的数据量峰值是多少？
7.复杂的事务可以在非峰值时间段中运行吗？
查询速度：
1.哪些重要的查询需要有最快的响应时间？
2.是否可能让一些查询定时运行，特别是在非高峰的时间段内？
3.是否允许一些汇总数据以冗余方式保留在数据库中？
4.允许即席查询吗？
5.可否通过灵活的参数来建立结构化查询以便处理更多的查询？
6.可以 将即席查询限制在预定义的视图上吗？
7.哪些查询需要保证读一致性？
55
并发需求
1.某一应用程序的运行只发生在一天之中的某些时刻吗？
2.某一应用程序会在不同的站点同时运行吗？
3.会有一些应用程序出现“热点”或“瓶颈”现象吗？
56
数据分布需求
数据如何分布？如何利用复制功能完成数据分布管理？
57
恢复需求
1.在一次故障事件中，某个应用服务器可以承受多少数据损失？
2.某个服务器 可以为恢复数据而停止多长时间？
3.备份是自动控制还是由人工控制？
4.对服务器设备是否有物理的存取限制？
5.如何考虑备份的代价？
58
安全问题
建立正确的安全性级别和方案，是保证整个 SQL Server应用
成功的一个保障。太低的保密级别会使一些未经授权的操作者看
到敏感的数据；太严格的保密级别又会限制操作者完成正常的工
作，并可能会导致用户对应用程序、甚至对整个系统的不满意。
59
系统需求
硬件需求
网络需求
软件需求
具体的信息系统需求
60
【本章小节】
?正如本章的题目,数据库应用系统开发方法,，
这一章的内容介绍了规划、开发数据库应用项目
的方法。正确的方法是保证项目成功的基础，选
择合适的工具来支持项目的开发和设计也为项目
的成功提供了保证。读者在熟悉相关的理论的基
础上，也应该了解相应的建模工具和设计工具，
这可以加强我们对理论和方法的理解，也可以促
进我们的实践能力。
第 13章 数据库应用系统的开发方法
?结构化生命周期方法
?快速原型方法
?面向对象设计方法
?!!!!!
?客户 /服务器应用规划综述
2
结构化生命周期方法
?确定系统需求；
?系统开发；
?系统安装配置；
?系统运行；
?系统切换 。
1.系统调查及可行性分析 ；
2.系统分析（需求分析） ；
3.概要设计（总体设计） ；
4.详细设计（模块设计） ；
5.系统实现（编程） ；
6.系统调试与试运行（测试） ；
7.系统运行、评价与维护（运行） 。
3
开发的进度安排
?规划, 需求分析和设计约占 1/3；
?编程实现约占 1/6；
?测试约占 1/2。
4
系统调查和可行性分析
?这一阶段的任务是初步了解信息系统用户
的组织机构、业务范畴以及新系统的目标，
并且做出可行性分析，包括经济可行性、
技术可行性和使用可行性。
5
需求分析和信息采集
?准确、全面地采集 信息是数据库应用规划
和设计的必不可少的重要组成部分，要想
确保在数据库应用开发的各个阶段所做出
的重要决定都是明智和正确的，那么做好
这一步的工作就更加至关重要。
6
总体设计
?这一步的主要任务是把用户的信息要求统
一到一个整体的逻辑结构或概念模式中，
此结构能表达用户的要求，并且独立于任
何硬件和数据库管理系统。这一步，从应
用程序的角度来讲，要完成子系统的划分
和功能模块的划分；从数据库的角度来讲
要完成概念模型的设计。
7
详细设计
?这一步同样是包括数据库设计和应用程序
设计两大部分。对数据库设计要根据具体
的数据库管理系统设计数据库、设计关系、
考虑数据的完整性、考虑数据的安全和备
份策略等。对应用程序设计要给出功能模
块说明，考虑实施方法，设计存储过程等。
8
编程
?它根据上一步的设计结果进行具体实施，
建立数据库并装入原始数据，建立存储过
程，编写和调试应用程序代码等。
9
调试与试运行
?一般在编程阶段都做了局部测试，现在各
个子系统、各个模块要进行联合调试和测
试，并试运行。在试运行阶段要广泛听取
用户的意见，并根据运行效果进行评估，
修改系统的错误、改进系统的性能。
10
交给用户使用
?最后一步是将系统交给用户使用，在使用
的过程中可能还会出现新的问题，甚至提
出新的需求，所以还要不断对系统进行评
价和维护。数据库系统的维护不是一朝一
夕的事，只要数据库系统存在，就要不断
进行评价、调整、修改，直至数据库生命
周期结束，或完全重新设计为止。
11
快速原型方法
?所谓“原型”可以看作是“企业作业原型”
或“软件功能原型”，它基本反映了最终
系统的基本功能和基本特征，依此可以快
速开发一个可以演示的系统，用户可以在
这个原型系统中得到启发，发现存在的问
题，提出新的要求，并和开发人员一起修
正和发展原型。如此反复进行，最后形成
用户满意的系统。
12
快速原型开发方法可以分为四个步骤：
?系统基本需求的确定；
?对原型的功能选择；
?原型的构造与试用；
?原型的修改和完善。
13
面向对象方法
?面向对象（ Object Oriented） 方法的思想源
于面向对象程序设计。面向对象的分析方
法是从现实世界抽象出对象及发生在对象
上的事件，从而建立起数据对象和处理操
作之间的联系。而利用面向对象的开发工
具去实现面向对象的模型是一件很自然的
转换过程。
14
面向对象的分析和设计方法
?系统分析
?系统设计
?系统实施
15
系统分析
?和结构化生命周期法一样，在面向对象开发方法
过程中需求分析阶段的主要任务也是确定用户的
需求，面向对象的分析方法以现实世界的对象为
基础，注重现实世界对象的数据特征和行为特征，
虽然它在表述对象的数据需求和操作需求方面是
很自然的，但却没有想象的那么简单，还是需要
一定的经验，因为现实世界中的客观对象是五花
八门的，所以有时利用面向对象方法进行抽象可
能会有一定的困难。
16
系统分析
?抽象对象的过程可以由上向下，也可以由
下向上。所谓由上向下，就是首先抽象出
整个问题域中的所有对象，并以对象为基
础分析对象的数据需求和操作需求，然后
给出问题和解决问题过程的准确描述；而
所谓由下向上则是首先描述各个问题和解
决问题的过程，并从各个问题中抽象出对
象，然后将同类对象进行合并。
17
系统分析
?需求模型化是面向对象方法中最常用的方
法之一，它通过对需要解决的实际问题建
立业务模型来抽取对象、描述对象，从而
将用户的需求准确地表达出来。一般包括
对象模型, 动态行为模型 和 用界面模型 等。
18
对象模型
?对象模型是整个面向对象方法的基础，它
是整个系统的抽象，其中要描述用户需求
中的各个对象，及其对象的属性、可能处
于的各种状态以及可能的继承、集合等，
还要包括各个对象之间的相互关系等。
19
动态行为模型
?动态行为模型主要用来描述系统的一些动
态特征，如定义可能的系统事件和各实体
对各种事件的响应等。
20
用界面模型
?用户界面模型显然用来描述用户使用和操
作应用系统的界面，包括界面的外观和各
种具体的操作功能等，它可以使客户对未
来的系统首先建立一个感官的认识。
21
系统设计
?概要设计
?概要设计也称作总体设计，所以这一阶段的任
务是要将用户的需求统一到一个总体的逻辑结
构和概念模式中，要描述出与对象模型对应的
所有类，要描述类之间的相互关系和继承关系
等；同时要将动态行为模型中的操作、事件和
对事件的响应等体现在类中；在这个阶段还要
确定整个应用系统的结构框架和输入输出接口
等。
22
系统设计
?详细设计
?确定系统的具体实施方法。要对每个类进行细化、分
析、验证，要确定每个类的属性，要确定每个对象可
能出现的各种状态，要确定每个类将要支持的方法，
要确定每个方法的功能、参数和返回值等。
?在设计类时要充分考虑类的封装性、继承性和多态性。
要明确规定类和类内成员的访问权限；要充分分析类
之间的关系，特别是继承关系，使软件可重用性得到
充分体现；要仔细、严格设计和验证各种方法和函数，
保证系统描述的一致性。
23
系统实施
?通过选择一种合适的面向对象的开发工具
（如 PowerBuilder） 具体开发和实现经过仔
细设计的应用系统。在编程实现工作过程
中，肯定会发现在分析和设计阶段隐藏的
问题，这时则要及时地返回相关步骤进行
调整。
24
可能会失败！
25
认识问题
有些系统集成公司在项目的网络、硬件、系统软件等
方面都很有经验，也很成功，但当他们为用户开发软件时，
往往开始也踌躇满志，在经过一段时间后就显得力不从心
了，结果搞的焦头烂额。其原因是这些系统集成公司多是
一些硬件商或软件商的代理，对产品很了解，但是他们缺
少系统分析人员，对数据库项目的开发认识不足、了解甚
少，并且普遍轻视系统分析和系统设计工作，结果很难收
场，最后以失败告终。
26
方法问题
国内各种教科书对结构化生命周期方法介绍较多，这
种方法比较规范，国外成功的例子也很多。这种方法对需
求分析的结果要求很高，按规定需求分析所产生的系统说
明书将作为系统开发的技术合同，以后的工作按部就班地
进行就可以了。
如果照搬结构化生命周期方法开发国内的数据库项目
，多数情况下都不现实，往往按照技术合同开发的系统并
不是用户所需要的系统，其原因我们已经在前文中说明了
。结果是用户对开发的系统不认可、不验收；开发方以技
术合同为证指责用户。如果双方都不让步，则只能以失败
告终。
27
工具问题
有一些开发单位或开发人员，对数据库项目开发了解
甚少，经常称自己采用的是“快速原形方法”，但结果却
不快。程序是一条条编出来的，开发人员需要经常修改程
序和数据库结构，甚至推倒重来。这里面，一方面是忽视
了前期的分析和设计工作，没有构造出准确的原型；另一
方面是没有掌握快速的开发工具，靠手工完成大部分程序
。
由于缺少对开发数据库项目的整体认识，盲目采用
所谓快速原型方法，结果反而不快，搞的自己狼狈不堪。
28
管理问题
有些单位对开发一些简单的系统还可以胜任，在开发
大系统时，各独立的子系统也分别能正确运行。但是，这
些子系统却不能协同工作，数据共享差。另外，各子系统
的界面风格可能也相差甚远。之所以会这样，主要是项目
负责人或开发单位缺乏对整个项目的有效管理，开发人员
之间也缺乏有效的沟通和交流
29
数据库设计
?概念模型设计
?逻辑数据库设计
?规范化理论的应用
?物理数据库设计
30
概念模型设计
?概念模型设计是不依赖于任何数据库管理系统的，
它是对用户信息需求的归纳。概念设计的结果得
到的是数据库的概念结构，或称概念数据模型，
由于它是从现实世界的角度进行的抽象和描述，
所以与具体的硬件环境和软件环境均无关。
31
概念模型设计
?概念模型的设计或描述工具是 E-R图
?确定实体；
?确定实体的属性；
?确定实体的标识属性（关键字）；
?确定实体间的联系和联系类型；
?确定实现实体间联系的属性（外部关键字或连
接属性）；
?画出表示概念模型的 E-R图；
?确定属性间的依赖关系。
32
概念模型设计
?设计局部 E-R图
?将 局部 E-R图合并成全局 E-R图
?在不同的局部 E-R图中，表示相同事物的实体名和属性
名要统一，在合并 E-R图前先做此统一工作，要消除同
名异义和同义异名，这样可以有效避免不一致性和冗余。
?如果两个有相同意义的实体在一个局部 E-R图中存在着
一种联系，而在另一个局部 E-R图中存在着另一种不同
的联系，那么在合并时这两种联系都要保留下来，即在
两个实体之间，可能存在着两种不同的联系。
33
概念模型设计
?对合并后得到的整体概念数据模型进行必
要的审核和验证，以保证它的正确性和可
用性。审核或验证工作包括：
?整体概念模型内部必须具有一致性，不能有相
互矛盾的表述；
?整体概念模型必须能够准确反映原来的每个局
部模型的结构，包括实体、属性和联系等；
?整体概念模型必须能够满足需求分析阶段所确
定的所有要求，这一条实际蕴涵了以上两条。
34
逻辑数据库设计
?概念数据库设计是独立于数据库管理系统的，而
逻辑数据库设计却与具体的数据库管理系统有关。
?在逻辑数据库阶段首先要考虑实现数据库的数据
库管理系统所支持的数据模型是什么。
?在逻辑数据库设计阶段，我们首先将概念数据模
型转换为关系数据模型，即将 E-R图中的实体和
联系转换为关系模式。
?对关系数据库来说，逻辑数据库设计的结果是一
组关系模式，接着要应用关系规范理论对这些关
系模式进行规范化处理。
35
逻辑数据库设计阶段应该考虑
?确定各个关系模式的主关键字，考虑实体
完整性；
?确定各个关系模式的外部关键字，考虑参
照完整性；
?确定各个关系模式中属性的约束、规则和
默认值，考虑域完整性；
?根据用户需求设计视图；
?考虑安全方案和用户使用权限等。
36
规范化理论的应用
?运用规范化的标准（ 3NF,BCNF,4NF）
来检验目前所得到的关系模式是否达到了
规范化的要求，并对没有达到规范化要求
的关系模式进行模式分解。
37
物理数据库设计
?物理数据库设计的内容是设计数据库的存储结构
和物理实现方法。
?关系数据库的物理设计一般包括：
?估算数据库的数据存储量
?安排数据库的存储
?设计索引
?设计备份策略
38
数据库设计工具 PowerDesigner
?概念数据模型 （ Conceptual Data Model）
?物理数据模型 （ Physical Data Model）
?面向对象模型 （ Object-Oriented Model）
?业务处理模型 （ Business Process Model）
PowerDesigner的 数据库设计功能
39
概念数据模型设计
?概念数据模型建模工具，简称 CDM。 概念
数据模型由现实世界的数据对象构成，描
述系统的整体逻辑结构，它提供一种对企
业或商业活动中的数据进行形式化描述的
手段。
40
物理数据模型设计
?物理数据模型建模工具，简称 PDM。 物理
数据模型详细描述数据库的物理实现，需
要包括数据库实际物理实现的所有细节，
以及数据存取和数据存储的约束机制等。
41
面向对象模型
?面向对象模型建模工具，该工具可以建立与 UML
（ 统一建模语言）密切相关的面向对象模型，支
持：
?用例图（ Use case diagram）
?序列图（ Sequence diagram）
?类图（ Class diagram）
?构件图（ Component diagram）
?活动图（ Activity diagram）
?等 ……
42
业务处理模型
?业务处理模型建模工具 。 业务处理模型是
一种描述业务伙伴间业务逻辑和规则的概
念模型 。 该 模 型 使 用 图 说 明 处 理
（ Processes）, 数据流 （ Flows）, 消息
（ Messages） 和协作协议 （ Collaboration
Protocols） 之间的相互作用和关系 。
43
PowerDesigner的数据库设计功能
?概念数据模型（ CDM） 和物理数据模型（ PDM） 统称
为 DataArchitect,可以完成如下工作：
?可以使用 E-R图建立概念数据模型（ CDM）；
?可以针对特定的数据库管理系统生成物理数据模型（ PDM）；
?可以定制 PDM,以适应物理和性能上的考虑；
?可以生成目标数据库管理系统的建立数据库的脚本 (Script)；
?可以生成参照完整性触发器（如果目标数据库支持）；
?可以定制和打印模型的文档报告；
?可以对已经存在的数据库和应用实施逆向工程；
?可以为 PDM对象定义扩展属性。
44
使用 DataArchitect设计数据库的处理流程
?首先设计概念数据模型；
?接着由概念数据模型（ CDM） 生成初步的物理数
据模型（ PDM）；
?然后在生成的物理数据模型中完成物理数据库设
计；
?最后生成创建目标数据库的脚本甚至可以直接创
建目标数据库。
45
DataArchitect还可以完成逆向工程
?首先连接到目标数据库；
?接着由目标数据库生成物理数据模型；
?然后由物理数据模型生成概念数据模型。
46
概念数据库设计
?建立概念数据模型的常规操作包括：
?定义实体；
?定义实体的属性；
?定义联系。
47
用 CDM设计的概念模型
?疑问：
?连接属性？
?联系符号？
48
物理数据库设计
?在物理数据模型中可以定义如下内容：
?指定目标数据库；
?定义表；
?定义关键字；
?定义视图；
?定义列；
?定义域；
?定义约束规则；
?定义索引；
?定义触发器；
?定义参照联系；
?定义扩展属性。
49
根据 CDM生成的 PDM
50
建立数据库
?可以从物理数据模型可以生成创建目标数
据库的脚本文件（扩展名为,SQL的 SQL命
令文件）；
?也可以直接从物理数据模型创建目标数据
库。
51
客户 /服务器应用规划综述
? 可以量化的需求分析
? 性能需求
? 并发需求
? 数据分布需求
? 恢复需求
? 安全问题
? 系统需求
52
可以量化的需求分析（ 1）
站点的数量：
1.整个应用系统是否需要有一个中心服务器？
2.是否需要多台服务器？若是，是按部门划分还是按地理区域划分？
3.下一级服务器是否需要向上一级服务器传送 汇总数据？
4.各站点 间的需求是否会不一致？
事务的数量：
1.应用系统的事务有哪些？
2.每一个事务的复杂程度如何？
3.每一个事务的执行频率如何？
4.事务的峰值 会在每天的固定时间出现吗？
5.比较大且复杂的事务可以分解为数个小而简单的事务吗？
53
可以量化的需求分析（ 2）
数据特征：
⒈动态与静态数据
⒉数据的增长
⒊历史数据
用户的数量：
1.一共有多少用户？
2.在同一时刻最多会有多少用户连接到服务器？
3.这些用户执行事务的分布情况如何？会很集中吗？
4.用户是按照地理因素或部门因素平均分布的吗？
54
性能需求
事务的速度：
1.更新数据库的哪些事务是最复杂的？
2.复杂的事务可以分解为数个较简单的事务吗？
3.从 业务规则来看，哪些事务是最重要的？
4.哪些事务必须有最快的响应时间？
5.每类事务的时间峰值会发生在什么时间？
6.每类事务的数据量峰值是多少？
7.复杂的事务可以在非峰值时间段中运行吗？
查询速度：
1.哪些重要的查询需要有最快的响应时间？
2.是否可能让一些查询定时运行，特别是在非高峰的时间段内？
3.是否允许一些汇总数据以冗余方式保留在数据库中？
4.允许即席查询吗？
5.可否通过灵活的参数来建立结构化查询以便处理更多的查询？
6.可以 将即席查询限制在预定义的视图上吗？
7.哪些查询需要保证读一致性？
55
并发需求
1.某一应用程序的运行只发生在一天之中的某些时刻吗？
2.某一应用程序会在不同的站点同时运行吗？
3.会有一些应用程序出现“热点”或“瓶颈”现象吗？
56
数据分布需求
数据如何分布？如何利用复制功能完成数据分布管理？
57
恢复需求
1.在一次故障事件中，某个应用服务器可以承受多少数据损失？
2.某个服务器 可以为恢复数据而停止多长时间？
3.备份是自动控制还是由人工控制？
4.对服务器设备是否有物理的存取限制？
5.如何考虑备份的代价？
58
安全问题
建立正确的安全性级别和方案，是保证整个 SQL Server应用
成功的一个保障。太低的保密级别会使一些未经授权的操作者看
到敏感的数据；太严格的保密级别又会限制操作者完成正常的工
作，并可能会导致用户对应用程序、甚至对整个系统的不满意。
59
系统需求
硬件需求
网络需求
软件需求
具体的信息系统需求
60
【本章小节】
?正如本章的题目,数据库应用系统开发方法,，
这一章的内容介绍了规划、开发数据库应用项目
的方法。正确的方法是保证项目成功的基础，选
择合适的工具来支持项目的开发和设计也为项目
的成功提供了保证。读者在熟悉相关的理论的基
础上，也应该了解相应的建模工具和设计工具，
这可以加强我们对理论和方法的理解，也可以促
进我们的实践能力。
