依赖模式
函数依赖：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y
X->Y y 依赖x ，y的值是由x确定的，x动 y动
x -> y不依赖x，类似数学中的函数关系 y = f(x)；
非平凡函数依赖 x -/U> y
Y完全依赖x x->y, x'->y x-F>y
完全依赖：联合主键共同确定某一个列的值
部分依赖：联合主键中的某一个键自己就能确定某一个列的值 x-P>y
传递函数依赖：一个列的值通过另一个依赖主键的列的值来确定。
码：关系中的某个属性或者某几个属性的组合，用于区分每个元组（可以把“元组”理解为一张表中的每条记录，也就是每一行）。
找码：
假如A是码，那么所有包含了A的属性组，如（A，B）、（A，C）、（A，B，C）等等，都不是码了（因为作为码的要求里有一个“完全函数依赖”）
第一范式
存在非主属性对码的部分依赖关系 R(A,B,C) AB是码 C是非主属性 B-->C B决定C C部分依赖于B
定义：如果关系R 中所有属性的值域都是单纯域，那么关系模式R是第一范式的
那么符合第一模式的特点就有
1)有主关键字
2)主键不能为空，
3)主键不能重复,
4)字段不可以再分
例如：
| StudyNo | Name | Sex | Contact |
|---|---|---|---|
| 20040901 | john | Male | Email:kkkk@ee.net,phone:222456 |
| 20040901 | mary | famale | email:kkk@fff.net phone:123455 |
以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段可以再分
所以变更为正确的是
| StudyNo | Name | Sex | Email | Phone|
|:------:|:------:|:------:|:------:|
|20040901 | john | Male | kkkk@ee.net | 222456
|
|20040902 | mary | famale | kkk@fff.net | 123455|
第二范式
不存在部分依赖的表格设计（不存在某个非主属性依赖主键中的一部分）
| SNO | SDEPT | SLOC | CNO | GRADE |
|---|---|---|---|---|
| 20170101 | IS | N | 3 | 89 |
| 20170101 | IS | N | 2 | 97 |
| 20170105 | IS | N | NULL | NULL |
第一范式的问题是
- 如果要添加一个学生，但是学生还没有选课，则无法添加；
- 另外如果一个学生说不选择这门课程了，那么如果删除课程会导致学生基础信息也被删除。
- 如果一个学生选8门课程那么重复存储，数据冗余
问题的原因是：部分依赖的存在，Grade依赖CNO,解决方案是进行拆分。2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖
| SNO | CNO | GRADE |
|---|---|---|
| 20170101 | 3 | 89 |
| SNO | SDEPT | SLOC |
|---|---|---|
| 20170101 | IS | N |
第三范式
第二范式的问题:
- 插入异常 如果暂时没有学生想要添加专业的信息会出问题
| SNO| SDEPT| SLOC|
| :-------- | --------:| :------: |
| null| IS | N|
- 删除异常 删除所有学生会导致删除专业的信息
- 冗余的情况依然较大
- 修改专业信息，需要修改所有该专业的学生
问题的原因： 因为SLOC虽然依赖SNO，但是其实是由于SDEPT依赖SNO ，SLOC的值其实是SDEPT决定的，SDEPT的值由SNO决定，所以推导出SLOC是SNO的传递依赖。
解决方案 需要再对SNO 和（SDEPT）进行拆分。
| SNO| SDEPT|
| :-------- :------: |
| 20140101| IS|
| SDEPT| SLOC|
| :-------- :------: |
| IS| N|
BC范式
修正的第三范式
案例：
假设有一个表 S,T,J
一个老师只教一门课，一门课可以几个老师讲。
推导出：一个学生选择一门课就确定一个老师；一个学生选择一个老师也确定一门课
存在多组的码：
S,T 或者S,J
所有列都是主属性，没有非主属性
S-T ,T-J, S-J
(S,J)-T
J-T
主属性存在部分依赖
| S | T| J |
| :-------- :| :--------:| :------: |
| s1| JAVA| JIN|
| s1| ORACLE| WANG|
问题：
- 插入异常：老师开课，暂时没人选 无法录入
- 删除学生：老师的信息连带删除
- 数据冗余：课程数据记录过多
- 修改复杂：修改课程名称，都需要修改
| S | J|
| :-------- :| :--------:|
| s1| jin|
| s1| wang|
| T| J |
| :-------- :| :--------:|
| JAVA| JIN|
| oracle| WANG|
寻找在分解后都核心的关联字段，比如学生通过老师学习，课程通过老师讲授。
第四范式
如果满足了BC范式，那么就不再会有任何由于函数依赖导致的异常，但是我们还可能会遇到由于多值依赖导致的异常。
比如我们建立课程教师和教材的模型，我们规定，每门课程有对应的一组教师，每门课程也有对应的一组教材，一门课程使用的教程和教师没有关系。这样我们首先肯定有三个实体表，分别表示课程，教师和教材。现在我们要建立这三个对象的关系，于是我们建立的关系表，定义如下：
课程ID，教师ID，教程ID；这三列作为联合主键。
以下是示例，为了表述方便，我们用Name代替ID，这样更容易看懂：
| Course | Teacher | Book |
|---|---|---|
| 英语 | Bill | 人教版英语 |
| 英语 | Bill | 美版英语 |
| 高数 | Dave | 美版高数 |
这个表除了主键，就没有其他字段了，所以肯定满足BC范式，但是却存在多值依赖导致的异常。
我们先来看看多值依赖的定义：
一个关系，至少存在三个属性（A、B、C），才能存在这种关系。对于每一个A值，有一组确定的B值和C值，并且这组B的值独立于这组C的值。
假如我们下学期想采用一本新的英版高数教材，但是还没确定具体哪个老师来教，那么我们就无法在这个表中维护Course高数和Book英版高数教材的的关系。
解决办法是我们把这个多值依赖的表拆解成2个表，分别建立关系。这是我们拆分后的表：
| Course | Teacher |
|---|---|
| 英语 | Bill |
| 高数 | Dave |
| Course | Book |
|---|---|
| 英语 | 人教版英语 |
| 高数 | 美版高数 |
第四范式的定义很简单：已经是BC范式，并且不包含多值依赖关系。
网友评论