数据库设计理论

依赖模式

函数依赖：若在一张表中，在属性（或属性组）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:[email protected],phone:222456
20040901	mary	famale	email:[email protected] phone:123455

以上的表就不符合，第一范式：主键重复(实际中数据库不允许重复的)，而且Contact字段可以再分

所以变更为正确的是

| StudyNo | Name | Sex | Email | Phone|
|:------:|:------:|:------:|:------:|
|20040901 | john | Male | [email protected] | 222456
|
|20040902 | mary | famale | [email protected] | 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范式，并且不包含多值依赖关系。