您的位置: 网站首页 > 公共课 > 计算机软件技术基础 > 第4章 数据库系统 > 【4.2 关系数据库系统】

4.2 关系数据库系统

4.2       关系数据库系统

 

4.2.1关系数据库系统的特点

 

1)关系模型以二维表的形式表示,它既能表示实体,又能表示实体间的联系,数据结构简单清晰,概念单一,易学易懂。

2)可以直接处理实体间111mmn等关系。

3)一条查询命令可以同时获取满足该条件的多个记录,查询效率较高。

4)数据独立性高,用户只需要按命令要求查询数据,不必关心数据的物理存储。

5)有较坚实的理论基础,保证设计质量。

 

4.2.2关系数据库有关概念

 

1.       关系

 

关系是一张二维表,每个关系有一个关系名,表的各列称为属性,标的每行成为元组。

 

2.       关键字(码)

 

属性或属性的组合。如果其值能唯一的标识一个元组称为候选关键字。在一个关系中可能有多个候选关键字,从中选择一个作为主关键字(主码)。

 

3.       关系模式

 

关系的名称与关系的属性集称为关系模式,用关系名(属性名1,属性名2...,属性名n)来表示。

 

4.       关系模型

 

在数据库设计中包含一个或多个关系模式,这些关系模式的集合称为关系模型。

 

5.关系数据库系统

 

以关系模型为基础的数据库系统。

 

            关系代数

 

对用户来说,面对数据库的主要问题是如何从数据库中获取所需要的信息,关系代数是一种抽象的查询语言,通过对关系的运算来表达查询要求。关系代数运算的对象是关系,运算结果也是关系。

 

1.       并运算(

RS为同类关系,RS的结果是R中元素和S中元素共同组合成的集合,两个关系中相同的元素只能在RS中出现一次。

2.       交运算(

RS为同类关系,RS的是即出现在R中又出现在S中元素组合成的集合。

3.       差运算(

RS为同类关系,R–S的是只在R中出象,不再在S中出现的元素组合成的集合。

4.       笛卡尔积(χ)

RχS是一个新关系,它把RS的元组以所以可能的方式组合起来,因此RχS拥有的元组数量应是R的元组与S的元组数的乘积。设关系R有两个属性AB,如图4.1所示;关系S有三个属性BCD,如图4.2所示;由于RS关系中有同名属性B,故用R.BS.B来表示,因此在关系RχS中应有五个属性:AR.BS.BCD,有6个元组,如图4.3所示。

                  

 


4.1 关系R                                    4.2 关系S

 

 

                     4.3 关系RχS

5.  选择(σ)

对关系R进行选择运算,将产生一个新关系SS的元组集合是R中满足条件C的子集。

                S=σ(R)

.  投影(∏)

从关系中挑选在若干个属性组成新的关系成为投影。这是从列的角度进行的运算,相当于对一个关系进行垂直分解。新关系所包含的属性个数往往比原关系少,如果新关系中包含有重复元组,则要删除重复元组。

                S=∏(R)

S是在关系R中挑选以x为一组属性构成的新关系。

7.       连接()   

(θ) 

两个关系R和S基于条件xθy的连接为

                   R

                   xθy

其中θ是比较运算符,当θ为“=”时,称为等值连接。

考虑图4.1和图4.2中的R和S,S 的结果为图4.4所示。

               R.S.B

              图4.  关系R

                   .≠S.B

 

8. 自然连接(

它是除去重复属性后的等值连接,是最常用的连接方式。

两个关系RS的自然连接记作R∞S,得到新的关系如图4.5所示。

                             4.5 关系RS

只有当两个关系的元组在所有重复属性上取值都相同时,才可以将它们的组合放入自然连接中。例如关系U和V有两个重复属性B和C,如图4.6所示,则其自然连接结果应如图4.7所示。

    

(1)   关系U                            (2)关系

图4.6 关系U和关系V

                   

                              4.7 关系UV

 

   9. 复合运算

如果将以上的各种运算符加以组合,就能完成功能强大的查询,必要时还可以使用括号来表明运算的先后次序。

例4.1        设有同学关系模式为

Student(S-NO,S-Name,Age,Dept)

若想查询计算机系,年龄大于18岁的学生学号(S-NO)和姓名(S-Name),可以用如下的关系代数表达式

        S-NO,S-Name(σAge>18 and Dept=“计算机”Student)

例4.2        已知学生选课关系SCS-NO,Course-NO,Score),现在想查询成绩超过80分的学生姓名。它涉及Student SC两个关系,可以用如下关系代数表达式

            S-Name(σScore>80(Student∞SC))

 

    数据库设计

 

设计与使用数据库的过程是把现实世界的数据经过人为加工和计算机处理,重新为现实世界提供信息的过程。数据库的生命周期分为两个阶段:一是数据库的分析设计阶段,二是数据库的实施和运行阶段。其中数据库的设计阶段是数据库生命周期中工作量比较大的一个阶段,其质量对整个数据库系统的影响很大。

数据库设计的基本任务包括数据模式设计和应用程序设计。前者表达了对数据库的内容及结构要求,也就是静态要求;后者表达了基于数据库的数据处理要求,也就是动态要求。由于应用程序是随着应用而不断发展的,因此数据库设计的最基本成果是数据模式。我们在后面的讨论也侧重在这方面。

一般数据库设计需经历以下几个步骤:

 

 

1.       需求分析

 

需求分析是设计人员和用户密切合作,对数据库用户作系统的调查与分析,使设计人员对用户需求有全面准确的理解。在调查分析的基础上提出概念数据模型,一般采用E-R图,它表示数据及其相互间的联系,其目标是为了准确描述应用领域的信息模式,支持用户地各种应用,它是独立于任何数据库管理系统、面向现实世界的数据模型,不能直接用于数据库的实现。

E-R图作为概念设计的工具,比较自然地反映了现实世界,但由于设计者和用户对客观世界的理解和观察各有不同,因此同一个设计对象对于不同的设计者又设计出不同的数据模型。

E-R图设计一般从局部模式开始,提出局部视图——局部E-R图,然后进行视图的集成,得到全局视图——全局E-R图。在集成过程中,应尽可能合并对应的部分,保留特殊的部分,删除冗余的部分,力求简明清晰。最后的E-R图作为逻辑设计的基础。

2.逻辑设计

 

逻辑设计的任务是把数据概念模式变换为数据库逻辑模式。数据库逻辑设计依赖于逻辑数据模型和所采用的数据管理系统。关系模型和关系数据管理系统早已被广泛使用并成为主流,所以这里讨论的是以关系模型和关系数据系统为基础的逻辑设计方法。

1E-R图到关系模式的转换

· 实体的转换

E-R图重点每个实体集,需要建立一个关系与之对应,每一个关系需确定一个主关键字。例如,有学生实体集S和课程实体集T,入图4.8所示。

 

    

(1) 学生实体集S                             (2) 课程实体集T

4.8 学生实体集和课程实体集

将图中的学生和课程实体集转换成关系ST

S(姓名,出生年月,学号,性别,系名,班号)主关键字:学号

T(教师,课程名,学分,课程号)主关键字:课程号

 

·联系的转换

下面分1:1联系、1:m联系和m:n联系三种。

  1:1联系

这种联系一般可以通过外部关键字来建立两个实体之间的联系。

例如图4.9,设大学中每个班由一个班长,而且只有一个班长,学号与班级之间有班级这个1:1的联系,可以转换为关系模式S,T。


 

 

图4.9  1:1 联系举例

 

S(学号,姓名,性别,出生日期)主关键字:学号

T(班号,姓名,地点,学号,任期)主关键字:班号;外部关键字:学号

  1:m联系

这种联系也可通过外部关键字建立联系。例如图4.10,设大学中教师与系之间有“系籍”这个1:m的联系,即每个教师必属于一个系,可以转换成关系S,T。

图4.10 1:m 联系举例

 

S(教师号,姓名,性别,出生日期,教会,编号)主关键字:教师号;外部关键字:编号

T(编号,名称,地点)主关键字:编号

  m:n联系

m:n与前两种联系不同,不能用外部关键字来作为联系,必须用两个实体的主关键字才能识别一个联系。如图4.11的例子,设大学中学生和课程之间有“选课”这样一个m:n的联系,可以转换成关系模式R、S和T。

R(学号,出生日期,性别,姓名,系别)主关键字:学号

S(课程号,课程名,成绩)主关键字:课程号

T(学号,课程号,成绩)主关键字:(学号,课程号)

在T中,学号,课程号为外部关键字。

图4.11 m:n 联系举例

 

 

  多元联系

在多元联系中,一般取各个实体的主关键字组合成一个联系的复合主关键字。例如图4.12中,设大学中教师,学生和课程之间有一个“授课”的多元联系,可以转换成关系模式R、S、T、W。

图4.12 多元联系举例

 

R(学号,姓名)主关键字:学号

S(教师号,系别)主关键字:教师号

T(课程号,课程名,学分)主关键字:课程号

W(学号,教师号,课程号,成绩)主关键字:(学号,教师号,课程号)

在W中,学号,教师号,课程号均为外部关键字。

(2)逻辑模式的规范化

·问题的提出

关系数据库逻辑设计的最终目标是要确定关系模式的划分及每个关系模式所包含的属性,从而使由一组关系模式组成的关系模型作为一个整体,它既能客观点描述各种实体,又能准确反映实体间的联系,还能如实的体现出实体内部属性之间的相互依赖与制约;此外,我们还应该了解,由于关系模式设计不当,可能会带来什么问题,并从函数依赖的角度分析产生这些问题的症结所在;最后在此基础上探讨解决这些问题的途径。

在关系数据模式转换时,很容易出现的问题是冗余性,即一个事实在多个元组中重复。当我们企图把太多的信息存放在一个关系中时,就会出象数据冗余和更新异常等问题。例如有同学关系为:

S-no     S-name    S-dept    M-name    C-name      Grade

021230         自动化    李有光    控制理论      95

021003         自动化    李有光    C语言         90

021003         自动化    李有光    微机原理      92

022400   高于红                建筑原理      88

023534         计算机          编译原理      85

023301   李小红    计算机          操作系统      93

023534         计算机          数据库        89

 

在操作时出现的问题主要有:

   数据冗长  如学生所在系和系主任名

   更新异常  例如当计算机系主任更名时,可能由于疏忽,没有全部修改,出现了数据的不一致。

   删除异常  如果学生高于红不选修建筑原理课,那么这个纪录就无法存在,因为该关系是由学号(S-no)和课程名(C-name)组成的主关键字,而主关键字项的属性值不能为“空”,这样与高于红有关的其他信息将会消失。

 插入异常  当学生还没有选课时,由于主关键字中缺少课程名值,导致学生的基本情况(学号,姓名,所在系等)都不能插入。

根据上述情况,促使我们思考一些问题,即属性的组合与数据冗余和更新异常有什么关系?属性之间有什么相互联系?为了构成一个好的关系模式应该考虑哪些原则?如何将一个不太好的关系模式转换为较满意的模式?

从关系内部属性之间的联系,使我们很自然的想到主关键字和属性之间的函数依赖问题。由于主关键字能唯一的确定一个元组,所以也可以说主关键字函数决定该关系中的所有属性。我们把主关键字所在的属性成为主属性,而把主关键字以外的属性称为非主属性。例如上述例子中,S-no和C-name为主属性,其他四个属性为非主属性。

再进一步分析,可以发现,不同的属性对主关键字函数依赖的性质和程度是有差别的,有的属于直接依赖,有的属于间接依赖(传递依赖);当主关键字由的多个属性组成时,有的属性函数依赖于整个主关键字属性集,而有的属性只函数依赖于主关键字属性中的一部分属性。因此下面首先讨论属性间的函数依赖关系。

·函数依赖性

  完全函数依赖和部分函数依赖

若属性A函数依赖于属性W,记作W→A,如果存在W的真子集V,而函数依赖V→A成立,则称A部分函数依赖于W,记作WA。若不存在这种V,则称A完全函数依赖于W,记作WA。

由上述定义可以得出一个结论,若W为单函数,则不存在真子集V,所以A必须完全依赖于W。

结合上面的学生例子,关系模式student(S-no,S-name,S-dept,M-name,C-name,Grade)中(S-no,C-name)为主关键字,函数依赖如下:

S-no→S-name,S→dept

S-dept→M-name

S-no→M-name

    S-no,C-nameS-name,S-dept,M-name

S-no,C-name Grade

可以看出,属性S-name,S-dept和M-name都属函数依赖于S-no,而部分依赖于主关键字(S-no,C-name0.

对于主关键字完全函数依赖的属性S-name、S-dept和M-name,由于它们只依赖于S-no,因此当一个学生选修几门课时,这些数据会多次重复出现,造成大量的数据冗余。同时当对一个学生的基本情况进行更新时,会出现各种异常。

  传递函数依赖

如果X→Y(Y函数依赖于X),而Y-﹨->X (X不函数依赖于Y),而Y→Z成立,则称Z对X传递函数依赖,记作XT。这里要注意:如果X→Y,且Y→X,即X,Y相互依赖(X←→Y),那么Z与X之间就不是传递函数依赖,而是直接依了,例如,学生中没有重名现象,则学号与姓名之间就属于相互依赖,S-no←→S-name。

我们还是以学生关系为例:

S-no→S-dept,S-dept→-name,S-noM-name

由于一个系有很多学生,所以S-dept-﹨->S-no,因此M-name传递函数依赖于S-no。

由上例可以看出,关系模式中非主属性对主属性的部分函数依赖和传递函数依赖是产生数据冗余和更新异常对主要根源。

·规范化理论

找到了问题的所在,也就有了解决问题的途径——消除关系模式中各属性的冗余依赖。所谓冗余依赖是指部分函数依赖和传递函数依赖。从不同的分析与解决问题的角度出发,导致解决问题的深度与效果也会有所不同,我们把解决的途径分为几个不同的级别,用属于第几范式来加以区别。

通过对低级范式的关系模式进行分析,转换为几个属于高一级范式的关系模式集合,这一过程称为规范化。

  第1范式(1NF)

如果一个关系模式R中所有属性都是不可分的基本数据项,则这个关系模式属于第1范式,这是对关系模式最起码的要求。例如上述的学生关系模式满足第1范式。

  第2范式(2NF)

若关系模式R属于第1范式,且每个非主属性都是完全函数依赖于主属性,则R属于第2范式。

在学生关系模式中,存在如下依赖关系:

S-no,C-nameS-name,S-dept,M-name

显然不属于第2范式。现在要对它进行分解,使其满足第2范式条件。

对关系R的分解包括两个方面,一方面把R的属性分开,以构成两个新的关系模式;另一方面是通过对R的元组进行投影产生两个新的关系。

给定一个模式为{A1A2...An}的关系R,可以把它分解为两个关系ST,模式分别为{B1B2...,Bm}{C1C2...Ck}使得:

{A1A2...An}={B1B2...,Bm}{C1C2...Ck}

其中S中的元组时R的所有元组在{B1B2...,Bm}上的投影;各项T的元组时R的所有元组在{C1C2...Ck}上的投影。

在学生关系中,我们把关系Student分解成关系模式S1S-no,S-name,S-dept,M-name)和关系模式S2S-no,C-name,Grade)。

分解后,关系模式S1,关键字为S-no,有如下的函数依赖:

S-no→S-name,S-dept,M-name    S-dept→M-name

由于关键字是单属性,不可能出现部分函数依赖,因此S1属于第2范式。

分解后,关系模式S2关键字为{S-no,C-name}函数依赖如下:

S-no,C-name→Grade

非主属性Grade完全函数依赖于关键字,也满足第2范式。

 

  第3范式(3NF)

若关系模式R属于第2范式,且每个非主属性都不传递依赖于主属性,则R属于第3范式。

从学生关系中分解出来的关系模式S1S-no,S-name,S-dept,M-name,由于存在传递函数依赖的不属于第3范式。我们可以将S1分解成两个关系模式S11S-noS-nameS-dept)和S12S-deptM-name)。S11S12均满足第2范式。

如果进一步消除现有关系模式中的其它依赖关系,还可以获得更高的范式,这里就不再讨论。

3)数据库性能的优化

在前面的模式设计中,我们只侧重考虑模式的合理性。而较少注意数据库的性能问题,即操作的合理性。从逻辑设计的角度来改善数据库性能,可以有以下几种措施:

     减少连接运算

连接是开销最大的运算,参与连接的关系越多,开销越大。因此对于一些常用的、性能要求比较高的数据库的查询最好是一元操作。这与规范化的要求往往是矛盾的。有时为了保证性能,不得不牺牲规范化要求。

     减小关系大小和数据量

关系的大小对查询的速度影响很大。有时为了提高查询速度,把一个关系分成多个小关系是有利的。例如可以把全校学生的数据放在一个关系中,也可以按系建立学生关系,后者可以提高一个系范围内的查询速度,这是把关系从水平方向分割。有时也可以从垂直方向分割,例如有些属性要经常查询,有些则很少用到,如果放在一个关系中,数据量较大,影响查询速度,若分成两个关系,则可提高常用常用查询的速度。

由此可见,数据库的设计需要根据实际情况,因时、因地灵活掌握,才能设计出最合理的关系模式。

 

3.       物理设计

物理设计是在计算机的物理设备上确定应采取的数据存储结构和存取方法,以及如何分配存储空间等。确定之后,用系统选定的DBMS提供的数据定义语言,把逻辑设计的结果描述出来。对于关系型的DBMS,物理设计的主要工作是由系统自动完成的,用户可做的事很少。

 

4.       应用程序设计及测试

数据库应用系统的程序设计属于一般的程序设计范畴,但数据库应用程序有自己的一些特点,例如大量使用的屏幕显示控制语言、复杂的输入输出屏幕、形式多样的输出报表、灵活的交互功能等。为了加快应用系统开发速度,应选择良好的第四代语言开发环境,应用自动生成技术、可重用模块技术等开发工具。

程序编写完成后,应按照系统支持的各种应用,分别测试它们在数据库上的操作情况,测定能否完成预定点功能。

 

5.       性能测试及企业确认

当有部分数据装入数据库后,就可以对数据库系统进行联调,这个过程也称为数据库的试运行。在这个阶段,除了对应用程序作进一步测试之外,重点是执行对数据库的各种操作,实际测量系统的性能指标,检查是否达到设计要求。

 

6.       装配数据库

组织数据入库是十分费事的,一般都是通过系统提供的实用程序或专门的录入程序来完成。如果运行调试后又要修改数据库设计,则又要重新组织数据入库,因此应分批分期输入数据。

数据库投入运行意味着开发任务基本完成和维护工作的开始,任何数据库只要它存在一天,它的设计就得不断地进行评价、调整、修改甚至改变,这就是数据库的运行、维护工作。