数据库设计范式1——三范式-阿里云开发者社区

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

2015-04-01 1014

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

简介：

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

	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)

简单说来就是每个表都应该有主键（唯一标识每一行），每个字段应该是原子的不可再分的。

比如以下表不符合第一范式，因为没有主键，我们无法区分第一行和第三行数据。

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

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

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

现在这两个表才满足第一范式。

简单说来就是在满足第一范式的情况下，非主键属性应该完全依赖于候选键（候选关键字、唯一标识每一行数据的键，一个表存在多个候选键），而不应该依赖于候选键的部分。

比如以下的学生选课表，主键是学号和课程号，非主键属性是选课的时间，系统确认的时间，所选课程的名字。

这个表满足第一范式，因为StudentId+CourseId能够唯一的标识每一行数据，而且每个属性都是原子的，不可再分的。选课时间和系统确认时间完全依赖于主键，没有问题。课程名称只依赖于CourseId，不依赖于StudentId，所以不满足第二范式，需要将课程名称独立出来：

简单来说就是满足第二范式的情况下，非主键属性应该完全依赖于候选键，不应该依赖于其他非候选键。

比如以下的学生表，主键是学号，非主键属性为学生姓名、所在院系Id，所在院系名。

首先这个表满足第二范式，因为主键就一个字段，所有非主键属性都依赖于StudentId。但是该表不满足第三范式，因为院系名称是依赖于院系ID的，院系ID在这个表中是非主键，依赖于学生ID，也就是传递依赖。

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

本文转自深蓝居博客园博客，原文链接：http://www.cnblogs.com/studyzy/p/3305837.html，如需转载请自行联系原作者

文章标签：

数据库

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