20321关系数据库理论基础 (10)

l  由于“学号”和“导师工号”都是单属性,因此上述函数依赖都是完全函数依赖,一共有三种类型,因此在进行投影分解后可得到如下的三个关系模式:

Ø Student(学号, 姓名, 系别, 导师工号)

Ø supervisor(导师工号, 导师姓名, 导师职称)

Ø course(学号, 课程名称, 课程成绩)

l  这三个关系模式的码分别为学号、导师工号和{学号, 课程名称},每个关系模式中非主属性都完全函数依赖于码。这三个关系模式都属于第二范式。

l  利用基于外码的自然连接可以将这三个关系合成原来的关系SSC,即 SSC = student⋈ 导师工号supervisor ⋈学号course。外码的设置如:“导师工号”是student的关于supervisor的外码,“学号”是course的关于student的外码。

l  一个关系模式的码都是由一个属性构成,该关系模式肯定属于第二范式,因为这时每个非主属性都显然完全函数依赖于码。

 

  【例2.8】设有关系模式teacher(课程名, 任课教师名, 任课教师职称),表2.19为关系模式teacher的一张关系表。假设每名教师可以上多门课,每门课只由一名教师上,请问关系模式teacher属于几范式?

 

20321关系数据库理论基础

关系模式teacher的候选码只有“课程名”,而“任课教师名”和“任课教师职称”都是非主属性。显然有函数依赖集{课程名→任课教师名, 任课教师姓名→任课教师职称, 课程名

20321关系数据库理论基础

任课教师职称},即每个非主属性都完全依赖于候选码,故关系模式teacher属于2NF。

 

 

 

上例中关系模式teacher属于2NF,仍存在数据冗余和插入、删除操作异常。

 

   【例子】若某任课教师上多门课,则需要在teacher表中存储多次该教师的职称信息(数据冗余);对于一个新来教师,如果其还没有排课,那么将无法输入该教师的信息,因为课程名作为主码不能为空(插入异常);又如删除一个任课教师的所有任课记录,则找不到该任课教师姓名和职称信息了(删除异常)。导致这种数据冗余和操作异常的原因在于该关系模式中存在传递函数依赖,这将在2.5.3节举例说明。

 

2.5.3 第三范式(3NF)

     定义2.10   设R(U)是一个关系模式,如果R(U)∈2NF且每个非主属性都不传递函数依赖于任一候选码,则称R(U)属于第三范式,记为R(U)∈3NF。

          注意,如果一个关系模式的属性全是主属性,那该关系模式肯定属于第三范式,因为该关系模式不存在非主属性。

    【例2.9】假设有一个关于学生选课信息的关系模式——s_c(学号, 课程号, 名次),其相关语义是:学号和课程号分别是学生和课程的唯一标识属性,每一名学生选修的每门课程有一个名次,且名次不重复。

Ø 其函数依赖包括:{学号, 课程号} → 名次,{课程号, 名次} → 学号。{学号, 课程号}和{课程号, 名次}是此关系的候选码。其所有的属性都是主属性,此关系模式属于第三范式。

l  第三范式是在第二范式的基础上,增加了条件“每个非主属性都不传递函数依赖于任一候选码”而得到的。

 

 

【例2.10】假设有一个关于员工信息的关系模式:emp_info(Eno, Ename, Dept, Dleader)。其中,Eno为员工编号,Ename为员工姓名,Dept为员工所在部门,Dleader为部门领导。请说明该关系模式属于第几范式以及它存在的问题。

Ø 员工编号是唯一的,每个员工只属于一个部门,每个部门只有一个领导(这里假设领导不属于员工范畴,且不考虑纵向领导关系)。员工编号(Eno)为唯一的码,由此容易推出:   

        Eno → Ename

                  Eno → Dept

                       Eno → Dleader

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zygszg.html