国内绝大多数院校用的王珊的《数据库系统概论》这本教材,某些方面并无给出很详细很明确的解释,与实际应用联系不那么紧密,你有这样的疑问也是挺正常的。我教《数据库原理》这门课有几年了,有不少学生提出了和你同样的问题,试着给你解释一下吧。(基原本自于我上课的内容,某些地方为了避免过于啰嗦,放弃了必定的严谨,主要是在“关系”和“表”上)数据库
首先要明白”范式(NF)”是什么意思。按照教材中的定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。很晦涩吧?实际上你能够把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材,最环保的是E0级,其次是E1级,还有E2级等等。数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF。通常在咱们设计关系型数据库的时候,最多考虑到BCNF就够。符合高一级范式的设计,一定符合低一级范式,例如符合2NF的关系模式,一定符合1NF。架构
接下来就对每一级范式进行一下解释,首先是第一范式(1NF)。数据库设计
符合1NF的关系(你能够理解为数据表。“关系模式”和“关系”的区别,相似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例,你能够把”关系”理解为一张带数据的表,而“关系模式”是这张数据表的表结构。1NF的定义为:符合1NF的关系中的每一个属性都不可再分。表1所示的状况,就不符合1NF的要求。ide
表1函数
实际上,1NF是全部关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如SQL Server,Oracle,MySQL中建立数据表的时候,若是数据表的设计不符合这个最基本的要求,那么操做必定是不能成功的。也就是说,只要在RDBMS中已经存在的数据表,必定是符合1NF的。若是咱们要在RDBMS中表现表中的数据,就得设计为表2的形式:性能
表2学习
可是仅仅符合1NF的设计,仍然会存在数据冗余过大,插入异常,删除异常,修改异常的问题,例如对于表3中的设计:大数据
表3编码
正由于仅符合1NF的数据库设计存在着这样那样的问题,咱们须要提升设计标准,去掉致使上述四种问题的因素,使其符合更高一级的范式(2NF),这就是所谓的“规范化”。spa
第二范式(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
例如:
部分函数依赖
假如 Y 函数依赖于 X,但同时 Y 并不彻底函数依赖于 X,那么咱们就称 Y 部分函数依赖于 X,记做 X P→ Y,如图2。
图2
例如:
传递函数依赖
假如 Z 函数依赖于 Y,且 Y 函数依赖于 X (感谢
图3
码
设 K 为某表中的一个属性或属性组,若除 K 以外的全部属性都彻底函数依赖于 K(这个“彻底”不要漏了),那么咱们称 K 为候选码,简称为码。在实际中咱们一般能够理解为:假如当 K 肯定的状况下,该表除 K 以外的全部属性的值也就随之肯定,那么 K 就是码。一张表中能够有超过一个码。(实际应用中为了方便,一般选择其中的一个码做为主码)
例如:
对于表3,(学号、课名)这个属性组就是码。该表中有且仅有这一个码。(假设全部课没有重名的状况)
非主属性
包含在任何一个码中的属性成为主属性。
例如:
对于表3,主属性就有两个,学号 与 课名。
终于能够回过来看2NF了。首先,咱们须要判断,表3是否符合2NF的要求?根据2NF的定义,判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在,则数据表最高只符合1NF的要求,若不存在,则符合2NF的要求。判断的方法是:
第一步:找出数据表中全部的码。
第二步:根据第一步所获得的码,找出全部的主属性。
第三步:数据表中,除去全部的主属性,剩下的就都是非主属性了。
第四步:查看是否存在非主属性对码的部分函数依赖。
对于表3,根据前面所说的四步,咱们能够这么作:
第一步:
看起来很麻烦是吧,可是这里有一个诀窍,就是假如A是码,那么全部包含了A的属性组,如(A,B)、(A,C)、(A,B,C)等等,都不是码了(由于做为码的要求里有一个“彻底函数依赖”)。
图4表示了表中全部的函数依赖关系:
图4
这一步完成之后,能够获得,表3的码只有一个,就是(学号、课名)。
第二步:
主属性有两个:学号 与 课名
第三步:
非主属性有四个:姓名、系名、系主任、分数
第四步:
对于(学号,课名) → 姓名,有 学号 → 姓名,存在非主属性 姓名 对码(学号,课名)的部分函数依赖。
对于(学号,课名) → 系名,有 学号 → 系名,存在非主属性 系名 对码(学号,课名)的部分函数依赖。
对于(学号,课名) → 系主任,有 学号 → 系主任,存在非主属性 对码(学号,课名)的部分函数依赖。
因此表3存在非主属性对于码的部分函数依赖,最高只符合1NF的要求,不符合2NF的要求。
为了让表3符合2NF的要求,咱们必须消除这些部分函数依赖,只有一个办法,就是将大数据表拆分红两个或者更多个更小的数据表,在拆分的过程当中,要达到更高一级范式的要求,这个过程叫作”模式分解“。模式分解的方法不是惟一的,如下是其中一种方法:
选课(学号,课名,分数)
学生(学号,姓名,系名,系主任)
咱们先来判断如下,选课表与学生表,是否符合了2NF的要求?
对于选课表,其码是(学号,课名),主属性是学号和课名,非主属性是分数,学号肯定,并不能惟一肯定分数,课名肯定,也不能惟一肯定分数,因此不存在非主属性分数对于码 (学号,课名)的部分函数依赖,因此此表符合2NF的要求。
对于学生表,其码是学号,主属性是学号,非主属性是姓名、系名和系主任,由于码只有一个属性,因此不可能存在非主属性对于码 的部分函数依赖,因此此表符合2NF的要求。
图5表示了模式分解之后的新的函数依赖关系
图5
表4表示了模式分解之后新的数据
表4
(这里还涉及到一个如何进行模式分解才是正确的知识点,先不介绍了)
如今咱们来看一下,进行一样的操做,是否还存在着以前的那些问题?
因此说,仅仅符合2NF的要求,不少状况下仍是不够的,而出现问题的缘由,在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题,咱们还须要将符合2NF要求的数据表改进为符合3NF的要求。
第三范式(3NF) 3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。也就是说, 若是存在非主属性对于码的传递函数依赖,则不符合3NF的要求。
接下来咱们看看表4中的设计,是否符合3NF的要求。
对于选课表,主码为(学号,课名),主属性为学号和课名,非主属性只有一个,为分数,不可能存在传递函数依赖,因此选课表的设计,符合3NF的要求。
对于学生表,主码为学号,主属性为学号,非主属性为姓名、系名和系主任。由于 学号 → 系名,同时 系名 → 系主任,因此存在非主属性系主任对于码学号的传递函数依赖,因此学生表的设计,不符合3NF的要求。。
为了让数据表设计达到3NF,咱们必须进一步进行模式分解为如下形式:
选课(学号,课名,分数)
学生(学号,姓名,系名)
系(系名,系主任)
对于选课表,符合3NF的要求,以前已经分析过了。
对于学生表,码为学号,主属性为学号,非主属性为系名,不可能存在非主属性对于码的传递函数依赖,因此符合3NF的要求。
对于系表,码为系名,主属性为系名,非主属性为系主任,不可能存在非主属性对于码的传递函数依赖(至少要有三个属性才可能存在传递函数依赖关系),因此符合3NF的要求。。
新的函数依赖关系如图6
图6
新的数据表如表5
表5
如今咱们来看一下,进行一样的操做,是否还存在着以前的那些问题?
结论
因而可知,符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题。固然,在实际中,每每为了性能上或者应对扩展的须要,常常 作到2NF或者1NF,可是做为数据库设计人员,至少应该知道,3NF的要求是怎样的。
==============时隔半年,终于决定把这个坑填上,来晚了 ===========
BCNF范式
要了解 BCNF 范式,那么先看这样一个问题:
若:
那么关系模式 仓库(仓库名,管理员,物品名,数量) 属于哪一级范式?
答:已知函数依赖集:仓库名 → 管理员,管理员 → 仓库名,(仓库名,物品名)→ 数量
码:(管理员,物品名),(仓库名,物品名)
主属性:仓库名、管理员、物品名
非主属性:数量
∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。∴ 此关系模式属于3NF。
基于此关系模式的关系(具体的数据)可能如图所示:
好,既然此关系模式已经属于了 3NF,那么这个关系模式是否存在问题呢?咱们来看如下几种操做:
从这里咱们能够得出结论,在某些特殊状况下,即便关系模式符合 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 的要求。
========================================
花了好几天断断续续写了这个答案,累死我了。看有很多人对此有疑问,干脆写一个详细点的,但愿成为这个知识点的权威回答……若是有一些细节方面的问题,好比表达上,还会进行修改,大的方面,确定是没错的。
谢邀。
这个问题不太好解释,我尽力吧!
一范式就是属性不可分割。属性是什么?就是表中的字段。
不可分割的意思就按字面理解就是最小单位,不能再分红更小单位了。
这个字段只能是一个值,不能被拆分红多个字段,不然的话,它就是可分割的,就不符合一范式。
不过能不能分割并无绝对的答案,看需求,也就是看你的设计目标而定。
举例:
学生信息组成学生信息表,有姓名、年龄、性别、学号等信息组成。
姓名不可拆分吧?因此能够做为该表的一个字段。
但我要说这个表要在国外使用呢?人家姓和名要分开,都有特别的意义,因此姓名字段是可拆分的,分为姓字段和名字段。
简单来讲,一范式是关系数据库的基础,但字段是否真的不可拆分,根据你的设计目标而定。
二范式就是要有主键,要求其余字段都依赖于主键。
为何要有主键?没有主键就没有惟一性,没有惟一性在集合中就定位不到这行记录,因此要主键。
其余字段为何要依赖于主键?由于不依赖于主键,就找不到他们。更重要的是,其余字段组成的这行记录和主键表示的是同一个东西,而主键是惟一的,它们只须要依赖于主键,也就成了惟一的。
若是有同窗不理解依赖这个词,能够勉强用“相关”这个词代替,也就是说其余字段必须和它们的主键相关。由于不相关的东西不该该放在一行记录里。
举例:
学生信息组成学生表,姓名能够作主键么?
不能!由于同名的话,就不惟一了,因此须要学号这样的惟一编码才行。
那么其余字段依赖于主键是什么意思?
就是“张三”同窗的年龄和性别等字段,不能存储别人的年龄性别,必须是他本身的,由于张三的学号信息就决定了,这行记录归张三全部,不能给无关人员使用。
三范式就是要消除传递依赖,方便理解,能够看作是“消除冗余”。
消除冗余应该比较好理解一些,就是各类信息只在一个地方存储,不出如今多张表中。
好比说大学分了不少系(中文系、英语系、计算机系……),这个系别管理表信息有如下字段组成:
系编号,系主任,系简介,系架构。
那么再回到学生信息表,张三同窗的年龄、性别、学号都有了,我能不能把他的系编号,系主任、系简介也一块儿存着?
若是你问三范式,固然不行,由于三范式不一样意。
由于系编号,系主任、系简介已经存在系别管理表中,你再存入学生信息表,就是冗余了。
三范式中说的传递依赖,就出现了。
这个时候学生信息表中,系主任信息是否是依赖于系编号了?而这个表的主键但是学号啊!
因此按照三范式,处理这个问题的时候,学生表就只能增长一个系编号字段。
这样既能根据系编号找到系别信息,又避免了冗余存储的问题。
所谓的范式,是用来学习参考的,设计的时候根据状况,未必必定要遵照,切记。
三范式都能码这么多字,我果真愈来愈水了:)