如何理解关系型数据库的常见设计范式？

小咪咪 2023-10-02 22:28 40阅读 0赞

#### 目录 ####

*  理清基础概念
 *   *   *  实体
         *  属性
         *  元组
         *  分组
     *  函数依赖
     *   *  完全函数依赖
         *  部分函数依赖
         *  传递函数依赖
     *  码
     *   *  全码
 *  理解六范式
 *   *   *  第一范式（1NF）
         *  第二范式（2NF）
         *  第三范式（3NF）
         *  巴斯-科德范式（BCNF，Boyce-Codd Normal Form）
         *  第四范式（4NF）
         *  第五范式（5NF）

--------------------

## 理清基础概念 ##

要理解数据库范式，我们先对一些基础概念作一定的认知：

#### 实体 ####

客观存在并可相互区别的事物。就数据库而言，实体往往指某类事物的集合。把每一类数据对象的个体称为实体。实体可以是具体的人、事、物，也可以是抽象的概念、关系。在数据库中往往就表现为某张表。

![在这里插入图片描述][21634c996a4e4c94832bf47cf61d328d.png]

#### 属性 ####

实体所具有的某种特性，对应在关系型数据库中，你可以把这看成是表的某一列。

#### 元组 ####

简单理解，就是表中的某一行。

#### 分组 ####

元组的某个属性。

### 函数依赖 ###

设R(U)是属性集U上的关系模式，X、Y是U的子集。若对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，则称Y函数依赖于X或X函数确定Y。

#### 完全函数依赖 ####

设R(U)是属性集U上的关系模式，X、Y是U的子集。如果Y函数依赖于X，且对于X的任何一个真子集X1，都有Y不函数依赖于X1，则称Y对X完全函数依赖。

#### 部分函数依赖 ####

在关系模式R(U)中，如果X→Y，并且存在X的一个真子集X0，使得X0→Y，则称Y对X部分函数依赖。

#### 传递函数依赖 ####

在关系模式 R(U)中,设 X,Y,Z 是 U 的不同的属性子集,如果 X 确定 Y、Y 确定 Z,且有 X 不包含 Y,Y 不确定 X,(X∪Y)∩Z=空集合,则称 Z 传递函数依赖于X。

### 码 ###

表中可以唯一确定的某元组的某个属性（组），如果这样的码不止有一个，那么这些码统称为候选码，人为根据某些条件从候选码中挑出一个作为能够标识一个元组的最小属性集，那么这个码就是主码。

#### 全码 ####

当所有的属性共同构成一个候选码时，这时该候选码为全码。

--------------------

## 理解六范式 ##

接下来我们再来理解下六范式：

#### 第一范式（1NF） ####

简单来说就是属性不可分（1NF是对属性的原子性约束，要求属性具有原子性，不可再分解）。数据库表的每一列（也称为属性）都是不可分割的原子数据项，不能是集合，数组，记录等非原子数据项。实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。

#### 第二范式（2NF） ####

若某关系R属于第一范式，且每一个非主属性完全函数依赖于任何一个候选码，则关系R属于第二范式。也就是说，在满足第一范式（1NF）的基础上，每一个非码属性（不在主键中的列）都必须完全函数依赖于候选码。（2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性，更通俗的说法就是一个表必须有主键ID）。

#### 第三范式（3NF） ####

非主属性既不传递依赖于码，也不部分依赖于码。在满足第二范式（2NF）的基础上，每个非主属性不依赖于其它非主属性（即在2NF基础上，消除非码属性对候选码的传递函数依赖。3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余）。

也就是说，任何非主属性都直接依赖于主属性，不能传递依赖于主属性。即表中的每一列只与主键直接相关，而不是间接相关（表中的每一列只能依赖于主键）。每一个非码属性既不部分依赖于码，也不传递依赖于码。

#### 巴斯-科德范式（BCNF，Boyce-Codd Normal Form） ####

某些特殊情况下，即使关系模式符合3NF的要求，仍然存在着插入异常，修改异常与删除异常的问题。BCNF由Boyce与Codd提出，通常被认为是修正的第三范式。

巴斯-科德范式即在满足第三范式（3NF）基础上，任何非主属性不能对主键子集依赖（即在3NF基础上，消除主属性对候选码的部分函数依赖和传递函数依赖）。

BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式。或者还可以换一种说法：若一个关系达到了第三范式，并且它只有一个候选码，或者它的每个候选码都是单属性，则该关系自然达到BC范式。

一般来说，一个数据库设计符合3NF或BCNF就可以了。

#### 第四范式（4NF） ####

*  多值依赖的概念:

多值依赖即属性之间的一对多关系，记为K→→A。

函数依赖事实上是单值依赖，所以不能表达属性值之间的一对多关系。

*  平凡的多值依赖：

全集U=K+A，一个K可以对应于多个A，即K→→A。此时整个表就是一组一对多关系。

*  非平凡的多值依赖：

全集U=K+A+B，一个K可以对应于多个A，也可以对应于多个B，A与B互相独立，即K→→A，K→→B。整个表有多组一对多关系，且有：“一”部分是相同的属性集合，“多”部分是互相独立的属性集合。

第四范式即在满足巴斯-科德范式（BCNF）的基础上，消除非平凡且非函数依赖的多值依赖（即把同一表内的多对多关系删除）。

#### 第五范式（5NF） ####

即在满足第四范式（4NF）的基础上，消除不是由候选码所蕴含的连接依赖。

如果关系模式R中的每一个连接依赖均由R的候选码所隐含，则称此关系模式符合第五范式。函数依赖是多值依赖的一种特殊的情况，而多值依赖实际上是连接依赖的一种特殊情况。

但连接依赖不像函数依赖和多值依赖可以由语义直接导出，而是在关系连接运算时才反映出来。存在连接依赖的关系模式仍可能遇到数据冗余及插入、修改、删除异常等问题。  
![在这里插入图片描述][03bf630fd3ec49c1b6ce355a178abd8d.png_pic_center]

此篇偏向概念性讲解，希望能对大家的学习、运用有所帮助！

[21634c996a4e4c94832bf47cf61d328d.png]: https://img-blog.csdnimg.cn/21634c996a4e4c94832bf47cf61d328d.png
[03bf630fd3ec49c1b6ce355a178abd8d.png_pic_center]: https://img-blog.csdnimg.cn/03bf630fd3ec49c1b6ce355a178abd8d.png#pic_center