数据库三大范式

数据库三大范式

分类： 数据库 012-05-26 21:58   593人阅读   评论(0)   收藏   举报

 

第一范式（1NF）：

是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。

第二范式（2NF）：

要求数据库表中的每个实例或行必须可以被惟一地区分，数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

第三范式（3NF）：

要求一个数据库表中不包含已在其它表中已包含的非主关键字信息，在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。

上述三大范式说的有点官话，听不太明白，下面我就简单的说说这三大范式。

第一范式，确保每列的原子性。

例如，数据库中的一列一般不能是地址姓名，而应该将其分成俩列，地址和姓名。再如，地址是国家和城市组成的话，一般应该将地址再细分为，国家和地址，不能笼统的写地址。

第二范式指的是，在满足第一范式的条件下，并且除了主键以外的其他列，都依赖于该主键，也就是要求每个表中只描述一件事情。例如：

 

 如上图所示，第一个Orders里的四个字段，讲述的是俩个事情（订单和产品），也就是说，产品编号和产品价格并不依赖于订单，所以应该分成俩个表，这样就符合第二范式的要求。

第三范式要求：在满足第二范式的条件下，并且除了主键以为的其他列都不传递依赖于主键列。

  

如上图所示，第一个Orders里的订购日期和顾客编号依赖于主键订单编号，但是顾客姓名却是依赖于顾客编号然后再和订单编号。所以应该改成第二个Orders的样式，就满足第三范式了。数据库的三大范式，可以使数据库的的设计更加规范，避免数据冗余！

关于数据库三大范式有两种说法，一是：
1.字段不可分。
2.有主键，非主键字段依赖主键。
3.非主键字段不能相互依赖。
另外一种说法是：
第一范式： 
1、内容相似的数据列必须消除(消除的办法就是再创建一个数据表来存放他们，建立关联关系) 
2、必须为每一组相关数据分别创建一个表 
3、每条数据记录必须用一个主键来标示 
第二范式： 
1、只要数据列里面的内容出现重复，就意味着应该把表拆分为多个表 
2、拆分形成的表必须用外键关联起来。 
第三范式： 
1、与主键没有直接关系的数据列必须消除(消除的办法就是再创建一个表来存放他们) 
◆ 第一范式（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：非主键列是直接依赖于主键，还是直接依赖于非主键列。