数据库原理学习心得-范式理解

之前对于数据库原理中的范式很是一知半解,原因我总结为两点,第一是所有教材对于范式的描述趋向于概念性,很生硬晦涩不容易理解。第二是对于概念中的一些词汇不能理解也很难理解整个概念。为了理解这些范式的定义,我查阅很多的百度资料,也阅读了一些大佬的文章帮助了解,最后我自己做一个总结。

第一范式

第一范式的概念是:如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。简单的说,就是每一个列(属性),不能再分割成多个列(属性)。第一范式在所有范式概念中是最容易理解的了,它主要是对于各个属性的约束。表明属性是一个不可分割的最小单元。

,像这样一张表,属性联系方式里面还有电话,qq这两个属性,可以理解为是表中套表。这个在关系模式里面是不允许的,也可以说不满足第一范式就已经不属于关系型数据库可以表示的范围了。

第二范式

第二范式的概念是:若关系模式R∈1NF即R符合第一范式),并且每一个非主属性都完全依赖于R的主码,则R∈2NF(即R符合第二范式)。第二范式概念相对也是很简单的,如果不清楚这个概念的意思应该就是不理解完全依赖地定义。

完全依赖:在一个关系中,若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。

要理解一个定义其实可以从不满足某定义的其他定义入手,比如部分依赖是完全依赖地反例子,理解了部分依赖,自然就可以理解完全依赖了。

部分依赖:在关系模式R(U)中,如果X→Y,并且存在X的一个真子集X0,使得X0→Y,则称Y对X部分函数依赖。

字面意思有点晦涩我们看一个图就知道了。

这个图就很好的说明了部分依赖,A={K1,k2,k3}若A->k4,且K2 k3->k4,这就提现了A中k1在函数决定K4时不是必要属性,这就说明k4部分依赖A。反之没有k2 k3 ->k4这一条件,则可以称为k4完全依赖A。

回过来我们解释第二范式的概念,可以看出第二范式是对非主属性的约束,假设有R={A,B,C,D}

F={AC->B,C->D}如果集合R的属性函数依赖关系是F,则R不满足第二范式。首先我们不难看出R关系的候选码为:AC,在AC->D上有C->D存在部分依赖关系,所以R不满足第二范式。

第三范式

第三范式的定义为:集合R在符合第二范式的前提下,每个非主属性都不传递依赖于R的候选码,则称R属于第三范式。

第三范式也是对于非主属性的约束,在第二范式限制非主属性部分依赖后又加了一条不能存在传递依赖。

假设有R={A,B,C,D}F={A->B,A->C,C->D}可以看到A为R的候选码,在A->D中有A->C,C->D,而且D不属于主属性,这就存在了非主属性D传递依赖于R的候选码A。所以R不属于第三范式。


BC范式

BC范式的定义是如果R属于1NF(第一范式),且对于所有的函数依赖X->Y,决定因素X都包含了R的一个候选码,责成R属于BC范式。

BC范式算是第三范式的一个增强版,排出了一切非主属性的依赖关系。

关于BC范式与第三范式的区别

从上面的概念我们很难看书BC范式与第三范式的区别但是我在其他资料中对于第三范式的定义我们就可以很清楚的了解他们之间的区别以下是第三范式的另外一种角度的概念阐述:

关系模式R满足第三范式,则对所有R中存在的函数依赖关系中A->B下列条件至少一个成立:

(1)A->B是平凡的函数依赖

(2)A是R的超码

(3)B-A中的属性r都包含于R的一个候选码中(即r属于B-A是主属性,若A,B的并集是空集,则r=A是主属性)

我们再来看看这个角度BC范式的概念描述

(1)A->B是平凡的函数依赖

(2)A是R的超码

这样一来我们就可以很直观的发现BC范式与第三范式的区别,我们举个例子。

R={A,B,C,D}F={AB->C,AB->D,D->A}不难发现AB为R的候选键,函数依赖关系中没有非主属性的部分依赖和传递依赖,所以R是属于第三范式的。但是不属于BC范式,由于D->A的决定因素D不包含在R的候选码中。

以上是我个人对于数据库范式中的一些心得理解,用于自己参考学习记录所用,有错误的希望大家帮忙指出。


  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值