1.3 关系数据库及其设计
1.3.1 关系数据库
在关系数据库中，一个关系就是一张二维表，由行和列组成，如图1-6所示。表中的一行就是一个元组（也称记录），表中的列为一个属性，给每个属性起一个名即为其属性名（也称字段名）。
图1-6 关系（表）的结构
关系数据库的特点如下。
①关系中每个字段（属性）不可再分，是数据库中的最基本单位。
②每一竖列字段是同属性的，每个列的顺序是任意的。
③每一行记录由一个事物的诸字段项构成，记录的顺序可以是任意的。
④不允许有相同的字段名，也不允许有相同的记录行。每个关系都有主码关键字（Key）的属性集合，用以唯一地标识关系中的各个记录行。
⑤解决实际问题往往需要多个关系，关系和关系是有联系的，这种联系也用关系表示。
在一个给定的应用领域中，所有关系及关系之间联系的关系的集合构成一个关系数据库。
1.3.2 关系数据库设计
数据库的设计质量，直接影响数据库管理系统对数据的控制质量。数据库设计是指对于一个给定的应用环境，根据用户的信息要求、处理需求和数据库的支撑环境，利用数据模型和应用程序模拟现实世界中该单位的数据结构和处理活动的过程，是数据设计和数据处理设计的结合。规范化的数据库设计要求数据库内的数据文件的数据组织应获得最大程度的共享、最小的冗余度，消除数据及数据依赖关系中的冗余部分，使依赖于同一个数据模型的数据达到有效的分离，保证在输入修改数据时数据的一致性和正确性，保证数据与使用数据的应用程序之间的高度独立性。同时在设计时还要将数据和操作数据的行为紧密结合起来，保证数据的完整性约束。
1.需求分析
需求分析阶段的任务是收集数据库所需要的信息内容和数据处理规则，确定建立数据库的目的。在需求分析调研中，必须与用户充分讨论，确定数据库所要进行的数据处理范围、数据处理的流程及数据取值范围的界定。
描述需求分析常用的方法有数据流图、数据字典等。
2.概念结构设计
概念结构设计是对现实世界的一种抽象，即对实际的人、物、事和概念进行人为处理，抽取人们关心的共同特性，忽略非本质的细节，并把这些特性用各种概念精确地加以描述。
为了能够完成上述目标，我们把现实世界中客观存在并可相互区别的事物称为实体（Entity）。比如，一个职工、一个学生、一个部门、学生的一次选课、老师与系的工作关系。
把描述实体的某一特性称为属性（Attribute），一个实体可以由若干属性值来描述。比如，一个学生实体可以由“学号，姓名，性别，年龄，所在系”等属性的属性值（20021001，张三，男，21，计算机系）来描述。
同类实体中的实体彼此之间是可以区别的，能够唯一标示实体的属性集合称做实体的码或关键字。
实体集之间存在各种联系（Relationship），主要有三类：一对一联系（1：1）、一对多联系（1：n）、多对多联系（m：n）。
（1）一对一联系（1：1）
对于实体集A中的每一个实体，实体集B中有0个或1个实体与之联系，反之亦然，则称实体集A与实体集B具有一对一的联系。
例如，假设一个班级只能由一个班主任（教师）管理，一个班主任也只能管理一个班，则教师与班级之间具有一对一的联系。
（2）一对多联系（1：n）
对于实体集A中的每一个实体，实体集B中有0个或多个实体与之联系，反之，对于实体集B中的每一个实体，实体集A中有0个或1个实体与之联系，则称实体集A与实体集B具有一对多的联系。
例如，一个班级有若干学生，每个学生只在一个班级中学习，则班级与学生之间具有一对多的联系。
（3）多对多联系（m：n）
对于实体集A中的每一个实体，实体集B中有0个或多个实体与之联系，反之，对于实体集B中的每一个实体，实体集A中有0个或多个实体与之联系，则称实体集A与实体集B具有多对多的联系。
例如，一门课程同时有若干学生选修，而一个学生同时选修多门课程，则课程与学生之间具有多对多的联系。
描述概念模型的有力工具是E-R模型。
3.逻辑结构设计
关系模型的逻辑结构是一组关系模式的集合。E-R图则是由实体、实体的属性和实体之间的联系3个要素组成的。所以将E-R图转换为关系模型，实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式。这种转换一般遵循如下原则。
（1）实体与实体属性的转换
一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。
例如，学生实体可以转换为如下关系模式，其中学号为学生关系的码：
学生（学号，姓名，性别，年龄，所在系）
（2）实体间联系的转换
①一个1：1联系可以转换为一个独立的关系模式，也可以将任意一端关系中的码合并到另一端的关系模式中。
如果转换为一个独立的关系模式，则与该联系相连的各实体的码及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。
如果使用关系模式合并方式，则需要在一个关系模式的属性中加入另一个关系模式的码和联系本身的属性，而原来的码不变。
例如，假设一个班级只能由一个班主任（教师）管理，一个班主任也只能管理一个班，则教师与班级之间具有一对一的联系。将其转换为关系模式有3种方法。
·转换成一个独立的关系模式：
管理（职工号，班级号）
·将“教师”关系中的码“职工号”与“班级”关系模式合并，在“班级”关系增加“职工号”属性：
班级（班级号，学生人数，职工号）
·将“班级”关系中的码“班级号”与“教师”关系模式合并，在“教师”关系增加“班级号”属性：
教师（职工号，姓名，性别，职称，班级号）
推荐使用合并的方法。
②一个1：n联系可以转换为一个独立的关系模式，也可以将一端关系中的码与n端对应的关系模式合并。
如果转换为一个独立的关系模式，则与该联系相连的各实体的码及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
如果使用关系模式合并方式，则需要在n端关系模式的属性中加入一端关系模式的码和联系本身的属性，而原来的码不变。
例如，假如有一个学生“组成”的联系，即一个学生只能属于一个班级，一个班级可能有多个学生，该联系为1：n联系，将其转换为关系模式有两种方法。
·转换成一个独立的关系模式：
组成（学号，班级号）
·将其与“学生”关系模式合并，增加“班级号”属性：
学生（学号，姓名，年龄，所在系，班级号）
推荐使用合并的方法。
③一个m：n联系转换为一个关系模式。
必须转换为一个独立关系，与该联系相连的各实体的码及联系本身的属性均转换为新关系的属性。而关系的码为各实体码的组合。
例如，假如有一个学生“选修”的联系，即一个学生可以选修多门课程，一门课程可以被多个学生选修，该联系是一个m：n联系，将其转换为如下关系模式：
选修（学号，课程号，成绩）
4.数据库表的优化与规范化
在数据需求分析的基础上，进行概念结构和逻辑结构设计，并将数据信息分割成数个大小适当的数据表。例如，可以得到学生的相关数据信息（如表1-1所示的学生选课表），学生选课数据表包含学号、姓名、所在院系、电话、城市、课程编号、课程名称、成绩等属性。
表1-1是一个未被规范化的数据表，这张表存在大量的数据冗余。如果王东民同学选修了3门课程，则学号、姓名、院系、电话、城市等字段数据需要重复3遍。当王东民从一个城市搬到另一个城市，几乎所有的属于王东民的记录将要一一更正，这样效率很低。如果在更正的过程中发生意外，比如出现死机或掉电等情况，数据不一致的情况就会发生。如果一个学生没有选任何课程，按照完整性约束规则，则他的所有数据将无法输入。如果要取消某个学生的所有课程信息，则要将所有与该同学有关的信息全部去掉。总之，大量的数据冗余不但浪费了存储空间，而且降低了数据查询效率，提高了维护数据一致性的成本。
表1-1 学生选课表
关系模型的规范化理论是研究如何将一个不规范的关系模型转化为一个规范的关系模型理论。数据库的规范化设计，要求分析数据需求，去除不符合语义的数据，确定对象的数据结构，并进行性能评价和规范化处理，避免数据重复、更正、删除、插入异常。
规范化理论认为，关系数据库中的每一个关系都要满足一定的规范。根据满足规范的条件不同，可以划分为5个等级，分别称为第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF），其中NF是Normal Form的缩写。通常在解决一般性问题时，只要把数据规范到第三范式标准就可以满足需要。
（1）第一范式
在一个关系中，消除重复字段，且每个字段都是最小的逻辑存储单位。
（2）第二范式
若关系属于第一范式，则关系中每一个非主关键字段都完全依赖于主关键字段，没有部分依赖于主关键字段的部分。
这里的主关键字是指表中的某个属性组，它可以唯一确定记录其他属性的值。如表1-1所示，学生选课数据表的主关键字是由学号和课号共同组成的。属性成绩完全依赖于主关键字，属性姓名、院系、电话、城市等都只依赖于学号，不完全依赖于主关键字，因此学生选课数据表不符合第二范式的要求。
一个有效的解决办法是把信息分为各个独立的主题，例如“学生基本信息表”、“学生选课成绩表”等，保证关系中每个非主关键字都完全依赖于主关键字。
（3）第三范式
若关系模式属于第一范式，且关系中所有非主关键字段都只依赖于主关键字段。
第三范式要求去除传递依赖，如表1-2（学生情况表）所示，学生的年龄依赖于身份证号，身份证号又是由学号决定的，因此学生的年龄就传递依赖于主关键字学号。所以表1-2不符合第三范式要求。
表1-2 学生情况表
上述问题的解决办法是不要包含可以推导得到的数据或经计算得到的数据。实际年龄可以由身份证号计算得到，年龄和身份证号作为属性同时出现，本质上产生了数据冗余。
有些属性并不能经推导计算得到，但也存在传递依赖，比如电话号码可以通过身份证号传递依赖于主关键字的学号，但有些时候这样是需要的。
5.规范化的大学教学管理数据库
下面给出比较简单的、规范了的大学教学管理数据库。实际中由于涉及不同学校的大量不同管理条款，系统比较复杂。实例中忽略了许多细节，只保留大学的本质内容。
（1）学生表
学生表如表1-3所示，其中属性有学号、身份证号、姓名、性别、移动电话、城市、专业、所在院系、累计学分。主键为学号。
表1-3 学生表
（2）课程表
课程表如表1-4所示，其中属性有课号、课名、教材名称、编著者、出版社、版号、定价。主键为课号。
表1-4 课程表
（3）教师表
教师表如表1-5所示，其中属性有工号、身份证号、姓名、性别、移动电话、城市、院系、职称、负责人工号。主键为工号，外键是负责人工号，参考本表的工号。
表1-5 教师表
（4）开课表
开课表如表1-6所示，其中属性有开课号、课号、（教师）工号、开课地点、开课学年、开课学期、开课周数、开课时间、（该课的）学分。主键为开课号，外键一是课号，参照课程表中的属性课号，外键二是工号，参照教师表中的属性工号。
表1-6 开课表
（5）选课表
选课表如表1-7所示，其中属性有学号、开课号、（考试后得到的）成绩。主键为学号和计划编号，外键为计划编号，参考开课计划表中的属性计划编号。
表1-7 选课表
6.数据库中表间的联系
只理解每个数据表对于具体问题的解决往往是不够的。要真正理解一个关系数据库的内容，除了理解每个表的内容外，还需要理解各个表间的关系或联系。一个表中的行通常和其他表中的行相关联。不同表中相匹配的值（相同的值）表明相应表间存在联系。考虑学生表、开课表和选课表之间的联系，选课表中每一行表示一个学生选择了某门计划开设的课程。选课表的学号列中的每个值都与学生表中的学号列的某个值相匹配；同样，开课号列中的每个值也都与开课表中的开课号列的某个值相匹配。图1-7描绘了不同的表列值间的匹配关系。
众所周知，一般系统的关系数据库一般都包含很多表，少则10～15个表，多则上百个表。要从这么多的表中提取出有意义的信息，通常需要使用数据匹配的方法把多个表结合到一起。通过学生表.学号列和选课表.学号列上的数据匹配，就可以将学生表和选课表关联到一起。与此类似，通过开课表.课号列和选课表.开课号列上的数据匹配，就可以将开课表和选课表关联到一起。理解表之间的联系，对于提取有价值的数据是非常重要的。
1.3.3 关系数据库的完整性
关系完整性是关系数据库必须满足的完整性约束条件，它提供了一种手段来保证当授权用户对数据库修改时不会破坏数据的一致性。因此，完整性约束防止的是对数据的意外破坏，从而降低应用程序的复杂性，提高系统的易用性。
图1-7 选课表和学生表、开课表之间的匹配
1.实体完整性约束（PRIMARY）
实体完整性规则是主关键字段中的各属性值不能取空值。
例如，在学生表中，规定PRIMARY KEY=学号，因此学号不能取空值。
2.唯一性约束（UNIQUE）
唯一性约束规则是在约束的字段上不能有相同值出现。
例如，在学生表中，学号是唯一标示每个学生实体的，所以该字段的值就不能出现重复的学号值。又如，在课程表中，学校设置的课程名称一般是不允许有一样的名字的，所以课程表中的课名值就必须唯一。
3.参照完整性约束（FOREIGN）
参照完整性约束规则要求外关键字的值必须来源于被参照关系表的取值或为空值。
外关键字定义为：设F是基本关系R的一个或一组属性，但不是关系R的关键字。如果F与基本关系S的主关键字Ks相对应，则称F是基本关系R的外关键字，并称基本关系R为参照关系，基本关系S为被参照关系或目标关系。
例如，选课表中的学号和开课号字段，单独都不是选课表的关键字。但是，学号是学生表的主关键字，开课号是开课表的主关键字。所以选课表中的学号相对学生表就是外关键字，参照完整性约束要求选课表中的学号值必须在学生表的学号中可以找到，否则就只能取空值。同理，选课表中的开课号相对开课表就是外关键字，参照完整性约束要求选课表中的开课号值必须在开课表的开课号中可以找到，否则就只能取空值。
4.检查（CHECK）和默认值（DEFAULT）约束
该类完整性约束是针对某一具体关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求。
例如，选课表中的成绩字段通过这种约束，其值只能在0～100之间，或者是空值，可以把默认值设为NULL。
表1-8至表1-12是SQL Server关系数据库中学生表、课程表、教师表、开课表和选课表的完整性约束的部分情况。
表1-8 学生表约束
表1-9 课程表约束
表1-10 教师表约束
表1-11 开课表约束
表1-12 选课表约束
