数据库物理设计

6.3.2设计分E-R图（2）
• 现实世界中一组具有共同特性和行为的对象可 抽象为一个实体，例，张三、李斯、王五可抽 象为学生实体 • 对象的组成成分可抽象为实体的属性，例，学 号、姓名、年级等可抽象为学生实体的属性， 其中学号为标识实体的码 • 实体与属性很难划分界限。例，系是学生实体 的属性，在需要考虑系主任、教师人数、学生 人数、办公地点时就需要作为实体了。
整体概念结构（总E-RT图）必须 验证
• 整体概念结构内部必须具有一致性 • 整体概念结构能准确反映原来的每个视 图结构 • 整体概念结构能满足需求分析阶段所确 定的所有要求
6.4 逻辑结构设计
• 逻辑结构设计的任务
– 概念结构是各种数据模型的共同基础 – 为了能够用某一DBMS实现用户需求，还必 须将概念结构进一步转化为相应的数据模型， 这正是数据库逻辑结构设计所要完成的任务。
班主任 管理 班级 上课 教室
指导
组成
宿舍
住宿
学生
归档
档案材料
对学籍管理E-R草图调整
• 一般，性别应作为学生实体的属性，本 应用中由于宿舍分配与性别有关，依据 准则2-属性不能与其他实体有联系，性别 应作为实体对待 • 数据存储“学生登记表”由手工完成， 有用部分转入学生档案材料中，因此这 里不必作为实体。
学生 选修 成绩
课程 学生的码为学号，课程的码为课程号，选修的属 性为成绩
E-R图向关系模型的转换（续）
⒊ 一个1:n联系可以转换为一个独立的关系模式， 也可以与n端对应的关系模式合并。 – 1) 转换为一个独立的关系模式 • 关系的属性：与该联系相连的各实体的码 以及联系本身的属性 • 关系的码：n端实体的码
E-R图向关系模型的转换（续）
⒋ 一个1:1联系可以转换为一个独立的关系模式， 来自百度文库可以与任意一端对应的关系模式合并。 – 1) 转换为一个独立的关系模式 • 关系的属性：与该联系相连的各实体的码 以及联系本身的属性 • 关系的候选码：每个实体的码均是该关系 的候选码
E-R图向关系模型的转换（续）
或 管理（职工号，班级号） 管理（职工号，班级号）
（2）“管理”联系与班级关系模式合并，则只需在班 级关系中加入教师关系的码，即职工号： 班级（班级号，学生人数，职工号） （3）“管理”联系与教师关系模式合并，则只需在教 师关系中加入班级关系的码，即班级号： 教师（职工号，姓名，性别，职称，班级号， 是否为优秀班主任）
6.2需求分析 6.2.2需求分析的方法（1）
• 调查与初步分析用户需求需四步： 调查组织机构情况：部门组成、职责，为分析 信息流程做准备 调查各部门业务活动情况：输入和使用什么数 据，如何加工处理这些数据，输出什么信息、 到哪里、输出结果的格式 协助用户明确对新系统的要求 确定新系统边界，哪些是计算机完成的功能
管理信息系统
教师管理子系统 学生管理子系统 后勤管理子系统
学籍管理
课程管理
实例（续）
• 学生管理子系统的主要功能：学籍管理 和课程管理。包括：学生报到、入学、 毕业、上课情况管理。通过详细的信息 流程分析和数据收集后，生成该系统的 数据流图。见188-189
6.3概念结构设计
6.3.1概念结构设计方法与步骤
• 消除冗余主要采用分析方法，例如教师工资单里的实 发工资，可以推算 • 消除冗余还可采用规范化理论 例， 学生实体的年龄可由生日推算，属冗余数据 教室实体与班级实体的上课联系可由教室与课程间的 开设联系、课程与学生间的选修联系、学生与班级之 间的组成联系推导出来，属于冗余联系 学生实体中平均成绩可由选修联系中的成绩属性推算， 但经常查询，为维护数据一致性，应设置触发器
学籍管理分E-R图草图调整后
班主任 管理 班级 上课 教室
指导
组成
宿舍
住宿
性别
拥有
学生
归档
档案材料
课程管理的E-R图
教室 开设 课程 选修 成绩 讲授 教学 学生
教科书
教师
6.3.3E-R图的集成（1）
• 不同设计人员进行局部视图设计，这导 致各分E-R图之间存在许多不一致的地方， 因此着力消除冲突是主要工作与关键所 在 • 1.属性冲突-讨论协商解决 属性域冲突：属性值的类型、取值范围、 取值集合不同 属性取值单位冲突
6.2需求分析 6.2.2需求分析的方法（2）
• 常用的调查方法： 跟班作业 开调查会-用户彼此启发 请专人介绍 询问-专人 设计调查表请用户填写 查阅记录-与原系统有关的数据记录
6.2需求分析
• 分析和表达用户需求的方法主要包括： 自顶向下（SA）和自底向上方法 自顶向下（SA）方法从最上层的系统组 SA 织机构入手，采用逐层分解的方式分析 系统，并用数据流图和数据字典描述系 统 用SA方法做需求分析，设计人员需要把 任何一个系统都抽象为如下形式
基本E-R图 图 基本 转换规 则 特定 DBMS的 的 特点与限 制
优化方 法如规 范化理 论
逻辑 模型
6.4 逻辑结构设计
6.4.1 E-R图向关系模型的转换 6.4.2 向特定DBMS规定的模型进行转换 6.4.3 数据模型的优化 6.4.4 设计用户子模式
6.4.1 E-R图向关系模型的转换
6.1数据库设计的步骤（2）
• 选定参加设计的人员： 数据库分析设计人员-核心，自始至终 用户-重要，需求分析(头)，运行和维护(尾) 程序员-编制程序 操作员-准备软硬件环境
数据库设计过程图
需 求 分 析 构 设 计 计 计 护 设 理 设 和 维 结 构 念 结 物 施 行 概 辑 据 库 实 运 库 逻 数 据 库 数 据 数
6.3.3E-R图的集成（2）
• 2.命名冲突-讨论协商解决 同名异义 异名同义 • 3. 3.结构冲突 同一对象在不同应用中具有不同的抽象-例， “课程”在某一局部应用中当作实体，另一局 部应用中当作属性 解决办法：使同一对象有相同的抽象，遵守前面 的属性原则
6.3.3E-R图的集成（3）
• 3.结构冲突 同一实体在不同E-R图中所包含的属性不 完全相同，或排列次序不完全相同 解决办法：取分 E-R图的并集，再适当设计 属性的次序 实体间联系在不同视图中呈现不同类型 解决办法：根据应用的语义对实体联系的 类型进行综合或调整
⒋ 一个1:1联系可以转换为一个独立的关系模式， 也可以与任意一端对应的关系模式合并。 – 2) 与某一端对应的关系模式合并 • 合并后关系的属性：加入对应关系的码和 联系本身的属性 • 合并后关系的码：不变
E-R图向关系模型的转换（续）
例，“管理”联系为1:1联系，可以有三种转换方法： （1）转换为一个独立的关系模式：
6.2需求分析 6.2.1任务
• 重点是调查、收集与分析用户在数据管 理中的信息要求、处理要求、安全性和 完整性要求 信息要求-用户需从库中获得信息的内容 和性质，存储哪些信息于库中 处理要求-要求完成的功能、响应时间、 方式是批处理还是联机处理
6.2需求分析 6.2.1任务
• 困难在： 用户缺少计算机知识，无法准确表达自 己的需求，需求往往不断变化 设计人员缺乏用户的专业知识，不易理 解甚至误解用户的需求。 软硬件技术的出现会使用户需求发生变 化
6.4 逻辑结构设计
• 逻辑结构设计的步骤
– 将概念结构转化为一般的关系、网状、层次 模型 – 将转化来的关系、网状、层次模型向特定 DBMS支持下的数据模型转换 – 对数据模型进行优化
逻辑结构设计
转化为 一般数 据模型 转化为特 定DBMS 支持下的 据模型 优化模 型
概念结 构设计
数据库 物理设计
E-R图向关系模型的转换（续）
⒊ 一个1:n联系可以转换为一个独立的关系模式， 也可以与n端对应的关系模式合并。 – 2) 与n端对应的关系模式合并 • 合并后关系的属性：在n端关系中加入1端 关系的码和联系本身的属性 • 合并后关系的码：不变 – 可以减少系统中的关系个数，一般情况下更 倾向于采用这种方法
⒈ 一个实体型转换为一个关系模式。 – 关系的属性：实体型的属性 – 关系的码：实体型的码
例，学生实体可以转换为如下关系模式： 学生（学号，姓名，出生日期，所在系， 年级，平均成绩） 性别、宿舍、班级、档案材料、教师、课程、教室、 教科书等实体都分别转换为一个关系模式。
学生
学号
姓名
出生 日期
所在系
6.3.2设计分E-R图（3）
• 属性和实体区别的原则： 属性不能再具有需要描述的性质。即为 不可再分的数据项 属性不能与其他实体具有联系。联系只 能发生在实体之间。 能做属性对待尽量作属性。
“职称”分别作为实体和属性
教师 姓名 姓名 性别 职称 住房 教师 评定 职称
性别
分配
学籍管理分E-R图草图
年级
平均 成绩
E-R图向关系模型的转换（续）
⒉ 一个m:n联系转换为一个关系模式。 – 关系的属性：与该联系相连的各实体的码以 及联系本身的属性 – 关系的码：各实体码的组合 例，“选修”联系是一个m:n联系，可以将它转 换为如下关系模式，其中学号与课程号为关系 的组合码： 选修（学号，课程号，成绩）
6.3.3E-R图的修改与重构（1）
• 修改与重构-消除不必要的冗余信息,生成基 本E-R图 • 冗余数据-可由基本数据导出 • 冗余的实体间联系-可由其它联系导出 冗余信息易破坏数据库的完整性，给数据维 护增加困难，但有时为了提高某些应用的 效率不得不以冗余信息为代价。
6.3.3E-R图的修改与重构（2）
• 转换内容 • 转换原则
E-R图向关系模型的转换（续）
• 转换内容
– E-R图由实体、实体的属性和实体之间的联 系三个要素组成 – 关系模型的逻辑结构是一组关系模式的集合 – 将E-R图转换为关系模型：将实体、实体的 属性和实体之间的联系转化为关系模式。
E-R图向关系模型的转换（续）
• 转换原则
• 概念结构设计--将需求分析得到的用户需求抽象为概念 模型的过程 • 概念结构独立于数据库逻辑结构，也独立于DBMS • 四类方法： 自顶向下 自底向上—经常采用。即自顶向下进行需求分析，再 自底向上设计概念结构。 逐步扩张-先定义核心概念，然后向外扩充 混合策略
6.3.2分E-R图设计（1）
• 在多层数据流图中选择一个适当层次的 数据流图，让每一部分对应一个局部应 用，因为中层的数据流图能较好地反映 系统中各局部应用的子系统组成，所以 一般作为分E-R图的依据 • 参照数据流图，标定局部应用中的实体、 实体的属性、标识实体的码，确定实体 之间的联系及其类型。
E-R图向关系模型的转换（续）
例，“组成”联系为1:n联系。 将其转换为关系模式的两种方法： 1)使其成为一个独立的关系模式： 组成（学号，班级号）（见下页） 2)将其与学生关系模式合并： 学生（学号，姓名，出生日期，所在系， 年级，班级号，平均成绩）
班级 1 组成 n 学生 学生的码为学号，班级的码为班级号，选修的属 性为成绩
学籍管理与课程管理E-R图的合并
• 存在的冲突： 1.班主任也属于教师，两图存在异名同义，统一为教师实体， 属性构成为： 教师{职工号，姓名，性别，职称，优秀班主任否} 2.班主任改为教师后，教室和学生之间的联系为两类，因为 “指导”包含在“教学”中，所以综合为教学联系 3.性别在学籍管理为实体，在课程管理中为属性，合并后只 能作为实体，否则无法与宿舍实体发生联系 4.二者中学生实体属性组成及次序都存在差异，应将所有属 性综合并重新调整次序。
第六章 数据库设计
第六章 数据库设计
6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 数据库设计概述 需求分析 概念结构设计 逻辑结构设计 数据库的物理设计 数据库实施 数据库运行与维护 小结
6.1数据库设计的步骤（1）
• 目前主要采用以逻辑数据库设计和物理数据库 设计为核心的规范设计方法。 逻辑数据库设计-设计全局逻辑结构和每个用户 的局部逻辑结构，将概念结构转换为某个DBMS DBMS 支持的数据模型并优化 物理数据库设计-为逻辑数据模型选一个最适合 应用环境的物理结构，设计数据库的存储结构、 存取方法及其他实现细节
数据存储
数据流 数据流 数据来源 处理 数据输出
• 然后将处理功能分解，不停分解，直至 系统工作过程被表达清楚；数据也逐级 分解，形成若干层次的数据流图。 • 数据流图表达了数据和处理过程的关系 数据借助数据字典描述 处理过程的处理逻辑借助判定表或判定 树来描述
实例：开发学校管理系统
• 高层数据流图