函数依赖与范式

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

因此(学生,课程)是一个码。
然而,一个课程,一定指定了某个教材,一年级语文肯定用的是《小学语文 1》,那么就有 课ቤተ መጻሕፍቲ ባይዱ->教材。(学生,课程)是个码,课程却决定了教材,这就叫做不完全依赖,或者说 部分依赖。出现这样的情况,就不满足第二范式!
有什么不好吗?你可以想想:
1、校长要新增加一门课程叫“微积分”,教材是《大学数学》,怎么办?学生还没选课,而 学生又是主属性,主属性不能空,课程怎么记录呢,教材记到哪呢? ……郁闷了吧?(插入异 常)
-----------------------------------------------------------------------------------------第二范式:
定义:如果关系模式 R 是第一范式的,而且关系中每一个非主属性不部分依赖于主键,称 R 是第二范式的。
所以第二范式的主要任务就是
A楼3
这个表完全满足于第一范式, 主键由 StudyNo 和 ClassNo 组成,这样才能定位到指定行 但是,ClassAddress 部分依赖于关键字(ClassNo-〉ClassAddress), 所以要变为两个表
表一
StudyNo | Name | Sex | Email
| Phone | ClassNo
学生 课程 老师 老师职称 教室 课时间
小明 一年级语文(上) 大宝 副教授 101 14:30 学生上课表新
课程 教材 一年级语文(上) 《小学语文 1》 课程的表
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖 主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成 一个新的实体
有什么问题吗?想想:
1、 老师升级了,变教授了,要改数据库,表中有 N 条,改了 N 次……(修改异常)
2、 没人选这个老师的课了,老师的职称也没了记录……(删除异常)
3、 新来一个老师,还没分配教什么课,他的职称记到哪?……(插入异常)
那应该怎么解决呢?和上面一样,投影分解:
学生 课程 老师 教室 上课时间
2、下学期没学生学一年级语文(上)了,学一年级语文(下)去了,那么表中将不存在一 年级语文(上),也就没了《小学语文 1》。这时候,校长问:一年级语文(上)用的什么 教材啊?……郁闷了吧?(删除异常)
3、校长说:一年级语文(上)换教材,换成《大学语文》。有 10000 个学生选了这么课, 改动好大啊!改累死了……郁闷了吧?(修改异常) 那应该怎么解决呢?投影分解,将一个表分解成两个或若干个表
3NF 去除了非主属性对主键的部分函数依赖和传递函数依赖。一般满足 3NF 的关系模式已 能消除冗余和各种异常现象,获得较满意的效果,但无论 2NF 还是 3NF 都没有涉及主属性 间的函数依赖,所以有时仍会引起一些问题。由此我们引入 BC 范式(BCNF,Boyeet 和 Codd 提出),通常认为 BCNF 是第三范式的改进。
1.数 据 依 赖 数据依赖指的是通过一个关系中属性间的相等与否体现出来的数据间 的相互关系,其中最重要的是函数依赖和多值依赖。
2.函 数 依 赖 设 X,Y 是 关 系 R 的 两 个 属 性 集 合 , 当 任 何 时 刻 R 中 的 任 意 两 个 元 组 中 的 X 属 性 值 相 同 时 ,则 它 们 的 Y 属 性 值 也 相 同 ,则 称 X 函 数 决 定 Y,或 Y 函 数 依 赖 于 X。 3.平 凡 函 数 依 赖 当 关 系 中 属 性 集 合 Y 是 属 性 集 合 X 的 子 集 时 ( Y ∈X ) , 存 在 函 数 依 赖 X → Y, 即 一 组 属 性 函 数 决 定 它 的 所 有 子 集 , 这 种 函 数 依 赖 称 为 平 凡 函 数 依 赖。
Male kkkk@ee.net
20040902 mary
famale kkk@fff.net
bounsLevel | bouns
优秀
$1000

$600
上面的“学生上课表新”符合 2NF,可以这样验证:两个主属性单独使用,不用确定其它四个 非主属性的任何一个。但是它有传递依赖!
在哪呢?问题就出在“老师”和“老师职称”这里。一个老师一定能确定一个老师职称。
通常 BC 范式的条件有多种等价的表述:每个非平凡依赖的左边必须包含键码;每个决定因 素必须包含键码。
BC 范式既检查非主属性,又检查主属性。当只检查非主属性时,就成了第三范式。满足 BC 范式的关系都必然满足第三范式。
还可以这么说:若一个关系达到了第三范式,并且它只有一个候选码,或者它的每个候选码 都是单属性,则该关系自然达到 BC 范式。
BC 范式的定义:如果关系模式 R∈1NF,且 R 中每一个决定因素都是候选键,则 R 是满足 BC 范式的关系,记作 R∈BCNF。
当一个关系模式 R∈BCNF,则在函数依赖范畴里,已实现了分离,消除了插入、删除 的异常。
6.部 分 函 数 依 赖
设 X,Y 是 关 系 R 的 两 个 属 性 集 合 ,存 在 X→ Y,若 X’是 X 的 真 子 集 ,存 在 X’→ Y, 则 称 Y 部 分 函 数 依 赖 于 X。
7.传 递 函 数 依 赖
设 X,Y,Z 是 关 系 R 中 互 不 相 同 的 属 性 集 合 , 存 在 X→ Y(Y !→ X),Y→ Z, 则 称 Z 传 递 函 数 依 赖 于 X。
20040901 mary
famale email:kkk@fff.net phone:123455
以上的表就不符合,第一范式:主键重复(实际中数据库不允许重复的),而且 Contact 字段 可以再分
所以变更为正确的是
StudyNo | Name | Sex | Email
| Phone
20040901 john 20040902 mary
函数依赖与范式
版权所有:07 数字媒体
主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。 非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。 外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。 码:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那 么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。 第一范式是确定模式是符合关系关系模式的要求,即确立某关系属于关系模式。 第二范式是消除了非主属性对主码的部分函数依赖。 第三范式是消除了非主属性的传递函数依赖。 BCNF 是消除了所有属性的传递函数依赖。
满足第一范式的前提下,消除部分函数依赖。
StudyNo | Name | Sex | ClassAddress
Email
| Phone | ClassNo |
01
john Male kkkk@ee.net 222456 200401
A楼2
01
mary famale kkk@fff.net 123455 200402
小明 一年级语文(上) 大宝 101 14:30
老师 老师职称 大宝 副教授 ----------------------------------------------------------------------
BC 范式(BCNF):
符合 3NF,并且,主属性不依赖于主属性
若关系模式属于第一范式,且每个属性都不传递依赖于键码,则 R 属于 BC 范式。
小明 一年级语文(上) 大宝 副教授 《小学语文 1》 101 14:30
一个学生上一门课,一定在特定某个教室。所以有(学生,课程)->教室 一个学生上一门课,一定是特定某个老师教。所以有(学生,课程)->老师
一个学生上一门课,他老师的职称可以确定。所以有(学生,课程)->老师职称
一个学生上一门课,一定是特定某个教材。所以有(学生,课程)->教材 一个学生上一门课,一定在特定时间。所以有(学生,课程)->上课时间
-------------------------------------------------------------------------------第三范式:
满足第二范式的前提下,消除传递依赖。
例:
StudyNo | Name | Sex | Email
| bounsLevel | bouns
所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不 能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属 性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一 对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。例如,对于图 3-2 中 的员工信息表,不能将员工信息都放在一列中显示,也不能将其中的两列或多列在一列中显 示;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表中只出现一次。简而 言之,第一范式就是无重复的列。
第一范式
定义:如果关系 R 中所有属性的值域都是单纯域,那么关系模式 R 是第一范式的 那么符合第一模式的特点就有
1)有主关键字 2)主键不能为空, 3)主键不能重复, 4)字段不可以再分 例如:
StudyNo | Name | Sex | Contact
20040901 john
Male Email:kkkk@ee.net,phone:222456
20040901 john
Male kkkk@ee.net 优秀
$1000
20040902 mary
famale kkk@fff.net 良
$600
这个完全满足了第二范式,但是 bounsLevel 和 bouns 存在传递依赖
更改为:
StudyNo | Name | Sex | Email
20040901 john
Male kkkk@ee.net 222456 famale kkk@fff.net 123455
这两种情况都不满足第一范式。不满足第一范式的数据库,不是关系数据库!所以,我们在 任何关系数据库管理系统中,做不出这样的“表”来。
在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF) 的数据库就不是关系数据库。
01
john
Male kkkk@ee.net 222456 200401
01
mary
famale kkk@fff.net 123455 200402
表二
ClassNo | ClassAddress 200401 A 楼 2 200402 A 楼 3 (学生上课表)
学生 课程 老师 老师职称 教材 教室 上课时间
4.非 平 凡 函 数 依 赖 当 关 系 中 属 性 集 合 Y 不 是 属 性 集 合 X 的 子 集 时 , 存 在 函 数 依 赖 X→ Y, 则称这种函数依赖为非平凡函数依赖。
5.完 全 函 数 依 赖
设 X,Y 是 关 系 R 的 两 个 属 性 集 合 , X’是 X 的 真 子 集 , 存 在 X→ Y, 但 对 每 一 个 X’都 有 X’!→ Y, 则 称 Y 完 全 函 数 依 赖 于 X。
相关文档
最新文档