真别看吧，抄ppt而已啊
文章目录
- 6.1 引言
- 6.2 规范化
- 6.2.1 函数依赖
- 6.2.2 码
- 6.2.3 范式（Normal Form）
- 6.2.4 BC范式
- 6.2.5 规范化小结
6.1 引言
我们有这样一张表：
but 为啥这样设计呢？由此引出怎样设计一个关系数据库的问题。
进而出现：数据库逻辑设计的工具——关系数据库的规范化理论。
关系数据库有严格的理论支撑，这也是它的过人之处。
- 回顾关系模式
- 数据依赖
根据上图，关系中的映射不一定是单射的，即y不能确定x。（可能处于既不满也不单的混合态）
单射、满射、双射
X -> Y，可以认为知道了元组的X就能确定它的Y。 - 且看下面的问题
这是一个关系模式，而且不咋地。
Q: 怎么让它变好呢？
A: 通过分解关系模式来消除其中不合适的数据依赖。
为什么这样分解就好呢？
引入关系规范化
6.2 规范化
6.2.1 函数依赖
- 定义
- 解释
- 平凡与非平凡函数依赖
- 完全函数与部分函数依赖
- 传递函数依赖
事实上，如果 Y 是 X的子集或者，Y->X，那么X是直接函数决定Z的。
6.2.2 码
- 主码、候选码
- 主属性、非主属性、全码
- 外码
- 习题
AC -> A, AC -> C, A -> B => AC -> BC => AC -> D 从而 AC -> U， AC为码
6.2.3 范式（Normal Form）
-
1NF
反例：
-
2NF
反例：
坏处：
解决方法：
-
3NF
- 定义
直白点说，sdept能确定sloc，你把sloc与sdept 放在一张表里是多余的，放到(sdept,sloc)这张表里一条就够了。 - 存在问题
- 解决办法
- 习题
6.2.4 BC范式
6.2.5 规范化小结
- 习题
分成若干子表以后要多设一个表来保存二者之间的关系。
