数据库设计的三大范式——明确概念和通俗理解

一、数据库名词

在理解三大范式之前,我们先明确一下数据库一些名词的概念,方便我们之后的理解。

  • 实体——某类事物的集合,每一类数据对象的个体称为实体
  • 属性——实体的一个特征,也称之为字段,数据库表中的列
  • 元组——实体所有属性构成的集合,数据库表中的一行信息
  • 关系——实体的元组构成的集合,数据库的表
  • 码——码就是能唯一标识实体的属性。他是整个实体集的性质,而不是单个实体的性质。它包括超码,候选码,主码。
  • 超码——一个或多个属性的集合,能唯一标识一个实体,即能找到数据库中唯一的一列信息
  • 候选码——超码的其中一种。候选码是最小的超码,候选码的任何一个真子集都不能成为超码
  • 主码——也成为主属性,主键。被数据库设计者选中的,用来在同一实体集中区分不同实体的候选码

以下图为例对这些概念进行解释
在这里插入图片描述

  • 学生为实体
  • 学生的学号、姓名等成为属性(字段)。在数据库表中属性包括属性名,属性类型,属性值,值类型。如第一条数据的姓名属性,他的属性名为姓名,属性类型为非主属性,属性值为徐三,值类型为varchar。这里详细描述是像告诉大家属性不单单是指姓名这两个字,而是包含更多的内容。
  • 整个表即是一个关系,表中的每一行数据为一个元组
  • 超码:{学号}、{身份证号}、{学号、身份证号}、{学号、姓名}、{学号、院系}、{学号、身份证号、姓名、院系}等等都是超码,它们的集合都能唯一的标识一条数据,但是超码中可能会有一些冗余信息,比如
    {学号、身份证号、姓名、院系}中姓名和院系都是冗余信息 ,甚至学号和身份证号中的其中一个也可视作冗余信息
  • 候选码:最小的超码,也就是去除了冗余信息,其真子集不是超码,如{学号}、{院系}。假设每个班级学生的姓名时唯一的,{院系、班级、姓名}也能构成一个候选码,他的真子集{学院}、{班级}、{姓名}、{学院、姓名}、{班级、姓名}、{学院、班级}都无法标识一条数据。
  • 主码 :这里我们可以选用{学号}、{身份证号}两个其一都可以作为主码

二、三大范式

第一范式

当关系模式R的所有属性都不能在分解为更基本的数据单位时,称R是满足第一范式的,简记为1NF。

假设学生表如下则不满足第一范式,院系和班级信息可再分
在这里插入图片描述

简单理解:属性不可再分
第二范式

如果关系模式R满足第一范式,并且R得所有非主属性都完全依赖于R的每一个候选关键属性,称R满足第二范式,简记为2NF。

假设有一张成绩表如下则不满足第二范式
在这里插入图片描述
该表的主码为{学号、科目},通过主码能唯一的标识一条数据,但是该条数据中的姓名是依赖学号找出的,而与科目属性无关,即姓名属性没有完全依赖于候选码的每一个属性,不满足第二范式。修改为两张表
在这里插入图片描述

简单理解:所有非主属性只能通过主键的属性集合查询出,不能通过主键的真子集属性(一个或多个不完全包含于主键的属性)查询出

第三范式

设R是一个满足第一范式条件的关系模式,X是R的任意属性集,如果X非传递依赖于R的任意一个候选关键字,称R满足第三范式,简记为3NF。

假设有一张学生表如下则不满足第三范式
在这里插入图片描述
设此表主键为{学号},所有属性都完全依赖于学号,所以满足第二范式。但学院说在地址可以通过院系查出,即学院所在地址属性直接依赖于院系,传递依赖于学号。

将它改成两张表

在这里插入图片描述
但从姓名属性来考虑,我认为他既可以看作直接依赖于主键学号,也可以看作直接依赖于身份证号,传递依赖于学号,此时它就不满足第三范式。

但数据库设计允许部分冗余,一般要求设计至少达到第二范式,这里可以不做修改。

简单理解:所有非主属性只能通过主键查出,不能通过非主属性查出

三、总结

  • 第一范式要求字段必须具有原子性。
    ——即属性不可再分。
  • 第二范式要求非主属性不能部分依赖于码。
    ——即所有非主属性只能通过主属性的属性集合查询出,不能通过主属性的真子集属性(一个或多个不完全包含于主键的属性)查询出
  • 第三范式要求非主属性既不部分依赖于码也不传递依赖于码。
    ——即所有非主属性只能通过主属性查出,不能通过非主属性查出
发布了35 篇原创文章 · 获赞 7 · 访问量 4万+

猜你喜欢

转载自blog.csdn.net/weixin_44804750/article/details/105121306