数据库物理设计

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