0%

数据库三大范式

本文为数据库三大范式的笔记整理。

数据库-基本概念整理-三大范式

候选码

候选码:若关系中的某一属性的值能唯一地标识一个元组,而其子集不能,则称该属性组为候选码,若一个关系中有多个候选码,则选定其中一个为主码。

主属性

主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。

第一范式

定义:表示属于第一范式的所有属性不可再分,即数据项不可再分。

第二范式

定义:若某关系R属于第一范式,且每一个非主属性完全函数完全依赖于任何一个候选码,则关系R属于第二范式。

部分函数依赖

部分函数依赖是指多个属性决定另一个属性,但事实上,这多个属性是有冗余的。例如,(学号,班级)->姓名,事实上只需要学号就能决定姓名,因此班级是冗余的。

完全函数依赖

完全函数依赖是消除了部分函数依赖,关系中的非主属性完全能主属性或者组合属性推导而出。如有选课关系表(学号,课程号,成绩,学分),其中关键字为组合关键字(学号,课程号),由于非主属性学分仅依赖于课程号,对关系字(学号,课程号)只是部分依赖,而不是完全依赖,因些这种方式会导致数据冗余以及更新异常等问题,解决办法是将其分为两个关键模式:学生表(学号,课程号,分数)和课程表(课程号,学分),新关系通过学生表中的外关键字课程号联系,在需要时进行连接。

我们有选课关系表(学号,课程号,成绩,学分),我们对其进行学分修改时,我们需要找到所有选过这个课程号的学生,并对其进行学分的修改,这样会导致数据冗余,而若我们拆分学生表与课程表就不会发生这种情况,而若我们需要删除该课程时,也会导致此类情况。

判断

判断一个关系是否属于第二范式:

1、找出数据表中的所有码;

2、找出所有主属性和非主属性;

3、判断所有非主属性对码的部分函数依赖;

第三范式

定义:第三范式是在第二范式的基础上消除了传递依赖,即非主属性既不传递依赖于码,也不部分依赖于码。

若我们有表学生上课表 (姓名,课程,老师,老师职称,教室,上课时间),这个表上具有传递依赖。即

(姓名,课程)->老师->老师职称

该表具有如下问题

1、若老师改变了职称,则需要修改数据库,若有N条记录,都需要修改N条(修改异常)

2、若没人选这个老师的课,那么老师的职称也没了记录(删除异常)

3、若新来一个老师,暂时还未分配教授课程,那么没有表记录他的职称(插入异常)

我们需要对于学生上课表进行分解,有

(姓名,课程,老师,教室,上课时间)

(老师,老师职称)

BC范式(BCNF)

BC范式符合3NF,并且主属性不依赖于主属性。

BC范式既检查非主属性,又检查主属性。当只检查非主属性时,就成了第三范式。满足BC范式的关系都必然满足第三范式。还可以这么说:若一个关系达到了第三范式,并且它只有一个候选码,或者它的每个候选码都是单属性,则该关系自然达到BC范式。

假设仓库管理关系表(仓库ID,存储物品ID,管理员ID,数量),且只有一个管理员只在一个仓库工作,一个仓库可以存储多种物品。

这个数据库表存在如下决定关系:

(仓库ID,存储物品ID)->(管理员ID,数量)

(管理员ID,存储物品ID)->(仓库ID,数量)

所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

这种关键字决定关键字段的情况,其不符合BCNF范式。

以上关系表会存在如下问题

1、删除异常

当仓库被清空后,所有”存储物品ID”和”数量”信息被删除的同时,”仓库ID“与”管理ID“也被删除了。

2、插入异常

当仓库没有存储任何物品时,无法给仓库分配管理员。

3、更新异常

如果仓库更换了管理员,则表中所有行的管理员ID都要修改。

所以需要把上述关系分解为

仓库管理:(仓库ID,管理员ID)

仓库:(仓库ID,存储物品ID,数量)

这样的数据库表符合BCNF范式,消除了删除异常,插入异常与更新异常

参考链接:https://www.cnblogs.com/lca1826/p/6601395.html