数据库的范式，第1、2、3、4、五范式、BC范式

数据库的规范化（上一篇博客有写到）的程度不一样，便有了这么多种范式。数据库范式是数据库设计必不可少的知识，没有对范式的理解，就没法设计出高效率、优雅的数据库，甚至设计出错误误的数据库。课本中的定义比较抽象，不太直观，也不易理解，记是确定记不住的。

关系数据库

经常使用范式

关系数据库知道了，再来理解范式。范式是关系数据库关系模式规范化的标准，从规范化的宽松到严格，分为不一样的范式，一般使用的有第一范式。第二范式、第三范式及BC范式。范式是创建在函数依赖基础上的。

函数依赖

若是一个表中某一个字段Y的值是由另一个字段或一组字段X的值来肯定的，就称为Y函数依赖于X。

 

函数依赖

定义

设X,Y是关系R的两个属性集合，当任什么时候刻R中的任意两个元组中的X属性值相同时，则它们的Y属性值也相同，则称X函数决定Y，或Y函数依赖于X。

3.平凡函数依赖

当关系中属性集合Y是属性集合X的子集时(Y⊆X)，存在函数依赖X→Y，即一组属性函数决定它的全部子集，这种函数依赖称为平凡函数依赖。

4.非平凡函数依赖

当关系中属性集合Y不是属性集合X的子集时，存在函数依赖X→Y，则称这种函数依赖为非平凡函数依赖。

5.彻底函数依赖

设X,Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每个X’都有X’!→Y，则称Y彻底函数依赖于X。

6.部分函数依赖

设X,Y是关系R的两个属性集合，存在X→Y，若X’是X的真子集，存在X’→Y，则称Y部分函数依赖于X。

7.传递函数依赖

设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（学号，系名，系主任），

学号 → 系名，系名 → 系主任，而且系名 －\→ 学号，系主任 －\→ 系名，因此学号 → 系主任为传递函数依赖。

具体的函数依赖应该是经过理解数据项和该企业的内部规则来决定的（不一样企业间有差别），根据表的内容得出的函数依赖多是不正确的。

范式间的关系

关系数据库有六种，1、2、3、4、五和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范式。