无敌！关系型数据库范式分析，第一范式、第二范式、第三范式、BC范式、第四范式、第五范式

本期文字教程，老刘和大家一起分析分享一下关系型数据库中常用的几个范式。

第一范式：（字段不能重复且不能分解）

我们也叫1NF。这个范式主要还是让我们去看看表中不要存在可以被分割的列，同时表的列不能重复。当然，在实际操作过程中，我们如果录入相同的列，系统也是会报错的。

第二范式：（增加主键）

我们也叫2NF。这个范式的前提是必须要先满足第一范式的要求。当然，2NF的主要特点还是主键（从候选码挑选出来的字段，候选码是能决定唯一一行记录的属性组），所谓主键也是是能够决定一行数据的候选码。也就是说，主键可以是一列或者多列组成的，只要能够根据主键，马上能精确到特定的一行数据即可。

这里要注意的是，主键（我们有时候也会叫主属性）内存的值不能为空！

第三范式：（消除非主键的传递关系）

我们也叫3NF。这个范式的前提必须先满足第二范式的要求。第三范式主要是要看表中的非主键字段（列）与主键字段是否含有传递关系。什么叫是否有传递关系呢？

假设有一张表如下图：

这个表中的“商品类别名称”、“商品类别描述”其实是可以根据“商品类别编号”这个字段去检索到的，在这个表中具有字段传递关系。如果按照这个表去存储数据库的话，意味着要将“商品类别名称”、“商品类别描述”两个字段的数据重复很多次，使得表的空间产生严重冗余。因此，我们考虑将这个表拆分为两个表，如图所示。

这样建立数据表，就符合了数据库第三范式3NF规范。如果我们想要在表内单独增加一个商品类别也相当方便，假设我们系统想要显示出来我们的商品类别，那么就更方便了。

在实际开发中，我们的系统一般符合3NF就可以了，但是在实际工作生产过程中，为了优化我们的系统性能，有时候可能会牺牲数据空间换取工作性能，最终部分表的关系只能符合2NF。这种情况也是非常正常的。

BC范式：（消除主键内的传递关系）

这个范式也叫BCNF。这个范式的前提条件是要先满足第三范式的要求。在BC范式中，比起第三范式来说还多了一个主键内部传递关系的检查。我们举个例子，看图中的表：

从这个表中，我们可以看出，商品价格是非主属性，店铺、店长、商品名称是主属性（主键），我们可以根据三个字段作为主键去确定找到某个商品的价格。

现在，作为老板的你，想要增加一家店铺，店铺也有商品，但是还没有招聘到店长，这个时候怎么办呢？如果按照以上3NF的要求设计的表，就会无法录入信息到表，因为主键是不能为空的。

所以，我们需要重新设计这个数据表，把它变成符合BCNF的表。即从主键中再次进行分解成其他的表。重新设计后，我们表如下：

这样设计就符合BCNF

第四范式：（消除一个表内的多个多值）

我们也叫做4NF。这个范式的设计我们需要先满足BC要求的前提要求。在4NF中最为特别的就是在一个表内要消除掉多个多值情况。我们还是举个例子，如下表中存在多值的情况。

首先，上表的设计是符合BC范式的，但我们也能明显看到一个学生肯定会有多个兴趣爱好的情况，一个学生也会有多个家长。因此，我们也可以这个表调整成4NF规范。下图所示。

第五范式：（消除非候选码的表字段连接依赖）

这个范式我们也叫5NF。这个范式首先前提必须要满足4NF。第五范式是指关系模型R依赖均有R候选码所隐含，这是指在连接时，所连接的属性均为候选码。这个是几近于完美的范式，对字段关系要求极高，但是可能会消耗数据库很大性能。这里不做举例了。主要强调一下，5NF主要就是表连接时注意，只能是候选码才能连接才可以。