1.2 关系数据库的基本理论

关系数据库具有坚实的理论基础，这一理论有助于关系数据库的设计和用户对数据库信息需求的有效处理。它涉及的内容包括模式的基本知识、关系数据库的标准语言SQL和关系数据理论，在本节中将对这些内容做简要的介绍。

1.2.1 数据库系统与关系数据库

数据库系统是指一个计算机存储记录的系统，它需要特定的软件和一系列硬件支持，并且利用数据库系统能够存储大量的数据记录，支持用户进行检索和更新所需的信息。数据库系统通常在企业应用或科学研究中用于对大量数据进行存储和分析，从而为实际应用提供帮助。

数据库系统的硬件设备主要包括：

※ 二级存储设备，以及相关的I/O设备、设备控制器等：最常用的存储设备为磁盘，数据库系统利用存储设备为数据记录提供物理存储空间。

※ 处理器以及相应的内存：足够快的CPU和足够大的内存，用于支持数据库系统软件的运行。

在物理数据库（即物理存储数据的存储设备）与数据库用户之间具有一个中间层，这就是数据库软件，通常称为“数据库管理系统（DBMS）”。DBMS是建立在操作系统的基础上的，对物理数据库进行统一的管理和控制。用户对数据库提出的访问请求都是由DBMS来处理的。DBMS还提供了许多数据操作的实用程序。

DBMS提供的基本功能为数据库用户屏蔽了数据库物理层的细节，使数据库管理员或者用户可以以更加高级的方式对物理数据进行管理和操作。另外，DBMS通常也指某个特定厂商的特定产品。例如，Oracle公司的Oracle 11g就是一个非常优秀的DBMS。

实际上，数据库系统经历了由层次模型到网状模型，再由网状模型到关系模型的发展过程，当今的数据库大部分都是支持关系模型的关系数据库。

关系数据库模型主要由三部分组成。

※ 数据结构：在关系数据库中，只有一种数据结构—关系。简单地说，关系就是一张二维表，而关系数据库就由许多表的集合。

※ 关系操作：关系操作的特点就是集合操作方式，即操作的对象和结果都是集合。

※ 完整性规则：完整性规则用于限制能够对数据和数据对象进行的关系操作，提供对数据和数据结构的保护。

1.2.2 关系数据库的逻辑模型

在关系数据库的设计阶段，需要为其建立逻辑模型。关系数据库的逻辑模型可以通过实体和关系组成的图来表示，这种图表称为E-R图，使用E-R图表示的逻辑模型称为ER模型。一个典型的ER模型由三部分组成—实体、属性和联系。

1. 实体和属性

客观存在并可相互区分的事物称为“实体”。实体可以指实际的对象，也可以指某些概念，例如，一个雇员、一个职位都是实体。在E-R模型中，实体用矩形表示，矩形框内写明实体名，以区分现实世界中的其他对象。

每个实体由一组属性来表示，其中的某一部分属性可以唯一标识实例，如雇员编号。实体集是具有相同属性的实体集合，例如，学校所有教师具有相同的属性，因此教师的集合可以定义为一个实体集；而学生具有相同的属性，因此学生的集合可以定义为另一个实体集。

在数据库中，每个实体集都对应于一个表，实体集中的每个实体都是表中的一条记录，而实体的每个属性就是表中的一个字段。例如，企业中的雇员、职位和部门可以分别定义为3个实体集，这些实体集分别对应表EMPLOYEES、JOBS和DEPARTMENTS。每个实体又具有它自己的属性，这些属性组成了表的字段。例如，雇员实体具有雇员编号、姓名、电话号码、职位、薪水、所属部门等属性。

2. 联系

实际应用中的实体之间是存在联系的，这种联系必须在逻辑模型中表示出来。在E-R模型中，联系用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接，同时在无向边旁标注上联系的类型。两个实体之间的联系可以分为三类。

※ 一对一：若对于某个实体集A中的每个实体，实体集B中至多有一个实体与之相关；反之亦然，则称实体集A与实体集B具有一对一的联系，记为1：1。

※ 一对多：若对于实体集A中的每个实体，实体集B中有多个实体与之相关；反过来，对于实体集B中的每个实体，实体集A中至多有一个实体与之相关，则称实体集A与实体集B有一对多的联系，记为1：n。

※ 多对多：若对于实体集A中的每个实体，实体集B中有多个实体与之相关；反过来，对于实体集B中的每个实体，实体集A中也有多个实体与之相关，则称为实体集A与实体集B具有多对多的联系，记为m：n。

例如，一个雇员只能属于一个部门，而一个部门可以同时对应于多个雇员，因此，雇员与部门之间具有一对多的联系，在E-R模型中的表示如下图所示。

通过逻辑设计，可以将E-R图表示的逻辑模型转换为具体DBMS处理的数据模型—关系表。从E-R模型向关系表转换时，所遵循的规则如下。

※ 每个实体都要转换成一个关系表，它的属性为关系表的各个列。

※ 一个1：1的联系可以转换为一个关系表，或者与任意一端的关系表合并。若独立转换为一个关系表，那么，两端关系表的键及联系的属性为该关系表的列；若与一端合并，那么，将另一端的键与联系的属性合并到该端。

※ 一个1：n联系可以转换为一个关系表，或与n端的关系表合并。若独立转换为一个关系表，那么，两端关系表的键及联系的属性为关系表的列。

※ 对于m：n的联系可以转换为一个关系表，两端关系表的键及联系的属性为关系表的列，而关系表的键为两端实体的键的组合。

例如，在上面的E-R模型中，可以将部门号合并到职工信息表中作为一个列。

1.2.3 关系数据库的设计规范

在关系数据库中，为了保证构造的表（关系）既能准确地反应现实世界，又有利于应用和具体的操作，还需要对构造的表进行规范，常用的规范化方法就是对关系应用不同的设计范式。在关系数据库中，在构建数据库时必须遵循一定的规则，这种规则就是范式。

关系数据库中的关系表必须满足一定的要求，即满足不同的范式。目前关系数据库有6种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以此类推。一般来说，数据库只需满足第三范式（3NF）就足够了。下面将举例介绍第一范式（1NF）、第二范式（2NF）和第三范式（3NF）。

1. 第一范式（1NF）

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

第一范式（1NF）是指数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值。即实体的某个属性不能具有多个值，或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。

在第一范式（1NF）中，表的每一行只包含一个实例的信息。例如，对于职工信息表，不能将职工信息都放在一列中显示，也不能将其中的两列或多列存入同一列中显示。职工信息表中每一行只表示一个职工的信息，一个职工的信息在表中只出现一次。

经过第一范式（1NF）后，数据库表中的字段都是单一的、不可再分的。这个单一属性由基本数据类型构成，包括整型、实数、字符型、逻辑型、日期型等。例如，下表所示的学生信息表是符合第一范式的。

而下表所示的学生信息表是不符合第一范式的。

很显然，第一范式是任何关系数据库管理系统（DBMS）必须满足的基本条件，任何关系表中各列的数据类型都是基本的数据类型，不允许再进行分隔。

2. 第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实体，或者各个行必须可以被唯一地区分。为实现区分各行，通常需要为表加上一个列，以存储各个实体的唯一标识。职工信息表中加上了员工编号列，因为每个员工的员工编号是唯一的，因此每个员工可以被唯一区分。这个唯一属性列称为主关键字或主键、主码。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓“完全依赖”，是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分，通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。

假定上述学生信息表为表示学生选课信息，以（学号，课程名称）为组合关键字，则存在如下决定关系。

      （学号，课程名称）→（姓名，联系电话，年龄，成绩，学分）

因为存在如下决定关系，所以这个关系表不满足第二范式。

     （课程名称）→（学分）
     （学号）→（姓名，年龄）

即存在组合关键字中的部分字段决定非关键字的情况。由于不符合2NF，因此这个学生选课关系表会存在如下问题。

※ 数据冗余：若同一门课程可以由n个学生选修，则“学分”重复n次；同样，若一个学生选修了m门课程，则姓名和年龄等列重复m次。

※ 更新异常：若调整了某门课程的学分，则关系表中所有行的“学分”值都要更新，否则会出现同一门课程，但学分不同的情况。

※ 插入异常：假设要开设一门新的课程，暂时还没有人选修。这样，由于没有“学号”关键字，因此课程名称和学分无法录入数据库。

※ 删除异常：假设一批学生已经完成课程的选修，这些选修记录就应该从关系表中删除。但是，与此同时，课程名称和学分信息也将被删除。

为克服上述问题，可以把上述关系表改为如下3个表。

※ 学生：Student（学号，姓名，年龄，电话号码）。

※ 课程：Course（课程名称，学分）。

※ 选课关系：SelectCourse（学号，课程名称，成绩）。

进行上述分解后，关系表就符合了第二范式，消除了数据冗余、更新异常、插入异常和删除异常。另外，所有单关键字的关系表都符合了第二范式，因为不可能存在组合关键字。

3. 第三范式（3NF）

满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式要求关系表不存在非关键字列对任意候选关键字列的传递函数依赖。简而言之，第三范式要求一个关系表中不包含已在其他表中包含的非主关键字信息。

所谓“传递函数依赖”，就是指如果存在关键字x段决定非关键字段y，而非关键字段y决定非关键字段z，则称非关键字段z传递函数依赖于关键字x。

例如，假定学生关系表Student（学号，姓名，年龄，所在学院，学院地点，学院电话），该关系表的关键字为单一关键字“学号”，因此存在如下决定关系。

    （学号）→（姓名，年龄，所在学院，学院地点，学院电话）

这个关系表是符合2NF的，但是它不符合3NF，因为存在如下决定关系。

    （学号）→（所在学院）→（学院地点，学院电话）

即存在非关键字列“学院地点”和“学院电话”对关键字段“学号”的传递函数依赖。该关系表也会存在数据冗余、更新异常、插入异常和删除异常的情况。因此，可以把学生关系表分解为如下两个表。

※ 学生：Student（学号，姓名，年龄，所在学院）。

※ 学院：Department（学院，地点，电话）。

这样关系表就符合了第三范式，消除了数据冗余、更新异常、插入异常和删除异常。

4. BCNF范式

当第三范式消除了主关键列对候选关键列的部分和传递函数依赖，则称为BCNF。举例说明，假设仓库管理关系表（仓库编号，存储物品编号，管理员编号，数量），并且规定一个管理员只在一个仓库工作，一个仓库可以存储多种物品。则这个关系表中存在如下决定关系。

     （仓库编号，存储物品编号）→（管理员编号，数量）
     （管理员编号，存储物品编号）→（仓库编号，数量）

所以，（仓库编号，存储物品编号）和（管理员编号，存储物品编号）都是仓库管理关系表的候选关键列，表中的唯一非关键列为“数量”，它是符合第三范式的。但是，由于存在如下决定关系。

     （仓库编号）→（管理员编号）
     （管理员编号）→（仓库编号）

即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况。

※ 删除异常：当清空仓库删除“存储物品编号”和“数量”信息时，“仓库编号”和“管理员编号”信息也将被同时删除。

※ 插入异常：当仓库没有存储任何物品时，无法给仓库分配管理员。

※ 更新异常：如果仓库换了管理员，则表中所有行的管理员编号都要修改。

同样，可以将仓库管理关系表分解为两个关系表。

※ 仓库管理表：仓库ID，管理员ID。

※ 仓库信息表：仓库ID，存储物品ID，数量。

这样创建的关系表就符合了BCNF范式，消除了删除异常、插入异常和更新异常。