博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
第三范式
阅读量:6153 次
发布时间:2019-06-21

本文共 1063 字,大约阅读时间需要 3 分钟。

如果关系模式R是1NF,且每个非主属性都不传递依赖于R的候选键,那么称R是第三范式(3NF)的模式。

 
 
 

基本信息

  • 中文名称

    第三范式

  • 外文名称

    third normal form

  • 关系

    传递函数依赖关系

  • 模式

    关系模式

 
  • 方法

    投影分解法

  • 解决目地

    每个关系模式中不能留有传递依赖

  • 注意

    关系S中不能没有外关键字DNO

 
目录
展开
 
 
 
 

简介

  每个非 列都独立于其他非关键字列,并依赖于关键字,第三范式指数据库中不能存在 关系。
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 函数决定是通过传递依赖 SNO -> 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}

转载地址:http://fpbfa.baihongyu.com/

你可能感兴趣的文章
WPF中,多key值绑定问题,一个key绑定一个界面上的对象
查看>>
UML类图简明教程
查看>>
java反编译工具(Java Decompiler)
查看>>
Android开发之自定义对话框
查看>>
微信Access Token 缓存方法
查看>>
Eclipsed的SVN插件不能识别之前工作空间的项目
查看>>
Linux 查看iptables状态-重启
查看>>
amazeui学习笔记一(开始使用2)--布局示例layouts
查看>>
c#中lock的使用(用于预约超出限额的流程)
查看>>
ODI基于源表时间戳字段获取增量数据
查看>>
并发容器之CopyOnWriteArrayList(转载)
查看>>
什么是AAC音频格式 AAC-LC 和 AAC-HE的区别是什么
查看>>
原创:goldengate从11.2升级到12.1.2
查看>>
Quartz
查看>>
正则表达式的语法规则
查看>>
C#一个关于委托和事件通俗易懂的例子
查看>>
类似于SVN的文档内容差异对比工具winmerge
查看>>
Cause: java.sql.SQLException: The user specified as a definer ('root'@'%') does not exist
查看>>
quratz线程
查看>>
execnet: rapid multi-Python deployment
查看>>