数据库之关系数据理论
数据库的规范化（上一篇博客有写到）的程度不同，便有了这么多种范式。数据库范式是数据库设计必不可少的知识，没有对范式的理解，就无法设计出高效率、优雅的数据库，甚至设计出错误误的数据库。课本中的定义比较抽象，不太直观，也不易理解，记是肯定记不住的。
关系数据库
常用范式
关系数据库知道了，再来理解范式。范式是关系数据库关系模式规范化的标准，从规范化的宽松到严格，分为不同的范式，通常使用的有第一范式。第二范式、第三范式及BC范式。范式是建立在函数依赖基础上的。
函数依赖
如果一个表中某一个字段Y的值是由另外一个字段或一组字段X的值来确定的，就称为Y函数依赖于X。
函数依赖
定义
设X,Y是关系R的两个属性集合，当任何时刻R中的任意两个元组中的X属性值相同时，则它们的Y属性值也相同，则称X函数决定Y，或Y函数依赖于X。
1.平凡函数依赖
当关系中属性集合Y是属性集合X的子集时(Y⊆X)，存在函数依赖X→Y，即一组属性函数决定它的所有子集，这种函数依赖称为平凡函数依赖。
2.非平凡函数依赖
当关系中属性集合Y不是属性集合X的子集时，存在函数依赖X→Y，则称这种函数依赖为非平凡函数依赖。
3.完全函数依赖
设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。
4.部分函数依赖
设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。
5.传递函数依赖
设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
属性关系
属性之间有三种关系，但并不是每一种关系都存在函数依赖。设R(U)是属性集U上的关系模式，X、Y是U的子集：
● 如果X和Y之间是1：1关系（一对一关系），如学校和校长之间就是1:1关系，则存在函数依赖X → Y和Y →X。
● 如果X和Y之间是1：n关系（一对多关系），如年龄和姓名之间就是1:n关系，则存在函数依赖Y → X。
●如果X和Y之间是m：n关系（多对多关系），如学生和课程之间就是m:n关系，则X和Y之间不存在函数依赖。
案例分析
编辑
例: Student(Sno, Sname, Ssex, Sage, Sdept)
假设不允许重名，则有:
Sno → Ssex， Sno → Sage , Sno → Sdept，
Sno ←→ Sname, Sname → Ssex， Sname → Sage
Sname → Sdept
但Ssex －\→ Sage
若 X → Y，并且 Y → X, 则记为 X ←→ Y。
若 Y 不函数依赖于 X, 则记为 X －\→ Y。
在关系模式R(U)中，对于U的子集X和Y，
1.如果 X → Y，但 Y 不为 X 的子集，则称 X → Y 是非平凡的函数依赖
例：在关系SC(Sno, Cno, Grade)中，
非平凡函数依赖： (Sno, Cno) → Grade。
2.若 X → Y，但 Y 为 X 的子集, 则称 X → Y 是平凡的函数依赖
平凡函数依赖： (Sno, Cno) → Sno ，(Sno, Cno) → Cno。
3.若 x → y 并且，存在 x 的真子集 x1，使得 x1 → y, 则 y 部分依赖于 x。
例：学生表（学号，姓名，性别，班级，年龄）关系中，
部分函数依赖：（学号，姓名）→ 性别，学号 → 性别，所以（学号，姓名）→ 性别 是部分函数依赖。
4.若 x → y 并且，对于 x 的任何一个真子集 x1，都不存在 x1 → y 则称y完全依赖于x。
例：成绩表（学号，课程号，成绩）关系中，
完全函数依赖：（学号，课程号）→ 成绩，学号 －\→ 成绩，课程号 －\→ 成绩，所以（学号，课程号）→ 成绩 是完全函数依赖。
5.若x → y并且y → z，而y －\→ x，则有x → z，称这种函数依赖为传递函数依赖。
例：关系S1（学号，系名，系主任），
学号 → 系名，系名 → 系主任，并且系名 －\→ 学号，系主任 －\→ 系名，所以学号 → 系主任为传递函数依赖。
具体的函数依赖应该是通过理解数据项和该企业的内部规则来决定的（不同企业间有差异），根据表的内容得出的函数依赖可能是不正确的。
范式间的关系
关系数据库有六种，一、二、三、四、五和BC。满足最低要求的范式是第一范式。在第一范式的基础上进一步满足更多要求的称为第二范式，其余范式以此类推。一般情况的数据库只需满足第三范式即可。
1NF
如果关系模式R是第一范式的模式，那么，R的每一个关系r的属性都是原子项，不可分割。
1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不能称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。
2NF
如果关系模式R是1NF，且每一个非主属性完全依赖于候选建，那么就称R是第二范式。
第二范式要满足的条件：首先要满足第一范式，其次每一个非主属性要完全函数依赖于候选键，或者是主键。也就是说，每个非主属性是由整个主键函数决定的，而不能有主键的一部分来决定。
第二范式（2NF）：符合1NF，并且，非主属性完全依赖于码。（一个候选码中的主属性也可能是好几个。如果一个主属性，它不能单独做为一个候选码，那么它也不能确定任何一个非主属性。
什么样的实例不符合第二范式？
举一个教务管理系统的例子。
学生上课指定一个老师，一本教材，一个教室，一个时间，学生去上课，怎么设计数据库？
有如下关系成立：
（学生，课程）——>教室；
（学生，课程）——>老师；
（学生，课程）——>老师职称；
（学生，课程）——>教材；
（学生，课程）——>上课时间；
可以得出（学生，课程）是一个码。
又：课程——>教材；
（学生，课程）是一个码，课程却决定了教材，这就叫做不完全依赖，或者说部分依赖。
出现了这种情况，就不满足第二范式了。
解决办法：分解。进行投影分解：
3NF
如果关系模式R是2NF，且关系模式R（U,F）中的所有非主属性对任何候选关键字都不存在传递依赖，则称关系R是属于第三范式。
第三范式（3NF）；符合2NF，并且，消除传递依赖。
上图中符合2NF ，但存在传递依赖（老师——>老师职称。一个老师一定能确定一个老师职称）。
解决办法：分解。投影分解：
其他范式
第四范式：要求把同一表内的多对多关系删除。
第五范式：从最终结构重新建立原始结构。
BC范式（BCNF）：符合3NF，并且，主属性不依赖于主属性。若关系模式R属于第一范式，且每个属性都不传递依赖于键码，则R属于BC范式。