2009年 11月 10日Designed by Tao Hongcai 1
Principle,Application and
Design of Database
西南交通大学
计算机与通信工程学院
数据库原理与应用设计
2009年 11月 10日Designed by Tao Hongcai 2
二, 课程目的
◆ 掌握数据库管理系统的基本原理；
陶宏才主编, 数据库原理及设计,
清华大学出版社,2004.1
◆ 作为系统管理员应用、操作和管理数据库管理系统；
◆ 设计开发数据库应用系统。
一, 教材
2009年 11月 10日Designed by Tao Hongcai 3
◆ 数据库管理系统基本原理
◆ DBMS的基本原理在 SQL Server中的体现；
◆ 数据库应用系统的设计与开发 。
三, 课程内容
（ 1）基本概念：数据库、数据库管理系统、数据库
系统、视图、数据模型及抽象等
（ 2）基本内容：关系数据库与理论,SQL语言、数
据库安全性、数据库完整性、数据库并发控制、数据库故
障恢复等
2009年 11月 10日Designed by Tao Hongcai 4
◆ 首先讲解数据库系统的整体框架，了解其各部分组成
及地位作用、所涉及的概念及内容；重视英文术语；
◆ 根据整体框架，分别讲授各个组成部分；
◆ 各个部分的讲解，基本上先讲其基本概念及理论，紧
接着将以 SQL Server DBMS为例，对应讲解该理论在实际
的 DBMS中的运用及体现；
四, 讲授方式
◆ 利用上机实验条件和课外课时，实际上机实习，加深
理论，掌握有代表性的 SQL Server DBMS；
◆ 为加深理解、活跃气氛，适当进行课堂提问并视情况
给予成绩奖励加分计入期末总评成绩 。
2009年 11月 10日Designed by Tao Hongcai 5
◆ 平时成绩占 30％
◆ 期末考试成绩占 70％
◆ 课堂 正确答问奖励加分（加分之和 ≤10分）
五, 总评成绩分布
（ 1）作业占 15％
（ 2）考勤占 15％（考勤方法）
（ 3）上机
以满分（ 100分）为上限。
内容以课堂讲授及教材为准。
2009年 11月 10日Designed by Tao Hongcai 6
六, 主要参考书
1 Raghu Ramakrishnan,Johannes Gehrke,
Database Management Systems(2nd Edition)[M],
清华大学出版社,McGraw-Hill,2000.3
2 李建中,王珊编著, 数据库系统原理 [M],电子工业出版社,1999.4
3 王珊,陈红编著, 数据库系统原理教程 [M],
清华大学出版社,1998.7
4 刘云生等, 数据库系统概论（第二版） [M],
华中理工大学出版社,1998.4
5 张龙祥等编著, 数据库原理与设计 [M],
人民邮电出版社,2002.7
6 王能斌, 数据库系统 [M],电子工业出版社,1995.10
2009年 11月 10日Designed by Tao Hongcai 7
第一章 数据库系统概述
学习目的和要求
◆ 数据库管理系统出现的背景
◆ 数据库管理系统基本功能、抽象层次
◆ 数据库系统总体结构
◆ 理解数据库原理、应用及设计三部分间的关系
◆ 数据库系统中的术语与基本概念
◆ 数据库技术发展
2009年 11月 10日Designed by Tao Hongcai 8
1.1 数据库管理系统及其总体概述
从最原始的观点出发来看如下问题,
一,从利用文件系统来开发管理软件和网络
共享观点来看待数据库管理系统的出现
1.利用文件系统的应用软件开发过程
★ 开发任务
★ 开发工具及环境
简单学生管理系统，有学生注册、选课、学籍、和成绩等模块。
C/C++,Windows操作系统的文件系统。
★ 开发任务分析及设计
注意：要完全抛开现成的数据库及工具。利用文件系统来模
拟数据库。
2009年 11月 10日Designed by Tao Hongcai 9
★ 数据结构及数据文件
struct Student
{
int nStudNo;
char szStudName[20];
char cStudSex;
int nStudAge;
char szDept[30];
};
struct Enrolled
{
int nStudNo;
int nWhichTerm;
char cEnrolled;
char szMem[30];
};
struct Course
{
int nCourseNo;
char szCourseName[20];
char szDept[30];
};
struct Grade
{
int nStudNo;
int nCourseNo;
int nGrade;
};
2009年 11月 10日Designed by Tao Hongcai 10
★ 数据管理操作
2.文件系统的缺陷
※ 大容量数据存储，大数据量如 500GB
最基本的数据操作：增加、删除、修改和查询，简称：增删
改查询。业务操作或功能由这四个基本操作组合而来。
1 KB (kilobyte) = 1024 Bytes;
1 MB (megabyte) = 1024 KBs;
1 GB (gigabyte) = 1024 MBs;
1 TB (terabyte) = 1024 GBs;
1 PB (petabyte) = 1024 TBs.
2009年 11月 10日Designed by Tao Hongcai 11
问题：
并发访问下避免数据不一致；系统故障下如何保证数据一致。
※ 安全性
※ 数据一致性
不同用户的授权问题等。
（ 1）内存不够；
（ 2） 32位计算机直接访问的地址为 4GB；
在 32位机上 Linux,Windows NT,Windows 2000等操作系统
不允许硬盘上单个文件超过 232=4GB大小。
（ 3）大数据量下的查询速度。
※ 多用户并发访问
2009年 11月 10日Designed by Tao Hongcai 12
二,从文件系统缺陷及管理特点来看数据库管
理系统应具有的基本功能
◆ 数据独立性 (Data Independence)：指应用程序
独立于数据的表示（逻辑）与存储（物理），通过将数据
的定义与存储从程序中独立出来实现。
◆ 高效数据访问 (Efficient Data Access),DBMS
利用许多复杂的技术来高效存储和检索数据，这对存于外
部存储设备上的数据相当重要。
◆ 数据完整性与安全性 (Data Integrity and
Security),DBMS通过数据的完整性约束或限制 (Integrity
Constraints)、访问控制来完成。
通过将数据存储于 DBMS中而不是文件系统中，可以
以一种强壮、高效的方式进行数据的管理，其优点为,
2009年 11月 10日Designed by Tao Hongcai 13
◆ 数据管理 (Data Administration)：数据的集中管
理可减少冗余。
◆ 并发访问与故障恢复 (Concurrent Access and
Crash Recovery)：并发访问可使用户感到好象只有他一
个人在使用某个数据。
◆ 缩短应用开发时间 (Reduced Application
Development Time)：有许多重要的数据管理及其相关的
任务由 DBMS来完成，而非 App.
※ 注：不使用 DBMS的环境
（ 1）苛刻的实时 (Real-Time)环境；
（ 2）操作少，代码要求精炼；
（ 3）操纵的数据不被查询语言支持，如文档数据。
2009年 11月 10日Designed by Tao Hongcai 14
数据库管理系统应具有的基本功能
◆ 数据独立性
◆ 并发控制
◆ 安全性
◆ 故障恢复
◆ 完整性
2009年 11月 10日Designed by Tao Hongcai 15
三,从应用系统开发的角度来看待数据库的抽
象层次
外模式 1 ……
现实系统
概念模式
内模式
物理抽象
概念抽象
视图抽象
数据库管理系统抽象层次
外模式 2 外模式 n
磁盘
2009年 11月 10日Designed by Tao Hongcai 16
四, 又从数据库的抽象层次来进行数据库应用
管理系统的设计与开发，及其设计工具
五, 从对数据库管理系统的要求和操作来看待
SQL数据库语言
■ 抽象层次体现的正是数据库设计与开发的过程
■ 各阶段中使用不同的设计工具
■ 数据定义
■ 数据操作
■ 系统管理
2009年 11月 10日Designed by Tao Hongcai 17
六, 数据库原理、应用与设计之间的联系
C G I / I S A P I
OD BC / J D BC / OLE D B
概念模式
外模式 1 外模式 n 外模式 2
现实系统
关系 数据库管理系统 R D BM S
利用 S Q L D D L 将
关系模型存入数据库
SQ L 的嵌入式 使用
C / C + +, PB, D el phi,
Jav a 应用程序
数据库应用部分
用户
SQ L
的 交
互式
使用
…
数
据
库
原
理
部
分
DB
数
据
库
安
全
并
发
控
制
故
障
恢
复
完
整
性
限
制
数据库系统总体结构图
数
据
库
设
计
部
分
SQ L 语句
SQ L 定义语句
C / S 模式
浏览器
WEB 服务器
B / S 模式
H T T P
SQ L
语句
C GI / A SP / J SP 程序
通过以上介绍应了解：数据库管理系统的原理与数据库应用系统的设
计与开发的联系是紧密相关的。
2009年 11月 10日Designed by Tao Hongcai 18
七, 从实际应用需要来看待数据库技术的发展
▲ 文件系统
▲ 第一代数据库系统（层次与网状数据库系统）
代表,IMS,DBTG报告
应用程序 n
应用程序 2
文件 n
文件 2
应用程序 1 文件 1
存取
方法 … …
2009年 11月 10日Designed by Tao Hongcai 19
▲ 第二代数据库系统 （关系数据库系统 RDBMS）
▲ 数据仓库 （ Data Warehousing）
代表,System R,Ingres,Oracle,DB2(Informix)、
Sybase,MS SQL Server
▲ OLTP (Online Transaction Process)
▲ 数据挖掘 （ Data Mining）
▲ 并行与分布式数据库
▲ Internet 数据库
▲ 面向对象数据库 OODBMS,……
▲ OLAP (Online Analysis Process)
2009年 11月 10日Designed by Tao Hongcai 20
1.2 数据库系统中的基本概念
一,数据、数据库、数据库管理系统和
数据库系统
数据 (Data) 是描述现实世界中各种具体事物或抽象
概念的可存贮并具有明确意义的信息。
数据库 (Database,DB) 是相互关联的数据集合。
数据库管理系统 (Database Management System,
DBMS) 是一个通用的软件系统，由一组计算机程序构成。
它能对数据库进行有效的管理，包括存储管理、安全性管
理、完整性管理等；同时，它也为用户提供了一个软件环
境，使其能够方便快速地创建、维护、检索、存取和处理
数据库中的信息。
2009年 11月 10日Designed by Tao Hongcai 21
数据库系统 (Database System,DBS) 由数据库和
数据库操作
D B A 或用户
应用程序
数据库管理系统 D B M S
数据库系统环境示意图
DB
数据库操作
数据库管理系统构成，更广义的构成则为,DB+DBMS+
数据库管理员 （ DataBase Administration,DBA） +应用程
序 +用户”。
2009年 11月 10日Designed by Tao Hongcai 22
数据字典 (Data Dictionary,DD) 是数据库系统中的
数据库操作 (Database Operation) 在数据库应用中，
最常见的数据库操作有：增加、删除、修改和查询。
视图 (View) 对同一数据库的每一种理解即被称为该
数据库的一个视图。
二, 视图
数据库的分层视图
一个特殊文件，用于存储数据库的一些说明信息，这些说
明信息称为 元数据 (Meta Data)。
大型数据库与微机数据库区别
2009年 11月 10日Designed by Tao Hongcai 23
应用程序员
最终用户
D BA
系统程序员
物理
数据
物理视图
内模式
内部视图
概念模式
概念视图
子模式 1
外部视图
子模式 2 子模式 n
?
用户图表 1
I / O 视图
? 用户图表 2 用户图表 n
数据库分层视图
组织
2009年 11月 10日Designed by Tao Hongcai 24
输入输出数据视图 即终端用户所见到的输入输出数
外部视图 (External View) 局部数据库逻辑结构称为
外部视图。这种视图在数据库设计时通常以图形的形式
（如 E-R图）表示，有的又叫视图或用户视图。
概念视图 (Conceptual View) 整个数据库系统的全局
逻辑结构。这种逻辑结构称为概念模型，它不包含任何数
据库的实现细节，如：何种 DBMS、文件组织、存取方法
等。这种逻辑结构的形式化描述称为概念视图。在数据库
设计时，概念视图通常也以 E-R图表示。
据结构描述，也就是最终用户所见到的数据库的样子。
2009年 11月 10日Designed by Tao Hongcai 25
内部视图 (Internal View)或存储视图 特定的 DBMS所
物理视图 (Physical View) 数据库在存储设备上的物
理组织称为物理模型，其描述称为物理视图。它包含了所
使用设备特征、物理记录或块的组成、寻址技术和压缩存
储技术等的说明。
处理的数据库的内部结构称为内部模型，其形式化描述称
为内部视图或存储视图，它将数据库表示为”内部记录”
或”存储记录”的集合。存储记录仍然是逻辑性的，它不
存储设备上的物理记录或物理块，也不涉及任何具体设备
限制，如：柱面或磁道的大小等，所以存储视图还不是最
底层的物理层。存储视图还指明存储记录的物理顺序、以
及它们如何彼此关联。存储视图的语言形式定义称为内部
模式。
2009年 11月 10日Designed by Tao Hongcai 26
三, 数据抽象、数据模型与数据模式之关系
数据抽象 (Data Abstraction) 即是将数据抽象化,
逻辑化, 使用户不必了解数据库文件的物理存储结构, 存
储位置和存取方法等细节, 即可存取数据库 。 在数据库系
统中, 有三种级别的数据抽象, 即：视图级抽象, 概念级
抽象和物理级抽象 。
数据模型 (Data Model) 即是对数据进行抽象化表示
的工具，主要使用逻辑概念（如对象、对象属性、对象联
系等）来表示数据。
由于抽象级别的存在, 数据模型也存在相应的级别 。
如：概念数据模型, 逻辑数据模型, 物理数据模型等 。 对
于抽象级别高的概念数据模型我们叫它 语义 (Semantic)数
据模型, 如 ER模型 。
数据模式 (Data Schema) 根据数据模型来描述数据，
亦即是描述数据的模板。
2009年 11月 10日Designed by Tao Hongcai 27
四, 数据模型
通俗来讲，数据模型就是对现实世界的模拟、描述
或表示。数据模型应满足的三个要求,
1.数据模型的三要素
（ 1）数据结构
（ 1）比较真实地描述现实世界；
（ 2）易为用户所理解；
（ 3）易于在计算机上实现。
用于描述系统的静态特性 。 数据结构不仅要描述数据
本身, 还要描述数据之间的联系 。
2009年 11月 10日Designed by Tao Hongcai 28
（ 2）数据操作
用于描述系统的动态特性。包括操作及有关的操作规
则。数据库的主要操作有：插入、删除、修改和查询。
2.数据模型应用现状
（ 3）数据的约束条件
是一组完整性规则的集合 。 完整性规则是数据模型中
数据及其联系所具有的约束规则, 用来限定数据库状态以
及状态的变化, 以保证数据的正确 。
为何要使用多种数据模型？
(1) 现实管理系统的用户与计算机管理系统的设计人
员之间的专业差异。
(2) 用户理解与计算机实现的矛盾。
2009年 11月 10日Designed by Tao Hongcai 29
3.传统数据模型回顾
（ 1） 层次数据模型 (Hierarchical Data Model)
HDM是数据库系统中最早出现的数据模型。 60年代
后期,IBM开发出 IMS (Information Management System)
DBMS，是层次数据模型的基础。
用树形结构表示各类实体以及实体之间的联系。
现实世界中许多实体之间的联系就呈现出一种很自
然的层次关系，如：行政机构、家庭关系等。层次模型是
以记录型为结点的有向树。
2009年 11月 10日Designed by Tao Hongcai 30
按树的定义，层次模型有以下两个限制：
☆ 只有一个结点没有双亲结点，即根结点；
☆ 根以外的其他结点有且只有一个双亲结点。
因此，层次数据库系统只能处理一对多的实体关系。
学生
学院
学生 系
教师
学生宿舍
2009年 11月 10日Designed by Tao Hongcai 31
层次模型中，每个结点表示一个记录类型，结点之间
的连线表示记录类型间的联系。这种联系只能是父子联系。
层次模型的另一个最基本的特点是：任何一个给定的
的记录值只有按其路径查看时，才能显出它的全部意义，
没有一个子女记录值能够脱离双亲记录值而独立存在。
（ 2） 网状数据模型 (Net Data Model)
用层次模型表示非树型结构很不直接，网状模型则可
克服这一弊病。
网状数据模型的典型代表是 DBTG系统，亦称
CODASYL系统。是由美国数据库系统语言协会
CODASYL (Conference On Data System Language)下
属的 DBTG (DataBase Task Group)于 60年代末 70年代初
提出的一个系统方案，形成 DBTG报告。
2009年 11月 10日Designed by Tao Hongcai 32
网状模型比层次模型更具普遍性。
它去掉了层次模型的两个限制，允许结点有多个双亲
结点。可比层次模型更直接地描述现实世界。
学院
学生 系
教师
学生宿舍
学生
课程
2009年 11月 10日Designed by Tao Hongcai 33
五, 数据库语言,SQL语言
数据定义子语言 (Data Definition Language,DDL)
用来定义数据库模式 。
数据操纵子语言 (Data Manipulation Language,
DML) 用来表示用户对数据库的操作请求。由于数据库语
言其主要的功能是查询数据库中的信息，故经常称之为 数
据查询语言 。
SQL(Structured Query Language,结构化查询语言 )
是一种集数据定义和数据操纵子语言为一体的, 标准化
（ 80年代后期 ） 的, 关系型数据库语言 。 目前的标准化版
本为 SQL-92, 被 ANSI(American National Standards
Institute),ISO(International Standards Organization)采
纳 。
2009年 11月 10日Designed by Tao Hongcai 34
SQL语言的第一个版本是由 IBM公司 SAN JOSE实验
室为 SYSTEM R关系数据库管理系统设计的。
SQL语言既可以作为交互式 （ Interactive） 数据库语
言使用，也可以嵌入 （ Embedded） 到程序设计语言中作
为其子语言使用，这时前者称为宿主语言 (Host
Language)，如,C/C++语言,PowerBuilder,Delphi等。
SQL标准有,SQL-86,SQL-89,SQL-92,SQL：
1999。
2009年 11月 10日Designed by Tao Hongcai 35
第二章 实体联系数据模型
学习目的和要求
◆ 数据模型的来源及评价
◆ 数据模型层次性及内容（静态结构与完整性约束）
◆ 实体联系数据模型 ERM中的基本概念
◆ 扩展 ERM中的基本概念
2009年 11月 10日Designed by Tao Hongcai 36
2.1 数据模型综述
回答如下问题,
1,为什么需要数据模型？
4,数据模型为什么有层次性？
3,如何评价数据模型？
2,如何描述数据模型，即数据模型含有哪些内容？
5,数据模型的未来？
6,实体联系数据模型的地位与作用？
2009年 11月 10日Designed by Tao Hongcai 37
一,为什么需要数据模型？
由于数据的定义与操作从应用程序中剥离出来, 交由
DBMS来定义和管理 。 于是 DBMS需要采用某种数据结构来
定义, 存储所要管理的数据 。 这种狭义的数据结构类似于
DBMS的数据模型 。
二,数据模型含有哪些内容？
1,数据的静态结构
2,数据的动态操作 （ 增删改查询 ）
3,数据的完整性约束
综合说来, 应描述数据, 数据乊间联系, 数据语义及
完整性限制 。
2009年 11月 10日Designed by Tao Hongcai 38
三,如何评价数据模型？
四,数据模型为什么有层次性？
1,真实地描述现实系统
2,易于为一般用户所理解
3,易于计算机实现
1,从与数据抽象的关系看
2,从评价指标 （ 第二, 三项 ） 的互斥性看
五,数据模型的未来？
1,设计, 开发与实现的一统数据模型 。
2,层次共存, 但各种用户只用一种高级模型, 而其它
工作由计算机及其编译环境负责 （ 类似高级语言编译器 ） 。
2009年 11月 10日Designed by Tao Hongcai 39
六,实体联系数据模型的地位与作用？
1.传统三种数据模型的特点
2.三种数据模型的不足
3.实体联系模型 (Entity Relationship Model,ERM)是用得
最多且最成熟的语义数据模型 。 属于数据库应用系统设计
的内容 。
能较好地满足第一和第三项评价要求；
不易被业务用户理解 。 这是提出语义数据模型
(Semantic Data Model)的基础 。
4.从数据库应用系统设计角度看, ER模型主要用于 DB
概念设计, 是 DB概念设计较常用的设计工具 。
2009年 11月 10日Designed by Tao Hongcai 40
2.2 数据库设计综述
对照数据库抽象层次，数据库设计按如下步骤进行：
一, 需求分析 （ Requirements Analysis）
☆ 任务,收集的信息变成数据高级描述及对数据的约
束限制。
☆ 工具,ER图。
☆ 结果,概念 DB设计。
☆ 对应,现实系统到外模式的视图抽象，以及外模式
到概念模式的概念抽象。
二, 概念数据库设计 (Conceptual DB Design)
☆ 了解,Data,App.,Operations,Performance.
☆ 方法,调查、讨论、座谈、收集,DFD等。
☆ 对应,抽象层次的现实系统描述。
2009年 11月 10日Designed by Tao Hongcai 41
三, 逻辑数据库设计 （ Logical DB Design）
☆ 任务,选择一 RDBMS，将概念 DB设计变成 RDM对应
的模式 (Schema)。
☆ 结果,为概念模式或逻辑模式。
☆ 对应,数据库抽象层次的概念抽象。
四, 模式优化 （ Schema Refinement）
☆ 任务,解决潜在问题，利用规范化 (Normalization)理
论迚行优化。
☆ 对应,数据库抽象层次的概念抽象。
2009年 11月 10日Designed by Tao Hongcai 42
五, 物理数据库设计 （ Physical DB Design）
☆ 考虑,负载、性能要求。
六, 安全设计 （ Security Design）
☆ 任务,哪些用户 (组 )可 /不可访问哪些数据。
需说明的几点问题：
☆ 对应,数据库抽象层次的物理抽象。
1,以上各步可能需不断重复, 直到满意为止；
2.这里忽略了 DB设计的实现, 即运行于 DBMS乊上的应
用层；
3.数据抽象的过程实际上是一个数据建模的过程 。
2009年 11月 10日Designed by Tao Hongcai 43
2.3 实体联系数据模型 ERM
一, Entities,Attributes,and Entity Sets
1.实体 (Entity)
2.实体型 (Entity Set)
注意,可以是具体的、也可以是抽象的。
概念,一个现实世界中有别于其它对象的对象。
示例,某某学生、某某老师、某门课程
概念,同类实体的集合。在不混淆的情冴下，简称实体。
示例,学生、教师、课程
(1) 正在从事建模或数据抽象工作，即是将现实世界（问题空间）
中的事物转换成计算机世界（解空间）中的对象。
提示：
(2) 既然是建模，就必然要考虑如何描述问题空间中的事物。
2009年 11月 10日Designed by Tao Hongcai 44
3.属性 (Attribute)
分类 (按结构 ),简单属性 (不可再分 )、复合属性和子属性。
域 (Domain),属性的取值范围。
概念,实体的特征或性质，即实体用属性描述。
示例,学生的学号、姓名、生日、年龄、性别、住址等；
课程的课程号、课程名、学时、学分、开课学院等。
示例,复合 — 姓名 (现用名、曾用名、英文名 — 子属性 )；
住址 (省、市、区、街道、门牌号、邮政编码 — 子属性 )。
分类 (按取值 ),单值、多值、导出和空值 (NULL)等属性。
示例,多值 — 学位值 (学士、硕士、博士 )；导出 — 生日导
出年龄。
注意,实体用属性描述，实体型中的所有实体具有相同的
属性。
2009年 11月 10日Designed by Tao Hongcai 45
4.键 (Key)
分类 (按属性个数 ),简单键、复合键。
候选键 (Candidate Key),最小属性集合 的键。
概念,具有唯一标识特性的一个或一组属性，用于唯一标
识集合中的实体。
示例,学生的学号；课程的课程号；选课的学号及课程号
示例,学生的指纹、眼波、学号等。
注：
ER模型可图示。实体型用长方形；属性用椭圆；主键
用下划线。
主键 (Primary Key),当存在多个候选键时，需选定一个作为
实体的主键。是描述实体的唯一标识。
2009年 11月 10日Designed by Tao Hongcai 46
示例：
概念,二个或多个实体间的关联 (Association)。
示例,选课是学生与课程乊间的联系；门市零售可以是客
户、售货员与商品乊间的联系。
?§ o? D? ??
?§ o?
D? ±e 3? éú ?ê ??
?? 1á
?§ éú
?ò í￥ ×? ?·
?? ó? ?? ?D ?? D? ?? ó￠ ?? D? ??
óê ±à 3? êD ?? ?? o?
?? μà
二, Relationships and Relationship Sets
1.联系 (Relationship)
2009年 11月 10日Designed by Tao Hongcai 47
联系的描述属性,联系也可有描述属性 (Description
Attribute)，用于记彔联系的信息而非实体的信息。
联系的识别,联系由参与的实体唯一确定。
概念,相似的一组联系。联系型的实例 (Instance)是联系的
集合。在不混淆的情冴下，简称联系。
示例,选课的成绩和修课学期；零售的商品数量。
示例,选课 (学号、课程号 )；零售 (售货员号、客户号、商
品条码、日期 )。
联系型的阶,一个联系型所关联的实体型的数量。阶为 n
的联系型称为 n元联系型。
示例,选课 (二元联系 )；零售 (三元联系 )。
注,联系型用菱形图示。
2.联系型 (Relationship Set)
2009年 11月 10日Designed by Tao Hongcai 48
示例：
(1)二元 (两个实体型乊间的 )联系 (Binary Relationship)；
(2)三元 (两个以上实体型乊间的 )联系 (Ternary Relationship)；
(3)两个实体型乊间可能有多个不同的联系；
3.联系型 存在的各种情况
成绩
零售
商品
学期
数量 选课
学生
课程
售货员 客户
日期
2009年 11月 10日Designed by Tao Hongcai 49
示例：
管理 工作
员工
部门
(4)有时一个联系型所关联的是同一个实体型中的两个实体。
领导
员工
装配
零件
2009年 11月 10日Designed by Tao Hongcai 50
三, Integrity Constraints of ERM
定义,设联系型 R关联实体型 A和 B。如果对应 A中的每个
实体,B中有且仅有一个实体与乊关联，则称 R是 一对一联系型,
简记作 1, 1联系。如果对应 A中的每个实体,B中有 n个实体
(n≥0) 与乊关联，则称 R是 一对多联系型,简记作 1, N联系。
如果对应 A中的每个实体,B中有 n个实体 (n≥0) 与乊关联，如
果对应 B中的每个实体,A中有 m个实体 (m≥0) 与乊关联，则称
R是 多对多联系型,简记作 M, N联系。
1.联系型分类
（ 1） 一对一联系 （ one-to-one,1:1）
（ 2） 一对多联系 （ one-to-many,1:N）
（ 3） 多对多联系 （ many-to-many,M:N）
提示,用这种方式（约束）来说明现实系统中的某种规定
2009年 11月 10日Designed by Tao Hongcai 51
示例：
M
管理
员工 部门
任期
部门号 姓名 生日 部门名 员工号 经费
工作
起始期
N
1
(1)一个部门只有一个经理，而一个经理只能管理一个部门，
则该管理联系为 1:1联系。
如果规定：
(2)一个员工可以是多个部门的经理，而一个部门最多只能
有一个经理，则该管理联系为 1:N联系。
(3)一个员工可以在多个部门工作，而一个部门有多个员工，
则该工作联系为 M:N联系。
2009年 11月 10日Designed by Tao Hongcai 52
2.键约束或限制 (Key Constraints)
说明,前面所述联系型中所关联实体间的三种对应关系，
实际上指的是一些约束，分别为：一对一约束、一对多约束和
多对多约束。
概念,键约束指的是，如果在一个联系 R的实例中，其中
一个关联的实体 A最多只能出现在一个联系实例中。与, 实体
对应约束, 同义。
注意,只有 1:1约束和 1:N约束才存在键约束。
图示,键约束可用 箭头 表示（对于 1:N约束，箭头应标在
1:n的 n方,表明给定一个该实体即可唯一确定其间的联系）。
A B A B R
1, 1 中的键 约束 1, N 中的键 约束
1 N 1 1
R
2009年 11月 10日Designed by Tao Hongcai 53
示例：
管理
员工 部门
任期
部门号 姓名 生日 部门名 员工号 经费
工作
起始期
1
N
1
1
(1)对于图中的 1:1管理联系，说明：给定一个部门实体，即
可唯一地确定一个管理联系的实例。这时，管理联系可用部门
的键（部门号）唯一确定，这也是使用, 键约束, 的原因。
(2)对于图中的 1:N工作联系，说明：给定一个员工实体，即
可唯一地确定一个工作联系的实例。这时，工作联系可用员工
的键（员工号）唯一确定。
2009年 11月 10日Designed by Tao Hongcai 54
键约束的好处,前面曾经指出，联系由其所关联实体唯一
确定。但对存在键约束的联系，只需用一个关联的实体即可唯
一地确定该联系。这也是为什么叫, 实体对应约束, 的原因。
扩展,多个实体间的联系也存在有键约束的情冴。
示例,每个员工最多在一个部门工作，并且在一个地点。
员工 部门
起始期
部门号 姓名 生日 部门名 员工号 经费
工作 于
容量
地点
地址
2009年 11月 10日Designed by Tao Hongcai 55
3.参与约束 (Participation Constraints)
概念,是实体与联系乊间的约束，即实体如何参与到联系
中。与, 实体关联约束, 同义。
分类,完全参与 （ Total Participation） 和部分参与 （ Partial
Participation） 。完全参与即, 全域实体关联约束,,部分参与
即, 部分关联约束, 。
图示,用粗线表示完全参与。
2009年 11月 10日Designed by Tao Hongcai 56
示例：
(1)管理中的员工实体集的参与为 部分参与,因为不是每个
员工都会去管理一个部门。而部门为 完全参与,因为每个部门
都会被某个员工管理。
(2)工作中的员工与部门均为 完全参与,因为每个员工都必
须在某个部门工作，而每个部门都会有员工在其中工作。
管理
员工 部门
任期
部门号 姓名 生日 部门名 员工号 经费
工作
起始期
N
1
1 1
2009年 11月 10日Designed by Tao Hongcai 57
四,联系型属性的移动处理
在某些情况下 (1:1和 1:N联系型的属性 )，可以将联系型的
属性移动到所关联的某个实体型中，作为其属性。具体移动方
法如下：
（ 1） 如果一个联系型 R是关联实体型 A和 B的 1:1联系型，则
R的属性既可以移动到 A，也可以移动到 B；
（ 2） 如果是 1:N联系型，则若移动 R的属性，最好移到与 N
对应的实体型 B，如果把 R的属性移动到 A，这些属性将成为 A
的多值属性，为以后的处理带来麻烦。
示例,如果员工与部门间的管理联系为 1:1的，则可将管理
的, 任期, 属性移到员工实体或部门实体中。
示例,如果员工与部门间的管理联系为 1:N的（即一个员工
可以是多个部门的经理），则可将管理的, 任期, 属性移到部
门实体中。 试想：如果移到员工实体中结果会如何？
2009年 11月 10日Designed by Tao Hongcai 58
注意：
（ 1） 如果是 M:N联系型，则其属性最好不要移动到实体型
中，以免产生多值属性。
（ 2） 一个联系型的属性是否作为相关实体型的属性以及作
为哪一个实体型的属性，需要由数据库设计者决定。
五,弱实体 (Weak Entities)
前面所涉及的实体型，均基于这种假设：总有一个属性是
键。然而，实际情况中，并不总是如此。
概念,没有键属性的实体。
识别实体型 (Identifying Owner)与 识别联系 (Identifying
Relationship), 由于弱实体型的不同实体的属性值可能完全相
同，难以区别。为此，弱实体型需要与一般的实体型相关联。
假如联系型 R关联弱实体型 A和一般实体型 B，弱实体型 A的不
同实体可以通过与 B的有关实体相结合来加以区别，则 B称为弱
实体型 A的 识别实体型, R称为弱实体型 A的 识别联系 。
2009年 11月 10日Designed by Tao Hongcai 59
示例：
保险 员工 子女
保费 子女名 姓名 生日 年龄 员工号
(1)识别实体与弱实体必须参与的是 1:n联系，该联系即为该
弱实体的识别联系。
(2)弱实体型必须完全参与识别联系。
限制或约束：
部分键 （ Partial Key）, 弱实体型必须具有一个或多个属性，
使得这些属性可以与识别实体型的键结合形成相应弱实体型的
键。这样的弱实体属性称为弱实体型的 部分键 。
图示,弱实体和识别联系用粗线条，部分键加虚下划线 。
2009年 11月 10日Designed by Tao Hongcai 60
2.4 扩展实体联系数据模型 EERM
一, 类层次 （ Class Hierarchies）
1.子类 (Subclass)
概念,有时，需要将实体型中的实体分成子类。分类后体
现为一种层次关系，最上层为 超类 （ Super class）,下层即为
子类。
示例,小时工和合同工是员工的子类。
表示,小时工 ISA（ is a）员工、合同工 ISA员工。 ISA为这
种类层次的联系。
扩展 ERM（ Extended ERM） 是对 ER模型的扩展，它包括 ERM
的所有概念，同时引出扩展的概念。
子类属性,除可继承 超类 属性外还可有自己独特的属性。
2009年 11月 10日Designed by Tao Hongcai 61
图示：
注意,实体有时还可按其他标准 （ Criterion） 分类，可根
据管理的需要来定。
示例,员工分资深员工 （ Senior Employee） 与非资深
（ Junior） 员工。
员工
合同工
小时数
姓名 生日
合同号
员工号
计时工资
小时工
IS A
2009年 11月 10日Designed by Tao Hongcai 62
2.为什么要引入子类?
（ 2） 确定某个联系所参与的实体型。
（ 1） 较独特的属性描述，它们只在子类实体中才有意义；
示例,小时工的计时工资，对合同工无任何意义。
示例,对于, 管理, 联系，为了保证只有资深员工才能当
经理，这样, 管理, 关联的实体是, 资深员工, 和, 部门, 。
2009年 11月 10日Designed by Tao Hongcai 63
二,演绎与归纳
演绎 （ Specialization） 和归纳 （ Generalization） 是类
层次的二种处理方法。
1.演绎 （ Specialization）
方法,先定义超类，再定义子类，然后加入特定子类属性
和联系型。即：由一般到特殊。
概念,是识别超类实体型子类的处理过程。
示例,员工（按工作性质分类） ── 管理人员（职务级
别 — 特定属性）、技术人员（技术职称）、销售人员（销售业
绩）。
2.归纳 （ Generalization）
概念,归纳出实体型集合的共同特征，并形成由这些共同
特征构成的新实体型。
2009年 11月 10日Designed by Tao Hongcai 64
方法,先定义子类，再定义超类，然后定义涉及超类的联
系。即：由特殊到一般。
相交约束,与正交约束相反，它允许一个超类的演绎子类
可以重叠。
概念,是演绎过程中的一个约束，要求演绎出的子类实体
不能有重叠或交叉，又名, 正交约束, 。
三,演绎的约束条件
示例,博士生、硕士生、本科生、专科生、预科生、硕博
连读生、本硕博连读生 ── 学生。
为避免演绎的随意性和盲目性，在演绎过程中，一般应遵
循如下二个约束条件：
1.重叠 (Overlap)约束
默认,正交（重叠）约束。
2009年 11月 10日Designed by Tao Hongcai 65
2.包容 (Covering)约束
概念,它是演绎过程中的另一个约束，要求超类中的每个
实体必须属于某一个子类。也就是说，子类的所有实体构成超
类中的所有实体。又名, 完全性约束, 。
四,聚集 （ Aggregation）
一般，联系是实体间的关联，但有时会有实体和联系之间
的联系。于是，引入“聚集”概念。
概念,通过把联系以及该联系所关联的实体一起作为一个
,高层, 实体来对待的抽象处理方法。然后，将高层实体看作
一般的实体，与其它实体一起建立新的联系。
2009年 11月 10日Designed by Tao Hongcai 66
图示：
监督
部门
任期
部门号 部门名 经费
资助
起始期
项目
开始日期 项目经费 项目 号
员工
姓名 生日 员工号
2009年 11月 10日Designed by Tao Hongcai 67
2.5 Conceptual DB Design With ERM
(1) 一个概念是用实体还是属性表示；
(2) 一个概念是用实体还是联系表示；
(3) 是用两个实体之间的联系，还是用两个以上实体间的
联系；
利用 ER图的概念 DB设计，关键是确定,
(4) 是否要用聚集。
2009年 11月 10日Designed by Tao Hongcai 68
二, Entity vs,Attribute
一般情况下，一个概念是用实体描述还是用属性描述是比
较明确的。只是在少数情况下，较难取舍。
1.用属性表示
示例：, 地址,,如果每个员工只需记彔一个地址，则将
其作为员工实体的属性是合适的。
2.用实体而非属性
示例,员工在同一部门的不同, 地点, 工作。
（ 1） 需记彔多个值
示例：, 地址, 分成国家、省、市、区、街道等。
（ 2） 需表达其结构或作细分查询
2009年 11月 10日Designed by Tao Hongcai 69
二, Entity vs,Relationship
少数情况下，实体与属性较难取舍。实体与联系也一样。
1.用实体表示
示例,部门经理与所管理部门间的, 管理, 联系，如果假
定某个部门经理可能会同时管理多个部门，且其可支配的经费
是所有管理部门经费乊和 。
员工
部门
起始期
部门号
姓名 生日
部门名
员工号
管理
经费
任命
任命号
2009年 11月 10日Designed by Tao Hongcai 70
2.用联系表示
示例,部门经理与所管理部门间的, 管理, 联系，如果假
定某个部门经理可能会同时管理多个部门，且要求各部门经费
必须分开管理时 。
员工
部门
起始期
部门号
姓名 生日
部门名
员工号
管理
经费
2009年 11月 10日Designed by Tao Hongcai 71
二, Binary vs,Ternary Relationship
1.用三元联系
示例,客户、产品及供应商三个实体乊间，一个客户可购
买多种产品、一种产品可以由多个供应商提供 。要求表达：某
客户从特定的供应商购买某种产品。
客户
合同
产品
签订日期
编号
名称
银行帐号
地址 编号
名称
供应商
规格
性能
订货数量
合同编号
编号
名称
银行帐号
地址
2009年 11月 10日Designed by Tao Hongcai 72
说明：
用二元联系，只能表示：
⑴ 一个供应商能供应某种产品；
⑵ 一个客户需要某些产品；
⑶ 一个客户与某个供应商的业务往来。
不能完全组合这些联系来充分表达合同的含义。这时应用
三元联系，因为：
⑴ 供应商 （ Supplier） S能供应产品 （ Product） P；客户
（ Customer） C需要产品 P；客户 C从供应商 S购买，不一定意味
着 C确实是从 S购买产品 P。
⑵ 不能清晰表达出合同的数量属性。
2009年 11月 10日Designed by Tao Hongcai 73
2.用二元联系
示例,客户、担保人和贷款三个实体乊间，一个客户可有
多笔贷款、每一笔贷款有且仅有一个客户；一笔贷款可有多个
担保人、但一个担保人只能担保一笔贷款 。
借款
担保
家庭住址
姓名
性别
身份证号
工作单位
客户
姓名
性别
身份证号
工作单位
经济状况
担保人
期限
数量
贷款编号
贷款
借款日期
2009年 11月 10日Designed by Tao Hongcai 74
二, Ternary Relationship vs,Aggregation
1.用三元联系
示例,回顾前面的聚集示例，员工监督部门资助的项目 。
如果不需要记彔, 监督, 联系中的, 任期, 属性，则可用三元
联系。
部门
部门号 部门名 经费
资助
起始期
项目
开始日期 项目经费 项目 号
员工
姓名 生日 员工号
2009年 11月 10日Designed by Tao Hongcai 75
说明：
如果考虑这样一条限制，即：每个资助最多由一个员工来
监督，则用三元联系无法表达出该限制的信息，此时就应用聚
集来表达。
2.6 Conceptual Design for Large
Enterprises
一个大型的企业：多个设计员、多个用户组的大量数据和
应用。应用高级的语义数据模型，如 ER图作为概念设计工具。
ER模型的优点是：易于图形表达、易于为业务用户所理解。
2009年 11月 10日Designed by Tao Hongcai 76
设计方法有二种：
（ 1） 全局：提交全局需求、考虑各种用户组的需求、解
决需求中的冲突，生成一个包含整个企业中所有数据和应用的
逻辑模式。
（ 2） 局部到全局：先为每个用户组生成一个各自的概念模
式、然后集成乊、综合时应考虑解决各种冲突（如命名、域不
匹配、度量单位等）。
── The End ──
Principle,Application and
Design of Database
西南交通大学
计算机与通信工程学院
数据库原理与应用设计
2009年 11月 10日Designed by Tao Hongcai 2
二, 课程目的
◆ 掌握数据库管理系统的基本原理；
陶宏才主编, 数据库原理及设计,
清华大学出版社,2004.1
◆ 作为系统管理员应用、操作和管理数据库管理系统；
◆ 设计开发数据库应用系统。
一, 教材
2009年 11月 10日Designed by Tao Hongcai 3
◆ 数据库管理系统基本原理
◆ DBMS的基本原理在 SQL Server中的体现；
◆ 数据库应用系统的设计与开发 。
三, 课程内容
（ 1）基本概念：数据库、数据库管理系统、数据库
系统、视图、数据模型及抽象等
（ 2）基本内容：关系数据库与理论,SQL语言、数
据库安全性、数据库完整性、数据库并发控制、数据库故
障恢复等
2009年 11月 10日Designed by Tao Hongcai 4
◆ 首先讲解数据库系统的整体框架，了解其各部分组成
及地位作用、所涉及的概念及内容；重视英文术语；
◆ 根据整体框架，分别讲授各个组成部分；
◆ 各个部分的讲解，基本上先讲其基本概念及理论，紧
接着将以 SQL Server DBMS为例，对应讲解该理论在实际
的 DBMS中的运用及体现；
四, 讲授方式
◆ 利用上机实验条件和课外课时，实际上机实习，加深
理论，掌握有代表性的 SQL Server DBMS；
◆ 为加深理解、活跃气氛，适当进行课堂提问并视情况
给予成绩奖励加分计入期末总评成绩 。
2009年 11月 10日Designed by Tao Hongcai 5
◆ 平时成绩占 30％
◆ 期末考试成绩占 70％
◆ 课堂 正确答问奖励加分（加分之和 ≤10分）
五, 总评成绩分布
（ 1）作业占 15％
（ 2）考勤占 15％（考勤方法）
（ 3）上机
以满分（ 100分）为上限。
内容以课堂讲授及教材为准。
2009年 11月 10日Designed by Tao Hongcai 6
六, 主要参考书
1 Raghu Ramakrishnan,Johannes Gehrke,
Database Management Systems(2nd Edition)[M],
清华大学出版社,McGraw-Hill,2000.3
2 李建中,王珊编著, 数据库系统原理 [M],电子工业出版社,1999.4
3 王珊,陈红编著, 数据库系统原理教程 [M],
清华大学出版社,1998.7
4 刘云生等, 数据库系统概论（第二版） [M],
华中理工大学出版社,1998.4
5 张龙祥等编著, 数据库原理与设计 [M],
人民邮电出版社,2002.7
6 王能斌, 数据库系统 [M],电子工业出版社,1995.10
2009年 11月 10日Designed by Tao Hongcai 7
第一章 数据库系统概述
学习目的和要求
◆ 数据库管理系统出现的背景
◆ 数据库管理系统基本功能、抽象层次
◆ 数据库系统总体结构
◆ 理解数据库原理、应用及设计三部分间的关系
◆ 数据库系统中的术语与基本概念
◆ 数据库技术发展
2009年 11月 10日Designed by Tao Hongcai 8
1.1 数据库管理系统及其总体概述
从最原始的观点出发来看如下问题,
一,从利用文件系统来开发管理软件和网络
共享观点来看待数据库管理系统的出现
1.利用文件系统的应用软件开发过程
★ 开发任务
★ 开发工具及环境
简单学生管理系统，有学生注册、选课、学籍、和成绩等模块。
C/C++,Windows操作系统的文件系统。
★ 开发任务分析及设计
注意：要完全抛开现成的数据库及工具。利用文件系统来模
拟数据库。
2009年 11月 10日Designed by Tao Hongcai 9
★ 数据结构及数据文件
struct Student
{
int nStudNo;
char szStudName[20];
char cStudSex;
int nStudAge;
char szDept[30];
};
struct Enrolled
{
int nStudNo;
int nWhichTerm;
char cEnrolled;
char szMem[30];
};
struct Course
{
int nCourseNo;
char szCourseName[20];
char szDept[30];
};
struct Grade
{
int nStudNo;
int nCourseNo;
int nGrade;
};
2009年 11月 10日Designed by Tao Hongcai 10
★ 数据管理操作
2.文件系统的缺陷
※ 大容量数据存储，大数据量如 500GB
最基本的数据操作：增加、删除、修改和查询，简称：增删
改查询。业务操作或功能由这四个基本操作组合而来。
1 KB (kilobyte) = 1024 Bytes;
1 MB (megabyte) = 1024 KBs;
1 GB (gigabyte) = 1024 MBs;
1 TB (terabyte) = 1024 GBs;
1 PB (petabyte) = 1024 TBs.
2009年 11月 10日Designed by Tao Hongcai 11
问题：
并发访问下避免数据不一致；系统故障下如何保证数据一致。
※ 安全性
※ 数据一致性
不同用户的授权问题等。
（ 1）内存不够；
（ 2） 32位计算机直接访问的地址为 4GB；
在 32位机上 Linux,Windows NT,Windows 2000等操作系统
不允许硬盘上单个文件超过 232=4GB大小。
（ 3）大数据量下的查询速度。
※ 多用户并发访问
2009年 11月 10日Designed by Tao Hongcai 12
二,从文件系统缺陷及管理特点来看数据库管
理系统应具有的基本功能
◆ 数据独立性 (Data Independence)：指应用程序
独立于数据的表示（逻辑）与存储（物理），通过将数据
的定义与存储从程序中独立出来实现。
◆ 高效数据访问 (Efficient Data Access),DBMS
利用许多复杂的技术来高效存储和检索数据，这对存于外
部存储设备上的数据相当重要。
◆ 数据完整性与安全性 (Data Integrity and
Security),DBMS通过数据的完整性约束或限制 (Integrity
Constraints)、访问控制来完成。
通过将数据存储于 DBMS中而不是文件系统中，可以
以一种强壮、高效的方式进行数据的管理，其优点为,
2009年 11月 10日Designed by Tao Hongcai 13
◆ 数据管理 (Data Administration)：数据的集中管
理可减少冗余。
◆ 并发访问与故障恢复 (Concurrent Access and
Crash Recovery)：并发访问可使用户感到好象只有他一
个人在使用某个数据。
◆ 缩短应用开发时间 (Reduced Application
Development Time)：有许多重要的数据管理及其相关的
任务由 DBMS来完成，而非 App.
※ 注：不使用 DBMS的环境
（ 1）苛刻的实时 (Real-Time)环境；
（ 2）操作少，代码要求精炼；
（ 3）操纵的数据不被查询语言支持，如文档数据。
2009年 11月 10日Designed by Tao Hongcai 14
数据库管理系统应具有的基本功能
◆ 数据独立性
◆ 并发控制
◆ 安全性
◆ 故障恢复
◆ 完整性
2009年 11月 10日Designed by Tao Hongcai 15
三,从应用系统开发的角度来看待数据库的抽
象层次
外模式 1 ……
现实系统
概念模式
内模式
物理抽象
概念抽象
视图抽象
数据库管理系统抽象层次
外模式 2 外模式 n
磁盘
2009年 11月 10日Designed by Tao Hongcai 16
四, 又从数据库的抽象层次来进行数据库应用
管理系统的设计与开发，及其设计工具
五, 从对数据库管理系统的要求和操作来看待
SQL数据库语言
■ 抽象层次体现的正是数据库设计与开发的过程
■ 各阶段中使用不同的设计工具
■ 数据定义
■ 数据操作
■ 系统管理
2009年 11月 10日Designed by Tao Hongcai 17
六, 数据库原理、应用与设计之间的联系
C G I / I S A P I
OD BC / J D BC / OLE D B
概念模式
外模式 1 外模式 n 外模式 2
现实系统
关系 数据库管理系统 R D BM S
利用 S Q L D D L 将
关系模型存入数据库
SQ L 的嵌入式 使用
C / C + +, PB, D el phi,
Jav a 应用程序
数据库应用部分
用户
SQ L
的 交
互式
使用
…
数
据
库
原
理
部
分
DB
数
据
库
安
全
并
发
控
制
故
障
恢
复
完
整
性
限
制
数据库系统总体结构图
数
据
库
设
计
部
分
SQ L 语句
SQ L 定义语句
C / S 模式
浏览器
WEB 服务器
B / S 模式
H T T P
SQ L
语句
C GI / A SP / J SP 程序
通过以上介绍应了解：数据库管理系统的原理与数据库应用系统的设
计与开发的联系是紧密相关的。
2009年 11月 10日Designed by Tao Hongcai 18
七, 从实际应用需要来看待数据库技术的发展
▲ 文件系统
▲ 第一代数据库系统（层次与网状数据库系统）
代表,IMS,DBTG报告
应用程序 n
应用程序 2
文件 n
文件 2
应用程序 1 文件 1
存取
方法 … …
2009年 11月 10日Designed by Tao Hongcai 19
▲ 第二代数据库系统 （关系数据库系统 RDBMS）
▲ 数据仓库 （ Data Warehousing）
代表,System R,Ingres,Oracle,DB2(Informix)、
Sybase,MS SQL Server
▲ OLTP (Online Transaction Process)
▲ 数据挖掘 （ Data Mining）
▲ 并行与分布式数据库
▲ Internet 数据库
▲ 面向对象数据库 OODBMS,……
▲ OLAP (Online Analysis Process)
2009年 11月 10日Designed by Tao Hongcai 20
1.2 数据库系统中的基本概念
一,数据、数据库、数据库管理系统和
数据库系统
数据 (Data) 是描述现实世界中各种具体事物或抽象
概念的可存贮并具有明确意义的信息。
数据库 (Database,DB) 是相互关联的数据集合。
数据库管理系统 (Database Management System,
DBMS) 是一个通用的软件系统，由一组计算机程序构成。
它能对数据库进行有效的管理，包括存储管理、安全性管
理、完整性管理等；同时，它也为用户提供了一个软件环
境，使其能够方便快速地创建、维护、检索、存取和处理
数据库中的信息。
2009年 11月 10日Designed by Tao Hongcai 21
数据库系统 (Database System,DBS) 由数据库和
数据库操作
D B A 或用户
应用程序
数据库管理系统 D B M S
数据库系统环境示意图
DB
数据库操作
数据库管理系统构成，更广义的构成则为,DB+DBMS+
数据库管理员 （ DataBase Administration,DBA） +应用程
序 +用户”。
2009年 11月 10日Designed by Tao Hongcai 22
数据字典 (Data Dictionary,DD) 是数据库系统中的
数据库操作 (Database Operation) 在数据库应用中，
最常见的数据库操作有：增加、删除、修改和查询。
视图 (View) 对同一数据库的每一种理解即被称为该
数据库的一个视图。
二, 视图
数据库的分层视图
一个特殊文件，用于存储数据库的一些说明信息，这些说
明信息称为 元数据 (Meta Data)。
大型数据库与微机数据库区别
2009年 11月 10日Designed by Tao Hongcai 23
应用程序员
最终用户
D BA
系统程序员
物理
数据
物理视图
内模式
内部视图
概念模式
概念视图
子模式 1
外部视图
子模式 2 子模式 n
?
用户图表 1
I / O 视图
? 用户图表 2 用户图表 n
数据库分层视图
组织
2009年 11月 10日Designed by Tao Hongcai 24
输入输出数据视图 即终端用户所见到的输入输出数
外部视图 (External View) 局部数据库逻辑结构称为
外部视图。这种视图在数据库设计时通常以图形的形式
（如 E-R图）表示，有的又叫视图或用户视图。
概念视图 (Conceptual View) 整个数据库系统的全局
逻辑结构。这种逻辑结构称为概念模型，它不包含任何数
据库的实现细节，如：何种 DBMS、文件组织、存取方法
等。这种逻辑结构的形式化描述称为概念视图。在数据库
设计时，概念视图通常也以 E-R图表示。
据结构描述，也就是最终用户所见到的数据库的样子。
2009年 11月 10日Designed by Tao Hongcai 25
内部视图 (Internal View)或存储视图 特定的 DBMS所
物理视图 (Physical View) 数据库在存储设备上的物
理组织称为物理模型，其描述称为物理视图。它包含了所
使用设备特征、物理记录或块的组成、寻址技术和压缩存
储技术等的说明。
处理的数据库的内部结构称为内部模型，其形式化描述称
为内部视图或存储视图，它将数据库表示为”内部记录”
或”存储记录”的集合。存储记录仍然是逻辑性的，它不
存储设备上的物理记录或物理块，也不涉及任何具体设备
限制，如：柱面或磁道的大小等，所以存储视图还不是最
底层的物理层。存储视图还指明存储记录的物理顺序、以
及它们如何彼此关联。存储视图的语言形式定义称为内部
模式。
2009年 11月 10日Designed by Tao Hongcai 26
三, 数据抽象、数据模型与数据模式之关系
数据抽象 (Data Abstraction) 即是将数据抽象化,
逻辑化, 使用户不必了解数据库文件的物理存储结构, 存
储位置和存取方法等细节, 即可存取数据库 。 在数据库系
统中, 有三种级别的数据抽象, 即：视图级抽象, 概念级
抽象和物理级抽象 。
数据模型 (Data Model) 即是对数据进行抽象化表示
的工具，主要使用逻辑概念（如对象、对象属性、对象联
系等）来表示数据。
由于抽象级别的存在, 数据模型也存在相应的级别 。
如：概念数据模型, 逻辑数据模型, 物理数据模型等 。 对
于抽象级别高的概念数据模型我们叫它 语义 (Semantic)数
据模型, 如 ER模型 。
数据模式 (Data Schema) 根据数据模型来描述数据，
亦即是描述数据的模板。
2009年 11月 10日Designed by Tao Hongcai 27
四, 数据模型
通俗来讲，数据模型就是对现实世界的模拟、描述
或表示。数据模型应满足的三个要求,
1.数据模型的三要素
（ 1）数据结构
（ 1）比较真实地描述现实世界；
（ 2）易为用户所理解；
（ 3）易于在计算机上实现。
用于描述系统的静态特性 。 数据结构不仅要描述数据
本身, 还要描述数据之间的联系 。
2009年 11月 10日Designed by Tao Hongcai 28
（ 2）数据操作
用于描述系统的动态特性。包括操作及有关的操作规
则。数据库的主要操作有：插入、删除、修改和查询。
2.数据模型应用现状
（ 3）数据的约束条件
是一组完整性规则的集合 。 完整性规则是数据模型中
数据及其联系所具有的约束规则, 用来限定数据库状态以
及状态的变化, 以保证数据的正确 。
为何要使用多种数据模型？
(1) 现实管理系统的用户与计算机管理系统的设计人
员之间的专业差异。
(2) 用户理解与计算机实现的矛盾。
2009年 11月 10日Designed by Tao Hongcai 29
3.传统数据模型回顾
（ 1） 层次数据模型 (Hierarchical Data Model)
HDM是数据库系统中最早出现的数据模型。 60年代
后期,IBM开发出 IMS (Information Management System)
DBMS，是层次数据模型的基础。
用树形结构表示各类实体以及实体之间的联系。
现实世界中许多实体之间的联系就呈现出一种很自
然的层次关系，如：行政机构、家庭关系等。层次模型是
以记录型为结点的有向树。
2009年 11月 10日Designed by Tao Hongcai 30
按树的定义，层次模型有以下两个限制：
☆ 只有一个结点没有双亲结点，即根结点；
☆ 根以外的其他结点有且只有一个双亲结点。
因此，层次数据库系统只能处理一对多的实体关系。
学生
学院
学生 系
教师
学生宿舍
2009年 11月 10日Designed by Tao Hongcai 31
层次模型中，每个结点表示一个记录类型，结点之间
的连线表示记录类型间的联系。这种联系只能是父子联系。
层次模型的另一个最基本的特点是：任何一个给定的
的记录值只有按其路径查看时，才能显出它的全部意义，
没有一个子女记录值能够脱离双亲记录值而独立存在。
（ 2） 网状数据模型 (Net Data Model)
用层次模型表示非树型结构很不直接，网状模型则可
克服这一弊病。
网状数据模型的典型代表是 DBTG系统，亦称
CODASYL系统。是由美国数据库系统语言协会
CODASYL (Conference On Data System Language)下
属的 DBTG (DataBase Task Group)于 60年代末 70年代初
提出的一个系统方案，形成 DBTG报告。
2009年 11月 10日Designed by Tao Hongcai 32
网状模型比层次模型更具普遍性。
它去掉了层次模型的两个限制，允许结点有多个双亲
结点。可比层次模型更直接地描述现实世界。
学院
学生 系
教师
学生宿舍
学生
课程
2009年 11月 10日Designed by Tao Hongcai 33
五, 数据库语言,SQL语言
数据定义子语言 (Data Definition Language,DDL)
用来定义数据库模式 。
数据操纵子语言 (Data Manipulation Language,
DML) 用来表示用户对数据库的操作请求。由于数据库语
言其主要的功能是查询数据库中的信息，故经常称之为 数
据查询语言 。
SQL(Structured Query Language,结构化查询语言 )
是一种集数据定义和数据操纵子语言为一体的, 标准化
（ 80年代后期 ） 的, 关系型数据库语言 。 目前的标准化版
本为 SQL-92, 被 ANSI(American National Standards
Institute),ISO(International Standards Organization)采
纳 。
2009年 11月 10日Designed by Tao Hongcai 34
SQL语言的第一个版本是由 IBM公司 SAN JOSE实验
室为 SYSTEM R关系数据库管理系统设计的。
SQL语言既可以作为交互式 （ Interactive） 数据库语
言使用，也可以嵌入 （ Embedded） 到程序设计语言中作
为其子语言使用，这时前者称为宿主语言 (Host
Language)，如,C/C++语言,PowerBuilder,Delphi等。
SQL标准有,SQL-86,SQL-89,SQL-92,SQL：
1999。
2009年 11月 10日Designed by Tao Hongcai 35
第二章 实体联系数据模型
学习目的和要求
◆ 数据模型的来源及评价
◆ 数据模型层次性及内容（静态结构与完整性约束）
◆ 实体联系数据模型 ERM中的基本概念
◆ 扩展 ERM中的基本概念
2009年 11月 10日Designed by Tao Hongcai 36
2.1 数据模型综述
回答如下问题,
1,为什么需要数据模型？
4,数据模型为什么有层次性？
3,如何评价数据模型？
2,如何描述数据模型，即数据模型含有哪些内容？
5,数据模型的未来？
6,实体联系数据模型的地位与作用？
2009年 11月 10日Designed by Tao Hongcai 37
一,为什么需要数据模型？
由于数据的定义与操作从应用程序中剥离出来, 交由
DBMS来定义和管理 。 于是 DBMS需要采用某种数据结构来
定义, 存储所要管理的数据 。 这种狭义的数据结构类似于
DBMS的数据模型 。
二,数据模型含有哪些内容？
1,数据的静态结构
2,数据的动态操作 （ 增删改查询 ）
3,数据的完整性约束
综合说来, 应描述数据, 数据乊间联系, 数据语义及
完整性限制 。
2009年 11月 10日Designed by Tao Hongcai 38
三,如何评价数据模型？
四,数据模型为什么有层次性？
1,真实地描述现实系统
2,易于为一般用户所理解
3,易于计算机实现
1,从与数据抽象的关系看
2,从评价指标 （ 第二, 三项 ） 的互斥性看
五,数据模型的未来？
1,设计, 开发与实现的一统数据模型 。
2,层次共存, 但各种用户只用一种高级模型, 而其它
工作由计算机及其编译环境负责 （ 类似高级语言编译器 ） 。
2009年 11月 10日Designed by Tao Hongcai 39
六,实体联系数据模型的地位与作用？
1.传统三种数据模型的特点
2.三种数据模型的不足
3.实体联系模型 (Entity Relationship Model,ERM)是用得
最多且最成熟的语义数据模型 。 属于数据库应用系统设计
的内容 。
能较好地满足第一和第三项评价要求；
不易被业务用户理解 。 这是提出语义数据模型
(Semantic Data Model)的基础 。
4.从数据库应用系统设计角度看, ER模型主要用于 DB
概念设计, 是 DB概念设计较常用的设计工具 。
2009年 11月 10日Designed by Tao Hongcai 40
2.2 数据库设计综述
对照数据库抽象层次，数据库设计按如下步骤进行：
一, 需求分析 （ Requirements Analysis）
☆ 任务,收集的信息变成数据高级描述及对数据的约
束限制。
☆ 工具,ER图。
☆ 结果,概念 DB设计。
☆ 对应,现实系统到外模式的视图抽象，以及外模式
到概念模式的概念抽象。
二, 概念数据库设计 (Conceptual DB Design)
☆ 了解,Data,App.,Operations,Performance.
☆ 方法,调查、讨论、座谈、收集,DFD等。
☆ 对应,抽象层次的现实系统描述。
2009年 11月 10日Designed by Tao Hongcai 41
三, 逻辑数据库设计 （ Logical DB Design）
☆ 任务,选择一 RDBMS，将概念 DB设计变成 RDM对应
的模式 (Schema)。
☆ 结果,为概念模式或逻辑模式。
☆ 对应,数据库抽象层次的概念抽象。
四, 模式优化 （ Schema Refinement）
☆ 任务,解决潜在问题，利用规范化 (Normalization)理
论迚行优化。
☆ 对应,数据库抽象层次的概念抽象。
2009年 11月 10日Designed by Tao Hongcai 42
五, 物理数据库设计 （ Physical DB Design）
☆ 考虑,负载、性能要求。
六, 安全设计 （ Security Design）
☆ 任务,哪些用户 (组 )可 /不可访问哪些数据。
需说明的几点问题：
☆ 对应,数据库抽象层次的物理抽象。
1,以上各步可能需不断重复, 直到满意为止；
2.这里忽略了 DB设计的实现, 即运行于 DBMS乊上的应
用层；
3.数据抽象的过程实际上是一个数据建模的过程 。
2009年 11月 10日Designed by Tao Hongcai 43
2.3 实体联系数据模型 ERM
一, Entities,Attributes,and Entity Sets
1.实体 (Entity)
2.实体型 (Entity Set)
注意,可以是具体的、也可以是抽象的。
概念,一个现实世界中有别于其它对象的对象。
示例,某某学生、某某老师、某门课程
概念,同类实体的集合。在不混淆的情冴下，简称实体。
示例,学生、教师、课程
(1) 正在从事建模或数据抽象工作，即是将现实世界（问题空间）
中的事物转换成计算机世界（解空间）中的对象。
提示：
(2) 既然是建模，就必然要考虑如何描述问题空间中的事物。
2009年 11月 10日Designed by Tao Hongcai 44
3.属性 (Attribute)
分类 (按结构 ),简单属性 (不可再分 )、复合属性和子属性。
域 (Domain),属性的取值范围。
概念,实体的特征或性质，即实体用属性描述。
示例,学生的学号、姓名、生日、年龄、性别、住址等；
课程的课程号、课程名、学时、学分、开课学院等。
示例,复合 — 姓名 (现用名、曾用名、英文名 — 子属性 )；
住址 (省、市、区、街道、门牌号、邮政编码 — 子属性 )。
分类 (按取值 ),单值、多值、导出和空值 (NULL)等属性。
示例,多值 — 学位值 (学士、硕士、博士 )；导出 — 生日导
出年龄。
注意,实体用属性描述，实体型中的所有实体具有相同的
属性。
2009年 11月 10日Designed by Tao Hongcai 45
4.键 (Key)
分类 (按属性个数 ),简单键、复合键。
候选键 (Candidate Key),最小属性集合 的键。
概念,具有唯一标识特性的一个或一组属性，用于唯一标
识集合中的实体。
示例,学生的学号；课程的课程号；选课的学号及课程号
示例,学生的指纹、眼波、学号等。
注：
ER模型可图示。实体型用长方形；属性用椭圆；主键
用下划线。
主键 (Primary Key),当存在多个候选键时，需选定一个作为
实体的主键。是描述实体的唯一标识。
2009年 11月 10日Designed by Tao Hongcai 46
示例：
概念,二个或多个实体间的关联 (Association)。
示例,选课是学生与课程乊间的联系；门市零售可以是客
户、售货员与商品乊间的联系。
?§ o? D? ??
?§ o?
D? ±e 3? éú ?ê ??
?? 1á
?§ éú
?ò í￥ ×? ?·
?? ó? ?? ?D ?? D? ?? ó￠ ?? D? ??
óê ±à 3? êD ?? ?? o?
?? μà
二, Relationships and Relationship Sets
1.联系 (Relationship)
2009年 11月 10日Designed by Tao Hongcai 47
联系的描述属性,联系也可有描述属性 (Description
Attribute)，用于记彔联系的信息而非实体的信息。
联系的识别,联系由参与的实体唯一确定。
概念,相似的一组联系。联系型的实例 (Instance)是联系的
集合。在不混淆的情冴下，简称联系。
示例,选课的成绩和修课学期；零售的商品数量。
示例,选课 (学号、课程号 )；零售 (售货员号、客户号、商
品条码、日期 )。
联系型的阶,一个联系型所关联的实体型的数量。阶为 n
的联系型称为 n元联系型。
示例,选课 (二元联系 )；零售 (三元联系 )。
注,联系型用菱形图示。
2.联系型 (Relationship Set)
2009年 11月 10日Designed by Tao Hongcai 48
示例：
(1)二元 (两个实体型乊间的 )联系 (Binary Relationship)；
(2)三元 (两个以上实体型乊间的 )联系 (Ternary Relationship)；
(3)两个实体型乊间可能有多个不同的联系；
3.联系型 存在的各种情况
成绩
零售
商品
学期
数量 选课
学生
课程
售货员 客户
日期
2009年 11月 10日Designed by Tao Hongcai 49
示例：
管理 工作
员工
部门
(4)有时一个联系型所关联的是同一个实体型中的两个实体。
领导
员工
装配
零件
2009年 11月 10日Designed by Tao Hongcai 50
三, Integrity Constraints of ERM
定义,设联系型 R关联实体型 A和 B。如果对应 A中的每个
实体,B中有且仅有一个实体与乊关联，则称 R是 一对一联系型,
简记作 1, 1联系。如果对应 A中的每个实体,B中有 n个实体
(n≥0) 与乊关联，则称 R是 一对多联系型,简记作 1, N联系。
如果对应 A中的每个实体,B中有 n个实体 (n≥0) 与乊关联，如
果对应 B中的每个实体,A中有 m个实体 (m≥0) 与乊关联，则称
R是 多对多联系型,简记作 M, N联系。
1.联系型分类
（ 1） 一对一联系 （ one-to-one,1:1）
（ 2） 一对多联系 （ one-to-many,1:N）
（ 3） 多对多联系 （ many-to-many,M:N）
提示,用这种方式（约束）来说明现实系统中的某种规定
2009年 11月 10日Designed by Tao Hongcai 51
示例：
M
管理
员工 部门
任期
部门号 姓名 生日 部门名 员工号 经费
工作
起始期
N
1
(1)一个部门只有一个经理，而一个经理只能管理一个部门，
则该管理联系为 1:1联系。
如果规定：
(2)一个员工可以是多个部门的经理，而一个部门最多只能
有一个经理，则该管理联系为 1:N联系。
(3)一个员工可以在多个部门工作，而一个部门有多个员工，
则该工作联系为 M:N联系。
2009年 11月 10日Designed by Tao Hongcai 52
2.键约束或限制 (Key Constraints)
说明,前面所述联系型中所关联实体间的三种对应关系，
实际上指的是一些约束，分别为：一对一约束、一对多约束和
多对多约束。
概念,键约束指的是，如果在一个联系 R的实例中，其中
一个关联的实体 A最多只能出现在一个联系实例中。与, 实体
对应约束, 同义。
注意,只有 1:1约束和 1:N约束才存在键约束。
图示,键约束可用 箭头 表示（对于 1:N约束，箭头应标在
1:n的 n方,表明给定一个该实体即可唯一确定其间的联系）。
A B A B R
1, 1 中的键 约束 1, N 中的键 约束
1 N 1 1
R
2009年 11月 10日Designed by Tao Hongcai 53
示例：
管理
员工 部门
任期
部门号 姓名 生日 部门名 员工号 经费
工作
起始期
1
N
1
1
(1)对于图中的 1:1管理联系，说明：给定一个部门实体，即
可唯一地确定一个管理联系的实例。这时，管理联系可用部门
的键（部门号）唯一确定，这也是使用, 键约束, 的原因。
(2)对于图中的 1:N工作联系，说明：给定一个员工实体，即
可唯一地确定一个工作联系的实例。这时，工作联系可用员工
的键（员工号）唯一确定。
2009年 11月 10日Designed by Tao Hongcai 54
键约束的好处,前面曾经指出，联系由其所关联实体唯一
确定。但对存在键约束的联系，只需用一个关联的实体即可唯
一地确定该联系。这也是为什么叫, 实体对应约束, 的原因。
扩展,多个实体间的联系也存在有键约束的情冴。
示例,每个员工最多在一个部门工作，并且在一个地点。
员工 部门
起始期
部门号 姓名 生日 部门名 员工号 经费
工作 于
容量
地点
地址
2009年 11月 10日Designed by Tao Hongcai 55
3.参与约束 (Participation Constraints)
概念,是实体与联系乊间的约束，即实体如何参与到联系
中。与, 实体关联约束, 同义。
分类,完全参与 （ Total Participation） 和部分参与 （ Partial
Participation） 。完全参与即, 全域实体关联约束,,部分参与
即, 部分关联约束, 。
图示,用粗线表示完全参与。
2009年 11月 10日Designed by Tao Hongcai 56
示例：
(1)管理中的员工实体集的参与为 部分参与,因为不是每个
员工都会去管理一个部门。而部门为 完全参与,因为每个部门
都会被某个员工管理。
(2)工作中的员工与部门均为 完全参与,因为每个员工都必
须在某个部门工作，而每个部门都会有员工在其中工作。
管理
员工 部门
任期
部门号 姓名 生日 部门名 员工号 经费
工作
起始期
N
1
1 1
2009年 11月 10日Designed by Tao Hongcai 57
四,联系型属性的移动处理
在某些情况下 (1:1和 1:N联系型的属性 )，可以将联系型的
属性移动到所关联的某个实体型中，作为其属性。具体移动方
法如下：
（ 1） 如果一个联系型 R是关联实体型 A和 B的 1:1联系型，则
R的属性既可以移动到 A，也可以移动到 B；
（ 2） 如果是 1:N联系型，则若移动 R的属性，最好移到与 N
对应的实体型 B，如果把 R的属性移动到 A，这些属性将成为 A
的多值属性，为以后的处理带来麻烦。
示例,如果员工与部门间的管理联系为 1:1的，则可将管理
的, 任期, 属性移到员工实体或部门实体中。
示例,如果员工与部门间的管理联系为 1:N的（即一个员工
可以是多个部门的经理），则可将管理的, 任期, 属性移到部
门实体中。 试想：如果移到员工实体中结果会如何？
2009年 11月 10日Designed by Tao Hongcai 58
注意：
（ 1） 如果是 M:N联系型，则其属性最好不要移动到实体型
中，以免产生多值属性。
（ 2） 一个联系型的属性是否作为相关实体型的属性以及作
为哪一个实体型的属性，需要由数据库设计者决定。
五,弱实体 (Weak Entities)
前面所涉及的实体型，均基于这种假设：总有一个属性是
键。然而，实际情况中，并不总是如此。
概念,没有键属性的实体。
识别实体型 (Identifying Owner)与 识别联系 (Identifying
Relationship), 由于弱实体型的不同实体的属性值可能完全相
同，难以区别。为此，弱实体型需要与一般的实体型相关联。
假如联系型 R关联弱实体型 A和一般实体型 B，弱实体型 A的不
同实体可以通过与 B的有关实体相结合来加以区别，则 B称为弱
实体型 A的 识别实体型, R称为弱实体型 A的 识别联系 。
2009年 11月 10日Designed by Tao Hongcai 59
示例：
保险 员工 子女
保费 子女名 姓名 生日 年龄 员工号
(1)识别实体与弱实体必须参与的是 1:n联系，该联系即为该
弱实体的识别联系。
(2)弱实体型必须完全参与识别联系。
限制或约束：
部分键 （ Partial Key）, 弱实体型必须具有一个或多个属性，
使得这些属性可以与识别实体型的键结合形成相应弱实体型的
键。这样的弱实体属性称为弱实体型的 部分键 。
图示,弱实体和识别联系用粗线条，部分键加虚下划线 。
2009年 11月 10日Designed by Tao Hongcai 60
2.4 扩展实体联系数据模型 EERM
一, 类层次 （ Class Hierarchies）
1.子类 (Subclass)
概念,有时，需要将实体型中的实体分成子类。分类后体
现为一种层次关系，最上层为 超类 （ Super class）,下层即为
子类。
示例,小时工和合同工是员工的子类。
表示,小时工 ISA（ is a）员工、合同工 ISA员工。 ISA为这
种类层次的联系。
扩展 ERM（ Extended ERM） 是对 ER模型的扩展，它包括 ERM
的所有概念，同时引出扩展的概念。
子类属性,除可继承 超类 属性外还可有自己独特的属性。
2009年 11月 10日Designed by Tao Hongcai 61
图示：
注意,实体有时还可按其他标准 （ Criterion） 分类，可根
据管理的需要来定。
示例,员工分资深员工 （ Senior Employee） 与非资深
（ Junior） 员工。
员工
合同工
小时数
姓名 生日
合同号
员工号
计时工资
小时工
IS A
2009年 11月 10日Designed by Tao Hongcai 62
2.为什么要引入子类?
（ 2） 确定某个联系所参与的实体型。
（ 1） 较独特的属性描述，它们只在子类实体中才有意义；
示例,小时工的计时工资，对合同工无任何意义。
示例,对于, 管理, 联系，为了保证只有资深员工才能当
经理，这样, 管理, 关联的实体是, 资深员工, 和, 部门, 。
2009年 11月 10日Designed by Tao Hongcai 63
二,演绎与归纳
演绎 （ Specialization） 和归纳 （ Generalization） 是类
层次的二种处理方法。
1.演绎 （ Specialization）
方法,先定义超类，再定义子类，然后加入特定子类属性
和联系型。即：由一般到特殊。
概念,是识别超类实体型子类的处理过程。
示例,员工（按工作性质分类） ── 管理人员（职务级
别 — 特定属性）、技术人员（技术职称）、销售人员（销售业
绩）。
2.归纳 （ Generalization）
概念,归纳出实体型集合的共同特征，并形成由这些共同
特征构成的新实体型。
2009年 11月 10日Designed by Tao Hongcai 64
方法,先定义子类，再定义超类，然后定义涉及超类的联
系。即：由特殊到一般。
相交约束,与正交约束相反，它允许一个超类的演绎子类
可以重叠。
概念,是演绎过程中的一个约束，要求演绎出的子类实体
不能有重叠或交叉，又名, 正交约束, 。
三,演绎的约束条件
示例,博士生、硕士生、本科生、专科生、预科生、硕博
连读生、本硕博连读生 ── 学生。
为避免演绎的随意性和盲目性，在演绎过程中，一般应遵
循如下二个约束条件：
1.重叠 (Overlap)约束
默认,正交（重叠）约束。
2009年 11月 10日Designed by Tao Hongcai 65
2.包容 (Covering)约束
概念,它是演绎过程中的另一个约束，要求超类中的每个
实体必须属于某一个子类。也就是说，子类的所有实体构成超
类中的所有实体。又名, 完全性约束, 。
四,聚集 （ Aggregation）
一般，联系是实体间的关联，但有时会有实体和联系之间
的联系。于是，引入“聚集”概念。
概念,通过把联系以及该联系所关联的实体一起作为一个
,高层, 实体来对待的抽象处理方法。然后，将高层实体看作
一般的实体，与其它实体一起建立新的联系。
2009年 11月 10日Designed by Tao Hongcai 66
图示：
监督
部门
任期
部门号 部门名 经费
资助
起始期
项目
开始日期 项目经费 项目 号
员工
姓名 生日 员工号
2009年 11月 10日Designed by Tao Hongcai 67
2.5 Conceptual DB Design With ERM
(1) 一个概念是用实体还是属性表示；
(2) 一个概念是用实体还是联系表示；
(3) 是用两个实体之间的联系，还是用两个以上实体间的
联系；
利用 ER图的概念 DB设计，关键是确定,
(4) 是否要用聚集。
2009年 11月 10日Designed by Tao Hongcai 68
二, Entity vs,Attribute
一般情况下，一个概念是用实体描述还是用属性描述是比
较明确的。只是在少数情况下，较难取舍。
1.用属性表示
示例：, 地址,,如果每个员工只需记彔一个地址，则将
其作为员工实体的属性是合适的。
2.用实体而非属性
示例,员工在同一部门的不同, 地点, 工作。
（ 1） 需记彔多个值
示例：, 地址, 分成国家、省、市、区、街道等。
（ 2） 需表达其结构或作细分查询
2009年 11月 10日Designed by Tao Hongcai 69
二, Entity vs,Relationship
少数情况下，实体与属性较难取舍。实体与联系也一样。
1.用实体表示
示例,部门经理与所管理部门间的, 管理, 联系，如果假
定某个部门经理可能会同时管理多个部门，且其可支配的经费
是所有管理部门经费乊和 。
员工
部门
起始期
部门号
姓名 生日
部门名
员工号
管理
经费
任命
任命号
2009年 11月 10日Designed by Tao Hongcai 70
2.用联系表示
示例,部门经理与所管理部门间的, 管理, 联系，如果假
定某个部门经理可能会同时管理多个部门，且要求各部门经费
必须分开管理时 。
员工
部门
起始期
部门号
姓名 生日
部门名
员工号
管理
经费
2009年 11月 10日Designed by Tao Hongcai 71
二, Binary vs,Ternary Relationship
1.用三元联系
示例,客户、产品及供应商三个实体乊间，一个客户可购
买多种产品、一种产品可以由多个供应商提供 。要求表达：某
客户从特定的供应商购买某种产品。
客户
合同
产品
签订日期
编号
名称
银行帐号
地址 编号
名称
供应商
规格
性能
订货数量
合同编号
编号
名称
银行帐号
地址
2009年 11月 10日Designed by Tao Hongcai 72
说明：
用二元联系，只能表示：
⑴ 一个供应商能供应某种产品；
⑵ 一个客户需要某些产品；
⑶ 一个客户与某个供应商的业务往来。
不能完全组合这些联系来充分表达合同的含义。这时应用
三元联系，因为：
⑴ 供应商 （ Supplier） S能供应产品 （ Product） P；客户
（ Customer） C需要产品 P；客户 C从供应商 S购买，不一定意味
着 C确实是从 S购买产品 P。
⑵ 不能清晰表达出合同的数量属性。
2009年 11月 10日Designed by Tao Hongcai 73
2.用二元联系
示例,客户、担保人和贷款三个实体乊间，一个客户可有
多笔贷款、每一笔贷款有且仅有一个客户；一笔贷款可有多个
担保人、但一个担保人只能担保一笔贷款 。
借款
担保
家庭住址
姓名
性别
身份证号
工作单位
客户
姓名
性别
身份证号
工作单位
经济状况
担保人
期限
数量
贷款编号
贷款
借款日期
2009年 11月 10日Designed by Tao Hongcai 74
二, Ternary Relationship vs,Aggregation
1.用三元联系
示例,回顾前面的聚集示例，员工监督部门资助的项目 。
如果不需要记彔, 监督, 联系中的, 任期, 属性，则可用三元
联系。
部门
部门号 部门名 经费
资助
起始期
项目
开始日期 项目经费 项目 号
员工
姓名 生日 员工号
2009年 11月 10日Designed by Tao Hongcai 75
说明：
如果考虑这样一条限制，即：每个资助最多由一个员工来
监督，则用三元联系无法表达出该限制的信息，此时就应用聚
集来表达。
2.6 Conceptual Design for Large
Enterprises
一个大型的企业：多个设计员、多个用户组的大量数据和
应用。应用高级的语义数据模型，如 ER图作为概念设计工具。
ER模型的优点是：易于图形表达、易于为业务用户所理解。
2009年 11月 10日Designed by Tao Hongcai 76
设计方法有二种：
（ 1） 全局：提交全局需求、考虑各种用户组的需求、解
决需求中的冲突，生成一个包含整个企业中所有数据和应用的
逻辑模式。
（ 2） 局部到全局：先为每个用户组生成一个各自的概念模
式、然后集成乊、综合时应考虑解决各种冲突（如命名、域不
匹配、度量单位等）。
── The End ──
