数据库的范式，第一、二、三、四、五范式、BC范式，为什么分不清

这件事，怪我。

数据库范式 的 来历

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

关系数据库

要理解范式，首先要知道什么是关系数据库。简单来说：关系数据库就是用二维表来保存数据。一些关于信息的二维表如：

常用范式

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

函数依赖

函数依赖的定义

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

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

范式间的关系

关系数据库有六种，一、二、三、四、五和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范式。