数据库三范式

数据库三范式
1.1 第一范式（1NF）每一属性（列）只有一个确定的数值
不满足第一范式（1NF）的数据库就不是关系数据库。

1.2 第二范式（2NF）属性完全依赖于主键

函数依赖正象一个函数 y = f(x) 一样，x的值给定后，y的值也就唯一地确定了。

如果属性集合Y中每个属性的值构成的集合唯一地决定了属性集合X中每个属性的值构成的集合，则属性集合X函数依赖于属性集合Y，计为：Y→X。

所谓完全依赖是指不能存在任何一个属性仅依赖主关键字一部分的属性，如果有，抽出来自己成立一张表。

1.3 第三范式（3NF）属性不依赖于其它非主属性

部门表主键编号（dept_id）。在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中（否则更改的时候会出现问题）。

如果不存在这张表，也该构建部门信息表，否则就是做乘积，会有大量的数据冗余。

1，每一列只有一个值
2，每一行都能区分。
3，每一个表都不包含其他表已经包含的非主关键字信息。

反例：

不符合第二范式（2NF）：  假定选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：
       (学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
       (课程名称) → (学分)  
       (学号) → (姓名, 年龄)
      由于不符合2NF，这个选课关系表会存在如下问题：
        (1) 数据冗余：
                同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
       (2) 更新异常：
                 若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。
        (3) 插入异常：
                假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。
       (4) 删除异常：
                假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。 但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
         把选课关系表SelectCourse改为如下三个表：
          1).学生：Student(学号, 姓名, 年龄)；
          2).课程：Course(课程名称, 学分)；
          3).选课关系：SelectCourse(学号, 课程名称, 成绩)。
        

不符合第三范式（3NF）：假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：

     (学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)
     (学号) → (所在学院) → (学院地点, 学院电话)
     它也会存在数据冗余、更新异常、插入异常和删除异常的情况，读者可自行分析得知。
     把学生关系表分为如下两个表：
     学生：(学号, 姓名, 年龄, 所在学院)；
     学院：(学院, 地点, 电话)。


BCNF： 假设仓库管理关系表为(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：
     (仓库ID, 存储物品ID) →(管理员ID, 数量)
     (管理员ID, 存储物品ID) → (仓库ID, 数量)
     由于存在如下决定关系：
       (仓库ID) → (管理员ID)
       (管理员ID) → (仓库ID)
         即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：
     (1) 删除异常：
     当仓库被清空后，所有"存储物品ID"和"数量"信息被删除的同时，"仓库ID"和"管理员ID"信息也被删除了。
     (2) 插入异常：
     当仓库没有存储任何物品时，无法给仓库分配管理员。
     (3) 更新异常：
     如果仓库换了管理员，则表中所有行的管理员ID都要修改。
     把仓库管理关系表分解为二个关系表：
     仓库管理：StorehouseManage(仓库ID, 管理员ID)；
     仓库：Storehouse(仓库ID, 存储物品ID, 数量)。
     这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。
1NF: 属性不可再分
2NF:消除1NF的部分依赖
3NF:消除2NF的传递依赖

BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。
例：配件管理关系模式 WPE（WNO，PNO，ENO，QNT）分别表仓库号，配件号，职工号，数量。有以下条件
a.一个仓库有多个职工。
b.一个职工仅在一个仓库工作。
c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。
d.同一种型号的配件可以分放在几个仓库中。
分析：由以上得 PNO 不能确定QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO） -> ENO。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（WNO，PNO）才能确定负责人，有（WNO，PNO）- > ENO。因为 一个职工仅在一个仓库工作，有ENO -> WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有 （ENO，PNO）-> QNT。
找一下候选关键字，因为（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此（WNO，PNO）可以决定整个元组，是一个候选关键字。根据ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能决定整个元组，为另一个候选关键字。属性ENO，WNO，PNO 均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。
分析一下主属性。因为ENO->WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字（ENO，PNO）的部 分依赖，因为（ENO，PNO）-> ENO但反过来不成立，而P->WNO，故（ENO，PNO）-> WNO 也是传递依赖。
虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。
解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO
缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。
一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。
1NF直到BCNF的四种范式之间有如下关系：
BCNF包含了3NF包含2NF包含1NF