规范化理论-函数依赖-范式-简单粗暴

一.为什么要设计范式？
避免插入，删除，更新，冗余异常

二、基本概念
实体：一张数据库表，比如：学生表，学生就是一个实体
属性：一张表（实体）会有很多属性，比如一个学生实体会有学号，班级等属性
候选码：可以决定其他属性的集合，比如A->B ,A->C,C->D
那么A,B,C就是候选码
主码（主关键字）：候选码中的一个，例如学生的学号就可以作为一个主码，因为这个学号可以决定班级，等等其他属性
元组：表的一行数据的集合就是一个元组
全码：如果一个属性可以确定所有的其他属性，则这个就是全码
外码：一个属性（不是主码），它是其他表的主码，则称它为这个表的外码

三、函数依赖
1.完全函数依赖：非主属性依赖所有的关键字（候选码）
例如：R实体有A,B,C,D,E,F的属性，其中A,B是候选码，A->C,B->C等等
这就满足完全函数的依赖了

2.部分函数依赖：与上大同小异，非主属性部分依赖关键字
比如：A->C,这个C没有依赖B，就说明是部分部分函数依赖

3.传递函数依赖：X Y Z是R的不同属性子集，就是说XYZ是不同列的
如果X->Y , Y->Z并且X不包含Y，Y不确定X（Y!->X），这样就是传递函数依赖

4.平凡函数依赖：U包含XY，X->Y，并且X包含Y

四、范式
1.第一范式（1NF）

就是说，一个属性下面不能再分了，有人看到这里会感到奇怪，这个1NF我要注意什么，感觉现在的数据库系统也没法设计成这样的，对，现在设计不出这样的了，因为现在的系统就可以自动的满足第一范式了

2.第二范式(2NF)
第二范式就是不允许有部分函数依赖
例如：A,B是候选码，A->C,C没有依赖B，这就是部分函数依赖了，所以这种就不是2NF，那么怎么解决呢
分成两个表 T1 A,C
T2 A,B
这样A->C这就是完全函数依赖

3.第三范式(3NF)
不允许非关键字对关键字的传递函数依赖
比如：A是关键字 A->B B->C
这里就存在c（非关键字）对A（关键字）的传递函数依赖

以上是自己在复习数据库期间整理总结的，适合应付考试