嘘~ 正在从服务器偷取页面 . . .

数据库系统概论(三)——规范化


数据依赖

在讨论规范化之前,我们有必要先考虑数据依赖的问题

数据依赖的主要类型有:函数依赖(Functional Dependency,简记为FD)和多值依赖(Multi-Valued Dependency,简记为MVD)

函数依赖

定义

设X,Y是关系R的两个属性集合,当任何时刻R中的任意两个元组中的X属性值相同时,则它们的Y属性值也相同,则称X函数决定Y,或Y函数依赖于X。

其实简单来说就是:若在一张表中,属性或属性组X确定,必定能确定属性Y的值,则称Y函数依赖于X,记做X->Y.例如在学生表中通过学号能唯一确定一个姓名,则姓名函数依赖于学号。

平凡函数依赖和非平凡函数依赖

定义

设一个关系为R(U),X和Y为属性集U上的子集,若X→Y且X不包含Y,则称X→Y为非平凡函数依赖,否则若X包含Y则必有X→Y,称此X→Y为平凡函数依赖.

例如在学生表中,学号总能决定它本身,记作“学号→学号”,对于任一个给定的学号,都有它本身的学号值唯一对应,此为平凡函数依赖.(学号,性别)->性别与(学号,性别)->学号也是平凡函数依赖

通常,我们主要讨论的是非平凡函数依赖:如学生表中学号函数决定的其他属性都是非平凡函数依赖

完全函数依赖

定义

设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。

具体来说,在一张表中,若 X → Y,且对于 X 的任何一个真子集(假如属性组 X 包含超过一个属性的话),X ‘ → Y 不成立,那么我们称 Y 对于 X 完全函数依赖。

部分函数依赖

定义

设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。

比如,学生表中(学号,姓名)->性别,但是存在学号->性别,所以称性别部分依赖于(学号,姓名)

传递函数依赖

定义

设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。

例如,关系S1(学号,系名,系主任),学号 → 系名,系名 → 系主任,并且系名 !→ 学号,所以学号 → 系主任为传递函数依赖。

多值依赖

设R(U)是属性集U上的一个关系模式。X,Y,Z是U的子集,并且Z=U-X-Y。若给定一对(x,z)值有一组Y的值且这组值仅仅决定于x值而与z值无关,则关系模式R(U)中多值依赖X→→Y成立

第一范式(1NF)

定义

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

第一范式是对关系模式的最起码的要求,不满足第一范式的数据库模式不能称为关系数据库。但满足第一范式的关系模式并不一定是一个好的数据库。

例如,如果将教师表的姓名与性别放在同一列就不符合1NF,当然这在建表的时候就不会成功。简而言之,同一列中不能有多个值。

判断方法:

  • 是否表中套表
  • 是否存在主键
  • 非主键是否依赖于主键

第二范式(2NF)

定义

在1NF基础上,消除非主属性的部分依赖

所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,例如,表的主键是学号加CID(课程号),但(学号)->姓名,所以姓名部分函数依赖于(学号,CID(课程号)),不符合2NF。

不满足第二范式可能造成:

  • 插入异常:例如一个学生在报道的时候由于只有学号其课程号为NULL则不满足主键不为NULL的要求,后续数据便无法录入。
  • 删除异常:例如一个学生生病了需要退选课程则需要将整个信息都删除,但学生并没有被开除因此会产生误解。
  • 更新异常:例如一个学生选了50门课程,则其基本信息重复了50次,如果学生家庭地址发生改变则基本信息需要修改50次,会产生不必要数据冗余。

第三范式(3NF)

定义

在2NF基础上,消除非主属性的传递依赖

例如,变成如下,存在
CID(课程号)->TID(授课老师ID),TID(授课老师ID)->教师姓名,所以教师姓名传递函数依赖于CID(课程号),不满足3NF,但是主键是CID满足2NF。

不满足第三范式可能造成:

  • 插入异常:例如一个员工有ID,工资等级,工资金额三个属性,其工资金额由工资等级决定,主键为ID。当录入新员工时由于其工资等级还未确定则工资等级和工资金额都无法录入。
  • 删除异常:同上,假设一个员工跳槽了,其整个信息都将被删除但某个等级对应的工资金额不应该被删除。
  • 更新异常:假设有多个拿三级工资的人,则三级工资对应的薪水工资信息也将重复,一旦修改金额则对应的信息要重复修改,会产生不必要数据冗余。

BC范式(BCNF)

定义

在3NF基础上,每个属性都不传递依赖于关系模型R的候选键,

假设仓库管理关系表(仓库号,存储物品号,管理员号,数量),满足一个管理员只在一个仓库工作;一个仓库可以存储多种物品,则存在如下关系:

(仓库号,存储物品号)——>(管理员号,数量)

(管理员号,存储物品号)——>(仓库号,数量)

所以,(仓库号,存储物品号)和(管理员号,存储物品号)都是仓库管理关系表的候选码符合第三范式。但是,由于存在如下决定关系:

(仓库号)——>(管理员号)

(管理员号)——>(仓库号)

因此其不符合BCNF

注意:基本的数据库设计到这里就可以结束了,4NF和5NF在现实中遇到极少,在这里便不详细论述了

第四范式(4NF)

定义

在BCNF基础上,消除多值依赖

第五范式(5NF)

定义

在4NF基础上,消除连接依赖

如果有其他问题欢迎留言或邮件提问

QQ:1269112498

Email:1269112498@qq.com

相关文章


文章作者: 刘天翼
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 刘天翼 !
评论
  目录