zoukankan      html  css  js  c++  java
  • 数据库三大范式

    1 第一范式(1NF)

        所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如 果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一 个实例的信息。

    如下例子,上面不满足第一范式,下面满足:

       

    2 第二范式(2NF)(实体的属性完全依赖于主关键字)

        第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表 中的每个实例或行必须可以被惟一地区分。
    第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主 关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而 言之,第二范式就是非主属性非部分依赖于主关键字。

    选课表(学号, 姓名, 年龄, 课程名称, 成绩, 学分)

    关键字(学号, 课程名称)

    这个数据库表不满足第二范式,因为存在如下决定关系:
        (课程名称) → (学分)
        (学号) → (姓名, 年龄)
        即存在组合关键字中的字段决定非关键字的情况。

        由于不符合2NF,这个选课关系表会存在如下问题:
        (1) 数据冗余:
        同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。
        (2) 更新异常:
        若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。
        (3) 插入异常:
        假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。
        (4) 删除异常:
        假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。

        把选课关系表SelectCourse改为如下三个表:
        学生:Student(学号, 姓名, 年龄);
        课程:Course(课程名称, 学分);
        选课关系:SelectCourse(学号, 课程名称, 成绩)。

        这样的数据库表是符合第二范式的, 消除了数据冗余、更新异常、插入异常和删除异常。

    3 第三范式(3NF)(属性不依赖于其它非主属性)

        满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

    假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话),关键字为单一关键字"学号",因为存在如下决定关系:
        (学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)

        这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:
        (学号) → (所在学院) → (学院地点, 学院电话)
        即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
       
        它也会存在数据冗余、更新异常、插入异常和删除异常的情况,读者可自行分析得知。
        把学生关系表分为如下两个表:
        学生:(学号, 姓名, 年龄, 所在学院);
        学院:(学院, 地点, 电话)。      这样的数据库表是符合第三范式的,消除了数据冗余、更新异常、插入异常和删除异常。

    4、BCNF范式

    在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

    假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:
        (仓库ID, 存储物品ID) →(管理员ID, 数量)
        (管理员ID, 存储物品ID) → (仓库ID, 数量)
        所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:
        (仓库ID) → (管理员ID)
        (管理员ID) → (仓库ID)
        即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况:
        (1) 删除异常:
        当仓库被清空后,所有"存储物品ID"和"数量"信息被删除的同时,"仓库ID"和"管理员ID"信息也被删除了。
        (2) 插入异常:
        当仓库没有存储任何物品时,无法给仓库分配管理员。
        (3) 更新异常:
        如果仓库换了管理员,则表中所有行的管理员ID都要修改。

        把仓库管理关系表分解为二个关系表:
        仓库管理:StorehouseManage(仓库ID, 管理员ID);
        仓库:Storehouse(仓库ID, 存储物品ID, 数量)。
        这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。

       

  • 相关阅读:
    拯救祭天的程序员——事件溯源模式
    啥?SynchronousQueue和钟点房一个道理
    程序员应该掌握的一些 Linux 命令
    Linux 环境下使用 sqlplus 访问远程 Oracle 数据库
    我对鸿蒙OS的一些看法
    我对技术潮流的一些看法
    git merge --ff/--no-ff/--ff-only 三种选项参数的区别
    go语言的初体验
    完全使用 VSCode 开发的心得和体会
    重复代码的克星,高效工具 VSCode snippets 的使用指南
  • 原文地址:https://www.cnblogs.com/suizi/p/3096316.html
Copyright © 2011-2022 走看看