第7章 数据库设计3(1).ppt

第七章 数据库设计 7.1 数据库设计概述 7.2 需求分析 7.3 概念结构设计 7.4 逻辑结构设计 7.5 物理结构设计 7.6 数据库的实施和维护 7.7 小结 * 7.2 需求分析阶段 7.2.1 需求分析的任务、内容和实现办法 1.需求分析的主要任务 2.需求分析的调查的内容 3.需求分析的实现办法 * 7.2 需求分析阶段 7.2.2 需求分析的步骤 第一步：分析用户活动，产生: 用户活动图。 第二步：确定系统范围，产生: 系统范围图。 第三步：分析用户活动所涉及到的数据， 产生: 数据流图。 第四步：分析系统数据，产生: 数据字典。 * 【例】某医院信息管理系统需要完成以下功能： 办理病历: 第一次来院治病时办理病历； 查询药品情况: 根据要求查询某种类或全部药品信息； 病人项目入库: 病人所用药、所做检查等治疗信息存入 到指定的数据库中； 催交欠费: 根据病人项目计算出总费用，减去预交费用， 若超过某一限度则催交欠费。 例：通过一个医院信息管理系统来说明这四个步骤应完成的功能。 需求分析的步骤 * 1．分析用户活动 接受申请 病人数据存档 打印病历 封面 接受申请 查药品信息 打印药品目录清单 接受申请 项目信息的 录入与保存 打印项目 信息 接受申请 查项目信息 计算逾期项目与费用 并打印 办理病历 药品查询 项目入库 催交欠费 发给病人 发给 查询人 交给病人 交给病人 图. 用户医院的业务流程所得到的 “用户活动图” 第一步：分析用户活动，产生: 用户活动图。 * 2．确定系统范围 上图中虚线框内的部分属于系统范围，而框外部分则需人工处理。 接受申请 病人数据存档 打印病历 封面 接受申请 查药品信息 打印药品目录清单 接受申请 项目信息的录入与保存 打印项目 信息 接受申请 查项目信息 计算逾期项目与费用 并打印 办理病历 药品查询 项目入库 催交欠费 发给病人 发给 查询人 交给病人 交给病人 第二步：确定系统范围，产生: 系统范围图。 * （1）数据流图的概念 数据流图是一种能全面描述系统逻辑模型的主要工具，它可以用少数几种符号综合地反映出数据在系统中的流动、存储和处理情况。 （2）数据流图的特征 抽象性：数据流图完全舍去了具体的物质，只剩下数据的 流动、加工处理、存储。 概括性：数据流图可以把系统中的不同业务处理过程联 系起来，形成一个整体。 数据流图 （DFD） 3. 画出数据流图 第三步：分析用户活动所涉及到的数据， 产生: 数据流图。 * 画数据流图应注意以下几点： 数据流图中反映的是数据流而不是控制流，这是与一般程序流程图的最大不同之处； 在对数据流图中各个成份命名时，应该体现命名的含义； 流入文件或流出文件的数据流不必命名，因为文件名本身已经表示了数据内容； 源点和终点不是必须的，因为它们是属于系统之外的事物，但画出源点和终点有助于理解数据流的来龙去脉。 S D1 P1 D2 F1 P2 D3 E F2 （3）数据流图的组成 * （4）数据流图的画法 一般地说，画数据流图应遵循 “由外向内，逐步细化” 的原则。 由外向内是指：根据用户活动图标定系统范围，系统范围内部 细节部分可以先不考虑，将其当成一个黑盒子。 逐步细化是指：逐一描述系统内部数据流，一般从每个业务的输入端开始向输出端推进，每当经过使数据流的组成或数值发生变化的地方，就用一个“加工”将其连接起来，这个“加工”正是实现这一数据变化的。 注意：不要把相互无关的数据画成一个数据流，也不要把作为一个处理单位的数据画成二个数据流。如果牵涉到文件，则应表示出“文件”与“加工”的读、写关系。 * 3. 画出数据流图 一般地说，画数据流图应遵循 “由外向内，逐步细化” 的原则。 由外向内是指：根据用户活动图标定系统范围，系统范围内部 细节部分可以先不考虑，将其当成一个黑盒子。如： 医院信息 管理系统 病人或其家属 药品管理人员 医生 财务管理人员 病人或其家属 药品管理人员 门诊请求 查询请求 处方项目 催款请求 病历 药品清单 本次项目清单 交款通知 病人或其家属 病人或其家属 第三步：分析用户活动所涉及到的数据， 产生: 数据流图。 * 办理 病历 门诊请求 打印 病历 病人档案数据 病历 病人 接受 查询 药品查询请求 打印 药品数据