数据库设计三大范式

理解三大范式

什么是三大范式：

第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要

求，否则，将有很多基本操作在这样的关系模式中实现不了。

第二范式：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。

第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF.

注：关系实质上是一张二维表，其中每一行是一个元组，每一列是一个属性

第一范式

   1、每一列属性都是不可再分的属性值，确保每一列的原子性

   2、两列的属性相近或相似或一样，尽量合并属性一样的列，确保不产生冗余数据。

如果需求知道那个省那个市并按其分类，那么显然第一个表格是不容易满足需求的，也不符合第一范式。

显然第一个表结构不但不能满足足够多物品的要求，还会在物品少时产生冗余。也是不符合第一范式的。

第二范式

每一行的数据只能与其中一列相关，即一行数据只做一件事。只要数据列中出现数据重复，就要把表拆分开来。

一个人同时订几个房间，就会出来一个订单号多条数据，这样子联系人都是重复的，就会造成数据冗余。我们应该把他拆开来。

这样便实现啦一条数据做一件事，不掺杂复杂的关系逻辑。同时对表数据的更新维护也更易操作。

第三范式

 数据不能存在传递关系，即每个属性都跟主键有直接关系而不是间接关系。像：a-->b-->c  属性之间含有这样的关系，是不符合第三范式的。

比如Student表（学号，姓名，年龄，性别，所在院校，院校地址，院校电话）

这样一个表结构，就存在上述关系。 学号--> 所在院校 --> (院校地址，院校电话)

这样的表结构，我们应该拆开来，如下。

（学号，姓名，年龄，性别，所在院校）--（所在院校，院校地址，院校电话）

最后：

三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。

第一范式

所谓第一范式，就是数据表的列不可再分。

看下面数据表，对于选课列明显是可以再分的，所以它是违反第一范式的。

第二范式

第二范式是指，首先满足第一范式，并且表中非主键列不存在对主键的部分依赖。

看下面的学生选课表：

表中主键为 （学号，课程），我们可以表示为 (学号，课程) -> (成绩，课程学分)， 表示所有非主键列 (成绩，课程学分)都依赖于主键 (学号，课程)。 但是，表中还存在另外一个依赖：（课程）->(课程学分）。这样非主键列 ‘课程学分‘ 依赖于部分主键列 ’课程‘， 所以上表是不满足第二范式的。

我们把它拆成如下2张表：

学生选课表：

 课程信息表：

 那么上面2个表，学生选课表主键为（学号，课程），课程信息表主键为（课程），表中所有非主键列都完全依赖主键。不仅符合第二范式，还符合第三范式。 

再看这样一个学生信息表：

上表中，主键为：（学号），所有字段 （姓名，性别，班级，班主任）都依赖与主键（学号），不存在对主键的部分依赖。所以是满足第二范式。

第三范式

第三范式定义是，满足第二范式，并且表中的列不存在对非主键列的传递依赖。

对于上面的学生信息表，虽然满足第二范式，所有字段都依赖主键（学号），但是，表中存在一个传力依赖，(学号）->(班级）->（班主任）。也就是说，（班主任）这个非主键列依赖与另外一个非主键列 （班级）。所以不符号第三范式。

把这个表拆分成如下2个表，

学生信息表：

班级信息表：

这样，对主键的传递依赖就消失了。上面的2个表都符合第3范式。

更高级别的范式

对应上面的班级信息表，完全可以设计成这样：

这显然是符合第三范式的，所有列都依赖主键（班级），也不存在传递依赖。但是列（班级人数） 显然可以通过统计方法获得，出现在这张表，会造成维护困难或者不一致的情况。这就需要更高级别范式的约束。