4．4 练习与实训
图4．4 实体之间联系的类型
4．2．2 关系数据库及其数据模型
逻辑模型用于在DBMS实现数据库的描述和存储，不同类型的逻辑模型是构造相应类型数据库的基础。逻辑模型主要有层次模型、网状模型、关系模型、面向对象模型和对象关系模型。其中关系模型简单灵活，并有着坚实的理论基础，一经问世便很快成为最流行的数据模型。
典型的关系数据库系统有ORACLE，SYBASE，INFORMIX，DB2，SQL SERVER，ACCESS，MySQL。
关系数据库之所以得到如此广泛的应用，主要原因是它把具有相同属性的数据独立地存储在一个二维表中，解决了层次数据库缺乏足够横向联系的缺陷，同时也避免了网状数据库关联太过复杂的弊病。
关系型数据库是按照关系型数据模型建立起来的数据库。每种数据模型都具有3个要素，即数据结构、操作集合和完整性约束。
（1）关系模型的数据结构
关系模型是由一组关系组成，每一个关系是一张规范化的二维表，关系模型只包含二维表这一种数据结构。因此，关系数据库的结构非常简单。关系模型有以下一些术语：
①关系。一个关系对应着一张规范化的二维表。因此在关系数据库中，关系就是表，表就是关系。
②元组。二维表中的一行数据称为一个元组。
③属性。表的一列就是一个属性，每个属性都必须有一个属性名。
④键。也称码，它是表中某个属性或几个属性的组合，键用来唯一标识一个元组。
⑤域。域是属性的取值范围。例如，属性性别只能取“男”或“女”二值之一，故其域就是（男，女）。而对于就读专业来说，它的域就是该校所有开设的专业的名称集合。
关系是由关系型和关系体组成。
关系型：由属性名的集合组成，每个属性正好对应一个域。关系型，也称关系框架，是相对固定的，是对关系的数据结构的描述。
关系体：是指关系结构中的内容或者数据，显然它并非固定的，它会随元组的建立、删除或修改而变化。
关系数据库的表在外形上看与电子表相似，由若干行和列组成。除表头所在的第一行之外，其余每一行数据称为一条记录（Record），每一列称为一个字段（Field），表头各列指明了每个字段的名称。这里的记录、段就是前面介绍的元组、属性，它们是同义语（在讨论数据模型时通常称为元组和属性），如图4．5所示。
图4．5 一个关系的构成
若关系中的某一属性或属性组合能够唯一地区分一个元组，则称该属性（属性组）为这个关系的候选码（或称“候选键”“候选关键字”）。唯一区分的含义是表的各个行在该列或这个列组合上的值是各不相同的。
包含在任何一个候选码中的属性称为主属性，不包含在任何候选码中的属性称为非主属性或非码属性。若一个关系有多个候选码，可以从中选择一个作为“主码”。
定义：一个关系模式中的主码是一个或多个属性的组合，其值不能为空且能够唯一地标识该关系中的每一个元组。主码又被称为主键、主关键字。
显然，最简单的情况是候选码只包含该关系中的一个属性；最极端的情况就是该关系的所有属性都是这个关系模式的候选码（此时，称其为全码）。例如，对于“系部”这个关系，如图4．6所示。
图4．6 系部
很明显，系部代号和系部名都能唯一识别每个系（因为同一学校里面不会有同名的系），所以“系部代号”和“系部名”都是候选码，它们同时也是主属性。而系主任、办公地址都是非主属性。可从“系部代号”和“系部名”二者中选择任何一个作为“系部”这个关系的主码。
（2）关系的性质
①每一列中的分量是同一类型的数据，并且是不可再分的数据项（见图4．7），称为列的“原子性”。
图4．7 非规范的关系（“表中表”）及其处理方法
②不同的列可出自同一数据类型，称每一列为关系的一个属性，不同的属性要给予不同的属性名。
③列的顺序无影响，即列的次序可以任意交换，如图4．8所示。
图4．8 关系中列的顺序无影响（T1和T2反映的是同一个事实）
④行的顺序无影响，即行的次序可以任意交换。
⑤任意两个元组的候选码不能相同，即没有完全相同的两条记录。
（3）关系模式与关系数据库
关系模式就是关系的框架，它指出了关系由哪些属性构成，是对关系结构的描述。由于关系就是二维表，因此也可以说关系模式是表的框架，它给出了表由哪些列（字段）组成，包括表名、列名、主码（关键字）等。
一个数据库往往要涉及多个实体及其联系，因此就需要一组关系模式。例如，教学管理数据库中教师与课程的关系模型如图4．9所示。
图4．9 教师—课程数据库的关系模型
从各个关系的框架中，可以很容易看出哪两个关系之间有联系。例如，教师关系和授课关系有公共的属性“教师号”，则表明这两个关系有联系。而课程关系和授课关系有公共的属性“课程号”，则表明这两个关系也有联系。至于元组之间的联系，则与具体的数据有关。只有在公共属性上具有相同属性值的元组之间才有联系。
由上例可知，在一个关系中可以存放两类信息：一类是描述实体本身的信息；另一类是描述实体（关系）之间联系的信息。
关系模型使用二维表来表示实体，也用二维表表示实体之间的联系，这就是关系模型的本质所在。
因此，在建立关系模型时，只要根据概念设计的结果（概念模型）把所有的实体及其属性用关系框架来表示，同时把实体之间的关系也用关系框架来表示，就可以得到一个关系模型。如上例中的教师—课程数据库的关系模型就是这样建立的。
（4）E-R模型到关系模式的转换规则
将E-R模型转换为关系模型，要遵循一定的规则：
瞯一个实体型转换为一个独立的关系模式，实体的属性就是关系的属性，实体的码就是关系的码。
瞯对于实体型之间的联系要分以下不同情况分别处理：
①1∶1的联系：
方案1：把这个联系转换为一个独立的关系模式。关系模式的名称就是这个联系的名称；该关系模式的属性包括这个联系本身的属性以及与这个联系相连的两个实体的键；与这个联系相连的两个实体的键就是该关系模式的候选键。
方案2：把这个联系的所有属性合并到与它相连的任意一端实体型所转换出来的关系模式中，同时将另一端实体的键也加入这个关系模式中。
②1∶n的联系：
方案1：把它转换为一个独立的关系模式。关系模式的名称就是这个联系的名称；与这个联系相连的两个实体的键以及联系本身的属性就是该关系模式的属性；n端实体的键就是该关系模式的键。
方案2：把它合并到n端实体型所转换出来的关系模式中。将1端实体的键和这个联系本身的属性都放进这个关系模式中作为它的属性。
③n∶m的联系只能转换为一个独立的关系模式。联系的名称就是关系模式的名称，与该联系相连的各实体的码以及联系本身的属性就是该关系的属性，各个实体的码组成该关系的码或码的一部分。
④3个及以上实体之间的多元联系转换成一个关系模式。
⑤具有相同码的关系模式可以合并。
4．2．3 关系数据库的规范化
（1）不合理的关系模式存在的存储异常问题
例如，某设计员为学生管理数据库设计出了关系模式，其中SCD如下：
SCD（Sno，Sn，Sex，Age，Dept，DHead，Cno，Cn，Score）
Sno表示学生学号，Sn表示学生姓名，Sex表示学生性别，Age表示学生年龄，Dept表示学生所在的系别，DHead表示系主任姓名，Cno表示课程号，Cn表示课程名，Score表示成绩。
在此关系模式中填入一部分具体的数据，则可得到SCD关系模式的实例，即学生管理数据库中的一张表，如图4．10所示。
图4．10 SCD关系实例
根据前面关于本数据库系统的语义说明分析关系SCD中的数据可知，（Sno，Cno）属性的组合能唯一标识一个元组，因此（Sno，Cno）是该关系模式的主关系键。但在进行数据库的操作时，会出现以下几方面的问题：
1）数据冗余
每个系名和系主任的名字存储的次数等于该系的学生人数乘以每个学生选修的课程门数，同时学生的姓名、出生日期也都要重复存储多次，数据的冗余度（即重复）很大，浪费了存储空间。
2）插入异常
如果某个新的系还没有招生时，尚无学生，则系名和系主任的信息就无法插入数据库中。
由于在这个关系模式中，（Sno，Cno）是主键。根据关系的实体完整性约束，主键的值不能为空，而这时没有学生，Sno和Cno均无值，因此不能进行插入操作。
另外，当某个学生尚未选课，即Cno未知，实体完整性约束还规定，主键的值不能部分为空，同样不能进行插入操作。
3）删除异常
某系学生全部毕业而没有招生时，删除全部学生的记录则系名、系主任也随之删除，于是在数据库中无法找到该系相应的信息。
另外，如果某个学生不再选修C04课程，本应该只删去C04，但C04是主键的一部分，为保证实体完整性，必须将整个元组一起删掉，这样有关该学生的其他信息也随之丢失。
4）更新异常
例如，如果学生改名，则该学生的所有记录都要逐一修改SN；又如，某系更换系主任，则属于该系的学生记录都要修改DHead的内容，稍有疏忽大意漏改、错改了某些记录，这就会造成数据的不一致性，破坏了数据库的完整性。
由此可知，SCD不是一个好的关系模式。直观来看，SCD关系中“包罗万象”，内容太多、太杂。那么，怎样才能得到一个好的关系模式呢？这里把关系模式SCD分解为以下3个结构简单的关系模式：
学生关系，S（Sno，Sn，Sex，Age，Dept）
选课关系，SC（Sno，Cno，Score）
系部关系，D（Dept ，DHead）
根据此3个关系模式建立的数据表如图4．11所示。
图4．11 将关系模式SCD分解为3个关系
在以上3个关系模式中，实现了信息的某种程度的分离：S中存储学生基本信息，与所选课程及系主任无关；D中存储系的有关信息，与学生无关；SC中存储学生选课的信息，而与学生的基本信息及系的有关信息无关。
与SCD相比，分解为3个关系模式后，数据的冗余度明显降低。
当新插入一个系时，只要在关系D中添加一条记录。当某个学生尚未选课，只要在关系S中添加一条学生记录，而与选课关系无关，这就避免了插入异常。
当一个系的学生全部毕业时，只需在S中删除该系的全部学生记录，而关系D中有关该系的信息仍然保留，从而不会引起删除异常。
同时，由于数据冗余度的降低，数据没有重复存储，也不会引起更新异常。
经过上述分析，分解后的关系模式是一个好的关系数据库模式。从而得出一个好的关系模式应该具备以下4个条件：
①尽可能少的数据冗余。
②没有插入异常。
③没有删除异常。
④没有更新异常。
（2）函数依赖的定义及性质
关系模式中的各属性之间相互依赖、相互制约的联系称为数据依赖。数据依赖一般分为函数依赖、多值依赖和连接依赖。其中函数依赖是最重要的数据依赖。
1）函数依赖
函数依赖是关系模式中属性之间的一种逻辑依赖关系。由于一个Sno只对应一个学生，而一个学生只能属于一个系，因此当Sno的值确定之后，Sn，Age，Dept的值也随之被唯一的确定了。例如，按照图4．9所示的学生关系，如果Sno＝“S1”，则该学生的姓名、性别，年龄、系名就是“赵悦，女，18，计算机”。这类似于变量之间的单值函数关系。设单值函数Y＝F（X），自变量X的值可以决定一个唯一的函数值Y。
在这里说Sno函数决定Sn，Age和Dept，或者说Sn，Age和Dept函数依赖于Sno。
定义：在一个关系模式中，如果某一个或某一组属性（记为X）被确定后，这个关系模式中的其他属性（记为Y）也就被必然确定了，则称属性Y函数依赖于属性X，或者称X函数决定Y，并记为X→Y。
2）完全函数依赖和部分函数依赖
对于学生的“选课”关系，根据常识可以知道一旦学生的学号和课程号都确定下来后，该学生所选的这门课的成绩也就必然被确定了。对于“选课”关系：
SC（SNO，CNO，SCORE）
其主码是由两个属性（SNO，CNO）组合而成的，非主属性SCORE既依赖于SNO又依赖于CNO，即依赖于整个主码（SNO，CNO）而不是其中任何一部分。因此称SCORE完全函数依赖于主码。否则，就称为部分函数依赖。
定义：一个关系模式中的所有非主属性都函数依赖于整个主码，反之，主码中的任何一部分都不能函数决定全部非主属性，则称这些非主属性完全函数依赖于主码，否则就称为部分函数依赖于主码。
显然，如果关系模式的主码是单一一个属性，则必然是完全函数依赖，不存在部分函数依赖的可能性。
对于教师任课的关系：
TC（Tno，Cno，Dct）
按照学校中的常识，教师上某门课的实际学时Dct完全函数依赖于这个教师（Tno）和这门课（Cno）。而对于下面的关系模式：
SCD（Sno，Sn，Sex，Age，Dept，DHead，Cno，Cn，Score）
不难作出分析，学生的姓名、出生日期、所属系部以及系主任是不以他选修了什么课程Cno而定的。同样课程名Cn也不决定于学生的学号。因此这个关系模式里面存在着部分函数依赖。
3）传递函数依赖
假设在设计“教学管理数据库”逻辑模型时，得出了关系模式SDD：
SDD（Sno，Dept，Dorm，Dormphone，Resp，Totalroom）
根据情境描述中的“一个系的学生居住在同一个宿舍区，一个宿舍区可以居住多个系部的学生”，可以分析出：学号函数决定系名（Sno→Dept），系名函数决定宿舍区（Dept→Dorm），但是宿舍区不能决定系名。即宿舍区通过系名的传递间接地依赖于学号。这种情况称为“传递依赖”或“间接依赖”。简单地表述为在关系模式中的属性X，Y，Z，如果X→Y，Y→Z，但Y 
X，则称Z传递依赖于X。
（3）关系模式规范化
从前面的讨论得知，在设计关系数据库时，不能随意建立关系模式。那么什么是好的关系模式？E．F．Codd在1971—1972年提出了关系数据库设计的3条准则，人们一般称之为三范式，即第一范式（1NF）、第二范式（2NF）和第三范式（3NF），这里NF是Normal Form的缩写。所谓三范式，就是指达到了一定条件的关系模式。3个范式中1NF要求最低，在1NF的基础上又达到了更高的条件，就成2NF了。同样原因，3NF是在2NF的基础满足了更高的条件。
1）第一范式（1NF）
定义：如果一个关系模式中的每一个属性值都是不可再分解的数据量，则称它属于第一范式，记为1NF。
1NF是关系模式必须达到的要求，否则就不是关系模式。
前面提到过的“表中表”就是存在着组合数据，因此它不是1NF。对于表4．10，由于在一列中放入了多个数据，因此也不是1NF。此外，表4．11由于“商品代号1”和“商品代号2”实质上是同类属性，“单价1”和“单价2”也是同类属性，也是1NF所不允许的。
表4．10 非1NF的数据表
表4．11 非1NF的数据表
对于上述情况分别处理。将表中表的组合列分解为独立的列，如图4．12所示。
图4．12 非1NF（“表中表”）及其处理方法
对于表4．10和表4．11所示的非1NF关系，采取的方法是将组合数据列分解为独立的列、把同类属性归并为一个属性，见表4．12所示。
表4．12 1NF的数据表
1NF只是达到了关系模式的最低要求，还存在着问题。下面以表4．12为例进行说明。
①数据冗余。很明显，订单上的每种商品都要占一行，其单价、计量单位、产地被重复存储。结果是不仅要多占用存储空间，更为严重的是一旦输入错误就会导致数据不一致。
②插入异常。如果新到货了商品需要输入表中供客户选购，但是由于缺少订单号码（主键组成部分），导致系统拒绝输入。
③删除异常。如果订单被撤销了，则该订单号就要删除，同时相应的商品代号、单价等信息也一并被删掉了，导致该商品的信息丢失。
④更新异常。当某种商品要调价，就需要修改购买该商品所有的记录，这不仅耗时而且漏掉、输入错误等就会造成同一种商品单价不一样的现象。
要避免这些问题，就需要提高该关系模式的范式级别，由1NF上升到2NF。
2）第二范式（2NF）
定义：对于一个1NF，如果它的每一个非主属性完全函数依赖于主码，则该关系模式是2NF。
可知，2NF关系模式首先必须是1NF，其次如果主码是单个属性则自然不存在部分函数依赖。因此，第二范式只针对由两个或多个属性组合构成主码的关系模式。
按照定义，2NF要求每一个非主属性都必须完全函数依赖于主码组合中的每个属性，而不是其中的部分属性。下面分析几个实例。
例4．1 规范化表4．12所示的订购单关系。
订购单（订购单号码，商品代号，单价，计量单位，产地，订购数量）
分析 首先，前面已经分析过了它是1NF。其次，很明显其主码应该是（订购单号码＋商品代号），即“订购单号码”与“商品代号”的组合。“订购数量”既函数依赖于“订购单号码”也函数依赖于“商品代号”，即完全函数依赖于主码（订购单号码＋商品代号）。而“单价”“计量单位”和“产地”3个属性仅仅函数依赖于主码中的一个属性（商品代号）。由于存在部分函数依赖，因此这个关系不是2NF。
例4．2 规范化关系模式SCD（Sno，Sn，Sex，Age，Dept，DHead，Cno，Cn，Score）。
分析 在介绍完全函数依赖的概念时，对它所作分析表明，其Sn，Age，Dept，DHead仅函数依赖于主码中的一个属性Sno，同时其中的Cn也是只函数依赖于主码中一个属性Cno。因此，它也不是2NF。
根据2NF的定义，要将1NF改造为2NF就是消除其中的部分函数依赖。具体办法是分解关系模式，即将一个关系模式分解为两个或多个关系模式，并使分解后所得的所有关系模式都成为2NF。
例4．3 分解订购单关系，使其成为2NF。
订购单（订购单号码，商品代号，单价，计量单位，产地，订购数量）
解 应用分解方法，得到以下结果：
订购单（订购单号码，商品代号，订购数量）
商品（商品代号，单价，计量单位，产地）
这里将一个关系模式分解成为了两个关系模式，分解后的两个关系模式显然都是2NF。“商品”关系中的主码是由一个属性构成，不存在部分函数依赖，是2NF。“订购数量”完全函数依赖于主码（订购单号码＋商品代号），是2NF。因此，分解后的关系模式是2NF。
例4．4 分解关系模式SCD，使其成为2NF。
SCD4（Sno，Sn，Sex，Age，Dept，DHead，Cno，Cn，Score）
分析 应用分解方法，得到以下结果：
SD（Sno，Sn，Sex，Age，Dept，DHead）
SC（Sno，Cno，Score）
C（Cno，Cn）
关系SD和关系C显然都是2NF了。关系SC中的非主属性“Score”必须同时取决于Sno 和Cno，即完全函数依赖于主码，属于2NF。因此，分解后的关系模式是2NF。
第二范式还有问题吗？将上面的关系SD（Sno，Sn，Sex，Age，Dept，DHead）填充数据进行观察，见表4．13所示。
表4．13 SD（Sno，Sn，Sex，Age，Dept，DHead）
容易看出，表中系主任的信息还是有大量重复存储，形成了数据冗余，同时也会引起插入、修改和删除数据时的操作异常。因此，还有必要对它进行进一步的处理以提高其范式等级。
3）第三范式（3NF）
上面的关系SD（Sno，Sn，Sex，Age，Dept，DHead）之所以还存在数据冗余和操作异常的问题，是因为这个关系里面的属性存在间接依赖的情况，即系主任（DHead）通过系部名（Dept）依赖于主码学号（Sno）。
定义：如果一个关系满足第二范式的要求，并且该关系模式中的每一个非主属性都不传递依赖于主码，则该关系模式属于第三范式。
对于存在传递依赖的2NF关系模式，通过关系分解消除传递函数依赖就可以将其提高为3NF。
例如，上面的SD（Sno，Sn，Sex，Age，Dept，DHead），可分解如下：
S（Sno，Sn，Sex，Age，Dept）
D（Dept，DHead）
注意：这里选择系部名（Dept）作为关系D的主码是因为同一个学校不会设置两个同名的系部，即系部名具有唯一性。
具备函数依赖和关系规范化的知识，就可对从概念模式转换而来的关系模式进行范式分析了。
例4．5 某同学从学生信息管理E-R模型转换出来的关系模式如下：
SCD（Sno，Sn，Sex，Age，Dept，Class，DHead，Cno，Cn，Score）
SDD（Sno，Dept，Dorm，Dormphone，Resp，Totalroom）
Teacher（Tno，Tn，Sex，BirthDay，Dept，DHead，Cno，Cn，Dct）
Course（Cno，Cn，Credit，Ct，Tno，Tn）
Department（Dept，Office，Phone，DHead，Dorm）
试分析其函数依赖关系，并进行规范化处理。
解 ①考察关系SCD（Sno，Sn，Sex，Age，Dept，Class，DHead，Cno，Cn，Score）中存在的问题并对其进行规范化：
存在部分函数依赖，Cn，Score只是函数依赖于主码中的Cno。其实，Cno，Cn，Score描述的是学生选修课程及其成绩数据，因此把它从这个关系模式中分离出来，构成一个新的关系：
SCa（Sno，Cno，Cn，Score）
关系中的属性学号Sno是必不可少的，它和课程号Cno组合为该关系的主码。
关系SCa还包含部分函数依赖，即课程名Cn与主码中的学号Sno是不存在函数依赖关系的，因此要进一步分解：
SC（Sno，Cno，Score） （a）
C（Cno，Cn） （b）
存在传递函数依赖，系主任DHead通过系名Dept传递依赖于学号Sno。将系部的信息分解出来：
Department（Dept，DHead） （c）
这样关系SCD中就只剩描述学生的信息，即
S（Sno，Sn，Sex，Age，Dept，Class） （d）
②考察关系SDD（Sno，Dept，Dorm，Dormphone，Resp，Totalroom）中存在的问题并对其进行规范化处理：
存在传递依赖，宿舍区Dorm通过系部名Dept依赖于Sno，将反映宿舍区信息的关系分解出来：
Dormitory（Dorm，Phone，Resp，totalroom） （e）
③考察关系Teacher（Tno，Tn，Sex，BirthDay，Dept，DHead，Cno，Cn，Dct）中存在的问题并对其进行规范化处理：
该关系实际包含了教师信息和教师任课信息，与前面分析过的关系SCD类似，它也存在着部分函数依赖和传递函数依赖。
Tno，Tn，Sex，BirthDay和Dept等依赖于主码的一部分Tno。Cn，Dct依赖于主码的另一部分Cno。DHead传递依赖于Sno。将该关系分解为反映教师信息的关系Teacher和反映教师任课的关系TC：
Teacher（Tno，Tn，Sex，BirthDay，Dept） （f）
TC（Tno，Cno，Dct） （g）
④考察关系Course（Cno，Cn，Credit，Ct，Tno，Tn）存在的问题并对它进行规范化处理：
这个关系想要反映课程及其任课教师的信息，但是里面又包含有部分函数依赖，即Cn，Credit，Ct依赖于主码中的一部分Cno；同时Tn也只是函数依赖于Tno。由于前面的关系式（g）就是反映教师任课信息的，因此这里就只需要分解出反映课程信息的关系：
Course（Cno，Cn，Credit，Ct） （h）
⑤分析和规范化关系Department（Dept，Office，Phone，DHead，Dorm）：
该关系反映的是系部信息。该关系的主码只有一个属性Dept，不存在部分函数依赖。Of-fice，Phone和DHead函数依赖于Dept是显然的；同时，根据语义“一个系部的学生住在一个宿舍区”，因此主码Dept与宿舍区Dorm之间是Dept→Dorm，即也不存在传递函数依赖。因此该关系是一个第三范式，不需分解，即
Department（Dept，Office，Phone，DHead，Dorm） （i）
将上述各个分解出来的关系模式集中进行综合：
SC（Sno，Cno，Score）（a）
C（Cno，Cn） （b）
Department（Dept，DHead） （c）
S（Sno，Sn，Sex，Age，Dept，Class） （d）
Dormitory（Dorm，Phone，Resp，Totalroom） （e）
Teacher（Tno，Tn，Sex，BirthDay，Dept） （f）
TC（Tno，Cno，Dct） （g）
Course（Cno，Cn，Credit，Ct） （h）
Department（Dept，Office，Phone，DHead，Dorm） （i）
其中，关系式（b）和关系式（h）都是反映课程信息的，但是关系式（b）中信息不全，故保留关系式（h）。关系式（c）和关系式（i）都是反映系部信息的，放弃信息不全的关系式（c）。
故得“学生管理数据库”的关系模型：
SC（Sno，Cno，Score）
S（Sno，Sn，Sex，Age，Dept，Class）
Dormitory（Dorm，Phone，Resp，Totalroom）
Teacher（Tno，Tn，Sex，BirthDay，Dept）
TC（Tno，Cno，Dct）
Course（Cno，Cn，Credit，Ct）
Department（Dept，Office，Phone，DHead，Dorm）
经过以上分析和分解，所得到的关系模式都是达到第三范式要求的3NF。
4）其式更高的范式
前面已经学习、讨论了第一范式、第二范式和第三范式的知识以及采用关系模式分解提高其范式等级的方法，并应用这些知识和方法对“学生管理数据库”的关系模型进行了分析和规范化。
除第一范式、第二范式和第三范式之外，1974年，Codd和Boyce又共同提出了一个新的范式的概念，即Boyce-Codd范式，简称BC范式。1976年Fagin提出了第四范式，后来又有人定义了第五范式。
至此在关系数据库规范中建立了一个范式系列：1NF，2NF，3NF，BCNF，4NF和5NF，一级比一级有更严格的要求，如图4．13所示。
2NF—BCNF都是在函数依赖范畴内讨论关系模型的问题。其中，2NF，3NF讨论的是非主属性对码的部分依赖和传递依赖，而BCNF解决的是主属性对码的部分依赖和传递依赖。
图4．13 各种范式之间的关系
在函数依赖范畴，BCNF已经实现了彻底的分离，消除了插入异常和删除异常。
通常来说，在对关系模式进行分析和规范化处理时，达到3NF基本就足够了。但是，3NF有时仍然存在着数据冗余、操作异常的问题。这时可对它进一步分解，使其达到BCNF。
对于超出函数依赖的多值依赖问题就需要应用更高的4NF，5NF理论进行分析和规范化。
4．2．4 关系的完整性
数据结构、数据完整性和数据操作是数据模型的三要素。
关系模型的完整性规则是对关系施以某种约束的条件，它限制关系的值在变化中应该满足一定的条件。约束反映了现实世界的要求。例如，人的性别这一属性的取值就是“男”或“女”。
关系模型中的完整性约束分为3个类型：实体完整性、参照完整性和用户定义的完整性。其中，实体完整性和参照完整性是关系数据模型必须满足的、应由关系系统自动支持的，被称为关系的两个不变性。
（1）实体完整性
实体完整性是指一个关系必须有一个主码（或称主键、主关键字），它能唯一地标识关系中的每一个元组，并且不允许为空值（NULL）。在关系数据库中，一个关系就是一张二维表，因此实体完整性也被称为表完整性。
实体完整性规则———若某属性是基本关系的主属性，则它不能取空值。
空值（NULL）就是“不确定”或“不存在”。
如果主码是由若干属性组合而成的，则这些属性都不能取空值。
一个基本关系通常对应于现实世界中的一个客观事物，如果其主码为空值，则表示它是不可识别的，即不可区分的，而这与现实世界的事实是矛盾的，可见表完整性实质上体现的是现实世界中的实体的完整性。
（2）参照完整性
参照完整性也称为引用完整性，是针对表与表之间的联系而言的。在现实世界中，实体之间往往存在着联系，如学生实体和系部实体。在关系模型中实体以及实体之间的联系都是用关系来描述的，因此，关系与关系之间必然存在着引用。“学生”实体和“系部”实体的关系为
学生（学号，姓名，性别，出生日期，系部名，宿舍区）
系部（系部名，办公地址，联系电话，系主任）
其中，带下画线的属性是主码。不难看出，学生关系引用了系部关系的主码“系部名”，学生关系中的属性“系部名”的取值必须是出自系部关系中的“系部名”，不能超出其外。这反映了“学生必须属于某个确实存在的系”这样一种现实世界中学生与系部的联系情形。
定义：如果关系R2的一个或一组属性X不是R2的主码，而是另一关系R1的主码，则该属性或属性组合X称为关系R2的外部关系键或外码（Foreign key）。并称关系R2为参照关系（referencing relation），关系R1为被参照关系（referenced relation）。
这样学生关系中的“系部名”就是它的外键，学生关系为参照关系，系部关系是被参照关系。
又如，教师关系为
教师（教师号，姓名，性别，出生日期，职称，系部名）
其中的属性“系部名”也是它的外部键，系部关系是被参照关系。
对于学生选修课程的关系———选课见表4．14。
表4．14 选课
只能选择学号＋课程作为它的主键，其关系模式记为
选课（学号，课程号，成绩）
学号和课程号都是它的外部键，分别参照了“学生”关系和“课程”关系。
除了主键、外键这两个术语之外，相应地在设计和建立参照完整性时还要用到以下两个术语：
①主键表。是指主键所在的表，也就是被参照的表。如上面的学生表、课程表。
②外键表。是指外键所在的表，即参照表。如上面的选课表。
参照完整性规则：若属性（或属性组）F是基本关系R的外键，它与基本关系S的主码K相对应，则对于R中的每个元组，其在F上的值必须等于S中某个元组的主码值。
对这个规则，请大家以学生表和系部表为例进行分析和理解。
（3）用户定义的完整性
用户定义的完整性是针对某一个具体的关系数据库设置的约束条件。
用户定义的完整性是指在具体的关系数据库中往往还有一些数据必须满足的语义要求。例如，要求学生关系、教师关系中的“性别”属性只能是“男”或者“女”；对于选课关系中的“成绩”属性要求必须为0～100分，等等。用户可以使用RDBMS提供的定义和检验这类完整性的机制，保证数据符合这类完整性要求。
4．2．5 数据类型
SQL语言中提供的数据定义语言（DDL）用来定义和撤销基本表、视图和索引等数据库对象。在定义表的各个属性（列）时要求指明数据类型。数据类型的属性包括类型名称、存储数据值的空间长度、数值的精度和小数位数（小数点不计在内）。SQL Server定义了一系列的系统数据类型供用户选用，用户在此基础上还可以根据需要创建自己的数据类型。表4．15是SQL Server中的基本数据类型。
表4．15 SQL Server的基本数据类型
续表
注：1．Bit数据可以表示字符串值TRUE和FALSE，TRUE转换为1，FALSE转换为0。
2．精确的小数数据类型decimal［（p［，s］）］和numeric［（p［，s］）］，p表示精度（最多可存储的十进制数字的总位数，包括小数点前后的位数）。该精度必须是从1到最大精度38之间的值。默认精度为18。s是表示小数位数，即小数点右边可以存储的十进制数字的最大位数。小数位数必须是从0到p之间的值。仅在指定精度后才可指定小数位数。默认的小数位数为0。
3．日期和时间数据的格式：默认的日期格式为yyyyy-mm-dd。［m］m，dd和［yy］yy表示月、日和年，使用斜线（／）、连字符（-）或句点（．）作为分隔符。可以设置成myd，dmy，ydm，myd，dym形式。设置命令的格式如下：SET DATEFORMAT｛format｜＠format＿var｝
式中，format｜＠format＿var即日期的格式。
4．3 任务小结
本次任务主要完成了从E-R模型导出关系模型的方法，同时也完成关系模型的规范化以及物理模型的设计。
通过学习和应用，完成了“学生管理数据库”的概念设计、逻辑设计和物理设计。
函数依赖用于描述关系模式中属性之间的关系，函数依赖的类型分为完全函数依赖、部分函数依赖和传递函数依赖。它们是分析和规范化关系模式的基础。
关系模式的范式分为第一范式、第二范式、第三范式、BCNF等。第一范式是达到了列的原子性、元组的唯一性的关系。第二范式是消除了第一范式中的部分函数依赖。第三范式是消除了第二范式中的传递函数依赖。1NF，2NF中都存在着数据冗余、操作异常等问题。操作异常主要有数据插入异常、更新异常和删除异常。数据冗余不仅仅是耗用存储空间，更严重的问题是存在导致数据库数据不一致的隐患。一般而言，关系模式必须达到3NF。
4．4 练习与实训
（1）选择题
从ABCD 4个答案中选出符合题意的一个或多个答案。
①在设计不好的关系模式中，存在的存储异常情况指（ ）。
A．删除异常 B．插入异常
C．插入异常、数据冗余、删除异常、更新异常 D．查询异常
②设R是一个关系模式，如果R中的每一个属性值都是不可分解的，则（ ）。
A．R∈1NF B．R∈2NF C．R∈3NF D．R∈4NF
③设R是一个1NF的关系模式，如果R中的每一个属性都是完全函数依赖于主属性的，则（ ）。
A．R∈1NF B．R∈2NF C．R∈3NF D．R∈4NF
④由数据库系统自动支持的完整性规则有（ ）。
A．用户自定义完整性 B．参照完整性和实体完整性
C．参照完整性 D．实体完整性、参照完整性和用户自定义完整性
⑤关系数据表的关键字可由（ ）字段组成。
A．一个 B．两个 C．多个 D．一个或多个
⑥设表R1的结构为（学生号，姓名，性别，班级号），关键字是学生号，表R2的结构为（班级号，班级名，班主任），关键字为班级号，则（ ）。
A．班级号为R2的外码 B．班级号为R1的主码
C．学生号为R1的外码 D．班级号为R1的外码
⑦有关“选课表”（学号，课程号，成绩）的主码，说法正确的是（ ）。
A．只有一个主码，即学号
B．只有一个主码，即课程号
C．只有一个主码，它由学号和课程号一起组成
D．有两个主码：一个是学号，另一个是课程号
⑧SQL Server 2005中的数据类型不包含（ ）。
A．时间日期型 B．二进制型 C．音频型 D．货币型
⑨对学生基本信息表的“性别”列而言，最合理的数据类型是（ ）。
A．int B．char（2） C．bit D．smallint
⑩以下哪些属于数据库的逻辑模型？（ ）
A．关系模型 B．层次模型
C．网状模型 D．面向对象模型
（2）简答题
①什么是实体？什么是实体的属性？什么是实体的码？术语“联系”的含义是什么？联系有哪几种类型？
②E-R模型描述什么？它的图形符号有哪几种？
③列表对比E-R模型和关系模型中常见术语的含义。
④简述SQL Server的char和varchar的区别，并说明其应用范围。
（3）实训题
实训任务1：华龙社区图书室要建立图书借阅管理数据库，该数据库定名为“华龙图书室”（HL＿Lib）。主要想实现对藏书和借阅活动的数据管理。其管理流程和办法是采购回来的所有图书先标印唯一的书号，然后把书号、类别、书名、作者、出版社、出版时间和定价等图书信息登记到藏书登记表Books中；社区居民凭读书卡借阅图书，读者信息记录在读书卡Readers中，其信息包含卡号、姓名、性别、出生日期、文化程度、服务行业和联系电话；借还登记表Borrow中的信息包含卡号、书号、借书时间、还书时间、赔偿金额。借书时登记卡号、书号、借书时间，还书时登记还书时间。损坏或遗失图书时须由工作人员按相关标准计算赔偿额，然后填入借还登记表中。规定居民可以借阅所有图书。请完成该数据库的需求分析和概念模型（E-R图）设计。
实训任务2：根据实训任务1所得出的“华龙图书室”数据库的概念模型（E-R图）。
①将其转换为逻辑模型并规范化为第三范式；
②根据逻辑模型设计各个基本表的结构，包括数据类型和完整性约束等。