数据库设计三范式

计算机擅长接受指令，不擅了解你的思想。——高德纳（Donald Knuth）。现代计算机鼻祖，《计算机程序设计艺术》作者

在设计关系数据库时，需要遵从不同的规范，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式。

各范式呈递次规范，越高的范式数据库冗余越小。

关系数据库六范式

第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。

一般来说，数据库只需满足第三范式(3NF）就行了。

第一范式

原子性。即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。

第一范式（1NF）是对关系模式的设计基本要求。

例子：

表1字段为：

用户，姓名，手机，地址

表2字段为：

用户，姓名，手机，省，市，详细地址

表1要查询某个省某个市并按其分类，显然无法满足，也不符合第一范式。

第二范式

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。

第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。即表必须有主键。

第二范式（2NF）要求实体的属性完全依赖于主关键字，所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。

例子：

表1字段为：

订单id，商品id，商品价格，折扣，数量，商品名

我们知道一个订单中可以有多个商品，所以单一的订单id是不足以成为主键的，主键应该是（订单id + 商品id），可以看到折扣和数量完全依赖（取决）于主键，而价格，商品名只依赖于商品id。所以表1不符合2NF，就会造成数据冗余，应该将其拆分成2个表，如下表2和表3。

表2字段为：

订单id，商品id，折扣，数量

表3字段为：

商品id，商品价格，商品名

第三范式

第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。

任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）。

例子：

表1字段为：

订单id，订单日期，用户id，用户姓名，用户城市

主键是订单id

其中非主键列订单日期、用户id、用户姓名、用户城市完全依赖于主键（订单id），不存在部分依赖的问题，所以符合2NF，但用户姓名、用户城市直接依赖的是用户id（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。需要将其拆分，如下表2和表3。

表2字段为：

订单id，订单日期，用户id

表3字段为：

用户id，用户姓名，用户城市

总结

1NF好辨认，但2NF和3NF很容易混淆，关键区别如下。

2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分。

3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。