图文结合看懂Mysql三大范式

文章介绍了数据库设计中的三大范式——第一范式(1NF)、第二范式(2NF)和第三范式(3NF),强调它们的目的在于减少数据冗余,提高存储和使用效率。1NF要求数据不可再分,2NF消除非主键部分依赖,3NF消除传递依赖。并通过实例说明了如何遵循这些范式来优化表结构,同时指出在实际应用中应结合项目需求灵活设计。
摘要由CSDN通过智能技术生成

目录

1.简介

2.第一范式 - 1NF

3.第二范式 - 2NF

4.第三范式 - 3NF


1.简介

三大范式是 Mysql 数据库设计表结构所遵循的规范和指导方法,目的是为了减少冗余,建立结构合理的数据库,从而提高数据存储和使用的性能。三大范式之间是具有依赖关系的,比如第二范式是在第一范式的基础上建设的、第三范式是在第二范式的基础上建设的。

 Mysql 数据库的范式不止三大范式,除了三大范式,还有巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF,又称“完美范式")。而本篇文章,我们只介绍范式中常用的三大范式。

每个范式,都是用来规定某种结构或数据要求——后一范式都是在前一范式已经满足的情况用来“加强要求”(这句话很重要)

2.第一范式 - 1NF

原子性(存储的数据应该具有“不可再分性”)

先看一个不符合第一范式的表结构,如下:

员工编码姓名年龄
001人事部小王23
002销售部小赵25
003研发部小李30

在这一个表中的,姓名字段下的数据是可以再进行拆分的,因此它不符合第一范式,那怎么样才符合第一范式呢?如下:

员工编码姓名年龄部门
001小王23人事部
002小赵25销售部
003小李30研发部

那是否遵循第一范式就一定是好的呢?如下:

员工编码姓名地址
001小赵陕西省西安市莲湖区
002小李陕西省宝鸡市陈仓区
003小王陕西省西安市长安区

通过观察上述表结构,我们发现,地址是可以再进一步拆分的,比如:

员工编码姓名
001小赵陕西省西安市莲湖区
002小李陕西省宝鸡市陈仓区
003小王陕西省西安市长安区

虽然拆分后,看上去更符合第一范式了,但是如果实际情况需要我们输出一个完整详细地址呢?那明显是表在没拆分的时候会更好用。

3.第二范式 - 2NF

唯一性 (消除非主键部分依赖联合主键中的部分字段)(一定要在第一范式已经满足的情况下)

在满足第一范式的情况下,遵循唯一性,消除部分依赖。即,表中任意一个主键或任意一组联合主键,可以确定除该主键外的所有的非主键值。

再通俗点讲就是,一个表只能描述一件事情

我们用一个经典案例进行解析。

学号姓名年龄课程名称成绩学分
001小张16语文905
001小张16数学805
002小李15数学755
002小李15英语904
003小王17语文805

我们先分析一下表结构:

1. 假设学号是表中的唯一主键,那由学号就可以确定姓名和年龄了,但是却不能确定课程名称和成绩。

2. 假设课程名称是表中的唯一主键,那由课程名称就可以确定学分了,但是却不能确定姓名、年龄和成绩。

3. 虽然通过学号和课程名称的联合主键,可以确定除联合主键外的所有的非主键值,但是基于上述两个假设,也不符合第二范式的要求。

那我们应该如何调整表结构,让它能复合第二范式的要求呢?

我们可以基于上述的三种主键的可能,拆分成 3 张表,保证一张表只描述一件事情

1. 学生表 - 学号做主键

学号姓名年龄
001小张16
002小李15
003小王17

2. 课程表 - 课程名称做主键

课程名称学分
语文5
数学5
英语4

3. 成绩表 - 学号和课程名称做联合主键

学号课程名称成绩
001语文90
001数学80
002数学75
002英语90
003语文80

这时候我们可能会想,为什么我们就要遵循第二范式呢?不遵循第二范式会造成什么样的后果呢

1. 造成整表的数据冗余。

如,学生表,可能我就只有2个学生,每个学生都有许多的信息,比如,年龄、性别、身高、住址......如果与课程信息放到同一张表中,可能每个学生有3门课程,那数据总条数就会变成6条了。但是通过拆分,学生表我们只需要存储 2 条学生信息,课程表只需要存储 3 条课程信息,成绩表就只需保留学号、课程名称和成绩字段。

2. 更新数据不方便。

假设,课程的学分发生了变更,那我们就需要把整表关于该课程的学分都要更新一次,但如果我们拆分出课程表,那我们就只需要把课程表中的课程信息更新就行。

3. 插入数据不方便或产生异常。

① 假设主键是学号或课程名称,我们新增了某个课程,需要把数据插入到表中,这时,可能只有部分人有选修这门课程,那我们插入数据的时候还要规定给哪些人插入对应的课程信息,同时可能由于成绩还没有,我们需要对成绩置空,后续有成绩后还得重新更新一遍。

② 假设主键是学号和课程名称的联合主键。同样也是新增了某课程,但是暂时没有人选修这门课,缺少了学号主键字段数据,会导致课程信息无法插入。

4.第三范式 - 3NF

独立性,消除传递依赖(非主键值不依赖于另一个非主键值)

在满足第二范式的情况下,消除传递依赖。即,在任一主键都可以确定所有非主键字段值的情况下,不能存在某非主键字段 A 可以获取 某非主键字段 B

仍然用一个经典例子来解析

学号姓名班级教师
001小王高一(8)班高老师

这个表中,学号是主键,它可以唯一确定姓名、班级、班主任,符合了第二范式,但是在非主键字段中,我们也可以通过班级推导出该班级的班主任,所以它是不符合第三范式的。

那怎么设计表结构,才是符合第三范式的呢?

1. 学生表

学号姓名班级
001小王高一(8)班

2. 班级表

班级老师
高一(8)班高老师

通过把班级与班主任的映射关系另外做成一张映射表,我们就成功地消除了表中的传递依赖了。

总结

不知道大家有没有发现,以上所介绍的范式的最终目的都是为了减少我们的工作量呢?所以说,尽管范式是一种很好的指导规范,但在实际应用中,我们也不需要太局限在范式中,更多的是应该从项目需求中出发,设计出合理的表结构。

以下是本篇三范式的简单总结:

  • 第一范式(1 NF):字段不可再拆分。
  • 第二范式(2 NF):表中任意一个主键或任意一组联合主键,可以确定除该主键外的所有的非主键值。
  • 第三范式(3 NF):在任一主键都可以确定所有非主键字段值的情况下,不能存在某非主键字段 A 可以获取 某非主键字段 B。
  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

北~笙

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值