转自链接：https://www.zhihu.com/question/268799867/answer/342358593
所谓范式就是规范化的关系模式，本质上是一个关系模式。
如果你要做一个学生信息表，这里面有好多信息：SNO(学号)、CNO(选修的课程号)、SNAME(姓名)、SAGE(年龄)、GRADE(某门课的成绩)、SDEPT(学生属于哪个系)、DEAN(系主任)、CONTACT(联系方式包括手机号和邮箱)
我们先来看一下这几个属性的关系，如果一个学生的SNO确定下来了，那么他的SNAME、SAGE、SDEPT和DEAN就确定下来了，我们称SNAME以及后面的几项依赖于SNO，或者SNO决定SNAME等项。但是GRADE无法确定，我们就称GRADE不依赖于SNO，因为还要知道CNO才能确定。最后的CONTACT我们先不管他，等讲到第一范式的时候再说。
所以你只要SNO和CNO那么所有其他的信息就可以被确定下来了。这个SNO和CNO我们就把它们合起来成为主键(或主码)。
但是有的时候SNO和CNO没必要同时给出来。比如想知道SNAME的时候只要知道SNO就行了，CNO知不知道无所谓的，但是如果想要知道GRADE就必须同时给出SNO和CNO。于是我们称GRADE完全依赖于SNO和CNO，因为只有给出的主键信息完整了才能查到，只给出SNO或CNO是不行的。我们称SNAME部分依赖于SNO和CNO，因为只要给出主键里的一部分信息就可以查询到，CNO是多余的信息。
先来看第一范式。刚刚我们提到了一个CONTACT属性，这个属性包括了邮箱和手机号。所以我们就称这个属性不是基本数据项，因为它还可以再分。当我们把它分为EMAIL和PHONE时就不能再分了。现在我们得到了一个新的关系模式，每个属性都是基本数据项，这个新的关系模式就是第一范式。
有一次你往这个关系模式里存新数据，内容是添加一个学生的某一门课成绩，你把SNO、CNO、GRADE都填了上去。后面空了好多，所以你把SNAMESAGE之类的又填了一遍，尽管你知道这根本没有必要。
于是你想改进这个关系模式。你发现除了GRADE完全依赖于主键以外，其他都是部分依赖于主键。于是你把原来的表拆成了两个，第一个在原来的表基础上去掉了GRADE和CNO属性，第二个则是只保留了SNO、CNO和GRADE以外全部去掉了。这样一来就再没有部分依赖了，每一个属性的主键都是干干净净的，完全不多余。虽然关系模式被一分为二，但是他们还是有SNAME做媒介。你得到的这两个关系模式是不存在部分依赖的，这两个新的关系模式就叫做第二范式。
你对自己的成果很满意，但是还没结束。有一次你在记录的时候发现好几个学生是同一个系的，所以他们的系主任也是一样的。系主任出现的次数太多了，直觉告诉你，反复出现的东西一般都可以进行简化。
你发现SNO一旦确定SDEPT就能确定，而SDEPT确定DEAN就能确定。DEAN依赖于SDEPT，而SDEPT依赖于SNO，所以DEAN依赖于SNO。我们称这种依赖为传递依赖，也就是说DEAN传递依赖于SNO。
于是你又开始拆关系模式。第一个关系模式只有SDEPT和DEAN，这样就把系和系主任联系起来了，第二个关系模式只有SNO、SNAME、SAGE和SDEPT，去掉了DEAN。如果你想知道一个学生的系主任，只要先找到系，再通过第一个关系模式找到DEAN就好，因为这两个关系模式是通过SDEPT联系起来的。最后一个关系模式不变。
这样一来你的关系模式就变成了三个互相关联的小关系模式。而这些小关系模式里每个属性只依赖于自己的主键，不存在传递依赖。我们称得到的这样三个小关系模式为第三范式。
总结一下：
第一范式消除非基本数据项。强调列的原子性。
第二范式消除部分依赖。首先是1NF，然后包含2部分：1.一个表必须有一个主键；2.没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
第三范式消除传递依赖。首先是2NF，另外非主键列必须直接依赖于主键，不能存在依赖传递。即不能存在：非主键列A依赖于非主键列B，非主键列B依赖于主键的情况。
