660 likes | 872 Views
第 7 章 数据库设计. 本章主要内容. 数据库设计 (Database Design, 简记为 DBD) 是指对于给定的软、硬件环境,针对现实问题,设计一个较优的数据模型,建立 DB 结构和 DB 应用系统。 本章主要讨论 DBD 的方法和步骤,详细介绍 DBD 的全过程。本章的重点有两个: 概念设计中的 ER 模型设计方法。设计 ER 模型是一件实用性很强的工作 ,ER 模型应该充分反映用户的需求。 逻辑设计中 ER 模型向关系模型转换的规则。. 本章主要内容 ( 续 ). ( 1 ) DBS 生存期及其 7 个阶段的任务和工作, DBD 过程的输入和输出。
E N D
本章主要内容 数据库设计(Database Design,简记为DBD)是指对于给定的软、硬件环境,针对现实问题,设计一个较优的数据模型,建立DB结构和DB应用系统。 本章主要讨论DBD的方法和步骤,详细介绍DBD的全过程。本章的重点有两个: • 概念设计中的ER模型设计方法。设计ER模型是一件实用性很强的工作,ER模型应该充分反映用户的需求。 • 逻辑设计中ER模型向关系模型转换的规则。
本章主要内容(续) (1)DBS生存期及其7个阶段的任务和工作,DBD过程的输入和输出。 (2)概念设计的重要性、主要步骤。逻辑设计阶段的主要步骤。 (3)ER模型的基本元素,属性的分类,联系的元数、连通词、基数。采用ER方法的概念设计步骤。 (4)ER模型到关系模型的转换规则。采用ER方法的逻辑设计步骤。
数据库设计 7.1 数据库设计概述 7.2 规划 7.3 需求分析 7.4 概念设计 7.5 数据库逻辑结构设计及优化 7.6 数据库的物理设计 7.7 数据库的实现 7.8 数据库的运行与维护工作 7.9 Power Designer辅助设计工具 本章小结
7.1 数据库设计概述 隶属关系 • 软件工程 人们认为,应该用科学知识、工程方面的规范指导软件开发的过程,以提高软件质量和开发效率,降低开发成本 。 • 软件生存期 从软件的规划、研制、实现、投入运行后的维护,直到它被新的软件所取代而停止使用的整个期间。 • 数据库系统生存期 数据库应用系统从开始规划、设计、实现、维护到最后被新的系统取代而停止使用的整个期间。 • 数据库工程设计方法 • 数据库设计的输入输出
7.1.1 数据库系统生存期 规划 规划 需求分析 需求分析 数据库生存期 软件生存期 概念设计 系统设计 逻辑设计 程序编制 物理设计 调试 实现 运行维护 运行和维护
7.1.2 数据库设计方法 1)直观设计法 直观设计法主要凭借设计者对整个系统的了解和认识,以及平时所积累的经验和设计技巧,完成对某一数据库系统的设计任务。 • 这样的方法具有周期短、效率高、操作简便、易于实现等优点。 • 这种方法主要是用于简单的小型系统。 2)规范化设计法 规范化设计法将数据库设计分为若干阶段,明确规定各阶段的任务,采用“自顶向下、分层实现、逐步求精”的设计原则,结合数据库理论和软件工程设计方法,实现设计过程的每一细节,最终完成整个设计任务。 常用的规范化设计方法主要有: • 基于实体联系的设计方法(常用方法) • 基于视图概念的数据库设计方法 • 基于3NF的数据库设计方法等。
3)计算机辅助设计法 计算机辅助设计法是指在数据库设计的某些过程中,利用计算机和一些辅助设计工具,模拟某一规范设计方法,并以人的知识或经验为主导,通过人机交互方式实现设计中的某些部分。 例如在需求分析完成后,可以使用POWERDESIGNER、E-Rwin等辅助工具产生E-R图,并将E-R图转换为关系数据模型,生成数据库结构,再编制相应的应用程序,从而缩短数据库设计周期。 4)自动化设计法 设计人员只要熟悉某种MIS辅助设计软件的使用,通过人机会话,输入原始数据和有关要求,无须人工干预,就可以由计算机系统自动生成数据库结构及相应的应用程序。 由于该设计方法基于某一MIS辅助设计系统,从而受限于某种DBMS,使得最终产生的数据库及其软件系统带有一定的局限性。
7.1.3 数据库设计的基本步骤 总体信息需求 处理需求 第1步 规划 DBMS特征 第2步 需求描述和分析 需求说明书 第3步 概念设计 信息结构 (独立于硬件、软件) 第4步 逻辑设计 逻辑数据库结构 (DBMS能处理的) 应用程序说明书 硬件和 OS特征 第5步 物理设计 物理数据库结构
7.2 规划 • 目标 进行建立数据库的必要性及可行性分析,确定数据库系统在组织中和信息系统中的地位,以及各个数据库之间的联系。 • 规划阶段的三个步骤 • 系统调查: 对企业组织作全面的调查,画出组织层次图,以了解企业的组织结构。 • 可行性分析 从技术、经济、效益、法律等方面对建立数据库的可行性进行分析;写出可行性分析报告;组织专家进行讨论其可行性。 • 确定数据库系统的总目标和制定项目开发计划
子系统1 子系统2 … 子系统n 专用 数据库m 公用 数据库1 公用 数据库2 专用 数据库1 … 分析企业的基本业务功能,确定数据库支持的范围,是建立一个综合的数据库,还是建立若干个专门的数据库。 • 在实际操作中,可以建立一个支持组织全部活动的包罗万象的综合数据库; • 也可以建立若干个范围不同的公用或专用数据库。
规划报告 数据库规划工作完成以后,应写出详尽的可行性分析报告和数据库系统规划纲要,内容包括: • 信息范围; • 信息来源; • 人力资源; • 设备资源; • 软件及支持工具资源; • 开发成本估算; • 开发进度计划; • 现行系统向新系统过渡计划等。
7.3 需求分析 • 目标 对系统的整个应用情况作全面的、详细的调查,确定企业组织的目标,收集支持系统总的设计目标的基础数据和对这些数据的要求,确定用户的需求,并把这些要求写成用户和数据库设计者都能够接受的文档。 • 需求分析工作 • 分析用户活动产生,产生业务流程图 • 确定系统范围,产生系统范围图 • 分析用户活动涉及的数据,产生数据流图 • 分析系统数据,产生数据字典
7.3.1 需求描述与分析 确定全部的用户需求是一件很困难的事情: • 第一,系统本身的需求是变化的,用户的需求必须不断调整,使之与这种变化一致。 • 第二,由于用户缺少计算机信息系统设计方面的专业知识,要表达他们的需求很困难。特别是很难说清楚某部分工作的功能与处理过程。 • 第三,要调动用户的积极性,使他们能积极参与系统的分析与设计工作相当困难。 • 我们设计人员必须首先认识到在整个需求分析以及系统设计过程中,用户参与的重要性。 • 需求分析中调查分析的方法很多,通常的办法是对不同层次的企业管理人员进行个人访问,内容包括业务处理和企业组织中的各种数据。 • 还应该考虑系统将来要发生的变化,充分考虑到系统可能的扩充和变动,以减少系统维护的代价。
7.3.2 需求分析阶段的输入和输出 总体信息需求 处理需求 第1步:需求分析 需求说明书
7.3.3 需求分析的步骤 1)需求信息的收集 (1)调查的目的 • 首先,要了解组织的机构设置,主要业务活动和职能。 • 其次,要确定组织的目标,大致工作流程和任务范围划分。 (2)调查的内容 • 外部要求 • 业务现状 • 组织机构等 (3)调查方式 • 开座谈会; • 跟班作业; • 请调查对象填写调查表; • 查看业务记录、票据; • 个别交谈。
2)需求信息的分析整理 (1)业务流程分析 业务流程分析的目的是获得业务流程及业务与数据联系的形式描述。 一般采用数据流分析法,分析结果以数据流图(data flow diagram,DFD)表示。 一个DFD由数据流、处理过程、数据存储等部分组成。
(2)分析结果的描述 除了DFD以外,还要用一些规范表格进行补充描述。 为了清楚地描述需求分析的结果,需要整理出下列清单: • 数据项清单:列出每一个数据项的名称、含义、来源、类型和长度等。 • 业务活动清单:列出每一部门中最基本的工作任务,包括任务的定义、操作类型、执行频度、所属部门及涉及的数据项等。 • 完整性、一致性要求。 • 安全性要求。 • 响应时间要求。 • 预期变化的影响。 3)评审 评审的目的在于确认某一阶段的任务是否全部完成,以避免重大的疏漏或错误。
7.3.4 数据字典 数据字典(data dictionary, DD)是对系统中数据的详尽描述,它提供对数据库数据描述的集中管理。 1)数据项 包括数据项名、含义、别名、类型、长度、取值范围以及与其它数据项的逻辑关系。 数据项名:选课单号 说 明:标识每张选课单 类 型:CHAR(8) 长 度:8 别 名:选课单号 取值范围:00000001~99999999
2)数据结构 数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成,或有若干个数据项和数据结构混合组成。 它包括数据结构名、含义及组成该数据结构的数据项名或数据结构名。 数据结构名:考试课程 说 明:作为考场安排的组成部分,说明某门课程哪位老 师代,以及所选学生人数。 组 成:课程号 教师号 选课人数
3)数据流 数据流可以是数据项,也可以是数据结构,表示某一加工处理过程的输入或输出数据。 对数据流的描述应包括数据流名、说明、流出的加工名、流入的加工名以及组成该数据流的数据结构或数据项。 数据流名:考场安排 说 明:由各课程所选学生数,选定教室、时间,安排考场 来 源:考试 去 向:教师 数据结构:考场安排 ――考试课程 ――考试时间 ――教学楼 ――教室编号
4)数据存储 数据存储是处理过程中要存储的数据,它可以是手工凭证、手工文档或计算机文档。 对数据存储的描述应包括:数据存储名、说明、输入数据流、输出数据流、数据量、存取频度和存取方式。 数据存储名:课程表 说 明:对每门课程的名称、学分、先行课程号和摘要描述 输出数据流:课程介绍 数据描述 :课程号 课程名 学分数 先行课程号 摘要 数 量:每年500种 存 取 方 式 :随机存取
5)处理进程 对处理进程的描述包括处理进程名、说明、输入数据流、输出数据流,并简要说明处理工作、频度要求、数据量及响应时间等。 处理进程:选课 说 明:对要选某门课程的每一个学生,根据已选修课程 确定其是否可选该课程。再根据学生选课的人数选择适当的教室,制定选课单 输 入:学生选课 可选课程 已选课程 输 出:选课单 程序提要:a. 对所选课程在选课表中查找其是否已选此课程 b. 若未选过此课程,则在选课表中查找是否已选此 课程的先行课程 c. 若a、b都满足,则在选课表中增加一条选课记录 d. 处理完全部学生的选课处理后,形成选课单
7.4 概念设计 目标 概念设计的目标是产生反映企业组织信息需求的数据库概念结构,即概念模式。概念模式是独立于计算机硬件结构,独立于支持数据库的DBMS。 为什么需要概念设计 概念设计的主要步骤 进行数据抽象,设计局部概念模式 将局部概念模式综合成全局概念模式 评审
7.4.1 概念设计的必要性 在概念设计阶段中,设计人员从用户的角度看待数据及处理要求和约束,产生一个反映用户观点的概念模式。 然后再把概念模式转换成逻辑模式。 将概念设计从设计过程中独立开来,至少有以下几个好处: 各阶段的任务相对单一化,设计复杂程度大大降低,便于组织管理。 不受特定的DBMS的限制,也独立于存储安排和效率方面的考虑,因而比逻辑模式更为稳定。 概念模式不含具体的DBMS所附加的技术细节,更容易为用户所理解,因而才有可能准确地反映用户的信息需求。
数据库的各级模式 应用1 应用1 应用2 应用3 概念要求 外模式1 外模式2 外模式3 映像 应用2 概念要求 概念模式 逻辑模式 映像 转换 应用3 内模式 概念要求 综合
E-R图设计方法 (1)自顶向下 根据用户需求,先定义全局概念结构的框架,然后分层展开,逐步细化。 (2)自底向上 根据用户的每一具体需求,先定义各局部应用的概念结构,然后将它们集成,逐步抽象引最终产生全局概念结构。 (3)逐步扩张 先定义最重要的核心概念结构,然后向外扩充,以滚雪球的方式逐步生成其他概念结构,直至全局概念结构。 (4)混合方式 将自顶向下和自底向上相结合,先用自顶向下方式设计一个全局概念结构框架,再以它选基础,采用自底向上法集成各局部概念结构。
7.4.2 概念设计的主要步骤 1)进行数据抽象,设计局部概念模式 先从个别用户的需求出发,为每个用户建立一个相应的局部概念结构。 设计概念结构时,常用的数据抽象方法是“聚集”和“概括”。 2)将局部概念模式综合成全局概念模式 综合各局部概念结构就可得到反映所有用户需求的全局概念结构。 • 在综合过程中,主要处理各局部模式对各种对象定义的不一致问题。 • 在结构合并时,解决冗余问题,对信息需求的再调整与分析。 3)评审 消除了所有冲突后,就可把全局结构提交评审。 • 用户评审 • DBA及应用开发人员评审
7.4.3 采用ER方法的数据库概念设计 在设计数据库概念结构时,为了更好地模拟现实世界,一个有效的策略是“分而治之”,即先分别考虑各个用户的信息需求,形成局部概念结构,然后再综合成全局结构。 需求分析结果 确定局部结构范围 实体定义 联系定义 属性分配 还有局部 结构待分析 有 无 进入全局ER模式设计 1)设计局部ER模式
(1)确定局部结构范围 一种是依据系统的当前用户进行自然划分。 例如,对一个企业的综合数据库,按决策部门、销售部门、生产部门、技术部门和供应部门分别设计各自的局部ER模式。 另一种是按用户要求数据库提供的服务归纳成几类,为每类应用设计一个局部ER模式。 例如,学校的教师数据库可以按提供的服务分为以下几类: 教师的档案信息的查询。 对教师的专业结构进行分析。 对教师的职称、工资变化的历史分析。 对教师的学术成果查询分析。 局部结构范围的确定要考虑下述因素: • 范围的划分要自然,易于管理。 • 范围之间的界面要清晰,相互影响要小。 • 范围的大小要适度。
(2)确定实体 通常可依据下列两个基本规则来区分实体和属性: 实体与属性之间的联系只能是1:n的; 属性本身不再具有需要描述的信息或与其他事物具有联系。 现实世界中的事物能够作为属性对待的,应尽量作为属性处理,以简化E-R模型。 图(a)仓库作为物资实体的属性 图(b)仓库作为单独的实体 物资 编号 名称 规格 单价 仓库号 存放数量 存放 编号 仓库号 物资 仓库 名称 规格 单价 存放数量 地点 面积
(3)联系设计 某商业集团中,商店、仓库、商品之间的进货联系 问题:运动员根据其得分来排定名次。在名次排列中,排在他前面只有一个人排在他后面也只有一个人 工厂的零件之间存在着组合关系,一种零件由许多种子零件组成,而一种零件也可以是其他零件的子零件 职工之间的上下级联系 学校里规定每学期学生至少选修1门课程,最多选修6门课程;每门课程至多有50人选修,最少可以没人选修 仓库号 仓库名 地址 仓库 数量 M 图7.13 联系的连通词和实体的基数 图7.10 一元联系中的1:N联系 图7.9 一元联系中的1:1联系 进货 图7.11 一元联系中的M:N联系 日期 图7.12 三元联系中的M:N:P联系 N P 商店 商品 1 1 商店号 商店名 商品号 商品名 规格 零件号 零件名 编号 姓名 性别 名次 零件 M N 运动员 组成 学生 M (1,6) 数量 顺序 选课 N (0,50) 课程 工号 姓名 年龄 性别 职工 1 N 领导 • 联系集 联系集是n(n≥2)个实体集上的数学关系,这些实体集不必互异。 • 联系的元数 一个联系涉及到的实体集个数。 • 联系的连通词 涉及到的实体集之间实体对应的方式 。 • 实体的基数 有两个实体集E1和E2,E1中每个实体与E2中有联系实体的数目的最小值min和最大值max,称为E1的基数,用(min,max)形式表示 。
(4)属性分配 基本工资 奖金 家庭地址 门牌号码 姓名 房租 规格 进货价格 区 名 供应商 经销价格 实发工资 零件编码 工号 街 道 代销价格 零件名 批发价格 图7.5 多值属性的表示 零件编码 职 工 零售价格 图7.8 导出属性的表示 零 件 省(市)名 图7.6 多值属性的变换(1) 邮政编码 地 址 图7.4 地址属性的层次结构 供应商 零件名 规格 销售性质 售货价格 进货价格 零件编码 1 N 存在 零 件 销售价格 规格 供应商 进货价格 零件名 图7.7 多值属性的变换(2) 销售价格 零件编码 零 件 • 基本属性和复合属性(可否再分) • 单值属性和多值属性(对一个实体对象是否只能取一个值) • 多值属性的处理 • 将原来的多值属性用几个新的单值属性来表示。 • 将原来的多值属性用一个新的实体类型表示 • 导出属性 • 空值
局部ER模式设计综述 范围的划分要自然,易于管理; 采用人们习惯的划分; 避免冗余,在一个局部结构中,对一个对象只取一种抽象形式,不要重复; 依据用户的信息处理需求 确定属性的原则: 属性应该是不可再分解的语义单位;实体与属性之间的关系只能是1:N的;不同实体类型的属性之间应无直接关联关系。 范围之间的界面要清晰,相互影响要小 范围的大小要适度。太小了,会造成局部结构过多,设计过程繁琐,综合困难;太大了,则容易造成内部结构复杂,不便分析 属性分配的原则: 当多个实体类型用到同一属性时, 一般把属性分配给那些使用频率最高的实体类型,或分配给实体值少的实体类型。 有些属性不宜归属于任一实体类型,只说明实体之间联系的特性 需求分析结果 确定局部结构范围 实体定义 联系定义 属性分配 还有局部 结构待分析 有 无 进入全局ER模式设计 图7.18 局部ER模式设计
局部模式 现有的教学 管理系统 初步分析系统的对象 根据服务种类分析教师子模块 …… 局部ER图
其他局部模式 1 有 N 1 管理 1 系 班级 班主任 1 导师 组成 指导 1 N N N 归档 1 N 住宿 1 档案材料 学生 宿舍 M 参加 N 学会 图7.21 学籍管理局部应用的分E-R图 1 具有 N 社会关系 根据服务种类分析学生子模块 …… 现有的教学 管理系统 初步分析系统的对象 局部ER图
其它局部模式 1 开设 N 系 课程 M 1 上课 担任 1 N 选修 MN 学生 P N 教室 教科书 教师 图7.22 课程管理局部应用分E-R图 现有的教学 管理系统 初步分析系统的对象 …… 根据服务种类分析课程子模块 局部ER图
ER模型的操作 教师 教师号 姓名 教师 出生日期 教师号 职务 工资 奖金 1 M M 主讲 辅导 主讲 教师不变信息 教师变动信息 N N (b) N 课程 课程 图7.15 实体类型的垂直分裂 (a) (b) 图7.16 联系类型的分裂 A B A B A-C B-C A-B-C 教师号 姓名 出生日期 职务 工资 奖金 C C 教师 (b) (a) (a) 图7.17 不合法的合并 包括实体类型、联系类型和属性的分裂、合并、增删等等
2)设计全局 ER模式 属性冲突 :如,重量单位有的用公斤,有的用克。 结构冲突 :同一对象在不同应用中的不同抽象 ;同一实体在不同局部ER图中属性的个数或次序不同 ;实体之间的联系在不同的局部ER图中呈现不同的类型 命名冲突 :属性名、实体名、联系名之间存在同名异义或异名同义冲突 局部ER模式 确定公共实体类型 合并两个局部ER模式 检查并消除冲突 还有冲突吗 有 还有未合并的局部模式 有 无 图7.20全局ER模式设计
结构冲突解决方式1 学生 学号 姓名 性别 年龄 所在系 专业 编号 系名 系主任 所在地点 联系电话 系 1 属于 n ① 对于同一对象在不同的局部E-R模型中产生不同的抽象: 把属性变为实体或实体变为属性,使同一对象具有相同的抽象,变换后产生的结果仍然要遵守7.4.3节中所阐述的两个基本规则。(一是实体与属性之间的联系只能是1:n的;二是属性本身不再具有需要描述的信息或与其他事物具有联系。)
结构冲突解决方式2 学生 学生 图(a) E-R模型1 图(b) E-R模型2 学号 学号 姓名 姓名 性别 性别 年龄 年龄 所在系 所在系 专业 专业 图(c)合并后的E-R模型 学生 学号 籍贯 姓名 政治面貌 家庭住址 籍贯 家庭住址 政治面貌 ② 对于同一实体在不同E-R模型中属性组成不同: 取两个分E-R模型属性的并,作为合并后的该实体属性,然后对属性的先后次序作适当调整。
结构冲突解决方式3 产品 m m p 组成 供应 组成数量 供应商 n n 供应数量 零件 图7-14 (c) 合并后的E-R模型 产品 产品 m p 组成 数量 供应商 组成 数量 n n 零件 零件 图7-14 (b) 产品、零件和供应商的ER模型2 图7-14 (a) 产品与零件的ER模型1 ③ 对于实体间的相同联系呈现的不同的类型: 根据具体应用的语义,对实体间的联系作适当的综合或调整。
3)全局ER模式的优化 • 实体类型的合并 • 1:1联系的两个实体类型 • 具有相同键的实体类型 • 冗余属性的消除 • 冗余联系的消除 利用规范化理论中函数依赖的概念消除冗余联系
例子:三个局部ER图合并成一个ER图 教师 教师 教师 院长 院长 院长 1 1 1 主管 主管 主管 学院 学院 学院 1 1 1 1 1 1 1 1 1 管理 管理 管理 设置 设置 设置 N N N 1 1 1 项目 项目 项目 N N N 承接 承接 承接 1 1 1 1 1 1 有 有 有 N N N 系 系 系 班级 班级 班级 学会 学会 学会 1 1 1 1 1 1 M M M 1 1 1 管理 管理 管理 1 1 1 参加 参加 参加 开设 开设 开设 组成 组成 组成 参加 参加 参加 选修 选修 选修 聘用 聘用 聘用 N N N 1 1 1 N N N N N N M M M N N N N N N 担任 担任 担任 N N N 教师 教师 教师 课程 课程 课程 N N N 1 1 1 M M M N N N 住宿 住宿 住宿 学生 学生 学生 宿舍 宿舍 宿舍 1 1 1 P P P N N N 上课 上课 上课 1 1 1 教科书 教科书 教科书 1 1 1 评定 评定 评定 具有 具有 具有 归档 归档 归档 1 1 1 教室 教室 教室 1 1 1 N N N N N N 职称 职称 职称 社会关系 社会关系 社会关系 指导 指导 指导 档案材料 档案材料 档案材料 1 1 1 N N N 1 1 1 分配 分配 分配 1 1 1 工作量 工作量 工作量 图7.24 合并后的教学管理E-R图 图7.24 合并后的教学管理E-R图 图7.24 合并后的教学管理E-R图
7.5 数据库逻辑结构设计及优化 数 据 库 逻 辑 结 构 设 计 独立于DBMS的概念模式 DBMS可处理的模式和子模式 处理需求 应用程序设计指南 约束条件 物理设计指南 DBMS特征 7.5.1 逻辑设计环境
7.5.2 逻辑设计的步骤 返回到前面阶段 概念模式 导出初始DBMS模式说明 子模式设计 应用程序设计草图 模式评价 是 否 处理结束 是 模式需要修正 否 进入物理设计阶段 模式修正 • 目标 • 逻辑设计步骤
7.5.3 ER模型向关系模型的转换 1)转换的一些问题 (1)命名和属性域的处理 关系模式的命名,可以采用E-R图中原来的命名,也可以另行命名。 (2)非原子属性的处理 E-R数据模型中允许非原子属性,这不符合关系模型的第一范式的条件。 对集合属性纵向展开,对元组属性横向展开。
职工号 姓名 性别 年龄 与职工关系 (3)弱实体的处理 (a)E-R图 (b)关系模式 职工号 出生日期 姓名 职工 家属 1 姓名 职工-家属 年龄 性别 与职工关系 N
姓名 名称 地址 职称 任期 联系电话 (4)联系的转换 l:l 联系 名称 姓名 1 1 管理 学校 校长 地址 职称 联系电话 任期 k h 1 1 r E1 E2 b a s 可以一个关系模式: R( k,a , h,b,s )