数据库(第5章)课件.pptVIP

第5章 数据库设计 5.1 数据库设计概要介绍 5.2 需求分析 5.3 概念设计 5.4 逻辑设计 5.5 物理设计 5.6 实施与维护 3、数据库设计的一般策略 采用结构化分析设计（structured analysis）的方法 自顶向下（Top—Down） 自底向上（Bottom—Up） 逐步扩张 混合策略 例： 企业职工管理中，需要涉及的功能有： ①人事处对职工的档案和部门进行管理，包括职工基本情况，部门的基本情况以及各种职称、职务的管理； ②财务处管理职工的工资情况； ③科研处管理项目、职工参加项目的情况。 第一步：确定局部应用范围，设计局部E-R模型 职工 性别 年龄 工资 职工号 分工 部门 部门号 名称 电话 负责人 职称职务 任职 任职日期 代号 名称 津贴 面积 姓名 n 1 m n 人事管理局部E-R图 职工 姓名 性别 年龄 职工号 拥有 工资 工资号 基本工资 保险 实发工资 补贴 1 1 工资管理局部E-R图 m n 项目管理局部E-R图 职工 性别 年龄 职务 职工号 参加 项目 项目号 名称 鉴定日期 起始日期 姓名 第二步：集成局部E-R模型，形成全局初步E-R模型 检查并消除冲突 确定公共实体型 合并局部E-R图 修改否？ 局部E-R模型 进入“全局模型优化” Y N 合并过程中主要解决三类冲突： 命名冲突 属性冲突 结构冲突 拥有 工资 补贴 基本工资 保险 实发工资 职工 性别 年龄 职工号 分工 部门 部门号 名称 电话 负责人 职称职务 任职 任职日期 代号 名称 津贴 面积 参加 项目 项目号 名称 鉴定日期 起始日期 姓名 工资号 合并后的全局初步E-R模型 m n 1 n m n 1 1 第三步：消除冗余，优化全局E-R模型 一个“好”的全局E-R模型，除能反映用户功能需求外，还应该满足以下几个条件： ★实体联系尽可能少； ★实体集所含属性尽可能少； ★实体集间联系无冗余。 续例1： 定义E-R图时可以首先以数据字典为出发点。数据字典中的“数据结构”、“数据流”和“数据存储”等已是若干属性的有意义的聚合。先从这些内容出发定义E-R图，然后根据前面提到的设计原则进行必要的调整。 在实例1中，销售管理局部应用中主要涉及到的实体包括顾客、产品、订单、发票、应收帐款,待完成订货清单。再分析这些实体之间的联系： 一个顾客可以下多个订单，而每个订单记录的某个顾客一次性所订货物的单据，因此顾客和订单之间是1：n的联系；同样分析得出：订单和产品之间的联系是m：n；顾客与发票之间联系是1：n；发票与应收帐款之间的联系是1：n。待发货物清单其实是未完成部分订单,因此只要在订单中增加一属性(状态),就可以包含在订单中。 因此得出销售管理局部应用的E-R图草图如下： 第一步：确定局部应用范围，设计局部E-R模型 销售管理局部E-R草图 进一步考虑该E-R图，作以下调整： ①销售系统中经常可能有折扣等活动,对于每一笔订单明细折扣有可能不同,因此订单明细与折扣之间有联系,作为联系的明细不可以和别的实体之间产生联系,因此将订单明细作为实体。 ②发票如果只是作为手工凭证，凭证上的具体内容都可以在应收帐款中查询到，所以去掉发票实体，在应收帐中加发票号属性。 学籍管理局部应用分E-R图 在上述E-R图中省略了各个实体的属性描述，实体的属性分别为： 顾客:{ 顾客号 , 姓名 , 地址，信贷状况，帐目余额 } 订单:{订单号 ，订货日期，交货日期，工种号，生产地点} 订单明细:{ 编号 ,产品号，数量，金额 } 应收帐款:{ 编号 ,订单号，顾客号，发票号，应收金额， 支付日期，支付金额，当前余额，贷款限额} 产品描述 :{ 产品号 , 品名，单价，重量 } 折扣规则 :{ 产品号，订货量，折扣} 同样得到劳动人事管理局部的分E-R图如下，其中各实体的属性为： 部门 :{部门号，名称 ,办公地址，电话 } 职工:{ 工号 , 姓名 ,职务职称，性别，年龄…… } 项目 :{产品号 , 产品名 , …… } 人事管理局部应用分E-R图 同样得到生产物资管理局部的分E-R图如下，其中各实体的属性为： 供应商 :{供应商号，名称 ,地址，联系电话…… } 职工:{ 工号 , 姓名 ,职务职称，性别，年龄…… } 项目 :{项目号 , 项目名 , …… } 零件：{零件号，零件名，……} 仓库：{库号，地址，电话