对于数据库范式（1NF，2NF，3NF，BCNF）的理解

第一范式

定义：属于第一范式关系的所有属性不能够再被拆分，即为一张简单的基本表

一个列名智能对应到一列，并且每一列都不可分

复杂表还能继续拆分，不符合第一范式：

符合基本范式的基本表：

定义：前提是满足第一范式且每个非主属性完全函数依赖于任何一个候选码则关系R为第二范式

什么候选码？

若关系中的某一属性组的值能唯一地标识一个元组，而其子集不能，则称该属性组为候选码。若一个关系中有多个候选码，则选定其中一个为主码。

什么是主属性？

所有候选码的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。

什么是完全函数依赖？

设R(U)是属性集U上的关系模式，X、Y是U的子集。如果Y函数依赖于X，且对于X的任何一个真子集X’，都有Y不函数依赖于X’，则称Y对X完全函数依赖。记作：如果Y函数依赖于X，但Y不完全函数依赖于X，则称Y对X部分函数依赖。

简单说就是：指不能存在仅依赖于候选键（主属性）的一部分的属性，所以只有一个主属性的表如果符合第一范式就一定符合第二范式。

如何判断是否符合第二范式？

定义：非主属性既不传递依赖于码，也不部分依赖于码，相互独立不存在其他函数关系

也就是在第二范式的基础上消除传递函数依赖，每一列（所有的非主属性）都要与候选码直接相关，而非间接相关，既不部分依赖于候选码，也不传递依赖于候选码。

也就是修正后的第三范式

定义：设关系模式R满足第一范式，如果对于R的每个函数依赖，X->Y,若Y不属于X，则X必含有候选码，那么R属于bc范式

换句话说，在关系模式R中，如果每一个决定属性集都包含候选码，则R属于bc范式，没有任何属性（主属性和非主属性）对候选码有部分函数依赖和传递函数依赖

将一个2NF关系采用投影分解的方法，分解成多个3NF的关系，可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。

但将一个2NF关系分解成多个3NF的关系后，在有些情况下，也还是不能完全消除关系模式中的各种异常情况和数据冗余。

哪里不符合BC范式，哪里就会出现冗余

范式级别越高、信息越分散，查询也越难