1NF-2NF-3NF-4NF.docx

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