数据库系统原理-关系数据库的规范化理论总结

x33g5p2x  于2021-11-16 转载在 其他  
字(2.6k)|赞(0)|评价(0)|浏览(443)

数据库系统原理中最容易混淆和难记的想必就是规范化理论了,涉及到的概念是一个接着一个,互相还有关联,还有3天就要考试了,在这里写个总结留着复习。

主要涉及的概念有码(键)、超码(超键)、候选码(候选键)、主码(主键)、全码(全键)、 主属性、非主属性、函数依赖、完全函数依赖、部分函数依赖、传递函数依赖,最终由以上概念推出第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯范式(BCNF)

码、超码、候选码、主码、全码

能唯一标识记录的属性(或属性组)

超码能移去某个属性,移除后还是码,称为超码

候选码不能移去任何一个属性的码,移除不是码,称为候选码

主码从候选码中选出来用来唯一标识关系的属性(或属性组)

全码:表中所有属性作为主码

码之间的包含关系如下图:

主属性与非主属性

主属性:在一个关系中包含任一候选码的属性,称为主属性

非主属性:在一个关系中不包含任一候选码的属性,称为非主属性

函数依赖

函数依赖(FD)是指关系中属性间的对应关系,其定义如下:

定义:设 R 为任一给定关系,如果对于 R 中属性 X 的每一个值,R 中的属性 Y 只有唯一值与之对应,则称 X 函数决定 Y 或称 Y 函数依赖于 X,记作 X→Y。其中 X 称为 Y 的决定因素。
同一表中两个属性(或属性组)X能唯一确定Y,就称X决定Y,它们两者间有函数依赖关系。

完全函数依赖

定义:设 R 为任一给定关系,X、Y 为其属性集,若 X→Y,且对 X 中的任何真子集 X' 都有 X' ↛ Y,则称 Y 完全函数依赖于 X。
同一表中的 X、Y 两个属性集中,如果 X 的每个属性(或属性组)都不能唯一确定Y的所有属性,就是完全函数依赖。

部分函数依赖

定义:设 R 为任一给定关系,X、Y为其属性集,若 X→Y,且 X 中存在一个真子集 X' 满足 X'→Y,则称 Y 部分函数依赖于 X。
同一表中的 X、Y 两个属性集中,如果 X 的某个属性(或属性组)能唯一确定 Y 的所有属性,就是部分函数依赖。

注意:如果将某个换成全部就成了完全函数依赖。

传递函数依赖

定义:设 R 为任一给定关系,X、Y、Z 为其不同属性子集,若 X→Y,Y ↛ X,Y→Z,则有 X → Z,称为 Z 传递函数依赖于 X。
同一表中三个不同属性组 X、Y、Z,如果 X 能确定唯一的 Y,Y 不能确定唯一的 X,同时 Y 能确定唯一的 Z,就会出现 X 能唯一确定 Z 的情况,就是传递函数依赖。

范式

所谓范式就是规范的方法,出现关系数据库的范式是消除因数据冗余而导致的更新异常、插入异常、删除异常。

数据冗余:指同一数据被反复存储的情况

更新异常:数据冗余造成的存储空间浪费和潜在的数据不一致性及修改麻烦的问题

插入异常:插入数据库数据失败的问题

删除异常:不应该删去的内容被删除的情况

数据库范式常用的有四种,第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯范式(又称增强版3NF,BCNF)

将低一级的范式的关系模式通过模式分解转换成高一级的范式的过程称为规范化。
以下范式举例中,可以将候选码看作主键便于理解(毕竟主码是特殊的候选码)

1NF

第一范式定义:设 R 为任一给定关系,如果 R 中每个列与行的交点行的取值都是不可再分的基本元素,则 R∈1NF。
1NF 是最简单的范式,意思是关系模式组织的二维表结构中,所有属性不可再分,不允许出现表中有表的情况。

所有关系模式中的二维表都满足 1NF。

1NF 仍存在数据冗余、更新异常、插入异常等问题。

2NF

第二范式定义:设 R 为任一给定关系,若 R∈1NF,且其所有非主属性都完全依赖于候选码,则 R∈2NF。
2NF 消除了非主属性的部分函数依赖,所有不是候选码的属性都能通过候选码唯一确定。

举例:假设有 R={A,B,C,D},F={AC→B,C→D},如果集合 R 的属性函数依赖关系是 F,则 R不满足第二范式。首先我们不难看出 R 的候选码为 AC,在 AC→D 上有 C→D 存在部分依赖关系,所以 R 不满足第二范式。

2NF 仍存在插入、删除操作异常与修改麻烦问题。

3NF

第三范式定义:设 R 为任一给定关系,若 R 为 2NF,且其每一个非主属性都不传递函数依赖于候选,则 R ∈3NF。
3NF 在 2NF 基础上消除了非主属性的传递函数依赖

举例:假设有 R={A, B, C, D},F={A→B, A→C, C→D},可以看到 A 为 R 的候选码,在 F 中有A→C,C→D,而且 D 不属于主属性,这就存在了非主属性 D 传递依赖于 R 的候选码 A。所以 R 不属于第三范式。

3NF 能解决大多数插入、删除操作异常的问题,数据冗余也得到有效控制。

BCNF

巴斯范式定义:设 R 为任一给定关系,X、Y 为其属性集,F 为其函数依赖集,若 R 为 3NF,且其 F 中所有函数依赖 X→Y(Y∉X)中的 X 必包含候选码,则 R∈BCNF。
简单来讲,在 3NF基础上,若 F 中每一个函数依赖的决定因素都包含候选码,就一定是 BCNF。

举例:假设有 R={A, B, C, D},F={AB→C, AB→D, D→A},不难发现 AB 为 R 的候选键,函数依赖关系中没有非主属性的部分依赖和传递依赖,所以 R 是属于第三范式的。但是不属于 BCNF,由于 D→A 的决定因素 D 不包含在 R 的候选码中。

BCNF 解决了插入及删除操作异常问题。

总结

基础概念就不再总结了,把各范式做了哪些事情简单总结下:

  • 1NF 确保属性不可再分,不会出现表中有表的情况。
  • 2NF 消除非主属性的部分函数依赖,减少了数据冗余。
  • 3NF 清除非主属性的传递函数依赖,解决大多数插入、删除操作异常的问题,数据冗余也有效控制住了。
  • BCNF 确保决定因素必须包含主键,解决了所有插入、删除操作异常的问题。

由低范式向高范式转换方法总结(拆表):

1NF→2NF:

找到候选关键字,看其余的属性是否完全依赖候选关键字

  • 是的,与候选关键字一同抄下来形成一个表格
  • 不是的,抄下来,形成第二个表格,并且将候选关键字里能够唯一决定表格2的属性组抄在第一列

2NF→3NF:

  1. 找到表格中的传递函数依赖关系的三个属性组,设为 X、Y、Z
  2. 将这三个属性组拆成两个表格,第一个表格为X、Y,第二个表格为Y、Z

3NF→BCNF:

  1. 列出表格中所有函数依赖关系
  2. 每个函数依赖关系拆出一个表格

行文过程中难免出现错误,如有错误欢迎大家评论告知。

本文同步发布于博客园(东北小狐狸 https://www.cnblogs.com/hellxz/)与CSDN(东北小狐狸-Hellxzhttps://blog.csdn.net/u012586326)禁止转载。

相关文章