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

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

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

第一范式 1NF First normal form

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

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

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

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

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

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

第二范式 2NF Second normal form

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

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

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

第三范式 3NF Third normal form

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

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

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

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

声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。TEL:177 7030 7066 E-MAIL:11247931@qq.com