【数据库】函数依赖,属性闭包计算,求候选码和范式的详细介绍

前提概念须知

  • 候选码(或候选键)∶属性或属性组合,其值能够唯一地标识一个元组。
  • 主码(或主键):在一个关系中可能有多个候选码,从中选择一个作为主码。
  • 主属性:包含在任何候选码中的属性称为主属性,不包含在任何候选码中的属性称为非码属性。
  • 外码(或外键):如果一个关系中的属性或属性组并非该关系的码,但它们是另外一个关系的码,则称其为该关系的外码。
  • 全码:关系模式的所有属性组是这个关系模式的候选码,称为全码。
  • 超码(超键):一个包含码的属性集称为超码,例如学号是码,则(学号,姓名)就是一个超码。

函数依赖

数据依赖是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系,是现实世界属性间联系和约束的抽象,是数据内在的性质,是语义的体现。函数依赖则是一种最重要、最基本的数据依赖。

  • 函数依赖。设R(U)是属性集U上的关系模式,X、Y是U的子集。若对R(U)的任何一个可能的关系r, r中不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等,则称X函数决定Y或Y函数依赖于X,记作X→Y。
  • 非平凡的函数依赖。如果X→Y,但Y不属于X,则称X→Y是非平凡的函数依赖。一般情况下,总是讨论非平凡的函数依赖。
  • 平凡的函数依赖。如果X→Y,但 Y属于X,则称X→Y是平凡的函数依赖。
  • 完全函数依赖。在R(U)中,如果X→Y,并且对于X的任何一个真子集X’ 都有X’ 不能决定Y,则称Y对X完全函数依赖,记作x --f-- >y。例如:(学号,课程号)→成绩
  • 部分函数依赖。如果X→Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖,记作X–p–>Y。部分函数依赖也称为局部函数依赖。
  • 传递依赖。在R(U,F)中,如果X→Y,Y不属于]X,Y→Z,则称Z对X传递依赖。

函数依赖的公理系统(Armstrong 公理系统):

设关系模式R(U,F),其中U为属性集,F是U上的一组函数依赖,那么有以下推理规则。

  • Al自反律:若Y属于X属于U,则X→Y 为F所蕴涵。
  • A2增广律:若X→Y为F所蕴涵,且Z属于U,则XZ→YZ为F所蕴涵。
  • A3传递律:若X→Y,Y→Z为F所蕴涵,则X→Z为F所蕴涵。

根据上述3条推理规则又可推出下述3条推理规则:

  • 合并规则:若X→Y,X→Z,则X→YZ为F所蕴涵。
  • 伪传递率:若X→Y,WY→Z,则XW→Z为F所蕴涵。
  • 分解规则:若X→Y,Z属于Y,则X→Z为F所蕴涵。

如何利用闭包求出候选码

属性的闭包计算

在这里插入图片描述

若对A求闭包:在这里插入图片描述

根据F的依赖关系,由A可以推出其他的属性,这个过程就是闭包计算过程。当刚求出的属性闭包与上一个闭包相同时或者已经求出了所有的属性U时,就停止计算,能够求出U的就是候选码,上例A的闭包不能求出U,所以A不是候选码

如何快速选出候选码

找入度为0的属性,即只出现在F箭头左边的一定是候选码

上例中,A和C只出现在箭头左边,我们用闭包计算可以得到U,则(AC)是该关系的候选码

范式

第一范式(1NF)

定义:设R是一个关系模式,R属于第一范式当且仅当R中每一个属性A的值域只包含原子项,即不可分割的数据项。

1NF不能排除数据冗余和更新异常等问题,因为其中可能存在部分函数依赖’。

举例说明:原始的关系表一中的工资属性包含基本工资,加班工资,实发工资,是可以进行分割的数据项;进行规范化后的关系表二每个属性只包含原子项,不能再分割,满足第一范式

在这里插入图片描述
在这里插入图片描述

(学号,课程号)是主键

【数据库】函数依赖,属性闭包计算,求候选码和范式的详细介绍_第1张图片

我们可以看到学号,姓名,学院,院长的数据冗余很严重;如果计算机学院的院长换人,则需要修改多条数据

插入异常:如果新成立一个学院时,因为没有学生和课程,没有包含主键则不能插入成功

删除异常:如果删除孙七-高等数学这条数据,则数学学院的信息也不存在了

【数据库】函数依赖,属性闭包计算,求候选码和范式的详细介绍_第2张图片

第二范式(2NF)

定义:设R是一个关系模式,R属于第二范式当且仅当R是 1NF,且每个非主属性都完全函数依赖于候选码。

属于2NF的关系模式R也可能存在数据冗余和更新异常等问题,因为其中可能存在传递函数依赖。但不属于2NF的关系模式R会产生插入异常、删除异常和修改复杂等问题。

举例说明:原始的关系R中,候选码是(学号,课程号),姓名,学院,院长,课程名都部分依赖于候选码;

【数据库】函数依赖,属性闭包计算,求候选码和范式的详细介绍_第3张图片

我们将关系模式分解来消除部分函数依赖,得到以下三个关系,满足了第二范式

【数据库】函数依赖,属性闭包计算,求候选码和范式的详细介绍_第4张图片

第三范式(3NF)

定义:设R是一个关系模式,R属于第三范式当且仅当R是2NF,且每个非主属性都非传递函数依赖于候选码。

一个不属于3NF的关系模式R会产生插入异常、删除异常和修改复杂等问题。属于3NF的关系模式R可能存在主属性对码的部分依赖和传递依赖。

下面的关系满足第二范式,但是可以看到,学院-院长的数据存在冗余,如果很多学生都属于计算机学院,那么院长李四的信息也会重复多行

插入异常:新增一个学院时没有学生学号信息,不能成功插入

删除异常:若一个学院暂时只有一个学生的信息,删除该学生信息时,学生所在的学院信息也一并被删除了

主要原因是学号→学院,学院→院长,存在传递依赖

【数据库】函数依赖,属性闭包计算,求候选码和范式的详细介绍_第5张图片

我们将院长分离出去,形成下面的四张表关系,消除了学号→学院,学院→院长的传递依赖,现在的关系就满足第三范式了

【数据库】函数依赖,属性闭包计算,求候选码和范式的详细介绍_第6张图片

BC范式(BCNF)

定义:设R是一个关系模式,F是它的依赖集,R属于BCNF,当且仅当其F中每个依赖的决定因素必定包含R的某个候选码。

由BCNF的定义可以得到结论,一个满足BCNF的关系模式有:

  • 所有非主属性对每一个码都是完全函数依赖。
  • 所有的主属性对每一个不包含它的码,也是完全函数依赖。
  • 没有任何属性完全函数依赖于非码的任何一组属性。

一个满足BCNF的关系模式R已消除了插入和删除异常。

候选码:(书店,图书)、(店长,图书)

主属性:书店、店长、图书

非主属性:库存量

在这里插入图片描述

书店 店长 图书 库存量
书店1 张三 数据库 100
书店1 张三 数据结构 200
书店2 李四 高等数学 300

上述关系已经满足第三范式,却仍然存在一些数据冗余;可以看到书店和店长的信息重复多行;

主要的原因是主属性书店,店长对候选码存在部分依赖

我们将关系分解成下面两个关系,消除了数据冗余,也满足了BC范式

书店 店长
书店1 张三
书店2 李四
书店 图书 库存量
书店1 数据库 100
书店1 数据结构 200
书店2 高等数学 300
规范化的步骤

【数据库】函数依赖,属性闭包计算,求候选码和范式的详细介绍_第7张图片

你可能感兴趣的:(数据库,数据库开发)