zoukankan      html  css  js  c++  java
  • 关系数据理论之第三范式

    函数依赖已经总结完了,直接总结第三范式,第三范式的形式化定义是这样的:关系模式R(U)中如果不存在这样的码X,属性组Y以及非主属性Z(Z不包含于Y),使得X函数确定Y, Y函数确定Z, Y不能函数确定X(也就是X不是R(U)的候选码),则称R(U)属于第三范式。第三范式讲的是:一个非主属性既不能部分依赖于码,也不能传递依赖于码。

    对于上一节的第二范式总结中,为了达到第二范式,原来的S-L-C(Sno,Sdept,Sloc,Cno,Grade)被分解为SC(Sno,Cno,Grade)、SL(Sno,Sdept,Sloc),但是这些分解后的关系模式达到第三范式了吗?请看下图:

    对于关系模式SL有这样的依赖关系:Sno函数确定Sdept,Sdept函数确定Sloc,可以得出Sno函数确定Sloc,所以SL关系模式中,存在非主属性对码的传递依赖,故而关系模式SL不属于第三范式,而关系模式SC则属于第三范式。

    总结:第三范式约束关系模式中的非主属性只能完全函数依赖于码,而不能依赖于非码的属性(这样就不存在传递依赖于码了)。相对于第二范式的“非主属性都得全部依赖于码”的要求,第三范式又多了一个限定,所以约束性更强了。

    下面接着总结一下BCNF(Boyce Codd Normal Form),它是由Boyce和Codd提出的,比上述的3NF又进了一步,有时称其为扩展的第三范式,其形式化的定义是:关系模式R(U)属于第一范式,如果X函数确定Y,且Y不包含于X时,则X必含有码,那么该关系模式属于BCNF,也就是说,关系模式R(U)中,每一个决定性因素都包含码,一个满足BCNF的关系模式有以下特性:

    1、所有的非主属性对一个码都是完全函数依赖。

    2、所有的主属性对一个不包含它本身的码也是完全函数依赖。

    3、没有任何属性完全函数依赖于非码的任何一组属性。

    可以看出,BCNF排除了任何属性对码的传递依赖和部分依赖,故而如果一个模式是BCNF,那么它必定是第三范式,但是反之未必,因为3NF中,可能存在主属性对码的部分依赖和传递依赖。

  • 相关阅读:
    linux 6.9 补丁修补漏洞
    更改交换分区
    MariaDB Windows 安装
    关于Oracle内存分配-解决实际运行时最大Session数不一致远小于系统配置最大的Session数目
    Angular 相关概念
    实用工具推荐
    DDD目录结构
    全局异常处理区分返回响应类型是页面还是JSON
    Lambda学习总结(三)--方法引用
    Lambda学习总结(二)--Stream流
  • 原文地址:https://www.cnblogs.com/codeMedita/p/7428694.html
Copyright © 2011-2022 走看看