数据库第一范式 | 原子性:表中每一列都不可以再分割成更小的列 |
---|---|
数据库第二范式 | 不产生局部依赖 每张表只描述一件事情 |
数据库第三范式 | 表中每列都直接依赖于主键,而不是通过其它列间接依赖于主键 |
1 数据库第一范式
目标
- 什么是数据库范式
- 学习第一范式的应用
什么是范式
一种规则,指导程序员创建表的规则
程序员在设计表的时候,只需要符合三大范式就可以了
有哪些范式
满足最低要求的范式是第一范式(1NF),在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了
满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常
范式特点
原子性:表中每一列都不可以再分割成更小的列
如果一列中包含的数据还可以再拆分,不符合第一范式
案例
班级表
学号 | 姓名 | 班级 |
---|---|---|
1000 | 张三 | 一年级3班 |
1001 | 李四 | 一年级2班 |
2001 | 王五 | 二年级1班 |
解决方案
将班级列拆分成为年纪列和班号列两个字段
学号 | 姓名 | 年级 | 班号 |
---|---|---|---|
1000 | 张三 | 一年级 | 3 |
小结
什么是第一范式?
原子性,每一列不可以继续拆分
2 数据库第二范式
目标
什么是第二范式
概念
在满足第一范式的基础上,有更多的要求,才是第二范式。特点是表中每一列都必须完全依赖于主键,而不是局部依赖。
如果主键是复合主键,即有多列做为主键时,表中部分列只依赖主键的一部分,则不符合第二范式。
范式特点
- 不产生局部依赖
- 每张表只描述一件事情
案例
学生课程表,主键是联合主键:学生id + 课程id
学生id | 学生姓名 | 学生年龄 | 课程id | 课程名字 | 课程周期 | 考试成绩 |
---|---|---|---|---|---|---|
stu001 | 张三 | 22 | course01 | 语文 | 16周 | 80 |
stu001 | 张三 | 21 | course02 | 数学 | 14周 | 90 |
stu002 | 李四 | 19 | course01 | 语文 | 16周 | 78 |
stu003 | 王五 | 20 | course03 | 英语 | 18周 | 99 |
解决方案
学生表,主键是学生id
学生id | 学生姓名 | 学生年龄 |
---|---|---|
stu001 | 张三 | 22 |
课程表,主键是课程id
课程id | 课程名字 | 课程周期 |
---|---|---|
course01 | 语文 | 16周 |
考试成绩表,主键是学生id和课程id
学生id | 课程id | 考试成绩 |
---|---|---|
stu001 | course01 | 80 |
stu001 | course02 | 90 |
小结
第二范式特点?
- 不产生局部依赖
- 每张表只描述一件事情
3 数据库第三范式
目标
什么是第三范式
范式特点
在满足第二范式的基础上,有更多的要求。 表中每列都直接依赖于主键,而不是通过其它列间接依赖于主键
依赖关系
所谓传递依赖,指的是如果存在"A → B → C"的决定关系,则C传递依赖于A
满足第三范式的数据库表应该不存在如下依赖关系:主键列 → 非主键列X → 非主键列Y
案例
学生信息表 ,主键是学号
学号 | 姓名 | 年龄 | 所在学院 | 学院地点 |
---|---|---|---|---|
1000 | 张三 | 20 | 传智专修学院 | 江苏 |
2000 | 李四 | 19 | 广州美术学院 | 广州 |
1001 | 王五 | 21 | 传智专修学院 | 江苏 |
2001 | 赵六 | 20 | 广州美术学院 | 广州 |
2002 | 小七 | 18 | 广州美术学院 | 广州 |
存在的传递关系:学号 --> 所在学院 --> 学院地点
当存在大数据量时,会造成数据冗余
解决方案
学生表
学号 | 姓名 | 年龄 | 所在学院ID |
---|---|---|---|
1000 | 张三 | 20 | 001 |
学院表
学院ID | 学院名字 | 学院地点 |
---|---|---|
001 | 传智专修学院 | 江苏 |
注:表使用的范式越高级,被拆分的表就越多
如果性能与范式有冲突,优先考虑性能
小结
第三范式特点?
不产生传递依赖