null第五章 数据库设计第五章 数据库设计5.1 数据库设计概述
5.2 规范化
5.3 需求分析
5.4 概念结构设计
5.5 逻辑结构设计
5.6 数据库的物理设计
5.7 小结学习目标学习目标数据库设计的基本步骤
需求分析的主要内容和方法
规范化理论
概念结构设计的任务与方法
E-R图向关系模型的转换5.1 数据库设计概述5.1 数据库设计概述 5.1.1 数据库和信息系统
5.1.2 数据库设计的内容
5.1.3 数据库设计的基本步骤
5.1.1 数据库和信息系统
5.1.1 数据库和信息系统数据库 数据库(Database,简称DB)是长期储存在计算机内、有组织的、可共享的数据集合信息系统:是提供信息、辅助人们对环境进行控制和进行决策的系统。 数据库是信息系统的核心和基础。数据库设计是信息系统开发和建设的重要组成部分。 数据库设计概述数据库设计概述什么是数据库设计
数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)
在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。5.1.2 数据库设计的内容
5.1.2 数据库设计的内容
数据库的结构设计
是指根据给定的应用环境,进行数据库的模式或子模式的设计。它包括数据库的概念设计、逻辑设计和物理设计。又称为静态模型设计。 数据库的行为设计
是指确定数据库用户的行为和动作。又称为动态模型设计即应用程序的设计。
null数据库设计应该和应用系统的设计相结合,也就是说整个设计过程中要把结构设计和行为设计紧密结合起来。 5.1.3 数据库设计的基本步骤5.1.3 数据库设计的基本步骤1、需求分析
2、概念结构设计阶段
3、逻辑结构设计阶段
4、数据库物理设计阶段
5、数据库实施阶段
6、数据库运行和维护阶段数据库设计之前,首先必须选定参加设计的人员,包括系统分析员、数据库设计人员、程序员、用户、数据库管理员。 设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。数据库设计的基本步骤(续)数据库设计的基本步骤(续)二、数据库设计的过程(六个阶段)
需求分析用户需求的确定;
概念结构设计全局性信息综合与抽象;
逻辑结构设计结合一个DBMS,将系统的信息合理地组成一组逻辑信息结构;
数据库物理设计形成以物理介质为基础的信息体;
数据库实施进行编码、调试并试运行;
数据库运行和维护将设计的系统投入正式运行并进行评价、调整和修改。
设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。5.2 规范化5.2 规范化5.2.1 问
的提出
5.2.2 规范化
5.2.3 范式
5.2.4 范式在工程化设计中的实际应用
5.2.5 小结5.2.1 问题的提出5.2.1 问题的提出关系数据库逻辑设计
针对具体问题,如何构造一个适合于它的数据模式
即应该构造几个关系模式(表)?每个关系有哪些属性组成?
数据库逻辑设计的工具──关系数据库的规范化理论一个实例一个实例例5-1 设计一个用于教务管理系统的数据库,用户有下面几点需求:
① 要能够查询到每个学生的基本情况;
② 要能够查询到每个学生选课情况、每门课的成绩及任课教师;
③ 要能够查询到各学院的情况;
④ 能够添加新同学的信息;
⑤ 能够添加新课程的信息;
⑥ 能够删除学生和课程的信息;
⑦ 能够更改学生、学院、课程的信息;
null初步设计:学籍(学号,姓名,性别,学院,院长,课程号,课程名称,成绩,任课教师)表5-1 学籍关系模式主码表中的信息是否有冗余,都是那些内容?计算机这门课为新开课,还没有学生选,是否可插入操作?如果一个院(系)的学生全部毕业会产生什么情况?怎样修改?
如果张刚转到化学学院 ,与张刚有关的所有记录的学院、院长这两列的值都要更新,如果记录很多容易漏更新,产生数据不一致。 总结问题所在:
插入异常、删除异常、
更新异常、冗余过大!改进
改进方案原关系:学籍(学号,姓名,性别,学院,院长,课程号,课程名称,成绩,任课教师)改进方案:
学生(学号,姓名,性别,学院)
学院(学院,院长)
选课(学号,课程号,成绩,任课教师)
课程(课程号,课程名称)“分解”是解决冗余的主要方法,也是规范化的一条基本原则:“关系模式有冗余问题,就分解它”。5.2.2 规范化5.2.2 规范化规范化理论的作用:改造关系模式,通过分解关系模式来消除其中不合适的问题,以解决删除异常、更新异常、插入异常和数据冗余问题。 一、函数依赖(形式化定义)
二、平凡函数依赖与非平凡函数依赖
三、完全函数依赖与部分函数依赖
四、传递函数依赖
一、函数依赖一、函数依赖定义5.1 设R(U)是一个属性集U上的关系模式,X和Y是U的子集。若对于R(U)的任意一个可能的关系r,r中不可能存在两个元组在X上的属性值相等, 而在Y上的属性值不等, 则称 “X函数确定Y” 或 “Y函数依赖于X”,记作X→Y。 返回说明: 说明: 1. 函数依赖不是指关系模式R的某个或某些关系实例满足的约束条件,而是指R的所有关系实例均要满足的约束条件。
2. 函数依赖是语义范畴的概念。只能根据数据的语义来确定函数依赖。
例如“姓名→年龄”这个函数依赖只有在不允许有同名人的条件下成立
3.函数依赖表达的是关系的属性与属性之间的关系。如果属性A与属性B之间是一对一的关系,则互相函数依赖。如果属性A与属性B之间是一对多的关系,则多端函数依赖于一端。如果属性A与属性B之间是多对多的关系,则不存在函数依赖。
null例5-2:分析关系“学籍(学号, 姓名, 性别, 学院, 院长,课程号,课程名称,成绩,任课教师)”的函数依赖。 分析1:不允许同名学号 姓名,学号 性别, 学号 学院, 学号 院长
姓名 学号,姓名 性别,姓名 学院,姓名 院长
课程号 课程名称
(学号,课程号) 成绩 ,(学号,课程号) 任课教师
学号 成绩
课程号 成绩 →→→→→→→→→→→null分析2:允许同名学号 →性别, 学号 → 学院, 学号 → 姓名,学号 → 院长
课程号 → 课程名称
(学号,课程号) → 成绩,(学号,课程号) → 任课教师 关系:学生成绩(学号, 课程号, 成绩)中:
非平凡函数依赖: (学号, 课程号) → 成绩
平凡函数依赖:(学号, 课程号) → 学号
(学号, 课程号) →课程号
2、函数依赖的性质2、函数依赖的性质(1)投影性
一组属性函数决定它的所有子集。(平凡的函数依赖) (2)合并性
有属性X、Y、Z,若X→Y且X→Z则必有X→(Y,Z)。 例:(学号,课程号)→学号
(学号,课程号)→课程号。 例:学号→姓名,学号→性别,则 学号→(姓名,性别) null(3)扩张性
有属性X、Y、Z,若X→Y且W→Z,则(X,W)→(Y,Z)。 例:学号→(姓名,性别),学院→院长,则有(学号,学院)→(姓名,性别,院长)。(4)分解性
若X→(Y,Z),则X→Y且X→Z。 由合并性和分解性,得出
X→A1,A2,…,An成立的充分必要条件是X→Ai(i=1,2,…,n)成立。 二、完全函数依赖与部分函数依赖二、完全函数依赖与部分函数依赖定义5.2 在关系模式R(U)中,如果X→Y,并且对于X的任何一个真子集X’,都有
X’ Y, 则称Y完全函数依赖于X,记作X f Y。
若X→Y,但Y不完全函数依赖于X,则称Y部分函数依赖于X,记作X P Y。
关系D(学号,院系,课程号,成绩)
(学号,课程号) p 院系看上表null例5-4:分析关系“学籍(学号, 姓名, 性别, 学院, 院长,课程号,课程名称,成绩,任课教师)”中的完全函数依赖及部分函数依赖。 4、传递函数依赖4、传递函数依赖注: 如果Y→X, 即X←→Y,则Z直接依赖于X。 例5-5:分析在关系“学籍(学号, 姓名, 性别, 学院, 院长,课程号,课程名称,成绩,任课教师)”中的传递函数依赖: null汇总:
函数依赖集为:学号→姓名,学号→性别,学号→学院,学院→院长,课程号←→课程名,
(学号,课程号)→成绩,(学号,课程号)→任课教师,任课教师→课程号(前提条件是一位教师只上一门课)。 图形表示法:null练习:分析关系R(连锁店号,店长名,员工号,员工名,货号,货名,销售量)中的函数依赖关系。销售量:一个员工销售一种货物的数量连锁店号店长名员工号员工名货号销售量货名主码是唯一标识实体的属性或属性集主码是唯一标识实体的属性或属性集根据函数依赖怎么判断一个关系模式的主码?
如果关系模式(A,B,C,D,E)中存在函数依赖如下:
A →B , A→D,A→C,A→E 则主码为: A
如果关系模式(A,B,C,D,E)中存在函数依赖如下:
A →B , A→D,B→C,D→E 则主码为: A
如果关系模式(A,B,C,D,E)中存在函数依赖如下:
A →B , A→C,D→E 则主码为: (A,D)
如果关系模式(A,B,C,D,E)中存在函数依赖如下:
A →B , B→C,D→E 则主码为: (A,D)
5.2.3 范式5.2.3 范式 关系最基本的要求:每一分量必须是不可分的数据项。 如何消除关系中的插入异常、删除异常、
更新异常、冗余过大 ?方法:分解
:范式就是符合某一种级别的关系模式的集合。 null范式的种类:
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式(BCNF)
第四范式(4NF)
第五范式(5NF)1、1范式1、1范式定义:如果R满足关系的每一分量是不可再分的数据项,则称R是第一范式的,记作R∈1NF。 第一范式是对关系模式的最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。例:学籍(学号, 姓名, 性别, 学院, 院长,课程号,课程名称,成绩,任课教师) ∈1NFnull改进:改进:有什么特点?每一个非主属性完全函数依赖于码2NF的定义
定义5.6 若关系模式R∈1NF,并且每一个非主属性都完全函数依赖于R的码,则R∈2NF。学生选课课程null学号-〉姓名
学号-〉性别
学号-〉学院
学号-〉院长
学院-〉院长学生选课课程(学号,课程号) -〉成绩
(学号,课程号)-〉任课教师课程号〈-〉课程名null任课
教师成绩学号课程号学号学院性别姓名院长ABC能否完全消除: 插入异常、删除异常、更新异常、冗余过大?null改进3NF的定义
定义5.8 关系模式R
中若不存在这样的码X、属性组Y及非主属性Z(Z Y), 使得X→Y,Y → X,Y→Z,成立,则称R ∈ 3NF。XYZ学生学生学院3、3范式3、3范式定义:如果R的每一个非主属性既不部分函数依赖于候选码也不传递函数依赖于候选码,则称R是第三范式的,记作R∈3NF。如果R∈3NF,则R也是2NF。3NF只限制了非主属性对码的函数依赖关系,而没有限制主属性对码的函数依赖关系。将一个2NF关系分解为多个3NF的关系后,并不能完全消除关系模式中的各种异常情况和数据冗余。D学生(学号,姓名,性别,学院)
E学院(学院,院长) nullC 选课(任课教师,学号,课程号,成绩) 前提:每一位教师只上一门课,每门课由若干位教师上,教师不同名。 函数依赖集:(学号,课程号)→成绩
(学号,课程号)→任课教师
该关系模式满足3NF但是:每位教师只讲授一门课程,但每个选该课程的学生都要存储该教师的信息——数据冗余学期初某位教师新开设一门课程,学生还没有选课,这时教师开设的课程无法插入——插入异常当某位教师开设的某门课程更名时,所有选该课程的学生信息都要修改——更新异常如果选修某课程的学生毕业,则相应的该课程与教师的信息也被删除——删除异常null前提:每一位教师只上一门课,每门课由若干位教师上,教师不同名。 C 选课(任课教师,学号,课程号,成绩) 函数依赖集为 :
(学号,课程号)→成绩
(学号,课程号)→任课教师
任课教师→课程号
(学号,任课教师) → 课程号
(学号,任课教师)→成绩 再改进:3. (学号,课程号,成绩,任课教师)
(任课教师,课程号) 再改进:如何改进?1.(学号,任课教师,成绩)
(任课教师,课程号)2. (学号,课程号,成绩)
(任课教师,课程号)使所有决定因素都包含码3NF4、BC范式4、BC范式定义:设关系模式R∈1NF,如果对于R的每个函数依赖X→Y,若Y不属于X,则X必含有候选码,那么R∈BCNF。 即:每一个决定属性集(因素)都包含(候选)码。 性质:
⒈ 所有非主属性都完全函数依赖于每个候选码。
⒉ 所有主属性都完全函数依赖于每个不包含它的候选码。
⒊ 没有任何属性完全函数依赖于非码的任何一组属性。 3NF与BCNF的关系3NF与BCNF的关系如果关系模式R∈BCNF, 必定有R∈3NF
如果R∈3NF,且R只有一个候选码, 则R必属于BCNF。
5.2.4 范式在工程化设计中的实际应用
5.2.4 范式在工程化设计中的实际应用
关系模式的规范化过程实际上是一个“分解”的过程;
实际上,在信息系统的数据库设计中 :
首先确定建立数据库系统所需要的信息。
把信息分成各个独立的主题 (关系)。
然后再从实际需要出发考虑这些单一的关系之间的联系。
把两个关系或更多地关系组合成一个动态的(或相对静态的)关系模式。 null例如:要设计一个教务管理系统的数据库 :(1)界定系统信息:
学号、姓名、性别、学院、院长、课程号、课程名、成绩、任课教师等信息 (2)划分:
学生(学号,姓名,性别)、学院(学院,院长)、课程(课程号,课程名)、(成绩)、(任课教师)(3)从实际出发:
1)要能够查询到学生所在的学院。 (学号,姓名,性别)
(学院,院长) (学号,姓名,性别,学院)
(学院,院长) 3NFnull2)要能够反映出学生选课这个关系。 (学号,姓名,性别)
(课程名,课程号)
(成绩) (学号,课程号,成绩) 2NF3)要能够查询出学生的某门课程被哪位任课教师所教的信息。 (课程号,课程名)
(任课教师)
(学号,姓名,性别) (学号,任课教师,成绩)
(课程号,任课教师)。 BCNF5.5.2 规范化小结5.5.2 规范化小结关系模式规范化的基本步骤
1NF(每个分量必须是不可分的项)
↓
消除决定属性 2NF(每个非主属性完全函数依赖于码)
集非码的非平 ↓
凡函数依赖 3NF(每个非主属性既不部分也不传递函数依赖于码)
↓ BCNF (每个决定因素都包含码)
↓ 消除非平凡且非函数依赖的多值依赖
4NF消除非主属性对码的部分函数依赖消除非主属性对码的传递函数依赖消除主属性对码的部分和传递函数依 赖规范化的基本规范化的基本思想消除不合适的数据依赖
使模式中的各关系模式达到某种程度的“分离”
采用“一事一地”的模式设计原则
让一个关系描述一个概念、一个实体或者实体间的一种联系。若多于一个概念就把它“分离”出去
所谓规范化实质上是概念的单一化规范化(续)规范化(续)不能说规范化程度越高的关系模式就越好
在设计数据库模式结构时,必须对现实世界的实际情况和用户应用需求作进一步分析,确定一个合适的、能够反映现实世界的模式
上面的规范化步骤可以在其中任何一步终止5.3需求分析5.3需求分析5.3.1 需求分析的基本内容
5.3.2 需求分析的方法
5.3.3 数据图简介
5.3.4 数据字典简介5.3.1 需求分析的基本内容5.3.1 需求分析的基本内容任务:通过详细调查现实世界要处理的对象(组织、部门、企业等),充分了解原系统(手工系统或计算机系统)工作概况,明确用户的各种需求(① 信息需求 ② 处理需求)需求分析是设计数据库的起点
重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。null难点在于数据库的用户和设计人员缺乏对对方的知识的必要了解,因此二者应不断深入沟通。
需求分析的输入/输出:
输入:手工处理或原有系统的信息集合;
处理:对信息进行整理和抽象;
输出:数据流程(DFD)、数据字典(DD)。 需求分析的具体步骤:⑴理清业务流程
复杂业务可以进行分解,最好画出业务流程图
⑵确定系统功能
明确系统的边界与人工操作的接口
⑶画出数据流程图(DFD)
用一组符号来描述整个系统中信息的全貌,综合的反映出数据在系统中的流动、处理和存储的逻辑关系。
⑷编写数据字典(DD) 对系统中的各个部分进行更加细致定义的集合。
需求分析的具体步骤:画业务流程图的方法:画业务流程图的方法:5.3.2 需求分析的方法5.3.2 需求分析的方法常用调查方法
⑴跟班作业
⑵开调查会
⑶请专人介绍
⑷询问
⑸设计调查表请用户填写
⑹查阅记录
了解用户需求后,需要进一步对其进行分析和表达:
分析:SA方法自顶向下逐步分解;
表达:数据字典5.3.3 数据流程图简介5.3.3 数据流程图简介数据流程图由四种元素组成:数据流、数据处理、数据存储、数据源及数据终点(也称作外部实体)。 (1)数据流:具有名字且有流向的一组数据 (记录或数据项), 用标有名字的箭头表示。 (2)数据处理:对数据所进行的加工和变换,在图中用椭圆表示。 null(3)数据存储:用数据库形式(或文件形式)所存储的数据,用开口矩形表示。对其进行的存取分别以指向或离开数据存储的箭头表示。(4)数据源及数据终点: 表示当前系统的数据来源或数据去向,也称作外部实体。用矩形框表示。
例:储户取款数据流程图例:储户取款数据流程图5.3.4 数据字典简介5.3.4 数据字典简介数据字典的内容:
数据项
数据结构
数据流
数据存储
处理过程
数据项是数据的最小组成单位若干个数据项可以组成一个数据结构通过对数据项和数据结构的定义来描述数据流、
数据存储的逻辑内容数据字典(续)数据字典(续)数据项描述={数据项名,数据项含义说明,
别名,数据类型,长度,取值范围,取值含义,与其他数据项的逻辑关系}不可再分的数据单位定义数据的完整性约束条件数据结构描述={数据结构名,含义说明,
组成:{数据项或数据结构}}反映了数据之间的组合关系null数据流描述={数据流名,说明,数据流来源,
数据流去向,组成:{数据结构},
平均流量,高峰期流量}数据结构在系统内传输的路径数据存储描述={数据存储名,说明,编号,
流入的数据流 ,流出的数据流 ,
组成:{数据结构},数据量,
存取频度,存取方式}数据结构停留或保存的地方,也是数据流的来源和去向之一批处理 / 联机处理;
检索 / 更新;
顺序检索 / 随机检索
null处理过程描述={处理过程名,说明,
输入:{数据流},输出:{数据流},
处理:{简要说明}}
具体处理逻辑一般用判定表或判定树来描述主要说明该处理过程的功能及处理要求
该处理过程用来做什么处理频度要求、响应时间要求等
后面物理设计的输入及性能评价的标准null强调两点:
数据字典、信息流程图的生成要充分考虑系统的扩充性;
这一阶段的成果是设计人员和应用人员共同完成的。
需求分析小结需求分析小结实例:假设我们要开发一个学校管理系统。
1.经过可行性分析和初步需求调查,抽象出该系统最高层数据流图,该系统由教师管理子系统、学生管理子系统、后勤管理子系统组成,每个子系统分别配备一个开发小组。
2.进一步细化各个子系统。
其中学生管理子系统开发小组通过进行进一步的需求调查,明确了该子系统的主要功能是进行学籍管理和课程管理,包括学生报到、入学、毕业的管理,学生上课情况的管理。通过详细的信息流程分析和数据收集后,他们生成了该子系统的数据流图。
null数据流图(见教材)数据字典:(1)数据项
以“学号”为例:
数据项:
含义说明:
别名:
类型:
长度:
取值范围:
取值含义:
与其他数据项的逻辑关系:
数据项还有:姓名,出生日期,性别,宿舍编号,地址,人数,班级号,学生人数,职工号,教室地址,容量,教室编号,档案号……等等。 学号唯一标识每个学生学生编号字符型800000000至99999999前两位标别该学生所在年级,
后六位按顺序编号null(2)数据结构
以“学生”为例
“学生”是该系统中的一个核心数据结构:
数据结构:
含义说明:
组成:
学生是学籍管理子系统的主体数据结
构,定义了一个学生的有关信息学号,姓名,性别,年龄,
所在系,年级数据结构还有:宿舍 、档案材料 、班级 、 班主任 、教室 、课程等等 null(3)数据流
“体检结果”可如下描述:
数据流:
说明:
数据流来源:
数据流去向:
组成:
平均流量: ……
高峰期流量:……学号,姓名,性别,身高,体重,血压等 体检结果学生参加体格检查的最终结果体检批准null(4)数据存储
“学生登记表”可如下描述:
数据存储:
说明:
流入数据流:……
流出数据流:……
组成:
数据量:
存取方式:
学生登记表记录学生的基本情况
每年3000张随机存取学生数据结构 数据存储还有:体检表、毕业登记表、宿舍分配表、教室情况表、课程表、学生选课情况表、宿舍情况表、班级情况表 等等。 null(5)处理过程
“分配宿舍”可如下描述:
处理过程:
说明:
输入:
输出:
处理: 分配宿舍为所有新生分配学生宿舍学生,宿舍,宿舍安排在新生报到后,为所有新生分配学
生宿舍。要求同一间宿舍只能安排
同一性别的学生,同一个学生只能
安排在一个宿舍中。每个学生的居
住面积不小于3平方米。安排新生
宿舍其处理时间应不超过15分钟。数据处理还有:学生选课、分配教室等等。 5.4概念结构设计5.4概念结构设计 5.4.1 概念结构设计的任务
5.4.2 概念结构设计的方法与步骤
5.4.3 局部 E—R 模型设计过程
5.4.4 全局概念结构设计 5.4.1 概念结构设计的任务5.4.1 概念结构设计的任务将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计
概念结构是各种数据模型的共同基础,它比数据模型更独立于机器、更抽象,从而更加稳定。
概念结构设计是整个数据库设计的关键
任务:将需求分析的结果进行概念化抽象,获得系统的E-R图。
描述概念模型的工具:E-R模型
5.4.2 概念结构设计的方法与步骤5.4.2 概念结构设计的方法与步骤设计概念结构的四类方法
自顶向下
自底向上
逐步扩张
混合策略
首先定义最重要的核心概念结构,然后向外扩充,以滚雪球的方式逐步生成其他概念结构,直至总体概念结构将自顶向下和自底向上相结合,用自顶向下策略设计一个全局概念结构的框架,以它为骨架集成由自底向上策略中设计的各局部概念结构。首先定义全局概念结构的框架,然后逐步细化首先定义各局部应用的概念结构,然后将它们集成起来,得到全局概念结构概念结构设计的方法与步骤(续)概念结构设计的方法与步骤(续)自顶向下策略概念结构设计的方法与步骤(续)概念结构设计的方法与步骤(续)自底向上策略 概念结构设计的方法与步骤(续)概念结构设计的方法与步骤(续)逐步扩张5.4.3 局部 E—R 模型设计过程5.4.3 局部 E—R 模型设计过程步骤:1、确定各局部E—R 模型描述的范围
通常采用的方法是将总的功能划分为几个子系统,每个子系统又划分几个子系统。2、逐一设计分E-R图
设计分E-R图主要完成以下工作:确定实体(集)、确定实体(集)的属性、确定实体间的联系。
如何区分实体和属性一般原则
即属性必须是不可分的数据项,不能再由另一些属性组成。
属性不能与其他实体具有联系。联系只发生在实体之间。
符合上述两条特性的事物一般作为属性对待。
现实世界中事物能做属性对待的,尽量作属性对待。如何区分实体和属性例2:职称通常作为教师实体的属性,但在涉及住房分配时,由于分房与职称有关,也就是说职称与住房实体之间有联系,根据准则2,这时把职称作为实体来处理会更合适些。例1:“学生”由学号、姓名等属性进一步描述,根据准则1,“学生”只能作为实体,不能作为属性。
5.4.4 全局概念结构设计5.4.4 全局概念结构设计任务:将所有得分E-R图综合成一个系统的总E-R图。
方式:
一次集成多个分E-R图
通常用于局部视图比较简单时
逐步集成式
首先集成两个局部视图(通常是比较关键的两个局部视图)
以后每次将一个新的局部视图集成进来
无论采用哪种集成法,每一次集成都分为两个阶段:合并分E-R图,生成初步E-R图、消除冗余。一、合并分E-R图,生成初步E-R图一、合并分E-R图,生成初步E-R图各分E-R图存在冲突
冲突:各分E-R图之间存在的不一致的地方。
属性冲突(属性域冲突、属性取值单位冲突)
命名冲突(同名异义、异名同义)
结构冲突
同一对象在不同应用中具有不同的抽象
同一实体在不同局部视图中所包含的属性个数和排列次序不完全相同
实体之间的联系在不同局部视图中呈现不同的类型
合并分E-R图的主要工作与关键所在:合理消除各分E-R图的冲突
解决方法:通常是把属性变换为实体或把实体变换为属性,使同一对象具有相同的抽象。变换时要遵循两个准则。
解决方法:使该实体的属性取各分E-R图中属性的并集,再适当设计属性的次序。解决方法:根据应用语义对实体联系的类型进行综合或调整。消除结构冲突实例:消除结构冲突实例:1、异名同义null2、同一对象在不同应用中具有不同的抽象例:职称在不同的应用中可以作为职工的属性,也可以作为一个实体。
通常当对职称没有进一步的描述时,根据准则1作为职工实体的属性;
但在涉及住房分配时,由于分房与职称有关,也就是说职称与住房实体之间有联系,根据准则2,这时把职称作为实体来处理会更合适些。null3、同一实体在不同局部视图中所包含的属性个数和排列次序不完全相同null4、实体之间的联系在不同局部视图中呈现不同的类型二、修改与重构二、修改与重构基本任务
消除不必要的冗余,设计生成基本E-R图1.冗余1.冗余冗余的数据是指可由基本数据导出的数据;
冗余的联系是指可由其他联系导出的联系。
并不是所有的冗余数据与冗余联系都必须加以消除,有时为了提高某些应用的效率,不得不以冗余信息作为代价。
设计数据库概念结构时,哪些冗余信息必须消除,哪些冗余信息允许存在,需要根据用户的整体需求来确定。
消除不必要的冗余后的初步E-R图称为基本E-R图。例:若物资部门经常查询各种材料的库存量,如果每次都查询每个仓库中此种材料的库存,再对他们求和,效率太低。所以应该保留“库存总量”的属性。2.消除冗余的方法2.消除冗余的方法分析方法
以数据字典和数据流图为依据,根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
如果是为了提高效率,人为地保留了一些冗余数据,则应把数据字典中数据关联的说明作为完整性约束条件。
使用规范化理论(不要求)
函数依赖的概念提供了消除冗余联系的形式化工具分析法消除冗余实例:分析法消除冗余实例:(1)例,教师工资单中包括该教师的基本工资、各种补贴、应扣除的房租水电费以及实发工资。因实发工资可以由前面各项推算出来,因此可以去掉,在需要查询实发工资时根据基本工资、各种补贴、应扣除的房租水电费数据临时生成。(2) 教室实体与班级实体的上课联系可以由教室与课程之间的开设联系、课程与学生之间的选修联系、学生与班级之间的组成联系三者推导出来,因此属于冗余联系,可以消去。
null(3) 学生实体中的年龄属性可以由出生日期推算出来,属于冗余数据,应该去掉。这样不仅可以节省存储空间,而且当某个学生的出生日期有误,进行修改后,无须相应修改年龄,减少了产生数据不一致的机会。
学生:{学号,姓名,出生日期,年龄,
所在系,年级,平均成绩}
概念结构设计小结:概念结构设计小结:消除冲突消除不必要的冗余null概念结构设计阶段
任务:
方法:
局部E-R图设计步骤:将需求分析的结果进行概念化抽象。 自顶向下、自底向上、逐步扩张、混合策略。 确定各局部E—R 模型描述的范围、逐一设计分E-R图。确定属性的基本原则:
集成全局E-R图的方法5.5 逻辑结构设计5.5 逻辑结构设计5.5.1 逻辑结构设计的任务
5.5.2 E-R图向关系模型的转换
5.5.3 数据模型的优化5.5.1 逻辑结构设计的任务
5.5.1 逻辑结构设计的任务
任务:把概念结构设计阶段设计好的基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。 关系、网状、层次三种数据模型:本章只讨论关系数据模型逻辑结构设计阶段的步骤:
E-R图向关系模型的转换
用关系数据理论对关系模式的规范化
关系模式的优化 5.5.2 E-R图向关系模型的转换5.5.2 E-R图向关系模型的转换转换过程中的主要问题: E-R图:
实体
实体的属性
实体间的联系关系模式:
关系
属性
码转换原则 : ⒈ 一个实体型转换为一个关系模式。
关系的属性:实体型的属性
关系的码:实体型的码2.一个m:n联系转换为一个关系模式。
关系的属性:与该联系相连的各实体的码以及联系本身的属性
关系的码:各实体码的组合转换原则 : nullnull2) 与n端对应的关系模式合并
合并后关系的属性:在n端关系中加入1端关系的码和联系本身的属性
合并后关系的码:不变⒊ 一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。
1) 转换为一个独立的关系模式
关系的属性:与该联系相连的各实体的码以及联系本身的属性
关系的码:n端实体的码可以减少系统中的关系个数,一般情况下更倾向于采用这种方法null2) 与某一端对应的关系模式合并
合并后关系的属性:加入对应关系的码和联系本身的属性
合并后关系的码:不变
⒋ 一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
1) 转换为一个独立的关系模式
关系的属性:与该联系相连的各实体的码以及联系本身的属性
关系的候选码:每个实体的码均是该关系的候选码null⒌ 三个或三个以上实体间的一个多元联系转换为一个关系模式。
关系的属性:与该多元联系相连的各实体的码以及联系本身的属性
关系的码:各实体码的组合 null⒍ 同一实体集的实体间的联系,即自联系,也可按上述1:1、1:n和m:n三种情况分别处理。null⒎ 具有相同码的关系模式可合并。
目的:减少系统中的关系个数。
合并方法:将其中一个关系模式的全部属性加入到另一个关系模式中,然后去掉其中的同义属性(可能同名也可能不同名),并适当调整属性的次序。
例:“拥有”关系模式:
拥有(学号,性别)
与学生关系模式:
学生(学号,姓名,出生日期,所在系,年级,
班级号,平均成绩)
合并为一个关系模式:
学生(学号,姓名,性别,出生日期,所在系,
年级,班级号,平均成绩)5.5.3 数据模型的优化5.5.3 数据模型的优化关系数据模型的优化通常以规范化理论为指导。优化数据模型的常用方法(1)合并
(2)分解(水平分解和垂直分解)5.6 数据库的物理设计5.6 数据库的物理设计数据库在物理设备上的存储结构与存取方法称为数据库的物理结构
为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程,就是数据库的物理设计。
数据库物理设计的步骤
确定数据库的物理结构
对物理结构进行评价,评价的重点是时间和空间效率
null设计物理数据库结构的准备工作
1. 充分了解应用环境,详细分析要运行的事务,以获得选择物理数据库设计所需参数
2. 充分了解所用RDBMS的内部特征,特别是系统提供的存取方法和存储结构
null设计数据库物理存储结构的内容:
(1)确定数据的存储结构
(2)设计合适的存取路径(索引方法、聚簇方法、HASH方法)
(3)确定数据的存放位置
(4)确定系统配置(同时使用数据库的用户数、同时打开的数据库对象数,内存分配参数、缓冲区分配参数,时间片的大小及数据库的大小等)null评价物理结构
综合权衡时间效率、空间效率、维护代价和各种用户的要求5.7 小结5.7 小结数据库的设计过程
需求分析
概念结构设计
逻辑结构设计
物理设计
实施
运行维护
设计过程中往往还会有许多反复。null
需求
分析
概念
结构
逻辑
结构
物理
结构
实施
运行
维护
数据流图
数据字典调查研究自顶向下抽象
数据,
设计局
部E-R
图集成
到全局
E-R图自底向上消除冲突消除不必要的冗余基本E-R图七条原则转换成
关系模型关系模型优化