快捷搜索:
来自 网络数据库 2019-07-30 00:20 的文章
当前位置: 67677新澳门手机版 > 网络数据库 > 正文

数据库设计中国共产党第五次全国代表大会范式

  1. 第一范式(1NF)

范式(数据库设计范式,数据库的设计范式)是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中,这种规则就是范式。关系数据库中的关系必须满足一定的要求,即满足不同的范式。

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、Boyce-Codd范式(BCNF)、第四范式(4NF)和第五范式(5NF)。

满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。

      强调的是列的原子性,即列不能够再分成其他几列。
      考虑这样一个表:【联系人】(姓名,性别,电话)
      如果在实际场景中,一个联系人有家庭电话和公司电话,那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列(电话)拆分,即:【联系人】(姓名,性别,家庭电话,公司电话)。1NF 很好辨别,但是 2NF 和 3NF 就容易搞混淆。

第一范式

每一列不可分割。是对关系模式的最基本要求。不满足1NF的数据库就不是关系数据库。

2.第二范式( 2NF )

第二范式

非主属性完全依赖于主属性,不能存在只依赖主属性一部分的属性。
假定选课关系表为SelectCourse(学号,姓名,年龄,课程名称,成绩,学分),关键字为组合关键字(学号,课程名称),因为存在如下决定关系:
(学号,课程名称) → (姓名,年龄,成绩,学分)
这个数据库表不满足第二范式,因为存在如下决定关系:
(课程名称) → (学分)
(学号) → (姓名,年龄)
即存在组合关键字中的字段决定非关键字的情况。
由于不符合2NF,这个选课关系表会存在如下问题:

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

      所谓第二范式,是指所有的非主属性都完全依赖于关键字。从这个定义可以看出,第二范式不存在非主属性对于部分候选关键字的部分依赖,不过允许非主属性之间存在着传递依赖。

第三范式

每列数据都和主键直接相关,不能传递依赖于主键。
假定学生关系表为Student(学号,姓名,年龄,所在学院,学院地点,学院电话),关键字为单一关键字"学号",因为存在如下决定关系:
(学号) → (姓名,年龄,所在学院,学院地点,学院电话)
这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:
(学号) → (所在学院) → (学院地点,学院电话)
即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况。

把学生关系表分为如下两个表:
学生:(学号,姓名,年龄,所在学院);
学院:(学院,地点,电话)。
这样的数据库表是符合第三范式的,消除了数据冗余、更新异常、插入异常和删除异常。

      下面是第二范式的优化实例:

BCNF

在3NF基础上消除主属性对于码的部分与传递函数依赖。

假设仓库管理关系表为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范式的,消除了删除异常、插入异常和更新异常。

      假定选课关系表为SelectCourse(学号,姓名,年龄,课程名称,成绩,学分),关键字为组合关键字(学号,课程名称),因为存在如下决定关系:

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

  这个数据库表不满足第二范式,因为存在如下决定关系:

  (课程名称) → (学分)

  (学号) → (姓名,年龄)

  即存在组合关键字中的字段决定非关键字的情况。

  由于不符合2NF,这个选课关系表会存在如下问题:

  (1) 数据冗余:

  同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。

  (2) 更新异常:

  若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。

  (3) 插入异常:

  假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。

  (4) 删除异常:

  假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。

  把选课关系表SelectCourse改为如下三个表:

  学生:Student(学号,姓名,年龄);

  课程:Course(课程名称,学分);

  选课关系:SelectCourse(学号,课程名称,成绩)。

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

  另外,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字。

3、第三范式(3NF)

      所谓第三范式,是指每一个非主属性既不部分依赖于也不传递依赖于关键字,也就是在第二范式的基础上消除传递依赖(A>B>C)。

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

  (学号) → (姓名,年龄,所在学院,学院地点,学院电话)

  这个数据库是符合2NF的,但是不符合3NF,因为存在如下决定关系:

  (学号) → (所在学院) → (学院地点,学院电话)

  即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。

  它也会存在数据冗余、更新异常、插入异常和删除异常的情况,读者可自行分析得知。

  把学生关系表分为如下两个表:

  学生:(学号,姓名,年龄,所在学院);

  学院:(学院,地点,电话)。

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

4、BCNF

      所谓BCNF,是指在第三范式的基础上进一步消除主属性对于码的部分函数依赖和传递依赖。BCNF需要符合3NF,并且,主属性不依赖于主属性。

      假设仓库管理关系表为StorehouseManage(仓库ID,存储物品ID,管理员ID,数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:

  (仓库ID,存储物品ID) →(管理员ID,数量)

  (管理员ID,存储物品ID) → (仓库ID,数量)

  所以,(仓库ID,存储物品ID)和(管理员ID,存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

  (仓库ID) → (管理员ID)

本文由67677新澳门手机版发布于网络数据库,转载请注明出处:数据库设计中国共产党第五次全国代表大会范式

关键词: