一： 引言

作为一个数据库的学习者，搞懂关系数据库的三大范式是很有用的。然而教科书上有关数据库范式的介绍都是采用学术性的定义，语法羞涩，让人难懂，故写下自己对数据库范式的理解，给初学者提供帮助，也备日后查看。

本文不介绍规范化程度高于3NF的范式，因为其在实际应用中基本不会用到，原因也是很明显的（查询代价变大），因此，对于很多大型复杂的系统，其数据库设计都没有遵循所谓的范式，这也是为什么会出现所谓的逆规范化，好了，进入正题吧。

二： 范式介绍

    a：第零范式

第零范式就是指没有使用任何范式的设计，其添加数据的行为非常诡异，看看下表便知：

假设一个学生学习了三门课程，每门课程都有成绩，那么，采用第零范式的设计将会是如下情况                          

表a_0

这样的话，会使得往表中添加数据变得非常麻烦，每次添加一个新的数据，都要添加相应的字段，而且，因为表中其他的记录可能不需要这么多字段，因此会浪费

很多空间。如表a_1所示。

表a_1

         由此可以看出，不对数据库任用任何范式是非常愚蠢的，因为不仅会产生大量无用的表字段，而且会使得表结构非常难以维护。由此，引出第一范式的介绍

    b:  第一范式

第一范式就是在第零范式的基础上进行的改进，网上有很多人认为，所谓第一范式就是指表中的所有字段都是原子的、不可再分的，我个人认为此种理解也是正确的，原因不解释，我对第一范式的理解是，将

　　   第零范式中重复的字段抽取出来，作为表的数据，从而形成一个稳定的、冗余数据少得表结构。

由此，可以得出符合第一范式的表结构应该是：

此时，表的结构变得稳定了，而且表中的冗余信息相对第零范式也少了很多。可是，第一范式只是关系数据库设计的最低满足的范式，第一范式中仍然有很多的冗余信息，由此，需要引入第二范 　　  式。

  c: 第二范式

第二范式是满足属性对主键是完全函数依赖的，因此，满足第二范式的表当然也是满足第一范式的，第二范式的目的就是消除表中的部分依赖。

这里，有几个概念要解释下，

1： 完全函数依赖

设有属性集K和P，若K中的所有属性共同能够推出P中的任意属性，且对于K的任何真子集，都不能推出P中的任意属性，则成K完全函数依赖P。

2： 部分函数依赖

与上相似，只是，K中存在真子集使得，该子集能推出p中任意属性。

概念性的东西，往往都难懂，举个例子，方便大家理解：

假如有一张学生成绩表，包含如下属性(学生Id，课程Id，课程分数，学生名字)，其中，主键为(学生id，课程id)，表中的数据如下：

那么，此时这张表的设计就不满足第二范式， 因为 主键(学生id，课程id) 能够唯一确定学生的姓名，因此，不满足属性完全函数依赖主键，因此不是第二范式。

从上面的表数据易知，不满足第二范式的表至少有以下几个缺点：

             1：数据重复，浪费空间，因为每存一条记录，都要存学生的名字，这样就是得存在大量重复的数据。

             2: 插入异常，若学生还没有成绩，那么这个学生就没有名字。

             3：  更新异常，删除异常等

        解决方法：

             将student_name字段放入学生表中，即消除表中的部分依赖。

   d: 第三范式

第三范式是指在满足第二范式的情况下，消除表中的传递依赖。

所谓传递依赖，就是指x–>y,y–>z,那么可以得到y–>z.

传递依赖常发生在主键、外键、外键相关的属性上，例如，假设有这样的表

学生表(学生id，学生姓名，院系id，院系名)  ，此处主键为（学生id），外键为(院系id)

院系表(院系id，院长名称)，主键为 （院系id）

很明显，此处存在传递依赖，因为 学生id  可以唯一确定  院系id，而 院系id 可以唯一确定 院系名。

表中的数据如下

从上面的表数据易知，不满足第三范式的表至少有以下几个缺点：

1 ：  数据重复，浪费空间，因为学生表每存一条记录，都会记录住院系的名字，存在大量的重复数据。

2：  插入异常，若新建一个院系，而该院系没有学生的话，该院系就没有名字。

3：  更新异常，删除异常等

三： 数据库设计的经验

       1: 表的数目不要太多，一般20-30张就够了。如果表的数目太多，则可以考虑采用同化操作，即将大体相同的实体放入到一张表中。

       2：当数据库中的信息非常庞大时，不要使用外键(逆规范化)，因为由此可能带来非常大的性能损失。

       3：一般以消耗存储空间来换取效率。