第三章关系数据库

第3章关系数据库本章学习目标本章深入地讨论了关系数据库系统的基本概念、函数的依赖关系，并在此基础上介绍了关系规范化理论，以及关系数据库的基本元素，如实体、关系、表、关键字、索引等。

通过本章学习，读者应该掌握以下内容：●掌握函数的依赖关系（完全函数依赖、部分函数依赖和传递函数依赖）●候选关键字，关键字和主属性的基本定义●关系规范化的理论，掌握范式的基本概念和分解方法3.1基本概念按关系数据模型组织的数据库是关系数据库。

其理论基础是集合代数。

按集合代数理论，关系名及其属性序列称为关系模式或关系的型。

一个元组为其所属关系模式的一个值，对应一个实体或一组联系。

元组中每一个分量对应该实体或联系的一个属性值。

例如一个关系名为RELATION，其属性有attrl，attr2，…，attrN则关系模式简单写成，RELATION(attr1，attr2,…，attrN)，其一个属性或若干属性取值的集合称为域，同一域中数据是同质的，例如性别域{男，女} ，姓名域{张，王，林，…彭}等。

各域各取一值的完全组合称为这些域的笛卡尔积。

例如图3.1所示，性别域和姓名域的笛卡尔积为C。

一般说来，域D1和域D2的笛卡尔积是一个表，其属性为原D1域和D2域所有属性的集合，其行数为D1域值的个数和D2域值个数的乘职，每一行由D1和D2各取一值组成，所有各行均不重复。

如果给定一组域D1，D2，…D n，这些域中允许有相同的。

则D1*D2*…*Dn={（d1,d2,…dn）︱di∈Di,I=1,2,…n} ,其中每一个元素（d1,d2,…dn）叫做一个N元元组，或简称为元组。

元素中的每一个值叫作元组的一个分量，也是它所对应的那个属性的一个值。

多个属性构成的关系是这些属性所属域的笛卡尔积的子集，一般说来只有其真子集才有意义。

图3.1的关系中同一位老师的性别不可能既为男又为女，因而C中只有一半元组是有意义的。

图3.1 关系的笛卡尔积按数据库理论，所有关系模式的集合（包括关系名，属性名，关键字，完整性约束和安全性要求）称为关系数据库模式，它表示一个关系数据库的逻辑结构。

关系数据库模式中所有关系模式的具体关系的集合称关系数据库。

关系数据库模式是数据的型的表示，而关系数据库则是数据的值的表示。

数据库中的关系应具备如下性质：1.每一列中的分量来自于同一个域，是同一类型的数据。

2.不同的列可来自于同一个域，每一列称为属性，要给予不同的属性名。

3.列的顺序的改变不改变关系。

4.在一个关系中任意两个元组不能全同。

5.元组次序可以任意交换而不改变关系。

6.每一分量必须是不可再分的数据项，即具有原子性，表1.9所示的重复组、向量和表1.10所示重复组结构都是关系不允许的结构。

3.2 函数依赖3.2.1 函数依赖概念关系理论中函数依赖是指关系中属性间的对应关系。

如关系中对于属性（组）X的每一个值，属性（组）Y只有唯一的值与之对应，则称Y函数依赖于X，或称X函数决定Y。

记作X→Y 。

其中，X称为决定因素。

例如表1.2所示“系”关系中：系代码→系名，系代码→系地址，系代码→系电话，系代码→系专业设置如果系名值是唯一的，即各系名均不相同，那么还有函数依赖集还可加入：系名→系代码，系名→系地址，系名→系电话，系名→系专业设置显然系地址对任何其他属性皆不是决定因素，因为系地址为“机电二楼”时对应任何属性都有两个不同值。

决定因素可能为两个以上属性构成的属性组。

例如在表1.7的“成绩”关系中，课程号不是决定性因素，每门课都有许多学生学，同一个课程号有多个学号、多个分数与之对应。

学号也不是决定性因素，同一个学生要学习多门课程，因此一个学号有多个课程号，有多个分数值与之对应。

只要每个学生每门课只有一个成绩，那么学号和课程号的值的集合在这个表中就是唯一的，任何两个元组中学号与课程号的值都不会相同，只要学号和课程号都确定，与之对应的分数值也唯一确定。

因此，学号+课程号→分数。

在表1.6“课程”关系中只有两行的课程名是相同的，但也因此存在这样的情况，当课程名为C 语言时，课程号有两个值与之对应，因而课程名不能唯一确定课程号。

我们在分析函数依赖时一定要全面分析了解在实际应用中属性和属性组全部取值可能，只要存在一个元组的某个属性值不能唯一决定另一个属性的值，另一个属性对这个属性的函数依赖关系就不成立。

在一个关系中，如果一个属性（组）值不唯一，则这个属性（组）与任何属性（组）的函数依赖关系中，它都不是决定因素。

3.2.2 部分函数依赖在一个关系中，可分析出许多依赖关系，但存在依赖程度的不同。

例如表1.6中，显然有课程号→课程名,课程号→开课教研室代码。

从另一角度看，只要课程号一定，同时课程名确定，开课教研室也就唯一确定。

因此课程号＋课程名→开课教研室代码。

但它与前述课程号→开课教研室代码是不同的，因为{课程号，课程名}存在真子集：“课程号”，课程号→开课教研室代码。

我们把课程号＋课程名→开课教研室代码称为“开课教研室代码”部分函数依赖于课程号十课程名。

定义部分函数依赖为：若X,Y 为关系R 中的属性(组)，如X →Y 且X 中存在真子集X ’(X ’≠X ∧X ’∈X)，满足X ’→Y ，则称Y 部分函数依赖于X ，记作X ｐ→Y 。

因而表1.6中（课程号＋课程名）ｐ→ 开课教研室代码。

3.2.3 完全函数依赖如X,Y 是关系R 中属性(组)，X →Y 的任何真子集X’（X’≠X ∧X’∈X ），都有X’ Y ，则称Y 完全函数依赖于X Y 。

我们前面所举的函数依赖例子中，除了“课程号＋课程名”与其他属性之间的函数依赖之外的函数依赖皆为完全函数依赖。

3.2.4 传递函数依赖在一个学校中，每门课均是某一位老师教，但有些老师可教多门课，则有关系“教学”如下所示：表3.1 教学表由以上关系不难分析，课程名→职工号、职工号课程名，但职工号和其地属性的函数关系中都是决定因素，即职工号→老师名、职工号→性别，在这种情况下，职称、老师名传递函数依赖于课程名。

一般说来，如X、Y为关系R中属性（组），有X→Y，Y X但Y →Z，则称Z传递函数依赖于X,记作XＴ→Z。

上例中有：课程名Ｔ→职称；课程名Ｔ→老师名。

3.3 候选关键字与主属性3.3.1 候选关键字在前面我们曾给关键字定义：在关系R中，如属性(组)X唯一标识一条记录，则X称为关系R 的关键字，显然这个定义是不严密的。

从前面例中我们看到“课程号＋课程名”能唯一标识一条记录，因为课程号就能唯一标识一条记录，课程号是关键字，课程号与课程名的集合不是关键字。

关键字的更严密定义是：在关系R中如记录完全函数依赖于属性(组)X，则称X为关系R中的一个候选关键字。

在表1.2中，“系代码”是关系“系”的候选关键字，表1.4中“职工号”是关系”教师”的候选关键字。

在表1.7“成绩”关系中，“学号+课程号”是候选关键字。

候选关键字有如下性质：1.在一个关系中，候选关键字可以有多个。

例如表1.2的系关系中，系代码、系名都是候选关键字。

2.任何两个候选关键字值都是不相同的，因为若有两条记录候选关键字的值相同，它和记录的关系就不是决定因素。

在实际应用中，只有在任何情况下值皆不重复的属性(组)才有可能是候选关键字。

由于同名同姓的人很多，在人事管理中，姓名一般不是候选关键字，我们需要设计代码例如“职工号”作为人事关系的关键字。

3.关键字可能由一个属性构成，也可能由多个属性构成。

关键字不可能再与其他的属性构成新的候选关键字。

我们分析一个关系中有哪些候选关键字时，一般首先一个个属性逐一分析判断，再两两判断，三三判断……等。

4.在任何关系中至少有一个关键字。

因为根据关系的基本要求，在一个关系当中任何二个元组不全同。

因而在一个N元关系当中如单个属性都不是关键字，任何两个属性的属性组也不是关键字，任何K (K<N)个属性的属性组都不是关键字，则该关系全部属性构成的属性组是其关键字。

3.3.2 主属性在一个关系中，如一个属性是构成某一个候选关键字的属性集中的一个属性，则称它为主属性。

如一个属性不是构成该关系任何一个候选关键字的属性集的成员，就称它为非主属性。

例表1.7中，“学号+课程号”是关键字，那么“学号”是主属性，“课程号”是主属性，分数是非主属性。

3.4 关系规范化3.4.1问题的提出设计关系数据库时，一种方法是分析并找出E-R模型再转换为关系数据模型,最后求取关系模式。

称为自上而下设计方法。

另外也有采用自下而上设计方法的。

其方法是首先收集应用对象全部表格、凭证等各类数据，对它们的所有栏目归纳分类。

例如，人事部门的数据表有：●人事卡片，栏目有：职工号、姓名、性别、出生日期、职务、职称、基本工资、政治面貌、所在部门、入校时间，还有爱人有关情况：爱人姓名、单位地址、性别、出生日期…，有社会关系情况：姓名、与本人关系、出生日期、地址…。

●人员报表，栏目有：姓名、性别、年龄、职务、职称、部门、政治面貌。

有关职称职务工资计算办法，例如：处长800元，副处长740元，科长700元…，教授1000元，副教授900元…，同一职工如有职务又有职称，则职务工资取两个标准较高者。

财务部门有工资单，栏目有部门名、姓名、基本工资、职务工资、考勤补扣、行政费补扣、公积金等。

还有其他一些凭证、收据、发票、报表文件等。

对所有表的所有栏目汇总并经过分析可知所在部门、部门和部门名是同一概念，定义完全相同，可统一称之为部门名，年龄可由系统当前日期及出生日期计算得到，年龄依不同年份而不同，但一个人出生日期是只有一个值且不会改变。

职务工资可从职务、职称及有关职务工资计算办法求得。

由此我们可知，人事报表数据源来自人事卡片，工资单有部分数据源来自人事卡片，另有一些数据与生产部门、行政部门相关，且有各自计算方法。

最终可设想系统由三个关系构成：人事卡片（职工号，姓名，性别，出生日期，职务，职称，基本工资，政治面貌，部门名，参加工作时间，爱人名，爱人性别，爱人生日，爱人职务，爱人职称，爱人单位，爱人地址，关系人姓名，关系人年龄，关系人性别，与本人关系，关系人单位，关系人地址）考勤表(职工号，加班天数，早班数，中班数，晚班数，病假天数，旷工天数)行政收费表（职工号，房租费，水电费，电话费，行政扣除，行政奖励）但在按此模式建立数据库后在录入数据时发现有几个问题：①在使用中，对爱人情况和社会关系有关数据查找取用次数极少。

②不少人尚未结婚，但表中仍需留下大量空位，使数据库文件规模扩大，影响效率。

③不少人社会关系人很多，如要对关系人利用数据库系统进行查找，必须对不同关系人数据分段存放，如表3.2所示。

表3.2 人事卡片表显然一个职工数据多行重复存放，出现了严重冗余。

这种冗余使表格文件规模增加了数倍，使检索速度降低，在数据录入和修改时需同时修改多处相关数据，工作量大且易出错。