数据库之三范式

如果不想看理论性的数的话，又想重温一下数据库知识，又是日本动漫迷的话，可以看一下： 作为漫画和专业知识结合在一起的点子十分有创意，而且读起来也有趣。 数据库通过E-R，entity-relationship模型进行数据库的设计，根据具体的关系。 一对多，一个职员对

如果不想看理论性的数的话，又想重温一下数据库知识，又是日本动漫迷的话，可以看一下：

作为漫画和专业知识结合在一起的点子十分有创意，而且读起来也有趣。

数据库通过E-R，entity-relationship模型进行数据库的设计，根据具体的关系。

一对多，一个职员对多个客户。如果只有一个职员。

多对一，反过来。

多对多，多个职员对多个客户。

确定关系后，还需要进行normalization，规范化，分三范式。

先看看非规范化：

你会发现一个王国里面的商品又有两个列，你设计数据库的时候不会这样吧。

规范化有什么用呢？你一改一样水果的单价，就要全部都要改动，如果规范化之后，将水果单独分开，那就不会造成矛盾了。

第一范式：

第一范式，商品和订单分开。如果苹果单价一变化，就不用将非范式表中含有苹果的价格全部改过。

每一列都是不可分割的，除去了非规范式中的重复记录（记录就是一行）。

但是，存在的问题是，如果商品没有卖出去过，那么数量为0，也没有报表编码，但是我们确实需要商品的名称，单价和商品编码。

所以，继续看第二范式。

第二范式：

商品的名称，单价和商品编码单独做成一个表，通过商品编码这一列确定其他两个字段的值，这种原则成为函数依赖（functionally dependent）通过主键确定其他列的值。

回头看看报表编码，出口国编码这个表，第二范式。

报表编码可以确定出口国编码，确定出口国编码后再确定出口国名称。

问题所在，出口国编码虽然能通过一列确认其他值，但是如果出口国根本就没有进口过，那么所谓的商品编码便是不存在的。

第三范式：

只能由主键确定其他列值，而第二范式中出现的，由报表编码可以确定出口国编码，确定出口国编码后再确定出口国名称。这种通过某一列的值间接确定另外一列的值，我们成为传递依赖，第三范式去除传递依赖。

其实报表编码，商品编码，数量这一个表，和商品编码，商品名称，单价这一个表不只满足第二范式了，也满足第三范式了。

但是，第二范式中，报表编码，口国编码，出口国名称的表却不满足第三范式，因为有传递依赖，分割之后就满足第三范式了。

总结一下：

第一范式：列不可分，行中没有重复记录。

第二范式：通过主键确定其他列的值，通过其他列又确定其他列的值，会存在传递依赖。

第三范式：只能通过主键确定其他列的值，不存在传递依赖，其实第三范式就是特殊的第二范式。