结合案例通俗理解关系型数据库中的三大范式

冷不防 2022-11-09 14:29 139阅读 0赞

## 三大范式的概念 ##

关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。数据库的设计范式是数据库设计所需要满足的规范。只有理解数据库的设计范式，才能设计出高效率、优雅的数据库，否则可能会设计出错误的数据库。  
  目前主要有六种范式：第一范式、第二范式、第三范式、BC范式、第四范式和第五范式。满足最低要求的叫第一范式，简称1NF。在第一范式基础上进一步满足一些要求的为第二范式，简称2NF。其余依此类推。  
  范式可以避免数据冗余，减少数据库的空间，减轻维护数据完整性的麻烦。但是操作困难，因为需要联系多个表才能得到所需要数据，而且范式越高性能就会越差。要权衡是否使用更高范式是比较麻烦的，一般在项目中，用得最多的也就是第三范式，用到第三范式也就足够了，性能好而且方便管理数据。

### 第一范式 ###

> 定义：如果关系模式R的每个关系r的属性都是不可分的数据项,那么就称R是第一范式的模式。

定义太过抽象，不太好理解。简单的说，每一个属性都是原子项,不可分割。1NF是关系模式应具备的最起码的条件，如果数据库设计不能满足第一范式，就不称为关系型数据库。关系数据库设计研究的关系规范化是在1NF之上进行的。

##### 案例 #####

<table> 
 <thead> 
  <tr> 
   <th>学生编号</th> 
   <th>姓名</th> 
   <th>性别</th> 
   <th>联系方式</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>20080901</td> 
   <td>张三</td> 
   <td>男</td> 
   <td>email:zs@126.com,phone:8888666</td> 
  </tr> 
  <tr> 
   <td>20080902</td> 
   <td>李四</td> 
   <td>男</td> 
   <td>email:ls@qq.com,phone:8888668</td> 
  </tr> 
 </tbody> 
</table>

以上的表就不符合第一范式。联系方式字段可以再分。  
变更为正确的是:

<table> 
 <thead> 
  <tr> 
   <th>学生编号</th> 
   <th>姓名</th> 
   <th>性别</th> 
   <th>电子邮件</th> 
   <th>电话</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>20080901</td> 
   <td>张三</td> 
   <td>男</td> 
   <td>zs@126.com</td> 
   <td>8888666</td> 
  </tr> 
  <tr> 
   <td>20080902</td> 
   <td>李四</td> 
   <td>男</td> 
   <td>ls@qq.com</td> 
   <td>phone:8888668</td> 
  </tr> 
 </tbody> 
</table>

### 第二范式 ###

> 定义:如果关系模式R是1NF,且每个非主属性完全函数依赖于候选键,那么就称R是第二范式。

简单的说，首先要满足第一范式,其次每个非主属性要完全赖于主键。也就是说，每个非主属性是由整个主键函数决定的，而不能由主键的一部分来决定。第二范式可以说是消除部分依赖。第二范式可以减少插入异常,删除异常和修改异常。

##### 案例 #####

<table> 
 <thead> 
  <tr> 
   <th>学生</th> 
   <th>课程</th> 
   <th>教师</th> 
   <th>教师职称</th> 
   <th>教材</th> 
   <th>教室</th> 
   <th>上课时间</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>李四</td> 
   <td>Spring</td> 
   <td>张老师</td> 
   <td>java讲师</td> 
   <td>《 Spring深入浅出》</td> 
   <td>301</td> 
   <td>08:00</td> 
  </tr> 
  <tr> 
   <td>张三</td> 
   <td>Struts</td> 
   <td>杨老师</td> 
   <td>java讲师</td> 
   <td>《 Struts in Action》</td> 
   <td>302</td> 
   <td>14:00</td> 
  </tr> 
 </tbody> 
</table>

这里通过(学生,课程)可以确定教师、教师职称,教材,教室和上课时间。所以可以把(学生,课程)作为主键。但是,教材并不完全依赖于(学生,课程),只用课程就可以确定教材,这就叫不完全依赖,或者部分依赖。出现这种情况,就不满足第二范式。  
变更为正确的是:  
选课表:

<table> 
 <thead> 
  <tr> 
   <th>学生</th> 
   <th>课程</th> 
   <th>教师</th> 
   <th>教师职称</th> 
   <th>教室</th> 
   <th>上课时间</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>李四</td> 
   <td>Spring</td> 
   <td>张老师</td> 
   <td>java讲师</td> 
   <td>301</td> 
   <td>08:00</td> 
  </tr> 
  <tr> 
   <td>张三</td> 
   <td>Struts</td> 
   <td>杨老师</td> 
   <td>java讲师</td> 
   <td>302</td> 
   <td>14:00</td> 
  </tr> 
 </tbody> 
</table>

课程表:

<table> 
 <thead> 
  <tr> 
   <th>课程</th> 
   <th>教材</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>Spring</td> 
   <td>《 Spring深入浅出》</td> 
  </tr> 
  <tr> 
   <td>Struts</td> 
   <td>《 Struts in Action》</td> 
  </tr> 
 </tbody> 
</table>

如果主键只有一个属性，就不会出现部份依赖了。

### 第三范式 ###

> 定义:如果关系模式R是2NF,且关系模式R(U,F)中的所有非主属性对任何候选关键字都不存在传递依赖,则称关系R是属于第三范式

简单的说,第三范式要满足以下的条件:首先要满足第二范式,其次非主属性之间不存在依赖。由于满足了第二范式,表示每个非主属性都依赖于主键。如果非主属性之间存在了依赖,就会存在传递依赖,这样就不满足第三范式。

##### 案例: #####

上例中修改后的选课表中,一个教师能确定一个教师职称。以至于教师依赖于(学生,课程),而教师职称又依赖于教师,这叫传递依赖。第三范式就是要消除传递依赖。  
变更为正确的是:  
选课表:

<table> 
 <thead> 
  <tr> 
   <th>学生</th> 
   <th>课程</th> 
   <th>教师</th> 
   <th>教室</th> 
   <th>上课时间</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>李四</td> 
   <td>Spring</td> 
   <td>张老师</td> 
   <td>301</td> 
   <td>08:00</td> 
  </tr> 
  <tr> 
   <td>张三</td> 
   <td>Struts</td> 
   <td>杨老师</td> 
   <td>302</td> 
   <td>14:00</td> 
  </tr> 
 </tbody> 
</table>

教师表:

<table> 
 <thead> 
  <tr> 
   <th>教师</th> 
   <th>教师职称</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>张老师</td> 
   <td>java讲师</td> 
  </tr> 
  <tr> 
   <td>杨老师</td> 
   <td>java讲师</td> 
  </tr> 
 </tbody> 
</table>

#### 问题提炼 ####

通过本文的内容，可以回答关于数据库范式常见的一些面试问答。

> 1.  什么是数据库范式?
> 2.  数据库范式有哪些?
> 3.  第一范式要满足什么条件?
> 4.  第二范式要满足什么条件?
> 5.  第三范式要满足什么条件?