【Mysql数据库进阶02】第一范式~第四范式 Normal Form

0 引言

因为软考,我又重新拾起了数据库,那么到底如何去判断它属于第几范式呢
在这里插入图片描述

1 第一范式

设R是一个关系模式,R属于第一范式当且仅当R中每一个属性A的值域只包含原子项,即不可分割的数据项。
1NF不能排除数据冗余和更新异常等问题,因为其中可能存在部分函数依赖。

第一范式要求数据库表中的每个字段都是原子性的,即每个字段只有一个值。
例如,如果一个“姓名”字段包含“姓”和“名”,则需要将其分开成独立的“姓”和“名”字段,以符合第一范式。

2 第二范式

设R是一个关系模式,R属于第二范式当且仅当R是1NF,且每个非主属性都完全函数依赖于候选码
除主键外的每一列都完全依赖于主键,即使主键是复合主键,要依赖它的全部。
属于 2NF 的关系模式R也可能存在数据几余和更新异常等问题,因为其中可能存在传递函数依赖。但不属于 2NF 的关系模式 R会产生插入异常、删除异常和修改复杂等问题。

例子:
在这里插入图片描述
主键是(零件号、供应商)
①看每个属性都是否是原子属性 ✓
②看非主属性有没有完全依赖于主键 ×
零件号→零件名称
零件名称部分依赖于主键中的零件号,没有完全依赖复合主键,所以不是完全依赖

3 第三范式

设R是一个关系模式,R属于第三范式当且仅当R是2NF,且每个非主属性都非传递函数依赖于候选码
一个不属于 3NF的关系模式R会产生插入异常、删除异常和修改复杂等问题。

例子:
在这里插入图片描述
主键是(时间,学生)
①看每个属性都是否是原子属性 ✓
②看非主属性有没有完全依赖于主键 ✓
③看非主属性是否没有传递依赖于主键 ×
(时间,学生)→教室 (时间,教室)→课程 ⇢ \dashrightarrow (时间,学生)→课程
可以用伪传递率推出此为传递依赖
在这里插入图片描述

4 BC范式

设R是一个关系模式,F是它的依赖集,R属于BCNF,当且仅当其F中每个依赖的决定因素必定包含R的某个候选码。任何非主属性必须完全依赖于候选键,而非部分依赖。
由BCNF的定义可以得到结论,一个满足BCNF的关系模式有:

  • 所有非主属性对每一个码都是完全函数依赖。
  • 所有的主属性对每一个不包含它的码,也是完全函数依赖
  • 没有任何属性完全函数依赖于非码的任何一组属性。一个满足BCNF的关系模式R已消除了插入和删除异常

5 第四范式

第四范式是一种更高级别的规范化形式,通过进一步减少冗余数据和处理多值依赖关系来提高数据库表的结构。第四范式通常用于解决表中出现多个多值依赖的情况,从而使数据库设计更加规范和灵活。

也就是取BCNF关系的投影,消去其中不是函数依赖的非平多值依赖(非平凡且非函数依赖的多值依赖),产生一组4NF关系。
说实话,后面两个范式不是很好理解啊

总结

设R是一个关系模式,当且仅当R中每一个属性都是原子项,R属于第一范式
在第一范式的基础上,每个非主属性都完全函数依赖于候选码,R属于第二范式
在第二范式的基础上,每个非主属性都非传递函数依赖于候选码,R属于第三范式
在这里插入图片描述

  • 18
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

打赏作者

失舵之舟-

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

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

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

打赏作者

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

抵扣说明:

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

余额充值