您好,登录后才能下订单哦!
这篇文章将为大家详细讲解有关如何进行数据库三大范式的分析,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。
一: 引言
作为一个数据库的学习者,搞懂关系数据库的三大范式是很有用的。然而教科书上有关数据库范式的介绍都是采用学术性的定义,语法羞涩,让人难懂,故写下自己对数据库范式的理解,给初学者提供帮助,也备日后查看。下面不介绍规范化程度高于3NF的范式,因为其在实际应用中基本不会用到,原因也是很明显的(查询代价变大),因此,对于很多大型复杂的系统,其数据库设计都没有遵循所谓的范式,这也是为什么会出现所谓的逆规范化,好了,进入正题吧。
二: 范式介绍
a:第零范式
第零范式就是指没有使用任何范式的设计,其添加数据的行为非常诡异,看看下表便知:
假设一个学生学习了三门课程,每门课程都有成绩,那么,采用第零范式的设计将会是如下情况
表a_0
这样的话,会使得往表中添加数据变得非常麻烦,每次添加一个新的数据,都要添加相应的字段,而且,因为表中其他的记录可能不需要这么多字段,因此会浪费
很多空间。如表a_1所示。
表a_1
由此可以看出,不对数据库任用任何范式是非常愚蠢的,因为不仅会产生大量无用的表字段,而且会使得表结构非常难以维护。由此,引出第一范式的介绍
b: 第一范式
第一范式就是在第零范式的基础上进行的改进,网上有很多人认为,所谓第一范式就是指表中的所有字段都是原子的、不可再分的,我个人认为此种理解也是正确的,原因不解释,我对第一范式的理解是,将
第零范式中重复的字段抽取出来,作为表的数据,从而形成一个稳定的、冗余数据少得表结构。
由此,可以得出符合第一范式的表结构应该是:
此时,表的结构变得稳定了,而且表中的冗余信息相对第零范式也少了很多。可是,第一范式只是关系数据库设计的最低满足的范式,第一范式中仍然有很多的冗余信息,由此,需要引入第二范 式。
c: 第二范式
第二范式是满足属性对主键是完全函数依赖的,因此,满足第二范式的表当然也是满足第一范式的,第二范式的目的就是消除表中的部分依赖。
这里,有几个概念要解释下,
1: 完全函数依赖
设有属性集K和P,若K中的所有属性共同能够推出P中的任意属性,且对于K的任何真子集,都不能推出P中的任意属性,则成K完全函数依赖P。
2: 部分函数依赖
与上相似,只是,K中存在真子集使得,该子集能推出p中任意属性。
概念性的东西,往往都难懂,举个例子,方便大家理解:
假如有一张学生成绩表,包含如下属性(学生Id,课程Id,课程分数,学生名字),其中,主键为(学生id,课程id),表中的数据如下:
那么,此时这张表的设计就不满足第二范式, 因为 主键(学生id,课程id) 能够唯一确定学生的姓名,因此,不满足属性完全函数依赖主键,因此不是第二范式。
从上面的表数据易知,不满足第二范式的表至少有以下几个缺点:
1:数据重复,浪费空间,因为每存一条记录,都要存学生的名字,这样就是得存在大量重复的数据。
2: 插入异常,若学生还没有成绩,那么这个学生就没有名字。
3: 更新异常,删除异常等
解决方法:
将student_name字段放入学生表中,即消除表中的部分依赖。
d: 第三范式
第三范式是指在满足第二范式的情况下,消除表中的传递依赖。
所谓传递依赖,就是指x-->y,y-->z,那么可以得到y-->z.
传递依赖常发生在主键、外键、外键相关的属性上,例如,假设有这样的表
学生表(学生id,学生姓名,院系id,院系名) ,此处主键为(学生id),外键为(院系id)
院系表(院系id,院长名称),主键为 (院系id)
很明显,此处存在传递依赖,因为 学生id 可以唯一确定 院系id,而 院系id 可以唯一确定 院系名。
表中的数据如下
从上面的表数据易知,不满足第三范式的表至少有以下几个缺点:
1 : 数据重复,浪费空间,因为学生表每存一条记录,都会记录住院系的名字,存在大量的重复数据。
2: 插入异常,若新建一个院系,而该院系没有学生的话,该院系就没有名字。
3: 更新异常,删除异常等
三: 数据库设计的经验
1: 表的数目不要太多,一般20-30张就够了。如果表的数目太多,则可以考虑采用同化操作,即将大体相同的实体放入到一张表中。
2:当数据库中的信息非常庞大时,不要使用外键(逆规范化),因为由此可能带来非常大的性能损失。
3:一般以消耗存储空间来换取效率。
关于如何进行数据库三大范式的分析就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。