【MySQL入门实战1】-数据库三大范式

📢📢📢📣📣📣
哈喽!大家好,我是【IT邦德】,江湖人称jeames007,10余年DBA工作经验
一位上进心十足的【大数据领域博主】!😜😜😜
中国DBA联盟(ACDU)成员,目前从事DBA及程序编程
擅长主流数据Oracle、MySQL、PG 运维开发,备份恢复,安装迁移,性能优化、故障应急处理等。
✨ 如果有对【数据库】感兴趣的【小可爱】,欢迎关注【IT邦德】💞💞💞
❤️❤️❤️感谢各位大可爱小可爱!❤️❤️❤️

前言

MySQL入门实战将持续推出MySQL入门的技能和相关运维经验给大家

📣 1.概述

为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则,在关系型数据库中这种规则就被称为范式。范式是符合某一种设计要求的总结。因此要设计一个结构合理的关系型数据库,就必须要满足下面这三大范式。

📣 2.第一范式

第一范式也称不可再分

数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。第一范式(1NF)主要是确保数据表中每个字段的值必须具有原子性,也就是说数据表中每个字段的值为不可再次拆分的最小数据单元。

表1-1
在这里插入图片描述

📢 如表1-1所示,这张表实际上就不满足1NF,因为班级这列是可以继续被拆分的。

表1-2
在这里插入图片描述
📢 如表1-2所示,这个表中不能有可以被继续拆分的列,即表中的每一个属性列都具有原子性。

📣 3.第二范式

第二范式即消除部分依赖。

第二范式(2NF)是指在第一范式的基础上,确保数据表中除了主键之外的每个字段都必须依赖主键,非主键列完全依赖于主键,而不能是依赖于主键的一部分,如表1-3.

表1-3
在这里插入图片描述

注意:不是所有属性字段都完全依赖联合主键的,它们或许只依赖主键中的一部分,这种部分依赖的关系是不满足2NF的,表1-3中的例子中,由于商品的名称和价格字段不依赖于商品类别的主键id,所以不符合第二范式,因此我们需要进行拆表。可以将其修改成如下表1-4 category和表1-5 goods所示的表设计,商品信息goods表通过商品类别id字段与数据表category中商品类别category_id字段进行关联。

表1-4
在这里插入图片描述

符合第二范式的category数据表的设计,如表1-4

表1-5
在这里插入图片描述

符合第二范式的goods数据表的设计,如表1-5

📣 4.第三范式

第三范式即消除部分依赖。

在第二范式的基础上,非主键列只依赖于主键,不依赖于其他非主键。第三范式(3NF)是需要确保数据表中的每一列数据都和主键直接相关,而不能间接相关。

表1-6 不满足3NF的表
在这里插入图片描述

注意:表1-6中主键是"学号",直接依赖于"学号"的有"姓名"和"课程号"。“课程名称"直接依赖于"课程号”,间接依赖于"学号"。因此,我们需要为课程号和课程名称单独创建一个表出来,下面是结果

表1-7,符合第三范式的学生表的设计
在这里插入图片描述
表1-8,符合第三范式的课程表的设计
在这里插入图片描述

📣 小结

三大范式只是一般设计数据库的基本理念,可以建立冗余较小、结构合理的数据库。如果有特殊情况,当然要特殊对待,数据库设计最重要的是看业务需求和性能,需求>性能>表结构,所以不能一味的去追求范式建立数据库关联。要尽量遵守三范式,如果不遵守,必须有足够的理由,事实上我们经常会为了性能而妥协数据库的设计。

✨ 每日一练

以下关于三个范式说法错误的是:()
A.第一范式中,数据库表中的字段都是单一属性的,不可再分。
B.第二范式中,在第一范式的基础上,非主键列完全依赖于主键,而不能是依赖于主键的一部分。
C.第三范式中,在第二范式的基础上,非主键列只依赖于主键,不依赖于其他非主键。
D.在设计数据库结构的时候,必须遵守三范式。

❤️❤️❤️ 请在评论区留下你的答案,我会做出详细的解答。

在这里插入图片描述

评论 29
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

IT邦德

客户部署资料,步骤超详细

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

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

打赏作者

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

抵扣说明:

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

余额充值