前言

关系数据库的规范化理论为：关系数据库中的每一个关系都要满足一定的规范。根据满足规范的条件不同，可以分为5个等级：第一范式 （1NF）、第二范式（2NF）....第五范式（5NF）。其中，NF是Normal Form的缩写。一般情况下，只要把数据规范到第三范式标准就可以满足需要。</font>

一、完全依赖、部分依赖、传递依赖

在了解关系数据库规范化之前，我们需要先了解函数依赖的定义

1.函数依赖

定义：设X、Y是关系R的两个属性集合，当任何时刻R中的任意两个元组中的X属性值相同时，则它们的Y属性值也相同，则称X函数决定Y，或Y函数依赖于X。

通俗的讲，如果知道一个人的身份证号，就一定能知道这个人的姓名，姓名依赖于身份证号，这就是函数依赖。

从性质上，函数依赖还可以分为完全函数依赖、部分函数依赖和传递函数依赖。

1.1完全函数依赖

设X,Y是关系R的两个属性集合，X'是X的真子集，存在X → Y（Y函数依赖于）,但对每一个X'都有X' !→ Y（Y不能函数依赖于X'），则称Y完全函数依赖于X，

也就是说，X的任何真子集，都不能被Y函数依赖，反之，Y函数能依赖于A的真子集，则称Y部分函数依赖于X

1.2部分函数依赖

设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

1.3传递函数依赖

设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X

二、关系数据库的规范化

了解了函数依赖的定义，下面我们开始学习关系数据库的规范化

1.第一范式（1NF）

第一范式是指数据库表的每一列都是不可分割的基本数据项。第一范式是第二范式和第三范式的基础，是最基本的范式。如果不满足第一范式，那这个数据库就不是关系数据库。

2.第二范式（2NF）

第二范式是在第一范式的基础上建立起来的，即满足第二范式必先满足第一范式。第二范式要求：数据库表中的每个实体（即各个记录行）必须可以被唯一地区分。实体的属性完全依赖于主关键字或主键，即不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

主键：为实现区分各行记录，需要为表设置一个“区分列”，用于存储唯一标识。例如学生信息表，设置“学号列”，由于每个学生编号都唯一，因此每个学生都可以被唯一区分（即使存在重名情况），这个唯一属性列被称为主关键字或主键。

3.第三范式（3NF）

第三范式是在第二范式的基础上建立起来的，满足第三范式必先满足第二范式。第三范式要求关系表不存在非关键字列队任意候选关键字列的传递函数依赖，也就是说，第三范式要求一个关系表中不包含已在其他表中包含的非主关键字。

例如：如S1（SNO，SNAME，CNO，CNAME，LOCATION） 各属性分别代表学号，姓名，所在年级，班级，家庭地址。

关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性CNO，CNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。

原因：关系中存在传递依赖造成的。即SNO -> CNO。 而CNO -> SNO却不存在，CNO -> LOCATION, 因此关键字 SNO 对 LOCATION 函数决定是通过传递依赖 CNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。

解决方法：分为两个关系 S（SNO，SNAME，CNO），C（CNO，CNAME，LOCATION）

三、关系数据库的设计和设计原则

学习完规范化，我们可以自己来设计一个关系数据库，但是在设计之前，我们要先了解数据库中会出现的异常。

1.数据冗余

数据冗余是指一个属性存放在多个表中，比如学生学号，可能存在于成绩单中，也会存在考勤表中，这其实会影响数据的完整性和一致性。如果其中一个表出现错误，可能会导致其他功能的查询都会有问题。当数据有冗余现象时，就可能会出现插入异常、删除异常、修改异常。

1.1 插入异常

插入异常是指插入的数据违反了数据库对象的规定，导致插入不正确的异常。比如一个表中有三个属性，而插入过程中你写了四个属性，数据就插入不进去。当设置的某字段为非空字段，给这个字段插入了一个空值，同样也会出现插入错误。

1.2 删除异常

当需要删除某个字段时，数据不能被删除导致的错误。比如表中有外键限制，删除数据就会出现错误。

1.3 修改异常

当你更新数据时，数据不能被更新而导致的错误。比如更新一个自增列，数据库就会提示更新失败。

2. 设计原则

数据库设计是指对一个给定的应用环境，根据用户的需求，利用数据模型和应用程序模拟现实世界中该应用环境的数据结构好处理活动的过程。

原则：

1. 数据库内数据文件的数据组织应获得最大限度的共享、最小的冗余度，消除数据及数据依赖关系中的冗余部分，使依赖于同一个数据模型的数据达到有效的分离。

2. 保证输入、修改数据时数据的一致性与正确性。

3. 保证数据与使用数据的应用程序之间的高度独立性。

四、体系结构

1.数据库三级模式结构

数据库三级模式结构是指模式、外模式、内模式

1.1 模式

模式也称逻辑模式或概念模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。一个数据库只有一个模式。模式处于三级结构的中间层。

**注意**：定义模式时，不仅要定义数据的逻辑结构，而且要定义数据之间的联系，定义域数据有关的安全性、完整性要求。

1.2 外模式

外模式也成用户模式，是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，

是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。外模式是模式的子集，一个数据库可以有多个外模式。外模式是保证数据安全性的一个有力措施。

1.3 内模式

内模式也称存储模式，是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。一个数据库只有一个内模式。

2.三级模式之间的映射

为了能够在内部实现数据库的3个抽象层次的联系和转换，数据库管理系统在三级模式之间提供了两层映射，分别是**外模式\模式映射**和**模式\内模式映射**

2.1 外模式\模式映射

对于同一个模式可以有任意多个外模式。对于每一个外模式，数据库系统都有一个外模式\模式映射。当模式改变时，由数据库管理员对各个外模式\模式映射做相应的改变，可以使外模式\模式映射保持不变，这样，根据数据外模式编写的应用程序就不用修改，保证了数据和程序的逻辑独立性。

2.2 模式\内模式映射

数据库中只有一个模式和一个内模式，所以模式\内模式映射是唯一的，它定义了数据库的全局逻辑结构与存储结构之间的对应关系。当数据库的存储结构改变时，由数据库管理员对模式\内模式映射做相应改变，可以使模式保持不变，应用程序也不做变动。这样保证了数据与程序的物理独立性。