Database（一）数据库范式

数据库范式为数据库的设计、开发提供了一个可参考的典范，在许多教学材料中也是作为关键的课程内容。那么范式的提出是为了解决什么问题？

第一范式，要求将列尽可能最小的分割，希望消除某个列存储多个值的冗余的行为
比如用户表中的地址信息，拆分为省、市这种明确的字段，可以按独立的字段检索、查询

第二范式，要求唯一的主键，且不存在对主键的部分依赖，希望消除表中存在冗余(多余)的列
比如订单表中的商品分类、详情信息，只需要由商品信息表存储一份即可。

第三范式，要求没有间接依赖于主键的列，即仍然是希望消除表中冗余的列
比如用户表中不需要存储额外的 其所在城市的人口、城市特点等信息。

很明显，这些范式大都是为了消除冗余而提出的，即尽可能的减少存储成本。

设计关系数据库时，遵从不同的规范要求，设计合理的关系型数据库，这些不同的规范被称为不同的范式，呈递次规范，越高的范式数据库冗余越小
目前关系数据库有六种范式：第一，二，三范式，巴斯-科德范式（BCNF），第四，五范式（第五又称完美范式）

数据库只要满足第三范式就可以了。

第一范式（1NF）
在关系模型中，对于添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，
而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）
表中的每个域值只能是实体的一个属性或一个属性的一部分。
（不过有些关系模型突破了1NF的限制，是否需要满足这个要求，主要看依赖的设计模型）

第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，
作为实体的唯一标识。
（实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性）

第三范式（3NF）
在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
（例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表
中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，
则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。）

巴斯-科德范式（BCNF）
在3NF基础上，任何非主属性不能对主键子集依赖（在3NF基础上消除对主码子集的依赖）
由BCNF的定义可以得到结论，一个满足BCNF的关系模式有：
-所有非主属性对每一个码都是完全函数依赖。
-所有主属性对每一个不包含它的码也是完全函数依赖。
-没有任何属性完全函数依赖于非码的任何一组属性。

若R∈BCNF，按定义排除了任何属性对码的传递依赖与部分依赖，所以R∈3NF。 [1] 
一般关系型数据库设计中，达到BCNF就可以了！