第9章软件详细设计导论.ppt

  1. 1、本文档共126页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
数据模型设计- 确定持久数据的组织结构 Schedule与CourseOffering之间存在多对多关系,Student与CourseOffering之间存在多对多关系,而Schedule与Student之间是一一对应的,所以,在T_Schedule与T_CourseOffering当中建立表格T_CourseOfferingAndStudent,其中包含两个外键,分别指向T_CourseOffering中的记录和T_Schedule(及T_Student)中的记录,所以它可以同时表示Schedule与CourseOffering之间的多对多关系和Student与CourseOffering之间的多对多关系。 对图9.17的进一步解释请见文献[17]。 * 国防科技大学计算机学院 * 图9.17 课程注册管理系统中持久数据的组织结构 * * 9.6.3 确立持久数据操作 这里考虑的持久数据操作是指:仅仅与持久数据本身有关、数据处理逻辑非常简单、因为使用频繁而对整个目标软件系统的性能有较大影响的数据操作。 典型的操作有:数据完整性验证,对数据对象或其属性的批量处理,数据求和、求均值等。 数据完整性又有两种:对表格中某些字段的取值范围的约束,以及一张表格中每条记录的外键所引用的另一张表格的记录必须存在。后者又称引用完整性。 * * 确立持久数据操作 当前的关系数据库管理系统普遍支持两种形式的持久数据操作:存储过程和触发器。 存储过程是命名的SQL语句块,它一经定义即可供反复调用。 触发器是带有执行条件的SQL语句块,触发器仅由关系数据库管理系统在触发条件成立时自动执行,不能以其他方式显式调用。 本步骤不是必需的,因为上述所有的持久数据操作既可采用存储过程或触发器来实现,也可以由数据持久存储服务(见7.6.1节)来实现。 * * 存储过程和触发器与数据持久存储服务的比较: 采用第一种方法的好处是执行效率较高,但是弊端也非常明显:存储过程和触发器破坏了面向对象的软件结构,并且,由于它们与具体的关系数据库管理系统密切相关,也破坏了目标软件系统相对于数据持久机制的独立性、可移植性。 建议采用第二种方法,不要使用存储过程和触发器,除非数据模型设计师经过审慎评估后确认存储过程或触发器能够显著改善系统性能,并且这样的性能提升对于目标软件系统达到预定的性能指标确有必要,舍此别无它法。 * * 9.6.4 优化持久数据操作的性能 在数据密集型应用中,持久数据操作的性能对于目标软件系统的整体性能表现起着至关重要的作用。 在关系数据模型中,常用的持久数据操作性能优化方法有索引和反规范化两种。 * * (一)索引的创建及优化 针对关键字、经常出现在查询语句和数据更新语句的条件部分的字段建立索引。 索引的代价:在写入、更新或删除数据时必须进行额外的索引更新;此外,索引也要占据一定的持久存储空间。 * * 索引的创建及优化 建立索引注意事项: 如果增、删、改的执行频度高于查询的执行频度,或者前者的性能表现比后者更重要,那么被索引的字段就不宜太多; 不需要针对执行频度不高,并且对性能无特殊要求的查询建立索引; 如果需要大批量地进行记录的增、删、改操作,那么应该先删除索引,在大批量操作完成后再重建索引。 被索引的字段在表格的UML类表示中可以冠以构造型indexed。 * * (二)反规范化 “反规范化”:如果需要一次性从多个表格中查询数据,关系数据库必须进行表格连接(table join)。表格连接操作的效率远低于单表查询,所以,在多表连接操作频繁执行时,系统性能会明显下降。此时,可考虑将多张表合并为一张表,这种手段称为“反规范化”。 “反规范化”与关系数据模型所要求的规范化设计原则背道而驰。 反规范化的代价是,针对未合并前的单表的查询操作效率降低,合并后数据更新的效率也会降低。所以,数据模型设计师必须权衡利弊,适度采用反规范化方法。 * * 9.7 设计整合与验证 设计整合的任务是,汇总迄今获得的所有设计模型,包括体系结构模型、界面设计模型、用例设计模型、子系统/构件/类设计模型、数据模型,在全局范围内检查并消解它们之间的不一致性,剔除冗余性,最终形成设计规约。 设计验证的任务是,基于设计规约,重新审视所有软件需求项(包括功能需求项――用例,以及非功能需求项)的实现方案,研究如何化解迄今标识出来的所有重要的全局风险,在此过程中验证详细设计的正确性、优化性和设计充分性。 * * 9.7.1 设计规约 软件设计规约的主要内容包括: (1)系统概述 (1.1)文档概览:文档的结构、每部分的内容简介;文档的读者对象及阅读顺序导引。 (1.2)术语定义:本文档中使用的所有术语、缩写、标识符的完整定义,特别包括在设计模型中出现的每个UML构

您可能关注的文档

文档评论(0)

过各自的生活 + 关注
实名认证
内容提供者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档