关系型数据库的范式理解-小记

关系型数据库的范式理解-小记

范式的理解,可以说是在数据库表设计时遵循的规范,这些规范有不同的级别。不同级别就对应不同的范式。

1.第一范式(1NF)

数据库表的每个属性都是原子项,内容不可分割。也就是说每个列的内容保持原子性,不可再划分,即属性不可分割。

不符合1NF的表设计:

id名字联系方式
1小乔123@gmail.com,18878051234
2大乔456@gmail.com,18878051235
3安琪拉789@gmail.com,18878051236

上面的表格中联系方式字段“123@gmail.com,18878051234”就没有保持原子性,还可以分割为两种,所以不符合第一范式。修改后,符合1NF的样子应该如下:

符合1NF的表设计:

id名字邮箱电话
1小乔123@gmail.com18878051234
2大乔456@gmail.com18878051235
3安琪拉789@gmail.com18878051236

这里每列的内容都是不可分割的,内容都保持了原子性,遵守了关系型数据库的第一范式。

2.第二范式(2NF)

第二范式(2NF)必须先满足第一范式(1NF)。第二范式要求记录不重复,即要有主键(或组合主键),要求其他字段都依赖于整个主键,而不是仅仅依赖主键的一部分。

不符合2NF的表设计:比赛成绩表

id名字比赛类型成绩-助攻数
1小乔五人匹配5
2大乔人机10
3安琪拉1VS17

上面的表可以看到,成绩是由id和比赛类型决定的,玩一局游戏的助攻数,肯定是要明确是谁在哪一场比赛的成绩,“id-比赛类型”组成了这个表的主键。但是人物名字只需要id就可以确定了,并不需要整个组合主键“id-比赛类型”来决定,所以这个表不符合2NF。

符合2NF的表设计:

(1)比赛成绩表

id比赛类型成绩-助攻数
1五人匹配5
2人机10
31VS17

(2)人物表

id名字
1小乔
2大乔
3安琪拉

3.第三范式(3NF)

满足第三范式(3NF)必须先满足第二范式(2NF)。

第三范式就是非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在非主键列A依赖于非主键列B,非主键列B依赖于主键的情况。
通俗一点,就是在其他表中的信息不能重复出现,如果出现则要求这个信息是其他表的主键(在本表就是“外键”)。

不符合3NF的表设计:

id名字老公老公姑妈老公姑妈的外公
1小乔周瑜周姑妈周姑妈外公
2大乔孙策孙姑妈孙姑妈外公
3孙尚香刘备刘姑妈刘姑妈外公

显然上面的表中有一个关系链,3NF里面不允许存在传递的关系。比如第一行,名字小乔依赖于逐渐id,老公周瑜只依赖于id,这都是没问题的,但是后面周姑妈就仅依赖于非主键列周瑜,不依赖主键id,这是不符合3NF的。

符合3NF的表设计:

(1)人物关系表1

id名字老公
1小乔周瑜
2大乔孙策
3孙尚香刘备

(2)人物关系表2

id老公名字老公姑妈
1周瑜周姑妈
2孙策孙姑妈
3刘备刘姑妈

(3)人物关系表3

id姑妈名字姑妈的外公
1周姑妈周姑妈外公
2孙姑妈孙姑妈外公
3刘姑妈刘姑妈外公

划分之后每个表的每行的内容都没有传递关系,而且仅依赖于主键,不依赖非主键。


注意:第二范式(2NF)和第三范式(3NF)的概念很容易混淆,区分关键点

  • 2NF:非主键列完全依赖于主键,不能依赖于主键的一部分。

  • 3NF:非主键列是直接依赖于主键,还是直接依赖于非主键列。


转载于:https://www.cnblogs.com/fefjay/p/7542547.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值