规范化normalization,范式,自下而上:1NF,2NF,3NF,BCNF,4NF,5NF.
更新异常
数据冗余data redundancy
更新异常update anomalies:很有可能由于数据冗余导致
三种更新异常
以下图中的数据为例(staff员工,branch分公司,应该是以staffNo为PK):
insertion anomalies
指当用户想要插入某一实体实例时,还必须输入另一个实体的数据。
eg.想正确添加新员工,必须保证对应的分公司的所有信息也要正确;想添加新分公司,此时没有员工,staff相关项为空值,可能更新失败
deletion anomalies
指当用户想要删除某一实体实例时,还必须删除另一个实体的数据。
eg.想删除的员工是某公司的唯一一个员工,若删除他,分公司的信息也彻底没了
modification anomalies
指当用户要修改某个值的时候,同样的修改操作需要重复多次。
eg.想修改分公司,则该分公司下所有的员工信息都要更改
分解
Two important properties of decomposition:
- lossless-join无损连接
- dependency preservation依赖保持
函数依赖
假设A和B均为关系R的属性,若A的每个值都和B 中的一个唯一的值相对应,则称B函数依赖于A,记为A→B(A决定B)。A、B可能由一或多个属性组成。
eg.职位函数依赖于员工编号,每个员工都有一个职位?(why不能多个呢)
恒成立函数依赖
Functional Dependency that holds for all Time
?考虑整个属性值域
完全依赖
full function dependency
A→B:B函数依赖于A,但不函数依赖于A的任一真子集。(能决定B的最小集)
传递依赖
transitive dependencies
A→B&&B→C,则称C通过B传递依赖于A
确定PK
identify the primary key for a relation using functional dependencies
确定关系函数依赖集的主要目的是确定该关系必须满足的完整性约束集(候选关键字、主关键字、)
首先要考虑辨别的一种重要完整性约束是候选关键宇,候选关键字中的一个将被选作关系的主关键字,候选关键字可决定其他任意列。(ps:可能有时候A→B看起来不太合理,但在客观逻辑上看确实有相应的依赖)
规范化过程
规范化基于primary/candidate key和函数依赖
UNF
unnormalized form非范式,包含重复组
1NF
一个表如果每一行都是唯一,并且任何行都没有包含多个值的列,则它满足1NF。但对于关系表来说,真正的规范化过程从第二范式开始,因为关系表本身已经满足1NF了。
UNF TO 1NF:
- 为非范式结构确定一个唯一标识(关键属性)(可以是组合的)(好好选……
- 根据关键属性,确定重复组
- 除去重复组
- 填充空值
- 拆分多表
1NF中每个非关键属性都完全函数依赖于关键属性
2NF
1NF TO 2NF:
- 检查非主属性,除去部分函数依赖(即主关键字并不是决定方的最小集)==保留主关键字能决定的完全依赖
- 拆分多表
3NF
2NF TO 3NF:
- 除去传递依赖(某一非主属性能由其他非主属性决定)
- 拆分多表
BCNF
函数依赖集
函数依赖集X,被某一函数依赖集X所蕴涵的所有函数依赖的集合X+(X的闭包)
覆盖
如果函数依赖集Y的每一个函数依赖都属于函数依赖集X的闭包X+,称Y 被X覆盖,即Y中每个函数依赖都可以从X推导出。
最小函数依赖集
conditions:
- X中的每个依赖的右边都只包含单个属性
- X中的函数依赖全是完全函数依赖
BCNF
boyce-codd normal form
2NF,3NF消除了对候选关键字的部分依赖和传递依赖,但仍可能存在一些会引起冗余的依赖
BCNF中的每个决定性属性都是候选关键字,对于函数依赖A→B:
- 3NF:允许情况-B是主属性且A不是候选关键字>
- BCNF:A必须是候选关键字
可能导致不满足BCNF:
- 包含多个候选关键字
- 候选关键字相互重叠
UNF TO BCNF
4NF、5NF
4NF:消除多值依赖Multi-valued Dependency (MVD)
5NF:消除连接依赖 join dependency
例题
UNF:
1NF:转成正式的结构化的表,可以填充空值。选了(clientNo,propertyNo)作为组合关键字
Rental:(clientNo, propertyNo, cName, pAddress, rentStart, rentFinish, rent, ownerNo, oName)
2NF:消除部分依赖,如cName可由clientNo直接决定,不需要组合关键字确认。(即确保完全依赖)
- Rental:(clientNo, propertyNo, rentStart, rentFinish)
- Client:(clientNo, cName)
- Property:(propertyNo, pAddress, rent, ownerNo, oName)
3NF:消除主关键字上的传递依赖,如propertyNo→ownerNo→oName
- Rental:(clientNo, propertyNo, rentStart, rentFinish)
- Client:(clientNo, cName)
- Property:(propertyNo, pAddress, rent, ownerNo)
- Owner:(ownerNo, oName)
BCNF:满足