数据库 范式

上个星期面试，经理突然要我描述一下第三范式，脑袋居然一片空白，只好坦白说太久没看忘记了。开发的时候都是凭着直觉来写，什么所谓依赖不依赖，正常人一看就看得出来要不要把表拆开。但是真正开发的时候又发现如果拆得太细，冗余问题虽然是解决了，按orm来做，却增加了数据库的访问数量，从而降低了系统整体的运行效率...后来发现存储过程这个好东西，应该可以解决这个问题，所以..要学的东西还有很多...

.为了加强范式复习的效果，就用博文来复习吧。（以下纯属个人观点，如果错误请指正，范式标准解释请参考维基百科：http://zh.wikipedia.org/wiki/%E6%95%B0%E6%8D%AE%E5%BA%93%E8%A7%84%E8%8C%83%E5%8C%96）

数据库设计范式是符合某一种级别关系模式的集合，用自己的话来说就是用来规范关系型数据库、预防关系数据库增删错误，减少关系数据库数据冗余等作用的标准。

1NF（第一范式）：

每一列都是一个不可分割的数据项。这是关系表或者说关系数据库的基础，如果这个条件不满足，那就不是一个关系数据库了。

2NF（第二范式）：

每个非主属性完全依赖于主属性。

说白了就是有主键，或者说是表的的唯一标识符。但是这里有一个地方特别要注意的就是完全依赖这个词，举个例子，有一个杯子的价格表，杯子型号A和杯子颜色B作为主属性，价格C为非主属性，如果不同颜色的杯子是不同价格的，那么这个表示符合第二范式的，但是如果假设同一个型号的杯子价格都是雷打不动的一样的，那么就是说价格C虽然是完全依赖于A但却部分依赖于AB，这个时候这个杯子价格表就不符合第二范式了。（感觉这个例子举得不是很好，因为史蒂夫用现实告诉我们白色的iphone和黑色的iphone是可以不一样价格的..）

3NF（第三范式）：

每个非主属性即不部分依赖也不传递依赖于码，另外一种说法是非主属性不依赖于任何其他非主键属性，当然都是在2NF前提下添加的条件。

简单点说2NF基础上取消了非主属性的传递依赖。举个web开发经常遇到的，实现一个 同级分类不能重复的多级分类，为了符合第三范式，每两级分类之间的关系必须单独定义一个表，最后一级分类和分类内容作为一个表。如果不分开，那么分类内容id）就会成为主键，一级分类会函数依赖于二级分类，而二级分类必定函数依赖（直接或者间接）分类内容id，所以如果某一一级分类的某一二级分类如果有n个分类内容，那么数据库里就会重复存储n-1个一级分类的内容，于此同时，如果删除分类的最后一个内容被删除，那么这个分类就会被删除。所以数据库设计的时候最少是要到达第三范式的。

BCNF（BC范式）：

对于每一个函数依赖，被依赖的属性必须是含有码。

这个范式是3NF的加强版，表述已经非常简单明了，每个被依赖项都必须是主键，这样就确保取消了非主属性的传递依赖。其实我觉得一般的数据库设计如果准许你了第三范式，一般都会遵循BCNF范式，书上那个例子...我想一般人怎么设计都不会设计出这样的表来...

4NF（第四范式）：

每个非平凡多值依赖的被依赖项都含有码。