要讨论数据库范式,首先不得不解释的是函数依赖的概念。设R(U)是属性集U上的关系模式。X和Y是U的子集。若对于R(U)上的任意一个可能的关系r,如果r中不可能存在两个元组,它们在X上的属性值相等,而在Y上的属性值不等,则称X函数决定Y或Y函数依赖于X,记作X->Y。
    总而言之,这段话可以总结为当X属性值决定Y属性值时,则称X决定Y,或Y依赖于X。
    举个简单的例子:
    设计学生表时,学生的学号可以决定学生的姓名,学生姓名依赖于学生学号。
    在函数依赖中还有平凡函数依赖与非平凡函数依赖,完全函数依赖与部分函数依赖,传递函数依赖等几种特殊的函数依赖。
    (1)平凡与非平凡函数依赖
    设R(U)是属性集上的一个关系模式。X和Y是U的子集。如果X->Y,且Y不属于X则称其为非平凡函数依赖。若X->Y且Y属于X,则称X->Y是平凡函数依赖。
    由此可见一般函数依赖都为平凡函数依赖。
    (2)完全函数依赖与部分函数依赖。
    在R(U)中,如果X->Y,并且对于X的任何一个真子集X',都有X'-\>Y,则称Y对X完全函数依赖,记作:X-f>Y.
    若X->Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖,记作X-p>Y。
    例如 学生表(学号,课程号,年级,学生宿舍)关系中,部分函数依赖:(学号,课程号)→ 学生宿舍 因为 学号 → 学生宿舍 成立

    (3)传递函数依赖。
    在R(U)中,如果X->Y,Y->Z,且Y不属于X,Y->X,则称Z传递函数依赖于X,记作X-t>Z。
    在此加上条件Y-\>X,是因为如果X->Y,Y->Z,则X<-->Y,实际上就是X-直接>Z,是直接函数依赖,而不是传递函数依赖。

    ---
    接下来开始看看何为范式。
    在关系数据库规范化过程中,为不同程度的规划化要求设立的不同标准称为范式。
    第一范式(1NF):
    定义:如果关系模式R的所有属性都是不可分的数据项,则称R属于第一范式,记为R属于1NF。
    不到第一范式
    学生(姓名,性别年龄)----(因为性别年龄列包括了两个属性)
    第一范式
    学生(姓名,性别,年龄)---(R的所有属性都不可在分了)
    第二范式(2NF):
    若关系模式R属于1NF,且每个非主属性都完全函数依赖于R的键,则R属于2NF。即第二范式主要目的为消除非主属性对主属性的部分函数依赖。
    那么为什么需要消除部分依赖呢?
    有这样一个关系模式,
    学生(学号,姓名,系别,住处,课程号,成绩)
    对于以上关系,学号->姓名,学号->系别
    存在以下问题:
    1,数据冗余
    因为姓名等部分依赖于(学号,成绩),所以增添数据每个系的系名和学生住处重复出现,浪费空间。
    2,更新异常
    由于数据的冗余,当更新数据库中的数据时,系统需要付出很大的代价来维护数据库的完整性,否则会造成数据的不一致。
    3,插入异常
    如果某个学生没有选课那么学生有关信息不能插入。
    4,删除异常
    若某个系学生全部毕业,在删除该系学生信息的同时,这个系的相关信息也一并被删除。但是事实上该系仍然存在。
    一个关系模式中若存在部分函数依赖,则必然有主属性与非主属性之间无联系的无关项,则必然会产生上述问题。所以我们需要消除部分函数依赖,这就是第二范式所要求做到的。
    消除部分函数依赖可以采用投影分解法,将部分函数依赖从其中分解出来。
    分解后的关系模式应非主属性对主属性都是完全函数依赖。
    第三范式(3NF):
    关系模式R<U,F>中若不存在这样的键X,属性组Y及非主属性Z(Z不属于Y),使得X->Y,Y->Z成立,且Y->X,则称R属于3NF。
    由此可见,第三范式的目的在于消除传递函数依赖,之所以要消除传递函数依赖是因为,假设X->Y,Y->Z,然而Z并不是直接依赖于X,所以对X所做的某些操作不需要影响到Z,而Y即依赖于X,也被依赖着,即Y在某种程度上有其独立性,可以单独存在不被影响决定,有些针对Y的操作势必会同时影响到X与Z,而且Y不属于X,针对X的有些操作不需要影响到Y,针对Y的操作有时不需要影响X,但并没有必要造成这种影响,所以我们要消除传递函数依赖。
    举个例子:
    学号 宿舍 费用
    062201 A 900
    062230 B 1200
    062240 B 1200
    学号确定宿舍、宿舍确定费用,且有学号不包含宿舍,宿舍不确定学号,符合传递函数依赖条件。
    所以以上关系R存在添加异常(建了C宿舍但是没人住无法添加了)删除异常(学生062201退学了宿舍A也删除掉)。
    综上为了避免异常,我们需要消除它。
    BC范式:
    由于3NF仅仅规定了非主属性的对键的依赖关系。没有限制主属性对键依赖。若存在主属性对键的部分函数依赖与传递函数依赖,必然会产生上面类似的问题。故又引入了BC范式。
    设关系模式R<U,F>∈1NF,如果对于R的每个函数依赖X→Y,若Y不属于X,则X必含有候选码,那么R∈BCNF。
    相对于第三范式,BC范式的要求更加严格。第三范式只是要求R为第二范式且非键属性不传递依赖于R的候选键,而BC范式则是对R的每个属性都做要求。
    在关系模式STJ(S,T,J)中,S表示学生,T表示教师,J表示课程。
    每一教师只教一门课。每门课由一名教师教,某一学生选定某门课,就确定了一个固定的教师。某个学生选修某个教师的课就确定了所选课的名称 : (S,J)→T,(S,T)→J,T→J
    由关系模式的定义可以得到如下结论,若R属于BCNF,则R有:
    1.所有非主属性对每一个码都是完全函数依赖。
    2.所有的主属性对每一个不包含它的码,也是完全函数依赖。
    3.没有任何属性完全函数依赖于非码的任何一组属性。
    由于R∈BCNF,按定义排除了任何属性对码的传递依赖与部分依赖,所以R∈3NF。但是若R∈3NF,则R未必属于BCNF。

    ---
    第四范式以及多值依赖还不太懂,一般若达到BC范式,则在函数依赖范畴上就已经消除了数据冗余,插入,和删除异常。

    ————没有什么是停不下来的,除了时间