
1) | 下面的这个数据库里面:我们的这个学号决定了系部,因此我们可以说这个西部依赖于学号; |
|---|---|
我们的系部决定了这个系主任的名字,我们可以说这个系主任的名字依赖于这个系部; | |
我们的这个学号和课程号决定这个课程的成绩,因此这个成绩依赖于这个课程号和学号组成的这个集合 |

1) | 下面的这个图就是对于上面的这个依赖关系的可视化的效果: |
|---|---|

1) | 单一模式存在的这个问题: |
|---|---|

我们的解决方案就是把上面的这个关系模式进行分解,消除这个不合适的数据以来对于其他的数据的影响;


下面的这个是我们的平凡函数依赖和非平凡函数依赖的这个定义,很好理解,但是这个名字起的让人不知道是什么意思~~~

下面的这个是完全函数依赖和部分函数依赖,这个也是结合下面的这个案例进行理解:

传递依赖类似于我们学习的这个传递性,就是一个道理,这个我们后续介绍这个范式的时候会使用到这个传递依赖进行范式的判断;

码:就是我们的这个函数依赖里面的这个前者(是我个人的理解):
例如这个sno,cno----------->grade:因此这个里面的学号和课程号就是码;
sno----->sdept因此这个里面的sno就是码;

1) | 下面的这个就是对于外码的一个解释: |
|---|---|
2) | 简单说明一下,这个为什么在这个sc里面的这个sno不是码,这个是因为sno和cno组合在一起才可以决定我们的grade,因此无论是单独的这个sno和sno都不是码,只有组合在一起才是码; |

1) | 下面的这个就是我们的范式的分类; |
|---|---|

1) | 关系数据库都是需要满足这个第一范式的:第一范式是我们的这个关系数据库最基本的这个要求; |
|---|---|

1) | 第二范式是基于这个第一范式进行定义的:如果这个范式是第二范式,那么肯定是第一范式,这个是我们首先需要明白的 |
|---|---|
2) | 我们的这个码是sno,cno,这个sdept就可以决定sloc,因为系部一样学生住的地方是一样的,但是我们的这个码sno,cno部分决定sdept,因此这个不满足我们的这个第二范式的定义,所以只能是第一范式; |
3) | 码:可以决定这个元组里面的所有的信息:因此这个下面写的这个sno,cno-------->sdept这个是我们的码的定义,不要问为什么(问的时候一定要去查看这个定义,我知道很多人这个地方想不明白,包括我自己在内) |

这个想要解决解决依赖的问题:就需要使用这个分解,把这个关系模式进行下面的分解,解决部份依赖问题:

1) | 第三范式就是在这个第二范式的基础上面,消除这个非主属性对于码的传递依赖; |
|---|---|

1) | 上面讨论的都是我们的非主属性对于码的依赖,我们的这个BC范式要求这个主属性对于码也要完全依赖(在第三范式的基础上面) |
|---|---|

) |