zoukankan      html  css  js  c++  java
  • 数据库规范化:函数依赖,三范式的区别

    函数依赖的定义

    关系模式中的各属性之间相互依赖、相互制约的联系称为数据依赖。数据依赖一般分为函数依赖、多值依赖和连接依赖。其中函数依赖是最重要的数据依赖。

    函数依赖(Functional Dependency,FD)是关系模式中属性之间的一种逻辑依赖关系。例如,在一个有关学生的关系模式SCD(属性SNo,SN,Age,Dept,MN,CNo,Score分别代表学生证号,学生姓名,年龄,所属院系,院系主人姓名,选修课程号,分数)中,属性SNo与SN、Age和Dept之间都有一种依赖关系。由于一个SNo只对应一个学生,而一个学生只能属于一个系,所以当SNo的值确定之后,SN、Age、Dept的值也随之被唯一地确定了。这类似于变量之间的单值函数关系。设单值函数Y=F(X),自变量X的值可以决定一个唯一的函数值Y。在这里,我们说SNo决定函数(SN, Age, Dept),或者说(SN, Age, Dept)函数依赖于SNo。

    设关系模式R(U, F),U是属性全集,F是U上的函数依赖集,X和Y是U的子集,如果对于R(U)的任意一个可能的关系r,对于X的每一个具体值,Y都有唯一的具体值与之对应,则称X决定函数Y,或Y函数依赖于X,记作X→Y。我们称X为决定因素,Y为依赖因素。当Y不函数依赖于X时,记作:Y↛X。当X→Y且Y→X时,则记作:X↔F。

    对于关系模式SCD
    U={SNo, SN, Age, Dept, MN, CNo, Score}
    F={SNo→SN, SNo→Age, SNo→Dept, (SNo, CNo)→Score}
    一个SNo有多个Score的值与其对应,因此 Score不能唯一地确定,即Score不能函数依赖于SNo,所以有:SNo↛Score,同样有:SNo↛CNo。但是Score可以被(SNo, CNo)唯一地确定。所以可表示为:(SNo,CNO)→Score。

    函数依赖的逻辑蕴涵定义

    假设已知关系模式R(X, Y, Z)有X→Y,Y→Z,问X→Z是否成立?能否从已知的函数依赖推导出XY→YZ?
    类似这些由已知的一组函数依赖,判断另外一些函数依赖是否成立或者能否从前者推导出后者的问题,就是函数依赖的逻辑蕴涵所要讨论的内容。

    设F是在关系模式R(U)上成立的函数依赖集合,X,Y是属性集U的子集,X→Y是一个函数依赖。如果从F中能够推导出X→Y,即如果对于R的每个满足F的关系r也满足X→Y,则称X→Y为F的逻辑蕴涵(或F逻辑蕴含X→Y),记为F|=X→Y。

    设F是函数依赖集,被F逻辑蕴涵的函数依赖的全体构成的集合,称为函数依赖集F的闭包(Closure),记为。

    函数依赖的推理规则及正确性

    从已知的函数依赖,可以推导出另外一些新的函数依赖,这就需要一系列推理规则,这些规则常被称为“Armstrong公理”。

    设有关系模式R(U),U是关系模式R的属性集,F是R上成立的只涉及U中属性的函数依赖集。X,Y,Z,W均是U的子集,r是R的一个实例。函数依赖的推理规则如下。

    Armstrong公理

    (1)自反律(Reflexivity)
    如果 Y⊆X⊆U,则X→Y在R上成立。即一组属性函数决定它的所有子集。
    例如,在关系SCD中,(SNo, CNo)→SNo和(SNo, CN)→CNo。

    (2)增广律(Augmentation)
    若X→Y在R上成立,且Z属于U,则XZ→YZ在R上也成立。

    (3)传递律(Transitivity)
    若X→Y和Y→Z在R上成立,则X→Z在R上也成立。

    Armstrong公理的推理规则是正确的。也就是,如果X→Y是从F用推理规则导出,那么X→Y在中。

    Armstrong公理推论

    (1)合并律(Union rule)
    若X→Y和X→Z在R上成立,则X→YZ在R上也成立。
    例如,在关系SCD中,SNo→(SN, Age),SNo→(Dept, MN), 则有SNo→(SN, Age, Dept, MN)。

    (2)伪传递律(Pseudotransitivity rule)
    若X→Y和YW→Z和在R上成立,则XW→Z在R上也成立。

    (3)分解律(Decomposition rule)
    若X→Y和Z⊆Y在R上成立,则X→Z在R上也成立。
    很显然,分解律为合并律的逆过程。

    由合并律和分解律,很容易得到以下定理:
    如果…是关系模式R的属性集,那么X→…成立的充分必要条件是X→(i=1, 2, … , n)成立。

    (4)复合律
    若X→Y和W→Z在R上成立, 则XW→YZ在R上也成立。

    函数依赖的分类

    完全函数依赖与部分函数依赖

    设有关系模式R(U),U是属性全集,X和Y是U的子集,如果X→Y,并且对于X的任何一个真子集X’,都有X’↛Y,则称Y对X完全函数依赖(Full Functional Dependency),记作XY。如果对X的某个真子集X’,有X’→Y,则称Y对X部分函数依赖(Partial Dependency),记作XY。

    例如,如在关系模式SCD中,因为SNo↛Score,且CNo↛Score,所以有(SNo, CN)Score。而SNo→Age,所以(SNo,CNo)Age。

    只有当决定因素是组合属性时,讨论部分函数依赖才有意义,当决定因素是单属性时,只能是完全函数依赖。例如,在关系模式S(SNo, SN, Age, Dept)中,决定因素为单属性SNo,有SNo→(SN, Age, Dept),不存在部分函数依赖。

    传递函数依赖

    设有关系模式R(U),U是属性全集,X,Y,Z是U的子集,若X→Y,但Y↛X,而Y→Z(Y⊄ X,Z⊄ Y),则称Z对X传递函数依赖(Transitive Functional Dependency),记作:XZ。如果Y→X,则Y↔X,这时称Z对X直接函数依赖,而不是传递函数依赖。

    例如,在关系模式SCD中,SNo→Dept,但Dept↛SNo,而Dept→MN, 则有SNoMN。当学生不存在重名的情况下,有SNo→SN,SN→SNo,SNo↔SN,SN→Dept,这时Dept对SNo是直接函数依赖,而不是传递函数依赖。

    综上所试述,函数依赖分为完全函数依赖、部分函数依赖和传递函数依赖三类,它们是规范化理论的依据和规范化程度的准则。

    范式

    1 、第一范式(1NF)

    在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。

    所谓第一范式(1NF)是指数据库表的每一列(即每个属性)都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。简而言之,第一范式就是无重复的列。

    2、 第二范式(2NF)

    第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是唯一的,因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。

    第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是非主属性依赖于主关键字。

    3 、第三范式(3NF)

    满足第三范式(3NF)必须先满足第二范式(2NF)。在满足第二范式的基础上,切不存在传递函数依赖,那么就是第三范式。简而言之,第三范式就是属性不依赖于其它非主属性。

    最后简单的总结一下:

    1、第一范式(1NF):一个关系模式R的所有属性都是不可分的基本数据项。

    2、第二范式(2NF):关系模式R属于第一范式,且每个非主属性都完全函数依赖于键码。

    3、第三范式(3NF):关系模式R属于第一范式,且每个非主属性都不伟递领带于键码。

    4、 BC范式(BCNF):关系模式R属于第一范式,且每个属性都不传递依赖于键码。

  • 相关阅读:
    哲理故事
    ajaxToolkit发布之后出错!说未能加载文件或程序集!
    一个沉重的教训!!!
    ValidatorCallout真的是太酷了!
    GridView放在UpdatePanle里面模板列取值!
    Prototype学习笔记之-Ajax.Request
    数据分类重排!
    SQL SERVER 2005 sa登录失败!
    flex应该学到什么程度
    jquery dataTable的学习
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13308067.html
Copyright © 2011-2022 走看看