数据库设计——三范式学习理解

什么是范式？

数据库设计中，需要遵循一定的规则才能避免数据的冗余，这些规则实际上限制的是表与表、表与属性之间的关系。这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

1.第一范式(1NF)

第一范式是指数据表中的每个字段必须是不可拆分的最小单元，也就是确保每一列的原子性。
举个例子，某省的投档线公布表：

院校代码	科类	院校名称	投档分
0019	理工	吉林大学	538.106123198
1000	理工	北京大学医学部	657.141142258
1001	文史	北京大学	633.127139227

很明显，这个投档线字段包括了总分、数学语文和英语，这个字段可以拆分为另外四个字段，所以这种设计不遵循第一范式。

2.第二范式(2NF)--先要满足第一范式

第二范式是指每一列必须要有主键，并且非主键列必须依赖于主键，确保了表关系的唯一性。

我们来简单理解，这句话的意思，首先就是要有主键，这很简单，很好理解，同一张表中，不能有任意两行的主键是相同的，这也就确保了每一行的主键唯一性。那后面一句话，非主键列必须依赖于主键，什么意思？首先，需要指出的是，所谓的依赖，可以通俗简单的理解为相关。也就是说，这一行数据已经依靠主键唯一确定了一组信息，那么该行的非主键数据必须是和主键是有关的，否则，就失去了意义，或者说，就产生了没有意义的列。所谓的表关系的唯一性，其实就是在说，这张表的结构所描述的只能是一种关系，无关的信息不应该出现。

举个例子，我们来看这样一张表：

表的显示如下：（作为例子，我只插入了一行数据）

仔细看这张表，有个很明显的问题，主键是学号，唯一标识了一位学生，但是在该表的列关系中却出现了课程名称和课程学分。这个表明显说明了两个事务:学生信息, 课程信息; 这两者，显然不应该是出现在一张表中的。注意，这张表是学生信息表，不要理解成学生选课的信息表。

上述例子，可能理解有些抽象，我们在来看一个更加极端的例子。

假如，现在我们有个学生表，学号，姓名，性别，商品单价。

现在，是不是一眼就看出来，哪里有点不对劲，学生表中的商品单价是什么鬼？哈哈，如果你能想到这个问题，说明你其实已经理解了第二范式，很显然，商品单价跟这个表关系想要描述的学生信息毫无关系，怎么能出现在一张表中呢？注意，这个简单的例子只是很极端的帮助理解第二范式。

3.第三范式(3NF)--先要满足第二范式

第三范式就是每一列非主键数据必须直接依赖主键，而不能存在间接依赖(传递依赖)。

这句话怎么理解呢？我们还是看我们第二范式介绍的时候，那个例子，我们当时说的是我们建立的学生信息表，所以课程名称和课程学分的信息和主键不相关。那么，我们此时改变逻辑，我们来看下面的例子：

我们上述简单理解为学生的选课信息，此时的行数据表示该学号的学生选择了哪一门课程。比如例子中所说信息表示，55161008这名学生，选择了数据库的课程，课程学分为4分。

哎，乍一看，这不是挺合理的吗？我们仔细想一下，学分和学号的关系是依托于课程的，也就是说学分与学号并没有直接的关系

换句话说，课程的学分数据是课程的相关信息，应该出现在描述课程信息的那张表中，出现在这里是冗余的。

我们例子中出现的所谓的间接相关：表关系的含义是，学号代表的那名学生选择了某一课程，这个课程的学分是多少分；

很明显，这不是直接关联的，因为课程学分本身跟学生毫无关系。

总结：

这里只是很简单的，阐述了三范式的含义和举出了例子进行基础的理解，其实无论是什么范式，都是为了更好的设计数据库，更好的管理表关系。所以，我们在数据库关系建表的时候，尽可能的应该结合实际更好的去利用这些范式。