建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块
标签
您还可以添加5个标签
  • 没有搜索到和“关键字”相关的标签
  • 云产品
  • 解决方案
  • 技术领域
  • 通用技术
  • 平台功能
取消

scu-w

发帖: 260粉丝: 8

级别 : 外部版主

发消息 + 关注

发表于2020年11月21日 10:18:36 47 3
直达本楼层的链接
楼主
显示全部楼层
[干货分享] 第三范式

定义

关系模式R<U,F> 中若不存在这样的码X、属性组Y及非主属性Z(Z (强制依赖)Y),使得X→Y,Y→Z,成立,Y→X不成立,则称R<U,F> ∈ 3NF。

若R∈3NF,则R的每一个非主属性既不部分函数依赖于候选码也不传递函数依赖于候选码。
如果R∈3NF,则R也是2NF。
采用投影分解法将一个2NF的关系分解为多个3NF的关系,可以在一定程度上解决原2NF关系中存在的插入异常、删除异常、数据冗余度大、修改复杂等问题。
将一个2NF关系分解为多个3NF的关系后,并不能完全消除关系模式中的各种异常情况和数据冗余。

例:

如S1(SNO,SNAME,DNO,DNAME,LOCATION) 各属性分别代表学号,姓名,所在系,系名称,系地址。

关键字SNO决定各个属性。由于是单个关键字,没有部分依赖的问题,肯定是2NF。但这关系肯定有大量的冗余,有关学生所在的几个属性DNO,DNAME,LOCATION将重复存储,插入,删除和修改时也将产生类似以上例的情况。
原因:关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在,DNO -> LOCATION, 因此关键字 SNO 对 LOCATION 函数决定是通过传递依赖 DNO -> LOCATION 实现的。也就是说,SNO不直接决定非主属性LOCATION。
解决目的:每个关系模式中不能留有传递依赖。
解决方法:分为两个关系 S(SNO,SNAME,DNO),D(DNO,DNAME,LOCATION)
注意:关系S中不能没有外关键字DNO。否则两个关系之间失去联系。
第一范式第二范式化为第三范式的步骤:
(1)求出R的最小函数依赖集Fmin
(2)找出不在Fmin中出现的属性,并将这些属性从R中去掉,构成一个关系模式
(3)若Fmin中有一个函数依赖涉及R的全部属性,则R不能分解
(4)否则,若Fmin中有X->A,则分解应包含{XA};若有X->A1,X->A2....X->An均属于Fmin,则分解应包含{XA1A2...An}


举报
分享

分享文章到朋友圈

分享文章到微博

极客潇

发帖: 359粉丝: 25

级别 : 外部版主

发消息 + 关注

发表于2020年11月21日 11:26:08
直达本楼层的链接
沙发
显示全部楼层

感谢分享

点赞 评论 引用 举报

andyleung

发帖: 764粉丝: 57

级别 : 外部版主

发消息 + 关注

发表于2020年11月21日 15:54:46
直达本楼层的链接
板凳
显示全部楼层

感谢分享

点赞 评论 引用 举报

柠檬PH=2

发帖: 254粉丝: 37

级别 : 外部版主

发消息 + 关注

发表于2020年11月21日 22:55:49
直达本楼层的链接
地板
显示全部楼层

清晰明了,感谢分享

点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册