当前位置:文档之家› 数据库物理设计

数据库物理设计


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)
相关主题