数据库的范式

2022-09-11 11:07:48

上一篇15【存储过程和存储函数】


下一篇17【JDBC基本操作】

目录【MySQL零基础系列教程】



16【数据库的范式】

16.1 第一范式

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

案例:

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

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

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

16.2 第二范式

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

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

案例

借阅表:

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

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

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

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

学号姓名年龄手机号
zs-001张三21110
ls-002李四22120

书籍表:

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

借阅表:

借阅ID借阅书籍ID借阅人学号借阅数量
0011zs-0011
0022zs-0022

16.3 第三范式

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

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

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

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

部门表

部门id部门名称部门地点部门简码部门等级
001研发部石家庄dev1
002行政部郑州admin2
003销售部济南sale2

员工表:

ID姓名年龄部门ID
001张三21001
002李四22002
003王五25001

16.4 反范式化

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

反范式设计表:

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

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

部门表:

部门id部门名称部门地点部门简码部门等级
001研发部石家庄dev1
002运营部郑州admin2
003销售部济南sale2

16.5 过分范式化带来的弊端

  • 1)过分的满足第一范式设计:即保证每一列的原子性,会给表带来非常多的列;
ID姓名年龄地址
001张三20江西省南昌市洪城路128号8栋601
002李四23江西省南昌市青云谱区洪都大道118号9栋301

过分满足第一范式:

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

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

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

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

  • 作者:緑水長流*z
  • 原文链接:https://blog.csdn.net/Bb15070047748/article/details/126569866
    更新时间:2022-09-11 11:07:48