关于数据库范式的理解

范式介绍

关系数据库中的关系满足一定的要求,满足不同程度要求的为不同范式。常见范式有第一范式(1NF),第二范式(2NF),第三范式(3NF),BC范式(BCNF)等,满足的范式越高,对数据库关系的要求就越高。同时范式也有传递性,满足第三范式必定会满足第一,第二范式。总体来说,范式是为了消除数据库中属性间依赖关系而存在的关系要求。

基础概念介绍

正式介绍范式之前需要对数据库依赖关系进行简单介绍。

完全函数依赖:如果X→Y,并且对于X的任何一个真子集X1都没有X1→Y,则称Y对X完全函数依赖。

部分函数依赖:如果X→Y,并且对于X的任何一个真子集X1X1→Y,则称Y对X部分函数依赖。(与完全函数依赖相反)

传递依赖:如果X→Y,同时不存在Y→X,且Y→Z,则称Z对X传递函数依赖。(如果X→Y,Y→X,此时是Z直接依赖于X)

接下来用例子再详细介绍依赖关系

(学号,课程)→成绩,由一个学号和课程可以唯一确定这个学生这节课的成绩,此时非主属性成绩完全依赖于码(学号,课程),称完全函数依赖。

(学号,课程)→姓名,由学号和课程可以确定一个学生的姓名,但本身由学号就可以确定学生的姓名,学号为(学号,课程)的真子集,此时非主属性姓名部分依赖于码(学号,课程),称部分函数依赖。

(学号,课程)→老师,老师→职称,由学号和课程可以确定上这节课的老师,老师又可以决定老师的职称,但(学号,课程)不能确定老师的职称,所以存在传递依赖。职称传递函数依赖于码(学号,课程)。

第一范式

第一范式(1NF)是数据库的基本范式要求,确保了数据的原子性。是每一个关系必须要遵守的要求。第一范式的具体要求简单来说就是表中不能有表,每个属性都是不可再分的最小单位。
在这里插入图片描述
以上表中,电话这一属性被拆分为两部分,不满足第一范式。

第二范式

第二范式(2NF)是在第一范式的基础上消除了部分函数依赖。确保码与非主属性间都为完全函数依赖。
在这里插入图片描述
如上表中,码为(学号,课程),此时姓名可由学号单独决定,形成姓名对码的部分函数依赖。为解决这一问题,可以将此表进行分解,使其满足2NF。
在这里插入图片描述
在这里插入图片描述

此时保证了非主属性对码的完全函数依赖。满足2NF。

第三范式

3NF在2NF基础上消除传递依赖。
在这里插入图片描述
上表中,职称和码(学号,课程)存在传递依赖,不满足3NF。为使关系满足3NF
可以将表拆分。
在这里插入图片描述
如上图,将表拆分后,连个两个表同时满足第三范式。

BF范式

BF范式可以看为第三范式的补充,消除主属性间的相互依赖。

在这里插入图片描述
以上表中存在(学生,教师)→课程(学生所选定的课),(学生,课程)→教师(教该学生的老师)的关系,由于每一位老师只教一科,一科可由多个老师教,所以存在教师→课程的关系。主属性间存在依赖关系,不满足BCNF。将上表拆为两个表,表一(学生,教师),表二(教师,课程)。
若一个关系达到了第三范式,并且它只有一个码,或者它的每个码都是单属性,则该关系自然达到BC范式。满足BC范式必定满足第三范式,但满足第三范式不一定满足BCNF。

以上是个人对范式的理解,有错误的地方请指出。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值