数据库三范式大总结

以下摘自：

数据库（第一范式，第二范式，第三范式）

 范式：英文名称是 Normal Form，它是英国人 E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的，范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。下面就简单介绍下这三个范式。 
◆ 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。 
考虑这样一个表：【联系人】（姓名，性别，电话） 
如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。1NF 很好辨别，但是 2NF 和 3NF 就容易搞混淆。 
◆ 第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。 
考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。 
因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。 
可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。 
◆ 第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。 
考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。 
其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。 
通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。 
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。

以下摘自：

数据库三范式简单理解

数据库设计当中三范式是经常遇到的，如果实际项目数据库设计中能达到第三范式基本也就满足要求了，那么如何快速有效的理解三个范式，同时应用于实际项目中去呢？

首先看看标准定义的三个范式：

第一范式（1NF)

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

我的理解：列不可分。

第二范式（2NF)

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一的区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。要求实体的属性完全依赖于主关键字。

我的理解：不能部分依赖。即：一张表存在组合主键时，其他非主键字段不能部分依赖。

第三范式（3NF)

 满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。

我的理解：不能存在传递依赖。即：除主键外，其他字段必须依赖主键。

官方标准的定义，我个人感觉说得非常术语化，比较难以理解消化。我简单的理解为三句话，非常简短，比较好理解。如果各位路过朋友们，有更好理解的总结，请不吝指出！

 

第一范式(1NF)：无重复的列

每一个属性都是原子项，不可分割。1NF是关系模型应具备最起码的条件，如果数据库设计不能满足第一范式，就不称为关系数据库。

第二范式(2NF)：属性完全依赖主键

第二范式要满足以下的条件：首先要满足第一范式，其次每个非主属性要完成函数依赖与候选健，或者主键。也就是说，每个非主属性都是由整个主键函数决定的，而不能由主键的一部分来决定。第二范式要求数据库表中的每个实例或行必须可以被唯一的区分。简而言之，第二范式就是属性完全依赖于主键。

 

第三范式(3NF)：属性不依赖于其他非主属性

满足第三范式必须先满足第二范式。简而言之，第三范式要求一个数据库表中不包含已在其他表中已包含的非关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门标号后就不能再将部门名称、部门简介等与部门有关的信息再加如员工信息表中。如果不存在部门信息表，则根据第三范式也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其他非主属性。

总结：第一范式：第一范式要求每列必需是最小的原子单元，即不能再分。第二范式：第二范式要求每列必需和主键相关，不相关的列放入别的表中，即要求一个表只描述一件事情。第三范式：第三范式要求表中各列必需和主键直接相关，不能间接相关，浏览每个表，都满足第三范式要求。