数据库原理—教案.doc

数据库原理 教案
数据库原理—教案
第一章
1.1 数据库系统概述
1.1.1数据库的地位
数据库技术产生于六十年代末，是数据管理的最新技术，是计算机科学的重要分支
数据库技术是信息系统的核心和基础，它的出现极大地促进了计算机应用向各行各业的渗透
1.1.2四个基本概念
一、数据(Data)
1．数据是数据库中存储的基本对象
2．数据的定义
3．数据的种类
4．数据的特点
二、数据库(Database,简称DB)
数据库的定义：
数据库是长期储存在计算机内、有组织的、可共享的大量数据集合。
三、数据库管理系统（Database Management System，简称DBMS）
1．什么是DBMS
数据库管理系统是位于用户与操作系统之间的一层数据管理软件。
2．DBMS的用途
科学地组织和存储数据、高效地获取和维护数据
3．DBMS的主要功能
（1）数据定义功能：
（2）数据操纵功能:提供数据操纵语言(DML)：
（3）数据库的运行管理：
（4）数据库的建立和维护功能(实用程序)：
四、数据库系统
1．什么是数据库系统（Database System，简称DBS）
数据库系统是指在计算机系统中引入数据库后的系统构成。在不引起混淆的情况下常常把数据库系统简称为数据库。
2．数据库系统的构成
由数据库、数据库管理系统（及其开发工具）、应用系统、数据库管理员（和用户）构成。
数据库系统在计算机系统中的位置图示，参看教材page_ 6 图1.2
1.1.3 数据管理技术的产生和发展
1．什么是数据管理
对数据进行分类、组织、编码、存储、检索和维护，是数据处理的中心问题
2．数据管理技术的发展动力
应用需求的推动
计算机硬件的发展
计算机软件的发展
一、人工管理
时期：40年代中--50年代中
产生的背景：
1．应用需求 科学计算
2．硬件水平 无直接存取存储设备（只有纸带、卡片、磁带）
3．软件水平 没有操作系统（只有汇编语言）
4．处理方式 批处理（在进行某一课程计算时，将原始数据随程序一起 存，运算处理后将结果数据输出）
特点
1．数据的管理者：应用程序，数据不保存。
2．数据面向的对象：某一应用程序
3．数据的共享程度：无共享、冗余度极大
4．数据的独立性：不独立，完全依赖于程序
5．数据的结构化：无结构
6．数据控制能力：应用程序自己控制

二、文件系统
时期：50年代末--60年代中
产生的背景
1．应用需求 科学计算、管理
2．硬件水平 磁盘、磁鼓
3．软件水平 有文件系统
4．处理方式 联机实时处理、批处理

文件系统中数据的结构：
1．记录内有结构。
2．数据的结构是靠程序定义和解释的。
3．数据只能是定长的。
可以间接实现数据变长要求，但访问相应数据的应用程序复杂了。
4．文件间是独立的，因此数据整体无结构。
可以间接实现数据整体的有结构，但必须在应用程序中对描述数据间的联系。
5．数据的最小存取单位是记录。
三、数据库系统
时期：60年代末以来
产生的背景
1．应用背景 大规模管理
2.硬件背景 大容量磁盘
3. 软件背景 有数据库管理系统
4．处理方式 联机实时处理,分布处理,批处理
特点
1．数据的管理者：DBMS
2．数据面向的对象：现实世界
3．数据的共享程度：共享性高
4．数据的独立性：高度的物理独立性和一定的逻辑独立性
5．数据的结构化：整体结构化 //用数据模型描述
6．数据控制能力：由DBMS 统一管理和控制
数据的高共享性的好处
1．降低数据的冗余度，节省存储空间
2．避免数据间的不一致性
3．使系统易于扩充

数据独立性：高度的物理独立性和一定的逻辑独立性
1．物理独立性
指用户的应用程序与存储在磁盘上的数据库中数据是相互独立的。当数据的物理存储改变了，应用程序不用改变。
2．逻辑独立性
指用户的应用程序与数据库的逻辑结构是相互独立的。数据的逻辑结构改变了，用户程序也可以不变。
3．数据结构化
整体数据的结构化是数据库的主要特征之一。
数据库中实现的是数据的真正结构化
数据的结构用数据模型描述，无需程序定义和解释。
数据可以变长。
数据的最小存取单位是数据项。

DBMS对数据的控制功能：数据控制能力是由DBMS统一管理和控制
1．数据的安全性（Security）保护
使每个用户只能按指定方式使用和处理指定数据，保护数据以防止不合法的使用造成的数据的泄密和破坏。
2．数据的完整性（Integrity ）检查：实体完整性、参照完整性、用户定义完整性
将数据控制在有效的范围内，或保证数据之间满足一定的关系。
3．并发（Concurrency）控制：与操作系统联系
对多用户的并发操作加以控制和协调，防止相互干扰而得到错误的结果。
4．数据库恢复（Recovery ）
将数据库从错误状态恢复到某一已知的正确状态。

第二章
2.1 关系模型概述
1. 关系数据结构
单一的数据结构----关系
2. 关系操作集合
1) 常用的关系操作
查询选择、投影、连接、除、并、交、差
数据更新：插入、删除、修改
2) 关系操作的特点
集合操作方式，即操作的对象和结果都是集合。
3) 关系数据语言的特点
关系语言是一种高度非过程化的语言
存取路径的选择由DBMS的优化机制来完成
用户不必用循环结构就可以完成数据操作
能够嵌入高级语言中使用
3. 关系的三类完整性约束
实体完整性：通常由关系系统自动支持
参照完整性：早期系统不支持，目前大型系统能自动支持
用户定义的完整性：反映应用领域需要遵循的约束条件，体现了具体领域中的语义约束，用户定义后由系统支持
2.2 关系数据结构
2.2.1 关系
⒈域（Domain）
域是一组具有相同数据类型的值的集合。
2. 笛卡尔积（Cartesian Product）
1) 笛卡尔积
给定一组域D1，D2，…，Dn，这些域中可以有相同的。D1，D2，…，Dn的笛卡尔积为：D1×D2×…×Dn＝｛（d1，d2，…，dn）｜diÎDi，i＝1，2，…，n｝
所有域的所有取值的一个组合，不能重复
2) 元组（Tuple）
笛卡尔积中每一个元素（d1，d2，…，dn）叫作一个n元组（n-tuple）或简称元组。
3) 分量（Component）
笛卡尔积元素（d1，d2，…，dn）中的每一个值di叫作一个分量。
4) 基数（Cardinal number）
若Di（i＝1，2，…，n）为有限集，其基数为mi（i＝1，2，…，n），则D1×D2×…×Dn的基数M为基数的乘积
5)笛卡尔积的表示方法
笛卡尔积可表示为一个二维表。表中的每行对应一个元组，表中的每列对应一个域。
3. 关系（Relation）
1) 关系
D1×D2×…×Dn的子集叫作在域D1，D2，…，Dn上的关系，表示为
R（D1，D2，…，Dn）
R：关系名
n：关系的目或度（Degree）
2) 元组
关系中的每个元素是关系中的元组，通常用t表示。
3) 单元关系与二元关系
当n=1时，称该关系为单元关系（Unary relation）。
当n=2时，称该关系为二元关系（Binary relation）。
4) 关系的表示
关系也是一个二维表，表的每行对应一个元组，表的每列对应一个域。
5) 属性
关系中不同列可以对应相同的域，为了加以区分，必须对每列起一个名字，称为属性（Attribute）。n目关系必有n个属性。
6) 码
候选码（Candidate key）：若关系中的某一属性组的值能唯一地标识一个元组，则称该属性组为候选码
主码：若一个关系有多个候选码，则选定其中一个为主码（Primary key）
主码的诸属性称为主属性（Prime attribute）。
不包含在任何侯选码中的属性称为非码属性（Non-key attribute）
7) 三类关系
基本关系（基本表或基表）：实际存在的表，是实际存储数据的逻辑表示
查询表：查询结果对应的表
视图表：由基本表或其他视图表导出的表，是虚表，不对应实际存储的数据
8) 基本关系的性质
①列是同质的（Homogeneous）
②不同的列可出自同一个域
③列的顺序无所谓
④任意两个元组不能完全相同
⑤行的顺序无所谓
⑥分量必须取原子值
2.2.2 关系模式
1．什么是关系模式
关系模式（Relation Schema）是型
2．定义关系模式
关系模式可以形式化地表示为：
R（U，D，dom，F）
R 关系名
U 组成该关系的属性名集合
D 属性组U中属性所来自的域
dom 属性向域的映象集合
F 属性间的数据依赖关系集合
关系模式通常可以简记为
R (U) 或 R (A1，A2，…，An)
R 关系名
A1，A2，…，An 属性名
3. 关系模式与关系
关系模式：
对关系的描述，静态的、稳定的
关系：
关系模式在某一时刻的状态或内容动态的、随时间不断变化的关系模式和关系往往统称为关系，通过上下文加以区别
2.2.3 关系数据库
在一个给定的应用领域中，所有实体及实体之间联系的关系的集合构成一个关系数据库。

第三章 关系数据库标准语言SQL
3.1 SQL概述
SQL的特点：
1. 综合统一
2. 高度非过程化
3. 面向集合的操作方式
4. 以同一种语法结构提供两种使用方法
5. 语言简洁，易学易用
3.2 数据定义
3.2.1定义语句格式
一、定义基本表：
CREATE TABLE <表名><列名> <数据类型>[ <列级完整性约束条件> ]
[，<列名> <数据类型>[ <列级完整性约束条件>] ] …
[，<表级完整性约束条件> ] ）；
<表名>：所要定义的基本表的名字
<列名>：组成该表的各个属性（列）
<列级完整性约束条件>：涉及相应属性列的完整性约束条件
<表级完整性约束条件>：涉及一个或多个属性列的完整性约束条件
[例1] 建立一个“学生”表Student，它由学号Sno、姓名Sname、性别Ssex、年龄Sage、所在系Sdept五个属性组成。其中学号不能为空，值是唯一的，并且姓名取值也唯一。
CREATE TABLE Student
(Sno CHAR(5) NOT NULL UNIQUE，
Sname CHAR(20) UNIQUE，
Ssex CHAR(1) ，
Sage INT，
Sdept CHAR(15))；
常用完整性约束：
主码约束： PRIMARY KEY
唯一性约束：UNIQUE
非空值约束：NOT NULL
参照完整性约束

PRIMARY KEY 与 UNIQUE 的区别？
[例2] 建立一个“学生选课”表SC，它由学号Sno、课程号Cno，修课成绩Grade组成，其中(Sno, Cno)为主码。
CREATE TABLE SC(
Sno CHAR(5) ,
Cno CHAR(3) ,
Grade int,
Primary key (Sno, Cno));
二、删除基本表
DROP TABLE <表名>;  
基本表删除，则数据、表上的索引都删除，表上的视图往往仍然保留，但无法引用
删除基本表时，系统会从数据字典中删去有关该基本表及其索引的描述
（标准中没有，认为表建立后就永久存在）
[例5] 删除Student表
DROP TABLE Student ;
三修改基本表
ALTER TABLE <表名>
[ ADD <新列名> <数据类型> [ 完整性约束 ] ]
[ DROP <完整性约束名> ]
[ MODIFY <列名> <数据类型> ]；
<表名>：要修改的基本表
ADD子句：增加新列和新的完整性约束条件
DROP子句：删除指定的完整性约束条件
MODIFY子句：用于修改列名和数据类型
[例2] 向Student表增加“入学时间”列，其数据类型为日期型。
ALTER TABLE Student ADD Scome DATE；
不论基本表中原来是否已有数据，新增加的列一律为空值。 
删除属性列
直接/间接删除：
把表中要保留的列及其内容复制到一个新表中
删除原表
再将新表重命名为原表名
直接删除属性列:(新)
例：ALTER TABLE Student Drop Scome；
[例3] 将年龄的数据类型改为半字长整数。
ALTER TABLE Student MODIFY Sage SMALLINT；
注：修改原有的列定义有可能会破坏已有数据
[例4] 删除学生姓名必须取唯一值的约束。
ALTER TABLE Student DROP UNIQUE(Sname)；
3.2.2 建立与删除索引
建立索引是加快查询速度的有效手段
建立索引
DBA或表的属主（即建立表的人）根据需要建立
有些DBMS自动建立以下列上的索引
PRIMARY KEY
UNIQUE
维护索引
DBMS自动完成 
使用索引
DBMS自动选择是否使用索引以及使用哪些索引
一、建立索引
语句格式
CREATE [UNIQUE] [CLUSTER] INDEX <索引名> ON <表名>(<列名>[<次序>][,<列名>[<次序>] ]…)；
用<表名>指定要建索引的基本表名字
索引可以建立在该表的一列或多列上，各列名之间用逗号分隔
用<次序>指定索引值的排列次序，升序：ASC，降序：DESC。缺省值：ASC
UNIQUE表明此索引的每一个索引值只对应唯一的数据记录
CLUSTER表示要建立的索引是聚簇索引
[例5] 为学生-课程数据库中的Student，Course，SC三个表建立索引。其中Student表按学号升序建唯一索引，Course表按课程号升序建唯一索引，SC表按学号升序和课程号降序建唯一索引。
CREATE UNIQUE INDEX Stusno ON Student(Sno)；
CREATE UNIQUE INDEX Coucno ON Course(Cno)；
CREATE UNIQUE INDEX SCno ON SC(Sno ASC，Cno DESC)；
唯一值索引
对于已含重复值的属性列不能建UNIQUE索引
对某个列建立UNIQUE索引后，插入新记录时DBMS会自动检查新记录在该列上是否取了重复值。这相当于增加了一个UNIQUE约束
聚簇索引
建立聚簇索引后，基表中数据也需要按指定的聚簇属性值的升序或降序存放。也即聚簇索引的索引项顺序与表中记录的物理顺序一致
例：
CREATE CLUSTER INDEX StusnameON
Student(Sname)；
在Student表的Sname（姓名）列上建立一个聚簇索引，而且Student表中的记录将按照Sname值的升序存放
l         在一个基本表上最多只能建立一个聚簇索引；
l         聚簇索引的用途：对于某些类型的查询，可以提高查询效率
l         聚簇索引的适用范围：
很少对基表进行增删操作
很少对其中的变长列进行修改操作
二、删除索引
DROP INDEX <索引名>；
删除索引时，系统会从数据字典中删去有关该索引的描述。
[例6] 删除Student表的Stusname索引。
DROP INDEX Stusname ；

第四章 数据库安全性
4.1 计算机安全性概述
4.1.1 计算机系统的三类安全性问题
计算机系统安全性
为计算机系统建立和采取的各种安全保护措施，以保护计算机系统中的硬件、软件及数据，防止其因偶然或恶意的原因使系统遭到破坏，数据遭到更改或泄露等。
三类计算机系统安全性问题:
技术安全类、管理安全类、政策法律类
4.2 数据库安全性控制概述
数据库安全性控制的常用方法
用户标识和鉴定
存取控制
视图
审计
密码存储
4.2.1 用户标识与鉴别
用户标识与鉴别
（Identification & Authentication）
系统核对口令以鉴别用户身份
4.2.2 存取控制
用户权限定义和合法权检查机制一起组成了 DBMS的安全子系统
常用存取控制方法：
自主存取控制
强制存取控制
4.2.3 自主存取控制方法
通过 SQL 的 GRANT 语句和 REVOKE 语句实现
4.2.4授权与回收
一、GRANT
GRANT语句的一般格式：
GRANT <权限>[,<权限>]...
[ON <对象类型> <对象名>]
TO <用户>[,<用户>]...
[WITH GRANT OPTION];
语义：将对指定操作对象的指定操作权限授予指定的用户
4.2.5数据库角色
一、角色的创建
CREATE ROLE <角色名>
二、给角色授权
GRANT <权限>［，<权限>］…
ON <对象类型>对象名
TO <角色>［，<角色>］…
三、将一个角色授予其他的角色或用户
GRANT <角色1>［，<角色2>］…
TO <角色3>［，<用户1>］…
［WITH ADMIN OPTION］
四、角色权限的收回
REVOKE <权限>［，<权限>］…
ON <对象类型> <对象名>
FROM <角色>［，<角色>］…

4.2.6 强制存取控制方法
保证更高程度的安全性
用户能不能直接感知或进行控制
适用于对数据有严格而固定密级分类的部门
4.3 视图机制
把要保密的数据对无权存取这些数据的用户隐藏起来，对数据提供一定程度的安全保护
主要功能是提供数据独立性，无法完全满足要求
间接实现了支持存取谓词的用户权限定义
4.4 审计
审计日志（Audit Log）
将用户对数据库的所有操作记录在上面
DBA利用审计日志
找出非法存取数据的人、时间和内容
4.5 数据加密
加密方法：
替换方法
置换方法
混合方法
4.6 统计数据库安全性
规则1：任何查询至少要涉及N(N足够大)个以上的记录
规则2：任意两个查询的相交数据项不能超过M个
规则3：任一用户的查询次数不能超过1+(N-2)/M
数据库安全机制的设计目标：
试图破坏安全的人所花费的代价 >> 得到的利益

第五章数据库完整性
5.1 实体完整性
5.1.1 实体完整性定义
关系模型的实体完整性
CREATE TABLE中用PRIMARY KEY定义
单属性构成的码有两种说明方法
定义为列级约束条件
定义为表级约束条件
对多个属性构成的码只有一种说明方法
定义为表级约束条件

5.1.2 实体完整性检查和违约处理
插入或对主码列进行更新操作时，RDBMS按照实体完整性规则自动进行检查。包括：
1. 检查主码值是否唯一，如果不唯一则拒绝插入或修改
2. 检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改
检查记录中主码值是否唯一的一种方法是进行全表扫描
5.2 参照完整性
5.2.1 参照完整性定义
关系模型的参照完整性定义
在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码
用REFERENCES短语指明这些外码参照哪些表的主码
例如，关系SC中一个元组表示一个学生选修的某门课程的成绩，（Sno，Cno）是主码。Sno，Cno分别参照引用Student表的主码和Course表的主码
［例3］ 定义SC中的参照完整性
CREATE TABLE SC
(Sno CHAR(9) NOT NULL，
Cno CHAR(4) NOT NULL，
Grade SMALLINT，
PRIMARY KEY (Sno， Cno)， /*在表级定义实体完整性*/
FOREIGN KEY (Sno) REFERENCES Student(Sno)，/*在表级定义参照完整性*/
FOREIGN KEY (Cno) REFERENCES Course(Cno) ); /*在表级定义参照完整性*/
参照完整性违约处理
1. 拒绝(NO ACTION)执行
默认策略
2. 级联(CASCADE)操作
3. 设置为空值（SET-NULL）
对于参照完整性，除了应该定义外码，还应定义外码列是否允许空值
5.3 用户定义的完整性
用户定义的完整性就是针对某一具体应用的数据必须满足的语义要求
RDBMS提供，而不必由应用程序承担
5.3.1 属性上的约束条件的定义
CREATE TABLE时定义
列值非空（NOT NULL）
列值唯一（UNIQUE）
检查列值是否满足一个布尔表达式（CHECK）
1.不允许取空值
2.列值唯一
3. 用CHECK短语指定列值应该满足的条件
5.3.2属性上的约束条件检查和违约处理
插入元组或修改属性的值时，RDBMS检查属性上的约束条件是否被满足
如果不满足则操作被拒绝执行
5.3.3 元组上的约束条件的定义
在CREATE TABLE时可以用CHECK短语定义元组上的约束条件，即元组级的限制
同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件
5.3.4元组上的约束条件检查和违约处理
插入元组或修改属性的值时，RDBMS检查元组上的约束条件是否被满足
如果不满足则操作被拒绝执行
第五章数据库完整性
5.4 完整性约束命名子句
CONSTRAINT 约束
CONSTRAINT <完整性约束条件名>
［PRIMARY KEY短语
|FOREIGN KEY短语
|CHECK短语］
在Student表上建立了5个约束条件，包括主码约束（命名为StudentKey）以及C1、C2、C3、C4四个列级约束。
2. 修改表中的完整性限制
使用ALTER TABLE语句修改表中的完整性限制
5.5 域中的完整性限制
SQL支持域的概念，并可以用CREATE DOMAIN语句建立一个域以及该域应该满足的完整性约束条件。
5.6 触发器
触发器（Trigger）是用户定义在关系表上的一类由事件驱动的特殊过程
由服务器自动激活
可以进行更为复杂的检查和操作，具有更精细和更强大的数据控制能力
5.6.1 定义触发器
CREATE TRIGGER语法格式:
CREATE TRIGGER <触发器名>
{BEFORE | AFTER} <触发事件> ON <表名>
FOR EACH {ROW | STATEMENT}
［WHEN <触发条件>］
<触发动作体>
定义触发器的语法说明:
1. 创建者：表的拥有者
2. 触发器名
3. 表名：触发器的目标表
4. 触发事件：INSERT、DELETE、UPDATE
5. 触发器类型
行级触发器（FOR EACH ROW）
语句级触发器（FOR EACH STATEMENT）
例如,假设在［例11］的TEACHER表上创建了一个AFTER UPDATE触发器。如果表TEACHER有1000行，执行如下语句：
UPDATE TEACHER SET Deptno=5;
如果该触发器为语句级触发器，那么执行完该语句后，触发动作只发生一次
如果是行级触发器，触发动作将执行1000次
6. 触发条件
触发条件为真
省略WHEN触发条件
7. 触发动作体
触发动作体可以是一个匿名PL/SQL过程块
也可以是对已创建存储过程的调用
5.6.2激活触发器
触发器的执行，是由触发事件激活的，并由数据库服务器自动执行
一个数据表上可能定义了多个触发器
同一个表上的多个触发器激活时遵循如下的执行顺序：
（1）执行该表上的BEFORE触发器；
（2）激活触发器的SQL语句；
（3）执行该表上的AFTER触发器。
［例20］执行修改某个教师工资的SQL语句，激活上述定义的触发器。
UPDATE Teacher SET Sal=800 WHERE Ename='陈平';
执行顺序是：
执行触发器Insert_Or_Update_Sal
执行SQL语句“UPDATE Teacher SET Sal=800 WHERE Ename='陈平';”
执行触发器Insert_Sal；
执行触发器Update_Sal
5.6.3 删除触发器
删除触发器的SQL语法：
DROP TRIGGER <触发器名> ON <表名>;
触发器必须是一个已经创建的触发器，并且只能由具有相应权限的用户删除。
［例21］ 删除教师表Teacher上的触发器Insert_Sal
DROP TRIGGER Insert_Sal ON Teacher;

第六章关系数据理论
6.1 问题的提出
一、概念回顾
二、关系模式的形式化定义
三、什么是数据依赖
四、关系模式的简化定义
五、数据依赖对关系模式影响
6.2 规范化
规范化理论正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、更新异常和数据冗余问题。
6.2.1 函数依赖
一、函数依赖
定义6.1 设R(U)是一个属性集U上的关系模式，X和Y是U的子集。
若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称 “X函数确定Y” 或 “Y函数依赖于X”，记作X→Y。
说明
1. 所有关系实例均要满足
2. 语义范畴的概念
3. 数据库设计者可以对现实世界作强制的规定
二、平凡函数依赖与非平凡函数依赖
在关系模式R(U)中，对于U的子集X和Y，
如果X→Y，但Y Í X，则称X→Y是非平凡的函数依赖
若X→Y，但Y Í X, 则称X→Y是平凡的函数依赖
例：在关系SC(Sno, Cno, Grade)中，
非平凡函数依赖： (Sno, Cno) → Grade
平凡函数依赖： (Sno, Cno) → Sno 、(Sno, Cno) → Cno
平凡函数依赖与非平凡函数依赖（续）
若X→Y ，则X 称为这个函数依赖的决定属性组，也称为决定因素（Determinant ）。
若X→Y ，Y→X ，则记作X←→Y 。
若Y 不函数依赖于X ，则记作X→Y 。
三、完全函数依赖与部分函数依赖
定义6.2 在R(U)中，如果X→Y，并且对于X的任何一个真子集X’，都有X’ Y, 则称Y对X完全函数依赖，记作 X F Y。
若X→Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖，记作X P Y。
[例1] 中(Sno,Cno)→Grade是完全函数依赖，(Sno,Cno)→Sdept是部分函数依赖
因为Sno →Sdept成立，且Sno是（Sno，Cno）的真子集
四、传递函数依赖
定义6.3 在R(U)中，如果X→Y，(Y ÍX) ,Y→X Y→Z，则称Z对X传递函数依赖。
记为：X → Z
注: 如果Y→X，即X←→Y，则Z直接依赖于X。
例: 在关系Std(Sno, Sdept, Mname)中，有：
Sno → Sdept，Sdept → Mname
Mname传递函数依赖于Sno
6.2.2 码
定义6.4 设K为R中的属性或属性组合。若K U， 则K称为R的侯选码（Candidate Key）。
若候选码多于一个，则选定其中的一个做为主码（Primary Key）。
主属性与非主属性
包含在任何一个候选码中的属性，称为主属性（Prime attribute）
不包含在任何码中的属性称为非主属性（Nonprime attribute）或非码属性（Non-key attribute）
全码
整个属性组是码，称为全码（All-key）
外部码
定义6.5 关系模式 R 中属性或属性组X 并非 R的码，但 X 是另一个关系模式的码，则称 X 是R 的外部码（Foreign key）也称外码
如在SC（Sno，Cno，Grade）中，Sno不是码，但Sno是关系模式S（Sno，Sdept，Sage）的码，则Sno是关系模式SC的外部码
主码与外部码一起提供了表示关系间联系的手段
6.2.3 范式
范式是符合某一种级别的关系模式的集合
关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式
范式的种类：
第一范式(1NF)
第二范式(2NF)
第三范式(3NF)
BC范式(BCNF)
第四范式(4NF)
第五范式(5NF)
各种范式之间存在联系：

某一关系模式R为第n范式，可简记为R∈nNF。
一个低一级范式的关系模式，通过模式分解可以转换为若干个高一级范式的关系模式的集合，这种过程就叫规范化
6.2.4 2NF
1NF的定义
如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF
2NF 的定义
定义6.6 若R∈1NF，且每一个非主属性完全函数依赖于码，则R∈2NF。
6.2.5 3NF
3NF 的定义
定义6.7 关系模式R 中若不存在这样的码X、属性组Y及非主属性Z（Z Í Y）, 使得X→Y，Y→Z成立，
Y → X，则称R ∈ 3NF。
若R∈3NF ，则每一个非主属性既不部分依赖于码也不传递依赖于码。
6.2.6 BC 范式（BCNF ）
定义6.8 关系模式R∈1NF ，若X→Y 且Y Í X 时X 必含有码，则R ∈BCNF 。
等价于：每一个决定属性因素都包含码
关系模式规范化的基本步骤
1NF
↓ 消除非主属性对码的部分函数依赖
消除决定属性 2NF
集非码的非平 ↓ 消除非主属性对码的传递函数依赖
凡函数依赖 3NF
↓ 消除主属性对码的部分和传递函数依赖
BCNF
↓ 消除非平凡且非函数依赖的多值依赖
4NF
不能说规范化程度越高的关系模式就越好
在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式
上面的规范化步骤可以在其中任何一步终止

第七章 数据库设计
7.1 数据库设计概述
什么是数据库设计
数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）
在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。
7.1.1 数据库和信息系统
数据库是信息系统的核心和基础
数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在
数据库设计是信息系统开发和建设的重要组成部分
7.1.2 数据库设计的特点
数据库设计应该与应用系统设计相结合
结构（数据）设计：设计数据库框架或数据库结构
行为（处理）设计：设计应用程序、事务处理等
数据库各级模式的形成过程(P205图7.4)
需求分析阶段
概念设计阶段
逻辑设计阶段
物理设计阶段
7.2 需求分析
7.2.1 需求分析的任务
一、需求分析的任务
通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求
在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库
二、需求分析的重点
需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。
三、需求分析的难点
确定用户最终需求的难点
用户缺少计算机知识，开始时无法确定计算机究竟能为自己做什么，不能做什么，因此无法一下子准确地表达自己的需求，他们所提出的需求往往不断地变化。
设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。
设计人员必须采用有效的方法，与用户不断深入地进行交流，才能逐步得以确定用户的实际需求
7.2.2 需求分析的方法
一、调查与初步分析用户需求
⑴调查组织机构情况
⑵调查各部门的业务活动情况。调查重点之一。
⑶在熟悉业务活动的基础上，协助用户明确对新系统的各种要求。调查重点之二。
⑷对前面调查的结果进行初步分析
二、常用调查方法
⑴跟班作业
⑵开调查会
⑶请专人介绍
⑷询问
⑸设计调查表请用户填写
⑹查阅记录
三、进一步分析和表达用户需求
自顶向下的结构化分析方法（Structured Analysis，简称SA方法）
四、需求分析小结
P207图7.6
实例：假设我们要开发一个学校管理系统。
1．经过可行性分析和初步需求调查，抽象出该系统最高层数据流图，该系统由教师管理子系统、学生管理子系统、后勤管理子系统组成，每个子系统分别配