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

     

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

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

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

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

     

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

       一 属性的原子性

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

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

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

 

       A 属性的原子性

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

    

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

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

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

 

   

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

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

          同样,以上一个表设计为例,字段依旧分别为:货品_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

  

 

 

 

      

posted @ 2016-05-03 14:45  Lumia1020  阅读(2763)  评论(1编辑  收藏  举报