数据库原理与应用.pptVIP

主讲教师：李刚 第三章 需求分析 （5）接口需求：描述应用系统与它的环境通信的格式，常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。 （6）约束：包括设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。 （7）逆向需求：说明软件不应该做什么。 （8）将来可能提出的要求 ：为系统的扩充和修改作准备。 基本任务：准确地回答“系统必须做什么？”（软件范围）对系统提出完整、准确、清晰、具体的要求。 在这个阶段结束时交出的文档是需求规格说明书（技术合同）。 3.1 需求分析的任务 1、确定对系统的综合需求 （1）系统功能要求 ：划分出系统必须完成的所有功能； （2）系统性能要求 ：联机响应时间、系统需要的存储容量、重新启动、安全性等； （3）可靠性和可用性要求 ：可用性与可靠性密切相关，它量化了用户可以使用系统的程度。 （4）出错处理需求 ：这类需求说明系统对环境错误应该怎样响应。 2、分析系统的数据要求 系统需要哪些数据，数据之间有什么联系，数据由哪些数据元素组成。 DFD（数据流图）、DD（数据字典）、 E-R图（实体-联系）、数据的组成层次结构 3、导出系统的逻辑模型 数据流程图、数据字典、主要算法。 4、修正系统开发计划 5、开发原型系统（样机） 主要目的：使用户通过实践获得关于未来的系统的更直接更具体的概念，更准确地提出和确定他们的要求。 主要理由： （1）由于人的认识能力的局限，不能预先指定所有的要求； （2）在用户和系统分析员之间存在固有的通信鸿沟； （3）用户需要一个“活”的系统模型，以便获得实践经验； （4）在开发过程中重复和反复是必要的和不可避免的； （5）目前有快速建立原型系统的工具可供选用。 主要问题：增加了软件成本。 3.2 分析过程 1、沿数据流程图回溯 从“输出端”到“输入端”回溯，分析数据元素。 2、用户复查 借助已有的数据流程图，帮助复查，再次完善数据流程图。 3、细化数据流程图 4、修正开发计划 5、书写文档 （1）需求规格说明：系统的概貌、功能要求、运行要求、将来可能的要求。 数据流图（DFD）、数据字典（DD）、数据结构（用图形工具的层次图、Warnier图表示）、处理逻辑说明（IPO图、结构化语言、判定树表）、数据存储（数据库、普通文件） （2）用户系统描述：初步的用户手册 （3）初步测试计划 （4）修正的开发计划 ：修正后的成本估计、资源使用计划、进度计划等。 6、技术审查和管理复审。 3.3 概念模型和规范化（数据库概要设计） 1、概念模型 最常用的表示概念性数据模型的方法：实体—联系方法(Entity-Relationship Approach)，简称E-R模型。 E-R模型包含三个基本成分：“实体”、“联系”、“属性” (1)实体：是客观世界中存在的、且可相互区分的事物。它可以是人或物，也可以是具体事物或抽象事物。 例如：教师、学生、课程是实体。 实体用矩形框表示，如： (2)联系：客观世界中的事物彼此之间有联系，描述实体与实体之间的关系。联系有三种： 1：1（一对一联系） 例如：实体“校长”与“大学”之间的联系为“1：1” 1：N（一对多联系） 例如：实体“学校”与“院系”之间的联系为“1:N ” M：N（多对多联系） 例如：实体“学生”与“课程”之间的联系为“M:N ” 联系用菱形框表示。 (3)属性：属性是实体或联系所具有的性质。通常一个实体或联系由若干属性来刻画。 2、范式（Normal Forms) 关系规范化的目的：消除数据冗余，避免插入异常和删除异常。 几个重要概念： 函数依赖(Functional Dependency) 完全函数依赖(Full Functional Dependency) 部分函数依赖(Partial Functional Dependency) 传递函数依赖(Transitive Functional Dependency) 候选关键字(Candidate Key) 主关键字(Prime Key) 主属性(Prime Attribute) 非主属性(Nonprime Attribute) 关系规范化(Normalization): 第一范式（1NF）：不存在重复组和组项； 第二范式（2NF）：不存在非主属性对候选关键字的部分函数依赖； 第三范式（3NF）：不存在非主属性对候选关键字的传递函数依赖。 一般分解到第三范式即可。范