数据库范式

数据库范式
设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

目前关系数据库有六种范式

第一范式（1NF）
第二范式（2NF）
第三范式（3NF）
巴斯-科德范式（BCNF）
第四范式(4NF）
第五范式（5NF，又称完美范式）
第一范式（1NF）
所谓第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的设计基本要求，一般设计中都必须满足第一范式（1NF）。不过有些关系模型中突破了1NF的限制，这种称为非1NF的关系模型。换句话说，是否必须满足1NF的最低要求，主要依赖于所使用的关系模型。

第二范式（2NF）
在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

第三范式（3NF）
在（1NF）基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。简而言之，第三范式就是属性不依赖于其它非主属性，也就是在满足2NF的基础上，任何非主属性不得传递依赖于主属性。

巴斯-科德范式（BCNF）
Boyce-Codd Normal Form（巴斯-科德范式）
所谓BCNF，是指在第三范式的基础上进一步消除主属性对于码的部分函数依赖和传递依赖。BCNF需要符合3NF，并且，主属性不依赖于主属性。

4NF（第四范式）
对于第四范式，从理论层面来讲是，关系模式R∈1NF,如果对于R对于R的每个非平凡多值依赖X→Y(Y不属于X),X都含有候选码，则R∈4NF。4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。显然一个关系模式是4NF，则必为BCNF。

也就是说，当一个表中的非主属性互相独立时（3NF），这些非主属性不应该有多值。若有多值就违反了第四范式。

5NF（第五范式）
不得存在不遵循键约束的非平凡连接依赖。如果且只有一个表符合4NF，同时其中的每个连接依赖被候选键所包含，此表才符合第五依赖。

示例表数据
假设有一个名为employee的员工表，它有九个属性：id(员工编号)、name(员工名称)、mobile(电话)、zip(邮编)、province(省份)、city(城市)、district(区县)、deptNo(所属部门编号)、deptName(所属部门名称)、表总数据如下：

一列存多条

id	name	mobile	zip	province	city	district	deptNo	deptName
101	张三	13910000001,13910000002	100001	北京	北京	海淀区	D1	部门1
101	张三	13910000001,13910000002	100001	北京	北京	海淀区	D2	部门2
102	李四	13910000003	200001	上海	上海	静安区	D3	部门3
103	王五	13910000004	510001	广东省	广州	白云区	D4	部门4
103	王五	13910000004	510001	广东省	广州	白云区	D5	部门 5

由于此员工表是非规范化的，我们将面对如下的问题。

修改异常：上表中张三有两条记录，因为他隶属于两个部门。如果我们要修改张三的地址，必修修改两行记录。假如一个部门得到了张三的新地址并进行了更新，而另一个部门没有，那么此时张三在表中会存在两个不同的地址，导致了数据不一致

新增异常：假如一个新员工假如公司，他正处于入职培训阶段，还没有被正式分配到某个部门，如果deptNo字段不允许为空，我们就无法向employee表中新增该员工的数据。

删除异常：假设公司撤销了D3部门，那么在删除deptNo为D3的行时，会将李四的信息也一并删除。因为他隶属于D3这一部门。

第一范式(1NF)
表中的列只能含有原子性(不可再分)的值。

表中的张三有两个手机号存储在mobile列中，违反了 1NF 规则。为了使表满足 1NF，数据应该修改如下：

id	name	mobile	zip	province	city	district	deptNo	deptName
101	张三	13910000001	100001	北京	北京	海淀区	D1	部门1
101	张三	13910000002	100001	北京	北京	海淀区	D1	部门1
101	张三	13910000001	100001	北京	北京	海淀区	D2	部门2
101	张三	13910000002	100001	北京	北京	海淀区	D2	部门2
102	李四	13910000003	200001	上海	上海	静安区	D3	部门3
103	王五	13910000004	510001	广东省	广州	白云区	D4	部门4
103	王五	13910000004	510001	广东省	广州	白云区	D5	部门 5

第二范式(2NF)
第二范式要同时满足下面两个条件

满足第一范式

没有部分依赖

例如，员工表的一个候选键是{id，mobile，deptNo}，而deptName依赖于deptNo，同样 name 依赖于 id，因此不是 2NF的。为了满足第二范式的条件，需要将这个表拆分成employee、dept、employee_dept、employee_mobile四个表。如下：

员工表 employee

id	name	zip	province	city	district
101	张三	100001	北京	北京	海淀区
102	李四	200001	上海	上海	静安区
103	王五	510001	广东省	广州	白云区

部门表 dept

deptNo	deptName
D1	部门1
D2	部门2
D3	部门3
D4	部门4
D5	部门5

员工部门关系表 employee_dept

id	deptNo
101	D1
101	D2
102	D3
103	D4
104	D5

员工电话表 employee_mobile

id	mobile
101	13910000001
101	13910000002
102	13910000003
103	13910000004

第三范式(3NF)
第三范式要同时满足下面两个条件

满足第二范式
没有传递依赖
例如，员工表的province、city、district依赖于zip，而zip依赖于id，换句话说，province、city、district传递依赖于id，违反了 3NF 规则。为了满足第三范式的条件，可以将这个表拆分成employee和zip两个表，如下

employee

id	name	zip
101	张三	100001
102	李四	200001
103	王五	510001

地区表area

zip	province	city	district
100001	北京	北京	海淀区
200001	上海	上海	静安区
51000	广东省	广州	白云区

在关系数据库模型设计中，一般需要满足第三范式的要求。如果一个表具有良好的主外键设计，就应该是满足3NF的表。规范化带来的好处是通过减少数据冗余提高更新数据的效率，同时保证数据完整性。然而，我们在实际应用中也要防止过度规范化的问题。规范化程度越高，划分的表就越多，在查询数据时越有可能使用表连接操作。而如果连接的表过多，会影响查询性能。关键的问题是要依据业务需求，仔细权衡数据查询和数据更新关系，指定最合适的规范化程度。不要为了遵循严格的规范化规则而修改业务需求。