摘要:数据库的常用设计范式有四种:第一范式,第二范式,第三范式和第四范式。本文将依次介绍这四种范式。

第一范式

一范式强调了属性的原子性,即字段不允许再分隔,一个字段不允许出现多个值。

第二范式

在第一范式的前提下,每个非主属性都完全函数依赖于主键。

首先,什么是“非主属性”?[1]
主属性(primary attribute)就是候选键中的每一个属性,候选键可能是多个属性。不包含在候选键的属性叫非主属性。
候选键可以有多组,例如候选键为AB或者AC或者AD,属性ABCD都包含在候选键中,那么ABCD都是主属性。

其次,什么叫“完全函数依赖”和“部分函数依赖”?
假设有X–>Y, X’是X的真子集,若满足X’–>Y,那么Y 部分函数依赖于X。
假设有X–>Y, X’是X的真子集,若对任意X’,均有X’!–>Y,那么Y完全函数依赖于X。

换而言之,当主键只拥有一个属性时,必然满足第二范式。当主键拥有多个属性时,主键的任意真子集都不能决定非主属性,只有主键才能决定非主属性,此时满足第二范式。

第三范式

在第二范式的基础上,如果每个非主属性都不传递函数依赖于主键。

也就是说,不存在这样的情况:非主属性A依赖于非主属性B,非主属性B依赖于主属性C。

换而言之,非主键之间不应该有依赖关系。

BC范式

BCNF的定义是[2]

如果对于关系模式R中存在的任意一个非平凡函数依赖X->A,都满足X是R的一个超键,那么关系模式R就属于BCNF。

换句话说[3],只要属性或属性组A能够决定任何一个属性B,则A的子集中必须有候选键。BCNF范式排除了任何属性(不光是非主属性,2NF和3NF所限制的都是非主属性)对候选键的传递依赖与部分依赖。
这段话也可以细化为如下四个条件:

考虑这样一个数据库和对应的依赖关系:

WarehouseManage(H#, P#, A#, Num)
Key FD
(H#, P#) (H#, P#) → Num
(A#, P#) (A#, P#) → Num
(H#, P#) → A#
(A#, P#) → H#
H# → A#
A# → H#

由于A# → H#A#的子集中不包含任意候选键,因此这个设计不符合BC范式。

第四范式

第四范式,即,在BC范式的基础上,不包含多值依赖。

一个关系中至少存在三个属性(A、B、C)才能存在多值依赖。若对于每一个A值,有一组确定的B值和C值,并且这组B的值独立于这组C的值,则存在多值依赖。

比如说:有这样一个关系 <仓库管理员,仓库号,库存产品号> ,假设一个产品只能放到一个仓库中,但是一个仓库可以有若干管理员,那么对应于一个 <仓库管理员,库存产品号>有一个仓库号,而实际上,这个仓库号只与库存产品号有关,与管理员无关,就说这是多值依赖[4]