数据库的三范式

1N:关系R中的属性都是不可分割的项.
2N:在1N的基础上,每个非主属性完全函数依赖于码.
3N:在2N的基础上,每一个非主属性既不部分依赖于码也不传递依赖于码.
 1N
  |   消除非主属性对码的部分函数依赖
 2N
  |   消除非主属性对码的传递函数依赖
 3N
  |   消除主属性对码的部分和传递函数依赖
 BCNF
  |   消除非平凡且非函数依赖的多值依赖
 4N


简单描述：
第三范式的要求如下： 
1，每一列只有一个值 
2，每一行都能区分。 
3，每一个表都不包含其他表已经包含的非主关键字信息。 
你说的两个表，如果每个都满足三范式，那么两个表也满足三范式。


转自：http://www.cublog.cn/u/23975/showart.php?id=391210
数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（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范式的，消除了删除异常、插入异常和更新异常。


例子二：
BCNF是比第三范式更严格一个范式。它要求关系模型中所有的属性（包括主属性和非主属性）都不传递依赖于任何候选关键字。也就是说，当关系型表***能上互相依赖的那些列的每一列都是一个候选关键字时候，该满足BCNF。
BCNF实际上是在第三范式的基础上，进一步消除了主属性的传递依赖。
3． 举例
有这样一个配件管理表WPE(WNO,PNO,ENO,QNT),其中WNO表示仓库号，PNO表示配件号，ENO表示职工号，QNT表示数量。
有以下约束要求：
（1）       一个仓库有多名职工；
（2）       一个职工仅在一个仓库工作；
（3）       每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件；
（4）       同一种型号的配件可以分放在几个仓库中。
分析表中的函数依赖关系，可以得到：
（1）       ENO->WNO;
（2）       （WNO，PNO）->QNT
（3）       （WNO，PNO）->ENO
（4）       （ENO，PNO）->QNT
可以看到，候选键有：（ENO,PNO）;(WNO,PNO)。所以，ENO,PNO,WNO均为主属性，QNT为非主属性。显然，非主属性是直接依赖于候选键的。所以此表满足第三范式。
而我们观察一下主属性：（WNO,PNO）->ENO;ENO->WNO。显然WNO对于候选键（WNO,PNO）存在传递依赖，所以不符合BCNF.
解决这个问题的办法是分拆为两个表：管理表EP（ENO，PNO，QNT）；工作表EW（ENO，WNO）。
为什么不写为（WNO，PNO，QNT），因为是ENO->WNO,ENO占有主导地位，也就是相当于决定位置，你可以试着让（WNO，PNO，QNT）这个时候丢失一个关系就是到底是谁管理这些元件，其实


缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）->   ENO   丢失了,   因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现   一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。  




理解：
第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
注解：因为我们本身已经定义好了一个表是以(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)关系，因为牵涉到一个学生有多个课程，所以(学号, 课程名称)才是主键，他决定的时候后面四个属性的值不一样，但是就有一个问题，这个组合主键中的一个字段决定了后面四个属性中的某些或者全部。解决的办法就是把这个组合主键中的字段跟他决定的关系重新生成一个表。
推广一下，如果是一个组合主键中，里面的几个属性，可以唯一标示非关键字中的某些字段，这时候的解决办法同样是，把这些具有直接依赖的关系，单独分出一个表，因为你要明确主键其实就是你用select语句，设置主键的值以后，他只能够取出一行，所以主键可以唯一标示任意一个非关键字属性。比如，你知道学号/课程名称以后，成绩就定了，这个就相当于等价的意思。肯定不会说另外一个分组学号/课程名称跟他一样，但是成绩不一样，如果真有这种情况，学号/课程名称也就不是主键了。这貌似有点互悖的意味。
尽管组合主键仍是与后面的属性是一对一的关系，其实我们为啥能够消除的原因就是一对一了，其并不等于等价的意思，只要能够往右边推出就行。既然是组合主键肯定里面是一个多对一的关系，如多个学号对应一个课程名称，这个时候关于课程决定的学分就是一个冗余。另外一个问题就是别认为一个组合主键实际上就是一个属性，决定一些字段，然后这些个起决定性的字段就组成了组合主键，这个显然不对的，因为如果组建的每个字段都能够决定一些字段，明显就违背了范式2，但是你也许会说例子中学号于课程名称是一对多的关系，因为论关系的话，总共有四种，现在如果是主键的话， 如果学号跟课程名称是一对一的话，这个时候显然只用学号当主键就行。一对一就是当用select时候，左边的给出一个值，整个式子只能得到一条记录，他们是有方向的，左到右。


第三范式       
     (学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
     (学号) → (所在学院) → (学院地点, 学院电话)
关键字段 → 非关键字段x → 非关键字段y --> point:
关键字段 → 非关键字段x 只是一个普通关系的存在，也就相当于是已知的，而关键是关键字段对x是多对一的关系，然后x能够决定y,这也就推出了 当多个关键字段都同时对应一个x时，y产生了冗余。


第三范式主要是消除非关键字段对任一候选关键字段的传递函数依赖，而BCNF是进一步消除主属性的依赖，其实我感觉我们范式一直努力的方向就是去掉那些我们离散说的蕴含，只要能始终从左推到右就行，不需逆过来，也就是比等价要松一些，原因可见BCNF例二所述，也就是知道这个以后，另一个也就自然明确了的东西。如果在写出来的话，就显然冗余了。


范式也就是对多对一关系的好好把握。