关系数据库.docx

关系数据库.docx

《关系数据库.docx》由会员分享，可在线阅读，更多相关《关系数据库.docx（13页珍藏版）》请在冰豆网上搜索。

关系数据库

第五章关系数据库

第五章

5．1数据库设计的基本步骤

按照规范设计的方法，同时考虑到数据库开发的全过程，可以将数据库设计分为六个阶段：

●需求分析阶段

●概念结构设计阶段

●逻辑结构设计阶段

●物理设计阶段

●数据库实施阶段

●数据库运行和维护阶段

6．2数据库需求分析

需求分析的任务是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。

新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库。

需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。

●信息要求

是指用户需要从数据库中获得信息的内容与性质。

由用户的信息要求可以导出数据要求，即在数据库中需要存储哪些数据。

●处理要求

是指用户要求完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。

新系统的功能必须能够满足用户的信息要求、处理要求。

●安全性与完整性要求

确定用户的最终需求其实是一件很困难的事，这是因为一方面用户缺少计算机知识，开始时无法确定计算机究竟能为自己做什么，不能做什么，因此无法一下子准确地表达自己的需求，他们所提出的需求往往不断地变化。

另一方面设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。

此外新的硬件、软件技术的出现也会使用户需求发生变化。

因此设计人员必须与用户不断深入地进行交流，才能逐步得以确定用户的实际需求。

采取的方法

⑴首先调查组织机构情况

⑵然后调查各部门的业务活动情况

⑶协助用户明确对新系统的各种要求

⑷确定新系统的边界

常用的调查方法有：

⑴跟班作业

⑵开调查会

⑶请专人介绍

⑷询问

⑸问卷调查

⑹查阅记录

6．3概念结构设计

概念设计的重点在于信息结构的设计，它是整个数据库系统设计的关键。

它独立于逻辑结构设计和DBMS.

设计概念结构通常有四类方法：

●自顶向下

●自底向上

●逐步扩张

●混合策略

但无论采用哪种设计方法，一般都以E-R模型为工具来描述概念结构。

以自底向上设计概念结构的方法为例，它通常分为两步：

第一步，首先要根据需求分析的结果（数据流图、数据字典等）对现实世界的数据进行抽象，设计各个局部视图即分E-R图。

标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型（1:

1、1:

n、m:

n）。

现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。

对象和实体之间是“ismemberof”的关系。

例如在学校环境中，可以把张三、李四、王五等对象抽象为学生实体。

对象类型的组成成分可以抽象为实体的属性。

组成成分与对象类型之间是“ispartof”的关系。

例如学号、姓名、专业、年级等可以抽象为学生实体的属性。

其中学号为标识学生实体的码。

实际上实体与属性是相对而言的，很难有截然划分的界限。

同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为“实体”。

一般说来，在给定的应用环境中：

①属性不能再具有需要描述的性质。

即属性必须是不可分的数据项。

②属性不能与其他实体具有联系。

联系只发生在实体之间。

例：

学籍管理局部应用中主要涉及的实体包括学生、宿舍、档案材料、班级、班主任。

那么，这些实体之间的联系又是怎样的呢？

由于一个宿舍可以住多个学生，而一个学生只能住在某一个宿舍中，因此宿舍与学生之间是1:

n的联系。

由于一个班级往往有若干名学生，而一个学生只能属于一个班级，因此班级与学生之间也是1:

n的联系。

由于班主任同时还要教课，因此班主任与学生之间存在指导联系，一个班主任要教多名学生，而一个学生只对应一个班主任，因此班主任与学生之间也是1:

n的联系。

而学生和他自己的档案材料之间，班级与班主任之间都是1:

1的联系。

接下来我们需要进一步斟酌该E-R图，做适当调整。

（1）在一般情况下，性别通常作为学生实体的属性，但在本局部应用中，由于宿舍分配与学生性别有关，根据准则２，应该把性别作为实体对待。

（2）数据存储“学生登记表”，由于是手工填写，供存档使用，其中有用的部分已转入学生档案材料中，因此这里就不必作为实体了。

这样，得到学籍管理局部应用的分E-R图，如图所示。

为节省篇幅，该E-R图中省略了各个实体的属性描述。

这些实体的属性分别为：

　　学生：

｛学号，姓名，出生日期，｝

档案材料：

｛档案号，……｝

班级：

｛班级号，学生人数｝

班主任：

｛职工号，姓名，性别，是否为优秀班主任｝

宿舍：

｛宿舍编号，地址，人数｝

教室：

{教室编号，地址，容量}

其中有下划线的属性为实体的码。

同样方法，我们可以得到课程管理局部应用的分E-R图，如图6-13所示。

各实体的属性分别为：

学生：

｛姓名，学号，性别，年龄，所在系，年级，平均成绩｝

课程：

｛课程号，课程名，学分｝

教师：

｛职工号，姓名，性别，职称｝

教科书：

｛书号，书名，价钱｝

教室：

｛教室编号，地址，容量｝

第二步，集成局部视图即设计全局E-R图。

集成局部E-R图时都需要两步：

1）合并；2）修改与重构。

各分E-R图之间的冲突主要有三类：

属性冲突、命名冲突和结构冲突。

1.属性冲突

（1）属性域冲突，即属性值的类型、取值范围或取值集合不同。

（2）属性取值单位冲突。

2.命名冲突

（1）同名异义。

（2）异名同义（一义多名）。

3.结构冲突

（1）同一对象在不同应用中具有不同的抽象。

例如“课程”在某一局部应用中被当作实体，而在另一局部应用中则被当作属性。

（2）同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序不完全相同。

（3）实体之间的联系在不同局部视图中呈现不同的类型。

例如实体E1与E2在局部应用A中是多对多联系，而在局部应用B中是一对多联系；又如在局部应用X中E1与E2发生联系，而在局部应用Y中E1、E2、E3三者之间有联系。

解决方法是根据应用的语义对实体联系的类型进行综合或调整。

下面我们来看看如何生成学校管理系统的初步E-R图。

我们着重介绍学籍管理局部视图与课程管理局部视图的合并。

这两个分E-R图存在着多方面的冲突：

（1）班主任实际上也属于教师，也就是说学籍管理中的班主任实体与课程管理中的教师实体在一定程度上属于异名同义，可以应将学籍管理中的班主任实体与课程管理中的教师实体统一称为教师，统一后教师实体的属性构成为：

教师：

｛职工号，姓名，性别，职称，是否为班主任｝

（2）将班主任改为教师后，教师与学生之间的联系在两个局部视图中呈现两种不同的类型，一种是学籍管理中教师与学生之间的指导联系，一种是课程管理中教师与学生之间的教学联系，由于指导联系实际上可以包含在教学联系之中，因此可以将这两种联系综合为教学联系。

（3）在两个局部E-R图中，学生实体属性组成及次序都存在差异，应将所有属性综合，并重新调整次序。

假设调整结果为：

（4）学生：

｛学号，姓名，出生日期，年龄，所在系，年级，平均成绩｝

解决上述冲突后，学籍管理分E-R图与课程管理分E-R图合并为初步E-R图。

修改与重构，生成基本E-R图

修改、重构初步E-R图以消除冗余主要采用分析方法。

除分析方法外，还可以用规范化理论来消除冗余。

图6-17是进行修改和重构后生成的基本E-R图。

6．4逻辑结构设计

设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。

设计逻辑结构时一般要分三步进行：

●将概念结构转换为一般的关系、网状、层次模型，并将转化来的关系、网状、层次模型向特定DBMS支持下的数据模型转换

●对数据模型进行优化

1．将E-R模型转换为关系模型

关系模型的逻辑结构是一组关系模式的集合。

而E-R图则是由实体、实体的属性和实体之间的联系三个要素组成的。

所以将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式，这种转换一般遵循如下原则：

（1）一个实体型转换为一个关系模式。

实体的属性就是关系的属性。

实体的码就是关系的码。

（2）一个m:

n联系转换为一个关系模式。

与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。

而关系的码为各实体码的组合。

（3）一个1:

n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。

如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。

（4）一个1:

1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。

如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。

如果与某一端对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性。

（5）三个或三个以上实体间的一个多元联系转换为一个关系模式。

与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。

而关系的码为各实体码的组合。

（6）同一实体集的实体间的联系，即自联系，也可按上述1:

1、1:

n和m:

n三种情况分别处理。

（7）具有相同码的关系模式可合并。

2．数据模型的优化

数据库逻辑设计的结果不是唯一的。

为了进一步提高数据库应用系统的性能，通常以规范化理论为指导，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。

数据模型的优化方法为：

（1）确定数据依赖。

（2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。

（3）按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。

（4）按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。

（5）对关系模式进行必要的分解。

规范化理论为数据库设计人员判断关系模式优劣提供了理论标准，可用来预测模式可能出现的问题，使数据库设计工作有了严格的理论基础。

3．设计外模式

前面我们根据用户需求设计了局部应用视图，这种局部应用视图只是概念模型，用E-R图表示。

在我们将概念模型转换为逻辑模型后，即生成了整个应用系统的模式后，还应该根据局部应用需求，结合具体DBMS的特点，设计用户的外模式。

目前关系数据库管理系统一般都提供了视图概念，支持用户的虚拟视图。

我们可以利用这一功能设计更符合局部用户需要的用户外模式。

定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。

由于用户外模式与模式是独立的，因此我们在定义用户外模式时应该更注重考虑用户的习惯与方便。

包括：

（1）使用更符合用户习惯的别名

（2）针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求。

（3）简化用户对系统的使用

6．5物理结构设计

数据库的物理设计通常分为两步：

●确定数据库的物理结构

●对物理结构进行评价，评价的重点是时间和空间效率

1．确定数据库的物理结构

（1）确定数据的存储结构

确定数据库存储结构时要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。

这三个方面常常是相互矛盾的，例如消除一切冗余数据虽然能够节约存储空间，但往往会导致检索代价的增加，因此必须进行权衡，选择一个折中方案。

聚簇功能不但适用于单个关系，也适用于多个关系。

假设用户经常要按系别查询学生成绩单，这一查询涉及学生关系和课程关系的连接操作，即需要按学号连接

（2）设计数据的存取路径

在关系数据库中，选择存取路径主要是指确定如何建立索引。

例如，应把哪些域作为次码建立次索引，建立单码索引还是组合索引，建立多少个为合适，是否建立聚集索引等。

（3）确定数据的存放位置

为了提高系统性能，数据应该根据应用情况将易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。

（4）确定系统配置

DBMS产品一般都提供了一些存储分配参数，供设计人员和DBA对数据库进行物理优化。

初始情况下，系统都为这些变量赋予了合理的缺省值。

但是这些值不一定适合每一种应用环境，在进行物理设计时，需要重新对这些变量赋值以改善系统的性能。

2．评价物理结构

数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。

评价物理数据库的方法完全依赖于所选用的DBMS，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。

如果该结构不符合用户需求，则需要修改设计。

6．6数据库实施

数据库实施主要包括以下工作：

●用DDL定义数据库结构

●组织数据入库

●编制与调试应用程序

●数据库试运行

1．定义数据库结构

确定了数据库的逻辑结构与物理结构后，就可以用所选用的DBMS提供的数据定义语言（DDL）来严格描述数据库结构。

2．数据装载

数据库结构建立好后，就可以向数据库中装载数据了。

组织数据入库是数据库实施阶段最主要的工作。

对于数据量不是很大的小型系统，可以用人式方法完成数据的入库，其步骤为：

（1）筛选数据

需要装入数据库中的数据通常都分散在各个部门的数据文件或原始凭证中，所以首先必须把需要入库的数据筛选出来。

（2）转换数据格式

筛选出来的需要入库的数据，其格式往往不符合数据库要求，还需要进行转换。

这种转换有时可能很复杂。

（3）输入数据

将转换好的数据输入计算机中。

（4）校验数据

检查输入的数据是否有误。

对于中大型系统，由于数据量极大，用人工方式组织数据入库将会耗费大量人力物力，而且很难保证数据的正确性。

因此应该设计一个数据输入子系统由计算机辅助数据的入库工作。

3．编制与调试应用程序

数据库应用程序的设计应该与数据设计并行进行。

在数据库实施阶段，当数据库结构建立好后，就可以开始编制与调试数据库的应用程序，也就是说，编制与调试应用程序是与组织数据入库同步进行的。

调试应用程序时由于数据入库尚未完成，可先使用模拟数据。

4．数据库试运行

应用程序调试完成，并且已有一小部分数据入库后，就可以开始数据库的试运行。

数据库试运行也称为联合调试，其主要工作包括：

∙功能测试。

即实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。

∙性能测试。

即测量系统的性能指标，分析是否符合设计目标。

6．7数据库运行和维护

数据库试运行结果符合设计目标后，数据库就可以真正投入运行了。

数据库投入运行标着开发任务的基本完成和维护工作的开始，并不意味着设计过程的终结，由于应用环境在不断变化，数据库运行过程中物理存储也会不断变化，对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。

在数据库运行阶段，对数据库经常性的维护工作主要是由DBA完成的，它包括：

⒈数据库的转储和恢复

定期对数据库和日志文件进行备份，以保证一旦发生故障，能利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态，并尽可能减少对数据库的破坏。

⒉数据库的安全性、完整性控制

DBA必须对数据库安全性和完整性控制负起责任。

根据用户的实际需要授予不同的操作权限。

另外，由于应用环境的变化，数据库的完整性约束条件也会变化，也需要DBA不断修正，以满足用户要求。

⒊数据库性能的监督、分析和改进

目前许多DBMS产品都提供了监测系统性能参数的工具，DBA可以利用这些工具方便地得到系统运行过程中一系列性能参数的值。

DBA应该仔细分析这些数据，通过调整某些参数来进一步改进数据库性能。

⒋数据库的重组织和重构造

数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。

这时DBA就要对数据库进行重组织，或部分重组织（只对频繁增、删的表进行重组织）。