数据库六范式中的一、二、三、BC范式

本次笔记是记录自己对上述范式的抽象理解，帮助记忆，并不权威

首先引入几个概念

范数逻辑下，可以认为SQL数据库中的某个表只用来描述某一种事件相关的属性，同时这种属性应当服务于事件整体，而不是事件的某个特定领域（即局部），与该事件整体不严格相关的属性都是在**增加冗余**

我认为可以将某个范数逻辑下SQL数据库中某个表存储的数据列（也即属性）划分为两种表达意义
1.用于构建表的构建意义
例如某个单属性主键，原则上来说，这一个属性就能构建整张表，只是缺失了一些表达或者描述而已

2.用于描述某种性质的描述意义
例如某个非主属性，它不需要参与表逻辑上的构建，而只是表达了此事务行的某种特性。

可以认为，单属性候选键只满足构建意义，非主属性只满足描述意义，其余主属性二种意义同时具备。

 *部分人可能质疑，难道单属性候选键不具备表述意义嘛，主观上讲确实没问题，比如学号和身份证号两个单属性候选键，主观上当然是一个学生的两种描述，但是对于表的作用来说，并没有任何区别，也无法根据这个属性对于表中某一行的元素实现更深的理解。*

在这个逻辑下，表中的每一列都有其作用，某种范式规定了这种意义的实现规则
（再次强调：并不权威！）

第一范式：属性的原子性

即明确某张表只服务于一种事件。尽管这个事件可以理解为多个事件的组合，但是在表的设计上不能体现出来（很像女朋友说的：“这是原则问题！”）

第一范式是所有SQL数据库的默认范式，从SQL设计原理决定了其不可能实现“表中表”。所以后续范式也无需特别说明其符合第一范式。

第二范式：相较于第一范式，增加要求非主属性对于候选码完全依赖

我的理解还是放入刚刚的概念，即一张表只服务于一种事件，同时是服务于这个事件整体，则所有的非主属性的描述特性应当体现为描述这个事件整体的特性，而不是这个事件某个关联事件的特性。

它的典型反面案例就是多个主属性构成的候选码的真子集就能确定某个非主属性，换句话说，在这张表中，这个非主属性最多只能描述这部分属性组所能确定的事件范围，这和范式逻辑下表的作用偏离了。

第三范式：相较于第二范式，增加要求非主属性不能依赖于另一个非主属性

同样的，放入概念，新增加的内容等价于不允许给只存在描述意义的属性增加另一个只存在描述意义的属性，也就是说，我们可以用一个事件去描述本事件，（当然这个前提是能够描述这个事件的整体特征，这就是第二范式的要求）；但是我们不能给这个用来描述的事件再添加一个描述事件，这就背离描述的初衷了。

可以发现的是，相对于第二范式，明显第三范式要求严格了一些，我解释一下：第二范式要求用于描述的属性必须用来描述事件整体，第三范式进一步要求，不能给这个描述性的事件再进行描述。也就是说尽管这个描述描述事件的事件（禁止套娃！）在这张表种仍然可能能够描述本事件的整体，但存在偏离的倾向，则第三范式予以禁止。

BC范式：相较于第一范式，增加要求只有超码（即候选集的父集）可以决定任何一个非子属性

请注意，这里的增加是**相对于第一范式**，我发现很多科普文章会将他的定义建立在第二或第三范式上，但从定义上讲，BC范式是直接基于第一范式的，并不要求提前满足第三或第二范式。各位可以自行推导，满足BC范式，则必定满足第三范式（当然也就满足第二范式）

发现从定义上讲不太好转换成刚刚的概念，这里换成逆否命题，即任何属性不能依赖于任何非码的属性（组），发现其相对于第三范式，只是换了前后两种属性的表达，放在概念中，即从“不允许给只存在描述意义的属性增加另一个只存在描述意义的属性”换成了“不允许给存在描述意义的属性增加另一个存在描述意义的属性”。

好了，这下第三范式和BC范式的区别清晰明了，相对于一个大于、小于的式子换成了一个大于等于、小于等于的式子，它对于表的要求和第三范式基本是一致的，只是更严格一点而已。二者只可能在一个非码的属性（组）恰好被另一个非码的属性（组）所决定时才会有区别，把这种情况放入概念：从构建意义上，前者被后者决定，则其构建意义冗余；从描述意义上，同样前者也只能描述后者范围内的事件特征，也偏离了表的作用，因此不被BC范式所认可。但是这些新增的内容也确实太少了，所以才不被称为第四范式吧。

————————————————————————

额外补充一点，这里说的某个属性对于表中事件的的整体性和局部性，是一个客观上的概念。这个事件不是依赖表的设计初衷或者表名来决定的，而是依赖于表中当前的所有属性，若某个属性所描述的特征服务于其他所有属性所完全确定的事件、该事件任何一个属性的改变都有可能改变其值，则认为其具备整体性，否则就是局部性