数据库范式

第一范式为关系数据库定下基础，满足第一范式的数据库设计必定是关系数据库。

第一范式的含义为：数据库的一行记录是确定的，不存在一行记录上的某个值（某列）有多个值（每个属性值都是不可再分的最小数据单位）。使用现在数据库管理软件不可能设计出不满足第一范式的数据库，因为它们都是以列为单位构成一行记录的。

第二范式是为了消除多余的主键（所有非主属性必然完全依赖于任意主键）。设想，一个数据表的主键为 (key1,key2) ，实质上，这个表中的非主属性只依赖于 key1，与 key2 没有关系，则这个数据表的主键应该为 key1。

它的缺点很明显，从增删改查的角度来分析，增加记录的时候，如果 key2 没有就绪，记录就插入不进来；删除一条记录可能把 key2 的信息删除了，这可能不是我们的意愿；改一条记录，还需要多传入一个无关的 key2，查也是。

满足第二范式的数据库设计不可能出现多余的主键。满足第二范式也必然满足前面的范式。

第三范式是为了消除多余的非主属性（非主属性对任何候选关键字都不存在传递依赖）。设想，一个数据表的设计为 (key,v1,v2,v3)，其中，v2 决定 v3,则这个表中的 v3 信息是是冗余信息（如果有另一个表，存放 了(v2,v3) 的映射关系），或者是易失信息（没有其它的表存放 (v2,v3)的映射关系），随着删除本表中的一条记录，(v2,v3) 的映射关系就可能丢失。而且，这个设计也会有冗余，可能一个 v2 对应多个 v3，那么，它在这个表中就会存在大量数据冗余。

满足第三范式的数据库设计不可能出现多余的非主属性。满足第三范式也必然满足前面的范式。

一般的数据库设计满足第三范式就足够了。

第四范式（BCNF）是为了消除第三范式中的主属性对主键的非完全依赖。设想，一个数据表为(v1,v2,v3,v4)，这个表中 (v1,v2) 或 (v3,v4) 是主键，但 v1 能决定v3（或称 v3 依赖于 v1），那么，当设置 (v1,v2)为主键后，就存在了 v3 对 (v1,v2)的部分依赖；这个设计是有弊端的。由于存在非完全依赖，必定会有冗余。而且删除一条记录，可能会删除与v3 相关的信息。