第三篇 数据库技术
第一章 数据库概述
第二章 关系数据库
第三章 关系数据库标准语言 SQL
第四章 关系数据库设计
第五章 数据库应用系统的设计与实现第二章 关系数据库
2.1 关系模型
2.2 关系模式
2.3 关系数据库规范化
小结关系数据库简介
系统而严格地提出关系模型的是美国 IBM 公司的
E.F.Codd
1970年提出关系数据模型
之后,提出了关系代数和关系演算的概念
1972年提出了关系的第一,第二,第三范式
1974年提出了关系的 BC范式
关系数据库应用数学方法来处理数据库中的数据
80年代后,关系数据库系统成为最重要,最流行的数据库系统
2.1 关系模型概述
关系数据库系统
是支持关系模型的数据库系统
关系模型的组成
关系数据结构
关系操作集合
关系完整性约束关系模型
关系型数据库的特点；
模型简单、数据独立性高、有较为坚实的理论基础
关系,有应用语义的二维表，表中的每一行描述事物或事物的一部分的状态的数据，表中的每一列描述事物的某个特征
属性,二维表中的一列就是关系模式中的一个属性。 注：
表中的每一个属性必须是基本类型。
表中的每一列的所有值必须是同类型、同语义的
属性的值只能是域中的值
表中的每一列都必须有唯一的名字，列在表中的顺序是不重要的
1.域,属性的取值范围 。
2.元组,二维表中的一行称为一个元组 。
3.候选码,关系中按应用语义能唯一标识元组的最小的属性集合 。
4.主码,指定为关系中元组标识的候选码,称主码属性组为主属性 。
主码有时也被称为主关键字或主键 。
1,关系数据结构
数据的逻辑结构 ----二维表
从用户角度,关系模型中数据的逻辑结构是一张二维表 。
数据模式：对数据的结构、类型和约束的描述。（ 关系模式 ）
关系模式：
关系名 (属性 1，属性
2,…,属性 n)
例：学生（ 学号,姓名，
性别，年龄，班号）
主关键字：学号学生登记表
1,关系数据结构
单一的数据结构 ----关系
在关系模型中,实体以及实体间的联系都是用关系来表示的 。
例：
学生（学号，姓名，性别，年龄，
班号）
课程（课程号，课程名，周学时，
学分）
选修 （学号，课程号，成绩）
课程选修学生
m
n
成绩
2,关系操作集合
1) 常用的关系操作
查询
选择,投影,连接,除,并,交,差
数据更新
插入,删除,修改
查询的表达能力是其中最主要的部分关系操作集合（续）
2) 关系操作的特点
集合操作方式,即操作的对象和结果都是集合 。
非关系数据模型的数据操作方式：一次一记录
文件系统的数据操作方式关系操作集合（续）
3) 关系数据语言的种类
关系代数,用对关系的运算来表达查询要求的方式。
（过程性的：既要知道要做什么，还要知道怎么做 ）
关系演算,用谓词来表达查询要求
（非过程性：是一种可以不必知道如何获得结果就能表达所要结果的语言。 ）
面向转化的语言,用关系表示的输入数据转换成用单个关系表示的结果。（非过程性化的语言，如,SQL）
按例子查询 /按窗体查询,由于带有图形界面，用户可以见到一个或多个关系的具体样例。（如,Access）
关系操作集合（续）
4) 关系数据语言的特点
关系语言是一种高度非过程化的语言
能够嵌入高级语言中使用
3,关系的三类完整性约束
实体完整性
通常由关系系统自动支持确保表中所有行的数据不重复（ 主属性不能取空值。）
例,选修（ 学号，课程号,成绩）
,学号、课程号,为主码，则两个属性都不能取空值。
关系的完整性 是指关系中数据值与其描述的应用对象实际状态保证一致的约束条件
3,关系的三类完整性约束引用完整性,
确保关联之间数据的一致性，即确保进入一个表的数据与相关的表之间数据同步。
例,学生实体、专业实体以及专业与学生间的一对多联系学生 （ 学号,姓名,性别,专业号,年龄 ）
专业 （ 专业号,专业名 ）
外键 （或叫外部关键字）是指一个表中的某个属性是另一个表的主关键字。
3,关系的三类完整性约束应用语义完整性：
确保数据库中的数据是有意义的。
一般用数据类型和约束来保证 。
用户定义后由系统支持
例：性别 （ 男 /女 ）
关系的完整性－ 实例
修课表中不允许出现,学生,表中没有的学号,同时也不允许出现,课程,
表中没有的课程号,修课表中,学号,的值是在学生表的,学号,的值的子集 。 修课表中的,课程号,的值也必须是课程表中,课程号,的子集 。 可以通过定义外键来实现,定义修课表中的学号是学生表的外键,修课表中的课程号是课程表的外键 。 注意是先有主关键字值,后有外键值学号 姓名 年龄
课程号 课程名
学号 课程号 成绩
学生情况表 课程表 学生修课表主关键字
2.2 关系模式关系概念模式关系内模式关系外模式两级映像
1、关系概念模式
关系概念模式主要包括出现在 DB中的每个关系的说明，它包括对 关系名、属性名和属性取值范围 (类型 )的说明。
在关系数据模型中 可不说明关系与关系间的联系 。关系与关系间的联系是 通过连接属性实现 的。
概念模式由 DBMS提供的 数据定义语言 （ DDL ）
来定义和描述。
班级与学生关系说明例,有如下两个关系：
班级 (班级号,班级名，人数 ),学生 (学号姓名，性别，年龄,班级号 )
相应属性取值类型和宽度如右表所示
create table 学生 (学号 char(6) primary key,姓名 char(6),性别 char(2),年龄 smallint,班级号
char(6)）,constraint pk_ks3 foreign key(班级号 ) references 班级 (班级号 ))；
2.关系内模式
从原理上讲，关系内模式与其他类型 DBS的内模式没有什么不同,RDB中的每个基本表都应对应一个存储文件。
基于主关键字进行直接存取，一般可根据主关键字建立相应索引。
在关系内模式中不用说明存储文件,存储文件的说明 由 RDBMS
根据基本表的定义 自动映射产生 。
在关系内模式主要内容中 要说明的是索引 。
内模式由 DBMS提供的 数据定义语言（ DDL ） 来定义和描述。
学生：按学号升序创建惟一的聚簇索引；
create unique clustered index idx_xh on 学生 (学号 )；
3.关系外模式
外模式是概念模式的逻辑子集，是用户与 DBS的接口，
是对用户所用到的那部分数据的描述。
如：窗体、查询等
在 RDB中，外模式被称作视图 (VIEW)。
外模式由 DBMS提供的 DDL来定义和描述。
例：在学生管理 DB中，建立 01001班学生的视图 VIEW_01001，其结构包括学号，姓名，年龄，班级号。
create view view_01001
as select 学号,姓名,年龄,班级号
from 学生
where 班级号＝ ′01001′；
4.两级映像
DBS的三级模式是对数据进行三个级别的抽象，使用户能逻辑地抽象地处理数据，而不必关心数据在机器中的具体表示方式和存储方式。
为实现三个抽象级别的联系和转换,DBMS提供两个层次的映像：
⑴ 外模式 /概念模式映像
⑵ 概念模式 /内模式映像映像,
是一种对应规则，它指出了映像双方是如何进行转换的。
定义各外模式与概念模式间的映像关系。
对应于同一个概念模式可有多个外模式,每个外模式,DBS都有一个外模式 /概念模式映像,它定义了该外模式与概念模式间的对应关系。
映像定义常在各自的外模式中加以描述。
⑴ 外模式 /概念模式映像
定义 DB全局逻辑结构与存储结构间的对应关系。
因这两级的数据结构可能不一致，即记录类型、字段类型的命名和组成可能不一样，故该映像说明概念记录和内部记录间的对应性。
概念模式 /内模式映像一般是在内模式中加以描述。
⑵ 概念模式 /内模式映像两级数据独立性
⑴ 物理数据独立性
若修改 DB的内模式 (DB的物理结构有所变化 ),则只修改概念模式 /内模式映像即可 。
可使概念模式尽可能保持不变,即对内模式的修改尽量不影响概念模式,对外模式和应用程序的影响则更小 。
⑵ 逻辑数据独立性
若修改 DB的概念模式 (增加记录类型或增加数据项 ),则只修改外模式 /概念模式映像,可使外模式和应用程序尽可能保持不变。
DB三级模式体系结构是数据管理的结构框架,按照其组织的数据是 DB的内容。
设计 DB时,主要是定义 DB的各级模式 ;在用户使用 DB
时,关心的是 DB的内容。
DB的模式通常是相对稳定的,而 DB的数据则是经常变化的。
DB分级结构图应用程序 A 应用程序 B 应用程序 C
外模式 外模式内模式模式外模式 /模式映射模式 /内模式映射外模式 /模式映射
DBMS
用户 用户 用户
2.3 关系模式的规范化关系模式规范化的必要性数值依赖关系的规范化
关系模式重要性原因：
它可用来表达独立于 DBMS的设计
规范化：
是把有问题的关系转化为两个或多个没有这些问题的关系的过程
关系模式好的标准 —— 规范化形式（范式）
范式,规定关系模式应满足的特定限制，分不同等级：
第一范式 (1NF)
第二范式 (2NF)
第三范式 (3NF)
BC范式、第四范式 (4NF)、第五范式 (5NF)
范式越高规范化程度越高，关系模式越好。
1,关系模式规范化的必要性关系模式规范化的必要性
更新异常,在删除关于一个实体的事实的同时，
还无意识地删除了关于另外一个实体的事实
插入异常,必须定要等到有一个 事实之后才能有关于与事实相关的另一事实的记录
解决方案,把一个关系分解成多个关系，每个关系处理一个不同的主题，
来消除更新异常和插入异常。分解关系时，同时注意多个关系之间的相互参照性学号 课程 课程 学分
10 0 人工智能 人工智能 3
12 5 文化学 文化学 2
15 0 市场营销 市场营销 2
17 5 人工智能 人工智能 2
19 0 文化学 文化学 2
（ a ）学生选课表 （ b ）课程学分表学号 课程 学分
1 0 0 人工智能 3
1 2 5 文化学 2
1 5 0 市场营销 2
1 7 5 人工智能 2
1 9 0 文化学 2
学生选课表学生 -选课、课程－学分关系表把原来的表分成两个新表关系模式可能出现的问题 实 例
如果一个关系没有经过规范化，可能会出现数据冗余大、
数据更新造成不一致、数据插入异常和删除异常。
例,学生关系存在的问题：数据冗余 (系主任名 )、更新异常 (换系主任 )、插入异常 (系没有招生系主任不能插入 )、删除异常 (学生毕业 )。
模式分解是关系规范化的主要方法
对于有问题的关系模式，可通过 模式分解 的方法使之规范化。
学生关系可分解为以下三个关系：
学生（ 学号,姓名，所在系）
系（ 所在系,系主任姓名）
考试（ 学号，课程名,成绩）
新关系克服了 学生关系存在的问题，更加合理和实用。
如何分解,涉及两个概念 —— 关键字、函数依赖
DB中出现的数据异常现象与数据依赖有着紧密的关联。
认识和掌握函数依赖知识，对于 DB的约束设计和规范化设计具有重要意义。
2,函数依赖函数依赖 是关系属性之间的一种联系 。 它说明,如果给定了一个属性的值,就可以获得另一个属性的值
例：如下表所示，知道了
,课程名,的值，即可知道
,授课学时,的值。称,授课学时,函数依赖于,课程名,,或,课程名,可以决定,授课学时,。记作课程名 → 授课学时，反之不成立。
课程号 课程名 授课学时 授课学期
J 0 0 1 数据库 72 6
J 0 0 3 C 程序设计 54 2
Z 0 0 4 操作系统 72 5
Z 0 0 6 编译原理 72 6
X 0 0 1 数值分析 54 3
X 0 0 2 面向对象 36 4
课程表
2,函数依赖
部分函数依赖：,学分,函数依赖于主关键字 {学号,课程 }。 但决定,学分,的只是,课程,,与,学号,无关 。
传递函数依赖：
学生住宿的楼号依赖于学号，学生应交的住宿费是由楼号决定的，即,收费,依赖于,楼号,,,楼号,依赖于,学号,,而,收费,又依赖于
,楼号,
学号 课程 学分
1 0 0 人工智能 3
1 2 5 文化学 2
1 5 0 市场营销 2
1 7 5 人工智能 2
1 9 0 文化学 2
学生选课表 （有部分依赖）
学号 楼号 收费
1 0 0 2 5 0 0
1 2 0 4 6 0 0
1 3 0 2 5 0 0
1 5 0 8 8 0 0
1 8 0 2 5 0 0
学生住宿收费表（有传递依赖的关系 ）
主关键字
3,关系的规范化
范式 是符合某一种级别的关系模式的集合。
关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。
范式的种类：
第一范式 (1NF)
第二范式 (2NF)
第三范式 (3NF)
BC范式 (BCNF)
第四范式 (4NF)
第五范式 (5NF)
规范化理论 正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、
更新异常和数据冗余问题。
NF5NF4B C N FNF3NF2NF1
各种范式之间存在联系：
第一范式 (1NF)
1NF,若一个关系模式 R的 所有属性都是不可分的 基本数据项，则该关系属于 1NF 。
关系模式必须是满足 1NF。
满足 1NF的关系模式并不一定是好的关系模式。
例如：学生 (学号，姓名，所在系，系主任姓名，课程名，成绩 )
存在插入异常、删除异常、更新异常和数据冗余问题第二范式 (2NF)
若关系模式 R属于 1NF，且 每个非主属性不存在部分函数依赖于主关键字,则 R属于 2NF 。
例,学生 (学号,姓名，所在系，系主任姓名,课程名,成绩 )
学生关系模式存在部分依赖：
(学号，课程名 )→ 姓名 (学号，课程名 )→ 所在系
(学号，课程名 )→ 系主任姓名
故不属于 2NF。
对学生关系模式进行分解，使其满足 2NF的条件，即要 消除非主属性对主关键字的部分依赖。
学生关系模式分解成：
学生 -系 (学号,姓名，所在系，系主任姓名 )
考试 (学号，课程名,成绩 ) 学生 -系、考试属于 2NF
第三范式 (3NF)
将学生 -系 (学号,姓名，所在系，系主任姓名 )
关系模式分解为：
学生 (学号，姓名，所在系 )
系 (所在系，系主任姓名 )
关系模式学生与系均已满足 3NF。
3NF是一个可用的关系模式应满足的最低范式。
若关系模式 R属于 1NF，且每个 非主属性都不传递依赖于主关键字,则 R属于 3NF。
学号 楼号 楼号 收费
1 0 0 2 2 5 0 0
1 2 0 4 4 6 0 0
1 3 0 2 2 5 0 0
1 5 0 8 8 8 0 0
1 8 0 2 2 5 0 0
分析：有传递依赖的关系 消除传递依赖后的关系消除传递依赖前后两个关系符合第三范式学号 楼号 收费
1 0 0 2 5 0 0
1 2 0 4 6 0 0
1 3 0 2 5 0 0
1 5 0 8 8 0 0
1 8 0 2 5 0 0
例：右表为学生住宿收费，设不同楼号的收费不同。问学生住宿收费（学号，楼号，收费）是否有更新异常？若有，应如何消除？
规范化的基本思想
消除不合适的数据依赖
采用,一事一地,的模式设计原则让一个关系描述一个概念、一个实体或者实体间的一种联系。若多于一个概念就把它,分离,出去
在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式
上面的规范化步骤可以在其中任何一步终止设计折中
规范化可以消除更新异常，但有时并不值得,有时分解前的非规范化的表可能更好，因为处理起来比较容易
关系有时故意保留成非规范化的，或者规范化后又反规范化了，这样做通常是为了改善性能。将关系分解到什么程度，要根据实际情况来决定
例,客户编号 → 邮政编码,邮政编码 → （省，城市），
该关系可以分解为如下两个关系：
客户 （ 客户编号,客户名称,邮政编码 ）,其中,,客户编号,主关键字 。
编码 （ 邮政编码,省,城市 ）,其中,,邮政编码,是主关键字 。
两个关系都属于第三范式了,但这样做可能并不一定就是好的设计,如果用户经常需要查询及生成的报表包括,客户编号,客户名,省,城市和邮政编码,
则对此表不再进行分解就比较合适
F={N#→NA,N#→AD,N#→AN#,AN#→ANN,EN#→ENN,(N#,EN#)→G}
R1(N#,NA,AD,AN#,ANN,N#→NA,N#→AD,N#→AN#,AN#→ANN)
R2(EN#,ENN,EN#→ENN) R3(N#,EN#,G,(N#,EN#)→G)
将 R1分解为 R11和 R12两个模式，即
R11(N#,NA,AD,AN#,N#→NA,N#→AD,N#→AN#)
R12(AN#,ANN,AN#→ANN)
关系的规范化过程非规范化关系
1 N F
2 N F
3 N F
B C N F
4 N F
5 N F
消去重复组消除非主属性对主属性的部分函数依赖消除非主属性对主属性的传递函数依赖消除主属性间的部分和传递函数依赖消除多值依赖消除连接依赖
关系模型的基本概念，关系数据结构、关系操作、关系完整性约束的概念；
关系模式的概念，以及关系概念模式、内模式与外模式的概念及其描述；
RDB规范化理论，关系模式规范化的必要性，函数依赖的概念
1NF,2NF,3NF的概念与它们之间的关系，以及 如何将一个非第一范式规范成 3NF
小 结
第一章 数据库概述
第二章 关系数据库
第三章 关系数据库标准语言 SQL
第四章 关系数据库设计
第五章 数据库应用系统的设计与实现第二章 关系数据库
2.1 关系模型
2.2 关系模式
2.3 关系数据库规范化
小结关系数据库简介
系统而严格地提出关系模型的是美国 IBM 公司的
E.F.Codd
1970年提出关系数据模型
之后,提出了关系代数和关系演算的概念
1972年提出了关系的第一,第二,第三范式
1974年提出了关系的 BC范式
关系数据库应用数学方法来处理数据库中的数据
80年代后,关系数据库系统成为最重要,最流行的数据库系统
2.1 关系模型概述
关系数据库系统
是支持关系模型的数据库系统
关系模型的组成
关系数据结构
关系操作集合
关系完整性约束关系模型
关系型数据库的特点；
模型简单、数据独立性高、有较为坚实的理论基础
关系,有应用语义的二维表，表中的每一行描述事物或事物的一部分的状态的数据，表中的每一列描述事物的某个特征
属性,二维表中的一列就是关系模式中的一个属性。 注：
表中的每一个属性必须是基本类型。
表中的每一列的所有值必须是同类型、同语义的
属性的值只能是域中的值
表中的每一列都必须有唯一的名字，列在表中的顺序是不重要的
1.域,属性的取值范围 。
2.元组,二维表中的一行称为一个元组 。
3.候选码,关系中按应用语义能唯一标识元组的最小的属性集合 。
4.主码,指定为关系中元组标识的候选码,称主码属性组为主属性 。
主码有时也被称为主关键字或主键 。
1,关系数据结构
数据的逻辑结构 ----二维表
从用户角度,关系模型中数据的逻辑结构是一张二维表 。
数据模式：对数据的结构、类型和约束的描述。（ 关系模式 ）
关系模式：
关系名 (属性 1，属性
2,…,属性 n)
例：学生（ 学号,姓名，
性别，年龄，班号）
主关键字：学号学生登记表
1,关系数据结构
单一的数据结构 ----关系
在关系模型中,实体以及实体间的联系都是用关系来表示的 。
例：
学生（学号，姓名，性别，年龄，
班号）
课程（课程号，课程名，周学时，
学分）
选修 （学号，课程号，成绩）
课程选修学生
m
n
成绩
2,关系操作集合
1) 常用的关系操作
查询
选择,投影,连接,除,并,交,差
数据更新
插入,删除,修改
查询的表达能力是其中最主要的部分关系操作集合（续）
2) 关系操作的特点
集合操作方式,即操作的对象和结果都是集合 。
非关系数据模型的数据操作方式：一次一记录
文件系统的数据操作方式关系操作集合（续）
3) 关系数据语言的种类
关系代数,用对关系的运算来表达查询要求的方式。
（过程性的：既要知道要做什么，还要知道怎么做 ）
关系演算,用谓词来表达查询要求
（非过程性：是一种可以不必知道如何获得结果就能表达所要结果的语言。 ）
面向转化的语言,用关系表示的输入数据转换成用单个关系表示的结果。（非过程性化的语言，如,SQL）
按例子查询 /按窗体查询,由于带有图形界面，用户可以见到一个或多个关系的具体样例。（如,Access）
关系操作集合（续）
4) 关系数据语言的特点
关系语言是一种高度非过程化的语言
能够嵌入高级语言中使用
3,关系的三类完整性约束
实体完整性
通常由关系系统自动支持确保表中所有行的数据不重复（ 主属性不能取空值。）
例,选修（ 学号，课程号,成绩）
,学号、课程号,为主码，则两个属性都不能取空值。
关系的完整性 是指关系中数据值与其描述的应用对象实际状态保证一致的约束条件
3,关系的三类完整性约束引用完整性,
确保关联之间数据的一致性，即确保进入一个表的数据与相关的表之间数据同步。
例,学生实体、专业实体以及专业与学生间的一对多联系学生 （ 学号,姓名,性别,专业号,年龄 ）
专业 （ 专业号,专业名 ）
外键 （或叫外部关键字）是指一个表中的某个属性是另一个表的主关键字。
3,关系的三类完整性约束应用语义完整性：
确保数据库中的数据是有意义的。
一般用数据类型和约束来保证 。
用户定义后由系统支持
例：性别 （ 男 /女 ）
关系的完整性－ 实例
修课表中不允许出现,学生,表中没有的学号,同时也不允许出现,课程,
表中没有的课程号,修课表中,学号,的值是在学生表的,学号,的值的子集 。 修课表中的,课程号,的值也必须是课程表中,课程号,的子集 。 可以通过定义外键来实现,定义修课表中的学号是学生表的外键,修课表中的课程号是课程表的外键 。 注意是先有主关键字值,后有外键值学号 姓名 年龄
课程号 课程名
学号 课程号 成绩
学生情况表 课程表 学生修课表主关键字
2.2 关系模式关系概念模式关系内模式关系外模式两级映像
1、关系概念模式
关系概念模式主要包括出现在 DB中的每个关系的说明，它包括对 关系名、属性名和属性取值范围 (类型 )的说明。
在关系数据模型中 可不说明关系与关系间的联系 。关系与关系间的联系是 通过连接属性实现 的。
概念模式由 DBMS提供的 数据定义语言 （ DDL ）
来定义和描述。
班级与学生关系说明例,有如下两个关系：
班级 (班级号,班级名，人数 ),学生 (学号姓名，性别，年龄,班级号 )
相应属性取值类型和宽度如右表所示
create table 学生 (学号 char(6) primary key,姓名 char(6),性别 char(2),年龄 smallint,班级号
char(6)）,constraint pk_ks3 foreign key(班级号 ) references 班级 (班级号 ))；
2.关系内模式
从原理上讲，关系内模式与其他类型 DBS的内模式没有什么不同,RDB中的每个基本表都应对应一个存储文件。
基于主关键字进行直接存取，一般可根据主关键字建立相应索引。
在关系内模式中不用说明存储文件,存储文件的说明 由 RDBMS
根据基本表的定义 自动映射产生 。
在关系内模式主要内容中 要说明的是索引 。
内模式由 DBMS提供的 数据定义语言（ DDL ） 来定义和描述。
学生：按学号升序创建惟一的聚簇索引；
create unique clustered index idx_xh on 学生 (学号 )；
3.关系外模式
外模式是概念模式的逻辑子集，是用户与 DBS的接口，
是对用户所用到的那部分数据的描述。
如：窗体、查询等
在 RDB中，外模式被称作视图 (VIEW)。
外模式由 DBMS提供的 DDL来定义和描述。
例：在学生管理 DB中，建立 01001班学生的视图 VIEW_01001，其结构包括学号，姓名，年龄，班级号。
create view view_01001
as select 学号,姓名,年龄,班级号
from 学生
where 班级号＝ ′01001′；
4.两级映像
DBS的三级模式是对数据进行三个级别的抽象，使用户能逻辑地抽象地处理数据，而不必关心数据在机器中的具体表示方式和存储方式。
为实现三个抽象级别的联系和转换,DBMS提供两个层次的映像：
⑴ 外模式 /概念模式映像
⑵ 概念模式 /内模式映像映像,
是一种对应规则，它指出了映像双方是如何进行转换的。
定义各外模式与概念模式间的映像关系。
对应于同一个概念模式可有多个外模式,每个外模式,DBS都有一个外模式 /概念模式映像,它定义了该外模式与概念模式间的对应关系。
映像定义常在各自的外模式中加以描述。
⑴ 外模式 /概念模式映像
定义 DB全局逻辑结构与存储结构间的对应关系。
因这两级的数据结构可能不一致，即记录类型、字段类型的命名和组成可能不一样，故该映像说明概念记录和内部记录间的对应性。
概念模式 /内模式映像一般是在内模式中加以描述。
⑵ 概念模式 /内模式映像两级数据独立性
⑴ 物理数据独立性
若修改 DB的内模式 (DB的物理结构有所变化 ),则只修改概念模式 /内模式映像即可 。
可使概念模式尽可能保持不变,即对内模式的修改尽量不影响概念模式,对外模式和应用程序的影响则更小 。
⑵ 逻辑数据独立性
若修改 DB的概念模式 (增加记录类型或增加数据项 ),则只修改外模式 /概念模式映像,可使外模式和应用程序尽可能保持不变。
DB三级模式体系结构是数据管理的结构框架,按照其组织的数据是 DB的内容。
设计 DB时,主要是定义 DB的各级模式 ;在用户使用 DB
时,关心的是 DB的内容。
DB的模式通常是相对稳定的,而 DB的数据则是经常变化的。
DB分级结构图应用程序 A 应用程序 B 应用程序 C
外模式 外模式内模式模式外模式 /模式映射模式 /内模式映射外模式 /模式映射
DBMS
用户 用户 用户
2.3 关系模式的规范化关系模式规范化的必要性数值依赖关系的规范化
关系模式重要性原因：
它可用来表达独立于 DBMS的设计
规范化：
是把有问题的关系转化为两个或多个没有这些问题的关系的过程
关系模式好的标准 —— 规范化形式（范式）
范式,规定关系模式应满足的特定限制，分不同等级：
第一范式 (1NF)
第二范式 (2NF)
第三范式 (3NF)
BC范式、第四范式 (4NF)、第五范式 (5NF)
范式越高规范化程度越高，关系模式越好。
1,关系模式规范化的必要性关系模式规范化的必要性
更新异常,在删除关于一个实体的事实的同时，
还无意识地删除了关于另外一个实体的事实
插入异常,必须定要等到有一个 事实之后才能有关于与事实相关的另一事实的记录
解决方案,把一个关系分解成多个关系，每个关系处理一个不同的主题，
来消除更新异常和插入异常。分解关系时，同时注意多个关系之间的相互参照性学号 课程 课程 学分
10 0 人工智能 人工智能 3
12 5 文化学 文化学 2
15 0 市场营销 市场营销 2
17 5 人工智能 人工智能 2
19 0 文化学 文化学 2
（ a ）学生选课表 （ b ）课程学分表学号 课程 学分
1 0 0 人工智能 3
1 2 5 文化学 2
1 5 0 市场营销 2
1 7 5 人工智能 2
1 9 0 文化学 2
学生选课表学生 -选课、课程－学分关系表把原来的表分成两个新表关系模式可能出现的问题 实 例
如果一个关系没有经过规范化，可能会出现数据冗余大、
数据更新造成不一致、数据插入异常和删除异常。
例,学生关系存在的问题：数据冗余 (系主任名 )、更新异常 (换系主任 )、插入异常 (系没有招生系主任不能插入 )、删除异常 (学生毕业 )。
模式分解是关系规范化的主要方法
对于有问题的关系模式，可通过 模式分解 的方法使之规范化。
学生关系可分解为以下三个关系：
学生（ 学号,姓名，所在系）
系（ 所在系,系主任姓名）
考试（ 学号，课程名,成绩）
新关系克服了 学生关系存在的问题，更加合理和实用。
如何分解,涉及两个概念 —— 关键字、函数依赖
DB中出现的数据异常现象与数据依赖有着紧密的关联。
认识和掌握函数依赖知识，对于 DB的约束设计和规范化设计具有重要意义。
2,函数依赖函数依赖 是关系属性之间的一种联系 。 它说明,如果给定了一个属性的值,就可以获得另一个属性的值
例：如下表所示，知道了
,课程名,的值，即可知道
,授课学时,的值。称,授课学时,函数依赖于,课程名,,或,课程名,可以决定,授课学时,。记作课程名 → 授课学时，反之不成立。
课程号 课程名 授课学时 授课学期
J 0 0 1 数据库 72 6
J 0 0 3 C 程序设计 54 2
Z 0 0 4 操作系统 72 5
Z 0 0 6 编译原理 72 6
X 0 0 1 数值分析 54 3
X 0 0 2 面向对象 36 4
课程表
2,函数依赖
部分函数依赖：,学分,函数依赖于主关键字 {学号,课程 }。 但决定,学分,的只是,课程,,与,学号,无关 。
传递函数依赖：
学生住宿的楼号依赖于学号，学生应交的住宿费是由楼号决定的，即,收费,依赖于,楼号,,,楼号,依赖于,学号,,而,收费,又依赖于
,楼号,
学号 课程 学分
1 0 0 人工智能 3
1 2 5 文化学 2
1 5 0 市场营销 2
1 7 5 人工智能 2
1 9 0 文化学 2
学生选课表 （有部分依赖）
学号 楼号 收费
1 0 0 2 5 0 0
1 2 0 4 6 0 0
1 3 0 2 5 0 0
1 5 0 8 8 0 0
1 8 0 2 5 0 0
学生住宿收费表（有传递依赖的关系 ）
主关键字
3,关系的规范化
范式 是符合某一种级别的关系模式的集合。
关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。
范式的种类：
第一范式 (1NF)
第二范式 (2NF)
第三范式 (3NF)
BC范式 (BCNF)
第四范式 (4NF)
第五范式 (5NF)
规范化理论 正是用来改造关系模式，通过分解关系模式来消除其中不合适的数据依赖，以解决插入异常、删除异常、
更新异常和数据冗余问题。
NF5NF4B C N FNF3NF2NF1
各种范式之间存在联系：
第一范式 (1NF)
1NF,若一个关系模式 R的 所有属性都是不可分的 基本数据项，则该关系属于 1NF 。
关系模式必须是满足 1NF。
满足 1NF的关系模式并不一定是好的关系模式。
例如：学生 (学号，姓名，所在系，系主任姓名，课程名，成绩 )
存在插入异常、删除异常、更新异常和数据冗余问题第二范式 (2NF)
若关系模式 R属于 1NF，且 每个非主属性不存在部分函数依赖于主关键字,则 R属于 2NF 。
例,学生 (学号,姓名，所在系，系主任姓名,课程名,成绩 )
学生关系模式存在部分依赖：
(学号，课程名 )→ 姓名 (学号，课程名 )→ 所在系
(学号，课程名 )→ 系主任姓名
故不属于 2NF。
对学生关系模式进行分解，使其满足 2NF的条件，即要 消除非主属性对主关键字的部分依赖。
学生关系模式分解成：
学生 -系 (学号,姓名，所在系，系主任姓名 )
考试 (学号，课程名,成绩 ) 学生 -系、考试属于 2NF
第三范式 (3NF)
将学生 -系 (学号,姓名，所在系，系主任姓名 )
关系模式分解为：
学生 (学号，姓名，所在系 )
系 (所在系，系主任姓名 )
关系模式学生与系均已满足 3NF。
3NF是一个可用的关系模式应满足的最低范式。
若关系模式 R属于 1NF，且每个 非主属性都不传递依赖于主关键字,则 R属于 3NF。
学号 楼号 楼号 收费
1 0 0 2 2 5 0 0
1 2 0 4 4 6 0 0
1 3 0 2 2 5 0 0
1 5 0 8 8 8 0 0
1 8 0 2 2 5 0 0
分析：有传递依赖的关系 消除传递依赖后的关系消除传递依赖前后两个关系符合第三范式学号 楼号 收费
1 0 0 2 5 0 0
1 2 0 4 6 0 0
1 3 0 2 5 0 0
1 5 0 8 8 0 0
1 8 0 2 5 0 0
例：右表为学生住宿收费，设不同楼号的收费不同。问学生住宿收费（学号，楼号，收费）是否有更新异常？若有，应如何消除？
规范化的基本思想
消除不合适的数据依赖
采用,一事一地,的模式设计原则让一个关系描述一个概念、一个实体或者实体间的一种联系。若多于一个概念就把它,分离,出去
在设计数据库模式结构时，必须对现实世界的实际情况和用户应用需求作进一步分析，确定一个合适的、能够反映现实世界的模式
上面的规范化步骤可以在其中任何一步终止设计折中
规范化可以消除更新异常，但有时并不值得,有时分解前的非规范化的表可能更好，因为处理起来比较容易
关系有时故意保留成非规范化的，或者规范化后又反规范化了，这样做通常是为了改善性能。将关系分解到什么程度，要根据实际情况来决定
例,客户编号 → 邮政编码,邮政编码 → （省，城市），
该关系可以分解为如下两个关系：
客户 （ 客户编号,客户名称,邮政编码 ）,其中,,客户编号,主关键字 。
编码 （ 邮政编码,省,城市 ）,其中,,邮政编码,是主关键字 。
两个关系都属于第三范式了,但这样做可能并不一定就是好的设计,如果用户经常需要查询及生成的报表包括,客户编号,客户名,省,城市和邮政编码,
则对此表不再进行分解就比较合适
F={N#→NA,N#→AD,N#→AN#,AN#→ANN,EN#→ENN,(N#,EN#)→G}
R1(N#,NA,AD,AN#,ANN,N#→NA,N#→AD,N#→AN#,AN#→ANN)
R2(EN#,ENN,EN#→ENN) R3(N#,EN#,G,(N#,EN#)→G)
将 R1分解为 R11和 R12两个模式，即
R11(N#,NA,AD,AN#,N#→NA,N#→AD,N#→AN#)
R12(AN#,ANN,AN#→ANN)
关系的规范化过程非规范化关系
1 N F
2 N F
3 N F
B C N F
4 N F
5 N F
消去重复组消除非主属性对主属性的部分函数依赖消除非主属性对主属性的传递函数依赖消除主属性间的部分和传递函数依赖消除多值依赖消除连接依赖
关系模型的基本概念，关系数据结构、关系操作、关系完整性约束的概念；
关系模式的概念，以及关系概念模式、内模式与外模式的概念及其描述；
RDB规范化理论，关系模式规范化的必要性，函数依赖的概念
1NF,2NF,3NF的概念与它们之间的关系，以及 如何将一个非第一范式规范成 3NF
小 结
