zoukankan      html  css  js  c++  java
  • 数据库设计中的规范化

    范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求。满足最低要求的叫第一范式,简称1NF,在第一范式基础上进一步满足一些要求的为第二范式,简称2NF。其余依此类推,目前有六种范式:1NF,2NF,3NF,BCNF,4NF,5NF。

    1 第一范式(1NF)

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

          所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如 果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一 个实例的信息。例如,对于图3-2 中的员工信息表,不能将员工信息都放在一列中显示,也不能将其中的两列或多列在一列中显示;员工信息表的每一行只表示一个员工的信息,一个员工的信息在表 中只出现一次。简而言之,第一范式就是无重复的列。

    2 第二范式(2NF)

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

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

    3 第三范式(3NF)

          满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例 如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将 部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简 而言之,第三范式就是属性不依赖于其它非主属性。

    BC范式(BCNF)

            例如:在关系模式STJ(S,T,J)中S表示学生,T表示教师,J表示课程。假设每一教师只教一门课程,一门课程由多个教师任课,某一学生选定某门课程,就确定了一个固定的教师。于是,有如下函数依赖
    (S,J)→T,(S,T)→J,T→J
    显然,(S,J)和(S,T)都可以作为候选码。该关系模式没有任何非主属性对码传递依赖或部分依赖,所以STJ∈3NF。但另一方面,T→J,即T是决定属性集,可是T只是主属性,它既不是候选键,也不包含候选键

    如果关系模式是R∈BCNF,由定义可知,R中不存在任何属性传递依赖于或部分依赖于任何候选键,所以必有R∈3NF。但是,如果R∈3NF,R未必属于BCNF。
    3NF和BCNF是以函数依赖为基础的关系模式规范化程度的测度。
    如果一个关系数据库中的所有关系模式都属于3NF,则已在很大程度上消除了插入异常和删除异常,但由于可能存在主属性对候选码的部分依赖和传递依赖,因此关系模式的分离不够彻底。
    如果一个关系数据库中的所有关系模式都属于BCNF,那么在函数依赖范畴内,它已实现了模式的彻底分解,达到了最高的规范化程度,消除了插入异常和删除异常。

    多值依赖与第四范式(4NF)

            前面完全是在函数依赖范畴内讨论关系模式的范式问题。如果仅考虑函数依赖这一种数据依赖,属于BCNF的关系模式已经很完美了,但如果考虑其他数据依赖,例如多值依赖,属于BCNF的关系模式仍然存在问题。


    此例子将帮助你更好的理解

    设有关系模式R(运动员编号,比赛项目,成绩,比赛类别,比赛主管),如果规定:每个运动员每参加一个比赛项目,只有一个成绩;每个比赛项目只属于一个比赛类别;每个比赛类别只有一个比赛主管。

    请回答下列问题:

    1)根据上述规定,写出模式R的基本FD和关键码

    2)说明R不是2NF的理由,并把R分解成2NF模式集

    3)进而分解成3NF模式集

    解:

    1)基本的FD3个:

    (运动员编号,比赛项目)→成绩;比赛项目→比赛类别;比赛类别→比赛主管

    该关系R的关键码(即候选码)为:(运动员编号,比赛项目)


    2R中两个这样的FD

    (运动员编号,比赛项目)→(比赛类别,比赛主管)

    比赛项目→(比赛类别,比赛主管)

    存在非主属性对主属性的部分函数依赖,所以R不是2NF

    R应分解为:R1比赛项目,比赛类别,比赛主管)

    R2运动员编号,比赛项目,成绩)

    此时,R1R22NF


    3R2已经是3NF,但是R1中存在两个FD

    比赛项目→比赛类别;

    比赛类别→比赛主管

    存在非主属性对主属性的传递函数依赖,所以R不是3NF

    R1分解为R11(比赛项目,比赛类别)

    R12(比赛类别,比赛主管)

     

    关系模式规范化的步骤:
    (1)    对1NF关系进行投影,消除原关系中非主属性对码的部分函数依赖,将1NF关系转换为若干个2NF
    (2)    对2NF关系进行投影,消除原关系中非主属性对码的传递函数依赖,从而产生一组3NF
    (3)    对3NF关系进行投影,消除原关系中主属性对码的部分函数依赖和传递函数依赖,得到一组BCNF关系。
    (4)    对BCNF关系进行投影,消除原关系中非平凡函数依赖的多值依赖,从而产生一组4NF 
  • 相关阅读:
    javascript深入理解js闭包
    hibernate 之 sql查询
    MongoDB 2.4企业版分析
    MongoDB 连接池
    GridFS实现原理
    MongoVUE破解
    mongodb 官方 手册
    mongodb的一些性能管理工具
    Python: names, values, assignment and mutability
    使用 mock 测试
  • 原文地址:https://www.cnblogs.com/lanzhi/p/6470530.html
Copyright © 2011-2022 走看看