数据库设计范式1——三范式

一讲到数据库设计，大家很容易想到的就是三范式，但是第四、第五范式又是什么，不是很清楚，三范式到底怎么区分，也不清楚，作为数据库设计的基础概念，我再讲解下数据库范式。 Normal form Brief definition 1NF First normal form Table faithfully repres

一讲到数据库设计，大家很容易想到的就是三范式，但是第四、第五范式又是什么，不是很清楚，三范式到底怎么区分，也不清楚，作为数据库设计的基础概念，我再讲解下数据库范式。

	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:[e-mail],phone:[phone]	Reading;Guitar
Devin	M	Email:[e-mail],phone:[phone]	Swimming
Neil	M	Email:[e-mail],phone:[phone]	Reading;Guitar

为了区分每一行数据，所以需要添加主键UserId，这样就能区分出每一行数据来。

UserId	Name	Gender	Contact	Interest
1	Neil	M	Email:[e-mail],phone:[phone]	Reading;Guitar
2	Devin	M	Email:[e-mail],phone:[phone]	Swimming

但是这个表仍然不符合第一范式，应该Contact字段不是不可再分的，该字段可以分为Email和Phone两个字段，所以我们表变为：

UserId	Name	Gender	Email	Phone	Interest
1	Neil	M	[e-mail]	1222456	Reading;Guitar
2	Devin	M	[e-mail]	13934563456	Swimming

这样做以后我们的表仍然是不符合第一范式的，应该Interest字段不是原子的，里面包含了一组数据，对于这个字段，就不能像Contact一样拆分成两个字段，应该Interest字段里面包含的对象是一样的，而且一个用户可以有无数多个兴趣爱好。所以我们需要将该字段单独出来，形成新的表：

UserId	Name	Gender	Email	Phone
1	Neil	M	[e-mail]	1222456
2	Devin	M	[e-mail]	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，也就是传递依赖。

以上说的是数据库设计中最基本的三范式，大部分数据库设计时，只需要满足这三个范式即可。接下来我还会写一篇博客讲解下更高级的范式。