相信,在学习数据库知识时,大家都会碰到这个概念问题:数据三大泛式,同时,在面试过程中,可能大部分面试官也会提及这个问题。
首先,看看维基百科对于三大泛式的定义:
数据库规范化,又称数据库或资料库的正规化、标准化,是数据库设计中的一系列原理和技术,以减少数据库中数据冗余,增进数据的一致性。关系模型的发明者埃德加·科德最早提出这一概念,并于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