文章目录

16【数据库的范式】

16【数据库的范式】

16.1 第一范式

概念：第一范式强调每一列的原子性，每列的数据必须保证其原子性，即每列的数据必须细化到不可再拆分

案例：

学号	姓名	班级
001	张三	Java01班
002	李四	Java02班
003	王五	UI01班
004	赵六	产品02班

在上述表中，班级字段存在数据冗余，如果我们想统计Java学科的人数或者01班级的人数岂不是很尴尬？根据第一大范式条件必须保证每一列数据的原子性，我们可细化分如下：

学号	姓名	学科	班级
001	张三	Java	01班
002	李四	Java	02班
003	王五	UI	01班
004	赵六	产品	02班

16.2 第二范式

概念：在满足第一范式的条件下，每一列的数据都完全依赖于主键，不产生局部依赖，每张表都只描述一件事物，每一列都和主键相关联

也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。

案例

借阅表：

借阅ID	书籍ID	书籍名称	出版社	数量	学号	学生姓名	手机号
001	1	高性能MySQL	清华大学出版社	1	zs-001	张三	110
001	2	MySQL技术内幕	北京大学出版社	2	ls-002	李四	120

缺点：大量重复数据，每存一条数据都会有重复的出版社、年龄、手机号等重复数据

根据第二大范式，表中的数据不能产生局部依赖，上述表中很明显出版社、书籍名称依赖于书籍ID，而学生姓名、手机号等依赖于学号

根据第二范式细化：拆分成学生表、书籍表、借阅表
学生信息表：

学号	姓名	年龄	手机号
zs-001	张三	21	110
ls-002	李四	22	120

书籍表：

书籍ID	书籍名称	出版社
1	高性能MySQL	清华大学出版社
2	MySQL技术内幕	北京大学出版社

借阅表：

借阅ID	借阅书籍ID	借阅人学号	借阅数量
001	1	zs-001	1
002	2	zs-002	2

16.3 第三范式

概念：在满足第二范式的条件下，表中的每一列不存在传递依赖，每列都直接依赖于主键
案例：

ID	姓名	年龄	所属部门	部门地点
001	张三	21	研发部	石家庄
002	李四	22	销售部	郑州
003	王五	25	研发部	济南

根据第三范式，每一列应该直接依赖于主键

我们应该拆分成一张用户表和一张部门表，通过建立外键来建立两表之间的关系

部门表

部门id	部门名称	部门地点	部门简码	部门等级
001	研发部	石家庄	dev	1
002	行政部	郑州	admin	2
003	销售部	济南	sale	2

员工表：

ID	姓名	年龄	部门ID
001	张三	21	001
002	李四	22	002
003	王五	25	001

16.4 反范式化

一般我们设计表都会按照数据库的三大范式，但是在某些情况下我们查询的数据在多张表中，例如我们需要查询员工的信息并且希望带出员工的部门名称，这个时候我们必须使用join关联表查询，如果这些数据是查询非常频繁的，那么无疑会降低数据库的读性能

反范式设计表：

编号	姓名	年龄	部门id	部门名称
001	张三	21	001	研发部
002	李四	22	002	运营部

此时数据都在一张表，查询也不用join关联查询，以此提高读取性能

部门表：

部门id	部门名称	部门地点	部门简码	部门等级
001	研发部	石家庄	dev	1
002	运营部	郑州	admin	2
003	销售部	济南	sale	2

16.5 过分范式化带来的弊端

1）过分的满足第一范式设计：即保证每一列的原子性，会给表带来非常多的列；

ID	姓名	年龄	地址
001	张三	20	江西省南昌市洪城路128号8栋601
002	李四	23	江西省南昌市青云谱区洪都大道118号9栋301

过分满足第一范式：

ID	姓名	年龄	省份	城市	县区	道路	牌号
001	张三	20	江西省	南昌市	西湖区	洪城路	128号
002	李四	23	江西省	南昌市	青云谱区	洪都大道	118号

过分的满足第一范式会带来非常多的列，导致查询性能下降

2）过分的满足第三范式：表中的每一列不存在传递依赖，每列都直接依赖于主键

反范式化明显就不符合第三范式

文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/131695.html

16【数据库的范式】

文章目录

16【数据库的范式】

16.1 第一范式

16.2 第二范式

16.3 第三范式

16.4 反范式化

16.5 过分范式化带来的弊端

相关推荐

发表回复

分享到: