东北大学,数据库开发技术,课件,第2章数据库应用系统开发过程.ppt

第2章 数据库应用系统开发过程 数据库工程概述 项目视图与范围 需求分析和需求定义 数据库设计 软件体系结构设计 详细设计和编码实现 测试 发布和实施 快速原型技术的应用 2.1 数据库工程概述 数据库应用系统的开发是一项复杂的软件工程，但又 有其自身的一些特点，因此，特称为“数据库工程” 。 数据库工程按其内容可分为两个部分 数据库的设计实现。数据库的设计实现是开 发数据库应用系统的核心工作 应用程序的设计实现。应用程序设计实现本 身也是一项软件工程，但与数据库的设计实 现紧密相关。 数据库应用系统从开始规划、分析、设计、实现、测 试、运行、维护到系统退役的整个过程称为数据库应 用系统的生存期 2.1 数据库工程概述 数据库工程主要包括以下步骤或开发阶段： 规划阶段，建立项目视图与范围 需求分析和需求定义 数据库概念结构设计 数据库逻辑结构设计 在DBMS中实施数据库逻辑结构和物理结构设计 应用程序的概要设计 应用程序的详细设计和编码实现 数据库、应用程序和系统集成测试 设计数据库的索引等物理结构 制作应用程序安装程序 规划整个数据库应用系统在用户环境中的实施方案 制订数据库应用系统的常规维护活动计划 2.2 项目视图与范围 2.2.1 项目视图和范围的概念和用途 项目视图可以把项目参与者（开发者和用户双方）定 位到一个共同和明确的目标上，项目视图描述了软件 产品所涉及到的和在一个理想环境中最终所应具有的 功能。 项目范围描述软件产品应包括的功能和不包括在内的 功能，范围描述在应包括和不包括在内的功能之间划 清了界限，同时确定项目的局限性。 项目的业务需求分析是在项目视图和范围描述的基础 上进行的，因此，一定要在业务需求分析之前完成项 目视图和范围的蓝图。如果不能清楚地标识项目的视 图和范围，业务需求可能会无边无际，最终导致无法 完成整个软件系统。 2.2.2 项目视图和范围的规格说明模板 1 业务需求 1.1 背景 1.2 业务机遇 1.3 业务目标 1.4 客户或市场需求 1.5 提供给客户的价值 1.6 业务风险 2 项目视图的解决方案 2.1 项目视图的陈述 2.2 主要特性 2.3 假设和环境依赖 3 范围和局限性 3.1 首次发行的范围 3.2 随后发行的范围 3.3 局限性和专用性 4 业务环境 4.1 客户概貌 4.2 项目优先级 5 产品成功的因素 2.2.3 有关项目视图和范围的一些建议 v如果在项目视图与范围规格说明中还不能澄清软件的开 发范围以及系统和外部的界限，建议使用关联图进一步 描述系统和外部的关系。 v项目视图和范围文档可以帮助开发者和用户代表判断所 提出的特性和需求放进项目中是否合适。 如果建议在项目范围之外，应重新协商项目费用、项 目计划，并考虑相关的资源与技术等是否能够实现新 的需求，在需求变更得到双方赞同后才能重新开始。 如果建议在项目范围之内，应分析该建议相关的需求 在项目中的优先级别，根据分析结果更改项目优先级 安排和项目开发计划。 v应该牢记，项目开发过程中应始终把注意力集中在项目 视图和范围的规格定义上，需求变更时应标识出项目视 图和范围的变更。 2.3 需求分析和需求定义 需求分析规格说明是项目开发过程中后续工作的参考基础，数 据库设计、系统结构设计、编码实现、测试和产品交付时都需 要以需求分析规格说明为参考依据。需求规格说明也是需求变 更的重要依据。 需求分析越清楚，设计和维护工作就越轻松，在未澄清关键需 求之前请不要急于系统结构设计、界面设计和编码实现。 推荐的需求分析过程 需求准备 从轮廓到细节逐步获取用户需求 需求整理和分析，确定关键需求 编写需求分析规格说明书 对需求进行验证核实 划分出明确的需求和模糊的需求 2.3.1 需求准备 了解项目或系统所涉及到的领域知识 编写简要的项目术语参考手册 确定需求分析过程，明确需求目标 将用户群分类并归纳各自特点 确定每类用户的代表 确定需求决策者 编写项目视图和范围的文档 2.3.2 从轮廓到细节逐步获取用户需求 v 从各用户代表处获取业务实例。业务实例有助于详细 了解业务的细节和用户的真正需求 v 召开需求讨论会议。这是获取需求的一种方法，在需 求获取过程中可能需要多次需求讨论会议，以便不断 了解用户需求 v 分析业务的工作流程。最好用示意图的方式表示出来 。编制业务的工作流程有助于明确系统的使用实例和 功能需求 v 确定质量特性和其他非功能的需求 v 综合用户需求，进一步完善需求分析 2.3.3 需求整理和分析 绘制系统关联图，定义系统与外部实体之间的界限和 接口，明确两者间的信息流和物质流。 创建用户界面原型。当开发人员或用户不能明确需求 时，最好的办法是开发一个用户界面原型。 分析需求的可行性。 建立需求的表示模型。使用图表分析模型来表示需求 是比较好的方法，也是对文字描述最好的补充说明。 创建数据字典，定义系统中系统的所有数据项和数据 结构。 明确用户功能需求的等级：期望需求、普通需求和兴 奋需求，有助于建立开发优先级和需求的重要等级。 2.3.4 编写需求分析规格说明书 使用标准模板编写需求分析规格说明书。 指明各需求项的来源。 标识需求定义，为各项需求标注上唯一的标号 记录业务规范。业务规范是指产品的操作原则或操作要 求。 创建需求跟踪表。需求跟踪表是为了将各项需求与实现 、测试它的设计和代码部分联系起来，这样有助于需求 变更时能够同时标识并修改相应的内容，获得一致的版 本。 2.3.5 需求验证 审查需求规格说明文档 以需求为依据编写功能测试用例 编写用户手册 确定产品或项目的验收标准 2.3.6 软件需求规格说明模板 1 引言 1.1 目的 1.2 文档约定 1.3 预期的读者和阅读建议 1.4 产品范围 1.5 参考文献 2 综合描述 2.1 产品的前景 2.2 产品的功能 2.3 用户类及其特征 2.4 运行环境 2.5 设计和实现上的限制 2.6 假设和依赖 3 外部接口需求 3.1 用户界面 3.2 硬件接口 3.3 软件接口 3.4 通信接口 4 系统特性 4.1 说明和优先级 4.2 激励/响应序列 4.3 功能需求 5 其他非功能需求 5.1 性能需求 5.2 安全设施需求 5.3 安全性需求 5.4 软件质量属性 5.5 业务规则 5.6 用户文档 6 其他需求 附录A：词汇表 附录B：分析模型 附录C：待确定问题的列表 2.4 数据库设计 数据库设计是数据库应用系统开发的核心任务。 数据库设计的好坏直接影响整个系统的质量，比较极 端的说法是，只要设计的数据库能够很好地完成业务 的数据管理和操作需求，那么就已经保证整个数据库 应用系统的质量。 如果数据库设计得有问题，则无论客户端应用程序开 发技术多么高明，花费再多的成本也无法构建出一个 好的数据库应用系统来。 应反复斟酌和验证数据库结构，确保数据库设计能够 满足业务的数据管理需求才能进行后一阶段的开发工 作。 2.4.1 数据库设计过程和设计基础 数据库设计过程主要包括以下步骤: 概念结构设计。概念结构设计一定要抛开平台约束 ，将注意力集中在业务数据的表示上。 逻辑结构设计。 针对具体的DBMS，实现数据库逻辑结构设计。应充 分利用DBMS提供的实现功能，尽量减少编码实现数 据库完整性约束的工作量。 物理结构设计和实现。应充分理解DBMS的存储和索 引技术再决定如何存储数据，如何设计索引等。 装载数据，测试数据库的运行状况。 压力测试和性能测试等 要想设计出性能优秀的数据库，必须掌握数据库设计 的基本原理知识和DBMS的应用技能 2.4.2 数据库设计规格说明模板 1 引言 1.1 编写目的 1.2 设计背景 1.3 定义 1.4 参考资料 2 外部设计 2.1 标识符和状态 2.2 使用它的程序 2.3 约定, 专门指导 2.4 支持软件 3 结构设计 3.1 概念结构设计 3.2 逻辑结构设计 3.3 物理结构设计 4 运用设计 4.1 数据字典设计 4.2 安全保密设计 2.4.3 数据库设计的一些建议 概念结构设计的重要性 不要因问题简单而忽视概念结构设计，除非你的理解力和记忆 力足够好。没有概念结构设计，无法直接跟踪和验证设计是否 满足业务需求。 概念结构设计的好坏直接影响逻辑结构设计的工作量。 某些数据库概念结构设计CASE工具不能反映真正的业务对象， 不能过份迷信CASE工具 设计概念模型最重要的是勾画出数据对象间的关系 未完整验证概念模型之前，不要急于开始下一步 标识业务规则 业务规则是保证数据完整性的约束，是逻辑结构设计、完整性 约束实现和事务实现的重要参考 业务规则应该是涉及到数据完整性问题的功能需求 2.4.3 数据库设计的一些建议 数据库逻辑结构设计 设计出与DBMS平台无关的数据库逻辑结构是最佳的 设计，这将有助于数据库的移植。 数据库的关系模式最低要求应满足3NF，而且应尽 量减少关系和字段的冗余，这是设计数据库的基本 准则。但在实际数据库工程中，还应考虑客户端应 用程序开发的问题，并非规划化程度越高的数据库 就一定是高质量的数据库。 验证逻辑结构是否满足业务数据管理的需求 2.4.3 数据库设计的一些建议 参考数据表 在设计数据库逻辑结构时，某些数据对象具有相似的逻辑结构 ，并且这些数据对象的用途也相似，例如职务类别、学历类别 、政治面貌类别等数据对象。这些数据对象通常用来作为其它 数据对象的分类属性，分析概念模型时通常是某一个实体的一 个属性。 为了便于管理维护这些参考数据，同时也为了减少数据库中表 的大小，在设计数据库的逻辑结构时，可将数据库中存在的各 种参考数据都单独设计为一个表。所有参考数据表都由两个字 段构成：编号和名称。 使用参考数据编号字段来替换数据库中所有表的参考数据字段 ，这样表之间就建立起了参照关系（主码外码的关系）。应将 这类参照关系设置为禁止级联删除、级联修改，或在代码中保 证这样的参照关系。 2.4.3 数据库设计的一些建议 数据完整性 业务规则在数据库中通过实施数据完整性来实现。 数据完整性的层次分为字段级、表级和数据库级三种，按照 实现方式相应地可称为域约束、表约束和断言实现。 字段级数据完整性指一条数据记录（或实体）中，字段的取 值、不同字段值之间应满足的约束条件 表级数据完整性指表（或关系）中某些字段的取值约束，通 常指候选码和外码约束。候选码约束实现时采用主码和唯一 约束来实现 断言实现数据库级的约束，通常这类约束不能使用上述约束 实现机制完成 设计实现数据库完整性时，应根据业务规则列表建立完整性 约束标识列表，在列表中清楚地描述完整性约束表达式或规 则，标识出实现约束的方式 2.4.3 数据库设计的一些建议 视图、存储过程和事务 数据库应用系统的业务需求规格说明中部分业务功 能是用户查询和操作数据库的数据，对于这类业务 功能，应在数据库中设计相应的视图或存储过程来 实现。返回数据集的存储过程也可以当做视图来使 用。存储过程能够实现相当复杂的数据操作功能， 尤其是事务类型的业务功能。 即使所采用的DBMS未提供视图或存储过程机制，在 设计数据库时也应标识出用户视图和事务（也可以 在业务规则中标识事务），这将有助于数据库应用 程序的开发。从极端角度来看，数据库应用程序是 数据库的子模式，应用程序是用户视图的表现。 2.4.3 数据库设计的一些建议 拙劣的设计 能工作的数据库也可能是一个拙劣的数据库设计。 能工作仅仅是数据库设计的最低评价指标。 此表亦彼表，也就是说将业务需求分析中获得的报 表格式直接当做数据库中的表，这是最拙劣的设计 从报表或电子表格的角度处理数据。必须以数据库 的观念查询和更新数据，才能保证设计出比较好的 数据库完整性约束 基于DBMS设计数据库。DBMS的应用是如何帮助人 们实现业务，而不是设计业务 2.4.3 数据库设计的一些建议 数据库测试。验证设计的数据库是否满足业务数据管理 和操作的需求 数据库逻辑结构是否能够满足数据存储和管理的需求 测试数据库的性能是否能够满足预期的目标，压力测 试和极限模拟应用测试等都是用来测试数据库性能的 技术 命名问题 随意命名 重复命名 汉语拼音或拼音缩写 使用数据库应用系统支持软件的关键字或保留字命名 不区分大小 2.5 软件体系结构设计 2.5.1 设计问题 数据库的表与应用程序功能模块有一定对应关系。对独立的表或 表集的数据管理通常由一个个独立的功能模块实现。 应对这些统计需求进行分类，不同类的统计功能需求由不同的功 能模块实现 最好为操作需求差异很大的用户类提供不同的应用程序。将各用 户类应用程序中功能相近或完全相同的功能模块设计为公用模块 数据库应用程序都涉及数据库连接、用户登录等操作，这些操作 都应当由独立的功能模块实现 软件体系结构设计最好在数据库逻辑结构设计结束后开始，这样 能够根据数据关系优化体系结构 2.5.2 软件体系结构设计规格说明模板 1 引言 1.1 编写目的 1.2 设计背景 1.3 定义 1.4 参考资料 2 总体设计 2.1 需求规定 2.2 运行环境 2.3 结构 2.4 功能需求与程序的关系 2.5 人工处理过程 2.6 尚未解决的问题 3 接口设计 3.1 用户