关系型数据库三大范式介绍

本文介绍了关系型数据库的三大范式:第一范式强调数据原子性,第二范式要求非主键列完全依赖主键,第三范式确保列只依赖主键。虽然规范化能避免数据冗余和保持一致性,但过高的范式可能导致查询性能下降。设计数据库时,通常需要在规范化和性能之间找到平衡。

一、为什么使用范式?

要想设计—个好的关系,必须使关系满足一定的约束条件,此约束已经形成了规范,分成几个等级,一级比一级要求得严格。满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦,而且面目可憎,可能存储了大量不需要的冗余信息。
目前关系数据库有六种范式,一般来说,数据库只需满足第三范式(3NF)就行了。

二、什么是数据库三大范式?

1、第一范式

第一范式(Normal Formate, 1NF) 的目标是确保每列的原子性。如果每列(或者每个属性值)
都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式。例如:

在这里插入图片描述
这里订单表的产品名称这一列存储了多个数据,不符合原子性,需要拆分。
在这里插入图片描述
这样每张表都满足第一范式。

2、第二范式

第二范式(2NF) 在第一范式的基础上更进一层,其目标是确保表中的每列都和主键相关。如果 个关系满足第一 范式(1NF).
并且除了主键以外的其他列都全部依赖于该主键, 则满足第二范式 (2NF)。

在上面的订单细节表里面,如果要添加一个新产品,无法放入这张表,因为没有订单号。产品名和单价并不依赖于订单号(主键),所以需要再拆。
在这里插入图片描述
如此这两张表又符合了第二范式。

3、第三范式

第三范式(3NF)在第二范式的基础上更进一层,第三范式的目标是确保每列都和主键列直接相
关,而不是间接相关。如果一个关系满足第二范式(2NF), 并且除了主键以外的其他列都只能依赖
于主键列,列和列之间不存在相互依赖关系,则满足第三范式(3NF )。

在第三范式这里,上面的订单表又不符合要求,因为订单号依赖于用户id,用户id又依赖于用户名称,这样一来用户信息就无法单独管理了,应该继续拆分,拆成订单表和用户表。
在这里插入图片描述

三、数据库设计一定要遵循三大范式吗?

规范化的优点是明显的,它避免了大量的数据冗余,节省了存储空间,保持了数据的一致性。当一个库里的数据经常发生变化时,达到3NF的库可以使用户不必在超过两个以上的地方更改同一个值。那么是不是只要把所有的表都规范为3NF后,数据库的设计就是最优的呢?这可不一定。范式越高意味着表的划分更细,一个数据库中需要的表也就越多,用户不得不将原本相关联的数据分摊到多个表中。当用户同时需要这些数据时只能采用连接表的形式将数据重新合并在一起。同时把多个表联接在一起的花费是巨大的,尤其是当需要连接的两张或者多张表数据非常庞大的时候,表连接操作几乎是一个噩梦,这严重地降低了系统运行性能。

四、总结

第一范式:确保每列的原子性
第二范式:第一范式的基础上,确保表中的每列都和主键相关
第三范式:在第二范式的基础上,确保每列都和主键列直接相关

通常为了确保查询数据的性能,我们允许字段有一定的冗余!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值