函数依赖 候选码 主码 第三范式 BCNF 多值依赖

关系数据库理论

课本第六章 关系数据库理论

一、函数依赖：

1.完全函数依赖

通过AB能得出C，但是AB单独得不出C，那么说C完全依赖于AB。

2.部分函数依赖

通过AB能得出C，通过A也能得出C，通过B也能得出C，那么说C部分依赖于AB。

3.传递函数依赖

通过A得到B，通过B得到C，但是C得不到B，B得不到A，那么说C传递依赖于A。

4.平凡依赖

定义：

若X->Y，且Y是X的子集（对任一关系模式，平凡函数依赖必然成立），就是平凡函数依赖。

例如：

在学生表(学号,姓名,年级)中,(学号,姓名)可以推出学号和姓名其中的任何一个,这就是平凡函数依赖.

直白点说，就是只要Y是X的子集，Y就依赖于X。

5.非平凡依赖

定义：

若X->Y，但Y不是X的子集，就是非平凡函数依赖。

例如：

在学生表(学号,姓名,年级)中,通过(学号,姓名)可以推出这个学生所在的年级,但年级不是（学号，姓名）的子集，这是非平凡函数依赖.((学号,姓名)就是一个x,学号或者姓名就是一个x’)。

函数依赖举例说明：

Student表：Sno(学号)，Sdept（系），Mname（系主任名字），Cno（课程号），Grade（成绩）

ex1: （Sno，Cno）->Grade是完全函数依赖，在该表中Sno和Cno都无法单独决定Grade，因此可以说，Grade完全依赖于Sno和Cno。

ex2: (Sno,Cno)->Sdept是部分函数依赖，因为Sno->Sdept成立，而Sno为（Sno,Cno)的真子集。

ex3: Sno->Sdept,Sdept->Mname,(加上条件Sdept不能决定Sno)，此时可以说Mname传递依赖于Sno。

完全函数依赖：

{学号,课号}–>成绩

学号+课号 可以决定 成绩 但只有学号or只有课号无法决定成绩

部分函数依赖：

{学号,课号}–>姓名

只有学号就能决定姓名 (课号是冗余的)

二、码

超集：

在该图中，我们称S2为S1的子集，S2为S1的超集。

码：

1.超码：

定义：能够唯一标识一条记录的属性或属性集。

特点：

1. 可能包含无关属性
2. 超码的任意超集也是超码。（通俗讲，就是同一个关系r上，如果某个属性集合S包含超码K，即K是S的子集，那么S也是 r 的超码）
3. 一张表（一个关系）一定有超码，因为至少所有属性的组合一定是超码，能唯一确定一个元组
4. 不唯一

2.候选码：

定义：能够唯一标识一条记录的最小属性集

特点：

1. 是超码的一个子集
2. 任意真子集都不可能是超码，候选码就是最小的超码
3. 没有无关属性
4. 不唯一

3.主码：

定义：某个能够唯一标识一条记录的最小属性集（是从候选码里人为挑选的一条）

特点：

1. 是候选码之一
2. 唯一或没有
3. 由数据库设计者指定，不指定的话表就没有主码

4.主属性与非主属性：

主属性 包含在任一候选码中的属性称主属性。简单来说，主属性是候选码所有属性的并集。

非主属性 不包含在候选码中的属性称为非主属性，也称为非码属性。

—ppt分类：—

1.candidate keys 候选码

能够决定其他所有列的因素，能够确定唯一一行。

2.composite keys 复合码

包含两列及以上的码。

3.primary keys 主码

当设计数据库时，会选取候选码中的其中一个充当主码，具有唯一确定一行的作用。

4.surrogate keys 代理码

当不适合用任何一个候选键作为主键时（如数据太长等），添加一个没有实际意义的键作为主键，这个键就是代理键。

ppt解释：人为加入的充当主码作用的列。

（代理码一般情况下对用户没有意义，在生成报表时进行隐藏）

5.foreign keys 外码

子数据表中出现的父数据表的主码，称为子数据表的外码。

假如我们还有一个教师表，每个教师都有自己的编号，假设老师编号在教师表中是主键，在学生表中它就是外键。

6.all-key 全码

当所有的属性共同构成一个候选码时，这时该候选码为全码。

（教师，课程，学生）假如一个教师可以讲授多门课程，某门课程可以有多个教师讲授，学生可以听不同教师讲授的不同课程，那么，要区分关系中的每一个元组，这个关系模式R的候选码应为全部属性构成 （教师、课程、学生），即主码。

三、范式：

第一范式（1NF）
数据库的每一个项都是不可分割的原子数据项，第一范式无重复的域。

不满足1NF：

满足1NF：

第二范式（2NF）
在第一范式的基础上,每一个非主属性完全依赖于任何一个候选码，即消除了部分函数依赖。

如下：图1满足1NF，但是姓名部分依赖于（学号，课名），故不满足2NF.

图1：

满足2NF的表：（图2：）

第三范式（3NF）
在2NF的基础上，任何非主属性不传递依赖于码，即进一步消除传递依赖。

图2中，学号决定系名，（包含条件系名不决定函数），系名又决定系主任，所以系主任传递依赖于学号，故不满足3NF。

满足3NF的图为：（图3：）

**巴斯-科德范式（BCNF）**BCNF是3NF的改进形式

一个满足BCNF的关系模式的条件:

1.所有非主属性对每一个码都是完全函数依赖。

2.所有的主属性对每一个不包含它的码,也是完全函数依赖。

3.没有任何属性完全函数依赖于非码的任何一组属性。
BCNF

满足3NF，消去决定因素不是码的函数依赖

若一张表的数据包括：“书号、书名、作者”，其中书号决定书名和作者，但是作者和书名同时可以决定书号，（作者，书名）非码，即现在就出现了决定因素不是码的函数依赖。
书号→（书名，作者）
（作者，书名）→书号

我们可以通过分解为两张表，实现BCNF：

四、多值依赖：

在关系模式中，函数依赖不能表示属性值之间的一对多联系，这些属性之间有些虽然没有直接关系，但存在间接的关系，把没有直接联系、但有间接的联系称为多值依赖的数据依赖。例如，教师和学生之间没有直接联系，但教师和学生可通过系名，或任课把教师和学生联系起来。

总结规范化的过程：

（1）取原始的1NF关系投影，消去非主属性对键的部门函数依赖，从而产生一组2NF关系。
（2）取2NF关系的投影，消去非主属性对键的传递函数依赖，产生一组3NF关系。
（3）取这些3NF的投影，消去决定因素不是键的函数依赖。产生一组BCNF关系。
（4）取这些BCNF关系的投影，消去其中不是函数依赖的非平多值依赖，产生一组4NF关系。
（来源：百度）

参考：

https://blog.csdn.net/sumaliqinghua/article/details/85872446

https://blog.csdn.net/panzelinsdo/article/details/102779683?
utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.edu_weight&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-2.edu_weight

https://blog.csdn.net/wenco1/article/details/88077279

https://www.cnblogs.com/guojiaxue/p/12655068.html

https://blog.csdn.net/SevenGirl2017/article/details/77678233?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.edu_weight&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.edu_weight