数据库 SQL ：数据库三大泛式简谈

相信，在学习数据库知识时，大家都会碰到这个概念问题：数据三大泛式，同时，在面试过程中，可能大部分面试官也会提及这个问题。

首先，看看维基百科对于三大泛式的定义：

数据库规范化，又称数据库或资料库的正规化、标准化，是数据库设计中的一系列原理和技术，以减少数据库中数据冗余，增进数据的一致性。关系模型的发明者埃德加·科德最早提出这一概念，并于1970年代初定义了第一范式、第二范式和第三范式的概念，还与Raymond F. Boyce于1974年共同定义了第三范式的改进范式——BC范式。

除外还包括针对多值依赖的第四范式，连接依赖的第五范式，DK范式和第六范式

下面，就不扯太多定义，谈谈本人，从网上及博客园博文中所理解到的三大泛式。关于三大泛式的定义，在之前有关一篇博文的评论中，我觉得总结的相当好。

       一 属性的原子性

       二 主键列与非主键列存在完全依赖关系

       三 非主键列间不存在函数依赖关系

       接下来，再来具体介绍介绍三大泛式内容。

       A 属性的原子性

        简而言之，即数据库表中每一列的值已为不可再进行分割最小单位。感觉这么一讲，还是 TMD 有点没扯太清。打个简单比方，比如：在电商网站中，存储用户收货地址信息(省市县信息)，在数据库表中，当然可以设置为一个字段，即可存储省市县全部地址字符串信息。但是，需要想清楚一个问题，数据库表设计始终要为代码设计，因此，如果在后续过程中，需要单独用到省、市字段信息，此时，如若还采取单个字段存储省市信息。那么，显示易见，即破坏了第一泛式设计。

B 主键列与非主键列存在完全依赖关系

在数据库表设计中，相信，大部分表设计，用户都会设置主键，以便作为唯一标识，便于增删查改中的删查改之用。而第二泛式提及的主键与非主键必须存在完全依赖关系，即严格表明了一点，为了减少冗余，必须每一个非主键与主键列必须完全依整，否则，将破坏第二泛式。

查看下表，其中为货品表，包括货品_ID、货品_Type、货品_Name、货品_Notice 四字段，货品_ID + 货品_Type 组成联合主键，货品_Notice 明显即即不完全依赖货品_ID 字段，而仅仅依赖货品_Type 字段。

C 非主键列间不存在函数依赖关系

         前面提到过，在数据库中，一般表设计，将包括唯一的主键标识以及非主键列，那么，在第二泛式中提到过，主键与非主键列必须存在完全依赖关系。而第三泛式中，明确表明，非主键列不能存在函数依整关系，不然，将会破坏第三泛式。

          同样，以上一个表设计为例，字段依旧分别为：货品_ID、货品_Type、货品_Name、货品_Notice 四字段，货品_ID为主键（注意此处区别），此时，会发现该表设计的问题，货品_Notice 与货物_Type 存在依赖关系，不符合设计要求。

       

          个人感想

          相信，很多刚出来工作的同学，进入公司时候，在见到公司数据库表设计时，就会严格按照以上提及的三大泛式，讲公司表设计不规泛，没有外键之类。但是，有时候要明白一点，设计归设计，数据库表设计始终于归于一点，最后为代码服务。

          所以，我们会看到种种设计，为了避免频繁连表查询，会在表中增加冗余字段，为了便于序列化，会在单个字段中存储 JSON 字符串或者 XML 信息。

          

         

参考资料：http://www.cnblogs.com/wuguanglei/p/4224893.html

https://zh.wikipedia.org/zh/%E6%95%B0%E6%8D%AE%E5%BA%93%E8%A7%84%E8%8C%83%E5%8C%96