数据库范式解析(1NF 2NF 3NF BCNF)
数据库设计范式是关系型数据库的设计准则。其目的在于通过规划设计使得数据库结构合理,尽量减少数据冗余,消除存储异常,方便数据的插入、更新和删除操作。目前常用范式包括1NF(第一范式)、2NF(第二范式)、3NF(第三范式)和BCNF(鲍依斯-科得范式)。
1NF 第一范式
如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。
也可表述为:数据库表中的字段都是单一属性的,不可再分。
比如“地址”属性应该拆分为“城市”、“区县”、“具体地址”便于使用。
2NF 第二范式
若关系模式R∈1NF,并且每一个非主属性都完全函数依赖于R的码(多个主属性字段的组合),则R∈2NF
也可表述为:数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。
比如选课关系表(学号, 姓名, 年龄, 课程名称, 成绩, 学分),码为组合关键字(学号, 课程名称),因为存在如下决定关系:
这个数据库表不满足第二范式,因为存在如下决定关系:(课程名称) → (学分) 和 (学号) → (姓名, 年龄),即存在码中的部分字段决定非关键字的情况,所以不符合2NF。应修改为一以下三个表:
学生:Student(学号, 姓名, 年龄);
课程:Course(课程名称, 学分);
选课关系:SelectCourse(学号, 课程名称, 成绩)。
3NF 第三范式
关系模式R<U,F> 中若不存在这样的码X、属性组Y及非主属性Z(Z Y), 使得X→Y,Y→Z,成立,则称R<U,F> ∈ 3NF。
也可表述为:在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。因此,满足第三范式的数据库表应该不存在如下依赖关系:关键字段 → 非关键字段x → 非关键字段y
比如:学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)关键字段为“学号”,存在以下决定关系(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话),符合2NF;但存在(学号) → (所在学院) → (学院地点, 学院电话),不符合3NF。应改为:
学生:(学号, 姓名, 年龄, 所在学院);
学院:(学院, 地点, 电话)。
BCNF 鲍依斯-科得范式
设关系模式R<U,F>∈1NF,如果对于R的每个函数依赖X→Y,若Y不属于X,则X必含有候选码,那么R∈BCNF。
也可表述为:在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。
比如:仓库管理关系表为(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是表的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。数据表应修改为:
仓库管理:(仓库ID, 管理员ID);
仓库:(仓库ID, 存储物品ID, 数量)。
四种范氏之间的关系
每一个范氏都是进一步约束的关系,如下图:
参考:
初学者,大概理解了,谢谢.
[回复]
怎么感觉你抄的课本呢?当时学数据库就是这个。还有4NF和5NF……
[回复]
晴枫 1月 13th, 2012 上午12:03 回复:
@Delbert, 没学过,在别人文章基础做的整理
[回复]
很勤劳啊,范式大概有六种,最常用的是范式3,但是现在随着web2.0的兴起,这些都有些力不从心,现在流行反范式
[回复]
晴枫 1月 11th, 2012 下午6:57 回复:
@junguo, 平时数据库设计完全凭经验;只是最近面试碰到了,来学习一下
[回复]