数据库之依赖

前言

我曾经考过两次数据库，每次都过了及格线，但是被无情得抹下去了。这次我要考90我看你怎么让我不及格，哼。

概念

关系模式

1. R 关系名
2. U 属性集合
3. D U中属性来自的域
4. DOM 属性向域映像
5. F 依赖关系集合
   也可以简化成 R ( U , F )

类型

1. 函数依赖
2. 多值依赖

案例

建立一个库，有学号Sno,系Sdept,主任名字Mname,课程名Cname,成绩Grade，那么单一关系模式 Student<U,F>
集合：U = { Sno,Sdept,Mname,Cname,Grade }
函数依赖: F={ Sno -> Sdept, Sdept -> Mname,(Sno,Cname)->Grade }
余以为其中意思就是： 了解学号才能找出他属于哪个系，了解系名才会知道系主任叫啥，只有确定那个学生考的哪一门课，才可找到得分多少。

公式化一下概念，这样更加有感觉嘛。

依赖带来的问题

对我这个菜鸟来说都是些奢侈的问题（毕竟没有接触到大量的数据）
以下问题我觉得都是大同小异。

1. 冗余（信息重复出现）
2. 更新异常 （信息不一致）
3. 插入异常
4. 删除异常

规范化

既然有这么多问题，自然要规范数据库啦，所以我们就迎来了规范化理论。
->-> 分解关系模式

函数依赖

X->Y，那么X就叫决定属性组，叫啥都没差。

分类1

• 平凡函数依赖 还是在自己这圈子里晃悠，就像 学号还是依赖于 学号和课程号，说了等于白说（没吊用）。
• 非平凡函数依赖 一定要推导出第三者，这个就有意思了（指不平凡）。

分类2

• 完全函数依赖(F) 不多余，干干净净得依赖，挺好。
• 部分函数依赖§ 就多余了，明明自己一个属性能搞定，非要带个无关紧要的小弟，余以为不可取。

传递函数依赖

人如其名，星火相传。

码

• 能推出所有属性的叫候选码 （有代表性）
• 候选码可多于一个，选其中一个作主码。
• 包含在任何一个候选码中的属性叫主属性
• 不包含候选码叫非主属性
• 整整一个属性组是码，就叫全码
• 外码，另一个关系模式的码，我老用的

案例

P:演奏者，W：作品，A：听众
R(P,W,A)

一个演奏者P可以有多个听众A
一个乐曲W可以有多个演奏者P
一个乐曲W可以有多个听众A

则码为(P,W,A)，即为全码。

范式

关系满足的不同等级（大概是越严越好）
大体是一二三四五，三和四夹一个BC
你若是想要升级，就要规范化（模式分解）

第一层境界：

最最最最基本，最最最起码
属性不可分割

第二层境界

非主属性完全依赖于码
（一个码能得到其它所有数据，且这个码还不能少）
此境界是对部份依赖赶尽杀绝

第三层境界

去除非主属性对码的传递函数依赖
若在二层境界精进修炼，去除传递依赖，则可以到达第三层境界。
此境界对传递依赖赶尽杀绝

BC境界

每个决定属性因素都包含码。
修炼到了第三境界，可是自己的核心却受到了损伤。所以这个境界是对主属性进行规范的。

数据依赖公理系统Armstrong

推理规则

• 自反：永远能推出自己的 (A1)
• 增广：X->Y那么，XZ->YZ (A2)
• 传递：X->Y,Y->Z,那么X->Z (A3)

导出规则

• 合并规则：X->Y,X->Z,则X->YZ (A2,A3)
• 伪传递：X->Y,WY->Z,则WX->Z (A2,A3)
• 分解规则 (A1,A3)

闭包

R<U,F>中F所逻辑蕴含的函数依赖全体叫"F的闭包"

规范化小节

就是概念单一化