mysql的三大范式解释——转载知乎刘慰老师

做者:刘慰
连接:https://www.zhihu.com/question/24696366/answer/29189700
来源:知乎
著做权归做者全部。商业转载请联系做者得到受权,非商业转载请注明出处。

国内绝大多数院校用的王珊的《数据库系统概论》这本教材,某些方面并无给出很详细很明确的解释,与实际应用联系不那么紧密,你有这样的疑问也是挺正常的。我教《数据库原理》这门课有几年了,有不少学生提出了和你同样的问题,试着给你解释一下吧。(基原本自于我上课的内容,某些地方为了避免过于啰嗦,放弃了必定的严谨,主要是在“关系”和“表”上)数据库

首先要明白”范式(NF)”是什么意思。按照教材中的定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。很晦涩吧?实际上你能够把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材,最环保的是E0级,其次是E1级,还有E2级等等。数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF。通常在咱们设计关系型数据库的时候,最多考虑到BCNF就够。符合高一级范式的设计,一定符合低一级范式,例如符合2NF的关系模式,一定符合1NF。数据库设计

接下来就对每一级范式进行一下解释,首先是第一范式(1NF)。函数

符合1NF的关系(你能够理解为数据表。“关系模式”和“关系”的区别,相似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例,你能够把”关系”理解为一张带数据的表,而“关系模式”是这张数据表的表结构。1NF的定义为:符合1NF的关系中的每一个属性都不可再分。表1所示的状况,就不符合1NF的要求。性能

表1大数据

实际上,1NF是全部关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如SQL Server,Oracle,MySQL中建立数据表的时候,若是数据表的设计不符合这个最基本的要求,那么操做必定是不能成功的。也就是说,只要在RDBMS中已经存在的数据表,必定是符合1NF的。若是咱们要在RDBMS中表现表中的数据,就得设计为表2的形式:设计

表23d

可是仅仅符合1NF的设计,仍然会存在数据冗余过大,插入异常,删除异常,修改异常的问题,例如对于表3中的设计:对象

表3blog

  1. 每一名学生的学号、姓名、系名、系主任这些数据重复屡次。每一个系与对应的系主任的数据也重复屡次——数据冗余过大
  2. 假如学校新建了一个系,可是暂时尚未招收任何学生(好比3月份就新建了,但要等到8月份才招生),那么是没法将系名与系主任的数据单独地添加到数据表中去的 (注1)——插入异常

    注1:根据三种关系完整性约束中实体完整性的要求,关系中的码(注2)所包含的任意一个属性都不能为空,全部属性的组合也不能重复。为了知足此要求,图中的表,只能将学号与课名的组合做为码,不然就没法惟一地区分每一条记录。

    注2:码:关系中的某个属性或者某几个属性的组合,用于区分每一个元组(能够把“元组”理解为一张表中的每条记录,也就是每一行)
  3. 假如将某个系中全部学生相关的记录都删除,那么全部系与系主任的数据也就随之消失了(一个系全部学生都没有了,并不表示这个系就没有了)。——删除异常
  4. 假如李小明转系到法律系,那么为了保证数据库中数据的一致性,须要修改三条记录中系与系主任的数据。——修改异常

正由于仅符合1NF的数据库设计存在着这样那样的问题,咱们须要提升设计标准,去掉致使上述四种问题的因素,使其符合更高一级的范式(2NF),这就是所谓的“规范化”。ip

第二范式(2NF)在关系理论中的严格定义我这里就很少介绍了(由于涉及到的铺垫比较多),只须要了解2NF对1NF进行了哪些改进便可。其改进是,2NF在1NF的基础之上,消除了非主属性对于码的部分函数依赖。接下来对这句话中涉及到的四个概念——“函数依赖”“码”“非主属性”、与“部分函数依赖”进行一下解释。

函数依赖
咱们能够这么理解(但并非特别严格的定义):若在一张表中,在属性(或属性组)X的值肯定的状况下,一定能肯定属性Y的值,那么就能够说Y函数依赖于X,写做 X → Y。也就是说,在数据表中,不存在任意两条记录,它们在X属性(或属性组)上的值相同,而在Y属性上的值不一样。这也就是“函数依赖”名字的由来,相似于函数关系 y = f(x),在x的值肯定的状况下,y的值必定是肯定的。

例如,对于表3中的数据,找不到任何一条记录,它们的学号相同而对应的姓名不一样。因此咱们能够说姓名函数依赖于学号,写做 学号 → 姓名。可是反过来,由于可能出现同名的学生,因此有可能不一样的两条学生记录,它们在姓名上的值相同,但对应的学号不一样,因此咱们不能说学号函数依赖于姓名。表中其余的函数依赖关系还有如:

  • 系名 → 系主任
  • 学号 → 系主任
  • (学号,课名) → 分数

但如下函数依赖关系则不成立:

  • 学号 → 课名
  • 学号 → 分数
  • 课名 → 系主任
  • (学号,课名) → 姓名

从“函数依赖”这个概念展开,还会有三个概念:

彻底函数依赖

在一张表中,若 X → Y,且对于 X 的任何一个真子集(假如属性组 X 包含超过一个属性的话),X ' → Y 不成立,那么咱们称 Y 对于 X 彻底函数依赖,记做 X F→ Y。(那个F应该写在箭头的正上方,没办法打出来……,正确的写法如图1

图1

例如:

  • 学号 F→ 姓名
  • (学号,课名) F→ 分数 (注:由于同一个的学号对应的分数不肯定,同一个课名对应的分数也不肯定)

部分函数依赖

假如 Y 函数依赖于 X,但同时 Y 并不彻底函数依赖于 X,那么咱们就称 Y 部分函数依赖于 X,记做 X P→ Y,如图2

 

图2

 

例如:

  • (学号,课名) P→ 姓名

 

传递函数依赖
假如 Z 函数依赖于 Y,且 Y 函数依赖于 X (感谢

指出的错误,这里改成:『Y 不包含于 X,且 X 不函数依赖于 Y』这个前提),那么咱们就称 Z 传递函数依赖于 X ,记做 X T→ Z,如 图3

 

图3


设 K 为某表中的一个属性或属性组,若除 K 以外的全部属性都彻底函数依赖于 K(这个“彻底”不要漏了),那么咱们称 K 为候选码,简称为。在实际中咱们一般能够理解为:假如当 K 肯定的状况下,该表除 K 以外的全部属性的值也就随之肯定,那么 K 就是码。一张表中能够有超过一个码。(实际应用中为了方便,一般选择其中的一个码做为主码

例如:
对于表3,(学号、课名)这个属性组就是码。该表中有且仅有这一个码。(假设全部课没有重名的状况)

非主属性
包含在任何一个码中的属性成为主属性。

例如:
对于表3,主属性就有两个,学号课名

 

终于能够回过来看2NF了。首先,咱们须要判断,表3是否符合2NF的要求?根据2NF的定义,判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在,则数据表最高只符合1NF的要求,若不存在,则符合2NF的要求。判断的方法是:

第一步:找出数据表中全部的
第二步:根据第一步所获得的码,找出全部的主属性
第三步:数据表中,除去全部的主属性,剩下的就都是非主属性了。
第四步:查看是否存在非主属性对码的部分函数依赖

对于表3,根据前面所说的四步,咱们能够这么作:

第一步:

  1. 查看全部每一单个属性,当它的值肯定了,是否剩下的全部属性值都能肯定。
  2. 查看全部包含有两个属性的属性组,当它的值肯定了,是否剩下的全部属性值都能肯定。
  3. ……
  4. 查看全部包含了六个属性,也就是全部属性的属性组,当它的值肯定了,是否剩下的全部属性值都能肯定。

看起来很麻烦是吧,可是这里有一个诀窍,就是假如A是码,那么全部包含了A的属性组,如(A,B)、(A,C)、(A,B,C)等等,都不是码了(由于做为码的要求里有一个“彻底函数依赖”)。

图4表示了表中全部的函数依赖关系:

图4

这一步完成之后,能够获得,表3的码只有一个,就是(学号、课名)

第二步:
主属性有两个:学号 课名

 

第三步:
非主属性有四个:姓名系名系主任分数

 

第四步:
对于(学号,课名) → 姓名,有 学号 → 姓名,存在非主属性 姓名 对码(学号,课名)的部分函数依赖。
对于(学号,课名) → 系名,有 学号 → 系名,存在非主属性 系对码(学号,课名)的部分函数依赖。
对于(学号,课名) → 系主任,有 学号 → 系主任,存在非主属性 对码(学号,课名)的部分函数依赖。

因此表3存在非主属性对于码的部分函数依赖,最高只符合1NF的要求,不符合2NF的要求。

 

 

为了让表3符合2NF的要求,咱们必须消除这些部分函数依赖,只有一个办法,就是将大数据表拆分红两个或者更多个更小的数据表,在拆分的过程当中,要达到更高一级范式的要求,这个过程叫作”模式分解“。模式分解的方法不是惟一的,如下是其中一种方法:
选课(学号,课名,分数)
学生(学号,姓名,系名,系主任)

咱们先来判断如下,选课表与学生表,是否符合了2NF的要求?

对于选课表,其码是(学号,课名),主属性是学号课名,非主属性是分数学号肯定,并不能惟一肯定分数课名肯定,也不能惟一肯定分数,因此不存在非主属性分数对于码 (学号,课名)的部分函数依赖,因此此表符合2NF的要求。

对于学生表,其码是学号,主属性是学号,非主属性是姓名、系名系主任,由于码只有一个属性,因此不可能存在非主属性对于码 的部分函数依赖,因此此表符合2NF的要求。

图5表示了模式分解之后的新的函数依赖关系

图5

表4表示了模式分解之后新的数据

 

表4

(这里还涉及到一个如何进行模式分解才是正确的知识点,先不介绍了)

如今咱们来看一下,进行一样的操做,是否还存在着以前的那些问题?

  1. 李小明转系到法律系
    只须要修改一次李小明对应的系的值便可。——有改进
  2. 数据冗余是否减小了?
    学生的姓名、系名与系主任,再也不像以前同样重复那么屡次了。——有改进
  3. 删除某个系中全部的学生记录
    该系的信息仍然所有丢失。——无改进
  4. 插入一个尚无学生的新系的信息。
    由于学生表的码是学号,不能为空,因此此操做不被容许。——无改进

因此说,仅仅符合2NF的要求,不少状况下仍是不够的,而出现问题的缘由,在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题,咱们还须要将符合2NF要求的数据表改进为符合3NF的要求。

第三范式(3NF) 3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。也就是说, 若是存在非主属性对于码的传递函数依赖,则不符合3NF的要求。

接下来咱们看看表4中的设计,是否符合3NF的要求。

对于选课表,主码为(学号,课名),主属性为学号课名,非主属性只有一个,为分数,不可能存在传递函数依赖,因此选课表的设计,符合3NF的要求。

对于学生表,主码为学号,主属性为学号,非主属性为姓名系名系主任。由于 学号 → 系名,同时 系名 → 系主任,因此存在非主属性系主任对于码学号的传递函数依赖,因此学生表的设计,不符合3NF的要求。。

为了让数据表设计达到3NF,咱们必须进一步进行模式分解为如下形式:
选课(学号,课名,分数)
学生(学号,姓名,系名)
系(系名,系主任)

对于选课表,符合3NF的要求,以前已经分析过了。

对于学生表,码为学号,主属性为学号,非主属性为系名,不可能存在非主属性对于码的传递函数依赖,因此符合3NF的要求。

对于表,码为系名,主属性为系名,非主属性为系主任,不可能存在非主属性对于码的传递函数依赖(至少要有三个属性才可能存在传递函数依赖关系),因此符合3NF的要求。。

 

新的函数依赖关系如图6

图6

新的数据表如表5

 

表5

 

如今咱们来看一下,进行一样的操做,是否还存在着以前的那些问题?

  1. 删除某个系中全部的学生记录
    该系的信息不会丢失。——有改进
  2. 插入一个尚无学生的新系的信息。
    由于系表与学生表目前是独立的两张表,因此不影响。——有改进
  3. 数据冗余更加少了。——有改进

 

结论
因而可知,符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题。固然,在实际中,每每为了性能上或者应对扩展的须要,常常 作到2NF或者1NF,可是做为数据库设计人员,至少应该知道,3NF的要求是怎样的。

==============时隔半年,终于决定把这个坑填上,来晚了 ===========

BCNF范式

要了解 BCNF 范式,那么先看这样一个问题:

若:

  1. 某公司有若干个仓库;
  2. 每一个仓库只能有一名管理员,一名管理员只能在一个仓库中工做;
  3. 一个仓库中能够存放多种物品,一种物品也能够存放在不一样的仓库中。每种物品在每一个仓库中都有对应的数量。

那么关系模式 仓库(仓库名,管理员,物品名,数量) 属于哪一级范式?

答:已知函数依赖集:仓库名 → 管理员,管理员 → 仓库名,(仓库名,物品名)→ 数量
码:(管理员,物品名),(仓库名,物品名)
主属性:仓库名、管理员、物品名
非主属性:数量
∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF。

基于此关系模式的关系(具体的数据)可能如图所示:

 

 

好,既然此关系模式已经属于了 3NF,那么这个关系模式是否存在问题呢?咱们来看如下几种操做:

  1. 先新增长一个仓库,但还没有存听任何物品,是否能够为该仓库指派管理员?——不能够,由于物品名也是主属性,根据实体完整性的要求,主属性不能为空。
  2. 某仓库被清空后,须要删除全部与这个仓库相关的物品存放记录,会带来什么问题?——仓库自己与管理员的信息也被随之删除了。
  3. 若是某仓库更换了管理员,会带来什么问题?——这个仓库有几条物品存放记录,就要修改多少次管理员信息。

从这里咱们能够得出结论,在某些特殊状况下,即便关系模式符合 3NF 的要求,仍然存在着插入异常,修改异常与删除异常的问题,仍然不是 ”好“ 的设计。

形成此问题的缘由:存在着主属性对于码的部分函数依赖与传递函数依赖。(在此例中就是存在主属性【仓库名】对于码【(管理员,物品名)】的部分函数依赖。

解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

仓库(仓库名,管理员)
库存(仓库名,物品名,数量)

这样,以前的插入异常,修改异常与删除异常的问题就被解决了。

以上就是关于 BCNF 的解释。

 

最近身体不太舒服,写不动了。有空再放几个典型习题及其解答吧。
===============================
问题1:

李德竹 :老师您好,我看了您关于数据库范式的回答,有一点不太理解,就是关于码的定义,若是除K以外的全部属性都彻底函数依赖于K时才能称K为码,那么在判断2NF时又怎么会存在非主属性对码的部分函数依赖这种状况?但愿老师有时间能指点一下,谢谢

我 :在“码”的定义中,除 K 以外的全部属性应该当作是一个集合 U(也就是一个总体),也就是说,只有 K 可以彻底函数决定 U 中的每个属性,那么 K 才是码。若是 K 只是可以彻底函数决定 U 中的一部分属性,而不能彻底函数决定另一部分属性,那么 K 不是码。

好比有关系模式 R (Sno, Sname, Cno, Cname, Sdept, Sloc, Grade),其中函数依赖集为 F= {
Sno → Sname, Sno → Sdept, Sdept → Sloc,Sno → Sloc, Cno → Cname, (Sno, Cno) → Grade }

那么 R 中的码只能是 (Sno, Cno),Sno 或 Cno 并不能彻底函数决定除 Sno / Cno 以外的全部其余属性(其实就是不能决定 Grade ),因此单独的 Sno 与 Cno 并不能做为码。

因此可获得主属性:Sno, Cno
非主属性:Sname, Cname, Sdept, Sloc, Grade

R 中存在非主属性 Cname 对于码 (Sno, Cno) 的部分函数依赖 (Cno → Cname) 。(还有不少别的例子就不一一列举了)。因此 R 不符合 2NF 的要求。

========================================

花了好几天断断续续写了这个答案,累死我了。看有很多人对此有疑问,干脆写一个详细点的,但愿成为这个知识点的权威回答……若是有一些细节方面的问题,好比表达上,还会进行修改,大的方面,确定是没错的。

相关文章
相关标签/搜索