数据库范式到底是怎么个回事

写在前面的话：我认为数据库范式是非常充满哲学意味的一种理论，学院派们说：“数据库设计一定要遵循某某范式啊”，实践派说：“一看你就没有实际经验”。使用范式还是不使用范式，这是一个问题。一看到“范式”这个词，就充满了厌恶之感，“干嘛一定要学习范式，不使用范式，照样建的一手好表。”随着学习的深入，才发现有些表的建立，感性中不知不觉的就达到了某一个范式，有的时候也会出现一些问题，修改修改就解决了。可是这种凭感觉的行为，总是感觉虚无缥缈，认为还是应该好好学习学习范式的理论，在理论的指导下，至少对于自己的行为是清醒的。“明白理论但是为了某一个目的不去遵守”和“不明白理论凭着感觉而达到了某一个目的”是截然不同的感觉，至少在别人问起你为什么不遵守某某范式时，可以理直气壮的说：我是故意的。

====正文开始========

　　范式，全称规范形式，外国名Normal Form,简称NF，一共有六大范式：1NF，2NF，3NF，BCNF，4NF，5NF。关于更加学术和严谨的论述，可以参看一些数据库教材书籍。接下来，我就要用土一些的话来解释。

　　先来看数据库是干什么的？当然是存储数据的。如何存储？以表table的形式来存储，更确切的说是用关系relation来存储，关系是表的一个特例，我们平时说的时候，就把表和关系等价了，对于关系的一些要求，实际上也对表进行要求了。那么这个表里面的数据可以随便放吗？当然不能，必须有一些基本的要求，例如表的每一行表示一个具体的实体，每个单元格必须是单个值，每个列的数据类型应该一致等等基本要求， 这些要求我们凭感觉就能掌握，于是我们很轻易的就根据实际的要求，建立了一个表，比如大学里面我们经常建立的学生表：Student，里面填满了我们需要的列，如学号studentID，姓名：name,性别sex，等等等等。好了，建好了表，也符合了关系的基本要求，那么这个表就是最好的吗？当然不是，我们可以凭感觉来调整拆分表，当然也可以利用今天要说的“范式”来调整表，或者说叫用“范式”来规范表。接下来一个一个的范式登上舞台。

一、第一范式（1NF）

　　关系模式中每一个分量是不可再分的数据项，则该关系模式属于第一范式。也就是我们建立的一个表中，每一个列都是不可以拆分的。第一范式非常容易实现，一般我们建立了一个表，每一个列都是不能再分了，假如可以再分的话，我们在建表的时候自然而然的就分开了。不过有一点需要注意：第一范式可能跟具体的业务要求有关，例如有时候学生表中姓名可以作为一列，直接保存学生的姓名，如马云；但是有的时候，学校希望姓和名应该分开，那么如果将姓名做为一列就是不符合1NF了，因为该列可以拆分为姓和名两个列了。不过总之，第一范式的建立，根据实际的情况，凭感觉建立就行了，想建成一个不符合第一范式的表，不是太容易的。

二、第二范式（2NF）

　　简单来说，每一个列必须完全依赖于主键，也就是每一列必须是由主键决定的。对于只有一列作为主键的情况，当然不存在问题，任何一列肯定可以由主键决定的，但是如果主键是由多个列组成的，如果某一列可以用主键中的一部分来决定，那么就不符合第二范式了。举个百度百科里面例子，下面的表一中主键为（货物类型，货物ID）。

表一

　　货物名称确实完全依赖与（货物类型，货物ID），但是注意事项不仅完全依赖于（货物类型，货物ID），而且还依赖于主键的一部分：货物类型，因此不符合第二范式，可以拆分为下面两个表：表二和表三，进而符合第二范式。

表二 

表三

三、第三范式（3NF）

　　官方的说法就不写了，简单来说就是，某一列除了完全依赖于主键外，不能依赖于别的非主键的列，否则就不符合第三范式了。比如下面的表四：

表四

 　　上表中，主键是学号，我们知道导师办公室依赖于主键学号，但是同时也依赖于导师ID，因此不符合第三范式。可以通过拆分成下面两个表：表五和表六，符合第三范式。

表五

表六

说明：（1）3NF和2NF有点儿类似，2NF要求不能依赖于主键的一部分，而3NF要求不能依赖于除主键以外的列。

　　　（2）之所以是要符合第三范式，是为了避免太多重复的内容，例如对于导师ID为12的，该表里面就有两条重复的，以后如果ID为12的导师更换办公地址，那么就需要对表中ID为12的导师办公地点全部进行更新，虽然数据量少的时候update一下花不了多长时间，可是万一有好多好多条，更新起来，估计死的心都有了。

　　BCNF、第四范式、第五范式，实在不想说了，真的感觉没什么用，当然如果为了防止被某些学术权威唬住，倒是可以学习学习。

　　最后祝愿大家在三大范式的指导下，建的一手好表。