数据库设计规范化及性能折衷

在上一篇《第二篇:严格的概念认识——关系、关系模型》,我们已经对关系及关系模型有了一个比较好的把握,并在文章结尾引了了关系模型的概念。在这篇文章中,我们会把关系模型的表示方法暂时简化一下,以便我们进一步研究、学习。简化后的表示方法如下:

  R(U,F)

  • R:关系的名称
  • U:关系的属性集合
  • F:在关系内部属性与属性的依赖关系。

这遍文章的重点将是讨论属性与属性之间的依赖、决定关系。可能有一个问题是:这些属性间的依赖是从何而来?比如说学号为什么就能确定班级?在这里告诉大家,属性间的依赖来自于需求,而并非固定不变。比如说,在省教育厅的数据库中,学习往往确定不了任何东西。

规范化

根据我的理解,数据库的规范化有这么几层:1NF、2NF、3NF、BCNF、4NF、5NF这么几种。而且,后边的范式包含了前边的范式,换句话说,一个关系,只要满足了后边的范式,那么它必定也满足前边的范式。在详细讲解每个范式之前,先提示大家一下:BCNF范式在实战中非常有用,因为它的判断相对简单、明了。这个我们在第一篇文章中已经讲过,在这里你可以把它与其它范式比较下:

  BCNF定义:关系模式R<U,F>符合1NF,若X->Y且Y不属于X时X必含有码,则R<R,F>符合BCNF

  附

  1. 1NF定义:每一个分量必须是不可分的数据项。其中,分量你可以看做表中一个属性的具体的值,不可分的意思其实就是能实实在在用明确的数字表示出来,需不是“利润率=X/X”这种没法用数据库直接存储的抽象公式。
  2. R:关系模式的名称
  3. U:属性集,相当于列名
  4. F:属性集上的函数依赖,可以把它理解的一套“哪些属性决定了哪些属性”的集合

1NF

上边已经给出了1NF的定义,可见1NF是基本,但并没有多少实际意义。

函数依赖

在讲其它范式之前,还必须讲几个相关的概念。像以前一样,我会以尽量通俗的文字描述。

函数依赖中有几个比较重要的依赖:传递函数依赖、完全函数依赖、及与其相对的部分函数依赖,这些概念是比较重要的。即使如此以下我会把其它的一些相关的概念也描述下,有兴趣的朋友可以了解下:

X->Y:X、Y都代表具体的属性集的子集,->表示函数确定(函数确定就是指知道了X就能知道Y,就像我们在学习里学习的函数那样,有x\y一一对应的关系,理解这个很重要,下面内容都是基于这点)整个表达式意思是:X函数确定Y,也可称为Y函数依赖于X。

  • 平凡的函数依赖:x->Y,且Y包含于X。
  • 非平凡的函数依赖:x->Y,且Y不包含于X。
  • 完全函数依赖:在R(U)中,如果X->Y,并且对于X的任何一个真子集X1,都有X1不函数确定Y,那么称Y对X完全函数依赖。
  • 部分函数依赖:对应的,如果X->Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖。
  • 传递函数依赖:在R(U)中,如果X->Y,(Y不包含于X),Y不函数确定X,但Y->Z,则称Z对X传递函数依赖,记作X_传递_>Y.

2NF

定义:如果R满足1NF,且每一个非主属性都完全函数依赖于码,则R满足2NF。举一个反例

(用户IP,页面)-->用户点击数;

用户IP-->用户地址

如果关系为 R(用户IP,页面,用户点击数,用户地址),那么这个关系R不满足2NF。

这种不满足范式的关系,总是让人觉得有大多冗余,有冗余就必定会造成更新的不一致。另外,这种关系本身的意义往往不能明确地表达出来,比如上例:一眼看上去,那个一个记录用户点击页面次数的表,但如果说它是一张用户访问来源的表也未尝不可。这种模棱两可的含义,势必造成后期困扰。

当然,以上说法比较经验化。理论上来说,这种不满足2NF的关系会造成插入异常、删除异常、修改复杂。但我觉得这种理论上的说法没什么可操作性。

3NF

关系模式R(U,F)中,若不存在这样的码X、属性组Y及非属性组Z(Z不包括与Y),使得X->Y,Y->Z成立,且Y不函数依赖于X,则称R满足3NF。

是不是很复杂?没实战意义吧?不如我们直接进入BCNF。因为两者差距甚小,但后者非常简洁、可操作。

BC`NF

我喜欢在中间加个符号^ ^,B、C其实是两个老外名字的首字母,这套我们已经吃习惯,不是么。这里就偏不道出他们的名字。

定义:关系模式R满足1NF,若X->Y且Y不包含于X时,X必含有码,则R满足BCNF。因为这点很重要,所以我要再把它去枝去叶。

首先,去掉前提关系模式R满足1NF,大家没意见吧,谁能举出一个不满足1NF的关系来?

再改后一句:对于任何属性组,找出他的依赖属性组,他的依赖属性必定包含码。这样就非常简洁了。

中断一下,是不是满足范式的层次越高的设计就越好?

答案是否定的,不知道大家是否察觉,所有范式都是跟据关系代数得出的理论东西。他不会考虑一些开销、性能问题。比果说,他不会考虑两个表链接时的开销;他也不会考虑这个表太大了严重影响性能,它更不会考虑索引的影响。但是、范式还是非常重要的,这点不加以论证。

结果语

讲到BCNF范式就已经讲了大半了,剩下还有4NF没讲,因为4NF为引入一些新的概念,如多值依赖,决定另起一篇文章讲解,下一篇将是《第四篇:数据库设计规范化之4NF及范式总结》

转载于:https://www.cnblogs.com/java-source/archive/2011/11/01/2604383.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值