关系型数据库的范式

　　关系型数据库有六个范式，越靠后的范式对数据库的“要求”越高。

　　我改写了描述，让其更通俗易懂，但是不太严谨，以下文字中：列对应属性、行对应实体、表对应关系。不再一一区分。对于我们使用的关系型数据库，满足第三范式即可。

　　第一范式(1NF)无重复的列

　　即每一行中，不能有两列的含义完全相同，也不能有某一列的值不确定。

　　定义：因果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模式。简单的说，每一个属性都是原子项，不可分割。 1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。

　　第二范式(2NF)属性完全依赖于主键 [消除部分子函数依赖]

　　满足第一范式，且——可以用主键(一列或多列)区分每一行。

　　定义：如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键，那么就称R是第二范式。简单的说，第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完全函数依赖与候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的，而不能由主键的一部分来决定。

　　第三范式(3NF)属性不依赖于其它非主属性 [消除传递依赖]

　　满足第二范式，且——如果某列不是主键或主键之一，那么该列仅能出现在一个表中。

　　如果关系模式R是2NF，且关系模式R(U，F)中的所有非主属性对任何候选关键字都不存在传递依赖，则称关系R是属于第三范式。简单的说，第三范式要满足以下的条件：首先要满足第二范式，其次非主属性之间不存在函数依赖。由于满足了第二范式，表示每个非主属性都函数依赖于主键。如果非主属性之间存在了函数依赖，就会存在传递依赖，这样就不满足第三范式。

　　巴德斯科范式(BCNF)

　　满足第三范式，且——主键必须最精简化。

　　BC范式是第三范式的增强版，不过也有人说是直接从1NF发展过来的，即每个属性，包括主属性或非主属性，都完全依赖于候选键，并且不存在传递依赖情况。

　　第四范式(4NF)

　　满足第三范式，且——对于全键表，删除某一列后，其他列不能重复。

　　第五范式(5NF)

　　满足第四范式，且——完全消除行冗余，这样会把表拆分得过小(一般会拆分成两列)，导致数据库支离破碎。

　　前四种范式的关系

　　

　　—————— 专注软件测试，转载请注明出处，谢谢。