二、关系型数据库理论
2.1 关系型数据库中基本概念
-
关系（Relation）
一个关系就是一张二维表，每个关系都有一个关系名 -
元组
二维表中的行称为元组 -
属性
二维表中的列称为属性 -
关系模式
关系模式是对关系的描述。一般格式为R(D1,D2,D3..) R关系名，D为属性名 例如：学生（学号，姓名，性别，年龄，系别）
关系的性质
> 每一列中的分量必须来自同一个域， 必须是同一类
型的数据。(每一列数据类型一致)
> 不同的列可来自同一个域， 每一列称为属性， 不同的属性必须有不同的名字。（属性名唯一）
> 列的顺序可以任意交换。
> 关系中元组的顺序（ 即行序） 可任意。
> 关系中每一分量必须是不可分的数据项。
2.2 关系的键和关系的完整性
- 候选键(Candidate Key)
能惟一标识关系中元组的一个属性或属性集，称为候选键
- 主键（Primary Key）
从多个候选键中选择一个作为查询、插入或删除元组的操作变量
，被选用的候选键称为主键。
每个关系必定有且仅有一个主关系键
- 外键（Foreign Key）
被参照关系的主码和参照关系的外码必须定义在同一个域上
- 关系的完整性
实体完整性【必须满足】：主键不能为空或部分为空
参照完整性【必须满足】：参照关系外键的值必须来自被参照关系的主键，
或取空值。
用户自定义完整性：针对某一具体关系数据库的约束条件。
如：成绩属性的取值范围在0-100之间
2.3 关系代数
关系代数是一种抽象的查询语言
关系代数的运算对象与结果都是关系
关系代数的运算符
传统的集合运算（并、差、交、笛卡尔积）
相容：1. 两个关系具有相同的度（列数一样）2. 两个关系在第 i 个属性上的值来自同一个域
除笛卡尔积外，其他的集合运算要求关系必须满足相容性定于。
传统的集合运算都只是从行的角度进行的。
专门的关系运算（选择、投影、连接、除法）
2.4 关系规范化提出
不合理的关系模式存在的存储异常问题
-
数据冗余
-
插入异常
-
删除异常
-
更新异常
根本原因：属性间存在着数据依赖关系
一个好的关系模式应该具备以下四个条件
-
尽可能少的数据冗余
-
没有插入异常
-
没有删除异常
-
没有更新异常
2.5 函数依赖
定义
给定一个X一定能查到Y，就是Y依赖于X，写作X → Y
例子
关系S(学号，姓名，年龄)中学号可以唯一确定一个学生，可以找到姓名和年龄。
就是说（姓名,年龄）函数依赖于学号。
完全函数依赖
在一张表中，若X → Y ， 且对于X 的任何一个真子集（ 假如属性组x 包含超过一个属性的话）， X**′** → Y 不成立， 那么我们称Y 对于X完全函数依赖。
解释：在这张表中，Y是依赖于X的（X → Y）。X中的真子集（学号和课程），通过单独的学号是不能得到分数的，通过单独的课程也是不能得到分数的。
只有X中的所有真子集（学号和课程）一起才能得到Y（分数）。所以说Y是完全依赖于X的。
在来看看这张表，Y是依赖X的，并且因为X的真子集只有一个，所以Y必然是完全依赖于X的。
部分函数依赖
假如Y 函数依赖于x ， 但同时Y 并不完全函数依赖于x ， 那么我们就称Y 部分函数依赖于
x 。
解释：X的其中一个真子集学号就可以得到系名Y，即Y是部分函数依赖于X的。
传递函数依赖
假如Z函数依赖于Y, 且Y 函数依赖于X ， 且Y 不包含于X ，X 不函数依赖于Y ， 那么我们就
称Z传递函数依赖于X
2.6 候选码判定
- 如果有属性不在函数依赖集中出现，那么它必须包含在候选码中。
- 如果有属性只在函数依赖集右边出现，那么它必不包含在候选码中。
- 如果有属性只在函数依赖集的左边出现，则该属性一定包含在候选码中。
- 如果有属性或属性组能唯一标识元组，则它就是候选码，也就是说，通过函数依赖所求出的候选码的闭包中，能够包含所有的属性。
什么是闭包？
有关系R（A,B,C,D），函数依赖集F（D →B，B →D，AD→B，AC→D）
A的闭包：A
B的闭包：B、D
C的闭包：C
D的闭包：D、B
AC的闭包：A、C、D、B
例子
有关系模式R<U,F>，U={A,B,C,D}，
1)F={A→B,B→C,C→D,D→A}
2)F=Φ(空集)
3)F={A→B,B→A,A→C}
4)F={(A,B)→C,D→A}
5)F={(A,B)→C,C→A}
1）：所有属性ABCD在左右两侧均出现，因此前三条判断均不起作用。通过（4）的判断方法可以得知，A的闭包为{A，B，C，D}；B的闭包为{A，B，C，D}；C的闭包为{A，B，C，D}；D的闭包为{A，B，C，D}。四者的闭包均包含了所有的属性，因此此关系模式的候选码为A、B、C、D。
2）：函数依赖为空集，根据（1）可知，此关系模式的候选码为A、B、C、D。
3）：属性D在函数依赖集中从未出现，因此候选码中一定有它，而属性C只在右侧出现，因此候选码中一定没有它，结合上述方法（4）闭包的判断，候选码为(A,D),(B,D)。
4）：同上，C只在右侧出现，而B和D只在左侧出现，因此候选码中一定有D无C，最后判断A，可知候选码为(B,D)
5）：同理，候选码为(A,B,D)和(B,C,D)
2.7 关系模式的范式
第一范式
关系模式R所有的属性均为简单属性，即每个属性都是不可再分的，则称R属于第一范式，简称1NF。
上图是不满足1NF的，很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
存在问题：
-
数据冗余
-
插入异常
-
删除异常
-
更新异常
第二范式
在1NF的基础上，数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖，也即所有非关键字段都完全依赖于任意一组候选关键字。简称2NF。
存在问题
-
数据冗余
同一门课程由n个学生选修，"学分"就重复n-1次； 同一个学生选修了m门课程，姓名和年龄就重复了m-1次。 -
插入异常
假设要开设一门新的课程，暂时还没有人选修。这样， 由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。 -
删除异常
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表 中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然， 这也会导致插入异常。 -
更新异常
若调整了某门课程的学分，数据表中所有行的"学分"值都要更新， 否则会出现同一门课程学分不同的情况。
规范化
消除部分函数依赖，满足完全函数依赖，就可以得到2NF。
把选课关系表改为如下三个表：
这样的数据库表是符合第二范式的。不过2NF还是存在数据冗余、插入、删除、修改异常的。
所以需要继续对关系进行规范化。
第三范式
在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。简称3NF。
存在问题
- 数据冗余
- 插入异常
- 删除异常
- 更新异常
自行分析可以得知。
规范化
消除函数传递依赖。就可以得到3NF
把学生关系表分为如下两个表：
这样的数据库表是符合第三范式的。3NF解决了2NF中存在的四个问题：
- 数据冗余降低了
- 不存在插入异常
- 不存在删除异常
- 不存在更新异常
巴斯-科德范式（BCNF）
在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合BCNF范式。
存在问题
- 删除异常
- 插入异常
- 更新异常
规范化
把仓库管理关系表分解为二个关系表
这样的数据库表是符合BCNF的，消除了删除异常、插入异常和更新异常。
2.8 小结
