关系模式规范化(上)

最近在学习数据库过程中,发现几本教材大都是按照数据库系统概论->关系数据库基础->SQL语言->关系数据库理论(大都是介绍规范化)介绍,第二部分的关系数据库基础主要谈到了基本算术运算关系和域运算,比如交并差,投影,选择,除法,元组关系演算等等,没有介绍如何合理设计一个数据库,可是如果作为一个数据库designer,必须了解如何设计与简化数据库,这都是数据模式规范化的内容。

如果不考虑数据库规范化,那么我们经常遇到的各种关系二维表,大都是易于理解与查阅,但是效率不高,主要体现在:

1.数据冗余度高,比如一个关系R(学号,学生姓名,课程,教室)中,假若一个学生选修N个课程,那么该学生的学号、姓名就要被重复记录N次,显然冗余度过大,浪费存储空间(但是便于我们直观的理解)。

2.数据修改复杂,再如上例中,假如需要修改学号,一个学生又修了N门课,那么需要修改N次姓名,效率何在?准确性谁能保证?

3.数据插入,删除异常,比如上例中,我暂时不知道某学生的学号,但是其他信息都知道,但我还是没法插入进去,如果删除的话,假如所有学生中只有一位学生选修了张三老师的课,那么现在需要删除该学生所在元祖的话,张三也会被删掉,这样一来,张三就从关系R中彻底消失了!

于是,这种低效率的关系表需要简化,需要拆分,需要规范化!

在规范化之前,需要阐明一些基本概念,因为规范化定义中会用到这些概念,这些基本概念名词定义听起来都文绉绉的,不过其实含义都很简单很明确,下面是一些基本概念:

1.函数依赖

对于关系R(U),X,Y是U的子集,若对于一个具体关系r,r中有任意两个元组s,t,且s(X)=t(X)能导致s(Y)=t(Y),则称X决定Y,Y依赖于X,记为X->Y。

含义就是:如果对于r中属性X中的每一个具体值,都有唯一的具体指Y与其对应,那么称Y依赖于X。类似于函数中的单值映射关系,反映了表中属性之间的决定关系。

2.完全函数依赖,部分函数依赖

扫描二维码关注公众号,回复: 10552887 查看本文章

若关系R(U)中,X->Y,且对于X的任意一个真子集X‘,X’不能->Y,那么说明Y完全依赖于X,否则,称为Y部分依赖于X。

3.函数依赖集

表中函数依赖的集合称为函数依赖集。

4.候选码形式定义

若在关系R(U,F)中,X是属性或属性集,U完全依赖于X,则X为R的候选码,简称码。

这是形式化的定义,定义暗指:候选码具有唯一确定性,能够唯一决定表中任一行,其次,候选码是具有最小性的,因为定义中强调了U完全依赖于候选码X,也就是X的子集是不能决定每一行的,那么便会得到以下结论:若X和Y都是候选码(或者两者有一个是),那么不能说(X,Y)是候选码,因为(X,Y)的真子集X或Y可以决定U,此时U不是完全依赖于(X,Y)。

下面先讨论第一、第二、第三范式。

第一范式(1NF):

如果关系R中的属性值都是不可再分的最小数据单位,则称为第一范式,记为R∈1NF。

根据定义,我们分别从横向和纵向去看,发现第一范式具有两个特点:

①不存在重复组,也就是每行的元祖不能又“内含”多个“小组”。

②不存在组合属性,也就是每个属性是单一的,明确的,不能属性里面又包含“小属性”。

1NF是很常见的,也是很容易设计的,只要保证每行每列都是单一的,不重复的即可。

第二范式(2NF):

若R中每个非属性组都完全依赖于R的任一候选码,且R∈1NF,则称为第二范式,R∈2NF。

根据定义,若判断某关系R是否为2NF,首先看是否存在非主属性对候选码的部分函数依赖,一旦存在,则不是2NF。那么如果不是2NF,应该如何分解使其满足2NF呢?

可以利用投影运算将其分解成三个关系(设候选码为XY),第一个是只依赖于X的子模式,第二个是只依赖于Y的子模式,第三个是完全函数依赖于XY的子模式。

由于2NF仅仅是消除了非主属性对候选码的部分函数依赖,还是存在一些问题的。

①数据冗余②修改复杂③插入删除异常。

之所以存在这些问题,因为2NF没有消除非主属性对候选码的传递函数依赖!因此需要继续分解……这就引入了下面的第三范式。

第三范式(3NF):

若关系R的任何一个非主属性都不传递函数依赖于任一候选码,则R∈3NF。

上述定义只是说明3NF中不存在非主属性间的函数依赖,但是不代表主属性间不存在函数依赖,也就是3NF中主属性间可能存在函数依赖。

还有一个性质,那就是3NF必然是2NF。

要判别一个关系R是否为3NF,那么可以进行一下步骤:

①找出候选码和非主属性

②看看是否存在非主属性对候选码的部分函数依赖,若存在,说明不是2NF,也就不会是3NF,否则进行下一步。

③判断非主属性间是否存在函数依赖,若不存在,则是3NF。

这么看来,经过上述2NF和3NF规范化后,似乎已经很“彻底”了,不过我们发现第二和第三范式只是将非主属性对候选码部分函数依赖和传递函数依赖消除了,还未消除主属性本身对候选码的部分函数依赖或者传递函数依赖,所以后来就有人提出了3NF的改进形式:BCNF。

……未完待续……

发布了75 篇原创文章 · 获赞 34 · 访问量 2019

猜你喜欢

转载自blog.csdn.net/chongchujianghu3/article/details/105205959