我对数据库范式的理解

1NF：第一范式—— 即关系模式中的属性的值域中每一个值都是不可再分解的值。

数据库表中每一列的值都是来自一个“域”，并且只能取这个域中的一个值而不能是集合。如何是集合的话SQL的很多基本操作就无法成立了。

2NF：如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的某个候选键， 则称为第二范式模式。

3NF：如果关系模式R是第二范式，且每个非主属性都不传递依赖于R的候选键，则称R为第三范式模式。

BCNF：若关系模式R是第一范式，且每个属性都不传递依赖于R的候选键。

2NF、3NF、BCNF的核心作用就是消除多余的关系，从而使一张表只明确表达“唯一的某种实体关系”。

2NF的理解：候选键的作用是标识唯一的一个实体，而非主属性是对这个实体的进一步描述。如果某个非主属性不完全依赖于某个候选键（违反1NF），而是部分依赖（依赖于候选键的某个子集），也就是说这个非主属性本质是另一个实体的进一步描述，那么它在当前的表中就必然会出现描述上的冗余，从而导致存储异常状况的发生。例如：“员工号”是“员工”实体的候选键，而“员工姓名”（有可能重名）是“员工”实体的补充描述，所以如果把“员工号”和“员工姓名”都放到“员工任务”表中，就出现了问题，因为“员工任务”表描述的是员工和任务的对应关系，而“员工姓名”只能描述员工，这样就可能出现存储异常，例如同一个员工的所有记录中姓名并不一致（更新异常）。（总结：非主属性是用来描述表所代表的实体的，而不应该是描述部分候选键的。）

3NF的理解：非主属性是描述表所代表的实体的，而不应该是描述非主属性的，否则就会出现描述上的冗余。例如：“员工表”上有“入职年限”和“带薪假”两列，两者之间存在着一定关系，例如：小于5年的2天，5-10年的5天，10年以上的10天等。也就是说属性“带薪假”的值决定于“入职年限”的取值范围，而不是员工实体。这样也有可能出现更新异常等。

BCNF的理解：如果候选键中的属相间存在依赖，就出现了和3NF中描述的类似情况。例如还是“员工任务”表中，“员工号”、“员工身份证号”和“任务号”是候选键，显然“员工号”和“员工身份证号”之间存在一对一的联系，但是它们的组合会在表中出现多次，存在冗余，又会产生存储异常的问题。

考虑范式的时候必须要注意，范式的作用是规范，是为了更好用，违反范式并不意味着表不能用了，而是可能出现存储异常的错误。