数据库之三范式

假设不想看理论性的数的话，又想重温一下数据库知识，又是日本动漫迷的话，能够看一下：

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

数据库通过E-R，entity-relationship模型进行数据库的设计，依据详细的关系。

一对多，一个职员对多个客户。假设仅仅有一个职员。

多对一，反过来。

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

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

先看看非规范化：

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

规范化有什么用呢？你一改一样水果的单位价格。就要所有都要修改，假设规范化之后。将水果单独分开。那就不会造成矛盾了。

第一范式：

第一范式，商品和订单分开。

假设苹果单位价格一变化，就不用将非范式表中含有苹果的价格所有改过。

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

可是。存在的问题是。假设商品没有卖出去过，那么数量为0，也没有报表编码，可是我们确实须要商品的名称，单位价格和商品编码。

所以，继续看第二范式。

第二范式：

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

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

报表编码能够确定出口国编码。确定出口国编码后再确定出口国名称。

问题所在，出口国编码尽管能通过一列确认其它值，可是假设出口国根本就没有进口过。那么所谓的商品编码便是不存在的。

第三范式：

仅仅能由主键确定其它列值，而第二范式中出现的，由报表编码能够确定出口国编码，确定出口国编码后再确定出口国名称。

这样的通过某一列的值间接确定另外一列的值。我们成为传递依赖，第三范式去除传递依赖。

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

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

总结一下：

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

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

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