下载掌阅APP，畅读海量书库
立即打开
在关系模型中，无论是实体还是实体之间的联系均用关系（Relation）来表示。由于关系模型是建立在集合代数基础上的，因此一般从集合论的角度对关系进行定义。
1.域
域（Domain）是一组具有相同数据类型的值的集合。例如，整数、实数、介于某个取值范围的整数、指定长度的字符串集合、介于某个时间段的日期、{'男'，'女'}等等，都可称为一个域。
2.笛卡儿乘积
给定一组域 D 1 ， D 2 ，…， D n ，这些域中可以有相同的部分，则 D 1 ， D 2 ，…， D n 的笛卡儿乘积（Cartesian Product）为
D 1 × D 2 ×…× D n ={（ d 1 ， d 2 ，…， d n ）| d i ∈ D i ， i =1，2，…， n }
式中，笛卡儿乘积中每一个元素（ d 1 ， d 2 ，…， d n ）称为一个 n 元组 （ n -Tuple），简称为 元组 （Tuple）。笛卡儿乘积元素（ d 1 ， d 2 ，…， d n ）中的每一个值 d i 称为一个 分量 （Component）。
由此可见，笛卡儿乘积是 D 1 ， D 2 ，…， D n 这些域所有取值的组合构成的集合。
思考 ：在笛卡儿乘积中是否会出现相同的元组？笛卡儿乘积所具有的元组个数一定是有限的吗？
一个集合中包含的元素个数称为 基数 （Cardinal Number）。若 D i （ i =1，2，…， n ）为有限集合，其基数为 m i （ i =1，2，…， n ），笛卡儿乘积 D 1 × D 2 ×…× D i × …× D n 的基数为 M ，则
【例4.1】 给定三个域： D 1 =研究生导师={'汤友德'，'林娜'}， D 2 =专业={'工商管理'，'软件工程'}， D 3 =研究生={'刘星'，'关文清'，'张蔷'}，则 D 1 、 D 2 、 D 3 的笛卡儿乘积为
该笛卡儿乘积包含（'汤友德'，'工商管理'，'刘星'）、（'林娜'，'软件工程'，'张蔷'）等元组共2×2×3=12个，即该笛卡儿乘积的基数为12。每个元组具有3个分量。若使用二维表来表示该笛卡儿乘积，见表4.1。表4.1中的每一行表示一个元组，每一列表示一个分量。
表4.1 笛卡儿乘积的二维表表示
3.关系
由表4.1可见， D 1 × D 2 × D 3 可以构造出一个“完整”的表，即包含“研究生导师指导学生”所有可能出现的情况。然而，事实上，每一个研究生只能就读一个专业、师从一位导师，因此， D 1 × D 2 × D 3 中的大部分元组是没有实际意义的。如果事实是刘星和张蔷就读软件工程专业并师从汤友德，关文清就读工商管理专业并师从林娜，我们从表4.1中抽取与事实对应的元组构造一个表（见表4.2），则这个与事实对应的笛卡儿子集就是一个关系。
表4.2 “研究生导师指导学生”关系
关系的数学定义如下：给定一组域 D 1 ， D 2 ，…， D n ，笛卡儿乘积 D 1 × D 2 ×…× D n 的子集称为在域 D 1 ， D 2 ，…， D n 上的关系，表示为 R （ D 1 ， D 2 ，…， D n ），其中， R 为关系名， n 是关系的度或目（Degree）。当 n =1时，称关系为单元关系（Unary Relation）；当 n =2时，称关系为二元关系（Binary Relation）。由于笛卡儿乘积可组织成一个二维表，关系作为笛卡儿乘积的子集，也是一个二维表，即二维表就是关系模型的基本数据结构。在这个二维表中，每一行称为一个 元组 （Tuple），每一列称为一个 属性 （Attribute），关系中元组的一个属性值称为 分量 （Component）。例如，表4.2这个关系中有3个元组，有3个属性，（'汤友德'，'软件工程'，'刘星'）是一个元组，它包含3个分量。
思考 ：关系中是否会出现相同的元组？关系所具有的元组个数一定是有限的吗？
1.超键
若关系中的某一属性或属性组的值能唯一地标识一个元组，则称该属性或属性组为关系的 超键 （Super Key） 。
【例4.2】 假设有“学生”关系如下：学生（身份证号码，学号，姓名），那么该关系中有多少个超键？
【解答】 该“学生”关系一共有6个超键，分别是：身份证号码，学号，（身份证号码，姓名），（学号，姓名），（身份证号码，学号），（身份证号码，学号，姓名）。
2.候选键
若关系中的某一超键，去掉其中任一属性后，均不再能为超键，则称该超键为关系的 候选键 （Candidate Key）。
【例4.3】 例4.2中的“学生”关系有多少个候选键？
【解答】 该“学生”关系一共有6个超键，分别是：身份证号码，学号，（身份证号码，姓名），（学号，姓名），（身份证号码，学号），（身份证号码，学号，姓名）。在这些超键中，一共有两个可以作为“学生”关系的候选键，分别是身份证号码和学号，其余的超键都不能作为“学生”关系的候选键。例如，对于超键（身份证号码，姓名），去掉了姓名属性后，身份证号码属性仍为“学生”关系的超键，因此超键（身份证号码，姓名）不能作为“学生”关系的候选键。同理，（学号，姓名）、（身份证号码，学号）和（身份证号码，学号，姓名）也不能作为“学生”关系的候选键。
由此可见，一个关系的候选键是该关系超键中不存在冗余属性的元组的唯一标识符。
最简单的情况是候选键只包含一个属性，在这种情况下，称该候选键是 单属性键 。若候选键是由多个属性构成的，则称它为 多属性键 。若关系当中只有一个候选键，且这个候选键包含了关系的全部属性，则称其为 全键 （All-key）。在关系中，候选键中的属性称为 主属性 （Prime Attribute），不包含在任何候选键中的属性称为 非主属性 （Non-key Attribute）。
例如，设有以下关系：
学生（身份证号码，学号，姓名）
课程（课程号，课程名）
选课（学号，课程号）
“学生”关系具有两个候选键，分别是身份证号码和学号。“课程”关系中具有唯一的候选键：课程号。“选课”关系具有唯一的候选键：属性组（学号，课程号）。因此，“学生”关系和“课程”关系的候选键都是单属性键，而“选课”关系的候选键是多属性键。由于“选课”关系的候选键（学号，课程号）包含了该关系的全部属性，因此（学号，课程号）就是全键。在“学生”关系中，身份证号码和学号是主属性，姓名是非主属性。在“课程”关系中，课程号是主属性，课程名是非主属性。“选课”关系中没有非主属性。
3.主键
为了方便管理数据，在关系的候选键中选定一个作为元组的唯一标识符，称为 主键 （Primary Key）。在一个关系中，候选键可能有多个，而主键只有一个。例如，在例4.3的“学生”关系中，可选择身份证号码或者学号作为主键。
4.外键
若关系 R 的某个属性或属性组 A 不是 R 的候选键，却是另一个关系 S 的候选键，则称 A 为 R 的 外键 （Foreign Key）。
例如，设有以下关系：
学生（身份证号码，学号，姓名）
课程（课程号，课程名）
选课（学号，课程号）
课程号是“课程”关系的候选键，在“选课”关系中课程号不是候选键，则是“选课”关系的外键。同理，学号也是“选课”关系的外键。
关系模式（Relation Schema）是对关系的描述，可以形式化地表示为
R （ U ， D ，Dom， F ）
式中， R 为关系名， U 是组成该关系的属性集合， D 是属性组 U 中属性所来自的域，Dom为属性向域映射的集合， F 是属性间的数据依赖关系的集合（关于数据依赖的问题将在第6章专门探讨）。例如，表4.2“研究生导师指导学生”关系中研究生导师与研究生都来自同一个域——人名，在关系模式中可定义研究生导师和研究生向人名的映射，即
Dom（研究生导师）=Dom（研究生）=人名
关系模式通常可以简单记为 R （ U ）或 R （ A 1 ， A 2 ，…， A n ），其中， R 为关系名， A 1 ， A 2 ，…， A n 为属性名，域或属性向域的映射通常直接用属性的类型、长度来说明。
关系模式是对关系的框架或结构的描述，是“型”，是静态的、相对稳定的，在关系设计过程中一旦关系确定下来，一般不随意更改。关系是关系模式在某一时刻的状态或内容，是与数据取值相关联的，是“值”，是动态的、易变的。随着用户对数据不断执行增加、删除或修改等操作，关系的内容会不断变化。
在一个给定的应用领域中，所有实体以及实体之间联系的关系的集合构成了一个关系数据库。关系数据库也有型和值的区别。关系数据库模式即关系数据库的型，是对关系数据库的描述，它包含若干域的定义以及在这些域上定义的若干关系模式。这些关系模式在某一时刻对应的关系的集合就是关系数据库的值，通常简称为关系数据库（Relational Database）。
在关系模型中对关系做了一些规范化限制，要求在数据库中的关系必须满足以下性质：
1.分量原子性
关系中每一个元组的分量都是不可分割的数据项，不允许表中有表。在现实生活中我们经常会像图4.1a这样组织数据，但这不符合关系的规范化定义。在设计数据库的过程当中，如遇到这种情况，必须要将表中嵌套的表拆分，直到每个元组的分量都不能再分为止，如图4.1b所示。
图4.1 关系分量的原子性
2.元组有限性
在关系中元组的个数是有限的，即关系这个二维表的行数是有限的。由于计算机系统硬件设备的限制，在数据库技术中提到的关系皆指有限的关系。
3.元组各异性
关系中每个元组均不能相同。关系是一个集合，集合的性质决定了集合里不存在两个相同的元素。在现实生活当中不存在完全相同的两个实体，而且将同一个实体在一个二维表中重复存储也是没有意义的。
4.元组次序任意性
在关系的二维表中，元组对应行的次序可以任意交换。关系是一个集合，集合中的元素不考虑次序。元组排序的先后不会影响关系的实际含义。在实际的应用当中，为了加快检索速度，提高数据处理的效率，经常会对关系中的元组排序。这将会打乱元组的初始顺序，但对关系不会产生任何影响。
5.属性名各异性
在同一个关系的二维表中不能存在相同的属性名。属性用于表示实体的特征，重复地描述一个实体的某一特征是没有意义的。即使关系中的两个属性来自同一个域，也要为它们取不同的名字加以区分。表4.2“研究生导师指导学生”关系中研究生导师与研究生都是人名，但若这两个属性都取名为“人名”，在数据管理过程中将会引起混淆。
6.属性同质性
在关系的二维表中，同一列的数据必须是同一种数据类型且来自同一个值域。例如，在“课程”关系中，课程号的取值范围为1000～1099。即便1024指的是“计算机基础”这门课，也不能将课程号取值为“计算机基础”。
7.属性次序任意性
在定义一个关系模式时，其属性的先后次序不会影响关系的实际意义。然而，关系模式定义好之后，不能随意地调换属性值在元组中的顺序，否则，会引起歧义。如在表4.2“研究生导师指导学生”关系模式下，不能插入元组（'刘星'，'软件工程'，'汤友德'），因为这意味着刘星是汤友德的导师，与事实不符。因此，为了保证数据的准确性和有效性，在更改属性值的顺序时必须要对属性的顺序做同样的更改。