1.数据库三范式。

 

（1）一范式：每一个字段都对应着一条数据，这就叫一范式。

举个例子：下面的图上半部分就不是一范式，因为出现了表中套表的情况，需要把它拆分成图的下半部分，每个字段单独占一个属性。

                         

（2）二范式：若消除了非主属性对主键的部分函数依赖，那么它就符合二范式的要求。

举个例子：

                

看上面这个图，可以把它理解为一张学生表s，他有s（学生id），sname（学生姓名），age（年龄），addr（住址），c（课程号），grade（该课程的成绩）。那么这张表的主键必须是s（学生id）和c（课程号）两个属性，因为如果只有一个s（学生id）当主键，那么当某一名同学选了多门课，则无法通过s（学生id）这一个属性来唯一确定一条值。

但是如果将主键设置为s（学生id）和c（课程号）这两个属性，我们的sname（学生姓名），age（年龄），addr（住址）这三个属性，又仅仅可以通过主键其中一个s（学生id）属性就可以确定了。就是说s（学生id）就可以决定某个学生的部分信息。这样设置了两个属性当主键就会显得多余。而且他也不满足二范式的要求：存在了非主属性sname（学生姓名），age（年龄），addr（住址）对主键s（学生id）和c（课程号）的部分s（学生id）函数依赖。所以我们在设计的时候要将这个表进行拆分成下面这张图来使他满足二范式要求。

                  

（3）三范式：在二范式的基础上消除传递依赖，就是三范式。

举个例子：

              

看上面这个雇员表：EMP（雇员编号），sal_level(薪水等级)，salary(薪水)，我们先看如果这样设计了会出现什么问题。

比如我这个公司刚成立，一个员工也没有，但是我应该日后招了员工，他的薪水等级和薪水应该是存在而且先设定好的把？这样设计怎么体现没员工这种情况呢？

再或者我公司运营的很好，每个人都要涨工资，假如我有100个员工他们的薪水等级都是B，那么每一个B等级的工资我都要去修改。这显然很麻烦。

再比如，我现在公司薪水等级只有ABC三种等级，恰巧我也只有三个员工，他们的薪水等级也恰巧是ABC，那么这时候，如果任何一个员工离职，我删除他的信息的时候，会连同着薪水等级一起删除，这显然不符合常理。

这就是传递依赖：员工的薪水除了依赖主键，还依赖着薪水等级。所以我们要把这个表拆分成两张表来消除这种传递依赖，达到三范式的要求。