数据库开发方法(可讲).ppt

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