第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.1 数据库设计的步骤
?数据库设计的准备工作
?数据库设计的过程
一、数据库设计的准备工作
?选定参加设计的人员
– 数据库分析设计人员
– 用户
– 程序员
– 操作员
数据库设计的准备工作 (续 )
?1,数据库分析设计人员
– 数据库设计的核心人员
– 自始至终参与数据库设计
– 其水平决定了数据库系统的质量
数据库设计的准备工作 (续 )
? 2,用户
– 在数据库设计中也是举足轻重的
– 主要参加需求分析和数据库的运行维护
– 用户积极参与带来的好处
? 加速数据库设计
? 提高数据库设计的质量
数据库设计的准备工作 (续 )
? 3,程序员
– 在系统实施阶段参与进来，负责编制程序
? 4,操作员
– 在系统实施阶段参与进来，准备软硬件环境
二,数据库设计的过程 (六个阶段 )
1,需求分析阶段
2,概念结构设计阶段
3,逻辑结构设计阶段
4,数据库物理设计阶段
5,数据库实施阶段
6,数据库运行和维护阶段
数据库设计的过程 (续 )
⒈需求分析阶段
– 准确了解与分析用户需求（包括数据与处理）
– 是整个设计过程的基础，是最困难、最耗费时间的
一步
数据库设计的过程 (续 )
⒉概念结构设计阶段
– 是整个数据库设计的关键
– 通过对用户需求进行综合、归纳与抽象，形
成一个独立于具体 DBMS的概念模型
数据库设计的过程 (续 )
⒊ 逻辑结构设计阶段
– 将概念结构转换为某个 DBMS所支持的数据
模型
– 对其进行优化
数据库设计的过程 (续 )
⒋ 数据库物理设计阶段
– 为逻辑数据模型选取一个最适合应用环境的
物理结构（包括存储结构和存取方法）
数据库设计的过程 (续 )
⒌ 数据库实施阶段
– 运用 DBMS提供的数据语言、工具及宿主语
言，根据逻辑设计和物理设计的结果
? 建立数据库
? 编制与调试应用程序
? 组织数据入库
? 并进行试运行
数据库设计的过程 (续 )
⒍ 数据库运行和维护阶段
– 数据库应用系统经过试运行后即可投入正式
运行。
– 在数据库系统运行过程中必须不断地对其进
行评价、调整与修改。
数据库设计的过程 (续 )
设计一个完善的数据库应用系统往往是
上述六个阶段的不断反复。
P184图 6-1
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.2 需求分析
6.2.1 需求分析的任务
6.2.2 需求分析的方法
6.2.3 数据字典
需求分析（续）
?需求分析就是分析用户的需要与要求
– 需求分析是设计数据库的起点
– 需求分析的结果是否准确地反映了用户的实
际要求，将直接影响到后面各个阶段的设计，
并影响到设计结果是否合理和实用
6.2 需求分析
6.2.1 需求分析的任务
6.2.2 需求分析的方法
6.2.3 数据字典
6.2.1 需求分析的任务
一、需求分析的任务
二、需求分析的重点
三、需求分析的难点
一、需求分析的任务
? 通过详细调查现实世界要处理的对象
（组织、部门、企业等），充分 了解原
系统 （手工系统或计算机系统） 工作概
况，明确用户的各种需求
? 在此基础上 确定新系统的功能 。新系统
必须充分考虑今后可能的扩充和改变，
不能仅仅按当前应用需求来设计数据库
二、需求分析的重点
? 需求分析的重点是调查、收集与分析用户在数
据管理中的 信息要求、处理要求、安全性与完
整性要求 。
? 信息要求
– 用户需要从数据库中获得信息的内容与性质
– 由用户的信息要求可以导出数据要求，即在
数据库中需要存储哪些数据
需求分析的重点（续）
? 处理要求
– 对处理 功能 的要求
– 对处理的 响应时间 的要求
– 对处理 方式 的要求 (批处理 / 联机处理 )
? 新系统的功能必须能够满足用户的信息要求、
处理要求、安全性与完整性要求。
三、需求分析的难点
?确定用户最终需求的难点
– 用户 缺少计算机知识，开始时无法确定计算
机究竟能为自己做什么，不能做什么，因此
无法一下子准确地表达自己的需求，他们所
提出的需求往往不断地变化。
– 设计人员 缺少用户的专业知识，不易理解用
户的真正需求，甚至误解用户的需求。
– 新 的硬件、软件 技术的出现 也会使用户需求
发生变化。
需求分析的难点 (续 )
?解决方法
– 设计人员必须采用有效的方法，与用户不断
深入 地进行 交流,才能逐步得以确定用户的
实际需求
6.2 需求分析
6.2.1 需求分析的任务
6.2.2 需求分析的方法
6.2.3 数据字典
6.2.2 需求分析的方法
?调查清楚用户的实际需求并进行初步分析
? 与用户达成共识
? 进一步分析与表达这些需求
一,调查与初步分析用户需求
⑴ 调查组织机构情况
– 部门的组成情况
– 各部门的职责等
调查与初步分析用户需求（续）
⑵ 调查各部门的业务活动情况。调查重点之一。
– 各个部门 输入 和使用什么数据
– 如何加工 处理 这些数据
– 输出 什么信息
– 输出到什么部门
– 输出结果的格式是什么
调查与初步分析用户需求（续）
⑶ 在熟悉业务活动的基础上，协助用户明确对
新系统的各种要求。调查重点之二。
– 信息要求
– 处理要求
– 完全性与完整性要求
调查与初步分析用户需求（续）
⑷ 对前面调查的结果进行初步分析
– 确定新系统的边界
? 确定哪些功能由计算机完成或将来准备让计算机
完成
? 确定哪些活动由人工完成
由计算机完成的功能就是新系统应该实现的功能。
二、常用调查方法
?做需求调查时，往往需要同时采用多种
方法
– 无论使用何种调查方法，都必须有用户的积
极参与和配合
– 设计人员应该和用户取得共同的语言，帮助
不熟悉计算机的用户建立数据库环境下的共
同概念，并对设计工作的最后结果共同承担
责任
常用调查方法（续）
?常用调查方法
⑴跟班作业
– 通过亲身参加业务工作了解业务活动的情况
– 能比较准确地理解用户的需求，但比较耗时
⑵开调查会
– 通过与用户座谈来了解业务活动情况及用户
需求
⑶请专人介绍
常用调查方法（续）
⑷ 询问
– 对某些调查中的问题，可以找专人询问
⑸设计调查表请用户填写
– 如果调查表设计合理，则很有效，且易于为
用户接受
⑹查阅记录
– 查阅与原系统有关的数据记录
三、进一步分析和表达用户需求
? 分析和表达用户的需求 的常用方法
– 自顶向下的结构化分析方法（ Structured
Analysis，简称 SA方法）
? SA方法从最上层的系统组织机构入手，采用逐
层分解的方式分析系统，并用数据流图和数据
字典描述系统。
进一步分析和表达用户需求（续）
1．首先把任何一个系统都抽象为,
数据流 数据流
数据
存储 信息要求
数据
来源
处理 数据
输出 处理要求
进一步分析和表达用户需求（续）
2．分解处理功能和数据
（ 1）分解处理功能
? 将处理功能的具体内容分解为若干子功能，再
将每个子功能继续分解，直到把系统的工作过
程表达清楚为止。
（ 2）分解数据
? 在处理功能逐步分解的同时，其所用的数据也
逐级分解，形成若干层次的数据流图
? 数据流图表达了数据和处理过程的关系
进一步分析和表达用户需求（续）
（ 3）表达方法
? 处理过程：用判定表或判定树来描述
? 数据：用数据字典来描述
进一步分析和表达用户需求（续）
3．将分析结果再次提交给用户，征得用户
的认可
四、需求分析小结
?P187图 6-4
需求分析小结（续）
实例：假设我们要开发一个学校管理系统。
1．经过可行性分析和初步需求调查，抽象出该系统最高
层数据流图，该系统由 教师管理子系统, 学生管理子
系统, 后勤管理子系统 组成，每个子系统分别配备一
个开发小组。
2．进一步细化各个子系统。
其中学生管理子系统开发小组通过进行进一步的需求
调查，明确了该子系统的主要功能是进行 学籍管理 和
课程管理,包括学生报到、入学、毕业的管理，学生
上课情况的管理。通过详细的信息流程分析和数据收
集后，他们生成了该子系统的数据流图。
6.2 需求分析
6.2.1 需求分析的任务
6.2.2 需求分析的方法
6.2.3 数据字典
6.2.3 数据字典
一、数据字典的用途
二、数据字典的内容
一、数据字典的用途
? 数据字典是各类数据描述的集合
? 数据字典是进行详细的数据收集和数据分析所
获得的主要结果
? 数据字典在数据库设计中占有很重要的地位
二、数据字典的内容
? 数据字典的内容
– 数据项
– 数据结构
– 数据流
– 数据存储
– 处理过程
? 数据项是数据的最小组成单位
? 若干个数据项可以组成一个数据结构
? 数据字典通过对数据项和数据结构的定义来描
述数据流、数据存储的逻辑内容。
⒈ 数据项
?数据项是不可再分的数据单位
? 对数据项的描述
数据项描述＝｛数据项名，数据项含义说明,
别名，数据类型，长度，取值范围,
取值含义，与其他数据项的逻辑关系｝
– 取值范围、与其他数据项的逻辑关系定义了
数据的完整性约束条件
⒉ 数据结构
? 数据结构反映了数据之间的组合关系。
? 一个数据结构可以由若干个数据项组成，也可
以由若干个数据结构组成，或由若干个数据项
和数据结构混合组成。
? 对数据结构的描述
数据结构描述＝｛数据结构名，含义说明,
组成,｛数据项或数据结构｝｝
⒊ 数据流
? 数据流是数据结构在系统内传输的路径。
? 对数据流的描述
数据流描述＝｛数据流名，说明，数据流来源,
数据流去向，组成,｛数据结构｝,
平均流量，高峰期流量｝
– 数据流来源是说明该数据流来自哪个过程
– 数据流去向是说明该数据流将到哪个过程去
– 平均流量是指在单位时间（每天、每周、每
月等）里的传输次数
– 高峰期流量则是指在高峰时期的数据流量
⒋ 数据存储
? 数据存储是数据结构停留或保存的地方，也是
数据流的来源和去向之一。
? 对数据存储的描述
数据存储描述＝｛数据存储名，说明，编号,
流入的数据流,流出的数据流,
组成,｛数据结构｝，数据量，存取方式｝
– 流入的数据流：指出数据来源
– 流出的数据流：指出数据去向
– 数据量：每次存取多少数据，每天（或每小时、每
周等）存取几次等信息
– 存取方法：批处理 / 联机处理；检索 / 更新；顺序
检索 / 随机检索
⒌ 处理过程
? 处理过程的具体处理逻辑一般用判定表或判定
树来描述。数据字典中只需要描述处理过程的
说明性信息
? 处理过程说明性信息的描述
处理过程描述＝｛处理过程名，说明,
输入,｛数据流｝，输出,｛数据流｝,
处理,｛简要说明｝｝
处理过程（续）
– 简要说明：主要说明该处理过程的功能及处
理要求
? 功能：该处理过程用来做什么
? 处理要求：处理频度要求（如单位时间里
处理多少事务，多少数据量）；响应时间
要求等
? 处理要求是后面物理设计的输入及性能评
价的标准
处理过程（续）
例：学生学籍管理子系统的数据字典。
数据项,以“学号”为例,
数据项,学号
含义说明：唯一标识每个学生
别名,学生编号
类型,字符型
长度,8
取值范围,00000000至 99999999
取值含义：前两位标别该学生所在年级,
后六位按顺序编号
与其他数据项的逻辑关系,
处理过程（续）
数据结构 以“学生”为例
,学生”是该系统中的一个核心数据结构,
数据结构,学生
含义说明,是学籍管理子系统的主体数据结
构，定义了一个学生的有关信息
组成,学号，姓名，性别，年龄,
所在系，年级
处理过程（续）
数据流,体检结果”可如下描述,
数据流,体检结果
说明,学生参加体格检查的最终结果
数据流来源：体检
数据流去向：批准
组成,……
平均流量,……
高峰期流量,……
处理过程（续）
数据存储,学生登记表”可如下描述,
数据存储,学生登记表
说明,记录学生的基本情况
流入数据流,……
流出数据流,……
组成,……
数据量,每年 3000张
存取方式,随机存取
处理过程（续）
处理过程,分配宿舍”可如下描述,
处理过程：分配宿舍
说明,为所有新生分配学生宿舍
输入,学生，宿舍,
输出,宿舍安排
处理,在新生报到后，为所有新生分配学
生宿舍。要求同一间宿舍只能安排
同一性别的学生，同一个学生只能
安排在一个宿舍中。每个学生的居
住面积不小于 3平方米。安排新生
宿舍其处理时间应不超过 15分钟。
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.3 概念结构设计
?什么是概念结构设计
– 需求分析阶段描述的用户应用需求是现实世
界的具体需求
– 将需求分析得到的用户需求抽象为信息结构
即概念模型的过程就是概念结构设计
– 概念结构是各种数据模型的共同基础，它比
数据模型更独立于机器、更抽象，从而更加
稳定。
– 概念结构设计是整个数据库设计的关键
概念结构设计（续）
现实世界
机器世界
信息世界
需求分析
概念结构设计
概念结构设计（续）
?概念结构设计的特点
（ 1）能真实、充分地反映现实世界，包括事物
和事物之间的联系，能满足用户对数据的处理
要求。是对现实世界的一个真实模型。
（ 2）易于理解，从而可以用它和不熟悉计算机
的用户交换意见，用户的积极参与是数据库的
设计成功的关键。
概念结构设计（续）
?概念结构设计的特点 (续 )
（ 3）易于更改，当应用环境和应用要求改变时，
容易对概念模型修改和扩充。
（ 4）易于向关系、网状、层次等各种数据模型
转换。
概念结构设计（续）
?描述概念模型的工具
– E-R模型
6.3 概念结构设计
6.3.1 概念结构设计的方法与步骤
6.3.2 数据抽象与局部视图设计
6.3.3 视图的集成
6.3 概念结构设计
6.3.1 概念结构设计的方法与步骤
6.3.2 数据抽象与局部视图设计
6.3.3 视图的集成
6.3.1 概念结构设计的方法与步骤
?设计概念结构的四类方法
– 自顶向下
? 首先定义全局概念结构的框架，然后逐
步细化
概念结构设计的方法与步骤（续）
自顶向下策略
概念结构设计的方法与步骤（续）
?设计概念结构的四类方法（续）
– 自底向上
? 首先定义各局部应用的概念结构，然后
将它们集成起来，得到全局概念结构
概念结构设计的方法与步骤（续）
自底向上策略
概念结构设计的方法与步骤（续）
– 逐步扩张
? 首先定义最重要的核心概念结构，然后
向外扩充，以滚雪球的方式逐步生成其他
概念结构，直至总体概念结构
– 混合策略
? 将自顶向下和自底向上相结合，用自顶
向下策略设计一个全局概念结构的框架，
以它为骨架集成由自底向上策略中设计的
各局部概念结构。
概念结构设计的方法与步骤（续）
逐步扩张
概念结构设计的方法与步骤（续）
?常用策略
– 自顶向下地进行需求分析
– 自底向上地设计概念结构
概念结构设计的方法与步骤（续）
?自底向上设计概念结构的步骤
– 第 1步：抽象数据并设计局部视图
– 第 2步：集成局部视图，得到全局概念结构
6.3 概念结构设计
6.3.1 概念结构设计的方法与步骤
6.3.2 数据抽象与局部视图设计
6.3.3 视图的集成
6.3.2 数据抽象与局部视图设计
?数据抽象
?局部视图设计
一、数据抽象
?概念结构是对现实世界的一种抽象
– 从实际的人、物、事和概念中抽取所关心的
共同特性，忽略非本质的细节
– 把这些特性用各种概念精确地加以描述
– 这些概念组成了某种模型
数据抽象（续）
?三种常用抽象
1,分类（ Classification）
– 定义某一类概念作为现实世界中一组对象的
类型
– 这些对象具有某些共同的特性和行为
– 它抽象了对象 值和型 之间的,is member of”
的语义
– 在 E-R模型中，实体型就是这种抽象
例,
数据抽象（续）
2,聚集（ Aggregation）
– 定义某一类型的组成成分
– 它抽象了对象内部类型和成分之间,is part
of”的语义
– 在 E-R模型中若干属性的聚集组成了实体型，
就是这种抽象
例,
数据抽象（续）
3,概括（ Generalization）
– 定义类型之间的一种子集联系
– 它抽象了类型之间的,is subset of”的语义
– 概括有一个很重要的性质：继承性。子类继
承超类上定义的所有抽象。
例,
数据抽象（续）
注：原 E-R模型不具有概括，本书对 E-R模型作
了扩充，允许定义超类实体型和子类实体型。
? 用双竖边的矩形框表示子类,
? 用直线加小圆圈表示超类 -子类的联系
数据抽象（续）
?数据抽象的用途
– 对需求分析阶段收集到的数据进行分类、组
织（聚集），形成
? 实体
? 实体的属性，标识实体的码
? 确定实体之间的联系类型 (1:1,1:n,m:n)
二、局部视图设计
设计分 E-R图的步骤,
⒈ 选择局部应用
⒉逐一设计分 E-R图
⒈ 选择局部应用
? 需求分析阶段，已用多层数据流图和数据字典
描述了整个系统。
? 设计分 E-R图首先需要根据系统的具体情况，
在多层的数据流图中 选择 一个 适当层次的数据
流图,让这组图中每一部分对应一个局部应用，
然后以这一层次的数据流图为出发点，设计分
E-R图。
选择局部应用（续）
?通常以中层数据流图作为设计分 E-R
图的依据。原因,
– 高层数据流图只能反映系统的概貌
– 中层数据流图能较好地反映系统中各局部应
用的子系统组成
– 低层数据流图过细
选择局部应用（续）
例：由于学籍管理、课程管理等都不太复
杂，因此可以它们入手设计学生管理子
系统的分 E-R图。如果局部应用比较复杂，
则可以从更下层的数据流图入手。
⒉ 逐一设计分 E-R图
?任务
– 标定局部应用中的实体、属性、码，实体间
的联系
? 将各局部应用涉及的数据分别从数据字典
中抽取出来，参照数据流图，标定各局部
应用中的实体、实体的属性、标识实体的
码，确定实体之间的联系及其类型（ 1:1，
1:n,m:n）
逐一设计分 E-R图（续）
?如何抽象实体和属性
– 实体,现实世界中一组具有某些共同特性和
行为的对象就可以抽象为一个实体。对象和
实体之间是,is member of"的关系。
例：在学校环境中，可把张三、李四等对象抽
象为学生实体。
逐一设计分 E-R图（续）
– 属性,对象类型的组成成分可以抽象为实体
的属性。组成成分与对象类型之间是,is
part of"的关系。
例：学号、姓名、专业、年级等可以抽象为学
生实体的属性。其中学号为标识学生实体的码。
逐一设计分 E-R图（续）
?如何区分实体和属性
– 实体与属性是相对而言的 。同一事物，在一
种应用环境中作为“属性”，在另一种应用
环境中就必须作为“实体”。
例：学校中的系，在某种应用环境中，它只
是作为“学生”实体的一个属性，表明一个
学生属于哪个系；而在另一种环境中，由于
需要考虑一个系的系主任、教师人数、学生
人数、办公地点等，这时它就需要作为实体
了。
逐一设计分 E-R图（续）
– 一般原则
? 属性不能再具有需要描述的性质。即属性
必须是不可分的数据项，不能再由另一些
属性组成。
? 属性不能与其他实体具有联系。联系只发
生在实体之间。
– 符合上述两条特性的事物一般作为属性对待。
– 为了简化 E-R图的处置，现实世界中的事物
凡能够作为属性对待的，应尽量作为属性。
逐一设计分 E-R图（续）
– 举例
例 1：“学生”由学号、姓名等属性进一步描
述，根据准则１，“学生”只能作为实体，
不能作为属性。
例 2：职称通常作为教师实体的属性，但在涉
及住房分配时，由于分房与职称有关，也就
是说职称与住房实体之间有联系，根据准则
２，这时把职称作为实体来处理会更合适些。
逐一设计分 E-R图（续）
?设计分 E-R图的步骤
– （ 1）以数据字典为出发点定义 E-R图。
? 数据字典中的“数据结构”、“数据流”
和“数据存储”等已是若干属性的有意义
的聚合
– （ 2）按上面给出的准则进行必要的调整。
逐一设计分 E-R图（续）
例：学籍管理局部应用中主要涉及的实体包括学
生、宿舍、档案材料、班级、班主任。
实体之间的联系,
– 由于一个宿舍可以住多个学生，而一个学生
只能住在某一个宿舍中，因此宿舍与学生之
间是 1:n的联系。
– 由于一个班级往往有若干名学生，而一个学
生只能属于一个班级，因此班级与学生之间
也是 1:n的联系 。
逐一设计分 E-R图（续）
– 由于班主任同时还要教课，因此班主任与学
生之间存在指导联系，一个班主任要教多名
学生，而一个学生只对应一个班主任，因此
班主任与学生之间也是 1:n的联系。
– 而学生和他自己的档案材料之间，班级与班
主任之间都是 1:1的联系。
学籍管理局部应用的分 E-R图草图,
逐一设计分 E-R图（续）
接下来需要进一步斟酌该 E-R图，做适当调整。
– (1) 在一般情况下，性别通常作为学生实体
的属性，但在本局部应用中，由于宿舍分配
与学生性别有关，根据准则２，应该把性别
作为实体对待。
– (2) 数据存储“学生登记表”，由于是手工
填写，供存档使用，其中有用的部分已转入
学生档案材料中，因此这里就不必作为实体
了。
最后得到学籍管理局部应用的分 E-R图,
逐一设计分 E-R图（续）
学籍管理 E-R图中省略了各个实体的属性描述,
学生：｛ 学号,姓名，出生日期｝
性别：｛ 性别 ｝
档案材料：｛ 档案号, …… ｝
班级：｛ 班级号,学生人数｝
班主任：｛ 职工号,姓名，性别,
是否为优秀班主任｝
宿舍：｛ 宿舍编号,地址，人数｝
其中有下划线的属性为实体的码。
逐一设计分 E-R图（续）
同样方法可以得到课程管理局部应用的分 E-R图
各实体的属性分别为,
学生：｛姓名,学号,性别，年龄，所在系,
年级，平均成绩｝
课程：｛ 课程号,课程名，学分｝
教师：｛ 职工号,姓名，性别，职称｝
教科书：｛ 书号,书名，价钱｝
教室：｛ 教室编号,地址，容量｝
6.3 概念结构设计
6.3.1 概念结构设计的方法与步骤
6.3.2 数据抽象与局部视图设计
6.3.3 视图的集成
6.3.4 视图的集成
?各个局部视图即分 E-R图建立好后，还需
要对它们进行合并，集成为一个整体的
数据概念结构即总 E-R图。
视图的集成（续）
?视图集成的两种方式
– 一次集成（图 6.25(a)）
? 一次集成多个分 E-R图
? 通常用于局部视图比较简单时
– 逐步累积式（图 6.25(b)）
? 首先集成两个局部视图（通常是比较关键
的两个局部视图）
? 以后每次将一个新的局部视图集成进来
视图的集成（续）
?集成局部 E-R图的步骤
1,合并
2,修改与重构
视图的集成（续）
一、合并分 E-R图，生成初步 E-R图
?各分Ｅ－Ｒ图存在冲突
– 各个局部应用所面向的问题不同
由不同的设计人员进行设计
各个分 E-R图之间必定会存在许多不一致的
地方
– 合并分 E-R图的主要工作与关键所在：合理
消除各分 E-R图的冲突
合并分 E-R图，生成初步 E-R图（续）
?冲突的种类
– 属性冲突
– 命名冲突
– 结构冲突
⒈ 属性冲突
?两类属性冲突
– 属性域冲突,属性值的类型、取值范围或取
值集合不同。
例 1,由于学号是数字，因此某些部门（即局
部应用）将学号定义为整数形式，而由于学号
不用参与运算，因此另一些部门（即局部应用）
将学号定义为字符型形式。
例 2,某些部门（即局部应用）以出生日期形
式表示学生的年龄，而另一些部门（即局部应
用）用整数形式表示学生的年龄。
属性冲突（续）
– 属性取值单位冲突 。
例：学生的身高，有的以米为单位，有的以厘
米为单位，有的以尺为单位。
属性冲突（续）
?属性冲突的解决方法
– 通常用讨论、协商等行政手段加以解决
⒉ 命名冲突
?两类命名冲突
– 同名异义,不同意义的对象在不同的局部应
用中具有相同的名字
例，局部应用 A中将教室称为房间
局部应用 B中将学生宿舍称为房间
– 异名同义（一义多名）,同一意义的对象在
不同的局部应用中具有不同的名字
例，有的部门把教科书称为课本
有的部门则把教科书称为教材
命名冲突（续）
?命名冲突可能发生在属性级、实体级、
联系级上。其中属性的命名冲突更为常
见。
?命名冲突的解决方法
– 通过讨论、协商等行政手段加以解决
⒊ 结构冲突
?三类结构冲突
– 同一对象在不同应用中具有不同的抽象
例，“课程”在某一局部应用中被当作实体
在另一局部应用中则被当作属性
? 解决方法：通常是把属性变换为实体或把
实体变换为属性，使同一对象具有相同的
抽象。变换时要遵循两个准则。
结构冲突（续）
– 同一实体在不同局部视图中所包含的属性不
完全相同，或者属性的排列次序不完全相同 。
? 产生原因：不同的局部应用关心的是该实
体的不同侧面。
? 解决方法：使该实体的属性取各分 E-R图
中属性的并集，再适当设计属性的次序 。
结构冲突（续）
学生
学号 姓名 性别 平均成绩
(a)在局部应用 A中
结构冲突（续）
学生
学号 姓名 出生日期 年级
(b)在局部应用 B中
所在系
结构冲突（续）
学生
学号 姓名 政治面貌
(c)在局部应用 C中
结构冲突（续）
学生
政治
面貌 学号
出生
日期 年级
(d)合并后
所在系 平均 成绩 姓名 性别
结构冲突（续）
– 实体之间的联系在不同局部视图中呈现不同
的类型
例 1,实体 E1与 E2在局部应用 A中是多对多
联系，而在局部应用 B中是一对多联系
例 2,在局部应用 X中 E1与 E2发生联系，而
在局部应用 Y中 E1,E2,E3三者之间有联
系。
? 解决方法：根据应用语义对实体联系的类
型进行综合或调整。
合并分 E-R图，生成初步 E-R图实例
例：生成学校管理系统的初步 E-R图
以合并学籍管理局部视图,课程管理局部视图为
例
这两个分 E-R图存在着多方面的冲突,
合并分 E-R图，生成初步 E-R图实例
(1) 班主任实际上也属于教师，也就是说学籍管
理中的班主任实体与课程管理中的教师实体在
一定程度上属于异名同义，可以应将学籍管理
中的班主任实体与课程管理中的教师实体统一
称为教师，统一后教师实体的属性构成为,
教师：｛ 职工号,姓名，性别，职称,
是否为优秀班主任｝
合并分 E-R图，生成初步 E-R图实例（续）
(2) 将班主任改为教师后，教师与学生之间的联
系在两个局部视图中呈现两种不同的类型，一
种是学籍管理中教师与学生之间的指导联系，
一种是课程管理中教师与学生之间的教学联系，
由于指导联系实际上可以包含在教学联系之中，
因此可以将这两种联系综合为教学联系。
合并分 E-R图，生成初步 E-R图实例（续）
(3) 性别在两个局部应用中具有不同的抽象，它
在学籍管理中为实体，在课程管理中为属性，
按照前面提到的两个原则，在合并后的 E-R图
中性别只能作为实体，否则它无法与宿舍实体
发生联系。
合并分 E-R图，生成初步 E-R图实例（续）
(4) 在两个局部 E-R图中，学生实体属性组成及次
序都存在差异，应将所有属性综合，并重新调
整次序。假设调整结果为,
学生：｛ 学号,姓名，出生日期，年龄，所在
系，年级，平均成绩｝
解决上述冲突后，学籍管理分 E-R图与课程管
理分 E-R图合并为学生管理子系统的初步 E-R
图
二、修改与重构
?基本任务
– 消除不必要的冗余，设计生成基本 E-R图
合并
初步 E-R图
分 E-R图
可能存在冗余的数据
和冗余的实体间联系
基本 E-R图
消除不必要的冗余
修改与重构（续）
1．冗余
2．消除冗余的方法
1．冗余
? 冗余的数据是指可由基本数据导出的数据,
冗余的联系是指可由其他联系导出的联系。
? 冗余数据和冗余联系容易破坏数据库的完整性，
给数据库维护增加困难
? 并不是所有的冗余数据与冗余联系都必须加以
消除，有时为了提高某些应用的效率，不得不
以冗余信息作为代价。
冗余（续）
? 设计数据库概念结构时，哪些冗余信息必须消
除，哪些冗余信息允许存在，需要根据用户的
整体需求来确定。
? 消除不必要的冗余后的初步 E-R图称为基本 E-
R图。
2．消除冗余的方法
?分析方法
– 以数据字典和数据流图为依据，根据数据字
典中关于数据项之间逻辑关系的说明来消除
冗余。
消除冗余的方法 (续 )
例，教师工资单中包括该教师的基本工资、各
种补贴、应扣除的房租水电费以及实发工资。
由于实发工资可以由前面各项推算出来，因此
可以去掉，在需要查询实发工资时根据基本工
资、各种补贴、应扣除的房租水电费数据临时
生成。
消除冗余的方法（续）
– 如果是为了提高效率，人为地保留了一些冗
余数据，则应把数据字典中数据关联的说明
作为完整性约束条件。
– 一种更好的方法是把冗余数据定义在视图中
消除冗余的方法（续）
?规范化理论
– 函数依赖的概念提供了消除冗余联系的形式
化工具
消除冗余的方法（续）
– 方法
1,确定分 E-R图实体之间的数据依赖 FL 。实
体之间一对一、一对多、多对多的联系可以
用实体码之间的函数依赖来表示。
例,
班级和学生之间一对多的联系,
学号 ?班级号
学生和课程之间多对多的联系,
（学号，课程号） ?成绩
消除冗余的方法（续）
2,求 FL的最小覆盖 GL,差集为
D = FL-GL。
逐一考察 D中的函数依赖，确定是否是冗余
的联系，若是，就把它去掉。
消除冗余的方法（续）
– 由于规范化理论受到泛关系假设的限制，应
注意下面两个问题,
1.冗余的联系一定在 D中，而 D中的联系不一
定是冗余的；
2.当实体之间存在多种联系时要将实体之间的
联系在形式上加以区分。
例 P229图 6.30中
部门和职工之间两种联系表示为,
负责人,职工号 ?部门号
部门号 ?负责人,职工号
泛关系假设
?假设存在着一个单一的关系模式
, 假设已知一个模式 Sφ,它仅由单个关系模
式组成, 问题是要设计一个模式 SD,它与
Sφ‘等价 ’, 但在某些方面更好一些,
– 从一个关系模式出发, 而不是从一组关系模
式出发实行分解
–, 等价, 的定义也是一组关系模式与一个关
系模式的, 等价,
泛关系假设 (续 )
?泛关系假设是运用规范化理论时的障碍
– 承认了泛关系假设, 就等于承认了现实世界
各实体间只能有一种联系
消除冗余，设计生成基本 E-R图实例
教程Ｐ 198图 6-16的初步 E-R图中存在着冗余数
据和冗余联系,
(1) 学生实体中的年龄属性可以由出生日期推
算出来，属于冗余数据，应该去掉。这样不仅
可以节省存储空间，而且当某个学生的出生日
期有误，进行修改后，无须相应修改年龄，减
少了产生数据不一致的机会。
学生：｛ 学号,姓名，出生日期，所在系,
年级，平均成绩｝
消除冗余，设计生成基本 E-R图实例（续）
(2) 教室实体与班级实体的上课联系可以由教室
与课程之间的开设联系、课程与学生之间的选
修联系、学生与班级之间的组成联系三者推导
出来，因此属于冗余联系，可以消去。
消除冗余，设计生成基本 E-R图实例（续）
(3) 学生实体中的平均成绩可以从选修联系中的
成绩属性中推算出来
– 由于应用中需要经常查询某个学生的平均成
绩，每次都进行这种计算效率就会太低，因
此为提高效率，保留该冗余数据
– 但定义一个触发器来保证学生的平均成绩等
于该学生各科成绩的平均值。
– 任何一科成绩修改后，或该学生学了新的科
目并有成绩后，就触发该触发器去修改该学
生的平均成绩属性值。
学生管理子系统初步 E-R图,
修改重构后的基本 E-R图,
消除冗余，设计生成基本 E-R图实例（续）
学生管理子系统的基本 E-R图与教师管理
子系统以及后勤管理子系统的基本 E-R图
合并后，生成整个学校管理系统的基本
E-R图
三、验证整体概念结构
? 视图集成后形成一个整体的数据库概念结构，
对该整体概念结构还必须进行进一步验证，确
保它能够满足下列条件,
– 整体概念结构内部必须具有一致性，不存在
互相矛盾的表达。
– 整体概念结构能准确地反映原来的每个视图
结构，包括属性、实体及实体间的联系。
– 整体概念结构能满足需要分析阶段所确定的
所有要求。
验证整体概念结构（续）
?整体概念结构最终还应该提交给用户，
征求用户和有关人员的意见，进行评审、
修改和优化，然后把它确定下来，作为
数据库的概念结构，作为进一步设计数
据库的依据 。
数据库设计
?数据库的设计过程
– 需求分析
– 概念结构设计
– 逻辑结构设计
– 物理数据库设计
– 实施
– 运行维护
设计过程中往往还会有许多反复。
概念结构设计小结
?什么是概念结构设计
现实世界
机器世界
信息世界
需求分析
概念结构设计
概念结构设计小结
?概念结构设计的步骤
– 抽象数据并设计局部视图
– 集成局部视图，得到全局概念结构
– 验证整体概念结构
概念结构设计小结
?数据抽象
– 分类
– 聚集
– 概括
概念结构设计小结
?设计局部视图
– ⒈ 选择局部应用
– ⒉ 逐一设计分 E-R图
? 标定局部应用中的实体、属性、码，实体
间的联系
? 用 E-R图描述出来
概念结构设计小结
?集成局部视图
– 1.合并分 E-R图，生成初步 E-R图
? 消除冲突
–属性冲突
–命名冲突
–结构冲突
– 2,修改与重构
? 消除不必要的冗余，设计生成基本 E-R图
–分析方法
–规范化理论
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.4 逻辑结构设计
?逻辑结构设计的任务
– 概念结构是各种数据模型的共同基础
– 为了能够用某一 DBMS实现用户需求，还必
须将概念结构进一步转化为相应的数据模型，
这正是数据库逻辑结构设计所要完成的任务。
6.4 逻辑结构设计
?逻辑结构设计的步骤
– 将概念结构转化为一般的关系, 网状, 层次
模型
– 将转化来的关系, 网状, 层次模型向特定
DBMS支持下的数据模型转换
– 对数据模型进行优化
逻辑结构设计
转化为
一般数
据模型
转化为特
定 DBMS
支持下的
据模型
优化模
型 概念结
构设计
数据库
物理设计
基本 E-R图
转换规
则
特定
DBMS的
特点与限
制
优化方
法如规
范化理
论
逻辑
模型
6.4 逻辑结构设计
6.4.1 E-R图向数据模型的转换
6.4.2 数据模型的优化
6.4.3 设计用户子模式
6.4 逻辑结构设计
6.4.1 E-R图向数据模型的转换
6.4.2 数据模型的优化
6.4.3 设计用户子模式
6.4.1 E-R图向数据模型的转换
?只介绍向关系数据模型的转换
– 转换内容
– 转换原则
E-R图向数据模型的转换（续）
?转换内容
– E-R图由实体、实体的属性和实体之间的联
系三个要素组成
– 关系模型的逻辑结构是一组关系模式的集合
– 将 E-R图转换为关系模型：将实体、实体的
属性和实体之间的联系转化为关系模式。
E-R图向关系模型的转换（续）
?转换原则
⒈ 一个 实体型 转换为一个关系模式。
– 关系的属性,实体型的属性
– 关系的码,实体型的码
例，学生实体可以转换为如下关系模式,
学生（ 学号,姓名，出生日期，所在系,
年级，平均成绩）
性别、宿舍、班级、档案材料、教师、课程、教室、
教科书都分别转换为一个关系模式。
学生
学号 出生 日期 年级 所在系 平均 成绩 姓名
E-R图向关系模型的转换（续）
⒉ 一个 m:n联系 转换为一个关系模式。
– 关系的属性,与该联系相连的各实体的码以
及联系本身的属性
– 关系的码,各实体码的组合
例，“选修”联系是一个 m:n联系，可以将它
转换为如下关系模式，其中学号与课程号为关
系的组合码,
选修（ 学号, 课程号,成绩）
E-R图向关系模型的转换（续）
⒊ 一个 1:n联系 可以转换为一个独立的关系模式，
也可以与 n端对应的关系模式合并。
– 1) 转换为一个独立的关系模式
? 关系的属性,与该联系相连的各实体的码
以及联系本身的属性
? 关系的码, n端实体的码
E-R图向关系模型的转换（续）
⒊ 一个 1:n联系 可以转换为一个独立的关系模式，
也可以与 n端对应的关系模式合并。
– 2) 与 n端对应的关系模式合并
? 合并后关系的属性,在 n端关系中加入 1
端关系的码和联系本身的属性
? 合并后关系的码,不变
– 可以减少系统中的关系个数，一般情况下更
倾向于采用这种方法
E-R图向关系模型的转换（续）
例，“组成”联系为 1:n联系。
将其转换为关系模式的两种方法,
1)使其成为一个独立的关系模式,
组成（ 学号,班级号）
2)将其学生关系模式合并,
学生（ 学号,姓名，出生日期，所在系,
年级,班级号,平均成绩）
E-R图向关系模型的转换（续）
⒋ 一个 1:1联系可以转换为一个独立的关系模式，
也可以与任意一端对应的关系模式合并。
– 1) 转换为一个独立的关系模式
? 关系的属性,与该联系相连的各实体的码
以及联系本身的属性
? 关系的候选码,每个实体的码均是该关系
的候选码
E-R图向关系模型的转换（续）
⒋ 一个 1:1联系可以转换为一个独立的关系模式，
也可以与任意一端对应的关系模式合并。
– 2) 与某一端对应的关系模式合并
? 合并后关系的属性,加入对应关系的码和
联系本身的属性
? 合并后关系的码,不变
E-R图向关系模型的转换（续）
例，“管理”联系为 1:1联系，可以有三种转换方
法,
（ 1）转换为一个独立的关系模式,
管理（ 职工号,班级号）
或 管理（职工号,班级号 ）
（ 2）“管理”联系与班级关系模式合并，则只需
在班级关系中加入教师关系的码，即职工号,
班级：（ 班级号,学生人数,职工号 ）
（ 3）“管理”联系与教师关系模式合并，则只需
在教师关系中加入班级关系的码，即班级号,
教师：（ 职工号,姓名，性别，职称,班级号,
是否为优秀班主任）
E-R图向关系模型的转换（续）
注意,
?从理论上讲,1:1联系可以与任意一端对应的
关系模式合并。
?但在一些情况下，与不同的关系模式合并效率
会大不一样。因此究竟应该与哪端的关系模式
合并需要依应用的具体情况而定。
?由于连接操作是最费时的操作，所以一般应以
尽量减少连接操作为目标。
例如，如果经常要查询某个班级的班主任姓名，
则将管理联系与教师关系合并更好些。
new
E-R图向关系模型的转换（续）
⒌ 三个或三个以上实体间的一个 多元联系 转换
为一个关系模式。
– 关系的属性,与该多元联系相连的各实体的
码以及联系本身的属性
– 关系的码,各实体码的组合
例，“讲授”联系是一个三元联系，可以将它
转换为如下关系模式，其中课程号、职工号和
书号为关系的组合码,
讲授（ 课程号，职工号，书号 ）
E-R图向关系模型的转换（续）
⒍ 同一实体集的实体间的联系，即 自联系,也
可按上述 1:1,1:n和 m:n三种情况分别处理。
例，如果教师实体集内部存在领导与被领导的
1:n自联系，我们可以将该联系与教师实体合
并，这时主码职工号将多次出现，但作用不同，
可用不同的属性名加以区分,
教师：｛ 职工号,姓名，性别，职称,系主任 ｝
new
E-R图向关系模型的转换（续）
⒎ 具有相同码的关系模式可合并。
– 目的：减少系统中的关系个数。
– 合并方法：将其中一个关系模式的全部属性
加入到另一个关系模式中，然后去掉其中的
同义属性（可能同名也可能不同名），并适
当调整属性的次序。
E-R图向关系模型的转换（续）
例，“拥有”关系模式,
拥有（ 学号,性别）
与学生关系模式,
学生（ 学号,姓名，出生日期，所在系，年级,
班级号，平均成绩）
都以学号为码，可以将它们合并为一个关系模式,
学生（ 学号,姓名，性别，出生日期，所在系,
年级，班级号，平均成绩）
E-R图向关系模型的转换（续）
实例
? 按照上述七条原则，学生管理子系统中的 18个
实体和联系可以转换为下列关系模型,
学生（ 学号,姓名，性别，出生日期，所在系,
年级，班级号，平均成绩，档案号）
性别（ 性别,宿舍楼）
宿舍（ 宿舍编号,地址，性别，人数）
班级（ 班级号,学生人数）
教师（ 职工号,姓名，性别，职称，班级号,
是否为优秀班主任）
E-R图向关系模型的转换（续）
教学（ 职工号，学号 ）
课程（ 课程号,课程名，学分，教室号）
选修（ 学号，课程号,成绩）
教科书（ 书号,书名，价钱）
教室（ 教室编号,地址，容量）
讲授（ 课程号，教师号，书号 ）
档案材料（ 档案号,…… ）
E-R图向关系模型的转换（续）
?该关系模型由 12个关系模式组成。
其中,
– 学生关系模式包含了“拥有”联系、“组成”
联系、“归档”联系所对应的关系模式
– 教师关系模式包含了“管理”联系所对应的
关系模式；
– 宿舍关系模式包含了“住宿”联系所对应的
关系模式；
– 课程关系模式包含了“开设”联系所对应的
关系模式 。
6.4 逻辑结构设计
6.4.1 E-R图向数据模型的转换
6.4.2 数据模型的优化
6.4.3 设计用户子模式
6.4.2 数据模型的优化
?数据库逻辑设计的结果不是唯一的。
?得到初步数据模型后，还应该适当地修
改、调整数据模型的结构，以进一步提
高数据库应用系统的性能，这就是数据
模型的优化。
?关系数据模型的优化通常以规范化理论
为指导。
数据模型的优化（续）
? 优化数据模型的方法
⒈ 确定数据依赖
– 按需求分析阶段所得到的语义，分别写出
每个关系模式内部各属性之间的数据依赖
以及不同关系模式属性之间数据依赖 。
数据模型的优化（续）
例，课程关系模式内部存在下列数据依赖,
课程号 → 课程名
课程号 → 学分
课程号 → 教室号
选修关系模式中存在下列数据依赖,
（学号，课程号） → 成绩
数据模型的优化（续）
学生关系模式中存在下列数据依赖,
学号 → 姓名
学号 → 性别
学号 → 出生日期
学号 → 所在系
学号 → 年级
学号 → 班级号
学号 → 平均成绩
学号 → 档案号
数据模型的优化（续）
学生关系模式的学号与选修关系模式的学号之
间存在数据依赖,
学生,学号 → 选修,学号
数据模型的优化（续）
⒉ 对于各个关系模式之间的数据依赖进行极小
化处理，消除冗余的联系。
数据模型的优化（续）
⒊ 按照数据依赖的理论对关系模式逐一进行分
析，考查是否存在部分函数依赖、传递函数
依赖、多值依赖等，确定各关系模式分别属
于第几范式。
例如经过分析可知，课程关系模式属于 BC范
式。
数据模型的优化（续）
⒋ 按照需求分析阶段得到的各种应用对数据处
理的要求，分析对于这样的应用环境这些模
式是否合适，确定是否要对它们进行合并或
分解。
数据模型的优化（续）
– 并不是规范化程度越高的关系就越优。
? 当一个应用的查询中经常涉及到两个或
多个关系模式的属性时，系统必须经常
地进行联接运算，而联系运算的代价是
相当高的，可以说关系模型低效的主要
原因就是做联接运算引起的，因此在这
种情况下，第二范式甚至第一范式也许
是最好的。
数据模型的优化（续）
? 非 BCNF的关系模式虽然从理论上分析
会存在不同程度的更新异常，但如果在
实际应用中对此关系模式只是查询，并
不执行更新操作，则就不会产生实际影
响。
? 对于一个具体应用来说，到底规范化进
行到什么程度，需要权衡响应时间和潜
在问题两者的利弊才能决定。一般说来，
第三范式就足够了。
数据模型的优化（续）
例：在关系模式
学生成绩单 (学号,英语,数学,语文,平均成绩 )
中存在下列函数依赖,
学号 → 英语
学号 → 数学
学号 → 语文
学号 → 平均成绩
(英语,数学,语文 )→ 平均成绩
数据模型的优化（续）
显然有,
学号 → (英语,数学,语文 )
因此该关系模式中存在传递函数信赖，是
2NF关系。
虽然平均成绩可以由其他属性推算出来，但
如果应用中需要经常查询学生的平均成绩，
为提高效率，我们仍然可保留该冗余数据，
对关系模式不再做进一步分解。
数据模型的优化（续）
⒌ 按照需求分析阶段得到的各种应用对数据处
理的要求，对关系模式进行必要的分解或合
并，以提高数据操作的效率和存储空间的利
用率
– 常用分解方法
? 水平分解
? 垂直分解
数据模型的优化（续）
– 水平分解
? 什么是水平分解
–把 (基本 )关系的元组分为若干子集合,
定义每个子集合为一个子关系, 以提
高系统的效率 。
? 水平分解的适用范围
–满足, 80/20原则, 的应用
–并发事务经常存取不相交的数据
数据模型的优化（续）
? 满足,80/20原则”的应用
– 80/20原则：一个大关系中，经常被使
用的数据只是关系的一部分，约 20%
–把经常使用的数据分解出来, 形成一
个子关系, 可以减少查询的数据量 。
? 并发事务经常存取不相交的数据
–如果关系 R上具有 n个事务, 而且多数
事务存取的数据不相交, 则 R可分解为
少于或等于 n个子关系, 使每个事务存
取的数据对应一个关系 。
数据模型的优化（续）
– 垂直分解
? 什么是垂直分解
–把关系模式 R的属性分解为若干子集合,
形成若干子关系模式 。
? 垂直分解的原则
–经常在一起使用的属性从 R中分解出来
形成一个子关系模式 。
数据模型的优化（续）
? 垂直分解的优点
–可以提高某些事务的效率
? 垂直分解的缺点
–可能使另一些事务不得不执行连接操
作, 从而降低了效率 。
数据模型的优化（续）
? 垂直分解的适用范围
–取决于分解后 R上的所有事务的总效率
是否得到了提高 。
? 进行垂直分解的方法
–简单情况：直观分解
–复杂情况：用第五章中的模式分解算
法
–垂直分解必须不损失关系模式的语义
(保持无损连接性和保持函数依赖 )。
6.4 逻辑结构设计
6.4.1 E-R图向数据模型的转换
6.4.2 数据模型的优化
6.4.3 设计用户子模式
6.4.3 设计用户子模式
? 定义数据库模式主要是从系统的时间效率、空
间效率、易维护等角度出发。
? 定义用户外模式时应该更注重考虑用户的习惯
与方便。包括三个方面,
设计用户子模式（续）
(1) 使用更符合用户习惯的别名
– 合并各分 E-R图曾做了消除命名冲突的工作，
以使数据库系统中同一关系和属性具有唯一
的名字。这在设计数据库整体结构时是非常
必要的。
– 但对于某些局部应用，由于改用了不符合用
户习惯的属性名，可能会使他们感到不方便,
设计用户子模式（续）
(1) 使用更符合用户习惯的别名 (续 )
– 因此在设计用户的子模式时可以重新定义某
些属性名，使其与用户习惯一致。
– 当然，为了应用的规范化，我们也不应该一
味地迁就用户。
例：负责学籍管理的用户习惯于称教师模式
的职工号为教师编号。因此可以定义视图，
在视图中职工号重定义为教师编号
设计用户子模式（续）
(2) 针对不同级别的用户定义不同的外模式，以
满足系统对安全性的要求。
设计用户子模式（续）
例,
教师关系模式中包括职工号、姓名、性别、出
生日期、婚姻状况、学历、学位、政治面貌、
职称、职务、工资、工龄、教学效果等属性。
学籍管理应用 只能查询教师的职工号、姓名、
性别、职称数据；
课程管理应用 只能查询教师的职工号、姓名、
性别、学历、学位、职称、教学效果数据；
教师管理应用 则可以查询教师的全部数据。
设计用户子模式（续）
定义两个外模式,
教师 _学籍管理 (职工号，姓名，性别，职称 )
教师 _课程管理 (工号，姓名，性别，学历,
学位，职称，教学效果 )
授权学籍管理应用只能访问教师 _学籍管理视图
授权课程管理应用只能访问教师 _课程管理视图
授权教师管理应用能访问教师表
这样就可以防止用户非法访问本来不允许他们查
询的数据，保证了系统的安全性。
设计用户子模式（续）
(3) 简化用户对系统的使用
– 如果某些局部应用中经常要使用某些很复杂
的查询，为了方便用户，可以将这些复杂查
询定义为视图。
逻辑结构设计小结
?任务
– 将概念结构转化为具体的数据模型
?逻辑结构设计的步骤
– 将概念结构转化为一般的关系、网状、层次
模型
– 将转化来的关系、网状、层次模型向特定
DBMS支持下的数据模型转换
– 对数据模型进行优化
– 设计用户子模式
逻辑结构设计小结
?E-R图向关系模型的转换内容
– 将 E-R图转换为关系模型：将实体、实体的
属性和实体之间的联系转化为关系模式。
逻辑结构设计小结
?E-R图向关系模型的转换原则
⒈ 一个 实体型 转换为一个关系模式。
⒉ 一个 m:n联系 转换为一个关系模式。
⒊ 一个 1:n联系 可以转换为一个独立的关系模式，
也可以与 n端对应的关系模式合并。
⒋ 一个 1:1联系 可以转换为一个独立的关系模式，
也可以与任意一端对应的关系模式合并。
逻辑结构设计小结
?E-R图向关系模型的转换原则
⒌ 三个或三个以上实体间的一个 多元联系 转换
为一个关系模式。
⒍ 同一实体集的实体间的联系，即 自联系,也
可按上述 1:1,1:n和 m:n三种情况分别处理。
⒎ 具有 相同码 的关系模式可合并。
逻辑结构设计小结
? 优化数据模型的方法
⒈ 确定数据依赖
⒉ 对于各个关系模式之间的数据依赖进行极小
化处理，消除冗余的联系。
⒊ 确定各关系模式分别属于第几范式。
⒋ 分析对于应用环境这些模式是否合适，确定
是否要对它们进行合并或分解。
⒌ 对关系模式进行必要的分解或合并
逻辑结构设计小结
?设计用户子模式
1,使用更符合用户习惯的别名
2,针对不同级别的用户定义不同的外模式，以满
足系统对安全性的要求。
3,简化用户对系统的使用
学生管理子系统基本 E-R图,
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.5 数据库的物理设计
?什么是数据库的物理设计
– 数据库在物理设备上的存储结构与存取方法
称为数据库的物理结构，它依赖于给定的计
算机系统。
– 为一个给定的逻辑数据模型选取一个最适合
应用环境的物理结构的过程，就是数据库的
物理设计。
6.5 数据库的物理设计
?数据库物理设计的步骤
– 确定数据库的物理结构
– 对物理结构进行评价，评价的重点是时间和
空间效率
– 如果评价结果满足原设计要求则可进入到物
理实施阶段，否则，就需要重新设计或修改
物理结构，有时甚至要返回逻辑设计阶段修
改数据模型。
数据库物理设计
确定数
据库的
物理结
构
评价数据
库的物理
结构
逻辑结
构设计
数据库
实施
物理
模型
逻辑
模型
6.5 数据库的物理设计
6.5.1 确定数据库的物理结构
6.5.2 评价物理结构
6.5 数据库的物理设计
6.5.1 确定数据库的物理结构
6.5.2 评价物理结构
6.5.3 确定数据库的物理结构
?确定数据库物理结构的内容
– 1,确定数据的存储结构
– 2,设计数据的存取路径
– 3,确定数据的存放位置
– 4,确定系统配置
1,确定数据的存储结构
?确定数据存储结构时要综合考虑存取时
间、存储空间利用率和维护代价三方面
的因素
?许多 DBMS提供聚簇功能，提高某个属
性或属性组的查询速度
确定数据的存储结构（续）
? 聚簇功能可以大大提高按聚簇码进行查询的效
率
– 例如：假设学生关系按所在系建有索引，现在要查
询信息系的所有学生名单，设信息系有 120个学生，
在极端情况下，这 120个学生所对应的元组分布在
120个不同的物理块上，由于每访问一个物理块需
要执行一次 I/O操作，因此查询即使不考虑访问索
引的 I/O次数，也要执行 120次 I/O操作。如果将同
一系的学生元组集中存放，则每读一个物理块可得
到多个满足查询条件的元组，从而显著地减少了访
问磁盘的次数
确定数据的存储结构（续）
?聚簇以后可以节省存储空间
?聚簇功能不但适用于单个关系，也适用
于多个关系
?聚簇只能提高某些特定应用的性能，而
且建立和维护聚簇的开销是很大的
确定数据的存储结构（续）
?建立聚簇需要满足的条件,
– 通过聚簇码进行访问或连接是该关系的主要
应用，与聚簇码无关的其他访问很少或者是
次要的
– 对应每个聚簇码值的平均元组数既不太少也
不太多。
– 聚簇码值相对稳定，以减少修改聚簇码值所
引起的维护开销
2,设计数据的存取路径
?在关系数据库中，选择存取路径主要是
指确定如何建立索引
3,确定数据的存放位置
?影响数据存放位置和存储结构的因素
– 硬件环境
– 应用需求
? 存取时间
? 存储空间利用率
? 维护代价
这三个方面常常是相互矛盾的
例：消除一切冗余数据虽能够节约存储空间和减少
维护代价，但往往会导致检索代价的增加
必须进行权衡，选择一个折中方案 。
确定数据的存放位置（续）
?基本原则
– 根据应用情况将
? 易变 部分与 稳定 部分
? 存取频率较高 部分与 存取频率较低 部分
分开存放，以提高系统性能
确定数据的存放位置（续）
例,
? 数据库数据备份、日志文件备份等由于只
在故障恢复时才使用，而且数据量很大，
可以考虑存放在磁带上。
? 如果计算机有多个磁盘，可以考虑将表和
索引分别放在不同的磁盘上，在查询时，
由于两个磁盘驱动器分别在工作，因而可
以保证物理读写速度比较快。
确定数据的存放位置（续）
例（续）,
? 可以将比较大的表分别放在两个磁盘上，
以加快存取速度，这在多用户环境下特别
有效。
? 可以将日志文件与数据库对象（表、索引
等）放在不同的磁盘以改进系统的性能。
4,确定系统配置
? DBMS产品一般都提供了一些存储分配参数
– 同时使用数据库的用户数
– 同时打开的数据库对象数
– 使用的缓冲区长度、个数
– 时间片大小
– 数据库的大小
– 装填因子
– 锁的数目
– 等等
确定系统配置（续）
? 系统都为这些变量赋予了合理的缺省值。但是
这些值不一定适合每一种应用环境，在进行物
理设计时，需要根据应用环境确定这些参数值，
以使系统性能最优。
? 在物理设计时对系统配置变量的调整只是初步
的，在系统运行时还要根据系统实际运行情况
做进一步的调整，以期切实改进系统性能。
6.5 数据库的物理设计
6.5.1 确定数据库的物理结构
6.5.2 评价物理结构
6.5.2 评价物理结构
?评价内容
– 对数据库物理设计过程中产生的多种方案进
行细致的评价，从中选择一个较优的方案作
为数据库的物理结构
评价物理结构（续）
?评价方法
– 定量估算各种方案
? 存储空间
? 存取时间
? 维护代价
– 对估算结果进行权衡、比较，选择出一个较
优的合理的物理结构
– 如果该结构不符合用户需求，则需要修改设
计
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.6 数据库的实施
?数据库实施的工作内容
– 用 DDL定义数据库结构
– 组织数据入库
– 编制与调试应用程序
– 数据库试运行
new
数据库实施
定义数
据库结
构
数据
装载
数据库
试运行 数据库物
理设计 数据库运 行和维护
物理
模型
编制与
调试应
用程序
数据库
系统
new
一、定义数据库结构
?确定了数据库的逻辑结构与物理结构后，
就可以用所选用的 DBMS提供的数据定
义语言（ DDL）来严格描述数据库结构。
new
定义数据库结构（续）
例，对于前面的例子，可以用 SQL语句如下定义
表结构,
CREATE TABLE 学生
(学号 CHAR(8),
……………
);
CREATE TABLE 课程
(
……………
);
…………… new
定义数据库结构（续）
接下来是在这些基本表上定义视图,
CREATE VIEW,..,
(
……………
);
……………
如果需要使用聚簇，在建基本表之前，应先用
CREATE CLUSTER语句定义聚族。 new
二、数据装载
? 数据库结构建立好后，就可以向数据库中装载
数据了。组织数据入库是数据库实施阶段最主
要的工作。
? 数据装载方法
– 人工方法
– 计算机辅助数据入库
new
数据装载（续）
? 人工方法：适用于小型系统
– 步骤
1) 筛选数据 。需要装入数据库中的数据通常都分
散在各个部门的数据文件或原始凭证中，所以
首先必须把需要入库的数据筛选出来。
2) 转换数据格式 。筛选出来的需要入库的数据，
其格式往往不符合数据库要求，还需要进行转
换。这种转换有时可能很复杂。
3) 输入数据 。将转换好的数据输入计算机中。
4) 校验数据 。检查输入的数据是否有误。
new
数据装载（续）
? 计算机辅助数据入库：适用于中大型系统
– 步骤
1) 筛选数据
2) 输入数据 。由录入员将原始数据直接输
入计算机中。数据输入子系统应提供输入
界面。
3) 校验数据 。数据输入子系统采用多种检
验技术检查输入数据的正确性。
new
数据装载（续）
4) 转换数据 。数据输入子系统根据数据库
系统的要求，从录入的数据中 抽取 有用成
分，对其进行 分类,然后 转换 数据格式。
抽取、分类和转换数据是数据输入子系统
的主要工作，也是数据输入子系统的复杂
性所在。
5) 综合数据 。数据输入子系统对转换好的
数据根据系统的要求进一步综合成最终数
据 。
new
数据装载（续）
– 如果数据库是在老的文件系统或数据库系统
的基础上设计的，则数据输入子系统只需要
完成转换数据、综合数据两项工作，直接将
老系统中的数据转换成新系统中需要的数据
格式。
– 为了保证数据能够及时入库，应在数据库物
理设计的同时编制数据输入子系统。
new
三、编制与调试应用程序
? 数据库应用程序的设计应该与数据设计并行进
行。
? 在数据库实施阶段，当数据库结构建立好后，
就可以开始编制与调试数据库的应用程序。调
试应用程序时由于数据入库尚未完成，可先使
用模拟数据。
new
四、数据库试运行
? 应用程序调试完成，并且已有一小部分数据入
库后，就可以开始数据库的试运行。
? 数据库试运行也称为联合调试，其主要工作包
括,
1） 功能测试,实际运行应用程序，执行对数
据库的各种操作，测试应用程序的各种功能。
2） 性能测试,测量系统的性能指标，分析是
否符合设计目标 。
数据库试运行（续）
? 数据库性能指标的测量
– 数据库物理设计阶段在评价数据库结构估算
时间、空间指标时，作了许多简化和假设，
忽略了许多次要因素，因此结果必然很粗糙。
– 数据库试运行则是要实际测量系统的各种性
能指标（不仅是时间、空间指标），如果结
果不符合设计目标，则需要返回物理设计阶
段，调整物理结构，修改参数；有时甚至需
要返回逻辑设计阶段，调整逻辑结构。
数据库试运行（续）
? 数据的分期入库
– 重新设计物理结构甚至逻辑结构，会导致数
据重新入库。
– 由于数据入库工作量实在太大，所以可以采
用分期输入数据的方法
? 先输入小批量数据供先期联合调试使用
? 待试运行基本合格后再输入大批量数据
? 逐步增加数据量，逐步完成运行评价
数据库试运行（续）
? 数据库的转储和恢复
– 在数据库试运行阶段，系统还不稳定，硬、
软件故障随时都可能发生
– 系统的操作人员对新系统还不熟悉，误操作
也不可避免
– 因此必须做好数据库的转储和恢复工作，尽
量减少对数据库的破坏。
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.7 数据库运行与维护
? 数据库试运行结果符合设计目标后，数据库就
可以真正投入运行了。
? 数据库投入运行标着开发任务的基本完成和维
护工作的开始
? 对数据库设计进行评价、调整、修改等维护工
作是一个长期的任务，也是设计工作的继续和
提高。
– 应用环境在不断变化
– 数据库运行过程中物理存储会不断变化
数据库运行与维护（续）
? 在数据库运行阶段，对数据库经常性的维护工
作主要是由 DBA完成的，包括,
⒈数据库的转储和恢复
– 转储和恢复是系统正式运行后最重要的维护
工作之一。
– DBA要针对不同的应用要求制定不同的转储
计划，定期对数据库和日志文件进行备份。
– 一旦发生介质故障，即利用数据库备份及日
志文件备份，尽快将数据库恢复到某种一致
性状态。
数据库运行与维护（续）
⒉ 数据库的安全性、完整性控制
– 初始定义
? DBA根据用户的实际需要授予不同的操作权限
? 根据应用环境定义不同的完整性约束条件
– 修改定义
? 当应用环境的变化，对安全性的要求也会发生变
化,DBA需要根据实际情况修改原有的安全性
控制。
? 由于应用环境的变化，数据库的完整性约束条件
也会变化，也需要 DBA不断修正，以满足用户
要求。
数据库运行与维护（续）
⒉ 数据库的安全性、完整性控制
– DBA必须根据用户的实际需要授予不同的操
作权限
– 在数据库运行过程中，由于应用环境的变化，
对安全性的要求也会发生变化,DBA需要根
据实际情况修改原有的安全性控制。
– 由于应用环境的变化，数据库的完整性约束
条件也会变化，也需要 DBA不断修正，以满
足用户要求。
数据库运行与维护（续）
⒊ 数据库性能的监督、分析和改进
– 在数据库运行过程中,DBA必须监督系统
运行，对监测数据进行分析，找出改进系统
性能的方法。
? 利用监测工具获取系统运行过程中一系列
性能参数的值
? 通过仔细分析这些数据，判断当前系统是
否处于最佳运行状态
? 如果不是，则需要通过调整某些参数来进
一步改进数据库性能
数据库运行与维护（续）
⒋ 数据库的重组织和重构造
1）数据库的重组织
– 为什么要重组织数据库
? 数据库运行一段时间后，由于记录的不断
增、删、改，会使数据库的物理存储变坏，
从而降低数据库存储空间的利用率和数据
的存取效率，使数据库的性能下降。
数据库运行与维护（续）
– 重组织的形式
? 全部重组织
? 部分重组织
–只对频繁增、删的表进行重组织
– 重组织的目标
? 提高系统性能
数据库运行与维护（续）
– 重组织的工作
? 按原设计要求
– 重新安排存储位置
– 回收垃圾
– 减少指针链
? 数据库的重组织不会改变原设计的数据逻
辑结构和物理结构
数据库运行与维护（续）
– DBMS一般都提供了供重组织数据库使用的
实用程序，帮助 DBA重新组织数据库。
数据库运行与维护（续）
2）数据库的重构造
– 为什么要进行数据库的重构造
? 数据库应用环境发生变化，会导致实体及
实体间的联系也发生相应的变化，使原有
的数据库设计不能很好地满足新的需求
–增加新的应用或新的实体
–取消某些已有应用
–改变某些已有应用
数据库运行与维护（续）
– 数据库重构造的主要工作
? 根据新环境调整数据库的模式和内模式
–增加新的数据项
–改变数据项的类型
–改变数据库的容量
–增加或删除索引
–修改完整性约束条件
数据库运行与维护（续）
– 重构造数据库的程度是有限的
? 若应用变化太大，已无法通过重构数据库
来满足新的需求，或重构数据库的代价太
大，则表明现有数据库应用系统的生命周
期已经结束，应该重新设计新的数据库系
统，开始新数据库应用系统的生命周期了。
小结
?数据库的设计过程
– 需求分析
– 概念结构设计
– 逻辑结构设计
– 物理设计
– 实施
– 运行维护
设计过程中往往还会有许多反复。
小结（续）
?数据库各级模式的形成
– 数据库的各级模式是在设计过程中逐步形成
的
– 需求分析阶段综合各个用户的应用需求（现
实世界的需求）。
– 概念设计阶段形成独立于机器特点、独立于
各个 DBMS产品的 概念模式 （信息世界模
型），用 E-R图来描述。
小结（续）
– 在逻辑设计阶段将 E-R图转换成具体的数据
库产品支持的数据模型如关系模型，形成数
据库 逻辑模式 。然后根据用户处理的要求，
安全性的考虑，在基本表的基础上再建立必
要的视图（ VIEW）形成数据的 外模式 。
– 在物理设计阶段根据 DBMS特点和处理的需
要，进行物理存储安排，设计索引，形成数
据库 内模式 。
小结（续）
?整个数据库设计过程体现了结构特征与
行为特征的紧密结合。
小结（续）
? 目前很多 DBMS都提供了一些辅助工具
（ CASE工具），为加快数据库设计速度，设
计人员可根据需要选用。
例如需求分析完成之后，设计人员可以使用
ORACLE DESIGNER 2000画 E-R图，将 E-
R图转换为关系数据模型，生成数据库结构；
画数据流图，生成应用程序。
小结（续）
– 利用 CASE工具生成的仅仅是数据库应用系
统的一个雏形，比较粗糙，数据库设计人员
需要根据用户的应用需求进一步修改该雏形，
使之成为一个完善的系统。
– 早期就选择某种 CASE工具固然能减少数据
库设计的复杂性，加快数据库设计的速度，
但往往容易将自己限制于某一个 DBMS上，
而不是根据概念设计的结果选择合适的
DBMS。
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.1 数据库设计的步骤
?数据库设计的准备工作
?数据库设计的过程
一、数据库设计的准备工作
?选定参加设计的人员
– 数据库分析设计人员
– 用户
– 程序员
– 操作员
数据库设计的准备工作 (续 )
?1,数据库分析设计人员
– 数据库设计的核心人员
– 自始至终参与数据库设计
– 其水平决定了数据库系统的质量
数据库设计的准备工作 (续 )
? 2,用户
– 在数据库设计中也是举足轻重的
– 主要参加需求分析和数据库的运行维护
– 用户积极参与带来的好处
? 加速数据库设计
? 提高数据库设计的质量
数据库设计的准备工作 (续 )
? 3,程序员
– 在系统实施阶段参与进来，负责编制程序
? 4,操作员
– 在系统实施阶段参与进来，准备软硬件环境
二,数据库设计的过程 (六个阶段 )
1,需求分析阶段
2,概念结构设计阶段
3,逻辑结构设计阶段
4,数据库物理设计阶段
5,数据库实施阶段
6,数据库运行和维护阶段
数据库设计的过程 (续 )
⒈需求分析阶段
– 准确了解与分析用户需求（包括数据与处理）
– 是整个设计过程的基础，是最困难、最耗费时间的
一步
数据库设计的过程 (续 )
⒉概念结构设计阶段
– 是整个数据库设计的关键
– 通过对用户需求进行综合、归纳与抽象，形
成一个独立于具体 DBMS的概念模型
数据库设计的过程 (续 )
⒊ 逻辑结构设计阶段
– 将概念结构转换为某个 DBMS所支持的数据
模型
– 对其进行优化
数据库设计的过程 (续 )
⒋ 数据库物理设计阶段
– 为逻辑数据模型选取一个最适合应用环境的
物理结构（包括存储结构和存取方法）
数据库设计的过程 (续 )
⒌ 数据库实施阶段
– 运用 DBMS提供的数据语言、工具及宿主语
言，根据逻辑设计和物理设计的结果
? 建立数据库
? 编制与调试应用程序
? 组织数据入库
? 并进行试运行
数据库设计的过程 (续 )
⒍ 数据库运行和维护阶段
– 数据库应用系统经过试运行后即可投入正式
运行。
– 在数据库系统运行过程中必须不断地对其进
行评价、调整与修改。
数据库设计的过程 (续 )
设计一个完善的数据库应用系统往往是
上述六个阶段的不断反复。
P184图 6-1
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.2 需求分析
6.2.1 需求分析的任务
6.2.2 需求分析的方法
6.2.3 数据字典
需求分析（续）
?需求分析就是分析用户的需要与要求
– 需求分析是设计数据库的起点
– 需求分析的结果是否准确地反映了用户的实
际要求，将直接影响到后面各个阶段的设计，
并影响到设计结果是否合理和实用
6.2 需求分析
6.2.1 需求分析的任务
6.2.2 需求分析的方法
6.2.3 数据字典
6.2.1 需求分析的任务
一、需求分析的任务
二、需求分析的重点
三、需求分析的难点
一、需求分析的任务
? 通过详细调查现实世界要处理的对象
（组织、部门、企业等），充分 了解原
系统 （手工系统或计算机系统） 工作概
况，明确用户的各种需求
? 在此基础上 确定新系统的功能 。新系统
必须充分考虑今后可能的扩充和改变，
不能仅仅按当前应用需求来设计数据库
二、需求分析的重点
? 需求分析的重点是调查、收集与分析用户在数
据管理中的 信息要求、处理要求、安全性与完
整性要求 。
? 信息要求
– 用户需要从数据库中获得信息的内容与性质
– 由用户的信息要求可以导出数据要求，即在
数据库中需要存储哪些数据
需求分析的重点（续）
? 处理要求
– 对处理 功能 的要求
– 对处理的 响应时间 的要求
– 对处理 方式 的要求 (批处理 / 联机处理 )
? 新系统的功能必须能够满足用户的信息要求、
处理要求、安全性与完整性要求。
三、需求分析的难点
?确定用户最终需求的难点
– 用户 缺少计算机知识，开始时无法确定计算
机究竟能为自己做什么，不能做什么，因此
无法一下子准确地表达自己的需求，他们所
提出的需求往往不断地变化。
– 设计人员 缺少用户的专业知识，不易理解用
户的真正需求，甚至误解用户的需求。
– 新 的硬件、软件 技术的出现 也会使用户需求
发生变化。
需求分析的难点 (续 )
?解决方法
– 设计人员必须采用有效的方法，与用户不断
深入 地进行 交流,才能逐步得以确定用户的
实际需求
6.2 需求分析
6.2.1 需求分析的任务
6.2.2 需求分析的方法
6.2.3 数据字典
6.2.2 需求分析的方法
?调查清楚用户的实际需求并进行初步分析
? 与用户达成共识
? 进一步分析与表达这些需求
一,调查与初步分析用户需求
⑴ 调查组织机构情况
– 部门的组成情况
– 各部门的职责等
调查与初步分析用户需求（续）
⑵ 调查各部门的业务活动情况。调查重点之一。
– 各个部门 输入 和使用什么数据
– 如何加工 处理 这些数据
– 输出 什么信息
– 输出到什么部门
– 输出结果的格式是什么
调查与初步分析用户需求（续）
⑶ 在熟悉业务活动的基础上，协助用户明确对
新系统的各种要求。调查重点之二。
– 信息要求
– 处理要求
– 完全性与完整性要求
调查与初步分析用户需求（续）
⑷ 对前面调查的结果进行初步分析
– 确定新系统的边界
? 确定哪些功能由计算机完成或将来准备让计算机
完成
? 确定哪些活动由人工完成
由计算机完成的功能就是新系统应该实现的功能。
二、常用调查方法
?做需求调查时，往往需要同时采用多种
方法
– 无论使用何种调查方法，都必须有用户的积
极参与和配合
– 设计人员应该和用户取得共同的语言，帮助
不熟悉计算机的用户建立数据库环境下的共
同概念，并对设计工作的最后结果共同承担
责任
常用调查方法（续）
?常用调查方法
⑴跟班作业
– 通过亲身参加业务工作了解业务活动的情况
– 能比较准确地理解用户的需求，但比较耗时
⑵开调查会
– 通过与用户座谈来了解业务活动情况及用户
需求
⑶请专人介绍
常用调查方法（续）
⑷ 询问
– 对某些调查中的问题，可以找专人询问
⑸设计调查表请用户填写
– 如果调查表设计合理，则很有效，且易于为
用户接受
⑹查阅记录
– 查阅与原系统有关的数据记录
三、进一步分析和表达用户需求
? 分析和表达用户的需求 的常用方法
– 自顶向下的结构化分析方法（ Structured
Analysis，简称 SA方法）
? SA方法从最上层的系统组织机构入手，采用逐
层分解的方式分析系统，并用数据流图和数据
字典描述系统。
进一步分析和表达用户需求（续）
1．首先把任何一个系统都抽象为,
数据流 数据流
数据
存储 信息要求
数据
来源
处理 数据
输出 处理要求
进一步分析和表达用户需求（续）
2．分解处理功能和数据
（ 1）分解处理功能
? 将处理功能的具体内容分解为若干子功能，再
将每个子功能继续分解，直到把系统的工作过
程表达清楚为止。
（ 2）分解数据
? 在处理功能逐步分解的同时，其所用的数据也
逐级分解，形成若干层次的数据流图
? 数据流图表达了数据和处理过程的关系
进一步分析和表达用户需求（续）
（ 3）表达方法
? 处理过程：用判定表或判定树来描述
? 数据：用数据字典来描述
进一步分析和表达用户需求（续）
3．将分析结果再次提交给用户，征得用户
的认可
四、需求分析小结
?P187图 6-4
需求分析小结（续）
实例：假设我们要开发一个学校管理系统。
1．经过可行性分析和初步需求调查，抽象出该系统最高
层数据流图，该系统由 教师管理子系统, 学生管理子
系统, 后勤管理子系统 组成，每个子系统分别配备一
个开发小组。
2．进一步细化各个子系统。
其中学生管理子系统开发小组通过进行进一步的需求
调查，明确了该子系统的主要功能是进行 学籍管理 和
课程管理,包括学生报到、入学、毕业的管理，学生
上课情况的管理。通过详细的信息流程分析和数据收
集后，他们生成了该子系统的数据流图。
6.2 需求分析
6.2.1 需求分析的任务
6.2.2 需求分析的方法
6.2.3 数据字典
6.2.3 数据字典
一、数据字典的用途
二、数据字典的内容
一、数据字典的用途
? 数据字典是各类数据描述的集合
? 数据字典是进行详细的数据收集和数据分析所
获得的主要结果
? 数据字典在数据库设计中占有很重要的地位
二、数据字典的内容
? 数据字典的内容
– 数据项
– 数据结构
– 数据流
– 数据存储
– 处理过程
? 数据项是数据的最小组成单位
? 若干个数据项可以组成一个数据结构
? 数据字典通过对数据项和数据结构的定义来描
述数据流、数据存储的逻辑内容。
⒈ 数据项
?数据项是不可再分的数据单位
? 对数据项的描述
数据项描述＝｛数据项名，数据项含义说明,
别名，数据类型，长度，取值范围,
取值含义，与其他数据项的逻辑关系｝
– 取值范围、与其他数据项的逻辑关系定义了
数据的完整性约束条件
⒉ 数据结构
? 数据结构反映了数据之间的组合关系。
? 一个数据结构可以由若干个数据项组成，也可
以由若干个数据结构组成，或由若干个数据项
和数据结构混合组成。
? 对数据结构的描述
数据结构描述＝｛数据结构名，含义说明,
组成,｛数据项或数据结构｝｝
⒊ 数据流
? 数据流是数据结构在系统内传输的路径。
? 对数据流的描述
数据流描述＝｛数据流名，说明，数据流来源,
数据流去向，组成,｛数据结构｝,
平均流量，高峰期流量｝
– 数据流来源是说明该数据流来自哪个过程
– 数据流去向是说明该数据流将到哪个过程去
– 平均流量是指在单位时间（每天、每周、每
月等）里的传输次数
– 高峰期流量则是指在高峰时期的数据流量
⒋ 数据存储
? 数据存储是数据结构停留或保存的地方，也是
数据流的来源和去向之一。
? 对数据存储的描述
数据存储描述＝｛数据存储名，说明，编号,
流入的数据流,流出的数据流,
组成,｛数据结构｝，数据量，存取方式｝
– 流入的数据流：指出数据来源
– 流出的数据流：指出数据去向
– 数据量：每次存取多少数据，每天（或每小时、每
周等）存取几次等信息
– 存取方法：批处理 / 联机处理；检索 / 更新；顺序
检索 / 随机检索
⒌ 处理过程
? 处理过程的具体处理逻辑一般用判定表或判定
树来描述。数据字典中只需要描述处理过程的
说明性信息
? 处理过程说明性信息的描述
处理过程描述＝｛处理过程名，说明,
输入,｛数据流｝，输出,｛数据流｝,
处理,｛简要说明｝｝
处理过程（续）
– 简要说明：主要说明该处理过程的功能及处
理要求
? 功能：该处理过程用来做什么
? 处理要求：处理频度要求（如单位时间里
处理多少事务，多少数据量）；响应时间
要求等
? 处理要求是后面物理设计的输入及性能评
价的标准
处理过程（续）
例：学生学籍管理子系统的数据字典。
数据项,以“学号”为例,
数据项,学号
含义说明：唯一标识每个学生
别名,学生编号
类型,字符型
长度,8
取值范围,00000000至 99999999
取值含义：前两位标别该学生所在年级,
后六位按顺序编号
与其他数据项的逻辑关系,
处理过程（续）
数据结构 以“学生”为例
,学生”是该系统中的一个核心数据结构,
数据结构,学生
含义说明,是学籍管理子系统的主体数据结
构，定义了一个学生的有关信息
组成,学号，姓名，性别，年龄,
所在系，年级
处理过程（续）
数据流,体检结果”可如下描述,
数据流,体检结果
说明,学生参加体格检查的最终结果
数据流来源：体检
数据流去向：批准
组成,……
平均流量,……
高峰期流量,……
处理过程（续）
数据存储,学生登记表”可如下描述,
数据存储,学生登记表
说明,记录学生的基本情况
流入数据流,……
流出数据流,……
组成,……
数据量,每年 3000张
存取方式,随机存取
处理过程（续）
处理过程,分配宿舍”可如下描述,
处理过程：分配宿舍
说明,为所有新生分配学生宿舍
输入,学生，宿舍,
输出,宿舍安排
处理,在新生报到后，为所有新生分配学
生宿舍。要求同一间宿舍只能安排
同一性别的学生，同一个学生只能
安排在一个宿舍中。每个学生的居
住面积不小于 3平方米。安排新生
宿舍其处理时间应不超过 15分钟。
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.3 概念结构设计
?什么是概念结构设计
– 需求分析阶段描述的用户应用需求是现实世
界的具体需求
– 将需求分析得到的用户需求抽象为信息结构
即概念模型的过程就是概念结构设计
– 概念结构是各种数据模型的共同基础，它比
数据模型更独立于机器、更抽象，从而更加
稳定。
– 概念结构设计是整个数据库设计的关键
概念结构设计（续）
现实世界
机器世界
信息世界
需求分析
概念结构设计
概念结构设计（续）
?概念结构设计的特点
（ 1）能真实、充分地反映现实世界，包括事物
和事物之间的联系，能满足用户对数据的处理
要求。是对现实世界的一个真实模型。
（ 2）易于理解，从而可以用它和不熟悉计算机
的用户交换意见，用户的积极参与是数据库的
设计成功的关键。
概念结构设计（续）
?概念结构设计的特点 (续 )
（ 3）易于更改，当应用环境和应用要求改变时，
容易对概念模型修改和扩充。
（ 4）易于向关系、网状、层次等各种数据模型
转换。
概念结构设计（续）
?描述概念模型的工具
– E-R模型
6.3 概念结构设计
6.3.1 概念结构设计的方法与步骤
6.3.2 数据抽象与局部视图设计
6.3.3 视图的集成
6.3 概念结构设计
6.3.1 概念结构设计的方法与步骤
6.3.2 数据抽象与局部视图设计
6.3.3 视图的集成
6.3.1 概念结构设计的方法与步骤
?设计概念结构的四类方法
– 自顶向下
? 首先定义全局概念结构的框架，然后逐
步细化
概念结构设计的方法与步骤（续）
自顶向下策略
概念结构设计的方法与步骤（续）
?设计概念结构的四类方法（续）
– 自底向上
? 首先定义各局部应用的概念结构，然后
将它们集成起来，得到全局概念结构
概念结构设计的方法与步骤（续）
自底向上策略
概念结构设计的方法与步骤（续）
– 逐步扩张
? 首先定义最重要的核心概念结构，然后
向外扩充，以滚雪球的方式逐步生成其他
概念结构，直至总体概念结构
– 混合策略
? 将自顶向下和自底向上相结合，用自顶
向下策略设计一个全局概念结构的框架，
以它为骨架集成由自底向上策略中设计的
各局部概念结构。
概念结构设计的方法与步骤（续）
逐步扩张
概念结构设计的方法与步骤（续）
?常用策略
– 自顶向下地进行需求分析
– 自底向上地设计概念结构
概念结构设计的方法与步骤（续）
?自底向上设计概念结构的步骤
– 第 1步：抽象数据并设计局部视图
– 第 2步：集成局部视图，得到全局概念结构
6.3 概念结构设计
6.3.1 概念结构设计的方法与步骤
6.3.2 数据抽象与局部视图设计
6.3.3 视图的集成
6.3.2 数据抽象与局部视图设计
?数据抽象
?局部视图设计
一、数据抽象
?概念结构是对现实世界的一种抽象
– 从实际的人、物、事和概念中抽取所关心的
共同特性，忽略非本质的细节
– 把这些特性用各种概念精确地加以描述
– 这些概念组成了某种模型
数据抽象（续）
?三种常用抽象
1,分类（ Classification）
– 定义某一类概念作为现实世界中一组对象的
类型
– 这些对象具有某些共同的特性和行为
– 它抽象了对象 值和型 之间的,is member of”
的语义
– 在 E-R模型中，实体型就是这种抽象
例,
数据抽象（续）
2,聚集（ Aggregation）
– 定义某一类型的组成成分
– 它抽象了对象内部类型和成分之间,is part
of”的语义
– 在 E-R模型中若干属性的聚集组成了实体型，
就是这种抽象
例,
数据抽象（续）
3,概括（ Generalization）
– 定义类型之间的一种子集联系
– 它抽象了类型之间的,is subset of”的语义
– 概括有一个很重要的性质：继承性。子类继
承超类上定义的所有抽象。
例,
数据抽象（续）
注：原 E-R模型不具有概括，本书对 E-R模型作
了扩充，允许定义超类实体型和子类实体型。
? 用双竖边的矩形框表示子类,
? 用直线加小圆圈表示超类 -子类的联系
数据抽象（续）
?数据抽象的用途
– 对需求分析阶段收集到的数据进行分类、组
织（聚集），形成
? 实体
? 实体的属性，标识实体的码
? 确定实体之间的联系类型 (1:1,1:n,m:n)
二、局部视图设计
设计分 E-R图的步骤,
⒈ 选择局部应用
⒉逐一设计分 E-R图
⒈ 选择局部应用
? 需求分析阶段，已用多层数据流图和数据字典
描述了整个系统。
? 设计分 E-R图首先需要根据系统的具体情况，
在多层的数据流图中 选择 一个 适当层次的数据
流图,让这组图中每一部分对应一个局部应用，
然后以这一层次的数据流图为出发点，设计分
E-R图。
选择局部应用（续）
?通常以中层数据流图作为设计分 E-R
图的依据。原因,
– 高层数据流图只能反映系统的概貌
– 中层数据流图能较好地反映系统中各局部应
用的子系统组成
– 低层数据流图过细
选择局部应用（续）
例：由于学籍管理、课程管理等都不太复
杂，因此可以它们入手设计学生管理子
系统的分 E-R图。如果局部应用比较复杂，
则可以从更下层的数据流图入手。
⒉ 逐一设计分 E-R图
?任务
– 标定局部应用中的实体、属性、码，实体间
的联系
? 将各局部应用涉及的数据分别从数据字典
中抽取出来，参照数据流图，标定各局部
应用中的实体、实体的属性、标识实体的
码，确定实体之间的联系及其类型（ 1:1，
1:n,m:n）
逐一设计分 E-R图（续）
?如何抽象实体和属性
– 实体,现实世界中一组具有某些共同特性和
行为的对象就可以抽象为一个实体。对象和
实体之间是,is member of"的关系。
例：在学校环境中，可把张三、李四等对象抽
象为学生实体。
逐一设计分 E-R图（续）
– 属性,对象类型的组成成分可以抽象为实体
的属性。组成成分与对象类型之间是,is
part of"的关系。
例：学号、姓名、专业、年级等可以抽象为学
生实体的属性。其中学号为标识学生实体的码。
逐一设计分 E-R图（续）
?如何区分实体和属性
– 实体与属性是相对而言的 。同一事物，在一
种应用环境中作为“属性”，在另一种应用
环境中就必须作为“实体”。
例：学校中的系，在某种应用环境中，它只
是作为“学生”实体的一个属性，表明一个
学生属于哪个系；而在另一种环境中，由于
需要考虑一个系的系主任、教师人数、学生
人数、办公地点等，这时它就需要作为实体
了。
逐一设计分 E-R图（续）
– 一般原则
? 属性不能再具有需要描述的性质。即属性
必须是不可分的数据项，不能再由另一些
属性组成。
? 属性不能与其他实体具有联系。联系只发
生在实体之间。
– 符合上述两条特性的事物一般作为属性对待。
– 为了简化 E-R图的处置，现实世界中的事物
凡能够作为属性对待的，应尽量作为属性。
逐一设计分 E-R图（续）
– 举例
例 1：“学生”由学号、姓名等属性进一步描
述，根据准则１，“学生”只能作为实体，
不能作为属性。
例 2：职称通常作为教师实体的属性，但在涉
及住房分配时，由于分房与职称有关，也就
是说职称与住房实体之间有联系，根据准则
２，这时把职称作为实体来处理会更合适些。
逐一设计分 E-R图（续）
?设计分 E-R图的步骤
– （ 1）以数据字典为出发点定义 E-R图。
? 数据字典中的“数据结构”、“数据流”
和“数据存储”等已是若干属性的有意义
的聚合
– （ 2）按上面给出的准则进行必要的调整。
逐一设计分 E-R图（续）
例：学籍管理局部应用中主要涉及的实体包括学
生、宿舍、档案材料、班级、班主任。
实体之间的联系,
– 由于一个宿舍可以住多个学生，而一个学生
只能住在某一个宿舍中，因此宿舍与学生之
间是 1:n的联系。
– 由于一个班级往往有若干名学生，而一个学
生只能属于一个班级，因此班级与学生之间
也是 1:n的联系 。
逐一设计分 E-R图（续）
– 由于班主任同时还要教课，因此班主任与学
生之间存在指导联系，一个班主任要教多名
学生，而一个学生只对应一个班主任，因此
班主任与学生之间也是 1:n的联系。
– 而学生和他自己的档案材料之间，班级与班
主任之间都是 1:1的联系。
学籍管理局部应用的分 E-R图草图,
逐一设计分 E-R图（续）
接下来需要进一步斟酌该 E-R图，做适当调整。
– (1) 在一般情况下，性别通常作为学生实体
的属性，但在本局部应用中，由于宿舍分配
与学生性别有关，根据准则２，应该把性别
作为实体对待。
– (2) 数据存储“学生登记表”，由于是手工
填写，供存档使用，其中有用的部分已转入
学生档案材料中，因此这里就不必作为实体
了。
最后得到学籍管理局部应用的分 E-R图,
逐一设计分 E-R图（续）
学籍管理 E-R图中省略了各个实体的属性描述,
学生：｛ 学号,姓名，出生日期｝
性别：｛ 性别 ｝
档案材料：｛ 档案号, …… ｝
班级：｛ 班级号,学生人数｝
班主任：｛ 职工号,姓名，性别,
是否为优秀班主任｝
宿舍：｛ 宿舍编号,地址，人数｝
其中有下划线的属性为实体的码。
逐一设计分 E-R图（续）
同样方法可以得到课程管理局部应用的分 E-R图
各实体的属性分别为,
学生：｛姓名,学号,性别，年龄，所在系,
年级，平均成绩｝
课程：｛ 课程号,课程名，学分｝
教师：｛ 职工号,姓名，性别，职称｝
教科书：｛ 书号,书名，价钱｝
教室：｛ 教室编号,地址，容量｝
6.3 概念结构设计
6.3.1 概念结构设计的方法与步骤
6.3.2 数据抽象与局部视图设计
6.3.3 视图的集成
6.3.4 视图的集成
?各个局部视图即分 E-R图建立好后，还需
要对它们进行合并，集成为一个整体的
数据概念结构即总 E-R图。
视图的集成（续）
?视图集成的两种方式
– 一次集成（图 6.25(a)）
? 一次集成多个分 E-R图
? 通常用于局部视图比较简单时
– 逐步累积式（图 6.25(b)）
? 首先集成两个局部视图（通常是比较关键
的两个局部视图）
? 以后每次将一个新的局部视图集成进来
视图的集成（续）
?集成局部 E-R图的步骤
1,合并
2,修改与重构
视图的集成（续）
一、合并分 E-R图，生成初步 E-R图
?各分Ｅ－Ｒ图存在冲突
– 各个局部应用所面向的问题不同
由不同的设计人员进行设计
各个分 E-R图之间必定会存在许多不一致的
地方
– 合并分 E-R图的主要工作与关键所在：合理
消除各分 E-R图的冲突
合并分 E-R图，生成初步 E-R图（续）
?冲突的种类
– 属性冲突
– 命名冲突
– 结构冲突
⒈ 属性冲突
?两类属性冲突
– 属性域冲突,属性值的类型、取值范围或取
值集合不同。
例 1,由于学号是数字，因此某些部门（即局
部应用）将学号定义为整数形式，而由于学号
不用参与运算，因此另一些部门（即局部应用）
将学号定义为字符型形式。
例 2,某些部门（即局部应用）以出生日期形
式表示学生的年龄，而另一些部门（即局部应
用）用整数形式表示学生的年龄。
属性冲突（续）
– 属性取值单位冲突 。
例：学生的身高，有的以米为单位，有的以厘
米为单位，有的以尺为单位。
属性冲突（续）
?属性冲突的解决方法
– 通常用讨论、协商等行政手段加以解决
⒉ 命名冲突
?两类命名冲突
– 同名异义,不同意义的对象在不同的局部应
用中具有相同的名字
例，局部应用 A中将教室称为房间
局部应用 B中将学生宿舍称为房间
– 异名同义（一义多名）,同一意义的对象在
不同的局部应用中具有不同的名字
例，有的部门把教科书称为课本
有的部门则把教科书称为教材
命名冲突（续）
?命名冲突可能发生在属性级、实体级、
联系级上。其中属性的命名冲突更为常
见。
?命名冲突的解决方法
– 通过讨论、协商等行政手段加以解决
⒊ 结构冲突
?三类结构冲突
– 同一对象在不同应用中具有不同的抽象
例，“课程”在某一局部应用中被当作实体
在另一局部应用中则被当作属性
? 解决方法：通常是把属性变换为实体或把
实体变换为属性，使同一对象具有相同的
抽象。变换时要遵循两个准则。
结构冲突（续）
– 同一实体在不同局部视图中所包含的属性不
完全相同，或者属性的排列次序不完全相同 。
? 产生原因：不同的局部应用关心的是该实
体的不同侧面。
? 解决方法：使该实体的属性取各分 E-R图
中属性的并集，再适当设计属性的次序 。
结构冲突（续）
学生
学号 姓名 性别 平均成绩
(a)在局部应用 A中
结构冲突（续）
学生
学号 姓名 出生日期 年级
(b)在局部应用 B中
所在系
结构冲突（续）
学生
学号 姓名 政治面貌
(c)在局部应用 C中
结构冲突（续）
学生
政治
面貌 学号
出生
日期 年级
(d)合并后
所在系 平均 成绩 姓名 性别
结构冲突（续）
– 实体之间的联系在不同局部视图中呈现不同
的类型
例 1,实体 E1与 E2在局部应用 A中是多对多
联系，而在局部应用 B中是一对多联系
例 2,在局部应用 X中 E1与 E2发生联系，而
在局部应用 Y中 E1,E2,E3三者之间有联
系。
? 解决方法：根据应用语义对实体联系的类
型进行综合或调整。
合并分 E-R图，生成初步 E-R图实例
例：生成学校管理系统的初步 E-R图
以合并学籍管理局部视图,课程管理局部视图为
例
这两个分 E-R图存在着多方面的冲突,
合并分 E-R图，生成初步 E-R图实例
(1) 班主任实际上也属于教师，也就是说学籍管
理中的班主任实体与课程管理中的教师实体在
一定程度上属于异名同义，可以应将学籍管理
中的班主任实体与课程管理中的教师实体统一
称为教师，统一后教师实体的属性构成为,
教师：｛ 职工号,姓名，性别，职称,
是否为优秀班主任｝
合并分 E-R图，生成初步 E-R图实例（续）
(2) 将班主任改为教师后，教师与学生之间的联
系在两个局部视图中呈现两种不同的类型，一
种是学籍管理中教师与学生之间的指导联系，
一种是课程管理中教师与学生之间的教学联系，
由于指导联系实际上可以包含在教学联系之中，
因此可以将这两种联系综合为教学联系。
合并分 E-R图，生成初步 E-R图实例（续）
(3) 性别在两个局部应用中具有不同的抽象，它
在学籍管理中为实体，在课程管理中为属性，
按照前面提到的两个原则，在合并后的 E-R图
中性别只能作为实体，否则它无法与宿舍实体
发生联系。
合并分 E-R图，生成初步 E-R图实例（续）
(4) 在两个局部 E-R图中，学生实体属性组成及次
序都存在差异，应将所有属性综合，并重新调
整次序。假设调整结果为,
学生：｛ 学号,姓名，出生日期，年龄，所在
系，年级，平均成绩｝
解决上述冲突后，学籍管理分 E-R图与课程管
理分 E-R图合并为学生管理子系统的初步 E-R
图
二、修改与重构
?基本任务
– 消除不必要的冗余，设计生成基本 E-R图
合并
初步 E-R图
分 E-R图
可能存在冗余的数据
和冗余的实体间联系
基本 E-R图
消除不必要的冗余
修改与重构（续）
1．冗余
2．消除冗余的方法
1．冗余
? 冗余的数据是指可由基本数据导出的数据,
冗余的联系是指可由其他联系导出的联系。
? 冗余数据和冗余联系容易破坏数据库的完整性，
给数据库维护增加困难
? 并不是所有的冗余数据与冗余联系都必须加以
消除，有时为了提高某些应用的效率，不得不
以冗余信息作为代价。
冗余（续）
? 设计数据库概念结构时，哪些冗余信息必须消
除，哪些冗余信息允许存在，需要根据用户的
整体需求来确定。
? 消除不必要的冗余后的初步 E-R图称为基本 E-
R图。
2．消除冗余的方法
?分析方法
– 以数据字典和数据流图为依据，根据数据字
典中关于数据项之间逻辑关系的说明来消除
冗余。
消除冗余的方法 (续 )
例，教师工资单中包括该教师的基本工资、各
种补贴、应扣除的房租水电费以及实发工资。
由于实发工资可以由前面各项推算出来，因此
可以去掉，在需要查询实发工资时根据基本工
资、各种补贴、应扣除的房租水电费数据临时
生成。
消除冗余的方法（续）
– 如果是为了提高效率，人为地保留了一些冗
余数据，则应把数据字典中数据关联的说明
作为完整性约束条件。
– 一种更好的方法是把冗余数据定义在视图中
消除冗余的方法（续）
?规范化理论
– 函数依赖的概念提供了消除冗余联系的形式
化工具
消除冗余的方法（续）
– 方法
1,确定分 E-R图实体之间的数据依赖 FL 。实
体之间一对一、一对多、多对多的联系可以
用实体码之间的函数依赖来表示。
例,
班级和学生之间一对多的联系,
学号 ?班级号
学生和课程之间多对多的联系,
（学号，课程号） ?成绩
消除冗余的方法（续）
2,求 FL的最小覆盖 GL,差集为
D = FL-GL。
逐一考察 D中的函数依赖，确定是否是冗余
的联系，若是，就把它去掉。
消除冗余的方法（续）
– 由于规范化理论受到泛关系假设的限制，应
注意下面两个问题,
1.冗余的联系一定在 D中，而 D中的联系不一
定是冗余的；
2.当实体之间存在多种联系时要将实体之间的
联系在形式上加以区分。
例 P229图 6.30中
部门和职工之间两种联系表示为,
负责人,职工号 ?部门号
部门号 ?负责人,职工号
泛关系假设
?假设存在着一个单一的关系模式
, 假设已知一个模式 Sφ,它仅由单个关系模
式组成, 问题是要设计一个模式 SD,它与
Sφ‘等价 ’, 但在某些方面更好一些,
– 从一个关系模式出发, 而不是从一组关系模
式出发实行分解
–, 等价, 的定义也是一组关系模式与一个关
系模式的, 等价,
泛关系假设 (续 )
?泛关系假设是运用规范化理论时的障碍
– 承认了泛关系假设, 就等于承认了现实世界
各实体间只能有一种联系
消除冗余，设计生成基本 E-R图实例
教程Ｐ 198图 6-16的初步 E-R图中存在着冗余数
据和冗余联系,
(1) 学生实体中的年龄属性可以由出生日期推
算出来，属于冗余数据，应该去掉。这样不仅
可以节省存储空间，而且当某个学生的出生日
期有误，进行修改后，无须相应修改年龄，减
少了产生数据不一致的机会。
学生：｛ 学号,姓名，出生日期，所在系,
年级，平均成绩｝
消除冗余，设计生成基本 E-R图实例（续）
(2) 教室实体与班级实体的上课联系可以由教室
与课程之间的开设联系、课程与学生之间的选
修联系、学生与班级之间的组成联系三者推导
出来，因此属于冗余联系，可以消去。
消除冗余，设计生成基本 E-R图实例（续）
(3) 学生实体中的平均成绩可以从选修联系中的
成绩属性中推算出来
– 由于应用中需要经常查询某个学生的平均成
绩，每次都进行这种计算效率就会太低，因
此为提高效率，保留该冗余数据
– 但定义一个触发器来保证学生的平均成绩等
于该学生各科成绩的平均值。
– 任何一科成绩修改后，或该学生学了新的科
目并有成绩后，就触发该触发器去修改该学
生的平均成绩属性值。
学生管理子系统初步 E-R图,
修改重构后的基本 E-R图,
消除冗余，设计生成基本 E-R图实例（续）
学生管理子系统的基本 E-R图与教师管理
子系统以及后勤管理子系统的基本 E-R图
合并后，生成整个学校管理系统的基本
E-R图
三、验证整体概念结构
? 视图集成后形成一个整体的数据库概念结构，
对该整体概念结构还必须进行进一步验证，确
保它能够满足下列条件,
– 整体概念结构内部必须具有一致性，不存在
互相矛盾的表达。
– 整体概念结构能准确地反映原来的每个视图
结构，包括属性、实体及实体间的联系。
– 整体概念结构能满足需要分析阶段所确定的
所有要求。
验证整体概念结构（续）
?整体概念结构最终还应该提交给用户，
征求用户和有关人员的意见，进行评审、
修改和优化，然后把它确定下来，作为
数据库的概念结构，作为进一步设计数
据库的依据 。
数据库设计
?数据库的设计过程
– 需求分析
– 概念结构设计
– 逻辑结构设计
– 物理数据库设计
– 实施
– 运行维护
设计过程中往往还会有许多反复。
概念结构设计小结
?什么是概念结构设计
现实世界
机器世界
信息世界
需求分析
概念结构设计
概念结构设计小结
?概念结构设计的步骤
– 抽象数据并设计局部视图
– 集成局部视图，得到全局概念结构
– 验证整体概念结构
概念结构设计小结
?数据抽象
– 分类
– 聚集
– 概括
概念结构设计小结
?设计局部视图
– ⒈ 选择局部应用
– ⒉ 逐一设计分 E-R图
? 标定局部应用中的实体、属性、码，实体
间的联系
? 用 E-R图描述出来
概念结构设计小结
?集成局部视图
– 1.合并分 E-R图，生成初步 E-R图
? 消除冲突
–属性冲突
–命名冲突
–结构冲突
– 2,修改与重构
? 消除不必要的冗余，设计生成基本 E-R图
–分析方法
–规范化理论
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.4 逻辑结构设计
?逻辑结构设计的任务
– 概念结构是各种数据模型的共同基础
– 为了能够用某一 DBMS实现用户需求，还必
须将概念结构进一步转化为相应的数据模型，
这正是数据库逻辑结构设计所要完成的任务。
6.4 逻辑结构设计
?逻辑结构设计的步骤
– 将概念结构转化为一般的关系, 网状, 层次
模型
– 将转化来的关系, 网状, 层次模型向特定
DBMS支持下的数据模型转换
– 对数据模型进行优化
逻辑结构设计
转化为
一般数
据模型
转化为特
定 DBMS
支持下的
据模型
优化模
型 概念结
构设计
数据库
物理设计
基本 E-R图
转换规
则
特定
DBMS的
特点与限
制
优化方
法如规
范化理
论
逻辑
模型
6.4 逻辑结构设计
6.4.1 E-R图向数据模型的转换
6.4.2 数据模型的优化
6.4.3 设计用户子模式
6.4 逻辑结构设计
6.4.1 E-R图向数据模型的转换
6.4.2 数据模型的优化
6.4.3 设计用户子模式
6.4.1 E-R图向数据模型的转换
?只介绍向关系数据模型的转换
– 转换内容
– 转换原则
E-R图向数据模型的转换（续）
?转换内容
– E-R图由实体、实体的属性和实体之间的联
系三个要素组成
– 关系模型的逻辑结构是一组关系模式的集合
– 将 E-R图转换为关系模型：将实体、实体的
属性和实体之间的联系转化为关系模式。
E-R图向关系模型的转换（续）
?转换原则
⒈ 一个 实体型 转换为一个关系模式。
– 关系的属性,实体型的属性
– 关系的码,实体型的码
例，学生实体可以转换为如下关系模式,
学生（ 学号,姓名，出生日期，所在系,
年级，平均成绩）
性别、宿舍、班级、档案材料、教师、课程、教室、
教科书都分别转换为一个关系模式。
学生
学号 出生 日期 年级 所在系 平均 成绩 姓名
E-R图向关系模型的转换（续）
⒉ 一个 m:n联系 转换为一个关系模式。
– 关系的属性,与该联系相连的各实体的码以
及联系本身的属性
– 关系的码,各实体码的组合
例，“选修”联系是一个 m:n联系，可以将它
转换为如下关系模式，其中学号与课程号为关
系的组合码,
选修（ 学号, 课程号,成绩）
E-R图向关系模型的转换（续）
⒊ 一个 1:n联系 可以转换为一个独立的关系模式，
也可以与 n端对应的关系模式合并。
– 1) 转换为一个独立的关系模式
? 关系的属性,与该联系相连的各实体的码
以及联系本身的属性
? 关系的码, n端实体的码
E-R图向关系模型的转换（续）
⒊ 一个 1:n联系 可以转换为一个独立的关系模式，
也可以与 n端对应的关系模式合并。
– 2) 与 n端对应的关系模式合并
? 合并后关系的属性,在 n端关系中加入 1
端关系的码和联系本身的属性
? 合并后关系的码,不变
– 可以减少系统中的关系个数，一般情况下更
倾向于采用这种方法
E-R图向关系模型的转换（续）
例，“组成”联系为 1:n联系。
将其转换为关系模式的两种方法,
1)使其成为一个独立的关系模式,
组成（ 学号,班级号）
2)将其学生关系模式合并,
学生（ 学号,姓名，出生日期，所在系,
年级,班级号,平均成绩）
E-R图向关系模型的转换（续）
⒋ 一个 1:1联系可以转换为一个独立的关系模式，
也可以与任意一端对应的关系模式合并。
– 1) 转换为一个独立的关系模式
? 关系的属性,与该联系相连的各实体的码
以及联系本身的属性
? 关系的候选码,每个实体的码均是该关系
的候选码
E-R图向关系模型的转换（续）
⒋ 一个 1:1联系可以转换为一个独立的关系模式，
也可以与任意一端对应的关系模式合并。
– 2) 与某一端对应的关系模式合并
? 合并后关系的属性,加入对应关系的码和
联系本身的属性
? 合并后关系的码,不变
E-R图向关系模型的转换（续）
例，“管理”联系为 1:1联系，可以有三种转换方
法,
（ 1）转换为一个独立的关系模式,
管理（ 职工号,班级号）
或 管理（职工号,班级号 ）
（ 2）“管理”联系与班级关系模式合并，则只需
在班级关系中加入教师关系的码，即职工号,
班级：（ 班级号,学生人数,职工号 ）
（ 3）“管理”联系与教师关系模式合并，则只需
在教师关系中加入班级关系的码，即班级号,
教师：（ 职工号,姓名，性别，职称,班级号,
是否为优秀班主任）
E-R图向关系模型的转换（续）
注意,
?从理论上讲,1:1联系可以与任意一端对应的
关系模式合并。
?但在一些情况下，与不同的关系模式合并效率
会大不一样。因此究竟应该与哪端的关系模式
合并需要依应用的具体情况而定。
?由于连接操作是最费时的操作，所以一般应以
尽量减少连接操作为目标。
例如，如果经常要查询某个班级的班主任姓名，
则将管理联系与教师关系合并更好些。
new
E-R图向关系模型的转换（续）
⒌ 三个或三个以上实体间的一个 多元联系 转换
为一个关系模式。
– 关系的属性,与该多元联系相连的各实体的
码以及联系本身的属性
– 关系的码,各实体码的组合
例，“讲授”联系是一个三元联系，可以将它
转换为如下关系模式，其中课程号、职工号和
书号为关系的组合码,
讲授（ 课程号，职工号，书号 ）
E-R图向关系模型的转换（续）
⒍ 同一实体集的实体间的联系，即 自联系,也
可按上述 1:1,1:n和 m:n三种情况分别处理。
例，如果教师实体集内部存在领导与被领导的
1:n自联系，我们可以将该联系与教师实体合
并，这时主码职工号将多次出现，但作用不同，
可用不同的属性名加以区分,
教师：｛ 职工号,姓名，性别，职称,系主任 ｝
new
E-R图向关系模型的转换（续）
⒎ 具有相同码的关系模式可合并。
– 目的：减少系统中的关系个数。
– 合并方法：将其中一个关系模式的全部属性
加入到另一个关系模式中，然后去掉其中的
同义属性（可能同名也可能不同名），并适
当调整属性的次序。
E-R图向关系模型的转换（续）
例，“拥有”关系模式,
拥有（ 学号,性别）
与学生关系模式,
学生（ 学号,姓名，出生日期，所在系，年级,
班级号，平均成绩）
都以学号为码，可以将它们合并为一个关系模式,
学生（ 学号,姓名，性别，出生日期，所在系,
年级，班级号，平均成绩）
E-R图向关系模型的转换（续）
实例
? 按照上述七条原则，学生管理子系统中的 18个
实体和联系可以转换为下列关系模型,
学生（ 学号,姓名，性别，出生日期，所在系,
年级，班级号，平均成绩，档案号）
性别（ 性别,宿舍楼）
宿舍（ 宿舍编号,地址，性别，人数）
班级（ 班级号,学生人数）
教师（ 职工号,姓名，性别，职称，班级号,
是否为优秀班主任）
E-R图向关系模型的转换（续）
教学（ 职工号，学号 ）
课程（ 课程号,课程名，学分，教室号）
选修（ 学号，课程号,成绩）
教科书（ 书号,书名，价钱）
教室（ 教室编号,地址，容量）
讲授（ 课程号，教师号，书号 ）
档案材料（ 档案号,…… ）
E-R图向关系模型的转换（续）
?该关系模型由 12个关系模式组成。
其中,
– 学生关系模式包含了“拥有”联系、“组成”
联系、“归档”联系所对应的关系模式
– 教师关系模式包含了“管理”联系所对应的
关系模式；
– 宿舍关系模式包含了“住宿”联系所对应的
关系模式；
– 课程关系模式包含了“开设”联系所对应的
关系模式 。
6.4 逻辑结构设计
6.4.1 E-R图向数据模型的转换
6.4.2 数据模型的优化
6.4.3 设计用户子模式
6.4.2 数据模型的优化
?数据库逻辑设计的结果不是唯一的。
?得到初步数据模型后，还应该适当地修
改、调整数据模型的结构，以进一步提
高数据库应用系统的性能，这就是数据
模型的优化。
?关系数据模型的优化通常以规范化理论
为指导。
数据模型的优化（续）
? 优化数据模型的方法
⒈ 确定数据依赖
– 按需求分析阶段所得到的语义，分别写出
每个关系模式内部各属性之间的数据依赖
以及不同关系模式属性之间数据依赖 。
数据模型的优化（续）
例，课程关系模式内部存在下列数据依赖,
课程号 → 课程名
课程号 → 学分
课程号 → 教室号
选修关系模式中存在下列数据依赖,
（学号，课程号） → 成绩
数据模型的优化（续）
学生关系模式中存在下列数据依赖,
学号 → 姓名
学号 → 性别
学号 → 出生日期
学号 → 所在系
学号 → 年级
学号 → 班级号
学号 → 平均成绩
学号 → 档案号
数据模型的优化（续）
学生关系模式的学号与选修关系模式的学号之
间存在数据依赖,
学生,学号 → 选修,学号
数据模型的优化（续）
⒉ 对于各个关系模式之间的数据依赖进行极小
化处理，消除冗余的联系。
数据模型的优化（续）
⒊ 按照数据依赖的理论对关系模式逐一进行分
析，考查是否存在部分函数依赖、传递函数
依赖、多值依赖等，确定各关系模式分别属
于第几范式。
例如经过分析可知，课程关系模式属于 BC范
式。
数据模型的优化（续）
⒋ 按照需求分析阶段得到的各种应用对数据处
理的要求，分析对于这样的应用环境这些模
式是否合适，确定是否要对它们进行合并或
分解。
数据模型的优化（续）
– 并不是规范化程度越高的关系就越优。
? 当一个应用的查询中经常涉及到两个或
多个关系模式的属性时，系统必须经常
地进行联接运算，而联系运算的代价是
相当高的，可以说关系模型低效的主要
原因就是做联接运算引起的，因此在这
种情况下，第二范式甚至第一范式也许
是最好的。
数据模型的优化（续）
? 非 BCNF的关系模式虽然从理论上分析
会存在不同程度的更新异常，但如果在
实际应用中对此关系模式只是查询，并
不执行更新操作，则就不会产生实际影
响。
? 对于一个具体应用来说，到底规范化进
行到什么程度，需要权衡响应时间和潜
在问题两者的利弊才能决定。一般说来，
第三范式就足够了。
数据模型的优化（续）
例：在关系模式
学生成绩单 (学号,英语,数学,语文,平均成绩 )
中存在下列函数依赖,
学号 → 英语
学号 → 数学
学号 → 语文
学号 → 平均成绩
(英语,数学,语文 )→ 平均成绩
数据模型的优化（续）
显然有,
学号 → (英语,数学,语文 )
因此该关系模式中存在传递函数信赖，是
2NF关系。
虽然平均成绩可以由其他属性推算出来，但
如果应用中需要经常查询学生的平均成绩，
为提高效率，我们仍然可保留该冗余数据，
对关系模式不再做进一步分解。
数据模型的优化（续）
⒌ 按照需求分析阶段得到的各种应用对数据处
理的要求，对关系模式进行必要的分解或合
并，以提高数据操作的效率和存储空间的利
用率
– 常用分解方法
? 水平分解
? 垂直分解
数据模型的优化（续）
– 水平分解
? 什么是水平分解
–把 (基本 )关系的元组分为若干子集合,
定义每个子集合为一个子关系, 以提
高系统的效率 。
? 水平分解的适用范围
–满足, 80/20原则, 的应用
–并发事务经常存取不相交的数据
数据模型的优化（续）
? 满足,80/20原则”的应用
– 80/20原则：一个大关系中，经常被使
用的数据只是关系的一部分，约 20%
–把经常使用的数据分解出来, 形成一
个子关系, 可以减少查询的数据量 。
? 并发事务经常存取不相交的数据
–如果关系 R上具有 n个事务, 而且多数
事务存取的数据不相交, 则 R可分解为
少于或等于 n个子关系, 使每个事务存
取的数据对应一个关系 。
数据模型的优化（续）
– 垂直分解
? 什么是垂直分解
–把关系模式 R的属性分解为若干子集合,
形成若干子关系模式 。
? 垂直分解的原则
–经常在一起使用的属性从 R中分解出来
形成一个子关系模式 。
数据模型的优化（续）
? 垂直分解的优点
–可以提高某些事务的效率
? 垂直分解的缺点
–可能使另一些事务不得不执行连接操
作, 从而降低了效率 。
数据模型的优化（续）
? 垂直分解的适用范围
–取决于分解后 R上的所有事务的总效率
是否得到了提高 。
? 进行垂直分解的方法
–简单情况：直观分解
–复杂情况：用第五章中的模式分解算
法
–垂直分解必须不损失关系模式的语义
(保持无损连接性和保持函数依赖 )。
6.4 逻辑结构设计
6.4.1 E-R图向数据模型的转换
6.4.2 数据模型的优化
6.4.3 设计用户子模式
6.4.3 设计用户子模式
? 定义数据库模式主要是从系统的时间效率、空
间效率、易维护等角度出发。
? 定义用户外模式时应该更注重考虑用户的习惯
与方便。包括三个方面,
设计用户子模式（续）
(1) 使用更符合用户习惯的别名
– 合并各分 E-R图曾做了消除命名冲突的工作，
以使数据库系统中同一关系和属性具有唯一
的名字。这在设计数据库整体结构时是非常
必要的。
– 但对于某些局部应用，由于改用了不符合用
户习惯的属性名，可能会使他们感到不方便,
设计用户子模式（续）
(1) 使用更符合用户习惯的别名 (续 )
– 因此在设计用户的子模式时可以重新定义某
些属性名，使其与用户习惯一致。
– 当然，为了应用的规范化，我们也不应该一
味地迁就用户。
例：负责学籍管理的用户习惯于称教师模式
的职工号为教师编号。因此可以定义视图，
在视图中职工号重定义为教师编号
设计用户子模式（续）
(2) 针对不同级别的用户定义不同的外模式，以
满足系统对安全性的要求。
设计用户子模式（续）
例,
教师关系模式中包括职工号、姓名、性别、出
生日期、婚姻状况、学历、学位、政治面貌、
职称、职务、工资、工龄、教学效果等属性。
学籍管理应用 只能查询教师的职工号、姓名、
性别、职称数据；
课程管理应用 只能查询教师的职工号、姓名、
性别、学历、学位、职称、教学效果数据；
教师管理应用 则可以查询教师的全部数据。
设计用户子模式（续）
定义两个外模式,
教师 _学籍管理 (职工号，姓名，性别，职称 )
教师 _课程管理 (工号，姓名，性别，学历,
学位，职称，教学效果 )
授权学籍管理应用只能访问教师 _学籍管理视图
授权课程管理应用只能访问教师 _课程管理视图
授权教师管理应用能访问教师表
这样就可以防止用户非法访问本来不允许他们查
询的数据，保证了系统的安全性。
设计用户子模式（续）
(3) 简化用户对系统的使用
– 如果某些局部应用中经常要使用某些很复杂
的查询，为了方便用户，可以将这些复杂查
询定义为视图。
逻辑结构设计小结
?任务
– 将概念结构转化为具体的数据模型
?逻辑结构设计的步骤
– 将概念结构转化为一般的关系、网状、层次
模型
– 将转化来的关系、网状、层次模型向特定
DBMS支持下的数据模型转换
– 对数据模型进行优化
– 设计用户子模式
逻辑结构设计小结
?E-R图向关系模型的转换内容
– 将 E-R图转换为关系模型：将实体、实体的
属性和实体之间的联系转化为关系模式。
逻辑结构设计小结
?E-R图向关系模型的转换原则
⒈ 一个 实体型 转换为一个关系模式。
⒉ 一个 m:n联系 转换为一个关系模式。
⒊ 一个 1:n联系 可以转换为一个独立的关系模式，
也可以与 n端对应的关系模式合并。
⒋ 一个 1:1联系 可以转换为一个独立的关系模式，
也可以与任意一端对应的关系模式合并。
逻辑结构设计小结
?E-R图向关系模型的转换原则
⒌ 三个或三个以上实体间的一个 多元联系 转换
为一个关系模式。
⒍ 同一实体集的实体间的联系，即 自联系,也
可按上述 1:1,1:n和 m:n三种情况分别处理。
⒎ 具有 相同码 的关系模式可合并。
逻辑结构设计小结
? 优化数据模型的方法
⒈ 确定数据依赖
⒉ 对于各个关系模式之间的数据依赖进行极小
化处理，消除冗余的联系。
⒊ 确定各关系模式分别属于第几范式。
⒋ 分析对于应用环境这些模式是否合适，确定
是否要对它们进行合并或分解。
⒌ 对关系模式进行必要的分解或合并
逻辑结构设计小结
?设计用户子模式
1,使用更符合用户习惯的别名
2,针对不同级别的用户定义不同的外模式，以满
足系统对安全性的要求。
3,简化用户对系统的使用
学生管理子系统基本 E-R图,
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.5 数据库的物理设计
?什么是数据库的物理设计
– 数据库在物理设备上的存储结构与存取方法
称为数据库的物理结构，它依赖于给定的计
算机系统。
– 为一个给定的逻辑数据模型选取一个最适合
应用环境的物理结构的过程，就是数据库的
物理设计。
6.5 数据库的物理设计
?数据库物理设计的步骤
– 确定数据库的物理结构
– 对物理结构进行评价，评价的重点是时间和
空间效率
– 如果评价结果满足原设计要求则可进入到物
理实施阶段，否则，就需要重新设计或修改
物理结构，有时甚至要返回逻辑设计阶段修
改数据模型。
数据库物理设计
确定数
据库的
物理结
构
评价数据
库的物理
结构
逻辑结
构设计
数据库
实施
物理
模型
逻辑
模型
6.5 数据库的物理设计
6.5.1 确定数据库的物理结构
6.5.2 评价物理结构
6.5 数据库的物理设计
6.5.1 确定数据库的物理结构
6.5.2 评价物理结构
6.5.3 确定数据库的物理结构
?确定数据库物理结构的内容
– 1,确定数据的存储结构
– 2,设计数据的存取路径
– 3,确定数据的存放位置
– 4,确定系统配置
1,确定数据的存储结构
?确定数据存储结构时要综合考虑存取时
间、存储空间利用率和维护代价三方面
的因素
?许多 DBMS提供聚簇功能，提高某个属
性或属性组的查询速度
确定数据的存储结构（续）
? 聚簇功能可以大大提高按聚簇码进行查询的效
率
– 例如：假设学生关系按所在系建有索引，现在要查
询信息系的所有学生名单，设信息系有 120个学生，
在极端情况下，这 120个学生所对应的元组分布在
120个不同的物理块上，由于每访问一个物理块需
要执行一次 I/O操作，因此查询即使不考虑访问索
引的 I/O次数，也要执行 120次 I/O操作。如果将同
一系的学生元组集中存放，则每读一个物理块可得
到多个满足查询条件的元组，从而显著地减少了访
问磁盘的次数
确定数据的存储结构（续）
?聚簇以后可以节省存储空间
?聚簇功能不但适用于单个关系，也适用
于多个关系
?聚簇只能提高某些特定应用的性能，而
且建立和维护聚簇的开销是很大的
确定数据的存储结构（续）
?建立聚簇需要满足的条件,
– 通过聚簇码进行访问或连接是该关系的主要
应用，与聚簇码无关的其他访问很少或者是
次要的
– 对应每个聚簇码值的平均元组数既不太少也
不太多。
– 聚簇码值相对稳定，以减少修改聚簇码值所
引起的维护开销
2,设计数据的存取路径
?在关系数据库中，选择存取路径主要是
指确定如何建立索引
3,确定数据的存放位置
?影响数据存放位置和存储结构的因素
– 硬件环境
– 应用需求
? 存取时间
? 存储空间利用率
? 维护代价
这三个方面常常是相互矛盾的
例：消除一切冗余数据虽能够节约存储空间和减少
维护代价，但往往会导致检索代价的增加
必须进行权衡，选择一个折中方案 。
确定数据的存放位置（续）
?基本原则
– 根据应用情况将
? 易变 部分与 稳定 部分
? 存取频率较高 部分与 存取频率较低 部分
分开存放，以提高系统性能
确定数据的存放位置（续）
例,
? 数据库数据备份、日志文件备份等由于只
在故障恢复时才使用，而且数据量很大，
可以考虑存放在磁带上。
? 如果计算机有多个磁盘，可以考虑将表和
索引分别放在不同的磁盘上，在查询时，
由于两个磁盘驱动器分别在工作，因而可
以保证物理读写速度比较快。
确定数据的存放位置（续）
例（续）,
? 可以将比较大的表分别放在两个磁盘上，
以加快存取速度，这在多用户环境下特别
有效。
? 可以将日志文件与数据库对象（表、索引
等）放在不同的磁盘以改进系统的性能。
4,确定系统配置
? DBMS产品一般都提供了一些存储分配参数
– 同时使用数据库的用户数
– 同时打开的数据库对象数
– 使用的缓冲区长度、个数
– 时间片大小
– 数据库的大小
– 装填因子
– 锁的数目
– 等等
确定系统配置（续）
? 系统都为这些变量赋予了合理的缺省值。但是
这些值不一定适合每一种应用环境，在进行物
理设计时，需要根据应用环境确定这些参数值，
以使系统性能最优。
? 在物理设计时对系统配置变量的调整只是初步
的，在系统运行时还要根据系统实际运行情况
做进一步的调整，以期切实改进系统性能。
6.5 数据库的物理设计
6.5.1 确定数据库的物理结构
6.5.2 评价物理结构
6.5.2 评价物理结构
?评价内容
– 对数据库物理设计过程中产生的多种方案进
行细致的评价，从中选择一个较优的方案作
为数据库的物理结构
评价物理结构（续）
?评价方法
– 定量估算各种方案
? 存储空间
? 存取时间
? 维护代价
– 对估算结果进行权衡、比较，选择出一个较
优的合理的物理结构
– 如果该结构不符合用户需求，则需要修改设
计
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.6 数据库的实施
?数据库实施的工作内容
– 用 DDL定义数据库结构
– 组织数据入库
– 编制与调试应用程序
– 数据库试运行
new
数据库实施
定义数
据库结
构
数据
装载
数据库
试运行 数据库物
理设计 数据库运 行和维护
物理
模型
编制与
调试应
用程序
数据库
系统
new
一、定义数据库结构
?确定了数据库的逻辑结构与物理结构后，
就可以用所选用的 DBMS提供的数据定
义语言（ DDL）来严格描述数据库结构。
new
定义数据库结构（续）
例，对于前面的例子，可以用 SQL语句如下定义
表结构,
CREATE TABLE 学生
(学号 CHAR(8),
……………
);
CREATE TABLE 课程
(
……………
);
…………… new
定义数据库结构（续）
接下来是在这些基本表上定义视图,
CREATE VIEW,..,
(
……………
);
……………
如果需要使用聚簇，在建基本表之前，应先用
CREATE CLUSTER语句定义聚族。 new
二、数据装载
? 数据库结构建立好后，就可以向数据库中装载
数据了。组织数据入库是数据库实施阶段最主
要的工作。
? 数据装载方法
– 人工方法
– 计算机辅助数据入库
new
数据装载（续）
? 人工方法：适用于小型系统
– 步骤
1) 筛选数据 。需要装入数据库中的数据通常都分
散在各个部门的数据文件或原始凭证中，所以
首先必须把需要入库的数据筛选出来。
2) 转换数据格式 。筛选出来的需要入库的数据，
其格式往往不符合数据库要求，还需要进行转
换。这种转换有时可能很复杂。
3) 输入数据 。将转换好的数据输入计算机中。
4) 校验数据 。检查输入的数据是否有误。
new
数据装载（续）
? 计算机辅助数据入库：适用于中大型系统
– 步骤
1) 筛选数据
2) 输入数据 。由录入员将原始数据直接输
入计算机中。数据输入子系统应提供输入
界面。
3) 校验数据 。数据输入子系统采用多种检
验技术检查输入数据的正确性。
new
数据装载（续）
4) 转换数据 。数据输入子系统根据数据库
系统的要求，从录入的数据中 抽取 有用成
分，对其进行 分类,然后 转换 数据格式。
抽取、分类和转换数据是数据输入子系统
的主要工作，也是数据输入子系统的复杂
性所在。
5) 综合数据 。数据输入子系统对转换好的
数据根据系统的要求进一步综合成最终数
据 。
new
数据装载（续）
– 如果数据库是在老的文件系统或数据库系统
的基础上设计的，则数据输入子系统只需要
完成转换数据、综合数据两项工作，直接将
老系统中的数据转换成新系统中需要的数据
格式。
– 为了保证数据能够及时入库，应在数据库物
理设计的同时编制数据输入子系统。
new
三、编制与调试应用程序
? 数据库应用程序的设计应该与数据设计并行进
行。
? 在数据库实施阶段，当数据库结构建立好后，
就可以开始编制与调试数据库的应用程序。调
试应用程序时由于数据入库尚未完成，可先使
用模拟数据。
new
四、数据库试运行
? 应用程序调试完成，并且已有一小部分数据入
库后，就可以开始数据库的试运行。
? 数据库试运行也称为联合调试，其主要工作包
括,
1） 功能测试,实际运行应用程序，执行对数
据库的各种操作，测试应用程序的各种功能。
2） 性能测试,测量系统的性能指标，分析是
否符合设计目标 。
数据库试运行（续）
? 数据库性能指标的测量
– 数据库物理设计阶段在评价数据库结构估算
时间、空间指标时，作了许多简化和假设，
忽略了许多次要因素，因此结果必然很粗糙。
– 数据库试运行则是要实际测量系统的各种性
能指标（不仅是时间、空间指标），如果结
果不符合设计目标，则需要返回物理设计阶
段，调整物理结构，修改参数；有时甚至需
要返回逻辑设计阶段，调整逻辑结构。
数据库试运行（续）
? 数据的分期入库
– 重新设计物理结构甚至逻辑结构，会导致数
据重新入库。
– 由于数据入库工作量实在太大，所以可以采
用分期输入数据的方法
? 先输入小批量数据供先期联合调试使用
? 待试运行基本合格后再输入大批量数据
? 逐步增加数据量，逐步完成运行评价
数据库试运行（续）
? 数据库的转储和恢复
– 在数据库试运行阶段，系统还不稳定，硬、
软件故障随时都可能发生
– 系统的操作人员对新系统还不熟悉，误操作
也不可避免
– 因此必须做好数据库的转储和恢复工作，尽
量减少对数据库的破坏。
第 6章 数据库设计
6.1 数据库设计的步骤
6.2 需求分析
6.3 概念结构设计
6.4 逻辑结构设计
6.5 数据库的物理设计
6.6 数据库实施
6.7 数据库运行与维护
6.7 数据库运行与维护
? 数据库试运行结果符合设计目标后，数据库就
可以真正投入运行了。
? 数据库投入运行标着开发任务的基本完成和维
护工作的开始
? 对数据库设计进行评价、调整、修改等维护工
作是一个长期的任务，也是设计工作的继续和
提高。
– 应用环境在不断变化
– 数据库运行过程中物理存储会不断变化
数据库运行与维护（续）
? 在数据库运行阶段，对数据库经常性的维护工
作主要是由 DBA完成的，包括,
⒈数据库的转储和恢复
– 转储和恢复是系统正式运行后最重要的维护
工作之一。
– DBA要针对不同的应用要求制定不同的转储
计划，定期对数据库和日志文件进行备份。
– 一旦发生介质故障，即利用数据库备份及日
志文件备份，尽快将数据库恢复到某种一致
性状态。
数据库运行与维护（续）
⒉ 数据库的安全性、完整性控制
– 初始定义
? DBA根据用户的实际需要授予不同的操作权限
? 根据应用环境定义不同的完整性约束条件
– 修改定义
? 当应用环境的变化，对安全性的要求也会发生变
化,DBA需要根据实际情况修改原有的安全性
控制。
? 由于应用环境的变化，数据库的完整性约束条件
也会变化，也需要 DBA不断修正，以满足用户
要求。
数据库运行与维护（续）
⒉ 数据库的安全性、完整性控制
– DBA必须根据用户的实际需要授予不同的操
作权限
– 在数据库运行过程中，由于应用环境的变化，
对安全性的要求也会发生变化,DBA需要根
据实际情况修改原有的安全性控制。
– 由于应用环境的变化，数据库的完整性约束
条件也会变化，也需要 DBA不断修正，以满
足用户要求。
数据库运行与维护（续）
⒊ 数据库性能的监督、分析和改进
– 在数据库运行过程中,DBA必须监督系统
运行，对监测数据进行分析，找出改进系统
性能的方法。
? 利用监测工具获取系统运行过程中一系列
性能参数的值
? 通过仔细分析这些数据，判断当前系统是
否处于最佳运行状态
? 如果不是，则需要通过调整某些参数来进
一步改进数据库性能
数据库运行与维护（续）
⒋ 数据库的重组织和重构造
1）数据库的重组织
– 为什么要重组织数据库
? 数据库运行一段时间后，由于记录的不断
增、删、改，会使数据库的物理存储变坏，
从而降低数据库存储空间的利用率和数据
的存取效率，使数据库的性能下降。
数据库运行与维护（续）
– 重组织的形式
? 全部重组织
? 部分重组织
–只对频繁增、删的表进行重组织
– 重组织的目标
? 提高系统性能
数据库运行与维护（续）
– 重组织的工作
? 按原设计要求
– 重新安排存储位置
– 回收垃圾
– 减少指针链
? 数据库的重组织不会改变原设计的数据逻
辑结构和物理结构
数据库运行与维护（续）
– DBMS一般都提供了供重组织数据库使用的
实用程序，帮助 DBA重新组织数据库。
数据库运行与维护（续）
2）数据库的重构造
– 为什么要进行数据库的重构造
? 数据库应用环境发生变化，会导致实体及
实体间的联系也发生相应的变化，使原有
的数据库设计不能很好地满足新的需求
–增加新的应用或新的实体
–取消某些已有应用
–改变某些已有应用
数据库运行与维护（续）
– 数据库重构造的主要工作
? 根据新环境调整数据库的模式和内模式
–增加新的数据项
–改变数据项的类型
–改变数据库的容量
–增加或删除索引
–修改完整性约束条件
数据库运行与维护（续）
– 重构造数据库的程度是有限的
? 若应用变化太大，已无法通过重构数据库
来满足新的需求，或重构数据库的代价太
大，则表明现有数据库应用系统的生命周
期已经结束，应该重新设计新的数据库系
统，开始新数据库应用系统的生命周期了。
小结
?数据库的设计过程
– 需求分析
– 概念结构设计
– 逻辑结构设计
– 物理设计
– 实施
– 运行维护
设计过程中往往还会有许多反复。
小结（续）
?数据库各级模式的形成
– 数据库的各级模式是在设计过程中逐步形成
的
– 需求分析阶段综合各个用户的应用需求（现
实世界的需求）。
– 概念设计阶段形成独立于机器特点、独立于
各个 DBMS产品的 概念模式 （信息世界模
型），用 E-R图来描述。
小结（续）
– 在逻辑设计阶段将 E-R图转换成具体的数据
库产品支持的数据模型如关系模型，形成数
据库 逻辑模式 。然后根据用户处理的要求，
安全性的考虑，在基本表的基础上再建立必
要的视图（ VIEW）形成数据的 外模式 。
– 在物理设计阶段根据 DBMS特点和处理的需
要，进行物理存储安排，设计索引，形成数
据库 内模式 。
小结（续）
?整个数据库设计过程体现了结构特征与
行为特征的紧密结合。
小结（续）
? 目前很多 DBMS都提供了一些辅助工具
（ CASE工具），为加快数据库设计速度，设
计人员可根据需要选用。
例如需求分析完成之后，设计人员可以使用
ORACLE DESIGNER 2000画 E-R图，将 E-
R图转换为关系数据模型，生成数据库结构；
画数据流图，生成应用程序。
小结（续）
– 利用 CASE工具生成的仅仅是数据库应用系
统的一个雏形，比较粗糙，数据库设计人员
需要根据用户的应用需求进一步修改该雏形，
使之成为一个完善的系统。
– 早期就选择某种 CASE工具固然能减少数据
库设计的复杂性，加快数据库设计的速度，
但往往容易将自己限制于某一个 DBMS上，
而不是根据概念设计的结果选择合适的
DBMS。
