鸣谢： https://baijiahao.baidu.com/s?id=1591955163343123446&wfr=spider&for=pc
https://www.cnblogs.com/yuelien/p/9934081.html
- 软件工程高内聚低耦合思想
函数依赖及其问题：（一夫一妻）
（1）数据冗余： 校长名字重复冗余，浪费存储空间。
（2）更新异常： 每次换校长就要跟换一批列数据，开销极大。
（3）插入删除异常： 这个系刚成立时为NULL，毕业后删光则校长信息丢失。
image.png
规范化：
低级关系模式通过模式分解转换为高级关系模式。
N级依赖缩略图：
1-3NF都是规范非主属性与码之间的关系。而主属性之间的关系没有规范。所以BCNF对主键之间的部分依赖进行了规定。
image.png
第一范式：
每一个分量都是不可再分的数据项。
例：
image.png
完善后：
image.png
第二范式：
在满足第一范式的基础上，实体的每个非主键属性完全函数依赖于主键属性。
不满足2NF的问题：
（1）插入异常：如果主键中的一个NULL，则插入失败。
（2）删除异常：如果删除其中一个主键元素，则要删除整行元素，因为主键必须非NULL。
（3）修改复杂：
部分依赖：
当主键由两个或两个以上字段构成，而表中的某些信息通过主键的一个字段就能唯一确定，我们称这样的依赖关系为部分依赖。
例： X->Y,X'属于X,X'->Y,则Y部分依赖于X;
例：
image.png
表中的姓名、专业通过主键中的学号就能唯一确定，而课程名通过课程号唯一确定，这就是部分依赖，这样的设计不符合第二范式。
解决办法：拆分
image.png
第三范式：
在满足第二范式的基础上，在实体中不存在非主键属性传递函数依赖于主键属性。
例：
系名依赖系号，系号依赖学号
image.png
拆分：
image.png
BCNF(巴斯-科德范式)
- 所有非主属性对每一个候选键(可唯一确定该行的主键组)都是完全函数依赖。
- 所有的主属性对每一个不包含它的候选键，也是完全函数依赖。
- 没有任何属性完全函数依赖于非候选键的任何一组属性。
BCNF与3NF有什么区别？
- 更加严格的完全函数依赖,加入了主属性对候选键的完全依赖和非候选键的任何属性不能被完全依赖。
例：每个老师只教一门课，每门课对应若干个老师，一个学生选一门课就只有一个老师。
（学生，课程）--> 老师,（学生，老师）-->课程,老师-->课程
-
候选键：
（学生，课程），（学生，老师） -
主属性：
学生，老师，课程
分析： 老师-->课程左部不包含候选键，而是候选键的一部分，违反了规定2，所以达不到BCNF范式的要求，是3NF。
多值依赖：（一夫多妻）
-
X，Y，Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立，当且仅当对R(U)的任一关系r,给定的一对(x，z)值有一组Y的值，这组值仅仅决定于x值而与z值无关。
-
例： 有这样一个关系 <仓库管理员T，仓库号B，库存产品号C> ，假设一个产品只能放到一个仓库中，但是一个仓库可以有若干管理员，那么对应于一个<仓库管理员，库存产品号>有一个仓库号，而实际上，这个仓库号只与库存产品号有关，与管理员无关，就说这是多值依赖。
表中，U = C+T+B，（C,T）确定一组B,但是这组B其实与T无关，仅由C确定，所以(C,T)->->B。又因为T不是空集，所以(C,T)->->B为非平凡多值依赖。
平凡与非平凡多值依赖：
- 若X→→Y,而Z为空集，则称X→→Y为平凡的多值依赖；若Z不为空，则称其为非平凡的多值依赖。
多值依赖与部分函数依赖：
image.png
4NF:
不许有非平凡多值依赖，即Z必须为空，避免因为Z的存在导致数据冗余。
网友评论