范式

第一范式（1NF）：

   数据库表中的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

   简而言之，第一范式就是无重复的列。例如，由“职工号”“姓名”“电话号码”组成的表(一个人可能有一部办公电话和一部移动电话)，这时将其规范化为1NF可以将电话号码分为“办公电话”和“移动电话”两个属性，即职工(职工号，姓名，办公电话，移动电话)。             

第二范式（2NF）：

   每一个非主属性完全函数依赖于R的每个候选键。

   例如，在选课关系表(学号，课程号，成绩，学分)，关键字为组合关键字(学号，课程号)，但由于非主属性学分仅依赖于课程号，对关键字(学号，课程号)只是部分依赖，而不是完全依赖，因此此种方式会导致数据冗余以及更新异常等问题，解决办法是将其分为两个关系模式：学生表(学号，课程号，分数)和课程表(课程号，学分)，新关系通过学生表中的外关键字课程号联系，在需要时进行连接。

第三范式（3NF）：

   每个非主属性都不传递依赖于R的候选键，就是说每一个非主属性都只直接依赖于主键，不能依赖其他的非主属性。

   以学生表(学号，姓名，课程号，成绩)为例，其中学生姓名无重名，所以该表有两个候选码(学号，课程号)和(姓名，课程号)，故存在函数依赖：学号——>姓名，(学号，课程号)——>成绩，唯一的非主属性成绩对码不存在部分依赖，也不存在传递依赖，所以属性属于第三范式。

   针对3NF可能出现的问题：

   主键之间存在传递依赖，可能出现插入异常，当没有内容，主键的之间的信息会丢失，删除异常，删除某个主键所有内容，就会把主键之间的信息也会删除

BC范式：

   每个属性都不传递依赖于R的候选键。

   主键之间不能相互决定，如果存在关键字段决定关键字段的情况，也是不符合BC范式的。

    针对BC范式出现的问题：

    大量的数据冗余。

第四范式：

   主要为了解决多值依赖导致的异常，对于每一个非平凡多值依赖X->Y,X必须含有码。

   例如，职工表(职工编号，职工孩子姓名，职工选修课程)，在这个表中，同一个职工可能会有多个职工孩子姓名，同样，同一个职工也可能会有多个职工选修课程，即这里存在着多值事实，孩子姓名->选修课程，这里不含有码，不符合第四范式。如果要符合第四范式，只需要将上表分为两个表，使它们只有一个多值事实，例如职工表一(职工编号，职工孩子姓名)，职工表二(职工编号，职工选修课程)，两个表都只有一个多值事实，所以符合第四范式。