曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
10
图 2.5 事件处理实体联系简图
本阶段设计出的ER 数据模型是联系现实世界和计算机世界的一个信息表示
桥梁，它不但用于数据库的后续设计(逻辑设计和物理设计)，而且也是与用户交
流和数据库移植的重要资料。
2.4 逻辑结构设计
数据库逻辑结构设计阶段的主要任务是将概念结构设计的结果(ER 模型)转
换为某个DBMS 所支持的数据模型(例如关系模型), 并对其进行规范化和优化。
设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型, 然后选择
最合适的DBMS。目前，关系数据库理论已经发展的十分成熟。大型关系数据库
管理系统如ORACLE9i，DB2，SYBASE，SQL SERVER2000 等在各行业内应用广泛，
这些系统具有管理方便、检索速度快、存取效率高、安全性性好、存储空间的
利用率高等优点，适合大规模数据的存储和处理。所以在逻辑结构设计阶段，
我们通常把ER 数据模型转换成关系模型。
2.4.1 ER 模型转换为关系模型
将ER 模型转换为关系模型实际上就是将实体、实体的属性和实体之间的联
系都转换为关系模式, 这种转换一般遵循如下原则:
(1) 一个实体型转换为一个关系模式。实体的属性就是关系的属性，实体的
码就是关系的码。
(2) 一个1: 1 联系可以转换为一个独立的关系模式, 也可以与任意一端对
应的关系模式合并。
(3) 一个1: n 联系可以转换为一个独立的关系模式, 也可以与n 端对应的
关系模式合并。如果转换为一个独立的关系模式, 则与该联系相连的各实体的
11
码以及联系本身的属性均转换为关系的属性, 而关系的码为n 端实体的码。
(4) 一个m: n 联系转换为一个关系模式。与该联系相连的各实体的码以及
联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
(5) 三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元
联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码
为各实体码的组合。
利用该转换原则将(图 2.4)所示的ER 模型转换为关系模式，同时定义主键和
外键：
** 对救援小组进行编号并转换
(1) 救援小组rg [小组编号，名称，任务概述]
** 对资源进行分类并编号并转换
(2) 资源类别rs [资源类别编号，资源类别名称]
** 对救援单位进行转换
(3) 救援单位ru [单位名，联系人，联系电话，移动电话，位置X，位置Y，
标志，备注] 说明：作为主键，单位名一定要写详细，如果需要就精确到部门。
标志：1-公司内部单位，2-协议救援单位，3-其他协助单位
** 救援单位和救援小组的关系
(4) 单位细节ug [细节编号，单位名，小组编号，备注] 说明：单位-小组联
系表。
** 人员的具体情况
(5) 通讯录al [ 人员ID 号，姓名，单位名，职务，办公电话，移动电话，
住宅电话，备注] 说明：人员-单位联系表。
** 小组的组成成员
(6) 小组成员gm [人员ID 号，小组编号，职别，角色，密码] ID 号即是PK，
也是FK；取自[通讯录表]，角色：1-管理员，0-普通用户。
** 资源的具体描述
(7) 资源res [资源编号，资源名，规格型号，计量单位，用途，资源类别
编号] 说明：资源编号由系统自动生成。
** 各个单位所拥有的资源
(8) 资源分配ra [单位名，资源编号，可用数量，已派遣数量，备注] 单位
名，资源编号既是PK，又是FK。
注意：下划线表示[主键]，曲线表示[外键]，粗下划线表示[既是主键又是外
键]。一般而言，一个实体不能既无主键又无外键。在ER 图中, 处于叶子部位
12
的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键
(因为它有父亲)。主键与外键的设计，在全局数据库的设计中，占有重要地位。
因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。
同理也可以将(图 2.5)示的ER 模型转换为关系模式，这里不再赘述。
2.4.2 关系规范化与模式优化
关系规范化理论(范式理论)的目的就是要减少数据冗余、避免插入异常和删
除异常、保证数据完整性和一致性。将ER 模型转换成关系模型后，需要利用关
系规范化理论对关系模式进行初步优化，确定关系模式的等级，必要的情况下
对其进行合并或分解。就数据库设计而言，基本表及其字段之间的关系, 应尽
量满足第三范式。因此，在数据库设计中，为了更好地应用三个范式，就必须
通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：
第一范式：1NF 是对属性的原子性约束，要求属性具有原子性，不可再分解；
第二范式：2NF 是对记录的惟一性约束，要求记录有惟一标识，即实体的惟
一性；
第三范式：3NF 是对字段冗余性的约束，即任何字段不能由其他字段派生出
来，它要求字段没有冗余。
例如，我们利用规范化理论考察关系模式R1、R2、R3，就会发现它们都属于
第三范式。这是因为我们在概念设计阶段就是遵守的第三范式规则。
R1=救援单位[单位名，联系人，联系电话，位置X，位置Y，标志，备注]
R2=资源[资源编号，资源名，规格型号，计量单位，用途，资源类别]
R3=资源分配[单位名，资源编号，可用数量，已派遣数量，备注]
上文提到，基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足
第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，
常常需要降低范式标准，适当增加冗余，达到以空间换时间的目的。因此，在
保证关系模式满足第三范式之后，仍然需要对关系模式进行进一步优化。
例如，对于关系模式R3=资源分配[单位名，资源编号，可用数量，已派遣数
量，备注]，根据系统设计需要，我们在关系表中增加一列”剩余数量”(剩余数量
=可用数量－已派遣数量)。这样资源分配表(表 2.1)就不符合第三范式了，因为”
剩余数量”可以由”可用数量”减去”已派遣数量”得到，说明”剩余数量”是冗余字
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
民用机场应急救援管理系统关键技术研究(4)
