database--对三范式和BCNF的理解

概念

三范式：要求先达到二范式，即非主属性对主码的完全函数依赖，而且不能有传递
BC范式：达到三范式要求，并且要求主属性对主码也是完全函数依赖，主属性和非主属性对主码都要达到这个要求，不能有部分函数依赖和传递函数依赖

三范式的不彻底性

三范式的“不彻底”性表现：有可能存在主属性对主码的部分函数依赖或是传递函数依赖。
三范式明确地要求了非主属性对主码的完全函数依赖，不能有部分和传递函数依赖，但没有考虑到主属性和主码之间有差异性。

基本概念了回顾

每个属性不可再分，达到原子性，即满足了一范式要求；
如果不是一范式，表都建不起来；
但一范式会有异常：插入、更新、删除 的异常，而且会有大量的冗余数据；

码的目的：在表中唯一区分每一行；它必须有值，且而唯一；即【not null + unique】

二范式在一范式基础上，强调非主属性对码的完全函数依赖；反过来理解，就是要消除非主属性对码的部分函数依赖现象；
函数依赖：学号决定了姓名，性别，年龄等，则反过来，就是姓名等函数依赖于学号；
起决定作用的，叫决定因素，它至少有一个属性，也可能、可以有多个属性，是属性组合；如果是属性组合，则里面的每一个具体的属性，就是决定因子。决定因子可能是决定因素的一部分，也可能是决定因子等于决定因素。
完全函数依赖：决定因素对非主属性起决定作用，但部分决定因子对非主属性起不了决定作用，这就是完全函数依赖；
部分函数依赖：决定因素肯定对非主属性起决定作用，而部分决定因子亦可以对非主属性起决定作用，这就是有了部分函数依赖了；
最简单的理解就是：【学号】决定了【性别】，肯定可以得到【学号，课程号】也决定了【性别】，但前者因为决定因素没有【部分】的概念，就肯定是完全函数依赖，而后者，【学号】是【学号，课程号】的一部分，而这一部分，照样可以起到决定【性别】的作用，这就是部分函数依赖现象了；
传递函数依赖：A决定了B，B决定了C，则A通过B传递决定了C。反之，就是C传递函数依赖于A。
表中的一个或几个属性K，之外的那些属性都完全函数依赖于K，则称K为候选码，简称为码。
理解就是：假如当K确定了，则表除K之外的其他属性也就随之而确定了，那么，K就是码。【key，码也叫键】。
选中的那个起决定作用的候选码，叫主码；如果非要问如何去选中，那肯定是根据经验和喜欢来选中呗。
但通常，人们会选择一个码来作为主键使用。即主码，主键，关键字，主关键字
在特别的情况下，一个表【关系】中，主键有了，但仍然还会有别的属性也可以作为码。【比如一些规范性不好的关系，但实用性很强】

包含在任何一个码中的属性，即主属性。
不是主属性的那些属性，即非主属性。

现在可以看出，主属性肯定起到决定作用，而非主属性，肯定是依赖于主属性的。
也可以直接这样理解：主属性也就是那些决定因子，而非主属性，就是被这些决定因子决定的。

其实规范化的一个终极目标就是：让起到决定作用的因子起到单纯地决定作用，然后建立起这些决定因子之间有关联关系即可。

三范式是在二范式的基础上，考虑非主属性中仍然出现可能有决定因子的可能，从而引发传递函数依赖现象，需要去除掉这种现象，否则，就会有操作异常发生。也就是说，二范式仍然会引起操作异常。要理解这个异常，一定要从动态地观念上去看待数据。
【1】表中的数据会不断地有插入，删除，更新操作；
【2】多个表中的数据一定会有冗余，因为关系数据库就是靠冗余列来关联表与表的；
【3】当存在部分函数依赖和传递函数依赖时，就会造成操作上的异常；

实例分析

如一范式
学校（学号，课程号，姓名，性别，年龄，所在学院，学院领导，课程名称，学时，学分，选课学期，平时成绩，考试成绩）；
在学校关系中，起决定作用的，肯定有学号和课程号，如果定为主键，则
学号只决定了：姓名，性别，年龄，所在学院，学院领导；
课程号只决定了：课程名称，学时，学分；
而学号和课程号一起，才能决定：选课学期，平时成绩，考试成绩；
因为教务管理的业务原理和过程是这样的。
【1】学生要记录哪些信息；
【2】课程要记录哪些信息；
【3】哪个学生选了哪门课程是在哪个学期；
【4】哪个学生选了哪门课程是什么平时成绩；
【5】哪个学生选了哪门课程是什么考试成绩；
那么，该范式它的不足在哪里呢，从动态的数据上来看
【ex00】如果一个学生选修了多门课程，或是一个门课被多个学生选修了，那么在该表中，肯定会有大量的重复的对应的课程数据行或是学生数据行，这就是数据冗余；
而这些数据冗余，很可能导致不好的数据关联关系；从而引发以下的操作异常。
【ex01】现在要做的业务是新生入学，如果用这张表来记录新生的记录，则无法进行，有插入异常。为什么呢，因为新生还没有选过课，主键【学号，课程号】有部分缺失，无法入库。
【ex02】现在有学生毕业了，从表中清除相应的数据，有可能有一些课程，随着这部分学生的所在行的删除，而导致相应的课程的信息也丢失了；因为业务其实只和学生有关，和课程没有关系，但操作上，会起发这种删除异常现象，这就要求，从原始表的设计上，需要将学生的数据信息和课程的数据信息分开，不能这样耦合在一起；
【ex03】现在教务上对课程信息进行调整，对某个学院的学生所修习的某一门课程调整课程的学时数，而在这样一张表中，就会有这样一种现象，当调整这门课的学时数时，其他学院的选修了这门课的对应的学时数也会跟着被调整了，而这是数据操作不希望发生的，这就是造成了修改异常。而且更奇怪的是，一门课程，在同一个表中，有不同的学时数，但学时数是依赖于课程号的。反过来，也就是说，课程号确定了，而学时数不确定了。这是动摇了整个关系代数的根基了。

将上面的关系进行模式分解，使之进化成二范式
学生（学号，姓名，性别，年龄，所在学院，学院领导）；
课程（课程号，课程名称，学时，学分）；
选课（学号，课程号，选课学期，平时成绩，考试成绩）；
首先判断，为何这组关系能达到二范式要求呢。因为
学生表只有一个属性为主键，没有部份，所以不存在部分函数依赖，肯定达到二范式要求；
课程表同理，也达到二范式要求；
选课表，可以从业务上判断，只有学号和课程号同时确定了，后面三个非主属性也才可以确定，缺少一个决定因子，都无法确定，故而也达到了二范式要求；
据此，可以认为它们进化到了二范式；
刚才的那些异常【ex00-04】再来看一看呢，显然，数据因为分散到不同的表中了，相应的冗余会少很多。
【ex00】学生的数据就是学生的，课程的数据就是课程的。而学号和课程号本来就是起关联作用的，在这里虽然是重复的数据，但已经不是冗余数据的概念了。但仍然有一些小的冗余，那就是当一个学院有多个学生时，【所在学院】和【学院领导】的数据会有重复；
【ex01】插入新的学生，不受课程的影响；
【ex02】删除毕业了的学生，不影响课程信息；但可能影响顺带把【学院】的信息删除了；
【ex03】更新课程的学分，这一项仍然无法完成；但业务上可以新增加一门课程，课程名不变，而学时数满足学院的要求，然后对应更新选课表里的该学院的学生和课程的对应；
可见，二范式对于数据冗余和数据操作异常有一定的改进，能解决一部分问题，但仍然有一些问题；

将上面的关系进行模式分解，使之进化成三范式
学生（学号，姓名，性别，年龄，所在学院）；
学院（学院，学院领导）；
课程（课程号，课程名称，学时，学分）；
选课（学号，课程号，选课学期，平时成绩，考试成绩）；
到这里，再用上面的方法来分析，可以说，基本上解决了数据冗余和操作异常的问题了。

BC范式

三范式只考虑了非主属性对主码的完全函数依赖，不发生传递；
三范式没有考虑主属性对主码的完全函数依赖，不发生传递的现象；
BC范式就是要检查这一基。

BC范式概念

它强调，决定因素必须含有主码。
每一个决定因素都包含主码。
特点分析：
【1】所有非主属性对每一个主码都是完全依赖；
【2】所有主属性对每一个不包含它的主码也是完全依赖；【这是之前未考虑的】
【3】不存在属性完全函数依赖于非主码的情况；
【4】也就是说，排除了任何属性对主码的传递依赖和部分依赖；
从上面的特点分析可以看出，一个关系，满足了三范式的要求，不一定满足BC范式的要求；
而反之，满足了BC范式的要求，则一定是满足了三范式的要求的。

经典示例

1. 业务描述：
   1.某公司有若干个仓库；
   2.每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；【即仓库和管理员相互决定：仓库定了，管理员也肯定确定了；对称的，反过来也一样】
   3.一个仓库中可以存放多个物品，一种物品可以存放于不同的仓库中。每种物品在每个仓库中都有记录对应的数量。【仓库和物品确定了，存了多少数量也就确定了】
   则关系模式 库存（仓库，管理员，物品，数量）是哪一级范式呢？
   分析可知：
   【仓库】 决定了 【管理员】
   【管理员】 决定了 【仓库】
   【仓库，物品】 决定了 【数量】
   起决定作用的是：【仓库】【管理员】【物品】，这些即为主属性；
   而候选码是：
   1【仓库，物品】
   或者2【管理员，物品】
   那么非主属性只有：【数量】
2. 判别
   在任取1或是2为主码的情况下，都不存在非主属性对码的部分和传递函数依赖，所以它是属于三范式的。
   但是：
   如果做如下操作，就会有异常
   【1】先增加一个仓库，但尚未存入物品，这时，数据行是无法入库的，也无法指派管理员；【有插入异常】
   【2】某仓库被清空时，需要删除物品和数据记录，但管理员的信息是很有可能也被清除了；【有删除异常】
   【3】如果仓库更换了管理员，对于存放物品特别多的仓库，就会更改很多行数据对应的管理员列【有冗余造成操作性能下降】
   因引，这个满足了三范式要求的设计，仍然不是一个【好】的设计；
3. 原因分析
   存在着：
   如果取1为码，即【仓库，物品】为主码
   主属性【起决定作用的属性，如管理员】对于码的部分函数依赖或传递函数依赖。
   显然，当关系
   库存（仓库，管理员，物品，数量）
   里的 【仓库，物品】为主码 时，数量是完全依赖于主码的，正是这点，达到了三范式的要求。
   而【管理员】是部分依赖于主码的，它是主属性，但当人们选定了【仓库，物品】为主码 时，它从定义上是要求去依赖于码的；
4. 解决之道
   进行模式分解
   仓库（仓库名，管理员）
   库存（仓库名，物品名，数量）
   也就是把管理员信息从原表里分出来进行记录