嗨客网搜索
数据库三大范式

什么是数据库范式

设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。范式来自英文 Normal form,简称 NF。

要想设计—个好的关系,必须使关系满足一定的约束条件,此约束已经形成了规范,分成几个等级,一级比一级要求得严格。满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。

数据库范式分类

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般来说,数据库只需满足第三范式(3NF)就行了。

第一范式(1NF)

定义

确保每列保持原子性。

说明

第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值,就说明该数据库表满足了第一范式。

案例

第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到 “地址” 这个属性,本来直接将 “地址” 属性设计成一个数据库表的字段就行。但是如果系统经常会访问 “地址” 属性中的 “城市” 部分,那么就非要将 “地址” 这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式,如下表所示:

10_数据库三大范式.png

上表所示的用户信息遵循了第一范式的要求,这样在对用户使用城市进行分类的时候就非常方便,也提高了数据库的性能。

第二范式(2NF)

定义

确保表中的每列都和主键相关。

说明

第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关,而不能只与主键的某一部分相关(主要针对联合主键而言)。也就是说在一个数据库表中,一个表中只能保存一种数据,不可以把多种数据保存在同一张数据库表中。

案例

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

11_数据库三大范式.png

这样就产生一个问题:这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关,而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。而如果把这个订单信息表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中,就非常完美了。如下所示:

12_数据库三大范式.png

这样设计,在很大程度上减小了数据库的冗余。如果要获取订单的商品信息,使用商品编号到商品信息表中查询即可。

问题

如果不满足第二范式,那么将会引发插入异常、删除异常、数据冗余和更新异常。

第三范式(3NF)

定义

确保每列都和主键列直接相关,而不是间接相关。

说明

第三范式需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关。

案例

比如在设计一个订单数据表的时候,可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息(比如姓名、所属公司等)的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表:

13_数据库三大范式.png

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

问题

如果不满足第三范式,那么将会引发插入异常、删除异常、数据冗余和更新异常。

反范式化

一般说来,数据库只需满足第三范式(3NF)就行了。没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段,允许冗余,达到以空间换时间的目的。

比如:有一张存放商品的基本表,“金额” 这个字段的存在,表明该表的设计不满足第三范式,因为 “金额” 可以由 “单价” 乘以 “数量” 得到,说明 “金额” 是冗余字段。但是,增加 “金额” 这个冗余字段,可以提高查询统计的速度,这就是以空间换时间的作法。

在 Rose 2002 中,规定列有两种类型:数据列和计算列。“金额” 这样的列被称为 “计算列”,而 “单价” 和 “数量” 这样的列被称为 “数据列”。


赞助商链接:


嗨客网顶部