3.1.4 关系数据库
关于关系数据库，我们需要了解关系模型、Codd十二条法则、关系数据库常用术语、关键码及数据库范式。下面分别介绍这些内容。
1．关系模型
为了了解一个关系数据库管理系统是由什么构成的，我们必须进一步了解关系模型。在一个关系模型中，数据的基础项是关系，在表上执行的操作只产生关系。
什么是关系？关系是一个描述两个集合的元素如何相互联系或如何一一对应的数学概念。因此，关系模型是建立在数学基础上的。然而，关系只是一个有一些特殊属性的表，一个关系模型把数据组织到表中，而且仅在表中。如果客户、数据库设计者、数据库系统管理员和用户均以同样的方式从表中查看数据，那么表就是关系模型的近义词。
一个关系表有一组命名的属性（attribute）或列，以及一组元组（tuple）或行。有时列称为字段，行称为记录，列和行的交集通常称为单元。列标识位置，有作用域或数据类型，如字符或整数，行就是数据，如图3-1所示。
图3-1 关于汽车的行和列
一个关系表必须符合某些特定条件，才能成为关系模型的一部分。
● 存储在单元中的数据必须是原子的，即每个单元只能存储一条数据，这也称为信息原则（information principle）。
● 存储在列下的数据必须具有相同的数据类型。
● 每行是唯一的（没有完全相同的行）。
● 列没有顺序。
● 行没有顺序。
● 列有一个唯一的名称。
除了表及其属性之外，关系模型有自己特殊的操作。不需要深入研究关系型数学，只须说明这些操作可能包括列的子集、行的子集、表的连接及其他数学集合操作（如联合）等就足够了。真正要知道的事情是这些操作把表当作输入，而将产生的表作为输出。
关系模型要求遵循两个基础的完整性原则，即是实体完整性原则（entity integrity rule）和引用完整性原则（referential integrity rule）。首先，介绍以下两个定义。
● 主键（primary key）是能唯一标识行的一列或一组列的集合。有时，多列或多组列可以当作主键。
● 由多个列构成的主键称为连接键（concatenated key）、组合键（compound key），或者更常称为复合键（composite key）。
数据库设计者决定哪些列的组合能够最准确和有效地反映业务情形，这并不意味着其他数据未存储，只是那一组列被选作主键而已。
剩余有可能被选为主键的列称为候选键（candidate key）或替代键（alternate key）。外键（foreign key）是一个表中的一列或一组列，这些列在其他表中作为主键而存在。一个表中的外键是对另一个表中主键的引用。实体完整性原则简洁地表明主键不能全部或部分空缺，引用完整性原则简洁地表明一个外键必须为空或者与它所引用的主键当前存在的值一致。
RDBMS就是一个建立在前面这些关系模型基础上的并且能满足上面提到的全部要求的DBMS。但是，在20世纪70年代末到80年代初，RDBMS开始销售的时候，SQL超越了本质为非关系型的系统，受到普遍欢迎，并被称作关系型系统。这引发了一些修正活动-诞生了Codd十二条法则（1985年）。
2．Codd十二条法则
DBMS应该遵循EF Codd提出的十二条法则，才能属于完全关系型的系统。
（1）信息法则。信息表现为存储在单元中的数据。
（2）授权存取法。每一个数据项必须通过一个"表名+行主键+列名"的组合形式访问。例如，如果用户用数组或指针访问一列，就违反了这条规则。
（3）必须以一致的方式使用空值。如果由于缺少数字值，空值（Null）被当作0来处理，或者由于缺少字符值而被当作一个空格处理，那么这就违反了这条规则。空值仅仅是指缺少数据而且没有任何数值。如果缺少的数据需要值，软件提供商通常通过提供使用默认值达到这一目的。
（4）一个活跃的在线数据字典应作为关系型表存储，并且该字典可以通过常规的数据存取语言访问。如果数据字典的任何部分存储在操作系统文件里，那么这就违反了这条规则。
（5）除了可能的低级存取例程外，数据存取语言必须提供所有的存取方式，并且是仅有的存取方式。如果用户能通过一个实用程序而不是一个SQL接口来存取支持一个表的文件，就有可能违反了本规则。参见规则12。
（6）所有能更新的视图是可更新的。例如，如果用户能将3个表连接起来，作为一个视图的基础，但不能更新这个视图，就违反了本规则。
（7）必须有集合级的插入、更新和删除。目前，大多数RDBMS提供商在某种程度上提供了这种能力。
（8）物理数据的独立性。应用不能依赖于物理结构，一个支持某表的文件从一张盘移动到其他盘上或重命名，不应该对应用产生影响。
（9）逻辑数据的独立性。应用不应依赖于逻辑结构。如果一个表必须分成两部分，那么应该提供一个视图，以把两部分连接在一起，以便不会对应用产生影响。
（10）完整性的独立性。完整性规则应该存储在数据字典中。主键约束、外键约束、检查约束、触发器等都应该存储在数据字典中。
（11）分布独立性。一个数据库即使是分布式的，也应该能继续工作。这是规则8的一个扩展，一个数据库不仅能分布在一个本地的系统中，而且能分布在通过系统的网络（远程的）中。
（12）非破坏性法则。如果允许低级存取，一定不能绕过安全性或完整性规则，这些规则是常规的数据存取语言所遵守的。例如，一个备份或载入工具不能绕过验证、约束和锁来备份或载入数据。然而，软件供应商出于速度的原因，通常提供这些功能。因此，数据库系统管理员就有责任确保数据的安全性和完整性，如果瞬间出现问题，应该立即恢复。
如果一个DBMS能满足本章讨论的所有基本原则和这12条法则，那么它就可以被当作一个RDBMS。Codd用他的法则总结了这一切："对于一个有资格成为RDBMS的系统来说，该系统必须排他地使用它的关系型工具来管理数据库。"
3．关系数据库常用术语
关系数据库是现在最流行的数据模型之一。请看下面两张二维表。
学生信息表如表3-2所示。
表3-2 学生信息表
老师信息表如表3-3所示。
表3-3 老师信息表
关系数据库常用术语主要有以下这些。
● 关系（表）：关系就是一张表，如老师信息表和学生信息表。
● 元组：表的一行为一个元组（不包括表头），有时也叫记录。
● 属性：表的一列为一个属性。
● 主码（或关键字）：可以唯一确定一个元组和其他元组不同的属性组。
● 关系模式：对关系的描述，一般表示为关系名（属性1，属性2，…，属性n）。
4．关键码
● 超键
在关系模式中，能唯一标识元组的属性集称为超键（super key）。例如，在整个地球上能唯一标识一个人的属性是DNA，通过DNA，我们可以唯一确定一个人，因此DNA就是地球人的超键。超键一般由DBMS管理。
● 候选键
如果一个属性集能唯一标识元组，且又不含多余属性，那么这个属性集称为候选键（candidate key）。在地球上除了DNA以外还能通过什么来唯一识别一个人？例如，在中国可以通过身份证来确定一个人，在美国可以通过社保卡号来确定一个人，通过"国籍+本国编号"也可以唯一识别一个人。
● 主键
在关系模式中，用户正在使用的候选键称为主键（primary key）。在中国这个关系模型中，身份证号码就是主键，用来唯一标识记录。
● 外键
如果关系模式R中的某属性集是其他模式的候选键，那么该属性对于模型R而言是外键。
5．数据库范式
关系数据库中的关系必须满足一定的要求，即满足不同的范式（Normal Format, NF）。范式为设计数据库中表内关系、表与表之间的关系提供了规范和标准，任何按照范式设计的表结构将是最优结构，同时也可以避免数据冗余，减少数据库的存储空间，减少维护数据完整性的麻烦。
目前关系数据库有6种范式，分别是第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式依次类推。一般来说，数据库只需要满足第三范式（3NF）即可。
● 第一范式：无重复的列
第一范式是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式中，表的每一行只包含一个实例的信息。简而言之，第一范式就表示无重复的列。
需要指出的是，在任何一个关系数据库中，第一范式是对关系模式的基本要求，不满足第一范式的数据库就不是关系数据库。
● 第二范式：无重复的行
第二范式是在第一范式的基础上建立起来的，即满足第二范式必须先满足第一范式。第二范式要求数据库表中的每个实例或行必须具有唯一性。为了实现区分，通常需要为表加上一列，以存储各个实例的唯一标识。例如，员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是唯一的，所以每个员工具有唯一性。这个唯一的属性列称为主关键字或主键、主码。
第二范式要求实体的属性完全依赖于主键。完全依赖是指不能存在仅依赖主键一部分的属性，如果存在，那么这个属性和主键的这一部分应该分离出来以形成一个新的实体，新实体与原实体之间是一对多的关系。为了实现区分，通常需要为表加上一列，以存储各个实例的唯一标识。简而言之，第二范式就表示属性完全依赖于主键。
● 第三范式：主表与外表
为了满足第三范式必须先满足第二范式。简而言之，第三范式要求一个数据库表不包含其他表已包含的非主键信息。如果存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息，那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息加入员工信息表中。如果不存在部门信息表，则根据第三范式也应该构建它；否则，就会有大量的数据冗余。简而言之，第三范式就表示属性不依赖于其他非主属性。
6．范式应用举例
下面以一个学校的学生系统为例来说明这几个范式的应用。
1）第一范式实例分析
某个单一的属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。在当前的任何DBMS中，不可能设计出不符合第一范式的数据库，因为这些DBMS不允许用户把数据库表的一列再分成两列或多列。因此，用户想在现有的DBMS中设计出不符合第一范式的数据库是不可能的。
首先确定一下要设计的内容，包括学号、姓名、年龄、性别、课程名称、课程学分、系别、学科成绩、系办地址、系办电话等信息。为了简单起见，我们暂时只考虑这些字段信息。对于这些信息，关心的问题有如下几个方面。
● 学生有哪些基本信息？
● 学生选了哪些课？成绩是多少？
● 每门课的学分是多少？
● 学生属于哪个系？系的基本信息是什么？
2）第二范式实例分析
首先把所有这些信息（学号，姓名、年龄、性别、课程名称、课程学分、系别、学科成绩、系办地址、系办电话）放到一个表中，这将会产生以下问题。
● 数据冗余。
同一门课程由n个学生选修，"学分"就重复n?1次；同一个学生选修了m门课程，姓名和年龄就重复了m?1次。
● 更新异常。
若调整了某门课程的学分，则数据表中所有行的"学分"值都要更新；否则，会出现同一门课程学分不同的情况。假设要开设一门新的课程，暂时还没有人选修，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
● 删除异常。
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。然而，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
分析所有字段，发现它们之间存在如下依赖关系。
● 姓名、年龄、性别、系别、系办地址、系办电话依赖于学号。
● 学分依赖于课程名称。
● 学科成绩依赖于学号和课程。
因此，可以把选课关系表StudentCourse改为如下3个表。
● 学生表：Student（学号，姓名，年龄，性别，系别，系办地址，系办电话）。
● 课程表：Course（课程名称，学分）。
● 选课关系表：Score（学号，课程名称，成绩）。
3）第三范式实例分析
接着看学生表Student（学号，姓名，年龄，性别，系别，系办地址，系办电话），其关键字为单一关键字"学号"，因为存在如下决定关系。
（学号）→（姓名，年龄，性别，系别，系办地址，系办电话）
还存在如下决定关系。
（学号）→（所在学院）→（学院地点，学院电话）
即存在非关键字段"学院地点""学院电话"对关键字段"学号"的传递函数依赖。因此，学生表也会存在数据冗余、更新异常、插入异常和删除异常的情况。把学生关系表分为如下两个表就可以满足第三范式了。
● 学生表：Student（学号，姓名，年龄，性别，系别）。
● 系别表：Dept（系别，系办地址，系办电话）。
因此，上面的数据库表符合第一范式、第二范式和第三范式，消除了数据冗余、更新异常、插入异常和删除异常。
7．数据库关系
数据库关系有如下3种。
● 一对一关系。
从Student表中，我们可以看到一个学生只能有一个学号，一个学号只指向一个学生，这种逻辑关系便属于一对一关系，通常用1:1表示。
● 一对多关系。
对于学生表和系别表的关系来说，一个学生只能选择一个系别，而一个系别可以有多个学生，这种关系称为一对多关系，通常用1:N表示。
● 多对多关系。
对于学生表和课程表来说，一个学生可以选择多门课程，而一门课程同样可以由多个学生选择，这种关系称为多对多关系，通常用M:N表示。
版权声明：51Testing软件测试网获得人民邮电出版社和作者授权连载本书部分章节。
任何个人或单位未获得明确的书面许可，不得对本文内容复制、转载或进行镜像，否则将追究法律责任。
