数据库入门——三个范式

前言

我觉得他说的最对:

我也来解释一波，参考《数据库系统概念》。

第一范式

书上一开始讲得什么"组合属性"、“多值属性”，都是在讲 E-R模型和表的区别，就是说E-R模型允许存在上述子结构，而表不能，跟第一范式的解释没有直接关系。
第一范式实际的解释为:关系模式中所有的属性的域都是原子域。
举几个反例:

• 例子1:属性children(书上的例子,children里面的值是孩子的名字)的域就不是原子域，因为名字还能分成姓和名。
• 例子2:属性address还能分成街道、城市等等子结构
• 例子3:属性课程标识符(如CS-101)还能分成系(CS)和课程号(101)

存在以上属性的关系模式都不满足第一范式。

第二范式

当关系模式中存在组合主键的时候，其它非组合主键必须要对这个组合主键完全依赖，而不是只是依赖于组合主键中的某一个(按照上面那个兄弟说的，"某一个"已经不算是主键了)。
举一个例子:
学生这个关系模式中有一个组合主键(学号，课程号)，非主键“成绩“，是由组合主键共同决定的，如果这个关系模式中不存在"非主键"对于"组合主键"部分依赖的函数依赖，那么它就满足第二范式。

第三范式

网上的解释好多啊。。
我还是就记住上面兄弟的好了。
只是他说的"每一列对主键的间接依赖"也可以说成是"非主键对于主键的传递函数依赖"。
举一个上课时候的例子: X是码，Y不是码，Z不是码，如果存在X->Y, Y->Z,那么根据传递性，我们就可以得到X->Z,也就是说非主键Z其实是对于主键X是存在函数依赖的，但是中间还夹了一个非主键Y，所以在这里它就不是一个直接的函数依赖，而是一个间接依赖，或者说是"非主键对于主键的传递函数依赖"。

为什么说第三范式是BC范式的放宽呢？
我理解为:BC范式中，函数依赖的左侧部分一定要是超码，也就是说 左侧部分一定可以->整个R。而在第三范式中，只要不存在上述的”非主键对于主键的传递函数依赖"，函数依赖的左侧部分可以不是超码，而只是一个简简单单普普通通的码(它可以不需要决定整个关系R)。