数据库三范式

第一范式：

第一范式为了排除每个字段有重复的组出现，要求每个字段只有一个值，而其每个记录都能用用一个唯一的主键来识别。

比如下面这个订单表

订单表

姓名                购买数量

A              10,20

B              15,15

C              100,40,30

购买数量段存在多个值，这就不符合第一范式的要求了，购买数量字段的值要求是单一的，不能够重复。

姓名   购买数量

A       10

A       20

B       15

B       15

C       100

C       40

C       30

但是这样还不符合第一范式的要求，第一范式还有每个记录都能用一个唯一的主键来识别。所以：

标识符ID   姓名   购买数量

1        A     10

2        A       20

3        B     15

4        B     15

5        C     100

6        C     40

7        C     30

  这样就符合了第一范式原则。

下面这个也是违法了第一范式的列子，虽然一个字段只有单一值，但用很多个字段来表达一个事实也是违反第一范式的：

用户的爱好表（爱好最多三个）

姓名   爱好1   爱好2   爱好3

A     看电影  乒乓球   吃

B     篮球    看书    听歌

C     羽毛球  看电影   写代码

D     乒乓球          看电影

总结一下就是：所谓的第一范式，就是数据库表中的每一列都是不可分割的基本数据项，即所有字段都是原子级的，每一项记录要有一个唯一识别码。

我们要如何设计出符合第一范式的的原则的表：既然我们的每一个列要求不可再分，当我们设计过程中出现了每一列出现多值的情况下的时候，我们要定义一个新的实体，这个新的实体存储这些重复的属性。这样设计只有原实体和新实体之间就是一对多的关系了。

说明：第一个范式是关系型数据库的最基本的要求，不符合第一范式，就不是关系型数据库。

 

第二范式：

   有了第一范式也是不够的，比如这个表(学号，学生姓名、年龄、性别、课程、课程学分、系别、学科成绩，系办地址、系办电话)，存在下面这种依赖关系：

   （学号）→ (姓名, 年龄，性别，系别，系办地址、系办电话) 

(课程名称) → (学分)          

   （学号，课程）→ (学科成绩) 

这样就会出现：

数据冗余：同一个课程有n个学生修，则学分会重复n-1次。同一个学生修了m门课程，则姓名和年龄会重复m-1次。

更新异常：如果想调整一门课的学分，那么要把所有的学分值进行更新。如果要加入一门新的课程，但是这门课还没人选，但是没有学号关键字，所以课程和学分无法录入表中。

删除异常：如果一批学生已经修完一门课程，这些选修的记录被删除之后，同时课程和学分的记录也被删除了。显然，这样会导致插入异常。

所以我们还需要第二范式。

第二范式要求，首先要符合第一范式，然后是所有数据都和主键有唯一的依赖关系，如果存在部分关系，那么这些数据要单独设计在另一个表中。

比如下面这个例子：

ID  商品ID  商品名称      价格      地区     数量总价

1  1       A      1000    杭州1        1000

2  2       B        600      深圳2        1200

3  3       C        800      上海1      800

4  4       D      1200    深圳2        2400

这里，比如商品id和id一起组合形成一个主键，而商品名称和地址只和商品id有依赖关系（部分依赖），这就不符合第二范式的原则了。

所以最好把这些数据存到另一个表中。

ID 商品名称              价格           地区

1   A                 1000           杭州

2   B                 600           深圳

3   C                 800           上海

4   D                 1200          深圳

然后原来的表就变成这样了。

ID 商品ID   数量   总价

1  1     1    1000

2  2     2    1200

3  3     1    800

4  4     2    2400

总结一下就是：首先要符合第一范式，然后是所有属性都和主键有完全的依赖关系，不存在只依赖一部分的情况。

符合第二范式的表我们如何设计呢？如果有部分依赖的情况，我们应当将这一部分分出来，用一个新的实体表示。然后新的实体和原来的实体是一对多的关系。

 

第三范式：

所有非键属性都之和候选键有相关性，也就是说，非键属性之间应该是无关的。简单的说，就是一个数据库的表中，不能包含在其它表中已经存在其他表中的非主键属性的关键字信息。

比如这个表：

Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系： 

(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话) 

（学院）->（所在学院, 学院地点, 学院电话）

那么这里就存在了（所在学院, 学院地点, 学院电话）对学号的传递依赖。

即第三范式不能存在（关键字段-》非关键字段x-》非关键字段x）这样的传递依赖。

这样的传递依赖也会存在数据冗余、更新异常、删除异常。

这样我们的设计表的时候，要注意，如果出现这种情况，那么我们把那些传递依赖的属性弄一个新的表。这样可以有效地消除了冗余，不会出现更新异常，插入异常，删除异常等问题。

总结一下就是：非键属性之间应该是无关的，不能出现传递依赖。

 

关于第二范式、第三范式感觉好容易混淆。关键性的区别是：

第二范式，非主键属性要完全依赖于主键属性，不能只依赖主键的一部分。

第三范式，不能出现传递依赖，也就是说非主属性之间是没有关联的，传递依赖即非主键1依赖主键，非主键2依赖非主键1。

还有第一范式就是，每一列都是原子的不可分割的属性，每一项记录要有一个唯一识别码。