4.2 关系数据库系统

 

 

图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的元组进行投影产生两个新的关系。

给定一个模式为{A₁，A₂，...，A_n}的关系R，可以把它分解为两个关系S和T，模式分别为{B₁，B₂，...,B_m}和{C₁，C₂，...，C_k}使得:

{A₁，A₂，...，A_n}={B₁，B₂，...,B_m}∪{C₁，C₂，...，C_k}

其中S中的元组时R的所有元组在{B₁，B₂，...,B_m}上的投影；各项T的元组时R的所有元组在{C₁，C₂，...，C_k}上的投影。

在学生关系中，我们把关系Student分解成关系模式S1（S-no,S-name,S-dept,M-name）和关系模式S2（S-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范式。

从学生关系中分解出来的关系模式S1（S-no,S-name,S-dept,M-name）,由于存在传递函数依赖的不属于第3范式。我们可以将S1分解成两个关系模式S11（S-no，S-name，S-dept）和S12（S-dept，M-name）。S11，S12均满足第2范式。

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

（3）数据库性能的优化

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

①     减少连接运算

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

②     减小关系大小和数据量

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

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

 

3.       物理设计

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

 

4.       应用程序设计及测试

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

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

 

5.       性能测试及企业确认

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

 

6.       装配数据库

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

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