数据库的设计范式是数据库设计所需要满足的规范,
设计范式是不是很难懂呢?非也,
实质上,设计范式用很形象、很简
范式说明
第一范式(1NF):数据库表中
例如,如下的数据库表是符合第一
字段1 | 字段2 | 字段3 | 字段4 |
而这样的数据库表是不符合第一范
字段1 | 字段2 | 字段3 | 字段4 | |
字段3.1 | 字段3.2 |
很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第
第二范式(2NF):数据库表中
假定选课关系表为SelectC
(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
这个数据库表不满足第二范式,因
(课程名称) → (学分)
(学号) → (姓名, 年龄)
即存在组合关键字中的字段决定非
由于不符合2NF,这个选课关系
(1) 数据冗余:
同一门课程由n个学生选修,"学
(2) 更新异常:
若调整了某门课程的学分,数据表
(3) 插入异常:
假设要开设一门新的课程,暂时还
(4) 删除异常:
假设一批学生已经完成课程的选修
把选课关系表SelectCou
学生:Student(学号, 姓名, 年龄);
课程:Course(课程名称,
选课关系:SelectCour
这样的数据库表是符合第二范式的
另外,所有单关键字的数据库表都
第三范式(3NF):在第二范式
关键字段 → 非关键字段x → 非关键字段y
假定学生关系表为Student
(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
这个数据库是符合2NF的,但是
(学号) → (所在学院) → (学院地点, 学院电话)
即存在非关键字段"学院地点"、
它也会存在数据冗余、更新异常、
把学生关系表分为如下两个表:
学生:(学号, 姓名, 年龄, 所在学院);
学院:(学院, 地点, 电话)。
这样的数据库表是符合第三范式的
鲍依斯-科得范式(BCNF):
假设仓库管理关系表为Store
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以,(仓库ID, 存储物品ID)和(管理员ID,
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情
(1) 删除异常:
当仓库被清空后,所有"存储物品
(2) 插入异常:
当仓库没有存储任何物品时,无法
(3) 更新异常:
如果仓库换了管理员,则表中所有
把仓库管理关系表分解为二个关系
仓库管理:Storehouse
仓库:Storehouse(仓
这样的数据库表是符合BCNF范
范式应用
我们来逐步搞定一个论坛的数据库
(1) 用户:用户名,email,主页
(2) 帖子:发帖标题,发帖内容,回复
第一次我们将数据库设计为仅仅存
用户名 | 主页 | 电话 | 联系地址 | 发帖标题 | 发帖内容 | 回复标题 | 回复内容 |
这个数据库表符合第一范式,但是
用户名 | 主页 | 电话 | 联系地址 | 发帖ID | 发帖标题 | 发帖内容 | 回复ID | 回复标题 | 回复内容 |
这样数据表中的关键字(用户名,
(用户名,发帖ID,回复ID)
但是,这样的设计不符合第二范式
(用户名) → (email,主页,电话,联系
(发帖ID) → (发帖标题,发帖内容)
(回复ID) → (回复标题,回复内容)
即非关键字段部分函数依赖于候选
我们将数据库表分解为(带下划线
(1) 用户信息:用户名,email,
(2) 帖子信息:发帖ID,标题,内容
(3) 回复信息:回复ID,标题,内容
(4) 发贴:用户名,发帖ID
(5) 回复:发帖ID,回复ID
这样的设计是满足第1、2、3范
不一定。
观察可知,第4项"发帖"中的"
(1) 用户信息:用户名,email,
(2) 帖子信息:用户名,发帖ID,标
(3) 回复信息:发帖ID,回复ID,
数据库表1显然满足所有范式的要
数据库表2中存在非关键字段"标
数据库表3中也存在非关键字段"
由此可以看出,并不一定要强行满
对于M:N的关系,不能将M一边
对于1:1的关系,我们可以将左
结论
满足范式要求的数据库设计是结构
在我们设计数据库的时候,一定要