详谈数据库泛型：第一、二、三、四和BCN范式

目录

1 什么是数据库泛型？

2 第一范式：无重复的列

3 第二范式：属性完全依赖于主键（针对联合主键）

4 第三范式：属性不依赖于其他非主属性

5 BCN范式：每个表中只有一个候选键

6 第四范式：消除表中的多值依赖

7 详细举例

---

1 什么是数据库泛型？

数据库泛型就是数据库应该遵循的规则。数据库泛型也称作数据库范式。数据库范式是数据库设计需要满足的一些规范。满足这些规范可以使数据库变得简洁、结构清晰，并且在操作数据库时不会发生异常操作。

目前，关系型数据库最常用的四种范式分别是第一范式、第二范式、第三范式和BCN范式。

应用数据库范式可以带来许多好处，但是最重要的好处归结为三点：

1）减少数据冗余（这是最主要的好处，其他好处都是由此而附带的）

2）消除异常（插入异常，更新异常，删除异常）

3）让数据组织的更加和谐…

 

但是数据库范式绝对不是越高越好，范式越高，意味着表越多，多表联合查询的机率就越大，SQL的效率就变低。

 

2 第一范式：无重复的列

第一范式即数据库表中每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的值。

在第一范式中，每一行只包含了一个示例的信息，简而言之就是无重复的列。

如上图，是一个数据库表的列信息，第一范式的要求即是：姓名、年龄和学号这三个属性没有重复的，且每个属性都是一个单一的值，不能包含其他值，例如：在第一范式中，我们不能将姓名和年龄合起来作为一个属性。这就是数据库的第一范式。

如果一个数据库连第一范式都不满足的话，那么它将不能被成为关系型数据库。

第一范式保证确保了数据库是关系型数据库。

在满足第一范式的情况下，我们将数据库进行进一步的细化，就可以使数据库满足第二范式。

接下来看第二范式的介绍。

3 第二范式：属性完全依赖于主键（针对联合主键）

在第一范式的基础上，才有了第二范式。即如果一个数据库满足第二范式，那么它肯定满足第一范式。

第二范式要求数据库表中的每个实例都能被唯一的区分。为实现区分，通常在数据库中要为每个实例存储一个唯一的标识符。这个唯一属性列通常被称为主键或者主码。

举类：

例如一个学生表中有学号、院系号和院系名这三个字段。在大部分的学校管理中学号是可以决定院系名的，而院系号也是可以决定院系名的。因此这个表是不满足第二范式的。现在将该表进行细化，细化之后生成两个表，第一个表有学号和院系名，第二个表有院系号和院系名。这样就满足了第二个范式。

第二范式消除了局部依赖。

4 第三范式：属性不依赖于其他非主属性

第三范式是在第二范式的基础上建立起来的。

要求一个数据库表中不包含已在其他表中已包含的非主关键字信息。

例如：学生生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，学号是主键，但是学院电话只依赖于所在学院，并不依赖于主键学号，因此该设计不符合第三范式，应该把学院专门设计成一张表，学生表和学院表，两个是一对多的关系。

第三范式消除了传递依赖。

注意：

通常情况下，如果一个数据库能够满足第三范式的要求，那么这个数据库就是一个很好的数据库了。当一个数据库达到第三范式的要求，数据库中基本上没有冗余的信息了。但有时候为了满足查询的速度要求，可以有意识的让某些表有些冗余。这时为了提高数据库的性能。

因此在设计数据库的时候，不一定拘泥于第三范式或者是BCN范式。只要数据库的设计让整个系统的性能得到提高，那么数据库就是一个设计良好的数据库。

5 BCN范式：每个表中只有一个候选键

简单来说，BCN范式是在第三范式的基础上的一种特殊情况，即每个表中只有一个候选键（在一个数据库中每行的值都不同，则可称为候选键）

示例见详细举例。

BCN范式消除了主键对候选键的依赖。

6 第四范式：消除表中的多值依赖

简单来说，第四范式就是要消除表中的多值依赖，也就是说可以减少维护数据一致性的工作。

示例见详细举例。

第四范式是BCN范式的推广。

7 详细举例

首先我们先看一个第一范式的数据库，如下：

第一范式要求不能有重复的列，由于员工信息中有AddressID,并且部门也有AddressID，因此将员工的住址信息抽出来单独作做一张表，来满足第一范式。

第二范式要求属性完全依赖于主键，但是在上述员工信息表noNF中，departmentName和departmentDescription并不完全依赖于主键。因此将部门的相关信息提取出来：

第三范式要求属性不依赖于其他非主属性，即要求一个数据库表中不包含已在其他表中已包含的非主关键字信息。但是jobDescription已经包含在了表job中，因此将其剔除出来。

在noNF中，email不可能有重复的，这样的话在noNF中，候选主键为email。因此为了满足BCN范式，要将email单独建一张表。

noNF表中的skill技能这个字段，有的人是“java，mysql”，有的人描述的是“Java，MySQL”，这样数据就不一致了，解决办法就是将多值属性放入一个新表，所以满足第四范式的关系图如下：

 

从上面对于数据库范式进行分解的过程中不难看出，应用的范式越高，表越多。表多会带来很多问题：

1 查询时需要连接多个表，增加了SQL查询的复杂度

2 查询时需要连接多个表，降低了数据库查询性能

因此，并不是应用的范式越高越好，要看实际情况而定。第三范式已经很大程度上减少了数据冗余，并且基本预防了数据插入异常，更新异常，和删除异常了。