关系数据库

关系数据库

历史

发展历程

• 系统而严格地提出关系模型的是美国IBM公司的E.F.Codd
• 1970年提出关系数据模型
• E.F.Codd, “A Relational Model of Data for Large Shared Data Banks”, 《Communication of the ACM》,1970
• 之后，提出了关系代数和关系演算的概念
• 1972年提出了关系的第一、第二、第三范式
• 1974年提出了关系的BC范式
• 关系数据库应用数学方法来处理数据库中的数据
• 80年代后，关系数据库系统成为最重要、最流行的数据库系统

经典系统

典型实验系统

• System R

• University INGRES

典型商用系统

• ORACLE
• SQL Server
• SYBASE
• INFORMIX
• DB2
• INGRES
• MySQL

关系数据库系统

• 是支持关系模型的数据库系统,包括：
  • 关系模型的组成
  • 关系数据结构
  • 关系操作集合
  • 关系完整性约束

关系数据结构

• 单一的数据结构----关系
  现实世界的实体以及实体间的各种联系均用关系来表示
• 数据的逻辑结构----二维表
  从用户角度，关系模型中数据的逻辑结构是一张二维表。

关系操作集合

• 常用的关系操作
  查询:选择、投影、连接、除、并、交、差
  数据更新:插入、删除、修改

• 关系操作的特点
  集合操作方式，即操作的对象和结果都是集合。

关系数据语言的种类

• 关系代数语言

• 用对关系的运算来表达查询要求,典型代表：ISBL

• 关系演算语言：用谓词来表达查询要求

• 元组关系演算语言–谓词变元的基本对象是元组变量,典型代表：APLHA, QUEL

• 域关系演算语言–谓词变元的基本对象是域变量,典型代表：QBE

• 具有关系代数和关系演算双重特点的语言：SQL

关系数据语言的特点

• 关系语言是一种高度非过程化的语言
• 存取路径的选择由DBMS的优化机制来完成
• 用户不必用循环结构就可以完成数据操作
• 能够嵌入高级语言中使用
• 关系代数、元组关系演算和域关系演算三种语言在表达能力上完全等价

关系的三类完整性约束

• 实体完整性，通常由关系系统自动支持
• 参照完整性早期系统不支持，目前大型系统能自动支持
• 用户定义的完整性反映应用领域需要遵循的约束条件，体现了具体领域中的语义约束，用户定义后由系统支持

关系模型

• 关系模型建立在集合代数的基础上

  关系
  关系模式
  关系数据库

基本概念

域

域（Domain）:域是一组具有相同数据类型的值的集合。例:
整数
实数
介于某个取值范围的整数
长度指定长度的字符串集合
{‘男’，‘女’}
介于某个取值范围的日期

笛卡尔积

笛卡尔积（Cartesian Product）
给定一组域D1，D2，…，Dn，这些域中可以有相同的。D1，D2，…，Dn的笛卡尔积为：
D1×D2×…×Dn＝｛(d1，d2，…，dn)｜diDi，i＝1，2，…，n｝
所有域的所有取值的一个组合不能重复

例 给出三个域：
D1=SUPERVISOR ={ 张清玫，刘逸 }
D2=SPECIALITY={计算机专业，信息专业}
D3=POSTGRADUATE={李勇，刘晨，王敏}

则D1，D2，D3的笛卡尔积为：
D1×D2×D3 ＝
｛(张清玫,计算机专业,李勇),(张清玫,计算机专业,刘晨)，
(张清玫，计算机专业,王敏),(张清玫,信息专业,李勇)，
(张清玫，信息专业，刘晨),(张清玫,信息专业,王敏)，
(刘逸，计算机专业，李勇),(刘逸,计算机专业,刘晨)，
(刘逸，计算机专业，王敏),(刘逸,信息专业,李勇)，
(刘逸，信息专业，刘晨),(刘逸,信息专业,王敏) ｝

元组（Tuple）

笛卡尔积中每一个元素（d1，d2，…，dn）叫作一个n元组（n-tuple）或简称元组。

元组集合的结构
属性构成；属性来自的域；属性与域之间的映象关系
元组语义以及完整性约束条件。

分量（Component）

笛卡尔积元素（d1，d2，…，dn）中的每一个值di叫作一个分量。

基数（Cardinal number）

若Di（i＝1，2，…，n）为有限集，其基数为mi（i＝1，2，…，n），则D1×D2×…×Dn的基数M为：
$$M=\prod _{i=1}^n{m}_i$$
在上例中，基数：2×2×3＝12，即D1×D2×D3共有2×2×3＝12个元组

笛卡尔积的表示方法

笛卡尔积可表示为一个二维表。表中的每行对应一个元组，表中的每列对应一个域。

关系（Relation）

• D1×D2×…×Dn的子集叫作在域D1，D2，…，Dn上的关系，表示为 R（D1，D2，…，Dn）
  R：关系名
  n：关系的目或度（Degree）

• 形式化定义

  R（U，D，DOM，F）

  字符	含义
  R	关系名,是符号化的元组语义
  U	组成该关系的属性名的集合,一组属性
  D	属性组U中属性所来自的域
  DOM	属性向域的映象集合
  F	属性间数据的依赖关系集合（关系内部属性与属性之间的一种约束关系，主要分函数依赖和多值依赖）

  由于D、DOM与模式设计关系不大，所以常常把关系模式看作一个三元组：R<U,F>。

  当且仅当U上的一个关系r 满足F时，r称为关 系模式 R（U, F）的一个关系。

• 注意：
  关系是笛卡尔积的有限子集。无限关系在数据库系统中是无意义的。
  由于笛卡尔积不满足交换律，即
  (d1，d2，…，dn )≠(d2，d1，…，dn )
  但关系满足交换律，即
  (d1，d2 ，…，di ，dj ，…，dn）=（d1，d2 ，…，dj，di ，…，dn）
  （i，j = 1，2，…，n）
  解决方法：为关系的每个列附加一个属性名以取消关系元组的有序性

​ 例 在表2.1 的笛卡尔积中取出有实际意义的元组来构造关系关系：SAP(SUPERVISOR，SPECIALITY，POSTGRADUATE)关系名，属性名假设：导师与专业：1:1，导师与研究生：1:n于是：SAP关系可以包含三个元组
​ ｛ (张清玫，信息专业，李勇)，

​ (张清玫，信息专业，刘晨)，
​ (刘逸，信息专业，王敏) }

• 元组
  关系中的每个元素是关系中的元组，通常用t表示。

• 单元关系与二元关系
  当n=1时，称该关系为单元关系（Unary relation）。
  当n=2时，称该关系为二元关系（Binary relation）。

• 关系的表示
  关系也是一个二维表，表的每行对应一个元组，表的每列对应一个域。

• 属性
  关系中不同列可以对应相同的域，为了区分，必须对每列起一个名字，称为属性（Attribute）。n目关系必有n个属性。

• 码

  • 候选码（Candidate key）:若关系中的某一属性组的值能唯一地标识一个元组，则称该属性组为候选码.在最简单的情况下，候选码只包含一个属性。

  • 全码（All-key）：在最极端的情况下，关系模式的所有属性组是这个关系模式的候选码，称为全码（All-key）

  • 主码:若一个关系有多个候选码，则选定其中一个为主码（Primary key）
    候选码的诸属性称为主属性（Prime attribute）。
    不包含在任何侯选码中的属性称为非码属性（Non-key attribute）

• 三类关系

  • 基本关系（基本表或基表）:实际存在的表，是实际存储数据的逻辑表示
  • 查询表:查询结果对应的表
  • 视图表:由基本表或其他视图表导出的表，是虚表，不对应实际存储的数据。

• 基本关系的性质

  • 列是同质的。（Homogeneous）
    每一列中的分量是同一类型的数据，来自同一个域

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

    上例中也可以只给出两个域：
    人（PERSON）=张清玫，刘逸，李勇，刘晨，王敏
    专业（SPECIALITY）=计算机专业，信息专业
    SAP关系的导师属性和研究生属性都从PERSON域中取值
    为避免混淆，必须给这两个属性取不同的属性名，而不能直接使
    用域名。
    例如定义:
    导师属性名为SUPERVISOR-PERSON（或SUPERVISOR）
    研究生属性名为POSTGRADUATE-PERSON（或POSTGRADUATE）

  • 列的顺序无所谓，列的次序可以任意交换
    遵循这一性质的数据库产品(如ORACLE)，增加新属性时，永远是插至最后一列.但也有许多关系数据库产品没有遵循这一性质，例如FoxPro仍然区分了属性顺序

  • 任意两个元组不能完全相同，由笛卡尔积的性质决定。但许多关系数据库产品没有遵循这一性质。
    例如:
    Oracle，FoxPro等都允许关系表中存在两个完全相同
    的元组，除非用户特别定义了相应的约束条件。

关系模式

• 关系模式与关系
  关系模式（Relation Schema）是型，对关系的描述； 静态的、稳定的

• 关系是值关系模式在某一时刻的状态或内容。
  动态的、随时间不断变化的关系模式是对关系的描述

• 关系模式和关系往往统称为关系，通过上下文加以区别

  例如：学生表（学号，姓名，班级，学院）-> 关系模式

  ​ （201903010xxx,Caldarius，计科19-3,计科院）->关系

关系数据库

定义

• 在一个给定的应用领域中，所有实体及实体之间联系的关系的集合构成一个关系数据库。

关系数据库的型与值

关系数据库也有型和值之分

• 关系数据库的型称为关系数据库模式，是对关系数据库的描述。
• 关系数据库的值是这些关系模式在某一时刻对应的关系的集合，通常简称为关系数据库。

完整性约束

• 关系模型的完整性规则是对关系的某种约束条件。
• 关系模型中三类完整性约束：
  • 实体完整性
  • 参照完整性
  • 用户定义的完整性
• 实体完整性和参照完整性是关系模型必须满足的完整性约束条件，被称作是关系的两个不变性，应该由关系系统自动支持。

实体完整性规则（Entity Integrity）

• 若属性A是基本关系R的主属性，则属性A不能取空值

  例 SAP(SUPERVISOR，SPECIALITY，POSTGRADUATE)

  POSTGRADUATE属性为主码（假设研究生不会重名），则其不能取空值.

• 关系模型必须遵守实体完整性规则的原因：

  • 实体完整性规则是针对基本关系而言的。一个基本表通常对应现实世界的一个实体集或多对多联系。
  • 现实世界中的实体和实体间的联系都是可区分的，即它们具有某种唯一性标识。 相应地，关系模型中以主码作为唯一性标识。(2)

• 主码中的属性即主属性不能取空值。
  空值就是“不知道”或“无意义”的值。
  主属性取空值，就说明存在某个不可标识的实体，即存在不可区分的实体，这与第（2）点相矛盾，因此这个规则称为实体完整性。
  注意：
  实体完整性规则规定基本关系的所有主属性都不能取空值
  例
  选修（学号，课程号，成绩）
  “学号、课程号”为主码，则两个属性都不能取空值。

参照完整性

• 关系间的引用
  在关系模型中实体及实体间的联系都是用关系来描述的，因此可能存在着关系与关系间的引用。

  例1 :
  学生实体、专业实体以及专业与学生间的一对多联系
  　学生（学号，姓名，性别，专业号，年龄）
  　 专业（专业号，专业名）

​ 例1 :
学生实体、专业实体以及专业与学生间的一对多联系
　学生（学号，姓名，性别，专业号，年龄）
　 专业（专业号，专业名）

专业（专业号，专业名）

学生、课程、学生与课程之间的多对多联系
学生（学号，姓名，性别，专业号，年龄）
课程（课程号，课程名，学分）
选修（学号，课程号，成绩）

外码（Foreign Key）和参照关系（Referencing Relation）

• 设F是基本关系R的一个或一组属性，但不是关系R的码。如果F与基本关系S的主码Ks相对应，则称F是基本关系R的外码，基本关系R称为参照关系（Referencing Relation），基本关系S称为被参照关系（ReferencedRelation）或目标关系（Target Relation）。

• Tips：

  • 关系R和S不一定是不同的关系
  • 目标关系S的主码Ks 和参照关系的外码F必须定义在同一个（或一组）域上
  • 外码并不一定要与相应的主码同名。当外码与相应的主码属于不同关系时，往往 取相同的名字，以便于识别

• 例：
  学生关系中每个元组的“专业号”属性只取下面两类值：
  （1）空值，表示尚未给该学生分配专业
  （2）非空值，这时该值必须是专业关系中某个元组的“专业号”值，表示该学生不可能分配到一个不存在的专业中

  选修（学号，课程号，成绩）
  “学号”和“课程号”是选修关系中的主属性，按照实体完整性和参照完整性规则，它们只能取相应被参照关系中已经存在的主码值 学生(学号，姓名，性别，专业号，年龄，班长)
  “班长”属性值可以取两类值：
  1）空值，表示该学生所在班级尚未选出班长，或该学生本人即是班长；
  2）非空值，这时该值必须是本关系中某个元组的学号值

用户定义的完整性

• 用户定义的完整性是针对某一具体关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求。

• 关系模型应提供定义和检验这类完整性的机制，以便用统一的系统的方法处理它们，而不要由应用程序承担这一功能。

  例: 课程(课程号，课程名，学分)
  “课程名”属性必须取唯一值
  非主属性“课程名”也不能取空值
  “学分”属性只能取值{1，2，3，4}