一、简而言之

1、是什么？

三大范式是针对关系型数据库的一种数据库设计规范，使数据库设计符合约定的规范要求。

2、为什么要符合该规范？

为了建立冗余较小、结构合理的数据库。

3、三大范式内容的简单理解（Normal Form）
第一范式（1NF）：字段（列）不可分；
第二范式（2NF）：唯一性，一个表只说明一个事物；
第三范式（3NF）：每列都与主键有直接关系，不存在传递依赖。侧重的是直接关系。任何非主属性不依赖其它非主属性。

二、详细分析

关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。

最常见的设计范式有三种：第一范式、第二范式、第三范式。一般来说，数据库只需满足第三范式(3NF）就行了。

1、第一范式

确保每列保持原子性，不能再分啦。第一范式是最基本的范式，数据库表的每一列都是不可分割的原子数据项才是符合第一范式的。

举例：

数据库表中有 “地址” 这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。

但是如果系统经常会访问 “地址” 属性中的 “城市” 部分，那么就要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储。

这样在对地址中某一部分操作的时候将非常方便，提高了数据库的性能。这样设计才算满足了数据库的第一范式。

如下表所示：

2、第二范式

第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言），即在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

在第一范式的基础上，非码属性必须完全依赖于候选码（在第一范式基础上消除非主属性对主码的部分函数依赖）。

举例：

要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示：

订单信息表

这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关，违反了第二范式的设计原则。

改进：把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中。如下：

这样设计才符合第二范式，减小了数据库的冗余。

3、第三范式

确保每列都和主键列直接相关，而不是间接相关，在第二范式的基础上消除传递依赖。

举例：

在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。

如下面这两个表所示的设计就是一个满足第三范式的数据库表：

这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。