一讲到数据库设计，大家很容易想到的就是三范式，但是第四、第五范式又是什么，不是很清楚，三范式到底怎么区分，也不清楚，作为数据库设计的基础概念，我再讲解下数据库范式。
| Normal form | Brief definition | |
| 1NF | First normal form | Table faithfully represents a relation, primarily meaning it has at least one candidate key |
| 2NF | Second normal form | No non-prime attribute in the table is functionally dependent on a proper subset of any candidate key |
| 3NF | Third normal form | Every non-prime attribute is non-transitively dependent on every candidate key in the table. The attributes that do not contribute to the description of the primary key are removed from the table. In other words, no transitive dependency is allowed. |
| EKNF | Elementary Key Normal Form | Every non-trivial functional dependency in the table is either the dependency of an elementary key attribute or a dependency on a superkey |
| BCNF | Boyce–Codd normal form | Every non-trivial functional dependency in the table is a dependency on a superkey |
| 4NF | Fourth normal form | Every non-trivial multivalued dependency in the table is a dependency on a superkey |
| 5NF | Fifth normal form | Every non-trivial join dependency in the table is implied by the superkeys of the table |
| DKNF | Domain/key normal form | Every constraint on the table is a logical consequence of the table's domain constraints and key constraints |
| 6NF | Sixth normal form | Table features no non-trivial join dependencies at all (with reference to generalized join operator) |
第一范式 1NF First normal form
简单说来就是每个表都应该有主键（唯一标识每一行），每个字段应该是原子的不可再分的。
比如以下表不符合第一范式，因为没有主键，我们无法区分第一行和第三行数据。
| Name | Gender | Contact | Interest |
| Neil | M | Email:neil@ee.net,phone:1222456 | Reading;Guitar |
| Devin | M | Email:studyzy@163.net,phone:13934563456 | Swimming |
| Neil | M | Email:neil@ee.net,phone:1222456 | Reading;Guitar |
为了区分每一行数据，所以需要添加主键UserId，这样就能区分出每一行数据来。
| UserId | Name | Gender | Contact | Interest |
| 1 | Neil | M | Email:neil@ee.net,phone:1222456 | Reading;Guitar |
| 2 | Devin | M | Email:studyzy@163.net,phone:13934563456 | Swimming |
但是这个表仍然不符合第一范式，应该Contact字段不是不可再分的，该字段可以分为Email和Phone两个字段，所以我们表变为：
| UserId | Name | Gender | Phone | Interest | |
| 1 | Neil | M | neil@ee.net | 1222456 | Reading;Guitar |
| 2 | Devin | M | studyzy@163.net | 13934563456 | Swimming |
这样做以后我们的表仍然是不符合第一范式的，应该Interest字段不是原子的，里面包含了一组数据，对于这个字段，就不能像Contact一样拆分成两个字段，应该Interest字段里面包含的对象是一样的，而且一个用户可以有无数多个兴趣爱好。所以我们需要将该字段单独出来，形成新的表：
| UserId | Name | Gender | Phone | |
| 1 | Neil | M | neil@ee.net | 1222456 |
| 2 | Devin | M | studyzy@163.net | 13934563456 |
| UserId | Interest |
| 1 | Reading |
| 1 | Guitar |
| 2 | Swimming |
现在这两个表才满足第一范式。
第二范式 2NF Second normal form
简单说来就是在满足第一范式的情况下，非主键属性应该完全依赖于候选键（候选关键字、唯一标识每一行数据的键，一个表存在多个候选键），而不应该依赖于候选键的部分。
比如以下的学生选课表，主键是学号和课程号，非主键属性是选课的时间，系统确认的时间，所选课程的名字。
| StudentId | CourseId | ChooseTime | ConfirmTime | CourseName |
| 1 | 10 | 2013/8/26 | 2013/8/27 | 微积分 |
| 1 | 11 | 2013/8/27 | 2013/8/27 | 线性代数 |
| 2 | 10 | 2013/8/26 | 2013/8/27 | 微积分 |
这个表满足第一范式，因为StudentId+CourseId能够唯一的标识每一行数据，而且每个属性都是原子的，不可再分的。选课时间和系统确认时间完全依赖于主键，没有问题。课程名称只依赖于CourseId，不依赖于StudentId，所以不满足第二范式，需要将课程名称独立出来：
| StudentId | CourseId | ChooseTime | ConfirmTime |
| 1 | 10 | 2013/8/26 | 2013/8/27 |
| 1 | 11 | 2013/8/27 | 2013/8/27 |
| 2 | 10 | 2013/8/26 | 2013/8/27 |
| CourseId | CourseName |
| 10 | 微积分 |
| 11 | 线性代数 |
第三范式 3NF Third normal form
简单来说就是满足第二范式的情况下，非主键属性应该完全依赖于候选键，不应该依赖于其他非候选键。
比如以下的学生表，主键是学号，非主键属性为学生姓名、所在院系Id，所在院系名。
| StudentId | Name | DepartmentId | DepartmentName |
| 1 | Neil | 21 | Math |
| 2 | Devin | 22 | Computer |
首先这个表满足第二范式，因为主键就一个字段，所有非主键属性都依赖于StudentId。但是该表不满足第三范式，因为院系名称是依赖于院系ID的，院系ID在这个表中是非主键，依赖于学生ID，也就是传递依赖。
以上说的是数据库设计中最基本的三范式，大部分数据库设计时，只需要满足这三个范式即可。接下来我还会写一篇博客讲解下更高级的范式。
