数据库入门之<范式概念解析>

[size=medium][color=green][b]基本范式概念解析[/b][/color][/size]

[color=black]范式:英文名称是 Normal Form,最早是由英国人 E.F.Codd在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法。 目前有迹可寻的共有8种范式,依次是: 1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。 其中,最基本的三个范式是1NF,2NF,3NF。[/color]


[color=green]第一范式(1NF):[/color] [color=black]强调的是列的原子性,即列不能够再分成其他几列。
如:订单表【订单编号,订单日期,客户编号,产品】。实际情况中,产品这一列(字段)可能包括多种产品(如:产品一,产品二,产品三)。那么,这种表结构设计就没有达到1NF的要求。要使之符合1NF则需将产品这一列拆开来,【订单编号,订单日期,客户编号,产品一,产品二,产品三】。[/color][color=green]


第二范式(2NF):[/color] [color=black]在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多次重复的情况。[/color]
[color=green]

第三范式(3NF):[/color] [color=black]在满足1NF、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关键点在于: 非主键列是直接依赖于主键,还是直接依赖于非主键列。

数据库设计过程:抽象出实体(确定其属性方法);确定对象间的关系(1-1,1-n,n-n);按照范式建表;
[/color]
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值