简介

　　数据库范式在数据库设计中的地位一直很暧昧，教科书中对于数据库范式倒是都给出了学术性的定义，但实际应用中范式的应用却不甚乐观，这篇文章会用简单的语言和一个简单的数据库DEMO将一个不符合范式的数据库一步步从第一范式实现到第四范式。

　　范式的目标

　　应用数据库范式可以带来许多好处，但是最重要的好处归结为三点：

　　1、减少数据冗余（这是最主要的好处，其他好处都是由此而附带的）

　　2、消除异常（插入异常，更新异常，删除异常）

　　3、让数据组织的更加和谐…

　　但剑是双刃的，应用数据库范式同样也会带来弊端，这会在文章后面说到。

　　什么是范式

　　简单的说，范式是为了消除重复数据减少冗余数据，从而让数据库内的数据更好的组织，让磁盘空间得到更有效利用的一种标准化标准，满足高等级的范式的先决条件是满足低等级范式。（比如满足2nf一定满足1nf）

　　DEMO

　　让我们先从一个未经范式化的表看起，表如下：

　　先对表做一个简单说明，employeeId是员工id，departmentName是部门名称，job代表岗位，jobDescription是岗位说明，skill是员工技能，departmentDescription是部门说明，address是员工住址

　　对表进行第一范式（1NF）

　　如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF。

　　简单的说，第一范式就是每一个属性都不可再分。不符合第一范式则不能称为关系数据库。对于上表，不难看出Address是可以再分的，比如”北京市XX路XX小区XX号”，着显然不符合第一范式，对其应用第一范式则需要将此属性分解到另一个表，如下：

　　对表进行第二范式（2NF）

　　若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于R的码，则R∈2NF

　　简单的说，是表中的属性必须完全依赖于全部主键，而不是部分主键.所以只有一个主键的表如果符合第一范式，那一定是第二范式。这样做的目的是进一步减少插入异常和更新异常。在上表中，departmentDescription是由主键DepartmentName所决定，但却不是由主键EmployeeID决定，所以departmentDescription只依赖于两个主键中的一个，故要departmentDescription对主键是部分依赖，对其应用第二范式如下表：