第一章 数据库应用系统开发方法
概述
数据库应用系统
术语 | 英文缩写 | 含义 |
---|---|---|
数据库系统 | DBS | 数据的组织,存储,访问等数据管理功能 |
数据库应用系统 | DBAS | 数据管理之外,通过数据库应用程序的数据处理功能 |
数据库应用系统设计与开发 | 设计应用数据在数据库中的组织与存储方式,即设计数据库的模式或结构,并设计数据库应用软件 |
数据库应用系统生命周期
软件工程与软件开发方法
模型方法 | 提出 | 简述 |
---|---|---|
瀑布模型 | 20世纪70年代初期 Winston Royce | 文档驱动,强调阶段工作完备性 |
快速原型模型 | 20世纪80年代中期随第四代语言及可视化开发工具产生 | 不必把前期各阶段的活动做得尽善尽美后才启动下阶段的活动 |
螺旋模型 | 1988年 Barry Boehm | 前两者的系统化、可修改性结合,引入风险评估u |
瀑布模型
文档驱动,强调阶段工作完备性。
阶段 | 简述 |
---|---|
项目规划 | 定义开发项目的背景,目标等,包括制订合理的项目开发计划 |
系统分析 | 全面理解系统需求,并以之叙述项目目标、功能等,以及数据的安全性、正确性、有效性等要求 |
总体设计 | 将前一阶段的需求转换成能够实现的软件框架以及系统结构 |
详细设计 | 细化总体设计的结果,包括确定每个模块的算法、结合具体的开发环境设计输入/输出的页面等 |
编码调试与集成测试 | 用程序设计语言描述每个模块的求解步骤,通过单元测试后,组装或集成到软件框架中进行集成测试 |
运行维护 |
快速原型模型
不必把前期各阶段的活动做得尽善尽美后才启动下阶段的活动
阶段 | 简述 |
---|---|
快速分析 | 调研分析,确定目标系统的功能,页面特点和性能需求,编写基本需求说明书 |
设计构造原型 | 利用可视化集成开发工具快速构建一个可运行的初始系统 |
运行原型 | 对原型系统进行操作,通过实际操作理解系统,并发现问题 |
评价原型 | 确认系统存在的问题,并 提出改进意见,补充缺失需求和因幻境变化,需求变动引发的新需求 |
改进原型 | 根据修改意见和修改方案,重构及修改原型系统 |
重复阶段3到阶段5,直到系统满足需求,修改迭代结束
螺旋模型
将瀑布模型的系统化与快速原型模型的可修改性结合起来,引入了风险评估活动,采用“演化”的概念开发系统。
模型对开发人员评估风险的经验要求较高。
象限 | 简述 |
---|---|
项目规划 | 确定系统功能和性能目标,选择可行的实施方案 |
风险评估 | 风险评估,识别和评估风险 |
工程实现 | 通过实施活动,将软件需求转化为软件产品 |
用户评估 | 评价实现结果 |
从项目规划开始,到风险评估,如果风险可以消除或承受,即进入实现阶段,最后,评价实现结果,并规划下一开发阶段,开发过程每经过一个迭代周期,螺旋线就增加一圈。
软件特征:可修改性,有效性,可靠性,可理解性,可维护性,可重用性,可适应性,可移植性,可追踪性,可互操作性。
DBAS生命周期模型
数据库应用系统
基本活动 | 简述 |
---|---|
项目规划 | 规划与分析 |
需求分析 | 数据项分析,数据流与事务分析,需求分析 性能/存储/安全需求 |
系统设计 | 概念设计,逻辑设计,物理设计 |
实现与部署 | 系统实现,数据转换与加载,系统测试、部署与交付,构造模型(可选) |
运行与维护 | 系统运行维护 |
三条主线
设计主线 | 对象 |
---|---|
数据组织与存储 | 数据库 |
数据访问与处理 | 数据库事务 |
应用程序 | 应用程序 |
系统设计
设计步骤 | 简述 |
---|---|
概念模型设计 | 系统概要设计-总体设计 |
逻辑结构设计 | 事务概要设计,应用程序概要设计 |
物理结构设计 | 事务详细设计,应用程序详细设计 |
规划与分析
工作内容如下:
系统规划与定义
任务内容 | 简述 |
---|---|
任务陈述 | 描述所要开发的DBAS的总体目标 |
确定任务目标 | 明确DBAS应该支持的数据管理与处理任务与活动 |
确定系统范围和边界 | 定义DBAS做什么,不做什么,做到什么程度,是后续开发步骤的设计依据,明确软件范围 |
确定用户视图 | 根据存取需求对用户进行分类,组成用户对应的用户视图 |
软件范围:一个软件应该实现的功能、性能边界;
用户视图:表示不同DBAS用户的数据访问/处理需求。
可行性分析
经济可行性
成本 | 简述 |
---|---|
系统软硬件购置费用 | DBMS、计算机、存储设备、网络设备的购置费用 |
系统开发费用 | 人工费用、材料费用、培训费用 |
系统安装、运行、维护费用 |
技术可行性
- 技术可行性研究:根据用户提出的系统功能、性能及实现系统的各项约束条件、对系统软硬件和技术方案做出评估和选择建议。
- 硬件可行性研究:分析DBAS的硬件平台环境和设备,提出硬件选型建议。
- 软件可行性研究:包括对可用的DBMS和操作系统的选型评估和建议、对中间件和开发环境的选型建议、对数据库应用程序开发模式和编程语言的建议。
- 技术方案的选择:根据系统技术需求,提出DBAS可能采用的合理技术方案或关键技术。例如DBAS体系结构,从集中式、分布式、客户/服务器结构、并行结构、web结构等几种方案中选择。
操作可行性
操作可行性研究:论证是否具备DBAS开发所需的各类人员资源、软件资源、硬件资源和工作环境等,以及如何改进加强上述资源。
人员资源:项目管理人员、数据库系统分析员、应用编程人员。
开发方案选择
提出并评价实现系统的各种开发方案,从中选出一种适用于DBAS软件的开发方案。
例如考虑DBAS软件开发模型时,可以选择瀑布模型、快速原型模型、螺旋模型、也可以选用DBAS生命周期模型;亦可根据实际情况进行委托开发。
完成上述可行性分析后应生成相应的数据库应用系统开发可行性研究报告。
项目规划
项目规划:项目管理者对资源、成本和进度做出合理估算,并在此基础上制订切实可行的DBAS项目开发计划的过程。
- 确定项目的目标和范围,具体说明项目的最终产品以及期望的时间,成本和质量目标。
- 根据DBAS软件开发模型,分解和定义整个项目包括的工作活动和任务。
- 估算完成项目规模及所需资源。
- 制订合理的DBAS项目计划,包括进度、成本、质量等方面的预测和控制方案。
完成项目规划时应形成数据库应用系统项目计划文档,即项目计划书。
需求分析
数据库应用系统需求:用户在对DBAS在功能、性能、行为、设计约束等方面的期望和要求,即希望DBAS做什么,做到什么程度等具体要求。
DBAS需求分析:在明确DBAS系统范围的基础上,系统描述DBAS功能特征、性能特征和约束,并形成需求规范说明文档。
上述文档称为DBAS需求分析规范说明书,是DBAS设计和测试阶段的重要依据。
需求分析过程:需求获取-需求分析-需求描述-规范说明-需求验证。
对比项 | 一般的软件系统 | DBAS |
---|---|---|
系统需求 | 功能需求和非功能需求 | 与数据处理密切相关的功能需求与业务规则需求 |
非功能需求 | 性能需求与其他需求 | |
其他 | 需要将数据需求或信息需求独立出来进行分析 |
与普通的软件系统需求分析一样,对DBAS系统的需求同样需要对性能需求以及存储、安全等方面进行分析,也需要对性能需求以及存储、安全等方面进行分析。
需求获取是DBAS系统分析人员的职责。
数据需求分析
数据需求分析是指从对数据进行组织与存储的角度,从用户视图出发,分析与辨识应用领域所管理的各类数据项(Data Items)和数据结构,形成数据字典的主要内容。
数据字典包括数据项、数据结构、数据流、数据存储、处理过程五部分。
数据项:数据的最小组成单位
数据结构:由若干数据项组成。
数据字典通过对前两者的定义描述数据流和数据存储的逻辑内容。
功能需求分析
主要针对DBAS应具有的功能进行分析,是DBAS需求分析的核心内容
数据处理需求分析
数据处理需求分析从数据访问和处理的角度,明确对各类数据项所需进行的数据访问操作。
结果可表示为数据流图(DFD)或事务规范。
-
数据流图:一种形式化的数据需求分析技术,利用数据项、数据存储、数据加工和数据流等概念描述对数据的处理。详见第二章。
-
事务规范:包括事务名称、事务描述、事务所访问的数据项、事务用户。
事务描述:指对事务功能、性能、完整性约束等方面的描述。
事务用户:指启动该事务执行的事件用户。
另外,可根据各类用户的用户视图进行数据及数据处理需求分析,即采用多视点、多角度的数据及数据处理分析技术。
结果可构成数据字典文档,亦称为“数据规范说明书”,作为下一步开展系统设计的主要输入文档。
业务规则需求分析
与数据访问无直接关系的其他功能。
应用领域业务规则,亦称业务处理逻辑,业务逻辑,描述应用领域中的业务功能、处理流程和步骤。业务规则需求反映了应用程序的功能、性能需求。
业务规则需求分析:分析系统或系统中一些大粒度子系统所具有的业务类型和功能,明确用户或外部系统与DBAS的交互模式。
业务规则需求分析主要涉及系统的外部行为,也包括某些系统内部关键特性,主要面向系统开发者。
分析对象既可以是与数据管理有关的业务规则,也可以是与数据库完全无关的系统业务(系统采用的人机交互模式)。
结果的表示:
- 自然语言
- UML。见第五章
- 某种特定领域相关的形式化、半形式化描述机制。
性能需求分析
功能需求描述了一个系统应当做什么。
性能需求描述系统应当做到什么程度。
DBAS的性能指标:
性能指标 | 简述 |
---|---|
数据操作响应时间 | 或数据访问相应时间。用户向系统提交数据操作请求到结果返回所需时间。 |
系统吞吐量 | 系统在单位时间内可以完成的数据库事务或数据查询的数量。可表示为每秒事务数TPS。 |
允许并发访问的最大用户数 | 保证单个用户查询相应时间的前提下,系统最多允许多少用户同时访问数据库。 |
每TPS代价值 | 用于衡量系统性价比的指标。 |
DBAS的性能指标是系统软硬件设计开发的重要依据。
影响DBAS性能的主要因素:
主要因素 | 简述 |
---|---|
系统硬件资源 | 如CPU数量与速度,I/O系统容量与速度,内存大小,内存缓冲区大小 |
网络通信设备功能 | 网络带宽、连接速度、数据传输速度等。 |
操作系统环境 | 对并发进程的支持程度、文件子系统和I/0子系统的性能等 |
数据库的逻辑设计和物理设计质量 | 关系数据库中好的关系模式结构、合理的数据库存储组织和存取路径,数据库配置参数等 |
DBMS的配置和性能 | DBMS采用的查询优化策略,索引优化策略、数据库管理配置参数等 |
数据库应用程序自身 | 程序中的事务机制、并发控制机制的使用方法、程序质量等。 |
数据库配置参数:数据库存储空间大小等。
数据库管理配置参数:内存配置选项、I/O配置选项、数据库缓冲区配置选项等。
其他需求分析
-
存储需求分析。
存储需求分析是指DBAS系统需要的数据存储量,如DB所存储的数据总量。包括:
- 初始数据库大小。DBAS刚投入运行时的数据总量。
- 数据库增长速度,运行过程中DB内数据量的变化情况(增加、减小)。
数据存储总量估算的基本方法:估计每个数据项所需空间(以byte为单位),进而估计一组数据项或一个元组所需的总数据项,以及数据项和元组的变化速度。以之计算一段时间(如数据保存期)内所需的数据存储总量。但该总量仅为数据存储空间,计算实际存储空间值还应考虑操作系统空间,DBMS空间,预留空间等。
-
安全性需求分析。
-
DBAS系统应达到的安全控制级别。依照可信(Trusted)计算机系统评测标准。数据安全性要求不高的一般场合,可定位为C级,如C2级;如果应用于军队、政府部门等高保密场合,可将级别定位为B级。
DBAS的整体安全性级别取决于DBMS、操作系统和其他系统软件的安全级别。上述软件的安全级别必须相互匹配。
-
各类用户的数据视图与数据访问权限。规定各类用户允许访问的数据库数据(用户的数据视图)以及对这些数据的访问权限(查询、插入、删除、修改等)。
-
DBAS应有的口令保护机制及其他的安全认证机制。用以控制用户登录数据库系统。
-
-
备份和恢复需求分析。
从数据库系统可靠性和系统故障恢复程度提出的系统需求。
- DBAS运行过程中备份数据库的时间和备份周期。
- 所需备份的数据是全部数据库数据(包括应用数据、索引、日志等),还是其中的一部分。
- 备份方式是采用完全备份还是差异备份。
需求分析及功能建模方法详见第2章。
系统设计
概念设计
概念模型设计
概念模型设计是指根据需求规范说明文档,分析辨识各类应用领域数据对象的特征及相互间的关联关系,并采用概念数据模型表示出来,得到独立于具体DBMS的数据库概念模型。
数据库概念模型可能采用多种方法表示,最常见的是ER方法。
系统总体设计
设计上应依据自上而下、由简到繁、逐步求精的原则。
作为DBAS应用设计主线的第一步,系统总体设计确定DBAS软硬件总体框架,作为系统后续设计活动的基础。
内容:
- DBAS体系结构设计。
- DBAS系统硬件平台的选型和配置。操作系统、数据库管理系统等系统软件的选型和配置。
- 应用软件结构设计。将应用软件划分为一系列软件子系统,定义子系统之间的信息交互方式;进一步划分各软件子系统的模块结构。以上工作可看作系统概要设计,为应用软件概要设计工作的第一部分内容。
- 对业务规则进行初步设计,细化业务规则流程,分析所处理的业务数据和处理方式,明确采用的关键技术和算法。
- 对系统采用的关键技术进行方案选型和初步设计。
逻辑设计
数据库逻辑结构设计
数据库逻辑结构设计是指从数据库的概念模型出发,设计表示为逻辑模式的数据逻辑结构。
逻辑结构设计于DBMS采用的数据模型密切相关,如关系模型、层次模型、网状模型,但与具体的DBMS系统实现无关。
数据库逻辑结构设计的主要内容是在ER图的基础上设计数据库关系模式。ER图是数据库概念模型密切相关。
应用程序概念设计
在应用软件结构设计基础上,将DBAS的应用软件模块按照逐步求精、信息隐藏和功能细化原则,进一步划分为子模块,组成应用软件的系统-子系统-模块-子模块层次结构,其中将直接访问数据库的模块/子模块抽象为数据库事务;确定各模块的功能和输入/输出数据,设计模块使用的数据结构,定义模块交互的接口关系和交互流程。
数据库事务概要设计
事务概要设计的任务是根据需求分析阶段识别出的各种DBAS事务,设计与具体DBMS和实现方法无关的事务数据处理流程,明确各事务所访问的各关系表。
把事务中对数据库数据的查询、插入、删除、修改操作同具体DBMS无关的两个元操作read,write来抽象表示。
物理设计
数据库物理结构设计
在具体的硬件环境、操作系统和DBMS约束下,为数据库的逻辑结构设计符合应用要求的物理结构的过程,就是数据库物理结构设计。
其目标是设计一个占用存储空间少、具有较高访问效率和较低的维护代价的数据库存储模式。
包括数据库逻辑模式调整、文件组织与存取设计、数据分布设计、安全模式设计、确定系统配置、物理模式评估。
数据库事务详细设计
根据事务概要设计的得出的与平台无关的事务流程,利用SQL语句、数据库访问接口(如JDBC,ODBC或其他DBMS的特定API),采用高级程序设计语言或DBMS提供的事务实现机制,在具体DBMS平台和开发环境下,设计数据库事务。
将事务概要设计中的read和write元操作替换为DBMS支持的查询、插入、删除、修改等具体数据访问操作或数据库访问API调用。详见第4章。
应用程序详细设计
设计各模块的内部处理流程和算法、数据结构、对外详细接口等。详见第4章。
实现与部署
DBAS的实现与部署也称DBAS的实施。
数据库应用系统开发人员需要根据DBAS设计结果,建立数据库,编写应用程序,集成DBAS软硬件,组成完整的DBAS。
包括以下内容:
- 建立数据库结构
- 数据加载
- 事务和应用程序的编码及测试
- 系统集成、测试与试运行。
- 系统部署
运行管理与维护
数据库应用系统投入运行标志着系统开发任务的基本完成和系统运行维护工作的开始。包括数据库应用系统的运行管理以及对数据库本身的运行管理。
DBAS的运行管理与维护是其生命周期过程中的一个重要组成部分。
应用案例需求
习题
DBAS可行性分析主要包括经济可行性、技术可行性、操作可行性、开发方案选择。
DBAS中的功能需求分析总体上可分为数据处理需求分析、业务规则需求分析
DBAS的概念设计包括数据库概念模型设计和系统总体设计
DBAS的逻辑设计包括数据库逻辑结构设计和应用程序概要设计
DBAS的物理设计包括数据库物理结构设计和数据库事务详细设计
编码及测试
- 系统集成、测试与试运行。
- 系统部署
运行管理与维护
数据库应用系统投入运行标志着系统开发任务的基本完成和系统运行维护工作的开始。包括数据库应用系统的运行管理以及对数据库本身的运行管理。
[外链图片转存中…(img-r4345ik5-1611397160597)]
DBAS的运行管理与维护是其生命周期过程中的一个重要组成部分。
应用案例需求
习题
DBAS可行性分析主要包括经济可行性、技术可行性、操作可行性、开发方案选择。
DBAS中的功能需求分析总体上可分为数据处理需求分析、业务规则需求分析
DBAS的概念设计包括数据库概念模型设计和系统总体设计
DBAS的逻辑设计包括数据库逻辑结构设计和应用程序概要设计
DBAS的物理设计包括数据库物理结构设计和数据库事务详细设计