数据库设计中的范式理论小结

关系数据库中的关系必须满足一定的要求，数据库的设计范式简单的说就是数据库设计的规范。只有理解数据库的设计范式，才能设计出高效率、优雅的数据库。

范式有哪些

按照满足设计规范的不同程度,范式又被划分多个等级。目前，主要有六种范式：

• 第一范式、
• 第二范式、
• 第三范式、
• BC范式、
• 第四范式、
• 第五范式。

他们的关系是，满足最低要求的叫第一范式，简称1NF。在第一范式基础上进一步满足一些要求的为第二范式，简称2NF。其余依此类推。

第一范式(1NF)

简单的说，即每一个属性都是原子项，不可分割。
数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值

1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。

第二范式

简单的说，第二范式要满足以下的条件：

• 首先,要满足第一范式，
• 其次,每个非主属性要完全函数依赖与候选键，或者是主键。(即，数据库表中的每个实例或行必须可以被唯一地区分)

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。

第三范式

• 首先要满足第二范式，
• 其次非主属性之间不存在函数依赖。(即，属性不依赖于其它非主属性)

简而言之，第三范式（3NF）要求 一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。
那么在其他的信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入其他的信息中。

简单的说：

• 一范式就是属性不可分割。（属性就是表中的字段）
• 二范式就是要有主键，要求其他字段都依赖于主键。
• 三范式就是要消除传递依赖，方便理解，可以看做是“消除冗余”

反范式

反范式是通过增加冗余数据或数据分组来提高数据库读性能的过程。
在某些情况下， 反范式有助于掩盖关系型数据库软件的低效。
关系型的范式数据库即使做过优化， 也常常会带来沉重的访问负载。

范式与反范式的选择

范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦，但是操作困难，因为需要联系多个表才能得到所需要数据，而且范式越高性能就会越差。要权衡是否使用更高范式是比较麻烦的。

但是，反范式数据模型与没有范式化的数据模型不同。 只有在范式化已经达到一定的满意水平并且所需的约束和规则都已经建立起来， 我们才进行反范式化。例如，所有的关系都属于第三范式， 连接的关系和多值依赖得到了妥善处理。

一般在项目中，用得最多的也就是第三范式，我认为使用到第三范式也就足够了，性能好而且方便管理数据。