1
第 6章 数据库设计
2
6.1 数据库设计概述
6.1.1 数据库设计的任务, 内容和特点
6.1.1.1 数据库设计的任务
?数据库设计是指根据用户需求研制数据库结构
的过程, 具体地说, 是指对于一个给定的应用
环境, 构造最优的数据库模式, 建立数据库及
其应用系统, 使之能有效的存储数据, 满足用
户的信息要求和处理要求 。
?也就是把现实世界中的数据, 根据各种应用处
理的要求, 加以合理地组织, 满足硬件和操作
系统的特性, 利用已有的 DBMS来建立能够实现
系统目标的数据库 。
3
数据库设计的任务如图 6.1所示 。
数据库
设 计
信息需求
处理需求
信息需求
典型应用程序
DBM特性 硬件和操作
系统特性
图 6.1 数据库设计的任务
4
6.1.1.2 数据库设计的内容
?数据库设计包括数据库的结构设计和数据库的
行为设计两方面的内容 。
1,数据库的结构设计
?数据库的结构设计指是根据给定的应用环境,
进行数据库的模式或子模式的设计 。
?它包括数据库的概念设计, 逻辑设计和物理设
计 。
?数据库模式是各应用程序共享的结构, 是静态
的, 稳定的, 一经形成后通常情况下是不容易
改变的, 所以结构设计又称为 静态模型设计 。
5
2,数据库的行为设计
? 数据库的行为设计是指确定数据库用户的行为和动作 。
而在数据库系统中, 用户的行为和动作指用户对数据
库的操作, 这些要通过应用程序来实现, 所以数据库
的行为设计就是应用程序的设计 。
? 用户的行为总是使数据库的内容发生变化, 所以行为
设计是动态的, 行为设计又称为 动态模型设计 。
6.1.1.3 数据库设计的特点
? 在 70年代末 80年代初, 人们为了研究数据库设计方法
学的便利, 曾主张将结构设计和行为设计两者分离,
随着数据库设计方法学的成熟和结构化分析, 设计方
法的普遍使用, 人们主张将两者作一体化的考虑, 这
样可以缩短数据库的设计周期, 提高数据库的设计效
率 。
6
?现代数据库的设计的特点是强调结构设计与行
为设计相结合, 是一种, 反复探寻, 逐步求精,
的过程 。 首先从数据模型开始设计, 以数据模
型为核心进行展开, 数据库设计和应用系统设
计相结合, 建立一个完整, 独立, 共享, 冗余
小, 安全有效的数据库系统 。
?图 6.2给出了数据库设计的全过程 。
7
现实世界
数据分析 用户业务活动分析
概念设计 功能模型
逻辑设计 事务设计
物理设计 程序说明
子模式设计 应用程序设计
加载试验数据 程序编码调试
性能考核
满意
是
否
加载数据库
运行和维护
图 6.2 数据库设计的全过程
8
6.1.2 数据库设计方法简述
? 数据库设计方法目前可分为四类,直观设计法, 规范设计法, 计
算机辅助设计法 和 自动化设计法 。
? 直观设计法也叫手工试凑法，它是最早使用的数据库设计方法。
这种方法依赖于设计者的经验和技巧，缺乏科学理论和工程原则
的支持，设计的质量很难保证，常常是数据库运行一段时间后又
发现各种问题，这样再重新进行修改，增加了系统维护的代价。
因此这种方法越来越不适应信息管理发展的需要。
? 为了改变这种情况,1978年 10月，来自三十多个国家的数据库专
家在美国新奥尔良（ New Orleans）市专门讨论了数据库设计问
题，他们运用软件工程的思想和方法，提出了数据库设计的规范，
这就是著名的新奥尔良法，它是目前公认的比较完整和权威的一
种规范设计法。新奥尔良法将数据库设计分成需求分析（分析用
户需求）、概念设计（信息分析和定义）、逻辑设计（设计实现）
和物理设计（物理数据库设计）。目前，常用的规范设计方法大
多起源于新奥尔良法，并在设计的每一阶段采用一些辅助方法来
具体实现。
? 下面简单介绍几种常用的规范设计方法。
9
1．基于 E-R模型的数据库设计方法
?基于 E-R模型的数据库设计方法是由 P.P.S.chen于
1976年提出的数据库设计方法，其基本思想是在需
求分析的基础上，用 E-R（实体 — 联系）图构造一
个反映现实世界实体之间联系的企业模式，然后再
将此企业模式转换成基于某一特定的 DBMS的概念
模式。
2,基于 3NF的数据库设计方法
?基于 3NF的数据库设计方法是由 S·Atre提出的结构
化设计方法，其基本思想是在需求分析的基础上，
确定数据库模式中的全部属性和属性间的依赖关系，
将它们组织在一个单一的关系模式中，然后再分析
模式中不符合 3NF的约束条件，将其进行投影分解，
规范成若干个 3NF关系模式的集合。
?其具体设计步骤分为五个阶段：
10
(1)设计企业模式, 利用规范化得到的 3NF关
系模式画出企业模式；
(2)设计数据库的概念模式, 把企业模式转换
成 DBMS所能接受的概念模式, 并根据概念模
式导出各个应用的外模式；
(3)设计数据库的物理模式 （ 存储模式 ） ；
(4)对物理模式进行评价；
(5) 实现数据库 。
11
3,基于视图的数据库设计方法
?此方法先从分析各个应用的数据着手, 其基本
思想是为每个应用建立自己的视图, 然后再把
这些视图汇总起来合并成整个数据库的概念模
式 。 合并过程中要解决以下问题：
(1) 消除命名冲突；
(2) 消除冗余的实体和联系；
(3)进行模式重构, 在消除了命名冲突和冗余后, 需
要对整个汇总模式进行调整, 使其满足全部完整性
约束条件 。
12
? 除了以上三种方法外, 规范化设计方法还有实体分析
法, 属性分析法和基于抽象语义的设计方法等, 这里
不再详细介绍 。
? 规范设计法从本质上来说仍然是手工设计方法, 其基
本思想是过程迭代和逐步求精 。
? 计算机辅助设计法是指在数据库设计的某些过程中模
拟某一规范化设计的方法, 并以人的知识或经验为主
导, 通过人机交互方式实现设计中的某些部分 。
? 目前许多计算机辅助软件工程 （ Computer Aided
Software Engineering,CASE） 工具可以自动或辅助
设计人员完成数据库设计过程中的很多任务,比如
SYSBASE公司的 PowerDesigner和 Oracle公司的 Design
2000。
13
6.1.3 数据库设计的步骤
?和其他软件一样, 数据库的设计过程可以使用
软件工程中的生存周期的概念来说明, 称为
,数据库设计的生存期,, 它是指从数据库研
制到不再使用它的整个时期 。
?按规范设计法可将数据库设计分为六个阶段
（ 如图 6.3所示 ）,
（ 1） 系统需求分析阶段
（ 2） 概念结构设计阶段
（ 3） 逻辑结构设计阶段
（ 4） 物理设计阶段
（ 5） 数据库实施阶段
（ 6） 数据库运行与维护阶段
14
? 该方法是分阶段完成的, 每完成一个阶段, 都要进行
设计分析, 评价一些重要的设计指标, 把设计阶段产
生的文档组织评审, 与用户进行交流 。 如果设计的数
据库不符合要求则进行修改, 这种分析和修改可能要
重复若干次, 以求最后实现的数据库能够比较精确地
模拟现实世界, 能较准确地反映用户的需求, 设计一
个完善的数据库应用系统往往是六个阶段的不断反复
的过程 。
? 数据库设计中, 前两个阶段是面向用户的应用要求,
面向具体的问题；中间两个阶段是面向数据库管理系
统；最后两个阶段是面向具体的实现方法 。 前四个阶
段可统称为, 分析和设计阶段,, 后两个阶段称为
,实现和运行阶段, 。
? 六个阶段的主要工作各有不同 。
15
1,系统需求分析阶段
?需求分析是整个数据库设计过程的基础, 要收集数
据库所有用户的信息内容和处理要求, 并加以规格
化和分析 。 这是最费时, 最复杂的一步, 但也是最
重要的一步, 相当于待构建的数据库大厦的地基,
它决定了以后各步设计的速度与质量 。 需求分析做
得不好, 可能会导致整个数据库设计返工重做 。 在
分析用户需求时, 要确保用户目标的一致性 。
2,概念结构设计阶段
?概念设计是把用户的信息要求统一到一个整体逻辑
结构中, 此结构能够表达用户的要求, 是一个独立
于任何 DBMS软件和硬件的概念模型 。
3,逻辑结构设计阶段
?逻辑设计是将上一步所得到的概念模型转换为某个
DBMS所支持的数据模型, 并对其进行优化 。
16
图 6.3 数据库的设计步骤
Y
Y
N
N
需求分析阶段
现 有应 用
,未来 应
用 数据分析
概念模型设计
转换规范, 规范
化理论 DBMS要
求 逻辑模型设计
用户应用要求
DBMS限制
物理模型设计
应 用程 序
的 使用 频
率
性能评价与预测
符合要求
？
物理实现
试运行
满意？
使用与维护
概念设计阶段
逻辑设计阶段
物理设计阶段
数据库实施阶段
数据库运行维护阶段
17
4,物理设计阶段
?物理设计是为逻辑数据模型建立一个完整的能实现的数据库
结构, 包括存储结构和存取方法 。
?上述分析和设计阶段是很重要的, 如果做出不恰当的分析或
设计, 则会导致一个不恰当或反应迟钝的应用系统 。
5,数据库实施阶段
?根据物理设计的结果把原始数据装入数据库, 建立一个具体
的数据库并编写和调试相应的应用程序 。 应用程序的开发目
标是开发一个可依赖的有效的数据库存取程序, 来满足用户
的处理要求 。
6,数据库运行与维护阶段
?这一阶段主要是收集和记录实际系统运行的数据, 数据库运
行的记录用来提高用户要求的有效信息, 用来评价数据库系
统的性能, 进一步调整和修改数据库 。 在运行中, 必须保持
数据库的完整性, 并能有效地处理数据库故障和进行数据库
恢复 。 在运行和维护阶段, 可能要对数据库结构进行修改或
扩充 。
18
? 可以看出, 以上六个阶段是从数据库应用系统设计和
开发的全过程来考察数据库设计的问题 。 因此, 它既
是数据库也是应用系统的设计过程 。 在设计过程中,
努力使数据库设计和系统其他部分的设计紧密结合,
把数据和处理的需求收集, 分析, 抽象, 设计和实现
在各个阶段同时进行, 相互参照, 相互补充, 以完善
两方面的设计 。 按照这个原则, 数据库过程各个阶段
的设计可用图 6.4描述 。
? 在上图有关处理特性的描述中, 采用的设计方法和工
具属于软件工程和管理信息系统等课程中的内容, 本
书不再讨论, 这里重点介绍数据特性的设计描述以及
在结构特性中参照处理特性设计以完善数据模型设计
的问题 。
? 以下各节分别详细介绍数据库设计的六个阶段 。
19
?需求分析是数据库设计的起点，为以后的具体
设计作准备。
?需求分析的结果是否准确的反映了用户的实际
要求，将直接影响到后面各个阶段的设计，并
影响到设计结果是否合理和实用。
?经验证明，由于设计要求的不正确或误解，直
到系统测试阶段才发现许多错误，则纠正起来
要付出很大代价。
?因此，必须高度重视系统的需求分析。
6.2 系统需求分析
20
6.2.1 需求分析的任务
?从数据库设计的角度来看，需求分析的任务是：
对现实世界要处理的对象（组织、部门、企业）
等进行详细的调查，通过对原系统的了解，收
集支持新系统的基础数据并对其进行处理，在
此基础上确定新系统的功能。
21
具体地说，需求分析阶段的任务包括以下三项：
设计阶段
设 计 描 述
数据 处理
需求分析 数据字典, 全系统中数据项,
数据流, 数据存储的描述
数据流图和定表 （ 判定树 ）
数据字典中处理过程的描述
概念结构设
计
概念模型 （ E-R图 ）
数据字典
系统说明书 。 包括：
(1) 新系统要求, 方案和概图
(2) 反映新系统信息的数据流图
逻辑结构设
计
某种数据模型
关系模型
系统结构图
非关系模型 （ 模块结构图 ）
物理设计 存储安排
存取方法选择
存取路径建立
模块设计
IPO表
实施阶段 编写模式
装入数据
数据库试运行
程序编码
编译联结
测试
运行维护 性能测试, 转储 /恢复数据库
重组和重构
新旧系统转换, 运行, 维护 （ 修正性, 适应性,
改善性维护 ）
图 6.4 数据库各个设计阶段的描述
22
1,调查分析用户的活动
?这个过程通过对新系统运行目标的研究, 对现
行系统所存在的主要问题的分析以及制约因素
的分析, 明确用户总的需求目标, 确定这个目
标的功能域和数据域 。 具体做法是：
(1) 调查组织机构情况, 包括该组织的部门组成情况,
各部门的职责和任务等 。
(2) 调查各部门的业务活动情况, 包括各部门输入和
输出的数据与格式, 所需的表格与卡片, 加工处理
这些数据的步骤, 输入输出的部门等 。
23
2,收集和分析需求数据, 确定系统边界
? 在熟悉业务活动的基础上, 协助用户明确对新系统的
各种需求, 包括用户的信息需求, 处理需求, 安全性
和完整性的需求等 。
（ 1） 信息需求指目标范围内涉及的所有实体, 实体的属性以及
实体间的联系等数据对象, 也就是用户需要从数据库中获得
信息的内容与性质 。 由信息要求可以导出数据要求, 即在数
据库中需要存储哪些数据 。
（ 2） 处理需求指用户为了得到需求的信息而对数据进行加工处
理的要求, 包括对某种处理功能的响应时间, 处理的方式
（ 批处理或联机处理 ） 等 。
（ 3） 安全性和完整性的需求 。 在定义信息需求和处理需求的同
时必须相应确定安全性和完整性约束 。
? 在收集各种需求数据后, 对前面调查的结果进行初步
分析, 确定新系统的边界, 确定哪些功能由计算机完
成或将来准备让计算机完成, 哪些活动由人工完成 。
由计算机完成的功能就是新系统应该实现的功能 。
24
3,编写需求分析说明书
? 系统分析阶段的最后是编写系统分析报告, 通常称为
需求规范说明书 。 需求规范说明书是对需求分析阶段
的一个总结 。 编写系统分析报告是一个不断反复, 逐
步深入和逐步完善的过程, 系统分析报告应包括如下
内容：
(1) 系统概况, 系统的目标, 范围, 背景, 历史和现状；
(2) 系统的原理和技术, 对原系统的改善；
(3) 系统总体结构与子系统结构说明；
(4) 系统功能说明；
(5) 数据处理概要, 工程体制和设计阶段划分；
(6) 系统方案及技术, 经济, 功能和操作上的可行性 。
? 完成系统的分析报告后，在项目单位的领导下要组织
有关技术专家评审系统分析报告，这是对需求分析结
构的再审查。审查通过后由项目方和开发方领导签字
认可。
25
随系统分析报告提供下列附件：
(1) 系统的硬件, 软件支持环境的选择及规格要求
（ 所选择的数据库管理系统, 操作系统, 汉字平台,
计算机型号及其网络环境等 ） 。
(2) 组织机构图, 组织之间联系图 t 各机构功能业务
一览图 。
(3) 数据流程图, 功能模块图和数据字典等图表 。
?如果用户同意系统分析报告和方案设计, 在与
用户进行详尽商讨的基础上, 最后签订技术协
议书 。
?系统分析报告是设计者和用户一致确认的权威
性文献, 是今后各阶段设计和工作的依据 。
26
6.2.2 需求分析的方法
? 用户参加数据库设计是数据应用系统设计的特点, 是
数据库设计理论不可分割的一部分 。
? 在数据需求分析阶段, 任何调查研究没有用户的积极
参加是寸步难行的, 设计人员应和用户取得共同的语
言, 帮助不熟悉计算机的用户建立数据库环境下的共
同概念, 所以这个过程中不同背景的人员之间互相了
解与沟通是至关重要的, 同时方法也很重要 。
? 用于需求分析的方法有多种, 主要方法有自顶向下和
自底向上两种,如图 6.5所示 。
? 其中自顶向下的分析方法（ Structured Analysis，简称
SA方法）是最简单实用的方法。 SA方法从最上层的系
统组织机构入手，采用逐层分解的方式分析系统，用
数据流图 （ Data Flow Diagram,DFD）和 数据字典
（ Data Dictionary,DD）描述系统。
? 下面对数据流图和数据字典作些简单的介绍。
27
1,数据流图
? 使用 SA方法, 任何一个系统都可抽象为图 6.6所示的数
据流图 。
? 在数据流图中, 用命名的箭头表示数据流, 用圆圈表
示处理, 用矩形或其他形状表示存储 。
? 图 6.7是一个简单的数据流图 。 一个简单的系统可用一
张数据流图来表示 。 当系统比较复杂时, 为了便于理
解, 控制其复杂性, 可以采用分层描述的方法 。 一般
用第一层描述系统的全貌, 第二层分别描述各子系统
的结构 。 如果系统结构还比较复杂, 那么可以继续细
化, 直到表达清楚为止 。 在处理功能逐步分解的同时,
它们所用的数据也逐级分解, 形成若干层次的数据流
图 。 数据流图表达了数据和处理过程的关系 。
? 在 SA方法中，处理过程的处理逻辑常常借助判定表或
判定树来描述，而系统中的数据则是借助数据字典来
描述
28
图 6.5 需求分析的方法
(a) 自顶向下的需求分析 (b) 自底向上的需求分析
……
………
…
需求
需求
…
…
需求
…
需求 需求 需求 需求
需求 需求 需求 需求
需求 需求
…
需求
…
29
图 6.6 数据流图
数据流数据流
数据存储
数据来源 处
理
数据输出
处理需求
信息需求
30
图 6.7 数据流图示例
付款凭证报销单
报销登记
报销人 审查
分录
31
2,数据字典
? 数据字典是对系统中数据的详细描述, 是各类数据结
构和属性的清单 。 它与数据流图互为注释 。
? 数据字典贯穿于数据库需求分析直到数据库运行的全
过程, 在不同的阶段其内容和用途各有区别 。
? 在需求分析阶段, 它通常包含以下五部分内容 。
(1) 数据项
?数据项是数据的最小单位, 其具体内容包括：数据顶名, 含
义说明, 别名, 类型, 长度, 取值范围, 与其他数据项的关
系 。
?其中, 取值范围, 与其他数据项的关系这两项内容定义了完
整性约束条件, 是设计数据检验功能的依据 。
(2) 数据结构
?数据结构是数据项有意义的集合 。 内容包括：数据结构名,
含义说明, 这些内容组成数据项名 。
32
(3) 数据流
?数据流可以是数据项, 也可以是数据结构, 它表示某一处理
过程中数据在系统内传输的路径 。
?内容包括：数据流名, 说明, 流出过程, 流入过程, 这些内
容组成数据项或数据结构 。
?其中, 流出过程说明该数据流由什么过程而来；流入过程说
明该数据流到什么过程 。
(4) 数据存储
?处理过程中数据的存放场所, 也是数据流的来源和去向之一 。
可以是手工凭证, 手工文档或计算机文件 。
?包括 ｛ 数据存储名, 说明, 输入数据流, 输出数据流, 组成：
｛ 数据项或数据结构 ｝, 数据量, 存取频度, 存取方式 ｝ 。
?其中, 存取频度是指每天 （ 或每小时, 或每周 ） 存取几次,
每次存取多少数据等信息 。 存取方法指的是批处理, 还是联
机处理；是检索还是更新；是顺序检索还是随机检索等 。
33
(5) 处理过程
?处理过程的处理逻辑通常用判定表或判定树来描述,
数据字典只用来描述处理过程的说明性信息 。
?处理过程包括 ｛ 处理过程名, 说明, 输入,｛ 数据
流 ｝, 输出,｛ 数据流 ｝, 处理, ｛ 简要说明 ｝｝ 。
?其中, 简要说明主要说明处理过程的功能及处理要
求 。
?功能是指该处理过程用来做什么 （ 不是怎么做 ）,
处理要求指该处理频度要求, 如单位时间里处理多
少事务, 多少数据量, 响应时间要求等, 这些处理
要求是后面物理设计的输入及性能评价的标准 。
?最终形成的数据流图和数据字典为, 需求分析
说明书, 的主要内容，这是下一步进行概念设
计的基础。
34
6.3.1 概念结构设计的必要性
? 在需求分析阶段, 设计人员充分调查并描述了用户的需求,
但这些需求只是现实世界的具体要求, 应把这些需求抽象
为信息世界的结构, 才能更好地实现用户的需求 。
? 概念设计就是将需求分析得到的用户需求抽象为信息结构,
即概念模型 。
? 在早期的数据库设计中, 概念设计并不是一个独立的设计
阶段 。 当时的设计方式是在需求分析之后, 接着就进行逻
辑设计 。 这样设计人员在进行逻辑设计时, 考虑的因素太
多, 既要考虑用户的信息, 又要考虑具体 DBMS的限制,
使得设计过程复杂化, 难以控制 。 为了改善这种状况,
P.P.S.chen设计了基于 E-R模型的数据库设计方法, 即在需
求分析和逻辑设计之间增加了一个概念设计阶段 。 在这个
阶段, 设计人员仅从用户角度看待数据及处理要求和约束,
产生一个反映用户观点的概念模型, 然后再把概念模型转
换成逻辑模型 。 这样做有三个好处：
6.3 概念结构设计
35
(1) 从逻辑设计中分离出概念设计以后, 各阶段的任
务相对单一化, 设计复杂程度大大降低, 便于组织
管理 。
(2) 概念模型不受特定的 DBMS的限制, 也独立于存储
安排和效率方面的考虑, 因而比逻辑模型更为稳定 。
(3) 概念模型不含具体的 DBMS所附加的技术细节, 更
容易为用户所理解, 因而更有可能准确反映用户的
信息需求 。
?设计概念模型的过程称为概念设计 。 概念模型
在数据库的各级模型中的地位如图 6.8所示 。
36
图 6.8 数据库各级模型的形成
应用 1
应用要求
应用 2
应用要求
应用 3
应用要求
概念模式
综合
应用 1
外模式 1
应用 2
外模式 2
应用 3
外模式 3
概念模式
概念模式
转换
映象
映象
37
6.3.2 概念模型的特点
? 概念模型作为概念设计的表达工具, 为数据库提供一
个说明性结构, 是设计数据库逻辑结构即逻辑模型的
基础 。 因此, 概念模型必须具备以下特点：
(1) 语义表达能力丰富 。 概念模型能表达用户的各种需求, 充
分反映现实世界, 包括事物和事物之间的联系, 用户对数据
的处理要求, 它是现实世界的一个真实模型 。
(2) 易于交流和理解 。 概念模型是 DBA,应用开发人员和用户之
间的主要界面, 因此, 概念模型要表达自然, 直观和容易理
解, 以便和不熟悉计算机的用户交换意见, 用户的积极参与
是保证数据库设计和成功的关键 。
(3) 易于修改和扩充 。 概念模型要能灵活地加以改变, 以反映
用户需求和现实环境的变化 。
(4) 易于向各种数据模型转换 。 概念模型独立于特定的 DBMS，
因而更加稳定, 能方便地向关系模型, 网状模型或层次模型
等各种数据模型转换 。
? 人们提出了许多概念模型，其中最著名、最实用的一
种是 E-R模型，它将现实世界的信息结构统一用属性、
实体以及它们之间的联系来描述。
38
6.3.3 概念结构设计的方法与步骤
1,概念结构设计的方法
? 设计概念结构的 E-R模型可采用四种方法 。
(1) 自顶向下 。 先定义全局概念结构 E-R模型的框架, 再逐步细
化 。 如图 6.9（ a） 所示 。
(2) 自底向上 。 先定义各局部应用的概念结构 E-R模型, 然后将
它们集成, 得到全局概念结构 E-R模型 。 如图 6.9（ b） 所示 。
(3) 逐步扩张 。 先定义最重要的核心概念 E-R模型, 然后向外扩
充, 以滚雪球的方式逐步生成其他概念结构 E-R模型 。 如图
6.9（ c） 所示 。
(4) 混合策略 。 该方法采用自顶向下和自底向上相结合的方法,
先自顶向下定义全局框架, 再以它为骨架集成自底向上方法
中设计的各个局部概念结构 。
? 其中最常用的方法是自底向上。即自顶向下地进行需
求分析，再自底向上地设计概念结构。
39
2,概念结构设计的步骤
? 自底向上的设计方法可分为两步, 如图 6.10所示：
(1) 进行数据抽象, 设计局部 E-R模型, 即设计用户视图 。
(2) 集成各局部 E-R模型, 形成全局 E-R模型, 即视图的集成 。
3,数据抽象与局部 E-R模型设计
? 概念结构是对现实世界的一种抽象 。
? 所谓抽象是对实际的人, 物, 事和概念进行人为处理,
它抽取人们关心的共同特性, 忽略非本质的细节, 并
把这些特性用各种概念精确地加以描述, 这些概念组
成了某种模型 。
? 概念结构设计首先要根据需求分析得到的结果 （ 数据
流图, 数据字典等 ） 对现实世界进行抽象, 设计各个
局部 E-R模型 。
40
图 6.9 概念结构设计的方法
…
………概念模式
…
…
(b) 自底向上的设计方法
概念模式 概念模式 概念模式
子需
求
概念模式 概念模式
全局概念模式
子需
求
子需
求
子需
求
…
全局概念模式
…
…
概念模式
概念模式 概念模式 概念模式 概念模式
(a) 自顶向下的设计方法
概念模式
需
求
(c) 逐步扩张的设计方法
核心需
求
需
求
核心
概念
结构
全局
概念
结构
…
41
图 6.10 自底向上方法的设计步骤
需求分析
数据抽象、
局部视图设计
视图集成
征求用
户意见
DFD,DD
局部 E－ R图
全局 E－ R图
逻辑结构设计
42
(1) E-R方法
? E-R方法是, 实体 -联系方法, （ Entity-Relationship
Approach） 的简称 。 它是描述现实世界概念结构模型的
有效方法 。 用 E-R方法建立的概念结构模型称为 E-R模型,
或称为 E-R图 。
? E-R图基本成分包含实体型, 属性和联系 。 （ 在第 1章已
经介绍过它们的基本概念, 这里只给出它们的表示方
法 。 ）
① 实体型：用矩形框表示, 框内标注实体名称 。 如图 6.11（ a） 所
示 。
② 属性：用椭圆形框表示, 框内标注属性名称 。 如图 6.11（ b） 所
示 。
③ 联系：指实体之间的联系, 有一对一 （ 1,1）, 一对多 （ 1,n）
或多对多 （ m, n） 三种联系类型 。 例如系主任领导系, 学生属
于某一系, 学生选修课程, 工人生产产品, 这里, 领导,,, 属
于,,, 选修,,, 生产, 表示实体间的联系, 可以作为联系名
称 。 联系用菱形框表示, 框内标注联系名称 。 如图 6.11（ c） 所示 。
43
?现实世界的复杂性导致实体联系的复杂性 。 表现在 E-R
图上可以归结为图 6.12所示的几种基本形式：
① 两个实体之间的联系, 如图 6.12（ a） 所示 。
② 两个以上实体间的联系, 如图 6.12（ b） 所示 。
③ 同一实体集内部各实体之间的联系, 例如一个部门内的职工
有领导与被领导的联系, 即某一职工 （ 干部 ） 领导若干名职工,
而一个职工 （ 普通员工 ） 仅被另外一个职工直接领导, 这就构
成了实体内部的一对多的联系 。 如图 6.12（ c） 所示 。
?需要注意的是，因为联系本身也是一种实体型，所以
联系也可以有属性。如果一个联系具有属性，则这些
联系也要用无向边与该联系连接起来。例如，学生选
修的课程有相应的成绩。这里的, 成绩, 既不是学生
的属性，也不是课程的属性，只能是学生选修课程的
联系的属性。图 6.12（ b）中, 供应数量, 是, 供应,
联系的属性。
44
?E-R图的基本思想就是分别用矩形框、椭圆形
框和菱形框表示实体、属性和联系，使用无向
边将属性与其相应的实体连接起来，并将联系
分别和有关实体相连接，注明联系类型。
?图 6.12为几个 E-R图的例子，只给出了实体及
其 E-R图，省略了实体的属性。
?图 6.13为一个描述学生与课程联系的完整的 E-
R图。
45
6.11 E-R图的三种基本成份及其图形的表示方法
学生 选修学号
(a)实体 (b)属性 (c)联系
46
图 6.12 实体及其联系图
(a)两个实体之间的联系
学生
选修 成绩
课程
系主任
领导
系
学生
属于
系
1
1
n
1
系
主
任
n
(c)实体集内部的联系
m
职工
领导
1 n
供应商
供应 数量
零件项目
m
n n
(b)多个实体之间的联系
47
图 6.13 学生与课程联系的完整的 E－ R图
课
程
名
学生
学
号
姓
名
性
别
年
龄
系
别
课程
课程
号
学
分
n
选修
成
绩
m
48
(2) 数据抽象
? 在系统需求分析阶段, 最后得到了多层数据流图, 数
据字典和系统分析报告 。 建立局部 E-R模型, 就是根据
系统的具体情况, 在多层的数据流图中选择一个适当
层次的数据流图, 作为设计分 E-R图的出发点, 让这组
图中毎一部分对应一个局部应用 。 在前面选好的某一
层次的数据流图中, 每个局部应用都对应了一组数据
流图, 局部应用所涉及的数据存储在数据字典中 。 现
在就是要将这些数据从数据字典中抽取出来, 参照数
据流图, 确定每个局部应用包含哪些实体, 这些实体
又包含哪些属性, 以及实体之间的联系及其类型 。
? 设计局部 E-R模型的关键就是正确划分实体和属性 。
实体和属性之间在形式上并无可以明显区分的界限,
通常是按照现实世界中事物的自然划分来定义实体和
属性, 将现实世界中的事物进行数据抽象, 得到实体
和属性 。
? 一般有两种数据抽象：分类和聚集 。
49
① 分类 （ Classification）
?分类定义某一类概念作为现实世界中一组对象的类
型, 将一组具有某些共同特性和行为的对象抽象为
一个实体 。 对象和实体之间是, is member of”的
关系 。
?例如, 在教学管理中,, 赵亦, 是一名学生, 表示
,赵亦, 是学生中的一员, 她具有学生们共同的特
性和行为 。
② 聚集 （ Aggregation）
?聚集定义某一类型的组成成份, 将对象类型的组成
成份抽象为实体的属性 。 组成成份与对象类型之间
是, is part of”的关系 。
?例如, 学号, 姓名, 性别, 年龄, 系别等可以抽象
为学生实体的属性, 其中学号是标识学生实体的主
键 。
50
(2) 局部 E-R模型设计
? 数据抽象后得到了实体和属性, 实际上实体和属性是
相对而言的, 往往要根据实际情况进行必要的调整 。
在调整中要遵循两条原则：
① 实体具有描述信息, 而属性没有 。 即属性必须是不可分的数
据项, 不能再由另一些属性组成 。
② 属性不能与其他实体具有联系, 联系只能发生在实体之间 。
?例如：学生是一个实体, 学号, 姓名, 性别, 年龄, 系别等
是学生实体的属性, 系别只表示学生属于哪个系, 不涉及系
的具体情况, 换句话说, 没有需要进一步描述的特性, 即是
不可分的数据项, 则根据原则 ① 可以作为学生实体的属性 。
但如果考虑一个系的系主任, 学生人数, 教师人数, 办公地
点等, 则系别应看作一个实体 。 如图 6.14所示 。
?又如,,职称, 为教师实体的属性，但在涉及住房分配时，
由于分房与职称有关，即职称与住房实体之间有联系，则根
据原则②，职称应作为一个实体。如图 6.15所示。
51
图 6.14 系别作为一个属性或实体
学生
学生 系别
属
于
n 1
m 姓
名
性
别
年
龄
系
别
学
号
姓
名
性
别
年
龄
系主任 学生人
数
教师人
数
办公地
点
52
图 6.15 职称作为一个属性或实体
聘任
教师 教师
n 1
职称
分
配
住房
姓名 性别 职称 姓名 性别
53
? 此外, 我们可能会遇到这样的情况, 同一数据项, 可
能由于环境和要求的不同, 有时作为属性, 有时则作
为实体, 此时必须根据实际情况而定 。 一般情况下,
凡能作为属性对待的, 应尽量作为属性, 以简化 E-R图
的处理 。
? 下面举例说明局部 E-R模型设计 。
? 在简单的教务管理系统中, 有如下语义约束 。
① 一个学生可选修多门课程, 一门课程可为多个学生选修, 因
此学生和课程是多对多的联系；
② 一个教师可讲授多门课程, 一门课程可为多个教师讲授, 因
此教师和课程也是多对多的联系；
③ 一个系可有多个教师, 一个教师只能属于一个系, 因此系和
教师是一对多的联系, 同样系和学生也是一对多的联系 。
? 根据上述约定，可以得到如图 6.16所示的学生选课局
部Ｅ－Ｒ图和如图 6.17所示的教师任课局部Ｅ－Ｒ图。
形成局部 E-R模型后，应该返回去征求用户意见，以
求改进和完善，使之如实地反映现实世界。
? E-R图的优点就是易于被用户理解，便于交流。
54
图 6.16 学生选课局部Ｅ－Ｒ图
m
m n
m
１
名称 系
拥
有
１
学生
学号 姓名 性别 年龄
开课
课程 教师
号
课程号 课程名
选修
成绩
平均成绩
55
图 6.17 教师任课局部Ｅ－Ｒ图
1
m
教师
号
姓名 性别 职称 课程
号
教师 讲
授
课程n
属
于
单位
单位
名
电话
m
56
4,全局 E-R模型设计
?局部 E-R模型设计完成之后, 下一步就是集成
各局部 E-R模型, 形成全局 E-R模型, 即视图的
集成 。 视图集成的方法有两种：
① 多元集成法, 一次性将多个局部 E-R图合并为一个
全局 E-R图, 如图 6.18（ a） 所示 。
② 二元集成法, 首先集成两个重要的局部视图, 以后
用累加的方法逐步将一个新的视图集成进来, 如图
6.18（ b） 所示 。 在实际应用中, 可以根据系统复杂
性选择这两种方案 。 一般采用逐步集成的方法, 如
果局部视图比较简单, 可以采用多元集成法 。 一般
情况下, 采用二元集成法, 即每次只综合两个视图,
这样可降低难度 。 无论使用哪一种方法, 视图集成
均分成两个步骤, 如图 6.19所示 。
① 合并, 消除各局部 E-R图之间的冲突, 生成初步 E-R图 。
② 优化, 消除不必要的冗余, 生成基本 E-R图 。
57
图 6.18 局部视图合并成全局视图
(a) 多元集成法
局部 E－ R图 1 …局部 E－ R图 2 局部 E－ R图 n
初步 E－ R图
基本 E－ R图
局部 E－ R图 1 局部 E－ R图 2
合并 E－ R图 12 局部 E－ R图 3
…
初步 E－ R图
基本 E－ R图
(b) 二元集成法
58
图 6.19 视图集成
局部Ｅ－Ｒ图
合并
（ 消 除冲 突
）
修改 与重 构
（ 消 除不 必
要的冗余 ）
集成视图
基本Ｅ－Ｒ图
初步Ｅ－Ｒ图 分析 规范化理论
59
(1) 合并局部 E-R图, 生成初步 E-R图
? 这个步骤将所有的局部 E-R图综合成全局概念结构 。
? 全局概念结构它不仅要支持所有的局部 E-R模型, 而且
必须合理地表示一个完整, 一致的数据库概念结构 。
? 由于各个局部应用不同, 通常由不同的设计人员进行
局部 E-R图设计, 因此, 各局部 E-R图不可避免地会有
许多不一致的的地方, 我们称之为 冲突 。
? 合并局部 E-R图时并不能简单地将各个 E-R图画到一起,
而必须消除各个局部 E-R图中的不一致, 使合并后的
全局概念结构不仅支持所有的局部 E-R模型, 而且必
须是一个能为全系统中所有用户共同理解和接受的完
整的概念模型 。
? 合并局部 E-R图的关键就是合理消除各局部 E-R图中的
冲突 。
60
?E-R图中的冲突有三种：属性冲突, 命名
冲突和结构冲突 。
① 属性冲突
?属性冲突又分为属性值域冲突和属性的取值单
位冲突 。
a.属性值域冲突, 即属性值的类型, 取值范围或取
值集合不同 。 比如学号, 有些部门将其定义为数值
型, 而有些部门将其定义为字符型 。 又如年龄, 有
的可能用出生年月表示, 有的则用整数表示 。
b.属性的取值单位冲突 。 比如零件的重量, 有的以
公斤为单位, 有的以斤为单位, 有的则以克为单位 。
?属性冲突属于用户业务上的约定, 必须与用户
协商后解决 。
61
② 命名冲突
? 命名不一致可能发生在实体名, 属性名或联系名之间,
其中属性的命名冲突更为常见 。
? 一般表现为同名异义或异名同义 （ 实体, 属性, 联系
名 ） 。
a.同名异义, 即同一名字的对象在不同的部门中具有不同的
意义 。
比如,, 单位, 在某些部门表示为人员所在的部门, 而在
某些部门可能表示物品的重量, 长度等属性 。
b.异名同义, 即同一意义的对象在不同的部门中具有不同的
名称 。
比如, 对于, 房间, 这个名称, 在教务管理部门中对应着
为教室, 而在后勤管理部门对应为学生宿舍 。
? 命名冲突的解决方法同属性冲突, 需要与各部门协商,
讨论后加以解决 。
62
③ 结构冲突
a.同一对象在不同应用中有不同的抽象, 可能为实体,
也可能为属性 。 例如, 教师的职称在某一局部应用
中被当作实体, 而在另一局部应用中被当作属性 。
这类冲突在解决时, 就是使同一对象在不同应用中具有相同的
抽象, 或把实体转换为属性, 或把属性转换为实体 。 但都要符
合 6.3.3中所介绍的准则 。
b.同一实体在不同应用中属性组成不同, 可能是属性
个数或属性次序不同 。
解决办法是, 合并后实体的属性组成为各局部 E-R图中的同名
实体属性的并集, 然后再适当调整属性的次序 。
c.同一联系在不同应用中呈现不同的类型 。 比如 E1与
E2在某一应用中可能是一对一联系, 而在另一应用
中可能是一对多或多对多联系, 也可能是在 E1,E2、
E3三者之间有联系 。
这种情况应该根据应用的语义对实体联系的类型进行综合或调
整。
63
?下面以教务管理系统中的两个局部 E-R图为例,
来说明如何消除各局部 E-R图之间的冲突, 进
行局部 E-R模型的合并, 从而生成初步 E-R图 。
?首先, 这两个局部 E-R图中存在着命名冲突, 学生
选课局部Ｅ－Ｒ图中的实体, 系, 与教师任课局部
Ｅ－Ｒ图中的实体, 单位,, 都是指, 系,, 即所
谓的异名同义, 合并后统一改为, 系,, 这样属性
,名称, 和, 单位, 即可统一为, 系名, 。
?其次, 还存在着结构冲突, 实体, 系, 和实体, 课
程, 在两个不同应用中的属性组成不同, 合并后这
两个实体的属性组成为原来局部 E-R图中的同名实
体属性的并集 。 解决上述冲突后, 合并两个局部 E-
R图, 生成如图 6.20所示的初步的全局 E-R图 。
64
图 6.20 教务管理系统的初步 E－ R图
m
n
1系
属
于
教师
拥
有
学生
开
课
讲
授
选
修
课程
m
m
n
m
1
m
1
学号 姓名 性别 年龄
平均成绩
成绩
教师
号
课程号 课程
名
教师
号
姓名 性别 职称系名 电话
65
(2) 消除不必要的冗余, 生成基本 E-R图
? 所谓冗余, 在这里指冗余的数据和实体之间冗余的联
系 。 冗余的数据是指可由基本的数据导出的数据, 冗
余的联系是由其他的联系导出的联系 。 在上面消除冲
突合并后得到的初步 E— R图中, 可能存在冗余的数据
或冗余的联系 。 冗余的存在容易破坏数据库的完整性,
给数据库的维护增加困难, 应该消除 。 我们把消除了
冗余的初步 E-R图称为基本 E-R图 。
? 通常采用分析的方法消除冗余 。 数据字典是分析冗余
数据的依据, 还可以通过数据流图分析出冗余的联系 。
? 如在图 6.20所示的初步 E-R图中,, 课程, 实体中的属
性, 教师号, 可由, 讲授, 这个教师与课程之间的联
系导出, 而学生的平均成绩可由, 选修, 联系中的属
性, 成绩, 中计算出来, 所以, 课程, 实体中的, 教
师号, 与, 学生, 实体中的, 平均成绩, 均属于冗余
数据 。
66
? 另外,, 系, 和, 课程, 之间的联系, 开课,, 可以
由, 系, 和, 教师, 之间的, 属于, 联系与, 教师,
和, 课程, 之间的, 讲授, 联系推导出来, 所以, 开
课, 属于冗余联系 。
? 这样, 图 6.20的初步 E-R图在消除冗余数据和冗余联系
后, 便可得到基本的 E-R模型, 如图 6.21所示 。
? 最终得到的基本 E-R模型是企业的概念模型, 它代表
了用户的数据要求, 是沟通, 要求, 和, 设计, 的桥
梁 。 它决定数据库的总体逻辑结构, 是成功建立数据
库的关键 。 如果设计不好, 就不能充分发挥数据库的
功能, 无法满足用户的处理要求 。
? 因此, 用户和数据库人员必须对这一模型反复讨论,
在用户确认这一模型已正确无误的反映了他们的要求
后, 才能进入下一阶段的设计工作 。
67
图 6.21 教务管理系统的基本 E－ R图
n
1系
属
于
教师
拥
有
学生
讲
授
选
修
课程
m
m
n
m
1
m
学号 姓名 性别 年龄 成绩 课程号 课程名
教师号 姓名 性别 职称系名 电话
68
6.4.1 逻辑结构设计的任务和步骤
? 概念结构设计阶段得到的 E-R模型是用户的模型, 它独
立于任何一种数据模型, 独立于任何一个具体的 DBMS。
为了建立用户所要求的数据库, 需要把上述概念模型
转换为某个具体的 DBMS所支持的数据模型 。 数据库逻
辑设计的任务是将概念结构转换成特定 DBMS所支持的
数据模型的过程 。 从此开始便进入了, 实现设计, 阶
段, 需要考虑到具体的 DBMS的性能, 具体的数据模型
特点 。
? 从 E-R图所表示的概念模型可以转换成任何一种具体
的 DBMS所支持的数据模型, 如网状模型, 层次模型
和关系模型 。 这里只讨论关系数据库的逻辑设计问题,
所以只介绍 E-R图如何向关系模型进行转换 。
6.4 逻辑结构设计
69
?一般的逻辑设计分为以下三步 （ 如图 6.22所
示 ）,
(1) 初始关系模式设计；
(2) 关系模式规范化；
(3) 模式的评价与改进 。
70
图 6.22 关系数据库的逻辑设计
概念结构设计
初始关系模式设计
关系模式规范化
模式评价
是否修正
以 DBMS语法描述
物理设计
模式修正
否
是
71
6.4.2 初始关系模式设计
1,转换原则
? 概念设计中得到的 E-R图是由实体, 属性和联系组成的,
而关系数据库逻辑设计的结果是一组关系模式的集合 。
所以将 E-R图转换为关系模型实际上就是将实体, 属性
和联系转换成关系模式 。 在转换中要遵循以下原则：
(1) 一个实体转换为一个关系模式, 实体的属性就是关系的
属性, 实体的键就是关系的键 。
(2) 一个联系转换为一个关系模式, 与该联系相连的各实体
的键以及联系的属性均转换为该关系的属性 。 该关系的键有
三种情况：
① 如果联系为 1:1,则每个实体的键都是关系的候选键；
② 如果联系为 1,n, 则 n端实体的键是关系的键；
③ 如果联系为 n,m,则各实体键的组合是关系的键 。
72
2,具体做法
(1) 把每一个实体转换为一个关系
?首先分析各实体的属性, 从中确定其主键, 然
后分别用关系模式表示 。 例如, 以图 6.21的 E-
R模型为例, 四个实体分别转换成四个关系模
式：
? 学生 （ 学号, 姓名, 性别, 年龄 ）
? 课程 （ 课程号, 课程名 ）
? 教师 （ 教师号, 姓名, 性别, 职称 ）
? 系 （ 系名, 电话 ）
?其中, 有下划线者表示是主键 。
73
(2) 把每一个联系转换为关系模式
?由联系转换得到的关系模式的属性集中, 包含
两个发生联系的实体中的主键以及联系本身的
属性, 其关系键的确定与联系的类型有关 。
?例如, 还以图 6.21的 E-R模型为例, 四个联系
也分别转换成四个关系模式：
?属于 （ 教师号, 系名 ）
?讲授 （ 教师号, 课程号 ）
?选修 （ 学号, 课程号, 成绩 ）
?拥有 （ 系名, 学号 ）
74
(3) 特殊情况的处理
?三个或三个以上实体间的一个多元联系在转换
为一个关系模式时, 与该多元联系相连的各实
体的主键及联系本身的属性均转换成为关系的
属性, 转换后所得到的关系的主键为各实体键
的组合 。
?例如, 图 6.23表示供应商, 项目和零件三个实
体之间的多对多联系, 如果已知三个实体的主
键分别为, 供应商号,,, 项目号, 与, 零件
号,, 则它们之间的联系, 供应, 可转换为关
系模式, 其中供应商号, 项目号, 零件号为此
关系的组合关系键 。
?供应 （ 供应商号, 项目号, 零件号, 数量 ）
75
供应商
供应 数量
零件项目
m
n n
图 6.23 多个实体之间的联系
76
6.4.3 关系模式规范化
? 应用规范化理论对上述产生的关系的逻辑模式进行初
步优化, 以减少乃至消除关系模式中存在的各种异常,
改善完整性, 一致性和存储效率 。
? 规范化理论是数据库逻辑设计的指南和工具, 规范化
过程可分为两个步骤：确定规范式级别, 实施规范化
处理 。
1,确定范式级别
?考查关系模式的函数依赖关系, 确定范式等级, 逐一分析各
关系模式, 考查是否存在部分函数依赖, 传递函数依赖等,
确定它们分别属于第几范式 。
2,实施规范化处理
?确定范式级别后, 利用第 4章的规范化理论, 逐一考察各个关
系模式, 根据应用要求, 判断它们是否满足规范要求, 可用
已经介绍过的规范化方法和理论将关系模式规范化 。
77
?综合以上数据库的设计过程, 规范化理论在数
据库设计中有如下几方面的应用：
(1) 在需求分析阶段, 用数据依赖概念分析和表示
各个数据项之间的联系 。
(2) 在概念结构设计阶段, 以规范化理论为指导,
确定关系键, 消除初步 E-R图中冗余的联系 。
(3) 在逻辑结构设计阶段, 从 E-R图向数据模型转
换过程中, 用模式合并与分解方法达到规范化级别 。
78
6.4.4 模式评价与改进
1,模式评价
? 关系模式的规范化不是目的而是手段, 数据库设计的
目的是最终满足应用需求 。 因此, 为了进一步提高数
据库应用系统的性能, 还应该对规范化后产生的关系
模式进行评价, 改进, 经过反复多次的尝试和比较,
最后得到优化的关系模式 。
? 模式评价的目的是检查所设计的数据库模式是否满足
用户的功能要求, 效率, 确定加以改进的部分 。 模式
评价包括功能评价和性能评价 。
? (1) 功能评价
?功能评价指对照需求分析的结果, 检查规范化后的关系模式
集合是否支持用户所有的应用要求 。 关系模式必须包括用户
可能访问的所有属性 。 在涉及多个关系模式的应用中, 应确
保联接后不丢失信息 。 如果发现有的应用不被支持, 或不完
全被支持, 则应该改进关系模式 。 发生这种问题的原因可能
是在逻辑设计阶段, 也可能是在需求分析或概念设计阶段 。
是哪个阶段的问题就返回到哪个阶段去, 因此有可能对前两
个阶段再进行评审, 解决存在的问题 。
79
? 在功能评价的过程中，可能会发现冗余的关系模式或属性，这时应
对它们加以区分，搞清楚它们是为未来发展预留的，还是某种错误
造成的，比如名字混淆。如果属于错误处置，进行改正即可，而如
果这种冗余来源于前两个设计阶段，则也要返回重新进行评审。
(2) 性能评价
? 对于目前得到的数据库模式, 由于缺乏物理设计所提
供的数量测量标准和相应的评价手段, 所以性能评价
是比较困难的, 只能对实际性能进行估计, 包括逻辑
记录的存取数, 传送量以及物理设计算法的模型等 。
? 美国密执安大学的 T.Teorey和 J.Fry于 1980年提出的逻
辑记录访问 （ Logical Record Access,LRA） 方法是
一种常用的模式性能评价方法 。 LRA方法对网状模型和
层次模型较为实用, 对于关系模型的查询也能起一定
的估算作用 。
? 有关 LRA方法本书不详细介绍, 读者可以参考有关书
籍 。
80
2,模式改进
?根据模式评价的结果, 对已生成的模式进行改
进 。
?如果因为需求分析, 概念设计的疏漏导致某些应用
不能得到支持, 则应该增加新的关系模式或属性 。
?如果因为性能考虑而要求改进, 则可采用合并或分
解的方法 。
(1) 合并
?如果有若干个关系模式具有相同的主键, 并且
对这些关系模式的处理主要是查询操作, 而且
经常是多关系的查询, 那么可对这些关系模式
按照组合使用频率进行合并 。
?这样便可以减少联接操作而提高查询效率 。
81
(2) 分解
?为了提高数据操作的效率和存储空间的利用率,
最常用和最重要的模式优化方法就是分解, 根
据应用的不同要求, 可以对关系模式进行垂直
分解和水平分解 。
?水平分解 是把关系的元组分为若干子集合, 定
义每个子集合为一个子关系 。
?对于经常进行大量数据的分类条件查询的关系,
可进行水平分解, 这样可以减少应用系统每次
查询需要访问的记录数, 从而提高了查询性能 。
82
?例如, 有学生关系 （ 学号, 姓名, 类别 …… ）, 其
中类别包括大专生, 本科生和研究生 。 如果多数查
询一次只涉及其中的一类学生, 就应该把整个学生
关系水平分割为大专生, 本科生和研究生三个关系 。
?垂直分解 是把关系模式的属性分解为若干子集
合, 形成若干子关系模式 。 垂直分解的原则是
把经常一起使用的属性分解出来, 形成一个子
关系模式 。
?例如, 有教师关系 （ 教师号, 姓名, 性别, 年龄,
职称, 工资, 岗位津贴, 住址, 电话 ）, 如果经常
查询的仅是前六项, 而后三项很少使用, 则可以将
教师关系进行垂直分割, 得到两个教师关系：
教师关系 1（ 教师号, 姓名, 性别, 年龄, 职称, 工资 ）
教师关系 2（ 教师号, 岗位津贴, 住址, 电话 ）
?这样, 便减少了查询的数据传递量, 提高了查
询速度 。
83
? 垂直分解可以提高某些事务的效率, 但也有可能使另
一些事务不得不执行连接操作, 从而降低了效率 。 因
此是否要进行垂直分解要看分解后的所有事务的总效
率是否得到了提高 。 垂直分解要保证分解后的关系具
有无损连接性和函数依赖保持性 。 相关的分解算法已
经在第 4章进行了详细介绍 。
? 经过多次的模式评价和模式改进之后, 最终的数据库
模式得以确定 。 逻辑设计阶段的结果是全局逻辑数据
库结构 。 对于关系数据库系统来说, 就是一组符合一
定规范的关系模式组成的关系数据库模型 。
? 数据库系统的数据物理独立性特点消除了由于物理存
储改变而引起的对应程序的修改 。 标准的 DBMS例行
程序应适用于所有的访问, 查询和更新事务的优化应
当在系统软件一级上实现 。 这样, 逻辑数据库确定之
后, 就可以开始进行应用程序设计了 。
84
?数据库最终要存储在物理设备上 。 对于给定的
逻辑数据模型, 选取一个最适合应用环境的物
理结构的过程, 称为数据库物理设计 。 物理设
计的任务是为了有效地实现逻辑模式, 确定所
采取的存储策略 。 此阶段是以逻辑设计的结果
作为输入, 结合具体 DBMS的特点与存储设备特
性进行设计, 选定数据库在物理设备上的存储
结构和存取方法 。
?数据库的物理设计可分为两步：
(1) 确定物理结构, 在关系数据库中主要指存取方
法和存储结构；
(2)评价物理结构, 评价的重点是时间和空间效率 。
6.5 数据库物理设计
85
6.5.1 确定物理结构
? 设计人员必须深入了解给定的 DBMS的功能, DBMS提供
的环境和工具, 硬件环境,特别是存储设备的特征 。 另
一方面也要了解应用环境的具体要求, 如各种应用的
数据量, 处理频率和响应时间等 。 只有, 知己知彼,
才能设计出较好的物理结构 。
1,存储记录结构的设计
? 在物理结构中, 数据的基本存取单位是存储记录 。 有了逻辑记录结
构以后, 就可以设计存储记录结构, 一个存储记录可以和一个或多
个逻辑记录相对应 。 存储记录结构包括记录的组成, 数据项的类型
和长度, 以及逻辑记录到存储记录的映射 。 某一类型的所有存储记
录的集合称为, 文件,, 文件的存储记录可以是定长的, 也可以是
变长的 。
? 文件组织或文件结构是组成文件的存储记录的表示法 。 文件结构应
该表示文件格式, 逻辑次序, 物理次序, 访问路径, 物理设备的分
配 。 物理数据库就是指数据库中实际存储记录的格式, 逻辑次序和
物理次序, 访问路径, 物理设备的分配 。
? 决定存储结构的主要因素包括存取时间, 存储空间和维护代价三个
方面 。 设计时应当根据实际情况对这三个方面进行综合权衡 。 一般
DBMS也提供一定的灵活性可供选择, 包括聚簇和索引 。
86
(1) 聚簇 （ Cluster）
? 聚簇就是为了提高查询速度, 把在一个 （ 或一组 ） 属
性上具有相同值的元组集中地存放在一个物理块中 。
如果存放不下, 可以存放在相邻的物理块中 。 其中,
这个 （ 或这组 ） 属性称为聚簇码 。
? 为什么要使用聚簇呢？ 聚簇有两个作用：
① 使用聚簇以后, 聚簇码相同的元组集中在一起了, 因而聚簇
值不必在每个元组中重复存储, 只要在一组中存储一次即可,
因此可以节省存储空间 。
② 聚簇功能可以大大提高按聚簇码进行查询的效率 。 例如, 假
设要查询学生关系中计算机系的学生名单, 设计算机系有 300名
学生 。 在极端情况下, 这些学生的记录会分布在 300个不同的物
理块中, 这时如果要查询计算机系的学生, 就需要做 300次的
I/O操作, 这将影响系统查询的性能 。 如果按照系别建立聚簇,
使同一个系的学生记录集中存放, 则每做一次 I/O操作, 就可以
获得多个满足查询条件和记录, 从而显著地减少了访问磁盘的
次数 。
87
(2) 索引
? 存储记录是属性值的集合, 主关系键可以惟一确定一
个记录, 而其他属性的一个具体值不能惟一确定是哪
个记录 。 在主关系键上应该建立惟一索引, 这样不但
可以提高查询速度, 还能避免关系键重复值的录入,
确保了数据的完整性 。
? 在数据库中, 用户访问的最小单位是属性 。 如果对某
些非主属性的检索很频繁, 可以考虑建立这些属性的
索引文件 。 索引文件对存储记录重新进行内部链接,
从逻辑上改变了记录的存储位置, 从而改变了访问数
据的入口点 。 关系中数据越多索引的优越性也就越明
显 。
? 建立多个索引文件可以缩短存取时间, 但是增加了索
引文件所占用的存储空间以及维护的开销 。 因此, 应
该根据实际需要综合考虑 。
88
2,访问方法的设计
? 访问方法是为存储在物理设备 （ 通常指辅存 ） 上的数据提
供存储和检索能力的方法 。 一个访问方法包括存储结构和
检索机构两个部分 。 存储结构限定了可能访问的路径和存
储记录；检索机构定义了每个应用的访问路径, 但不涉及
存储结构的设计和设备分配 。
? 存储记录是属性的集合, 属性是数据项类型, 可用作主键
或辅助键 。 主键惟一地确定了一个记录 。 辅助键是用作记
录索引的属性, 可能并不惟一确定某一个记录 。
? 访问路径的设计分成主访问路径与辅访问路径的设计 。 主
访问路径与初始记录的装入有关, 通常是用主键来检索的 。
首先利用这种方法设计各个文件, 使其能最有效地处理主
要的应用 。 一个物理数据库很可能有几套主访问路径 。 辅
访问路径是通过辅助键的索引对存储记录重新进行内部链
接, 从而改变访问数据的入口点 。 用辅助索引可以缩短访
问时间, 但增加了辅存空间和索引维护的开销 。 设计者应
根据具体情况作出权衡 。
89
3,数据存放位置的设计
?为了提高系统性能, 应该根据应用情况将数据
的易变部分, 稳定部分, 经常存取部分和存取
频率较低部分分开存放 。
?例如, 目前许多计算机都有多个磁盘, 因此可
以将表和索引分别存放在不同的磁盘上, 在查
询时, 由于两个磁盘驱动器并行工作, 可以提
高物理读写的速度 。
?在多用户环境下, 可能将日志文件和数据库对
象 （ 表, 索引等 ） 放在不同的磁盘上, 以加快
存取速度 。 另外, 数据库的数据备份, 日志文
件备份等, 只在数据库发生故障进行恢复时才
使用, 而且数据量很大, 可以存放在磁带上,
以改进整个系统的性能 。
90
4,系统配置的设计
? DBMS产品一般都提供了一些系统配置变量, 存储分配
参数, 供设计人员和 DBA对数据库进行物理优化 。 系统
为这些变量设定了初始值, 但是这些值不一定适合每
一种应用环境, 在物理设计阶段, 要根据实际情况重
新对这些变量赋值, 以满足新的要求 。
? 系统配置变量和参数很多, 例如, 同时使用数据库的
用户数, 同时打开的数据库对象数, 内存分配参数,
缓冲区分配参数 （ 使用的缓冲区长度, 个数 ）, 存储
分配参数, 数据库的大小, 时间片的大小, 锁的数目
等, 这些参数值影响存取时间和存储空间的分配, 在
物理设计时要根据应用环境确定这些参数值, 以使系
统的性能达到最优 。
91
6.5.2 评价物理结构
?和前面几个设计阶段一样，在确定了数据库的
物理结构之后，要进行评价，重点是时间和空
间的效率。
?如果评价结果满足设计要求，则可进行数据库
实施。
?实际上，往往需要经过反复测试才能优化物理
设计。
92
?数据库实施是指根据逻辑设计和物理设计的结
果, 在计算机上建立起实际的数据库结构, 装
入数据, 进行测试和试运行的过程 。
?数据库实施主要包括以下工作：
?建立实际数据库结构；
?装入数据；
?应用程序编码与调试；
?数据库试运行；
?整理文档 。
6.6 数据库实施
93
6.6.1 建立实际数据库结构
? DBMS提供的数据定义语言 （ DDL） 可以定义数据库结构 。
可使用第 3章所讲的 SQL定义语句中的 CREATE TABLE语
句定义所需的基本表, 使用 CREATE VIEW语句定义视
图 。
6.6.2 装入数据
? 装入数据又称为数据库加载 （ Loading）, 是数据库实
施阶段的主要工作 。 在数据库结构建立好之后, 就可
以向数据库中加载数据了 。
? 由于数据库的数据量一般都很大, 它们分散于一个企
业 （ 或组织 ） 中各个部门的数据文件, 报表或多种形
式的单据中, 它们存在着大量的重复, 并且其格式和
结构一般都不符合数据库的要求, 必须把这些数据收
集起来加以整理, 去掉冗余并转换成数据库所规定的
格式, 这样处理之后才能装入数据库 。 因此, 需要耗
费大量的人力, 物力, 是一种非常单调乏味而又意义
重大的工作 。
94
? 由于应用环境和数据来源的差异, 所以不可能存在普
遍通用的转换规则, 现有的 DBMS并不提供通用的数据
转换软件来完成这一工作 。
? 对于一般的小型系统, 装入数据量较少, 可以采用人
工方法来完成 。
? 首先将需要装入的数据从各个部门的数据文件中筛选出来, 转换成
符合数据库要求的数据格式,
? 然后输入到计算机中,
? 最后进行数据校验, 检查输入的数据是否有误 。
? 但是, 人工方法不仅效率低, 而且容易产生差错 。 对于数
据量较大的系统, 应该由计算机来完成这一工作 。 通常是
设计一个数据输入子系统, 其主要功能是从大量的原始数
据文件中筛选, 分类, 综合和转换数据库所需的数据, 把
它们加工成数据库所要求的结构形式, 最后装入数据库中,
同时还要采用多种检验技术检查输入数据的正确性 。
? 为了保证装入数据库中数据的正确无误, 必须高度重视数
据的校验工作 。 在输入子系统的设计中应该考虑多种数据
检验技术, 在数据转换过程中应使用不同的方法进行多次
检验, 确认正确后方可入库 。
95
?如果在数据库设计时, 原来的数据库系统仍在
使用, 则数据的转换工作是将原来老系统中的
数据转换成新系统中的数据结构 。 同时还要转
换原来的应用程序, 使之能在新系统下有效地
运行 。
?数据的转换, 分类和综合常常需要多次才能完
成, 因而输入子系统的设计和实施是很复杂的,
需要编写许多应用程序, 由于这一工作需要耗
费较多的时间, 为了保证数据能够及时入库,
应该在数据库物理设计的同时编制数据输入子
系统, 而不能等物理设计完成后才开始 。
96
6.6.3 应用程序编码与调试
? 数据库应用程序的设计属于一般的程序设计范畴, 但
数据库应用程序有自己的一些特点 。 例如, 大量使用
屏幕显示控制语句, 形式多样的输出报表, 重视数据
的有效性和完整性检查, 有灵活的交互功能 。
? 为了加快应用系统的开发速度, 一般选择第四代语言
开发环境, 利用自动生成技术和软件复用技术, 在程
序设计编写中往往采用工具 （ CASE） 软件来帮助编写
程序和文档, 如目前普遍使用的 PowerBuilder、
Delphi以及由北京航空航天大学研制的 863/CMIS支持
的数据库开发工具 OpenTools等 。
? 数据库结构建立好之后, 就可以开始编制与调试数据
库的应用程序, 这时由于数据入库尚未完成, 调试程
序时可以先使用模拟数据 。
97
6.6.4 数据库试运行
? 应用程序编写完成, 并有了一小部分数据装入后, 应
该按照系统支持的各种应用分别试验应用程序在数据
库上的操作情况, 这就是数据库的试运行阶段, 或者
称为联合调试阶段 。 在这一阶段要完成两方面的工作 。
(1) 功能测试 。 实际运行应用程序, 测试它们能否完成各种
预定的功能 。
(2) 性能测试 。 测量系统的性能指标, 分析系统是否符合设
计目标 。
? 系统的试运行对于系统设计的性能检验和评价是很重
要的, 因为有些参数的最佳值只有在试运行后才能找
到 。 如果测试的结果不符合设计目标, 则应返回到设
计阶段, 重新修改设计和编写程序, 有时甚至需要返
回到逻辑设计阶段, 调整逻辑结构 。
98
? 重新设计物理结构甚至逻辑结构, 会导致数据重新入
库 。 由于数据装入的工作量很大, 所以可分期分批的
组织数据装入, 先输入小批量数据做调试用, 待试运
行基本合格后, 再大批量输入数据, 逐步增加数据量,
逐步完成运行评价 。
? 数据库的实施和调试不是几天就能完成的, 需要有一
定的时间 。 在此期间由于系统还不稳定, 随时可能发
生硬件或软件故障, 加之数据库刚刚建立, 操作人员
对系统还不熟悉, 对其规律缺乏了解, 容易发生操作
错误, 这些故障和错误很可能破坏数据库中的数据,
这种破坏很可能在数据库中引起连锁反应, 破坏整个
数据库 。
? 因此必须做好数据库的转储和恢复工作, 要求设计人
员熟悉 DBMS的转储和恢复功能, 并根据调试方式和
特点首先加以实施, 尽量减少对数据库的破坏, 并简
化故障恢复 。
99
6.6.5 整理文档
?在程序的编码调试和试运行中，应该将发现的
问题和解决方法记录下来，将它们整理存档作
为资料，供以后正式运行和改进时参考。
?全部的调试工作完成之后，应该编写应用系统
的技术说明书和使用说明书，在正式运行时随
系统一起交给用户。
?完整的文件资料是应用系统的重要组成部分，
但这一点常被忽视。必须强调这一工作的重要
性，引起用户与设计人员的充分注意。
100
? 数据库试运行结果符合设计目标后, 数据库就投入正
式运行, 进入运行和维护阶段 。 数据库系统投入正式
运行, 标志着数据库应用开发工作的基本结束, 但并
不意味着设计过程己经结束 。
? 由于应用环境不断发生变化, 用户的需求和处理方法
不断发展, 数据库在运行过程中的存储结构也会不断
变化, 从而必须修改和扩充相应的应用程序 。
? 数据库运行和维护阶段的主要任务包括以下三项内容：
(1) 维护数据库的安全性与完整性；
(2) 监测并改善数据库性能；
(3) 重新组织和构造数据库 。
6.7 数据库运行和维护
101
6.7.1 维护数据库的安全性与完整性
? 按照设计阶段提供的安全规范和故障恢复规范, DBA要
经常检查系统的安全是否受到侵犯, 根据用户的实际
需要授予用户不同的操作权限 。
? 数据库在运行过程中, 由于应用环境发生变化, 对安
全性的要求可能发生变化, DBA要根据实际情况及时调
整相应的授权和密码, 以保证数据库的安全性 。
? 同样数据库的完整性约束条件也可能会随应用环境的
改变而改变, 这时 DBA也要对其进行调整, 以满足用户
的要求 。
? 另外, 为了确保系统在发生故障时, 能够及时地进行
恢复, DBA要针对不同的应用要求定制不同的转储计划,
定期对数据库和日志文件进行备份, 以使数据库在发
生故障后恢复到某种一致性状态, 保证数据库的完整
性 。
102
6.7.2 监测并改善数据库性能
?目前许多 DBMS产品都提供了监测系统性能参数
的工具, DBA可以利用系统提供的这些工具,
经常对数据库的存储空间状况及响应时间进行
分析评价；
?结合用户的反应情况确定改进措施；及时改正
运行中发现的错误；
?按用户的要求对数据库的现有功能进行适当的
扩充 。
?但要注意在增加新功能时应保证原有功能和性
能不受损害 。
103
6.7.3 重新组织和构造数据库
? 数据库建立后, 除了数据本身是动态变化以外, 随着
应用环境的变化, 数据库本身也必须变化以适应应用
要求 。
? 数据库运行一段时间后, 由于记录的不断增加, 删除
和修改, 会改变数据库的物理存储结构, 使数据库的
物理特性受到破坏, 从而降低数据库存储空间的利用
率和数据的存取效率, 使数据库的性能下降 。 因此,
需要对数据库进行重新组织, 即重新安排数据的存储
位置, 回收垃圾, 减少指针链, 改进数据库的响应时
间和空间利用率, 提高系统性能 。 这与操作系统对
,磁盘碎片, 的处理的概念相类似 。
? 数据库的重组只是使数据库的物理存储结构发生变化,
而数据库的逻辑结构不变, 所以根据数据库的三级模
式, 可以知道数据库重组对系统功能没有影响, 只是
为了提高系统的性能 。
104
? 数据库应用环境的变化可能导致数据库的逻辑结构发
生变化, 比如要增加新的实体, 增加某些实体的属性,
这样实体之间的联系发生了变化, 这样使原有的数据
库设计不能满足新的要求, 必须对原来的数据库重新
构造, 适当调整数据库的模式和内模式, 比如要增加
新的数据项, 增加或删除索引, 修改完整性约束条件
等 。
? DBMS一般都提供了重新组织和构造数据库的应用程序,
以帮助 DBA完成数据库的重组和重构工作 。
? 只要数据库系统在运行, 就需要不断地进行修改, 调
整和维护 。 一旦应用变化太大, 数据库重新组织也无
济于事, 这就表明数据库应用系统的生命周期结束,
应该建立新系统, 重新设计数据库 。 从头开始数据库
设计工作, 标志着一个新的数据库应用系统生命周期
的开始 。
105
小 结
? 本章介绍了数据库设计的六个阶段, 包括：系统需求
分析, 概念结构设计, 逻辑结构设计, 物理设计, 数
据库实施, 数据库运行与维护 。 对于每一阶段, 都分
别详细讨论了其相应的任务, 方法和步骤 。
? 需求分析是整个设计过程的基础, 需求分析做得不好,
可能会导致整个数据库设计返工重做 。
? 将需求分析所得到的用户需求抽象为信息结构即概念
模型的过程就是概念结构设计, 概念结构设计是整个
数据库设计的关键所在, 这一过程包括设计局部 E-R
图, 综合成初步 E-R图, E-R图的优化 。
106
小 结
? 将独立于 DBMS的概念模型转化为相应的数据模型, 这
是逻辑结构设计所要完成的任务 。 一般的逻辑设计分
为三步：初始关系模式设计, 关系模式规范化, 模式
的评价与改进 。
? 物理设计就是为给定的逻辑模型选取一个适合应用环
境的物理结构, 物理设计包括确定物理结构和评价物
理结构两步 。
? 根据逻辑设计和物理设计的结果, 在计算机上建立起
实际的数据库结构, 装入数据, 进行应用程序的设计,
并试运行整个数据库系统, 这是数据库实施阶段的任
务 。
? 数据库设计的最后阶段是数据库的运行与维护, 包括
维护数据库的安全性与完整性, 监测并改善数据库性
能, 必要时需要进行数据库的重新组织和构造 。
第 6章 数据库设计
2
6.1 数据库设计概述
6.1.1 数据库设计的任务, 内容和特点
6.1.1.1 数据库设计的任务
?数据库设计是指根据用户需求研制数据库结构
的过程, 具体地说, 是指对于一个给定的应用
环境, 构造最优的数据库模式, 建立数据库及
其应用系统, 使之能有效的存储数据, 满足用
户的信息要求和处理要求 。
?也就是把现实世界中的数据, 根据各种应用处
理的要求, 加以合理地组织, 满足硬件和操作
系统的特性, 利用已有的 DBMS来建立能够实现
系统目标的数据库 。
3
数据库设计的任务如图 6.1所示 。
数据库
设 计
信息需求
处理需求
信息需求
典型应用程序
DBM特性 硬件和操作
系统特性
图 6.1 数据库设计的任务
4
6.1.1.2 数据库设计的内容
?数据库设计包括数据库的结构设计和数据库的
行为设计两方面的内容 。
1,数据库的结构设计
?数据库的结构设计指是根据给定的应用环境,
进行数据库的模式或子模式的设计 。
?它包括数据库的概念设计, 逻辑设计和物理设
计 。
?数据库模式是各应用程序共享的结构, 是静态
的, 稳定的, 一经形成后通常情况下是不容易
改变的, 所以结构设计又称为 静态模型设计 。
5
2,数据库的行为设计
? 数据库的行为设计是指确定数据库用户的行为和动作 。
而在数据库系统中, 用户的行为和动作指用户对数据
库的操作, 这些要通过应用程序来实现, 所以数据库
的行为设计就是应用程序的设计 。
? 用户的行为总是使数据库的内容发生变化, 所以行为
设计是动态的, 行为设计又称为 动态模型设计 。
6.1.1.3 数据库设计的特点
? 在 70年代末 80年代初, 人们为了研究数据库设计方法
学的便利, 曾主张将结构设计和行为设计两者分离,
随着数据库设计方法学的成熟和结构化分析, 设计方
法的普遍使用, 人们主张将两者作一体化的考虑, 这
样可以缩短数据库的设计周期, 提高数据库的设计效
率 。
6
?现代数据库的设计的特点是强调结构设计与行
为设计相结合, 是一种, 反复探寻, 逐步求精,
的过程 。 首先从数据模型开始设计, 以数据模
型为核心进行展开, 数据库设计和应用系统设
计相结合, 建立一个完整, 独立, 共享, 冗余
小, 安全有效的数据库系统 。
?图 6.2给出了数据库设计的全过程 。
7
现实世界
数据分析 用户业务活动分析
概念设计 功能模型
逻辑设计 事务设计
物理设计 程序说明
子模式设计 应用程序设计
加载试验数据 程序编码调试
性能考核
满意
是
否
加载数据库
运行和维护
图 6.2 数据库设计的全过程
8
6.1.2 数据库设计方法简述
? 数据库设计方法目前可分为四类,直观设计法, 规范设计法, 计
算机辅助设计法 和 自动化设计法 。
? 直观设计法也叫手工试凑法，它是最早使用的数据库设计方法。
这种方法依赖于设计者的经验和技巧，缺乏科学理论和工程原则
的支持，设计的质量很难保证，常常是数据库运行一段时间后又
发现各种问题，这样再重新进行修改，增加了系统维护的代价。
因此这种方法越来越不适应信息管理发展的需要。
? 为了改变这种情况,1978年 10月，来自三十多个国家的数据库专
家在美国新奥尔良（ New Orleans）市专门讨论了数据库设计问
题，他们运用软件工程的思想和方法，提出了数据库设计的规范，
这就是著名的新奥尔良法，它是目前公认的比较完整和权威的一
种规范设计法。新奥尔良法将数据库设计分成需求分析（分析用
户需求）、概念设计（信息分析和定义）、逻辑设计（设计实现）
和物理设计（物理数据库设计）。目前，常用的规范设计方法大
多起源于新奥尔良法，并在设计的每一阶段采用一些辅助方法来
具体实现。
? 下面简单介绍几种常用的规范设计方法。
9
1．基于 E-R模型的数据库设计方法
?基于 E-R模型的数据库设计方法是由 P.P.S.chen于
1976年提出的数据库设计方法，其基本思想是在需
求分析的基础上，用 E-R（实体 — 联系）图构造一
个反映现实世界实体之间联系的企业模式，然后再
将此企业模式转换成基于某一特定的 DBMS的概念
模式。
2,基于 3NF的数据库设计方法
?基于 3NF的数据库设计方法是由 S·Atre提出的结构
化设计方法，其基本思想是在需求分析的基础上，
确定数据库模式中的全部属性和属性间的依赖关系，
将它们组织在一个单一的关系模式中，然后再分析
模式中不符合 3NF的约束条件，将其进行投影分解，
规范成若干个 3NF关系模式的集合。
?其具体设计步骤分为五个阶段：
10
(1)设计企业模式, 利用规范化得到的 3NF关
系模式画出企业模式；
(2)设计数据库的概念模式, 把企业模式转换
成 DBMS所能接受的概念模式, 并根据概念模
式导出各个应用的外模式；
(3)设计数据库的物理模式 （ 存储模式 ） ；
(4)对物理模式进行评价；
(5) 实现数据库 。
11
3,基于视图的数据库设计方法
?此方法先从分析各个应用的数据着手, 其基本
思想是为每个应用建立自己的视图, 然后再把
这些视图汇总起来合并成整个数据库的概念模
式 。 合并过程中要解决以下问题：
(1) 消除命名冲突；
(2) 消除冗余的实体和联系；
(3)进行模式重构, 在消除了命名冲突和冗余后, 需
要对整个汇总模式进行调整, 使其满足全部完整性
约束条件 。
12
? 除了以上三种方法外, 规范化设计方法还有实体分析
法, 属性分析法和基于抽象语义的设计方法等, 这里
不再详细介绍 。
? 规范设计法从本质上来说仍然是手工设计方法, 其基
本思想是过程迭代和逐步求精 。
? 计算机辅助设计法是指在数据库设计的某些过程中模
拟某一规范化设计的方法, 并以人的知识或经验为主
导, 通过人机交互方式实现设计中的某些部分 。
? 目前许多计算机辅助软件工程 （ Computer Aided
Software Engineering,CASE） 工具可以自动或辅助
设计人员完成数据库设计过程中的很多任务,比如
SYSBASE公司的 PowerDesigner和 Oracle公司的 Design
2000。
13
6.1.3 数据库设计的步骤
?和其他软件一样, 数据库的设计过程可以使用
软件工程中的生存周期的概念来说明, 称为
,数据库设计的生存期,, 它是指从数据库研
制到不再使用它的整个时期 。
?按规范设计法可将数据库设计分为六个阶段
（ 如图 6.3所示 ）,
（ 1） 系统需求分析阶段
（ 2） 概念结构设计阶段
（ 3） 逻辑结构设计阶段
（ 4） 物理设计阶段
（ 5） 数据库实施阶段
（ 6） 数据库运行与维护阶段
14
? 该方法是分阶段完成的, 每完成一个阶段, 都要进行
设计分析, 评价一些重要的设计指标, 把设计阶段产
生的文档组织评审, 与用户进行交流 。 如果设计的数
据库不符合要求则进行修改, 这种分析和修改可能要
重复若干次, 以求最后实现的数据库能够比较精确地
模拟现实世界, 能较准确地反映用户的需求, 设计一
个完善的数据库应用系统往往是六个阶段的不断反复
的过程 。
? 数据库设计中, 前两个阶段是面向用户的应用要求,
面向具体的问题；中间两个阶段是面向数据库管理系
统；最后两个阶段是面向具体的实现方法 。 前四个阶
段可统称为, 分析和设计阶段,, 后两个阶段称为
,实现和运行阶段, 。
? 六个阶段的主要工作各有不同 。
15
1,系统需求分析阶段
?需求分析是整个数据库设计过程的基础, 要收集数
据库所有用户的信息内容和处理要求, 并加以规格
化和分析 。 这是最费时, 最复杂的一步, 但也是最
重要的一步, 相当于待构建的数据库大厦的地基,
它决定了以后各步设计的速度与质量 。 需求分析做
得不好, 可能会导致整个数据库设计返工重做 。 在
分析用户需求时, 要确保用户目标的一致性 。
2,概念结构设计阶段
?概念设计是把用户的信息要求统一到一个整体逻辑
结构中, 此结构能够表达用户的要求, 是一个独立
于任何 DBMS软件和硬件的概念模型 。
3,逻辑结构设计阶段
?逻辑设计是将上一步所得到的概念模型转换为某个
DBMS所支持的数据模型, 并对其进行优化 。
16
图 6.3 数据库的设计步骤
Y
Y
N
N
需求分析阶段
现 有应 用
,未来 应
用 数据分析
概念模型设计
转换规范, 规范
化理论 DBMS要
求 逻辑模型设计
用户应用要求
DBMS限制
物理模型设计
应 用程 序
的 使用 频
率
性能评价与预测
符合要求
？
物理实现
试运行
满意？
使用与维护
概念设计阶段
逻辑设计阶段
物理设计阶段
数据库实施阶段
数据库运行维护阶段
17
4,物理设计阶段
?物理设计是为逻辑数据模型建立一个完整的能实现的数据库
结构, 包括存储结构和存取方法 。
?上述分析和设计阶段是很重要的, 如果做出不恰当的分析或
设计, 则会导致一个不恰当或反应迟钝的应用系统 。
5,数据库实施阶段
?根据物理设计的结果把原始数据装入数据库, 建立一个具体
的数据库并编写和调试相应的应用程序 。 应用程序的开发目
标是开发一个可依赖的有效的数据库存取程序, 来满足用户
的处理要求 。
6,数据库运行与维护阶段
?这一阶段主要是收集和记录实际系统运行的数据, 数据库运
行的记录用来提高用户要求的有效信息, 用来评价数据库系
统的性能, 进一步调整和修改数据库 。 在运行中, 必须保持
数据库的完整性, 并能有效地处理数据库故障和进行数据库
恢复 。 在运行和维护阶段, 可能要对数据库结构进行修改或
扩充 。
18
? 可以看出, 以上六个阶段是从数据库应用系统设计和
开发的全过程来考察数据库设计的问题 。 因此, 它既
是数据库也是应用系统的设计过程 。 在设计过程中,
努力使数据库设计和系统其他部分的设计紧密结合,
把数据和处理的需求收集, 分析, 抽象, 设计和实现
在各个阶段同时进行, 相互参照, 相互补充, 以完善
两方面的设计 。 按照这个原则, 数据库过程各个阶段
的设计可用图 6.4描述 。
? 在上图有关处理特性的描述中, 采用的设计方法和工
具属于软件工程和管理信息系统等课程中的内容, 本
书不再讨论, 这里重点介绍数据特性的设计描述以及
在结构特性中参照处理特性设计以完善数据模型设计
的问题 。
? 以下各节分别详细介绍数据库设计的六个阶段 。
19
?需求分析是数据库设计的起点，为以后的具体
设计作准备。
?需求分析的结果是否准确的反映了用户的实际
要求，将直接影响到后面各个阶段的设计，并
影响到设计结果是否合理和实用。
?经验证明，由于设计要求的不正确或误解，直
到系统测试阶段才发现许多错误，则纠正起来
要付出很大代价。
?因此，必须高度重视系统的需求分析。
6.2 系统需求分析
20
6.2.1 需求分析的任务
?从数据库设计的角度来看，需求分析的任务是：
对现实世界要处理的对象（组织、部门、企业）
等进行详细的调查，通过对原系统的了解，收
集支持新系统的基础数据并对其进行处理，在
此基础上确定新系统的功能。
21
具体地说，需求分析阶段的任务包括以下三项：
设计阶段
设 计 描 述
数据 处理
需求分析 数据字典, 全系统中数据项,
数据流, 数据存储的描述
数据流图和定表 （ 判定树 ）
数据字典中处理过程的描述
概念结构设
计
概念模型 （ E-R图 ）
数据字典
系统说明书 。 包括：
(1) 新系统要求, 方案和概图
(2) 反映新系统信息的数据流图
逻辑结构设
计
某种数据模型
关系模型
系统结构图
非关系模型 （ 模块结构图 ）
物理设计 存储安排
存取方法选择
存取路径建立
模块设计
IPO表
实施阶段 编写模式
装入数据
数据库试运行
程序编码
编译联结
测试
运行维护 性能测试, 转储 /恢复数据库
重组和重构
新旧系统转换, 运行, 维护 （ 修正性, 适应性,
改善性维护 ）
图 6.4 数据库各个设计阶段的描述
22
1,调查分析用户的活动
?这个过程通过对新系统运行目标的研究, 对现
行系统所存在的主要问题的分析以及制约因素
的分析, 明确用户总的需求目标, 确定这个目
标的功能域和数据域 。 具体做法是：
(1) 调查组织机构情况, 包括该组织的部门组成情况,
各部门的职责和任务等 。
(2) 调查各部门的业务活动情况, 包括各部门输入和
输出的数据与格式, 所需的表格与卡片, 加工处理
这些数据的步骤, 输入输出的部门等 。
23
2,收集和分析需求数据, 确定系统边界
? 在熟悉业务活动的基础上, 协助用户明确对新系统的
各种需求, 包括用户的信息需求, 处理需求, 安全性
和完整性的需求等 。
（ 1） 信息需求指目标范围内涉及的所有实体, 实体的属性以及
实体间的联系等数据对象, 也就是用户需要从数据库中获得
信息的内容与性质 。 由信息要求可以导出数据要求, 即在数
据库中需要存储哪些数据 。
（ 2） 处理需求指用户为了得到需求的信息而对数据进行加工处
理的要求, 包括对某种处理功能的响应时间, 处理的方式
（ 批处理或联机处理 ） 等 。
（ 3） 安全性和完整性的需求 。 在定义信息需求和处理需求的同
时必须相应确定安全性和完整性约束 。
? 在收集各种需求数据后, 对前面调查的结果进行初步
分析, 确定新系统的边界, 确定哪些功能由计算机完
成或将来准备让计算机完成, 哪些活动由人工完成 。
由计算机完成的功能就是新系统应该实现的功能 。
24
3,编写需求分析说明书
? 系统分析阶段的最后是编写系统分析报告, 通常称为
需求规范说明书 。 需求规范说明书是对需求分析阶段
的一个总结 。 编写系统分析报告是一个不断反复, 逐
步深入和逐步完善的过程, 系统分析报告应包括如下
内容：
(1) 系统概况, 系统的目标, 范围, 背景, 历史和现状；
(2) 系统的原理和技术, 对原系统的改善；
(3) 系统总体结构与子系统结构说明；
(4) 系统功能说明；
(5) 数据处理概要, 工程体制和设计阶段划分；
(6) 系统方案及技术, 经济, 功能和操作上的可行性 。
? 完成系统的分析报告后，在项目单位的领导下要组织
有关技术专家评审系统分析报告，这是对需求分析结
构的再审查。审查通过后由项目方和开发方领导签字
认可。
25
随系统分析报告提供下列附件：
(1) 系统的硬件, 软件支持环境的选择及规格要求
（ 所选择的数据库管理系统, 操作系统, 汉字平台,
计算机型号及其网络环境等 ） 。
(2) 组织机构图, 组织之间联系图 t 各机构功能业务
一览图 。
(3) 数据流程图, 功能模块图和数据字典等图表 。
?如果用户同意系统分析报告和方案设计, 在与
用户进行详尽商讨的基础上, 最后签订技术协
议书 。
?系统分析报告是设计者和用户一致确认的权威
性文献, 是今后各阶段设计和工作的依据 。
26
6.2.2 需求分析的方法
? 用户参加数据库设计是数据应用系统设计的特点, 是
数据库设计理论不可分割的一部分 。
? 在数据需求分析阶段, 任何调查研究没有用户的积极
参加是寸步难行的, 设计人员应和用户取得共同的语
言, 帮助不熟悉计算机的用户建立数据库环境下的共
同概念, 所以这个过程中不同背景的人员之间互相了
解与沟通是至关重要的, 同时方法也很重要 。
? 用于需求分析的方法有多种, 主要方法有自顶向下和
自底向上两种,如图 6.5所示 。
? 其中自顶向下的分析方法（ Structured Analysis，简称
SA方法）是最简单实用的方法。 SA方法从最上层的系
统组织机构入手，采用逐层分解的方式分析系统，用
数据流图 （ Data Flow Diagram,DFD）和 数据字典
（ Data Dictionary,DD）描述系统。
? 下面对数据流图和数据字典作些简单的介绍。
27
1,数据流图
? 使用 SA方法, 任何一个系统都可抽象为图 6.6所示的数
据流图 。
? 在数据流图中, 用命名的箭头表示数据流, 用圆圈表
示处理, 用矩形或其他形状表示存储 。
? 图 6.7是一个简单的数据流图 。 一个简单的系统可用一
张数据流图来表示 。 当系统比较复杂时, 为了便于理
解, 控制其复杂性, 可以采用分层描述的方法 。 一般
用第一层描述系统的全貌, 第二层分别描述各子系统
的结构 。 如果系统结构还比较复杂, 那么可以继续细
化, 直到表达清楚为止 。 在处理功能逐步分解的同时,
它们所用的数据也逐级分解, 形成若干层次的数据流
图 。 数据流图表达了数据和处理过程的关系 。
? 在 SA方法中，处理过程的处理逻辑常常借助判定表或
判定树来描述，而系统中的数据则是借助数据字典来
描述
28
图 6.5 需求分析的方法
(a) 自顶向下的需求分析 (b) 自底向上的需求分析
……
………
…
需求
需求
…
…
需求
…
需求 需求 需求 需求
需求 需求 需求 需求
需求 需求
…
需求
…
29
图 6.6 数据流图
数据流数据流
数据存储
数据来源 处
理
数据输出
处理需求
信息需求
30
图 6.7 数据流图示例
付款凭证报销单
报销登记
报销人 审查
分录
31
2,数据字典
? 数据字典是对系统中数据的详细描述, 是各类数据结
构和属性的清单 。 它与数据流图互为注释 。
? 数据字典贯穿于数据库需求分析直到数据库运行的全
过程, 在不同的阶段其内容和用途各有区别 。
? 在需求分析阶段, 它通常包含以下五部分内容 。
(1) 数据项
?数据项是数据的最小单位, 其具体内容包括：数据顶名, 含
义说明, 别名, 类型, 长度, 取值范围, 与其他数据项的关
系 。
?其中, 取值范围, 与其他数据项的关系这两项内容定义了完
整性约束条件, 是设计数据检验功能的依据 。
(2) 数据结构
?数据结构是数据项有意义的集合 。 内容包括：数据结构名,
含义说明, 这些内容组成数据项名 。
32
(3) 数据流
?数据流可以是数据项, 也可以是数据结构, 它表示某一处理
过程中数据在系统内传输的路径 。
?内容包括：数据流名, 说明, 流出过程, 流入过程, 这些内
容组成数据项或数据结构 。
?其中, 流出过程说明该数据流由什么过程而来；流入过程说
明该数据流到什么过程 。
(4) 数据存储
?处理过程中数据的存放场所, 也是数据流的来源和去向之一 。
可以是手工凭证, 手工文档或计算机文件 。
?包括 ｛ 数据存储名, 说明, 输入数据流, 输出数据流, 组成：
｛ 数据项或数据结构 ｝, 数据量, 存取频度, 存取方式 ｝ 。
?其中, 存取频度是指每天 （ 或每小时, 或每周 ） 存取几次,
每次存取多少数据等信息 。 存取方法指的是批处理, 还是联
机处理；是检索还是更新；是顺序检索还是随机检索等 。
33
(5) 处理过程
?处理过程的处理逻辑通常用判定表或判定树来描述,
数据字典只用来描述处理过程的说明性信息 。
?处理过程包括 ｛ 处理过程名, 说明, 输入,｛ 数据
流 ｝, 输出,｛ 数据流 ｝, 处理, ｛ 简要说明 ｝｝ 。
?其中, 简要说明主要说明处理过程的功能及处理要
求 。
?功能是指该处理过程用来做什么 （ 不是怎么做 ）,
处理要求指该处理频度要求, 如单位时间里处理多
少事务, 多少数据量, 响应时间要求等, 这些处理
要求是后面物理设计的输入及性能评价的标准 。
?最终形成的数据流图和数据字典为, 需求分析
说明书, 的主要内容，这是下一步进行概念设
计的基础。
34
6.3.1 概念结构设计的必要性
? 在需求分析阶段, 设计人员充分调查并描述了用户的需求,
但这些需求只是现实世界的具体要求, 应把这些需求抽象
为信息世界的结构, 才能更好地实现用户的需求 。
? 概念设计就是将需求分析得到的用户需求抽象为信息结构,
即概念模型 。
? 在早期的数据库设计中, 概念设计并不是一个独立的设计
阶段 。 当时的设计方式是在需求分析之后, 接着就进行逻
辑设计 。 这样设计人员在进行逻辑设计时, 考虑的因素太
多, 既要考虑用户的信息, 又要考虑具体 DBMS的限制,
使得设计过程复杂化, 难以控制 。 为了改善这种状况,
P.P.S.chen设计了基于 E-R模型的数据库设计方法, 即在需
求分析和逻辑设计之间增加了一个概念设计阶段 。 在这个
阶段, 设计人员仅从用户角度看待数据及处理要求和约束,
产生一个反映用户观点的概念模型, 然后再把概念模型转
换成逻辑模型 。 这样做有三个好处：
6.3 概念结构设计
35
(1) 从逻辑设计中分离出概念设计以后, 各阶段的任
务相对单一化, 设计复杂程度大大降低, 便于组织
管理 。
(2) 概念模型不受特定的 DBMS的限制, 也独立于存储
安排和效率方面的考虑, 因而比逻辑模型更为稳定 。
(3) 概念模型不含具体的 DBMS所附加的技术细节, 更
容易为用户所理解, 因而更有可能准确反映用户的
信息需求 。
?设计概念模型的过程称为概念设计 。 概念模型
在数据库的各级模型中的地位如图 6.8所示 。
36
图 6.8 数据库各级模型的形成
应用 1
应用要求
应用 2
应用要求
应用 3
应用要求
概念模式
综合
应用 1
外模式 1
应用 2
外模式 2
应用 3
外模式 3
概念模式
概念模式
转换
映象
映象
37
6.3.2 概念模型的特点
? 概念模型作为概念设计的表达工具, 为数据库提供一
个说明性结构, 是设计数据库逻辑结构即逻辑模型的
基础 。 因此, 概念模型必须具备以下特点：
(1) 语义表达能力丰富 。 概念模型能表达用户的各种需求, 充
分反映现实世界, 包括事物和事物之间的联系, 用户对数据
的处理要求, 它是现实世界的一个真实模型 。
(2) 易于交流和理解 。 概念模型是 DBA,应用开发人员和用户之
间的主要界面, 因此, 概念模型要表达自然, 直观和容易理
解, 以便和不熟悉计算机的用户交换意见, 用户的积极参与
是保证数据库设计和成功的关键 。
(3) 易于修改和扩充 。 概念模型要能灵活地加以改变, 以反映
用户需求和现实环境的变化 。
(4) 易于向各种数据模型转换 。 概念模型独立于特定的 DBMS，
因而更加稳定, 能方便地向关系模型, 网状模型或层次模型
等各种数据模型转换 。
? 人们提出了许多概念模型，其中最著名、最实用的一
种是 E-R模型，它将现实世界的信息结构统一用属性、
实体以及它们之间的联系来描述。
38
6.3.3 概念结构设计的方法与步骤
1,概念结构设计的方法
? 设计概念结构的 E-R模型可采用四种方法 。
(1) 自顶向下 。 先定义全局概念结构 E-R模型的框架, 再逐步细
化 。 如图 6.9（ a） 所示 。
(2) 自底向上 。 先定义各局部应用的概念结构 E-R模型, 然后将
它们集成, 得到全局概念结构 E-R模型 。 如图 6.9（ b） 所示 。
(3) 逐步扩张 。 先定义最重要的核心概念 E-R模型, 然后向外扩
充, 以滚雪球的方式逐步生成其他概念结构 E-R模型 。 如图
6.9（ c） 所示 。
(4) 混合策略 。 该方法采用自顶向下和自底向上相结合的方法,
先自顶向下定义全局框架, 再以它为骨架集成自底向上方法
中设计的各个局部概念结构 。
? 其中最常用的方法是自底向上。即自顶向下地进行需
求分析，再自底向上地设计概念结构。
39
2,概念结构设计的步骤
? 自底向上的设计方法可分为两步, 如图 6.10所示：
(1) 进行数据抽象, 设计局部 E-R模型, 即设计用户视图 。
(2) 集成各局部 E-R模型, 形成全局 E-R模型, 即视图的集成 。
3,数据抽象与局部 E-R模型设计
? 概念结构是对现实世界的一种抽象 。
? 所谓抽象是对实际的人, 物, 事和概念进行人为处理,
它抽取人们关心的共同特性, 忽略非本质的细节, 并
把这些特性用各种概念精确地加以描述, 这些概念组
成了某种模型 。
? 概念结构设计首先要根据需求分析得到的结果 （ 数据
流图, 数据字典等 ） 对现实世界进行抽象, 设计各个
局部 E-R模型 。
40
图 6.9 概念结构设计的方法
…
………概念模式
…
…
(b) 自底向上的设计方法
概念模式 概念模式 概念模式
子需
求
概念模式 概念模式
全局概念模式
子需
求
子需
求
子需
求
…
全局概念模式
…
…
概念模式
概念模式 概念模式 概念模式 概念模式
(a) 自顶向下的设计方法
概念模式
需
求
(c) 逐步扩张的设计方法
核心需
求
需
求
核心
概念
结构
全局
概念
结构
…
41
图 6.10 自底向上方法的设计步骤
需求分析
数据抽象、
局部视图设计
视图集成
征求用
户意见
DFD,DD
局部 E－ R图
全局 E－ R图
逻辑结构设计
42
(1) E-R方法
? E-R方法是, 实体 -联系方法, （ Entity-Relationship
Approach） 的简称 。 它是描述现实世界概念结构模型的
有效方法 。 用 E-R方法建立的概念结构模型称为 E-R模型,
或称为 E-R图 。
? E-R图基本成分包含实体型, 属性和联系 。 （ 在第 1章已
经介绍过它们的基本概念, 这里只给出它们的表示方
法 。 ）
① 实体型：用矩形框表示, 框内标注实体名称 。 如图 6.11（ a） 所
示 。
② 属性：用椭圆形框表示, 框内标注属性名称 。 如图 6.11（ b） 所
示 。
③ 联系：指实体之间的联系, 有一对一 （ 1,1）, 一对多 （ 1,n）
或多对多 （ m, n） 三种联系类型 。 例如系主任领导系, 学生属
于某一系, 学生选修课程, 工人生产产品, 这里, 领导,,, 属
于,,, 选修,,, 生产, 表示实体间的联系, 可以作为联系名
称 。 联系用菱形框表示, 框内标注联系名称 。 如图 6.11（ c） 所示 。
43
?现实世界的复杂性导致实体联系的复杂性 。 表现在 E-R
图上可以归结为图 6.12所示的几种基本形式：
① 两个实体之间的联系, 如图 6.12（ a） 所示 。
② 两个以上实体间的联系, 如图 6.12（ b） 所示 。
③ 同一实体集内部各实体之间的联系, 例如一个部门内的职工
有领导与被领导的联系, 即某一职工 （ 干部 ） 领导若干名职工,
而一个职工 （ 普通员工 ） 仅被另外一个职工直接领导, 这就构
成了实体内部的一对多的联系 。 如图 6.12（ c） 所示 。
?需要注意的是，因为联系本身也是一种实体型，所以
联系也可以有属性。如果一个联系具有属性，则这些
联系也要用无向边与该联系连接起来。例如，学生选
修的课程有相应的成绩。这里的, 成绩, 既不是学生
的属性，也不是课程的属性，只能是学生选修课程的
联系的属性。图 6.12（ b）中, 供应数量, 是, 供应,
联系的属性。
44
?E-R图的基本思想就是分别用矩形框、椭圆形
框和菱形框表示实体、属性和联系，使用无向
边将属性与其相应的实体连接起来，并将联系
分别和有关实体相连接，注明联系类型。
?图 6.12为几个 E-R图的例子，只给出了实体及
其 E-R图，省略了实体的属性。
?图 6.13为一个描述学生与课程联系的完整的 E-
R图。
45
6.11 E-R图的三种基本成份及其图形的表示方法
学生 选修学号
(a)实体 (b)属性 (c)联系
46
图 6.12 实体及其联系图
(a)两个实体之间的联系
学生
选修 成绩
课程
系主任
领导
系
学生
属于
系
1
1
n
1
系
主
任
n
(c)实体集内部的联系
m
职工
领导
1 n
供应商
供应 数量
零件项目
m
n n
(b)多个实体之间的联系
47
图 6.13 学生与课程联系的完整的 E－ R图
课
程
名
学生
学
号
姓
名
性
别
年
龄
系
别
课程
课程
号
学
分
n
选修
成
绩
m
48
(2) 数据抽象
? 在系统需求分析阶段, 最后得到了多层数据流图, 数
据字典和系统分析报告 。 建立局部 E-R模型, 就是根据
系统的具体情况, 在多层的数据流图中选择一个适当
层次的数据流图, 作为设计分 E-R图的出发点, 让这组
图中毎一部分对应一个局部应用 。 在前面选好的某一
层次的数据流图中, 每个局部应用都对应了一组数据
流图, 局部应用所涉及的数据存储在数据字典中 。 现
在就是要将这些数据从数据字典中抽取出来, 参照数
据流图, 确定每个局部应用包含哪些实体, 这些实体
又包含哪些属性, 以及实体之间的联系及其类型 。
? 设计局部 E-R模型的关键就是正确划分实体和属性 。
实体和属性之间在形式上并无可以明显区分的界限,
通常是按照现实世界中事物的自然划分来定义实体和
属性, 将现实世界中的事物进行数据抽象, 得到实体
和属性 。
? 一般有两种数据抽象：分类和聚集 。
49
① 分类 （ Classification）
?分类定义某一类概念作为现实世界中一组对象的类
型, 将一组具有某些共同特性和行为的对象抽象为
一个实体 。 对象和实体之间是, is member of”的
关系 。
?例如, 在教学管理中,, 赵亦, 是一名学生, 表示
,赵亦, 是学生中的一员, 她具有学生们共同的特
性和行为 。
② 聚集 （ Aggregation）
?聚集定义某一类型的组成成份, 将对象类型的组成
成份抽象为实体的属性 。 组成成份与对象类型之间
是, is part of”的关系 。
?例如, 学号, 姓名, 性别, 年龄, 系别等可以抽象
为学生实体的属性, 其中学号是标识学生实体的主
键 。
50
(2) 局部 E-R模型设计
? 数据抽象后得到了实体和属性, 实际上实体和属性是
相对而言的, 往往要根据实际情况进行必要的调整 。
在调整中要遵循两条原则：
① 实体具有描述信息, 而属性没有 。 即属性必须是不可分的数
据项, 不能再由另一些属性组成 。
② 属性不能与其他实体具有联系, 联系只能发生在实体之间 。
?例如：学生是一个实体, 学号, 姓名, 性别, 年龄, 系别等
是学生实体的属性, 系别只表示学生属于哪个系, 不涉及系
的具体情况, 换句话说, 没有需要进一步描述的特性, 即是
不可分的数据项, 则根据原则 ① 可以作为学生实体的属性 。
但如果考虑一个系的系主任, 学生人数, 教师人数, 办公地
点等, 则系别应看作一个实体 。 如图 6.14所示 。
?又如,,职称, 为教师实体的属性，但在涉及住房分配时，
由于分房与职称有关，即职称与住房实体之间有联系，则根
据原则②，职称应作为一个实体。如图 6.15所示。
51
图 6.14 系别作为一个属性或实体
学生
学生 系别
属
于
n 1
m 姓
名
性
别
年
龄
系
别
学
号
姓
名
性
别
年
龄
系主任 学生人
数
教师人
数
办公地
点
52
图 6.15 职称作为一个属性或实体
聘任
教师 教师
n 1
职称
分
配
住房
姓名 性别 职称 姓名 性别
53
? 此外, 我们可能会遇到这样的情况, 同一数据项, 可
能由于环境和要求的不同, 有时作为属性, 有时则作
为实体, 此时必须根据实际情况而定 。 一般情况下,
凡能作为属性对待的, 应尽量作为属性, 以简化 E-R图
的处理 。
? 下面举例说明局部 E-R模型设计 。
? 在简单的教务管理系统中, 有如下语义约束 。
① 一个学生可选修多门课程, 一门课程可为多个学生选修, 因
此学生和课程是多对多的联系；
② 一个教师可讲授多门课程, 一门课程可为多个教师讲授, 因
此教师和课程也是多对多的联系；
③ 一个系可有多个教师, 一个教师只能属于一个系, 因此系和
教师是一对多的联系, 同样系和学生也是一对多的联系 。
? 根据上述约定，可以得到如图 6.16所示的学生选课局
部Ｅ－Ｒ图和如图 6.17所示的教师任课局部Ｅ－Ｒ图。
形成局部 E-R模型后，应该返回去征求用户意见，以
求改进和完善，使之如实地反映现实世界。
? E-R图的优点就是易于被用户理解，便于交流。
54
图 6.16 学生选课局部Ｅ－Ｒ图
m
m n
m
１
名称 系
拥
有
１
学生
学号 姓名 性别 年龄
开课
课程 教师
号
课程号 课程名
选修
成绩
平均成绩
55
图 6.17 教师任课局部Ｅ－Ｒ图
1
m
教师
号
姓名 性别 职称 课程
号
教师 讲
授
课程n
属
于
单位
单位
名
电话
m
56
4,全局 E-R模型设计
?局部 E-R模型设计完成之后, 下一步就是集成
各局部 E-R模型, 形成全局 E-R模型, 即视图的
集成 。 视图集成的方法有两种：
① 多元集成法, 一次性将多个局部 E-R图合并为一个
全局 E-R图, 如图 6.18（ a） 所示 。
② 二元集成法, 首先集成两个重要的局部视图, 以后
用累加的方法逐步将一个新的视图集成进来, 如图
6.18（ b） 所示 。 在实际应用中, 可以根据系统复杂
性选择这两种方案 。 一般采用逐步集成的方法, 如
果局部视图比较简单, 可以采用多元集成法 。 一般
情况下, 采用二元集成法, 即每次只综合两个视图,
这样可降低难度 。 无论使用哪一种方法, 视图集成
均分成两个步骤, 如图 6.19所示 。
① 合并, 消除各局部 E-R图之间的冲突, 生成初步 E-R图 。
② 优化, 消除不必要的冗余, 生成基本 E-R图 。
57
图 6.18 局部视图合并成全局视图
(a) 多元集成法
局部 E－ R图 1 …局部 E－ R图 2 局部 E－ R图 n
初步 E－ R图
基本 E－ R图
局部 E－ R图 1 局部 E－ R图 2
合并 E－ R图 12 局部 E－ R图 3
…
初步 E－ R图
基本 E－ R图
(b) 二元集成法
58
图 6.19 视图集成
局部Ｅ－Ｒ图
合并
（ 消 除冲 突
）
修改 与重 构
（ 消 除不 必
要的冗余 ）
集成视图
基本Ｅ－Ｒ图
初步Ｅ－Ｒ图 分析 规范化理论
59
(1) 合并局部 E-R图, 生成初步 E-R图
? 这个步骤将所有的局部 E-R图综合成全局概念结构 。
? 全局概念结构它不仅要支持所有的局部 E-R模型, 而且
必须合理地表示一个完整, 一致的数据库概念结构 。
? 由于各个局部应用不同, 通常由不同的设计人员进行
局部 E-R图设计, 因此, 各局部 E-R图不可避免地会有
许多不一致的的地方, 我们称之为 冲突 。
? 合并局部 E-R图时并不能简单地将各个 E-R图画到一起,
而必须消除各个局部 E-R图中的不一致, 使合并后的
全局概念结构不仅支持所有的局部 E-R模型, 而且必
须是一个能为全系统中所有用户共同理解和接受的完
整的概念模型 。
? 合并局部 E-R图的关键就是合理消除各局部 E-R图中的
冲突 。
60
?E-R图中的冲突有三种：属性冲突, 命名
冲突和结构冲突 。
① 属性冲突
?属性冲突又分为属性值域冲突和属性的取值单
位冲突 。
a.属性值域冲突, 即属性值的类型, 取值范围或取
值集合不同 。 比如学号, 有些部门将其定义为数值
型, 而有些部门将其定义为字符型 。 又如年龄, 有
的可能用出生年月表示, 有的则用整数表示 。
b.属性的取值单位冲突 。 比如零件的重量, 有的以
公斤为单位, 有的以斤为单位, 有的则以克为单位 。
?属性冲突属于用户业务上的约定, 必须与用户
协商后解决 。
61
② 命名冲突
? 命名不一致可能发生在实体名, 属性名或联系名之间,
其中属性的命名冲突更为常见 。
? 一般表现为同名异义或异名同义 （ 实体, 属性, 联系
名 ） 。
a.同名异义, 即同一名字的对象在不同的部门中具有不同的
意义 。
比如,, 单位, 在某些部门表示为人员所在的部门, 而在
某些部门可能表示物品的重量, 长度等属性 。
b.异名同义, 即同一意义的对象在不同的部门中具有不同的
名称 。
比如, 对于, 房间, 这个名称, 在教务管理部门中对应着
为教室, 而在后勤管理部门对应为学生宿舍 。
? 命名冲突的解决方法同属性冲突, 需要与各部门协商,
讨论后加以解决 。
62
③ 结构冲突
a.同一对象在不同应用中有不同的抽象, 可能为实体,
也可能为属性 。 例如, 教师的职称在某一局部应用
中被当作实体, 而在另一局部应用中被当作属性 。
这类冲突在解决时, 就是使同一对象在不同应用中具有相同的
抽象, 或把实体转换为属性, 或把属性转换为实体 。 但都要符
合 6.3.3中所介绍的准则 。
b.同一实体在不同应用中属性组成不同, 可能是属性
个数或属性次序不同 。
解决办法是, 合并后实体的属性组成为各局部 E-R图中的同名
实体属性的并集, 然后再适当调整属性的次序 。
c.同一联系在不同应用中呈现不同的类型 。 比如 E1与
E2在某一应用中可能是一对一联系, 而在另一应用
中可能是一对多或多对多联系, 也可能是在 E1,E2、
E3三者之间有联系 。
这种情况应该根据应用的语义对实体联系的类型进行综合或调
整。
63
?下面以教务管理系统中的两个局部 E-R图为例,
来说明如何消除各局部 E-R图之间的冲突, 进
行局部 E-R模型的合并, 从而生成初步 E-R图 。
?首先, 这两个局部 E-R图中存在着命名冲突, 学生
选课局部Ｅ－Ｒ图中的实体, 系, 与教师任课局部
Ｅ－Ｒ图中的实体, 单位,, 都是指, 系,, 即所
谓的异名同义, 合并后统一改为, 系,, 这样属性
,名称, 和, 单位, 即可统一为, 系名, 。
?其次, 还存在着结构冲突, 实体, 系, 和实体, 课
程, 在两个不同应用中的属性组成不同, 合并后这
两个实体的属性组成为原来局部 E-R图中的同名实
体属性的并集 。 解决上述冲突后, 合并两个局部 E-
R图, 生成如图 6.20所示的初步的全局 E-R图 。
64
图 6.20 教务管理系统的初步 E－ R图
m
n
1系
属
于
教师
拥
有
学生
开
课
讲
授
选
修
课程
m
m
n
m
1
m
1
学号 姓名 性别 年龄
平均成绩
成绩
教师
号
课程号 课程
名
教师
号
姓名 性别 职称系名 电话
65
(2) 消除不必要的冗余, 生成基本 E-R图
? 所谓冗余, 在这里指冗余的数据和实体之间冗余的联
系 。 冗余的数据是指可由基本的数据导出的数据, 冗
余的联系是由其他的联系导出的联系 。 在上面消除冲
突合并后得到的初步 E— R图中, 可能存在冗余的数据
或冗余的联系 。 冗余的存在容易破坏数据库的完整性,
给数据库的维护增加困难, 应该消除 。 我们把消除了
冗余的初步 E-R图称为基本 E-R图 。
? 通常采用分析的方法消除冗余 。 数据字典是分析冗余
数据的依据, 还可以通过数据流图分析出冗余的联系 。
? 如在图 6.20所示的初步 E-R图中,, 课程, 实体中的属
性, 教师号, 可由, 讲授, 这个教师与课程之间的联
系导出, 而学生的平均成绩可由, 选修, 联系中的属
性, 成绩, 中计算出来, 所以, 课程, 实体中的, 教
师号, 与, 学生, 实体中的, 平均成绩, 均属于冗余
数据 。
66
? 另外,, 系, 和, 课程, 之间的联系, 开课,, 可以
由, 系, 和, 教师, 之间的, 属于, 联系与, 教师,
和, 课程, 之间的, 讲授, 联系推导出来, 所以, 开
课, 属于冗余联系 。
? 这样, 图 6.20的初步 E-R图在消除冗余数据和冗余联系
后, 便可得到基本的 E-R模型, 如图 6.21所示 。
? 最终得到的基本 E-R模型是企业的概念模型, 它代表
了用户的数据要求, 是沟通, 要求, 和, 设计, 的桥
梁 。 它决定数据库的总体逻辑结构, 是成功建立数据
库的关键 。 如果设计不好, 就不能充分发挥数据库的
功能, 无法满足用户的处理要求 。
? 因此, 用户和数据库人员必须对这一模型反复讨论,
在用户确认这一模型已正确无误的反映了他们的要求
后, 才能进入下一阶段的设计工作 。
67
图 6.21 教务管理系统的基本 E－ R图
n
1系
属
于
教师
拥
有
学生
讲
授
选
修
课程
m
m
n
m
1
m
学号 姓名 性别 年龄 成绩 课程号 课程名
教师号 姓名 性别 职称系名 电话
68
6.4.1 逻辑结构设计的任务和步骤
? 概念结构设计阶段得到的 E-R模型是用户的模型, 它独
立于任何一种数据模型, 独立于任何一个具体的 DBMS。
为了建立用户所要求的数据库, 需要把上述概念模型
转换为某个具体的 DBMS所支持的数据模型 。 数据库逻
辑设计的任务是将概念结构转换成特定 DBMS所支持的
数据模型的过程 。 从此开始便进入了, 实现设计, 阶
段, 需要考虑到具体的 DBMS的性能, 具体的数据模型
特点 。
? 从 E-R图所表示的概念模型可以转换成任何一种具体
的 DBMS所支持的数据模型, 如网状模型, 层次模型
和关系模型 。 这里只讨论关系数据库的逻辑设计问题,
所以只介绍 E-R图如何向关系模型进行转换 。
6.4 逻辑结构设计
69
?一般的逻辑设计分为以下三步 （ 如图 6.22所
示 ）,
(1) 初始关系模式设计；
(2) 关系模式规范化；
(3) 模式的评价与改进 。
70
图 6.22 关系数据库的逻辑设计
概念结构设计
初始关系模式设计
关系模式规范化
模式评价
是否修正
以 DBMS语法描述
物理设计
模式修正
否
是
71
6.4.2 初始关系模式设计
1,转换原则
? 概念设计中得到的 E-R图是由实体, 属性和联系组成的,
而关系数据库逻辑设计的结果是一组关系模式的集合 。
所以将 E-R图转换为关系模型实际上就是将实体, 属性
和联系转换成关系模式 。 在转换中要遵循以下原则：
(1) 一个实体转换为一个关系模式, 实体的属性就是关系的
属性, 实体的键就是关系的键 。
(2) 一个联系转换为一个关系模式, 与该联系相连的各实体
的键以及联系的属性均转换为该关系的属性 。 该关系的键有
三种情况：
① 如果联系为 1:1,则每个实体的键都是关系的候选键；
② 如果联系为 1,n, 则 n端实体的键是关系的键；
③ 如果联系为 n,m,则各实体键的组合是关系的键 。
72
2,具体做法
(1) 把每一个实体转换为一个关系
?首先分析各实体的属性, 从中确定其主键, 然
后分别用关系模式表示 。 例如, 以图 6.21的 E-
R模型为例, 四个实体分别转换成四个关系模
式：
? 学生 （ 学号, 姓名, 性别, 年龄 ）
? 课程 （ 课程号, 课程名 ）
? 教师 （ 教师号, 姓名, 性别, 职称 ）
? 系 （ 系名, 电话 ）
?其中, 有下划线者表示是主键 。
73
(2) 把每一个联系转换为关系模式
?由联系转换得到的关系模式的属性集中, 包含
两个发生联系的实体中的主键以及联系本身的
属性, 其关系键的确定与联系的类型有关 。
?例如, 还以图 6.21的 E-R模型为例, 四个联系
也分别转换成四个关系模式：
?属于 （ 教师号, 系名 ）
?讲授 （ 教师号, 课程号 ）
?选修 （ 学号, 课程号, 成绩 ）
?拥有 （ 系名, 学号 ）
74
(3) 特殊情况的处理
?三个或三个以上实体间的一个多元联系在转换
为一个关系模式时, 与该多元联系相连的各实
体的主键及联系本身的属性均转换成为关系的
属性, 转换后所得到的关系的主键为各实体键
的组合 。
?例如, 图 6.23表示供应商, 项目和零件三个实
体之间的多对多联系, 如果已知三个实体的主
键分别为, 供应商号,,, 项目号, 与, 零件
号,, 则它们之间的联系, 供应, 可转换为关
系模式, 其中供应商号, 项目号, 零件号为此
关系的组合关系键 。
?供应 （ 供应商号, 项目号, 零件号, 数量 ）
75
供应商
供应 数量
零件项目
m
n n
图 6.23 多个实体之间的联系
76
6.4.3 关系模式规范化
? 应用规范化理论对上述产生的关系的逻辑模式进行初
步优化, 以减少乃至消除关系模式中存在的各种异常,
改善完整性, 一致性和存储效率 。
? 规范化理论是数据库逻辑设计的指南和工具, 规范化
过程可分为两个步骤：确定规范式级别, 实施规范化
处理 。
1,确定范式级别
?考查关系模式的函数依赖关系, 确定范式等级, 逐一分析各
关系模式, 考查是否存在部分函数依赖, 传递函数依赖等,
确定它们分别属于第几范式 。
2,实施规范化处理
?确定范式级别后, 利用第 4章的规范化理论, 逐一考察各个关
系模式, 根据应用要求, 判断它们是否满足规范要求, 可用
已经介绍过的规范化方法和理论将关系模式规范化 。
77
?综合以上数据库的设计过程, 规范化理论在数
据库设计中有如下几方面的应用：
(1) 在需求分析阶段, 用数据依赖概念分析和表示
各个数据项之间的联系 。
(2) 在概念结构设计阶段, 以规范化理论为指导,
确定关系键, 消除初步 E-R图中冗余的联系 。
(3) 在逻辑结构设计阶段, 从 E-R图向数据模型转
换过程中, 用模式合并与分解方法达到规范化级别 。
78
6.4.4 模式评价与改进
1,模式评价
? 关系模式的规范化不是目的而是手段, 数据库设计的
目的是最终满足应用需求 。 因此, 为了进一步提高数
据库应用系统的性能, 还应该对规范化后产生的关系
模式进行评价, 改进, 经过反复多次的尝试和比较,
最后得到优化的关系模式 。
? 模式评价的目的是检查所设计的数据库模式是否满足
用户的功能要求, 效率, 确定加以改进的部分 。 模式
评价包括功能评价和性能评价 。
? (1) 功能评价
?功能评价指对照需求分析的结果, 检查规范化后的关系模式
集合是否支持用户所有的应用要求 。 关系模式必须包括用户
可能访问的所有属性 。 在涉及多个关系模式的应用中, 应确
保联接后不丢失信息 。 如果发现有的应用不被支持, 或不完
全被支持, 则应该改进关系模式 。 发生这种问题的原因可能
是在逻辑设计阶段, 也可能是在需求分析或概念设计阶段 。
是哪个阶段的问题就返回到哪个阶段去, 因此有可能对前两
个阶段再进行评审, 解决存在的问题 。
79
? 在功能评价的过程中，可能会发现冗余的关系模式或属性，这时应
对它们加以区分，搞清楚它们是为未来发展预留的，还是某种错误
造成的，比如名字混淆。如果属于错误处置，进行改正即可，而如
果这种冗余来源于前两个设计阶段，则也要返回重新进行评审。
(2) 性能评价
? 对于目前得到的数据库模式, 由于缺乏物理设计所提
供的数量测量标准和相应的评价手段, 所以性能评价
是比较困难的, 只能对实际性能进行估计, 包括逻辑
记录的存取数, 传送量以及物理设计算法的模型等 。
? 美国密执安大学的 T.Teorey和 J.Fry于 1980年提出的逻
辑记录访问 （ Logical Record Access,LRA） 方法是
一种常用的模式性能评价方法 。 LRA方法对网状模型和
层次模型较为实用, 对于关系模型的查询也能起一定
的估算作用 。
? 有关 LRA方法本书不详细介绍, 读者可以参考有关书
籍 。
80
2,模式改进
?根据模式评价的结果, 对已生成的模式进行改
进 。
?如果因为需求分析, 概念设计的疏漏导致某些应用
不能得到支持, 则应该增加新的关系模式或属性 。
?如果因为性能考虑而要求改进, 则可采用合并或分
解的方法 。
(1) 合并
?如果有若干个关系模式具有相同的主键, 并且
对这些关系模式的处理主要是查询操作, 而且
经常是多关系的查询, 那么可对这些关系模式
按照组合使用频率进行合并 。
?这样便可以减少联接操作而提高查询效率 。
81
(2) 分解
?为了提高数据操作的效率和存储空间的利用率,
最常用和最重要的模式优化方法就是分解, 根
据应用的不同要求, 可以对关系模式进行垂直
分解和水平分解 。
?水平分解 是把关系的元组分为若干子集合, 定
义每个子集合为一个子关系 。
?对于经常进行大量数据的分类条件查询的关系,
可进行水平分解, 这样可以减少应用系统每次
查询需要访问的记录数, 从而提高了查询性能 。
82
?例如, 有学生关系 （ 学号, 姓名, 类别 …… ）, 其
中类别包括大专生, 本科生和研究生 。 如果多数查
询一次只涉及其中的一类学生, 就应该把整个学生
关系水平分割为大专生, 本科生和研究生三个关系 。
?垂直分解 是把关系模式的属性分解为若干子集
合, 形成若干子关系模式 。 垂直分解的原则是
把经常一起使用的属性分解出来, 形成一个子
关系模式 。
?例如, 有教师关系 （ 教师号, 姓名, 性别, 年龄,
职称, 工资, 岗位津贴, 住址, 电话 ）, 如果经常
查询的仅是前六项, 而后三项很少使用, 则可以将
教师关系进行垂直分割, 得到两个教师关系：
教师关系 1（ 教师号, 姓名, 性别, 年龄, 职称, 工资 ）
教师关系 2（ 教师号, 岗位津贴, 住址, 电话 ）
?这样, 便减少了查询的数据传递量, 提高了查
询速度 。
83
? 垂直分解可以提高某些事务的效率, 但也有可能使另
一些事务不得不执行连接操作, 从而降低了效率 。 因
此是否要进行垂直分解要看分解后的所有事务的总效
率是否得到了提高 。 垂直分解要保证分解后的关系具
有无损连接性和函数依赖保持性 。 相关的分解算法已
经在第 4章进行了详细介绍 。
? 经过多次的模式评价和模式改进之后, 最终的数据库
模式得以确定 。 逻辑设计阶段的结果是全局逻辑数据
库结构 。 对于关系数据库系统来说, 就是一组符合一
定规范的关系模式组成的关系数据库模型 。
? 数据库系统的数据物理独立性特点消除了由于物理存
储改变而引起的对应程序的修改 。 标准的 DBMS例行
程序应适用于所有的访问, 查询和更新事务的优化应
当在系统软件一级上实现 。 这样, 逻辑数据库确定之
后, 就可以开始进行应用程序设计了 。
84
?数据库最终要存储在物理设备上 。 对于给定的
逻辑数据模型, 选取一个最适合应用环境的物
理结构的过程, 称为数据库物理设计 。 物理设
计的任务是为了有效地实现逻辑模式, 确定所
采取的存储策略 。 此阶段是以逻辑设计的结果
作为输入, 结合具体 DBMS的特点与存储设备特
性进行设计, 选定数据库在物理设备上的存储
结构和存取方法 。
?数据库的物理设计可分为两步：
(1) 确定物理结构, 在关系数据库中主要指存取方
法和存储结构；
(2)评价物理结构, 评价的重点是时间和空间效率 。
6.5 数据库物理设计
85
6.5.1 确定物理结构
? 设计人员必须深入了解给定的 DBMS的功能, DBMS提供
的环境和工具, 硬件环境,特别是存储设备的特征 。 另
一方面也要了解应用环境的具体要求, 如各种应用的
数据量, 处理频率和响应时间等 。 只有, 知己知彼,
才能设计出较好的物理结构 。
1,存储记录结构的设计
? 在物理结构中, 数据的基本存取单位是存储记录 。 有了逻辑记录结
构以后, 就可以设计存储记录结构, 一个存储记录可以和一个或多
个逻辑记录相对应 。 存储记录结构包括记录的组成, 数据项的类型
和长度, 以及逻辑记录到存储记录的映射 。 某一类型的所有存储记
录的集合称为, 文件,, 文件的存储记录可以是定长的, 也可以是
变长的 。
? 文件组织或文件结构是组成文件的存储记录的表示法 。 文件结构应
该表示文件格式, 逻辑次序, 物理次序, 访问路径, 物理设备的分
配 。 物理数据库就是指数据库中实际存储记录的格式, 逻辑次序和
物理次序, 访问路径, 物理设备的分配 。
? 决定存储结构的主要因素包括存取时间, 存储空间和维护代价三个
方面 。 设计时应当根据实际情况对这三个方面进行综合权衡 。 一般
DBMS也提供一定的灵活性可供选择, 包括聚簇和索引 。
86
(1) 聚簇 （ Cluster）
? 聚簇就是为了提高查询速度, 把在一个 （ 或一组 ） 属
性上具有相同值的元组集中地存放在一个物理块中 。
如果存放不下, 可以存放在相邻的物理块中 。 其中,
这个 （ 或这组 ） 属性称为聚簇码 。
? 为什么要使用聚簇呢？ 聚簇有两个作用：
① 使用聚簇以后, 聚簇码相同的元组集中在一起了, 因而聚簇
值不必在每个元组中重复存储, 只要在一组中存储一次即可,
因此可以节省存储空间 。
② 聚簇功能可以大大提高按聚簇码进行查询的效率 。 例如, 假
设要查询学生关系中计算机系的学生名单, 设计算机系有 300名
学生 。 在极端情况下, 这些学生的记录会分布在 300个不同的物
理块中, 这时如果要查询计算机系的学生, 就需要做 300次的
I/O操作, 这将影响系统查询的性能 。 如果按照系别建立聚簇,
使同一个系的学生记录集中存放, 则每做一次 I/O操作, 就可以
获得多个满足查询条件和记录, 从而显著地减少了访问磁盘的
次数 。
87
(2) 索引
? 存储记录是属性值的集合, 主关系键可以惟一确定一
个记录, 而其他属性的一个具体值不能惟一确定是哪
个记录 。 在主关系键上应该建立惟一索引, 这样不但
可以提高查询速度, 还能避免关系键重复值的录入,
确保了数据的完整性 。
? 在数据库中, 用户访问的最小单位是属性 。 如果对某
些非主属性的检索很频繁, 可以考虑建立这些属性的
索引文件 。 索引文件对存储记录重新进行内部链接,
从逻辑上改变了记录的存储位置, 从而改变了访问数
据的入口点 。 关系中数据越多索引的优越性也就越明
显 。
? 建立多个索引文件可以缩短存取时间, 但是增加了索
引文件所占用的存储空间以及维护的开销 。 因此, 应
该根据实际需要综合考虑 。
88
2,访问方法的设计
? 访问方法是为存储在物理设备 （ 通常指辅存 ） 上的数据提
供存储和检索能力的方法 。 一个访问方法包括存储结构和
检索机构两个部分 。 存储结构限定了可能访问的路径和存
储记录；检索机构定义了每个应用的访问路径, 但不涉及
存储结构的设计和设备分配 。
? 存储记录是属性的集合, 属性是数据项类型, 可用作主键
或辅助键 。 主键惟一地确定了一个记录 。 辅助键是用作记
录索引的属性, 可能并不惟一确定某一个记录 。
? 访问路径的设计分成主访问路径与辅访问路径的设计 。 主
访问路径与初始记录的装入有关, 通常是用主键来检索的 。
首先利用这种方法设计各个文件, 使其能最有效地处理主
要的应用 。 一个物理数据库很可能有几套主访问路径 。 辅
访问路径是通过辅助键的索引对存储记录重新进行内部链
接, 从而改变访问数据的入口点 。 用辅助索引可以缩短访
问时间, 但增加了辅存空间和索引维护的开销 。 设计者应
根据具体情况作出权衡 。
89
3,数据存放位置的设计
?为了提高系统性能, 应该根据应用情况将数据
的易变部分, 稳定部分, 经常存取部分和存取
频率较低部分分开存放 。
?例如, 目前许多计算机都有多个磁盘, 因此可
以将表和索引分别存放在不同的磁盘上, 在查
询时, 由于两个磁盘驱动器并行工作, 可以提
高物理读写的速度 。
?在多用户环境下, 可能将日志文件和数据库对
象 （ 表, 索引等 ） 放在不同的磁盘上, 以加快
存取速度 。 另外, 数据库的数据备份, 日志文
件备份等, 只在数据库发生故障进行恢复时才
使用, 而且数据量很大, 可以存放在磁带上,
以改进整个系统的性能 。
90
4,系统配置的设计
? DBMS产品一般都提供了一些系统配置变量, 存储分配
参数, 供设计人员和 DBA对数据库进行物理优化 。 系统
为这些变量设定了初始值, 但是这些值不一定适合每
一种应用环境, 在物理设计阶段, 要根据实际情况重
新对这些变量赋值, 以满足新的要求 。
? 系统配置变量和参数很多, 例如, 同时使用数据库的
用户数, 同时打开的数据库对象数, 内存分配参数,
缓冲区分配参数 （ 使用的缓冲区长度, 个数 ）, 存储
分配参数, 数据库的大小, 时间片的大小, 锁的数目
等, 这些参数值影响存取时间和存储空间的分配, 在
物理设计时要根据应用环境确定这些参数值, 以使系
统的性能达到最优 。
91
6.5.2 评价物理结构
?和前面几个设计阶段一样，在确定了数据库的
物理结构之后，要进行评价，重点是时间和空
间的效率。
?如果评价结果满足设计要求，则可进行数据库
实施。
?实际上，往往需要经过反复测试才能优化物理
设计。
92
?数据库实施是指根据逻辑设计和物理设计的结
果, 在计算机上建立起实际的数据库结构, 装
入数据, 进行测试和试运行的过程 。
?数据库实施主要包括以下工作：
?建立实际数据库结构；
?装入数据；
?应用程序编码与调试；
?数据库试运行；
?整理文档 。
6.6 数据库实施
93
6.6.1 建立实际数据库结构
? DBMS提供的数据定义语言 （ DDL） 可以定义数据库结构 。
可使用第 3章所讲的 SQL定义语句中的 CREATE TABLE语
句定义所需的基本表, 使用 CREATE VIEW语句定义视
图 。
6.6.2 装入数据
? 装入数据又称为数据库加载 （ Loading）, 是数据库实
施阶段的主要工作 。 在数据库结构建立好之后, 就可
以向数据库中加载数据了 。
? 由于数据库的数据量一般都很大, 它们分散于一个企
业 （ 或组织 ） 中各个部门的数据文件, 报表或多种形
式的单据中, 它们存在着大量的重复, 并且其格式和
结构一般都不符合数据库的要求, 必须把这些数据收
集起来加以整理, 去掉冗余并转换成数据库所规定的
格式, 这样处理之后才能装入数据库 。 因此, 需要耗
费大量的人力, 物力, 是一种非常单调乏味而又意义
重大的工作 。
94
? 由于应用环境和数据来源的差异, 所以不可能存在普
遍通用的转换规则, 现有的 DBMS并不提供通用的数据
转换软件来完成这一工作 。
? 对于一般的小型系统, 装入数据量较少, 可以采用人
工方法来完成 。
? 首先将需要装入的数据从各个部门的数据文件中筛选出来, 转换成
符合数据库要求的数据格式,
? 然后输入到计算机中,
? 最后进行数据校验, 检查输入的数据是否有误 。
? 但是, 人工方法不仅效率低, 而且容易产生差错 。 对于数
据量较大的系统, 应该由计算机来完成这一工作 。 通常是
设计一个数据输入子系统, 其主要功能是从大量的原始数
据文件中筛选, 分类, 综合和转换数据库所需的数据, 把
它们加工成数据库所要求的结构形式, 最后装入数据库中,
同时还要采用多种检验技术检查输入数据的正确性 。
? 为了保证装入数据库中数据的正确无误, 必须高度重视数
据的校验工作 。 在输入子系统的设计中应该考虑多种数据
检验技术, 在数据转换过程中应使用不同的方法进行多次
检验, 确认正确后方可入库 。
95
?如果在数据库设计时, 原来的数据库系统仍在
使用, 则数据的转换工作是将原来老系统中的
数据转换成新系统中的数据结构 。 同时还要转
换原来的应用程序, 使之能在新系统下有效地
运行 。
?数据的转换, 分类和综合常常需要多次才能完
成, 因而输入子系统的设计和实施是很复杂的,
需要编写许多应用程序, 由于这一工作需要耗
费较多的时间, 为了保证数据能够及时入库,
应该在数据库物理设计的同时编制数据输入子
系统, 而不能等物理设计完成后才开始 。
96
6.6.3 应用程序编码与调试
? 数据库应用程序的设计属于一般的程序设计范畴, 但
数据库应用程序有自己的一些特点 。 例如, 大量使用
屏幕显示控制语句, 形式多样的输出报表, 重视数据
的有效性和完整性检查, 有灵活的交互功能 。
? 为了加快应用系统的开发速度, 一般选择第四代语言
开发环境, 利用自动生成技术和软件复用技术, 在程
序设计编写中往往采用工具 （ CASE） 软件来帮助编写
程序和文档, 如目前普遍使用的 PowerBuilder、
Delphi以及由北京航空航天大学研制的 863/CMIS支持
的数据库开发工具 OpenTools等 。
? 数据库结构建立好之后, 就可以开始编制与调试数据
库的应用程序, 这时由于数据入库尚未完成, 调试程
序时可以先使用模拟数据 。
97
6.6.4 数据库试运行
? 应用程序编写完成, 并有了一小部分数据装入后, 应
该按照系统支持的各种应用分别试验应用程序在数据
库上的操作情况, 这就是数据库的试运行阶段, 或者
称为联合调试阶段 。 在这一阶段要完成两方面的工作 。
(1) 功能测试 。 实际运行应用程序, 测试它们能否完成各种
预定的功能 。
(2) 性能测试 。 测量系统的性能指标, 分析系统是否符合设
计目标 。
? 系统的试运行对于系统设计的性能检验和评价是很重
要的, 因为有些参数的最佳值只有在试运行后才能找
到 。 如果测试的结果不符合设计目标, 则应返回到设
计阶段, 重新修改设计和编写程序, 有时甚至需要返
回到逻辑设计阶段, 调整逻辑结构 。
98
? 重新设计物理结构甚至逻辑结构, 会导致数据重新入
库 。 由于数据装入的工作量很大, 所以可分期分批的
组织数据装入, 先输入小批量数据做调试用, 待试运
行基本合格后, 再大批量输入数据, 逐步增加数据量,
逐步完成运行评价 。
? 数据库的实施和调试不是几天就能完成的, 需要有一
定的时间 。 在此期间由于系统还不稳定, 随时可能发
生硬件或软件故障, 加之数据库刚刚建立, 操作人员
对系统还不熟悉, 对其规律缺乏了解, 容易发生操作
错误, 这些故障和错误很可能破坏数据库中的数据,
这种破坏很可能在数据库中引起连锁反应, 破坏整个
数据库 。
? 因此必须做好数据库的转储和恢复工作, 要求设计人
员熟悉 DBMS的转储和恢复功能, 并根据调试方式和
特点首先加以实施, 尽量减少对数据库的破坏, 并简
化故障恢复 。
99
6.6.5 整理文档
?在程序的编码调试和试运行中，应该将发现的
问题和解决方法记录下来，将它们整理存档作
为资料，供以后正式运行和改进时参考。
?全部的调试工作完成之后，应该编写应用系统
的技术说明书和使用说明书，在正式运行时随
系统一起交给用户。
?完整的文件资料是应用系统的重要组成部分，
但这一点常被忽视。必须强调这一工作的重要
性，引起用户与设计人员的充分注意。
100
? 数据库试运行结果符合设计目标后, 数据库就投入正
式运行, 进入运行和维护阶段 。 数据库系统投入正式
运行, 标志着数据库应用开发工作的基本结束, 但并
不意味着设计过程己经结束 。
? 由于应用环境不断发生变化, 用户的需求和处理方法
不断发展, 数据库在运行过程中的存储结构也会不断
变化, 从而必须修改和扩充相应的应用程序 。
? 数据库运行和维护阶段的主要任务包括以下三项内容：
(1) 维护数据库的安全性与完整性；
(2) 监测并改善数据库性能；
(3) 重新组织和构造数据库 。
6.7 数据库运行和维护
101
6.7.1 维护数据库的安全性与完整性
? 按照设计阶段提供的安全规范和故障恢复规范, DBA要
经常检查系统的安全是否受到侵犯, 根据用户的实际
需要授予用户不同的操作权限 。
? 数据库在运行过程中, 由于应用环境发生变化, 对安
全性的要求可能发生变化, DBA要根据实际情况及时调
整相应的授权和密码, 以保证数据库的安全性 。
? 同样数据库的完整性约束条件也可能会随应用环境的
改变而改变, 这时 DBA也要对其进行调整, 以满足用户
的要求 。
? 另外, 为了确保系统在发生故障时, 能够及时地进行
恢复, DBA要针对不同的应用要求定制不同的转储计划,
定期对数据库和日志文件进行备份, 以使数据库在发
生故障后恢复到某种一致性状态, 保证数据库的完整
性 。
102
6.7.2 监测并改善数据库性能
?目前许多 DBMS产品都提供了监测系统性能参数
的工具, DBA可以利用系统提供的这些工具,
经常对数据库的存储空间状况及响应时间进行
分析评价；
?结合用户的反应情况确定改进措施；及时改正
运行中发现的错误；
?按用户的要求对数据库的现有功能进行适当的
扩充 。
?但要注意在增加新功能时应保证原有功能和性
能不受损害 。
103
6.7.3 重新组织和构造数据库
? 数据库建立后, 除了数据本身是动态变化以外, 随着
应用环境的变化, 数据库本身也必须变化以适应应用
要求 。
? 数据库运行一段时间后, 由于记录的不断增加, 删除
和修改, 会改变数据库的物理存储结构, 使数据库的
物理特性受到破坏, 从而降低数据库存储空间的利用
率和数据的存取效率, 使数据库的性能下降 。 因此,
需要对数据库进行重新组织, 即重新安排数据的存储
位置, 回收垃圾, 减少指针链, 改进数据库的响应时
间和空间利用率, 提高系统性能 。 这与操作系统对
,磁盘碎片, 的处理的概念相类似 。
? 数据库的重组只是使数据库的物理存储结构发生变化,
而数据库的逻辑结构不变, 所以根据数据库的三级模
式, 可以知道数据库重组对系统功能没有影响, 只是
为了提高系统的性能 。
104
? 数据库应用环境的变化可能导致数据库的逻辑结构发
生变化, 比如要增加新的实体, 增加某些实体的属性,
这样实体之间的联系发生了变化, 这样使原有的数据
库设计不能满足新的要求, 必须对原来的数据库重新
构造, 适当调整数据库的模式和内模式, 比如要增加
新的数据项, 增加或删除索引, 修改完整性约束条件
等 。
? DBMS一般都提供了重新组织和构造数据库的应用程序,
以帮助 DBA完成数据库的重组和重构工作 。
? 只要数据库系统在运行, 就需要不断地进行修改, 调
整和维护 。 一旦应用变化太大, 数据库重新组织也无
济于事, 这就表明数据库应用系统的生命周期结束,
应该建立新系统, 重新设计数据库 。 从头开始数据库
设计工作, 标志着一个新的数据库应用系统生命周期
的开始 。
105
小 结
? 本章介绍了数据库设计的六个阶段, 包括：系统需求
分析, 概念结构设计, 逻辑结构设计, 物理设计, 数
据库实施, 数据库运行与维护 。 对于每一阶段, 都分
别详细讨论了其相应的任务, 方法和步骤 。
? 需求分析是整个设计过程的基础, 需求分析做得不好,
可能会导致整个数据库设计返工重做 。
? 将需求分析所得到的用户需求抽象为信息结构即概念
模型的过程就是概念结构设计, 概念结构设计是整个
数据库设计的关键所在, 这一过程包括设计局部 E-R
图, 综合成初步 E-R图, E-R图的优化 。
106
小 结
? 将独立于 DBMS的概念模型转化为相应的数据模型, 这
是逻辑结构设计所要完成的任务 。 一般的逻辑设计分
为三步：初始关系模式设计, 关系模式规范化, 模式
的评价与改进 。
? 物理设计就是为给定的逻辑模型选取一个适合应用环
境的物理结构, 物理设计包括确定物理结构和评价物
理结构两步 。
? 根据逻辑设计和物理设计的结果, 在计算机上建立起
实际的数据库结构, 装入数据, 进行应用程序的设计,
并试运行整个数据库系统, 这是数据库实施阶段的任
务 。
? 数据库设计的最后阶段是数据库的运行与维护, 包括
维护数据库的安全性与完整性, 监测并改善数据库性
能, 必要时需要进行数据库的重新组织和构造 。
