数据库设计

      数据库的范式设计是为了优化关系数据库的关系模式，便于减少数据冗余以及冲突。而范式是建立在函数依赖的基础上的。其相关概念包括函数依赖、部分函数依赖，传递函数依赖、多值依赖、主属性（主键或者主码）和非主属性（常规列）。

      不同阶段的范式是一个不断的优化关系模式的过程，其实就是限制条件不断加强，关系模式不断精化的过程。不过随着范式的提高，关系模式（表结构）的数量也会增加，如果多个关系之间进行连接或并的操作（表连接）的话，对数据库的性能会产生影响。

      综合考虑一般精化至3NF即可。

      高阶段的范式是在低阶段范式的基础上，加入新的限制条件形成的。所以满足高范式的一定满足比其低的范式。

      第一范式（1NF）是确定模式是符合关系模式的要求，即确立某种关系属于关系模式。第一范式是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式中表的每一行只包含一个实例的信息。简而言之，第一范式就是列是不可再分、无重复的列。

      第二范式（2NF）是消除了非主属性对主码的部分函数依赖。第二范式要求数据库表中的每个实例或行必须可以被唯一地区分。这个唯一属性列被称为主属性（主码或者主键）。实体的属性完全依赖于主属性。所谓完全依赖是指不能存在仅依赖主主属性一部分的属性，如果存在，那么这个属性和主属性的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。

      第三范式（3NF）是消除了非主属性的传递函数依赖。 第三范式去除了非主属性对主属性的部分函数依赖和传递函数依赖。要求一个数据库表中的实例不能包含已在其它表中的实例的非主属性信息，不符合第三范式最常见的现象就是数据冗余。

      BC范式（BCNF）消除了所有属性的传递函数依赖，既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式。换而言之，若一个关系达到了第三范式，并且它只有一个候选码，或者它的每个候选码都是单属性，则该关系自然达到BC范式。

（1）所有非主属性对每一个码都是完全函数依赖；

（2）所有的主属性对于每一个不包含它的码，也是完全函数依赖；

（3）没有任何属性完全函数依赖于非码的任意一个组合。

      3NF去除了非主属性对主键的部分函数依赖和传递函数依赖。一般满足3NF的关系模式已能消除冗余和各种异常现象。

     第四范式取消了多值依赖。

     第五范式取消了连接依赖。

     严格的说上述两种依赖，不属于函数依赖的范畴