关系数据库的规范化理论

概叙

规范化理论研究的是关系模式中各属性间的依赖关系及对其概念性模式性能的影响,它提供了判断关系模式优劣的理论标准,能帮助数据库设计人员预测可能出现的问题。

规范化理论主要应用于数据库设计中的概念设计阶段。

关系模式中可能存在的冗余或异常问题

关系模式可能存在如下问题:

  • 数据冗余

数据冗余指同一数据被反复存储的情况。如在一个供应商关系模式中,一个供应商每供应一种货物,其地址就存储一次,如果供应成千上万种货物,地址就会反复成千上完成。

  • 更新异常
    数据冗余将导致存储空间的浪费和潜 在数据不一致性及修改麻烦问题。如供应1000种货物的供应商的地址信息发生变化,那么需要对这些供应商的地址进行逐一修改,这样就有可能在一个元组中修改了地址,而没修改该另一个元组中同一供应商的地址,从而导致与实际情况不相符

  • 插入异常
    插入异常指应该插入到数据库中的数据不能只需插入操作的情形。

  • 删除异常
    数据的删除操作异常指不应该删除的数据被删除的情形。

产生上述问题的原因,及消除这些问题的方法,都与数据库依赖的概念密切相关。数据依赖是可以作为关系模式的取值的任何一个关系所必须满足的一种约束条件,是通过一个关系中各个元组的某些属性值之间的相等与否体现出来的相互关系。

函数依赖与关键字

函数依赖指关系中属性间的对应关系

定义

设R 为任一给定关系,如果对于 R 中属性 X 的每个值,R 中的属性 Y 只有唯一值与之对应,则称 X 函数决定 Y (Y 函数依赖于 X) 记作 $X\to Y$。 X称为决定因素
example:
表 T1

学号(SNO) 姓名(SNAME) 性别(SSEX) 宿舍(SROOM)
0001 张三 N101
0002 王二 N101
0003 李梅 C101

T1中存在如下函数依赖:
$SNO\to SName$
$SNO\to SSEX$
$SNO\to SROOM$

T1 中的函数依赖关系仅当SNO作为决定因素时存在

完全函数依赖

设 R 为任一给定定关系,X、Y 为其属性集, 若$X\to Y$,且 X 中的任一真子集 $X^{‘}$都有 Y 函数不依赖于 $X^{‘}$,则 Y 完全依赖于 X

Example:

表 T2

学号(SNO) 课程编号(CNO) 课程名(CTITLE) 授课老师(INAME) 成绩(GRADE)
0001 201 张三 80
0002 202 李四 90
0003 203 王五 60

T2 中,函数依赖:$(SNO,CNO)\to GRADE$ ,它为完全函数依赖。因为其中单个属性 SNO/CNO 都不能单独决定GRADE

部分函数依赖

设 R 为任一给定关系, X、Y 为其属性集合,若$X\to Y$,且 X 中存在某个真子集 $X^{‘}$满足 $X^{‘}\to Y$ ,则 Y 部分函数依赖于 X。

T1 中 函数依赖$(SNO,SNAME)\to SSEX$,而其中$SNO\to SSEX$ ,那么 SSEX部分函数依赖于(SNO,SNAME)

传递函数依赖

设 R 为任一给定关系, X、Y、Z为不同属性子集,若$X\to Y$,X函数不依赖于Y,$Y\to Z$,则 $X\to Z$,即 Z传递函数依赖于X。

Example:

有一个关系模式 T2(BNO(书号),PNAME(出版社名),PADDRESS(出版社地址)),一种书对应一个唯一的书号,且只能为某一出版社出版;
一个出版社只有唯一名称和地址,但一个出版社可出版多种书。
那么该关系中存在函数依赖:$BNO \to PNAME$, $PNAME\to PADDRESS$, PNAME函数不依赖于BNO,所以$BNO\to PADDRESS$

严格的关键字定义

设 R 为任一给定关系,U 为所有属性集合, X 为 U 的子集,若 U 完全依赖于 X,则 X 为 R 的候选关键字。

范式与关系规范化过程

关系数据库中的关系需要满足一定的要求,不同程度的要求称为不同的范式(Normal Form,NF)。

第一范式 1FN

设 R 为任一给定关系, R 中每个列和行的交点处的取值都是不可再分的基本元素,则 R 为 1FN。 1FN是范式的最低要求,是一个不含重复组的关系,不存在嵌套结构。

表 T3

学生选课信息表
SNO CNO CTITLE INAME IPLACE GRADE
1027 C01 操作系统 王五 东01 100
1028 C02 数据库 刘备 东02 91
1029 C01 操作系统 王五 东01 88
C03 人工智能 曹操 东03 100
1030 C04 C语言 刘备 东02 97

T3关系是一个非归范式关系,因为 SNO属性中 1029出现重复的组,可将T3转化为 1FN

T4 1FN

SNO CNO CTITLE INAME IPLACE GRADE
1027 C01 操作系统 王五 东01 100
1028 C02 数据库 刘备 东02 91
1029 C01 操作系统 王五 东01 88
1029 C03 人工智能 曹操 东03 100
1030 C04 C语言 刘备 东02 97

第二范式 2FN

设 R 为任一给定关系,如果 R 为 1FN,且所有非主属性都完全函数依赖于候选关键字,则 R为 2FN。

Example:

T4 中存在着冗余度高、插入和删除操作异常等问题,CTITLE 中都某一课程被多人选修,那么对应的授课老师和地址将反复存储(数据冗余);若新增一门课程,而没人任何同学选修,则这们课程将无法存储(插入异常);如果将最后一元组删除,同时会删除C语言这门课程及相关老师和地址等信息(删除异常);

存在这些问题的原因在于仅有非主属性 GEEADE 完全 依赖于(SNO,CNO),其他非主属性都只依赖于 CNO ,对于主键(SNO,CNO)为部分依赖

通过分解 T4 将部分函数依赖分解成完全函数依赖,得到 2FN
T4.1

SNO CNO GRADE
1027 C01 100
1028 C02 91
1029 C01 88
1029 C03 100
1030 C04 97

T4.2

CNO CTITLE INAME IPLACE
C01 操作系统 王五 东01
C02 数据库 刘备 东02
C03 人工智能 曹操 东03
C04 C语言 刘备 东02

此时的 T4.2依然存在插入、删除操作及修改麻烦等异常问题。如:将一位新老师插入 T4.2表中,但这位老师暂无任何教学工作,因缺关键字 CNO的值而不能执行插入操作。

原因在于:T4.2 关系中存在非主属性对主属性的传递函数依赖,须进一步分解。

第三范式 3FN

设 R 未任一给定关系, 如 R 未 2FN,且每一个非主属性都不传递依赖于候选关键字,则 R 为3FN。

Example:

通过分解 T4.2 将传递函数依赖分解成完全函数依赖,得到 3FN

T4.2.1

CNO CTITLE INAME
C01 操作系统 王五
C02 数据库 刘备
C03 人工智能 曹操
C04 C语言 刘备

T4.2.2

INAME IPLACE
王五 东01
刘备 东02
曹操 东03

BCNF

通常 3FN 大多数能解决插入和删除操作异常的问题,数据冗余也能得到有效控制。为解决3FN有时出现的操作问题,R.F.Boyce和E.F.Codd 提出 改进范式 BCNF

设 R 为任一给定关系,X、Y 为属性集,F为其函数依赖集, 若 R 为 3NF,且 F 中所有函数依赖 $X\to Y$ (Y 不属于 X)中 X 必须包含候选关键字,则 R 为 BCNF。 即 R中每一函数依赖的决定因素X(可为单一属性或组合属性) 都包含 候选关键字,则 R 为 BCNF。

当所有属性集合为候选关键字时依然会存在操作异常和数据冗余等问题
Example:

表 T5

SNO CTITLE TNAME
S01 操作系统 王五
S02 人工智能 曹操
S02 数据库 刘备
S03 数据库 孙权

T5中新增一门课程和一位老师的数据时,须至少有一位学生选修该课且指导老师已被分配才能插入T5中。

此时可通过公共的函数依赖将 T5分解位为 T5.1 和 T5.2

T5.1

SNO TNAME
S01 王五
S02 曹操
S02 刘备
S03 孙权

T5.2

TNAME CTITLE
王五 操作系统
曹操 数据库
刘备 人工智能
孙权 C语言
--------------------- Thank you for reading ---------------------