当前位置:   article > 正文

【数据库】第一范式、第二范式、第三范式、BCNF详解

第二范式

 

目录

1、范式

2、第一范式(1NF)

3、第二范式(2NF)

4、第三范式(3NF)

5、BCNF

6、小结


1、范式

是符合某一种级别的关系模式的集合。是关系数据库规范化过程中为不同程度的规范化要求设立的不同的标准或准则。不同的范式满足的要求不同。

基本思想:消除关系模式中的数据冗余,消除数据依赖中的不合适的部分, 解决数据插入、删除与修改时发生的异常现象。

已定义的范式:

                     1NF、2NF、3NF、BCNF:基于函数依赖的范式

                             4NF:基于多值依赖的范式

                             5NF:基于连接依赖的范式

2、第一范式(1NF)

定义:如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF

在任何一个关系数据库系统中,第一范式是对关系模式的一个最起码的要求。(最基本的要求!!)

不满足第一范式的数据库模式不能称为关系数据库。

表1
姓名部门             薪水
基本工资提成

在表1中,我们可以发现薪水被分为基本工资和提成,所以这里的数据是不符合第一范式的要求。

例如,关系模式:学生(学号、系部、学生住处、课程号、成绩),码为(学号、课程号)---后面举例时都会用到这个关系模式

但是满足第一范式的关系模式并不一定是一个好的关系模式。

存在的问题:

· 插入异常:假如要插入一个已知学号、系别、学生住处,但还未选课的学生,也就是这个学生没有课程号,这样的元组不能插入到学生关系中。因为插入时必须给定码值,但是此时码值的一部分为空,因而学生的信息无法插入。

· 删除异常:假如某个学生只选修了一门课,如学号为2104011的学生只选修了3号课程。现在他连3号课程也不想选了,那么课程号为3的这个数据项就要删除。但是课程号是主属性,删除了课程号3,整个元组都不能存在了,也必须跟着删除,从而删除了210411学生的其他信息,产生了删除异常,也就是把不该删除的信息也删除了

· 数据冗余度大:如果一个学生选修了10门课程,那么他的系部和学生住处值就要重复存储10次。

· 修改复杂:如果一个学生转系了,本只用修改此学生的系部、学生住处。如果这个学生选修了K门课程,当数据更新时需无遗漏地修改K个元组中全部的系部、学生住处信息,这就造成了修改的复杂化。

3、第二范式(2NF)

定义:若关系模式R∈1NF,并且每一个非主属性完全函数依赖于R的,则R∈2NF。

   在定义中我们需要注意的是有前提条件,R必须先满足第一范式,不能直接跳过,要一层一层递进!

   还要注意三组词-非主属性(第一步就是要知道这个关系模式的主属性、非主属性)、完全函数依赖(在前面的学习中有讲到,忘记了的话就翻翻书)、(这是在一个关系中必须要首先明确的!)

在学生关系中,(学号、课程号),学号和课程号是主属性,系部、学生住处、成绩就是非主属性;

对于(学号,课程号)→成绩,非主属性 成绩 完全依赖于码(学号,课程号),因为一个课程有多名学生选,每名学生又可以选多门课程,某学生的相应课程成绩就必须由学号和课程号一起决定,缺一不可;

对于(学号,课程号)→系部,非主属性 系部 部分依赖于码(学号,课程号),已知学生学号也是可以知道它所在的系部的;

对于(学号,课程号)→学生住处,非主属性 学生住处 部分依赖于码(学号,课程号),已知学生学号也是可以知道它所在的学生住处;

所以,关系模式学生(学号、系部、学生住处、课程号、成绩)存在非主属性对于码的部分函数依赖,最高只符合1NF的要求,它不符合2NF的要求。

为了消除这些部分函数依赖,可以采用投影分解法,把学生分解为两个关系模式:

选课(学号,课程号,成绩)

基本信息(学号、系部、学生住处)

让我们来判断一下现在的选课表和住宿表是否符合第二范式的要求!

选课表:码是(学号,课程号),主属性是学号和课程号,非主属性是成绩,不能由学号确定成绩,也不能由课程号确定成绩,不存在非主属性对于码的部分函数依赖,符合2NF的要求。

基本信息表:码是学号,主属性是学号,非主属性是系部、学生住处,码只有一个属性,所以不存在非主属性对于码的部分函数依赖,符合2NF的要求。

在分解后的关系模式中,非主属性都完全依赖与码了。从而使第一范式中提到的四个问题在一定程度上得到了解决,让我们一起看看有了哪些变化!

· 插入异常:假如要插入一个已知学号、系别、学生住处,但还未选课的学生,也就是这个学生没有课程号,这样的元组不能插入到学生关系中。因为插入时必须给定码值,但是此时码值的一部分为空,因而学生的信息无法插入。

可以在基本信息关系中插入尚未选课的学生。

· 删除异常:假如某个学生只选修了一门课,如学号为2104011的学生只选修了3号课程。现在他连3号课程也不想选了,那么课程号为3的这个数据项就要删除。但是课程号是主属性,删除了课程号3,整个元组都不能存在了,也必须跟着删除,从而删除了210411学生的其他信息,产生了删除异常,也就是把不该删除的信息也删除了

删除学生选课信息涉及到的是选课表,如果一个学生所有的选课记录全部删除了,只是选课表中没有关于这个学生的记录了,不会牵涉到基本信息关系中关于该学生的记录。

· 数据冗余度大:如果一个学生选修了10门课程,那么他的系部和学生住处值就要重复存储10次。

由于选课情况和基本情况是分开存储到两个关系中的,因此无论学生选多少门课程,它的系部和学生住处都只存储一次,大大降低了数据冗余。

· 修改复杂:如果一个学生转系了,本只用修改此学生的系部、学生住处。如果这个学生选修了K门课程,当数据更新时需无遗漏地修改K个元组中全部的系部、学生住处信息,这就造成了修改的复杂化。

某个学生转系,只需修改基本信息表中的系部值和学生住处值即可。

但是将一个1NF关系分解为多个2NF的关系,并不能完全消除关系模式中各种异常情况和数据冗余。也就是说,属于2NF的关系模式并不一定是一个好的关系模式。

仍存在问题:

· 插入异常:如果刚刚成立某个系,目前暂时没有在校学生,就无法把这个系的信息存入数据库。

· 删除异常:如果某个系的学生全部毕业了,在删除该系学生信息的同时,把这个系的信息也丢掉了。

· 数据冗余度大:每个系的学生都住在同一个地方,关于系的住处信息重复出现的次数与该系学生人数相同。

· 修改复杂:如果学校调整学生住处,要把计算机系的学生全部迁到另一个地方住宿,由于每个系的住处信息是重复存储的,修改时必须同时更新该系所有学生的学生住处属性值。

4、第三范式(3NF)

若关系模式R∈2NF,并且R中所有非主属性对任意候选码都不存在传递函数依赖, 则 R∈3NF。

例如,前面提到的关系模式:基本信息(学号、系部、学生住处)有下列函数依赖:

学号->系部

系部->学生住处

学号->学生住处

我们可以看到基本信息表中存在非主属性对码的传递函数依赖。所以,该基本信息表最高只符合2NF的要求,它不符合3NF的要求。

为了消除该传递函数依赖,把基本信息表分解为两个关系模式:

所在系部(学号,系部)

住宿(系部,学生住处)

所在系部表的码为学号,住宿表的码为系部。

在分解后的关系模式中,既没有非主属性对码的部分函数依赖,也买有非主属性对码的传递函数依赖,在一定程度上解决了上述四个问题。

· 插入异常:如果刚刚成立某个系,目前暂时没有在校学生,就无法把这个系的信息存入数据库。

可以在住宿表中插入无在校学生的系的信息。

· 删除异常:如果某个系的学生全部毕业了,在删除该系学生信息的同时,把这个系的信息也丢掉了。

某个系的学生全部毕业了,删除的是所在系部表,住宿表中信息还存在。

· 数据冗余度大:每个系的学生都住在同一个地方,关于系的住处信息重复出现的次数与该系学生人数相同。

系的住处信息只在住宿表中存储一次。

· 修改复杂:如果学校调整学生住处,要把计算机系的学生全部迁到另一个地方住宿,由于每个系的住处信息是重复存储的,修改时必须同时更新该系所有学生的学生住处属性值。

当学校调整学生住处时,只需要修改住宿表中系部对应的学生住处的值。

但是将一个2NF关系分解为多个3NF的关系,并不能完全消除关系模式中各种异常情况和数据冗余。也就是说,属于3NF的关系模式并不一定是一个好的关系模式。

在关系模式STJ(S,T,J)中,S表示学生,T表示教师,J表示课程。

假设每一名教师只教一门课。每门课由若干教师教,某同学选定某门课程,就确定了一个固定的教师。所以,有如下函数依赖:

(S,J)->T,(S,T)->J,T->J

其中(S,J)和(S,T)都可作为候选码。

该关系模式中不存在任何非主属性对码的传递函数依赖或者部分函数依赖,所以STJ∈3NF。

但还存在一些问题:(只列举一二)

· 插入异常:某个教师开设了某种课程,但尚未有学生选修,则有关信息无法存入数据库中。

· 删除异常:如果选修过某门课程的学生全部毕业了,在删除这些学生元组的同时,相应教师开设改门课程的信息也同时丢失。

......

5、BCNF

如果关系模式 R∈1NF,且对于R的每个非平凡函数依赖X->Y(Y ⊈ X),决定因素X(单属性或属性组)都包含R的一个候选码,则R∈BCNF。

BCNF的关系模式具有如下三个性质:

①所有的非主属性对每一个候选码都是完全函数依赖;

②所有的主属性对每一个不包含它的候选码都是完全函数依赖;

③没有任何属性完全函数依赖于非码的任何一组属性。

 

关系模式STJ出现上述问题的原因在于主属性J部分依赖于码(S,T)。

现将STJ分解为以下两个关系模式:

ST(S,T)

TJ(T,J)

在分解后的关系模式中没有任何属性对码的部分函数依赖和传递函数依赖。

· 插入异常:某个教师开设了某种课程,但尚未有学生选修,则有关信息无法存入数据库中。

这个问题就可解决啦

· 删除异常:如果选修过某门课程的学生全部毕业了,在删除这些学生元组的同时,相应教师开设改门课程的信息也同时丢失。

这个问题也可解决啦

如果一个关系数据中的所有关系模式都属于BCNF,那么在函数依赖范畴内,它已实现了模式的彻底分解,达到了最高的规范化程度,消除了插入异常和删除异常。但还可能存在数据冗余和修改复杂等问题。

6、小结

本文部分是《数据库系统原理教程》给出的实例以及分析过程,在这过程中,我也会产生更多的思考,这能让我对知识点了解得更加透彻。书本真的是最重要的学习工具,一定要利用好这个工具,用心钻研。最后,祝大家学业有成!事业有成!

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/繁依Fanyi0/article/detail/682753
推荐阅读
相关标签
  

闽ICP备14008679号