概叙
规范化理论研究的是关系模式中各属性间的依赖关系及对其概念性模式性能的影响,它提供了判断关系模式优劣的理论标准,能帮助数据库设计人员预测可能出现的问题。
规范化理论主要应用于数据库设计中的概念设计阶段。
关系模式中可能存在的冗余或异常问题
关系模式可能存在如下问题:
- 数据冗余
数据冗余指同一数据被反复存储的情况。如在一个供应商关系模式中,一个供应商每供应一种货物,其地址就存储一次,如果供应成千上万种货物,地址就会反复成千上完成。
更新异常
数据冗余将导致存储空间的浪费和潜 在数据不一致性及修改麻烦问题。如供应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语言 |