MySQL数据库与数据库三范式

在这里插入图片描述

文章中所有操作均是在 MySQL 5.7 版本下进行的

数据库范式

第一范式

第一范式,就是数据库中的每一列(字段)都是不可分割的基本数据项,每一列(字段)中不能有多个值,每一列(字段)必须是不可拆分的最小单元。

这个很好理解,比如我有一个表(如下图)其中有个字段是用来存储地址的,其中存储的数据类似:“山东省济南市历下区解放路街道解放路2020号20楼20室”,其实从数据上看并没有什么不妥,其实这种地址存储形式在一般的项目中都会被拆分的很细,将所谓的地址拆分为:地址1(省份),地址2(市),地址3(区县),地址4(街道乡镇)… 等等吧,分开存储。生活中你会经常碰到这种情况,比如某宝或者某东或者某外卖平台里面填入地址的时候就将地址分的很细,这样直至分到没有再细分为止,确保每个列(字段)是最小单元不能再拆分了。
在这里插入图片描述

第二范式

第二范式是在第一范式的基础上建立起来的,即满足第二范式必须先满足第一范式。第二范式要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。

其实说白了就是需要一个主键列(字段),但是还会存在多列主键(复合主键或者叫联合主键),理论上复合主键是可以符合第二范式的,但是有时候复合主键经常会不满足第二范式。

比如有一个“学生成绩表”(如下图),其中 stu_no 和 course_no 是复合主键,通过这两个列的复合主键确定最后那个 score,这个表在存储数据的时候是没有任何问题的。但是仔细分析一下,stu_name,stu_age,stu_sex 是可以通过 stu_no 就能够唯一确定,course_name,course_credit 是可以通过 course_no 就能够唯一确定,因此这样就存在了部分依赖,就不符合第二范式。所以为了满足第二范式,就可以这张表拆分成多张表。
在这里插入图片描述

第三范式

第三范式是先满足第二范式,第三范式要求一个数据库表中不包含已在其它表中已包含的非主关键字信息,不能有不相干的数据冗余。

看见上面的解释新手会有些不好理解,它其中的意思说白了就是和外键有几分联系。其实举个例子最简单不过了(如下图),这里有一个“员工表”,其中的 dept_no,dept_name,dept_info 完全可以视为一个独立的实例,可以拆分成两个表“员工表”和“部门表”。
在这里插入图片描述

其它范式

除了重要的三个范式之后,还有巴斯-科德范式、第四范式和第五范式,这里就不去具体分析了,有兴趣的朋友可以去搜一搜。

结语

作者参与了不少项目和产品的开发,这些项目和产品的数据库表设计,如果非要以这个三范式去衡量的话,好像没有一个完全符合三范式的要求,只能说是勉强达标吧。往往并不是非要符合三范式才是最好的,在设计数据库表的时候往往会把性能与合理摆在第一位,甚至有时候会允许一部分的数据冗余来减少数据库连接,以提升性能。
这篇文章仅是理论性研究和探讨,关于数据库范式文章网络上很多,大同小异,所以本文的见解只代表作者本人吧。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

WorkLee

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

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

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

打赏作者

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

抵扣说明:

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

余额充值