目录
什么是数据依赖？
如下左图，这样的一张关系表如果一个系八百个人，同一个系主任名字可能被重复八百遍！所以为了避免冗余，我们可以使用右图的关系依赖：
学号确定了所在系，所在的系对应其系主任。学号和课程序号加起来就确定了某人的成绩啦（右图：函数依赖）
什么是规范化理论？
找出关系模式中不合适的数据依赖，消除它们，可以在不同程度上解决插入异常，删除异常、更新异常和数据冗余问题。就是设计合适的数据库逻辑模式。
函数依赖
- 平凡函数依赖
- 非平凡函数依赖
完全函数依赖
在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。
例：成绩表（学号，课程号，成绩）关系中，
完全函数依赖：（学号，课程号）→ 成绩，学号 －\→ 成绩，课程号 －\→ 成绩，所以（学号，课程号）→ 成绩 是完全函数依赖
部分函数依赖
例1在关系模式Student中，因为Sno不能函数决定Grade，Cno也不能函数决定Grade，但(Sno，Cno)可以唯一地函数决定Grade，所以(Sno，Cno)→Grade是完全函数依赖。因为Sno可以函数决定Sage，所以(Sno，Cno)→Sage是部分函数依赖。
传递函数依赖：这样婶儿哒↓↓↓
码
范式
符合某一种级别的关系模式的集合
第一范式（1NF）
一个关系所有属性都是不可分的基本数据项
| 期初余额 | 本期发生额 | 期末余额 | |||
| 借方 | 贷方 | 借方 | 贷方 | 借方 | 贷方 |
| 12 | 23 | 55 | 35 | 56 | 35 |
| 134 | 435 | 534 | 35 | 35 | 566 |
| 245 | 245 | 35 | 56 | 53 | 53 |
如上图就不是第一范式：期初余额、本期发生额、期末余额都可分
第一范式是对关系模式最起码的要求，不满足第一范式的数据库模式不能称为关系数据模式。
第二范式（2NF）
若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于R的码，则R∈2NF
不符合第二范式的例子
| 货物类型 | 货物ID | 货物名称 | 注意事项 |
| 瓷碗 | 1 | 白色瓷碗 | 易碎品 |
| 瓷碗 | 2 | 青花瓷碗 | 易碎品 |
| 瓷碗 | 3 | 雕花瓷碗 | 易碎品 |
| 三合板 | 1 | 普通三合板 | 易燃物品，注意防火 |
在该表中主键为（货物类型，货物ID），货物名称字段完全依赖于这个主键，换句话说，货物的名称完全是取决于这个主键的值的。但“注意事项”这一列，仅依赖于一个主键中”货物类型“这一个属性。简单地说，第二范式要求每个非主属性完全依赖于主键，而不是仅依赖于其中一部分属性。
那么，既然表中存在一个对主键不是完全依赖的字段，那么我们就可以确定，该表不符合第二范式。
符合第二范式的例子
| 货物类型 | 货物ID | 货物名称 |
| 瓷碗 | 1 | 白色瓷碗 |
| 瓷碗 | 2 | 青花瓷碗 |
| 瓷碗 | 3 | 雕花瓷碗 |
| 三合板 | 1 | 普通三合板 |
在该表中的主键依然是（货物类型、货物ID），非主键字段“货物名称”，完全依赖于这两个主键，那么我们就可以说，该表是符合数据库第二范式的。
例：不符合第二范式的可以使用投影分解法，把关系模式分解为两个（或多个）关系模式，消除部分函数依赖：
第三范式（3NF）
在第二范式的基础上消除传递依赖，就是第三范式。
- 不符合第三范式的例子
这样的传递依赖使Sloc不能随意修改，Sdept不能随意删除等等，存在冲突！
可以使用投影分解法修改为第三范式，消除传递依赖，如下图小方块↓↓↓
这样就不存在刚才那些异常了，变成了这样，解决了上述冲突:
- 符合第三范式的例子
下面正式介绍3NF：
BC范式（BCNF）-- 也叫作修正的第三范式
满足BC范式的关系将消除任何属性（主属性和非主属性）对关系键的部分函数依赖和传递函数依赖。在函数依赖的范畴内，它实现了模式的彻底分解，达到了最高的规范化程度，消除了操作异常诸多问题。
- 不符合第三范式的例子
这样的传递使没有学生的老师不能入数据库等等问题。
可以使用投影分解法修改为BC范式，消除传递依赖，如下图小方块↓↓↓
总之，如果不存在
–>C , B–>C 类似这样的情况，也就是说部分函数依赖。
A–>B , B–>C 这种情况，也就是传递函数依赖，不管这些ABC属性是主属性还是非主属性，反正就是不存在 “部分函数依赖和传递函数依赖” ，这就是
关系模式规范化总结
