数据库知识点总结（第三讲 关系模型之基本概念）

第三讲 关系模型之基本概念

1、关系模型概述

（1）关系模型的提出

• 最早由E.F.Codd在1970年提出
• 是从表（Table）及表的处理方式中抽象出来的，是在对传统表及其操作进行数学化严格定义基础上，引入集合理论与逻辑学理论提出的
• 是数据库的三大经典数据模型之一，也是现在大多数商品化数据库系统所仍然使用的数据模型
• 标准的数据库语言（SQL语言）是建立在关系模型基础之上的，数据库领域的众多理论也都是建立在关系模型基础之上的

（2）关系模型研究什么

• 形象的说，一个关系（relation）就是一个Table
• 关系模型就是处理Table的，它由三个部分组成：
• • 描述DB各种数据的基本结构形式（Table/Relation）
  • 描述Table与Table之间所可能发生的各种操作（关系运算）
  • 描述这些操作所应遵循的约束条件（完整性约束）
• 就是要学习：Table如何描述，有哪些操作、结果是什么、有哪些约束等？

（3）关系模型的三要素

关系模型的三个要素（详细内容在后面讲述）

• 基本结构：Relation/Table
• 基本操作：Relation Operator

• 完整性约束：实体完整性、参照完整性和用户自定义的完整性

（4）关系模型与关系数据库语言的关系

• 关系运算：关系代数和关系演算；
• 关系演算：元组演算和域演算
• 关系代数示例：基于集合的运算
• 即：操作的对象及结果都是集合，是一次一集合（Set-at-a-time）的操作。而非关系型的数据操作通常是一次一记录（Record-at-a-time）的操作

• 基于关系代数设计的数据库语言（ISBL）：用计算机可识别的符号表征关系代数的运算符号

• 元组演算示例：基于逻辑的运算
  

• 基于元组演算设计的数据库语言（Ingres系统的QUEL）：用于计算机可识别的符号表征元组演算的运算符号

​ range of t is R

​ range of u is W

​ retrieve t

​ where t.sage < u.sage

• 域演算示例：基于示例的运算
  

• 基于域演算设计的数据库语言示例：（QBE：Query By Example)

（5）为什么要学习关系模型与关系数据库语言

（6）即将学习的内容概述

• 理解关系（relation），理解如何用Relation对Table进行抽象或说严格定义
• 理解关系/表（relation/table）所具有的各种特性，理解关系模型
• 熟练掌握关系代数、元组演算和域演算（域演算以QBE为例来学习），用这些关系运算来表达各种复杂的检索需求，以便于后续SQL语言的学习
• 本讲将要学习：关系、关系模型的完整性
• 后续两讲将要学习：关系代数和元组演算

2、什么是关系

（1）什么是“表”

为什么把“表”称为关系？

怎样严格定义一个“表”？

“表”和“关系”有什么异同？

（2）“表”的基本构成要素

如何严格地定义Table呢？

（3）“表”的严格定义——关系

首先定义“列”的取值范围“域（Domain）”

域（Domain）

• 一组值的集合，这组具有相同的数据类型
• 如整数的集合、字符串的集合、全体学生的集合
• 再如，由8位数字组成的数字串的集合，由0到100组成的整数集合
• 集合中元素的个数称为域的基数（Cardinality）

再定义“元组”及所有可能组合成的元组：笛卡尔积

笛卡尔积（Cartesian Product）

• 一组域D1，D2，…，Dn的笛卡尔积为：

• 笛卡尔积的每个元素（d1，d2，…，dn）称作一个n-元组（n-tuple）

• 元组（d1，d2，…，dn）的每一个di叫做一个分量（component）
• 元组（d1，d2，…，dn）是从每一个域任取一个值所形成的一种组合，笛卡尔积是所有这种可能组合的集合，即：笛卡尔积是由n个域形成的所有可能的n-元组的集合
• 若Di的基数为mi，则笛卡尔积的基数，即元组个数为:

​ m1×m2×…×mn

由于笛卡尔积中的所有元组并不都是有意义的，因此…

关系（Relation）

• 一组域D1，D2，…，Dn的笛卡尔积的子集

• 笛卡尔积中具有某一方面意义的那些元组被称为一个关系（Relation）

• 由于关系的不同列可能来自同一个域，为区分，需要为每一列起一个名字，该名字即为属性名

• 关系可用R（A1：D1，A2：D2，…，An：Dn）表示，可简记为R（A1，A2，…，An），这种描述又被称为关系模式（Schema）或表标题（head）
• R是关系的名字，Ai是属性，Di是属性所对应的域，n是关系的度或目（degree），关系中元组的数目称为关系的基数（Cardinality）
• 例如下图的关系为一3目关系，描述为
• • 家庭（丈夫：男人，妻子：女人，子女：儿童）或家庭（丈夫，妻子，子女）

• 关系模式R（A1：D1，A2：D2，…，An：Dn）中属性向域的映象在很多DBMS中一般直接说明为属性的类型、长度等
• 例如：

Student（S# char(8)，Sname char(10)，Ssex char(2)，Sage integer，D# char(2)，Sclass char(6)）

再如：

Course（C# char(3)，Cname char(12)，Chours integer，Credit float (1)，T# char(3)）

SC（S# char(8)，C# char(3)，Grade float(1)）

一个字段由属性，数据类型，长度构成

关系模式与关系

同一关系模式下，可有很多的关系

关系模式是关系的结构，关系是关系模式在某一时刻的数据

关系模式是稳定的；而关系是某一时刻的值，是随时间可能变化的

Student（S# char(8)，Sname char(10)，Ssex char(2)，Sage integer，D# char(2)，Sclass char(6)）

思维回顾

（4）关系的特性

列是同质：即每一列中的分量来自同一域，是同一类型的数据

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

关系模型R（A1：D1，A2：D2，…，An：Dn）中，Ai（i = 1，…，n）必须是不同的，而Di（i = 1，…，n）可以是相同的

例，我们定义一个域为Person = 所有男人、女人和儿童的集合 = {李基，张鹏，王芳，刘玉，李健，张睿，张峰}，则下述“家庭”关系的三个列将来自同一个域Person，因此需要不同属性名“丈夫”“妻子”“子女”以示区分。

列位置互换性：区分哪一列是靠列名

行位置互换性：区分哪一行是靠某一或某几列的值（关键字/键字/码字）

关系是以内容（名字或值）来区分的，而不是属性在关系的位置来区分

如下面两个关系是完全相同的关系

理论上，关系的任意两个元组不能完全相同。（集合的要求：集合内不能有相同的两个元素）；

现实应用中，表（Table）可能并不完全遵守此特性

元组相同是指两个元组的每个分量都相同

属性不可再分特性：又被称为关系第一范式

（5）关系上的一些重要概念——候选码/候选键

候选码（Candidate Key）/候选键

关系中的一个属性组，其值能唯一标识一个元组，若从该属性组中去掉任何一个属性，它就不具有这一性质了，这样的属性组称作候选码

例如：“学生（S#，Sname，Sage，Sclass）”，S#就是一个候选码，在此关系中，任何两个元组的S#是一定不同的，而这两个元组的Sname，Sage，Sclass都可能相同（同名、同龄、同班），所以S#是候选码。

再如，“选课（S#，C#，Sname，Cname，Grade）”，（S#，C#）联合起来是一个候选码

有时，关系中有很多组候选码，例如：

学生（S#，Sname，Sage，Sclass，Saddress）

其中属性S#是候选码，属性组（Sname，Saddress）也是候选码（同名同地址的两个同学是不存在的）

再如：

Employee（EmpID，EmpName，Moblie）

每一雇员有唯一的EmpID，没有两个雇员有相同的手机号Mobile，则EmpID是候选码，Mobile也是候选码

（6）关系上的一些重要概念——主码/主键

主码（Primary Key）/主键

当有多个候选码时，可以选定一个作为主码

DBMS以主码为主要线索管理关系中的各个元组

例如可选定属性S#作为“学生”表的主码，也可以选定属性组（Sname，Saddress）作为“学生”表的主码。选定EmpID为Employee的主码。

（7）关系上的一些重要概念——主属性与非主属性

主属性与非主属性

包含在任何一个候选码中的属性被称作主属性，而其他属性被称作非主属性

如“选课”中的S#，C#为主属性，而Sname，Cname，Grade则为非主属性；

最简单的，候选码只包含一个属性

最极端的，所有属性构成这个关系的候选码，称为全码（All-Key）

比如：关系“教师授课”（T#，C#）中的候选码（T#，C#）就是全码

（8）关系上的一些重要概念——外码/外键

外码（Foreign Key）/外键

关系R中的一个属性组，它不是R的候选码，但它与另一个关系S的候选码相对应，则称这个属性组为R的外码或外键

例如“合同”关系中的客户号不是候选码，但却是外码。因它与“客户”关系中的候选码“客户号”相对应

两个关系通常是靠外码连接起来的

(9)小结

3、关系模型中的完整性

（1）实体完整性

实体完整性

关系的主码中的属性值不能为空值

空值：不知道或无意义的值

意义：关系中的元组对应到现实世界相互之间可区分的一个个个体，这些个体是通过主码来唯一标识的；若主码为空，则出现不可标识的个体，这是不容许的

（2）空值及其含义

空值的含义

• 空值：不知道、不存在或无意义的值；
• 在进行关系操作时，有时关系中的某属性值在当前是填不上的，比如档案中有“生日不详”、“下落不明”、“日程尚待公布”等，这时就需要空值来代表这种情况。关系模型中用‘？’表征
• 数据库中有了空值，会影响许多方面，如影响聚集函数运算的正确性，不能参与算术、比较或逻辑运算等
• 例如：“ 3 + ？”结果是多少呢？ “ 3 * ？”结果是多少呢？ “ ？and （A=A）”结果又是多少呢？
• 再例如，一个班有30名同学，如所有同学都有成绩，则可求出平均成绩；如果有一个同学没有成绩，怎样参与平均成绩的计算呢，是当作0，还是当做100呢？还是不考虑他呢？
• 有空值的时候是需要特殊处理的，要特别注意

（3）参照完整性

如果关系R1的外码Fk与关系R2的主码Pk相对应，则R1中的每一个元组的Fk值或者等于R2中某个元组的Pk值，或者为空值

意义：如果关系R1的某个元组t1参照了关系R2的某个元组t2，则t2必须存在

例如关系Student在D#上的取值有两种可能：

• 空值，表示学生尚未分到任何系中
• 若非空值，则必须是Dept关系中某个元组的D#值，表示该学生不可能分到一个不存在的系中

（4）用户自定义完整性

用户自定义完整性

• 用户针对具体的应用环境定义的完整性约束条件
• 如S#要求是10位整数，其中前四位为年度，当前年度与他们的差必须在4以内
• 再如：

（5）DBMS对关系完整性的支持

DBMS对关系完整性的支持

实体完整性和参照完整性由DBMS系统自动支持

DBMS系统通常提供了如下机制：

• 它使用户可以自行定义有关的完整性约束条件
• 当有更新操作发生时，DBMS将自动按照完整性约束条件检验更新操作的正确性，即是否符合用户自定义的完整性

4、小结