数据库复习笔记 四.关系数据库设计理论
数据依赖#
函数依赖: 有了 A 就能绝对确定 B, 例如知道学号确定姓名, 知道身份证号确定生日.
平凡函数依赖: (学号, 课程号) → 学号, 废话依赖.
非平凡函数依赖: 学号 → 姓名, 有用的依赖.
部分函数依赖 Partial: 只需要其中的一部分就能确定, 例如姓名部分依赖于 (学号, 课程号).
完全函数依赖 Full: 必须凑齐才能确定, 例如分数依赖于 (学号, 课程号).
传递函数依赖 Transitive: 学号 → 宿舍楼, 宿舍楼 → 楼长, 所以学号 → 楼长.
码: 设 K 是关系模式 R 中的属性集合. 如果 K完全函数依赖决定 R 中的所有其他属性, 那么 K 就是候选码 (Candidate Key).
实际上候选码主码超码就是第一章的候选键主键超键, 这里叫码是因为 PPT 不知道发什么癫, 第一章 Key 翻译成键, 这里又翻译成码了.
参考: 数据库基础笔记 一.绪论
数据依赖对关系模式的影响#
U＝{Sno,Sdept,Mname,Cname,Grade}
F＝{Sno->Sdept, Sdept->Mname, (Sno,Cname)->Grade}
(U 表示所有属性, F 表示依赖)
该关系模式存在如下问题 :
- 数据冗余太大: 系主任名字重复出现, 和所有学生的所有课程成绩次数一样
- 更新异常: 更换系主任必须修改每一个学生信息
- 插入异常: 刚成立的系如果还没有招生就无法存储系主任信息
- 删除异常: 某个系的学生全部毕业删除时会丢失系主任信息
范式#
1NF ∈ 2NF ∈ 3NF ∈ BCNF ∈ 4NF ∈ 5NF.
第一范式#
1NF, 原子性, 不可再分.
现在的关系型数据库根本创建不出不满足 1NF 的表, 所以考试应该不用管.
第二范式#
如果一个关系模式 R ∈ 1NF, 并且每一非主属性都完全依赖于 R 的码, 则 R ∈ 2NF.
若 R 的码只包含一个属性, 且 R 是 1NF, 则 R 必是 2NF.
人话: 不存在部分函数依赖.
例:
R (学号, 课程, 姓名, 成绩), 主键 (学号, 课程), 但姓名只依赖于学号, 对主键是部分依赖, 不满足 2NF.
解决方法: 拆成两张表, (学号, 课程, 成绩) 和 (学号, 姓名).
第三范式#
如果一个关系模式 R 中不存在非主属性对码的传递依赖, 则 R ∈ 3NF .
人话: 不存在传递函数依赖.
例:
学生表 (学号, 系名, 系主任), 系主任传递依赖于学号, 不满足 3NF.
BC 范式#
如果一个关系模式 R (U,F) ∈ 1NF, 对 R 中的任意一个非平凡的函数依赖 X->Y, X 都含有候选码, 则 R ∈ BCNF.
人话: 任何能决定某一项的东西, 都必须包含候选键.
例:
R (学生, 课程, 老师)
老师能决定课程, 但老师不能决定学生, 故不满足 BCNF.
第四范式#
不允许有非平凡且非函数依赖的多值依赖.
多值依赖: 存在独立的一对多依赖.
例如, 学生有两个属性, 选课和爱好, 选课包括英语和数学, 爱好包括唱歌和篮球, 选课和爱好无关, 如果放在一张表里:
| 学生 | 课程 | 爱好 |
|---|---|---|
| 张三 | 英语 | 篮球 |
| 张三 | 英语 | 唱歌 |
| 张三 | 数学 | 篮球 |
| 张三 | 数学 | 唱歌 |
这张表非常唐, 所以需要拆成 (学生, 课程) 和 (学生, 爱好), 满足 4NF.
第五范式#
消除了由连接依赖导致的异常.
很复杂, 一般不考.
关系模式的规范化#
无损连接性: 把大表拆成小表后, 将小表自然连接回去, 得到的数据必须和原本相同.
保持函数依赖: 原来大表里有的规则, 在拆分后的小表里, 依然能找到地方验证, 不需要把表拼起来就能验证.
无损连接的判断#
若 R 分解为 和 , 则 和 的交集是 或 的主键 (或超键), 当且仅当分解是无损的.