详细解析查看百度百科:数据库范式数据库
如何理解这几个范式的含义?光看字面意思就很是的晦涩!函数
这几种范式有什么意义呢?能够简单理解为是一种设计标准。url
通常咱们是如何设计表字段呢? 彷佛并无什么硬性的要求,能够把一个表搞成几个表,反过来也行;spa
几十个字段放一块儿也行,拆分在不一样的地方也行。可是,这种为所欲为的设计,项目是走不长远的 设计
1NF理解起来比较容易,关系型数据库通常都知足这个,是关系型数据库最基本的要求了。blog
即每一列所表明的数据属性是不可再分的,就像原子一眼,已是物质构成的最小单位。以下图:get
图1数学
商品类型列包涵了2种属性:分类ID与名称;hash
这在数据库表中是不可能存在的,即取数据的时候“商品类型”这一列不可能即表明名称又表明ID,符合1NF要求的表应该以下:it
图2
这样设计就比较清晰明了了;1NF比较好理解,通常都不会犯错误这种错误,但也不排除例外的。
好比难道就不能按照必定格式存储吗,好比这样:分类ID|分类名称、或这样:{cls=分类ID,title=名称}
固然能够那样作!你把“分类ID与类型名称”hash取值再取模再平方均可以。但那样就算是破坏了规则了,旁门左道说的就是如此。
好了,咱们的表也已经符合1NF了, 是否是这样就万事大吉了呢?咱们来试试看;
一、查看每一行数据,发现商品名称、分类ID、类型名称等信息重复屡次,数据冗余太大了,待改进!
二、新增记录,假设新设置了一个分类,前台维护数据会发生什么状况呢?
根据图2能够得知,表中的码(就是肯定惟一一行数据的一个或多个属性(字段))是:商品ID+日期,根据这个码,才能够区分数据表中的每一条记录
也就是说,这个码是非空的!你如今新增一个分类,码的信息都尚未,那就会直接致使插入异常,待改进!
三、修改记录,如今“名称1”的分类改变了,分类1要改为分类2;
发现有多少条“名称1”的记录就得把对应的分类1改为分类2,若是有上万条记录,估计鼠标都得换好几个,待改进!
四、删除记录,如今商品“名称1”下架了,得删除与之相关的信息,发现连分类、销售额等信息都被删掉了,待改进!
问题这么多,这彻底是胡乱设计致使的结果,怎么办才能避免这种结果呢,因而有了2NF
这句话有几个名称须要解析一下:
一、主属性,能够理解为码的子集;码就是由一个或多个主属性组成的;
二、非主属性,那固然就是主属性以外的全部字段咯。。
三、部分函数依赖,首先函数依赖能够参考数学里的方程式:y = f(x),即自变量x明确的状况下,y是明确可知的。
那这里说的部分函数依赖是什么意思呢,根据图2看下图
图3
参照上图, y = f(x) 可理解为:非主属性 = f(码),即码肯定的状况下,那些非主属性确定能获取到。
这个部分函数依赖,指的是部分非主属性对码的部分主属性产生依赖,有哪些呢?
很明显:右边的非主属性只对商品ID产生依赖,跟日期无关;
既然要求符合2NF,那就要消除这种部分依赖;那咱们就只能拆表了,以下:
图4
数据表也改好了,咱们再看看会不会还有问题。如今各表的码以下:
表1:码(商品ID+日期),非主属性“销售额”已经彻底依赖于码,不存在部分依赖了
表2:码(商品ID),非主属性也是彻底依赖于码
一、查看表2,变成基础数据了,每一个员工只有一条记录;查看表1,发现名称、分类等信息没有了,冗余少了不少,有改进!
二、新增记录,仍是新增新分类,而表2的码是“商品ID”,新增的分类显然不关员工的“商品ID”啥事,仍是会插入异常,待改进!
三、修改记录,仍是商品1改分类,由于拆表了,因此在表2把商品1对应的分类1改为分类2就好了,只改了一行数据就搞定!有改进!
四、删除记录,删除商品1相关信息,发现分类仍是被删掉了,待改进!
看来拆表了仍是没有彻底解决问题呀,为何会这样呢,非主属性已经彻底依赖于码了呀?因而3NF出场了
非主属性:这个不用多说了,上面已经解析过。
传递函数依赖:这个能够理解为2个或多个函数依赖组成的,如:A=f(B) , B = f(C),则 A = T(C)
即由C可获得B,由B可获得A,那由C可获得A,中间多了一层。
那图4存在哪些传递依赖关系呢,以下:
在商品ID肯定的状况下,可获得分类ID,再由分类ID获得分类名称,这就是所谓的传递函数依赖
咱们再继续拆表,以下:
图5
好了,如今看看表一、二、3;彻底都符合要求,便是原子性,又没有部分函数依赖,也没有传递函数依赖;
一、彻底没有数据冗余,数据很简洁
二、新增记录,新增分类,改动的只是分类基础数据表,跟其余表无关。有改进!
三、修改记录,商品1改分类,只改动商品基础数据表,跟其余表无关。有改进!
四、删除记录,删除商品1相关记录, 删除的也是商品基础数据表,和销售表与分类表无关。有改进!