数据库范式--另类理解

以下，关键字就是只候选关键字或候选码，另外以下纯属个人理解，可能有误。

第一范式略：（就是指无重复的列）【确保每列保持原子性】

第二范式：【不能部分依赖。简单来说就是确保表中的每列都和主键完全相关，而不能只与主键的某一部分相关。】

第二范式建立在第一范式的基础之上。其定义为，数据库表中不存在非关键列对任一关键字的部分函数依赖，也即所有非关键列都完全依赖于任意一个关键字。

例如，学生选课表的结构设计为（学号, 姓名, 年龄, 所选课程, 课程学分）。那么对于学生选课表来说，（学号, 课程）是表的候选码，是表的唯一标识，

即（学号, 课程）------->(姓名, 年龄, 课程学分)。

但是，这存在着非常大的缺陷。因为表中仍然存在如下依赖关系：（学号）------->（姓名, 年龄）和（所选课程）------->（课程学分），这两种依赖方式均为非关键列对关键字的部分依赖。

 

第三范式：【不能传递依赖。简单来说就是确保每列都和主键列直接相关，而不是间接相关】

第三范式建立在第二范式的基础之上。其定义为，数据表中如果不存在非关键列对任一关键字的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在

"A -------> B -------> C"的决定关系，则C传递函数依赖于A。

假如学生表被定义为（学号, 姓名, 年龄, 学院, 学院电话, 学院地址）。毫无疑问，该表符合第二范式，表的关键字为学号，其他列均为非关键字，并不存在部分依赖。但是，存在着如下依赖关系（学院）------->（学院电话, 学院地址）。而又有（学号）------->(学院)，这样就产生了传递依赖：(学号)------->(学院)------->（学院电话, 学院地址)。

同样，存在传递函数依赖，也会导致数据冗余、更新异常、删除异常和插入异常。

 

BCNF范式是建立在第三范式的基础之上，并具有了更加严格的限制。在讲述了三大范式之后，我们首先从企业架构的角度，反向推导BCNF范式的规则。

在第二、第三范式中，分别针对普通员工与领导班子，不能产生部分依赖和传递依赖的角度进行了约束。那么，当一个企业只有一个领导班子的情况下，所有的情况下均被考虑在内了。但是，如果该企业有多个领导班子，相当于表具有多个关键字（一个主关键字和多个关键字），那么这些班子之间也不能存在部分依赖。这就是BCNF范式。

 

总结：在判断是否满足第二或第三范式的时候，多个候选关键字（关键字）之间分开来分别判断，从定义也可以看出都必须满足“非关键列”对“任一关键字”的要求，所以判断时先判断某一个关键字是否满足而不管其他关键字，然后在判断其他关键字。（物理学上的隔离考虑方式）

如果从领导和平民的角度判断，可以这样理解：

第二范式：集体领导制，既不能是领导组中的一部分人具有领导平民的能力。

第三范式：单一领导制（愚民领导制），即平民总是相互隔离，没有文化，互相之间从不联系，所以平民绝不能听从另一个平民，而只听从领导集体。

BCNF范式：互相制衡，即各个领导组之间互相制衡，每一个领导组对其他领导组来说，都不能是个人英雄主义。

 

我们最常遇到的是不满足第三范式，因为最常见到的表都只有一个单一的主键，即ID，所以不存在领导组，就肯定满足第二范式和BCNF范式。例如班级学生信息表好班级信息表融合成一个表的情况。也就是一对多的情况，大部分都不满足第三范式，应使用外键拆分成两个表。

 

关于不满足第二范式的情况，可以想象一下原来两个完全没任何联系的两个表硬要融合成一个表，然后添加一列“联系”以表示这两个表建立了新联系，即把原来两个表的ID挑出来组成一个领导组（组合在一起形成关键字），最后再加一个“联系”列，它肯定不满足第二范式，所以不满足第二范式的情况，可以考虑拆分成两个没任何关系的表，对于一定要让这两个表之间产生联系，可以新建一个表。这就是典型的“多对多”关系情况，所以多对多的情况，大部分不满足第二范式。

 

 

 

下面内容摘自网络，便于详细理解三个范式：

1、关系数据库设计范式介绍

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

说明：在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

1.2 第二范式（2NF）属性完全依赖于主键[消除部分子函数依赖]
      第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
        第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是属性完全依赖于主键。

1.3 第三范式（3NF）属性不依赖于其它非主属性[消除传递依赖]
            满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

II、范式应用实例剖析
        下面以一个学校的学生系统为例分析说明，这几个范式的应用。首先第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
首先我们确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程、课程学分、系别、学科成绩，系办地址、系办电话等信息。为了简单我们暂时只考虑这些字段信息。我们对于这些信息，说关心的问题有如下几个方面。

学生有那些基本信息
学生选了那些课，成绩是什么
每个课的学分是多少
学生属于那个系，系的基本信息是什么。

2.1 第二范式（2NF）实例分析
      首先我们考虑，把所有这些信息放到一个表中(学号，学生姓名、年龄、性别、课程、课程学分、系别、学科成绩，系办地址、系办电话)下面存在如下的依赖关系。
        （学号）→ (姓名, 年龄，性别，系别，系办地址、系办电话)
         (课程名称) → (学分)
        （学号，课程）→ (学科成绩)
2.1.1 问题分析
      因此不满足第二范式的要求，会产生如下问题

数据冗余： 同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。

        更新异常：
             1)若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
            2)假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。

       删除异常 ： 假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
2.1.2 解决方案
      把选课关系表SelectCourse改为如下三个表：
学生：Student(学号，姓名, 年龄，性别，系别，系办地址、系办电话)；
课程：Course(课程名称, 学分)；
选课关系：SelectCourse(学号, 课程名称, 成绩)。

2.2 第三范式（3NF）实例分析
        接着看上面的学生表Student(学号，姓名, 年龄，性别，系别，系办地址、系办电话)，关键字为单一关键字"学号"，因为存在如下决定关系：

       （学号）→ (姓名, 年龄，性别，系别，系办地址、系办电话)
        但是还存在下面的决定关系
       (学号) → (所在学院)→(学院地点, 学院电话)
        即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。
        它也会存在数据冗余、更新异常、插入异常和删除异常的情况。 (数据的更新，删除异常这里就不分析了，可以参照2.1.1进行分析)

        根据第三范式把学生关系表分为如下两个表就可以满足第三范式了：

        学生：(学号, 姓名, 年龄, 性别，系别)；
        系别：(系别, 系办地址、系办电话)。

总结
       上面的数据库表就是符合I,II,III范式的，消除了数据冗余、更新异常、插入异常和删除异常。

补充【讲的不错】：

举例说明数据库一、二、三及BCNF范式

（转载：数据库的设计范式是数据库设计所需，之所以为原创，我觉得它很重要，和大家分享一下，有必要学习一下，于是转载以下这篇文章。希望对于读者有益，提高班的兄弟姐妹们别嫌太长了，耐心看一下吧，灰常有用滴）

要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，
可能存储了大量不需要的冗余信息。

设计范式是不是很难懂呢？非也，大学教材上给我们一堆数学公式我们当然看不懂，
也记不住。所以我们很多人就根本不按照范式来设计数据库。

实质上，设计范式用很形象、很简洁的话语就能说清楚，道明白。本文将对范式进行
通俗地说明，并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式
应用于实际工程。

范式说明

第一范式（1NF）：

数据库表中的字段都是单一属性的，不可再分。这个单一属性由
基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

例如，如下的数据库表是符合第一范式的：

字段1 字段2 字段3 字段4


而这样的数据库表是不符合第一范式的：

字段1 字段2 字段3 字段4
字段3.1 字段3.2很显然，在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第
一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此
，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。

第二范式（2NF）：

数据库表中不存在非关键字段对任一候选关键字段的部分函数依
赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也
即所有非关键字段都完全依赖于任意一组候选关键字。

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

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

(课程名称) → (学分)

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

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


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

(1) 数据冗余：

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

(2) 更新异常：

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

(3) 插入异常：

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

(4) 删除异常：

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

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

学生：Student(学号, 姓名, 年龄)；

课程：Course(课程名称, 学分)；

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

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

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

第三范式（3NF）：

在第二范式的基础上，数据表中如果不存在非关键字段对任一候
选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"
A → B → C"的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应
该不存在如下依赖关系：

关键字段 → 非关键字段x → 非关键字段y

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

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

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

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

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

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


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

学生：(学号, 姓名, 年龄, 所在学院)；

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

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

鲍依斯-科得范式（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范式的，消除了删除异常、插入异常和更新异常。

范式应用

我们来逐步搞定一个论坛的数据库，有如下信息：

（1） 用户：用户名，email，主页，电话，联系地址

（2） 帖子：发帖标题，发帖内容，回复标题，回复内容

第一次我们将数据库设计为仅仅存在表：


用户名 email 主页 电话 联系地址 发帖标题 发帖内容 回复标题 回复内容

这个数据库表符合第一范式，但是没有任何一组候选关键字能决定数据库表的整行，
唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID
"字段，即将表修改为：


用户名 email 主页 电话 联系地址 发帖ID 发帖标题 发帖内容 回复ID 回复标题
回复内容

这样数据表中的关键字(用户名，发帖ID，回复ID)能决定整行：

(用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复
标题,回复内容)

但是，这样的设计不符合第二范式，因为存在如下决定关系：

(用户名) → (email,主页,电话,联系地址)

(发帖ID) → (发帖标题,发帖内容)

(回复ID) → (回复标题,回复内容)

即非关键字段部分函数依赖于候选关键字段，很明显，这个设计会导致大量的数据冗
余和操作异常。

我们将数据库表分解为（带下划线的为关键字）：

（1） 用户信息：用户名，email，主页，电话，联系地址

（2） 帖子信息：发帖ID，标题，内容

（3） 回复信息：回复ID，标题，内容

（4） 发贴：用户名，发帖ID

（5） 回复：发帖ID，回复ID

这样的设计是满足第1、2、3范式和BCNF范式要求的，但是这样的设计是不是最好的
呢？

不一定。

观察可知，第4项"发帖"中的"用户名"和"发帖ID"之间是1：N的关系，因此我们可以
把"发帖"合并到第2项的"帖子信息"中；第5项"回复"中的" 发帖ID"和"回复ID"之间
也是1：N的关系，因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一
定量地减少数据冗余，新的设计为：

（1） 用户信息：用户名，email，主页，电话，联系地址

（2） 帖子信息：用户名，发帖ID，标题，内容

（3） 回复信息：发帖ID，回复ID，标题，内容

数据库表1显然满足所有范式的要求；

数据库表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖，
即不满足第二范式的要求，但是这一设计并不会导致数据冗余和操作异常；

数据库表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖
，也不满足第二范式的要求，但是与数据库表2相似，这一设计也不会导致数据冗余
和操作异常。

由此可以看出，并不一定要强行满足范式的要求，对于1：N关系，当1的一边合并到
N的那边后，N的那边就不再满足第二范式了，但是这种设计反而比较好！

对于M：N的关系，不能将M一边或N一边合并到另一边去，这样会导致不符合范式要求
，同时导致操作异常和数据冗余。
对于1：1的关系，我们可以将左边的1或者右边的1合并到另一边去，设计导致不符合
范式要求，但是并不会导致操作异常和数据冗余。

结论

满足范式要求的数据库设计是结构清晰的，同时可避免数据冗余和操作异常。这并意
味着不符合范式要求的设计一定是错误的，在数据库表中存在1：1或1：N关系这种较
特殊的情况下，合并导致的不符合范式要求反而是合理的。

在我们设计数据库的时候，一定要时刻考虑范式的要求。
转载于www.itput.net http://space.itpub.net/12125877/viewspace-474702