这样的数据库设计显然是不好的。

　　1.插入异常。当学生的课程尚未安排时，班主任老师的有关信息不允许 插入（在该关系中，课程属性是主码，不能为空，删除主码时，整个元组也 要删除），引起插入异常。
2.删除异常。当学生毕业时，班主任的信息不能保留。
　　3.修改复杂。当张老师的职称改变时，虽然仅仅改变了一个属性，却要 改变所有的有关元组。
4.数据冗余大。 那么怎样才能设计一个好的数据库模式呢？这就是规范化理论讨论的内
容。

2.规范化与范式
1971 年，E·F·科德提出了规范化理论。 关系必须是规范化的，关系应满足：每个元组不可分，不存在异常插入，
不存在异常删除，修改简单，冗余小。 我们按照属性间依赖情况，可以区分关系规范化的程度为第一范式、第
二范式、第三范式和第四范式等。 范式就是对关系模式的限制条件，满足最低要求的叫第一范式，进一步
满足另一些要求叫第二范式，依此类推，还有第三范式，第四范式等。分别
写为 1NF，2NF，3NF，4NF。 上面的例子是满足关系模式的最基本要求的，是合法的、允许的。但是
由于插入、删除、数据冗余等问题，需要消除数据依赖中的不合理的部分，
需要进行规范化。一个低一级范式的关系模式，通过模式分解可以转换为若 干个高一级范式的关系模式，这种过程就叫规范化。
在前面举过的那个例子，经过规范化后，形成三个关系，由一个仅仅符
合 1NF 的关系规范为符合更高级范式的关系：
关系二 关系三 关系四
学号 课程 成绩 01 语文 100 01 数学 90 01 英语 99 02 语文 80 02 数学 90 ? ? ?



规范化后的关系改善了关系数据模式，部分消除了插入、删除异常和数
据冗余。我们再看关系四，在这个关系中，由于存在着传递依赖，仅仅是符
合 2NF，而不符和 3NF，在某些情况下，存在插入异常、删除异常和数据冗余 的现象，读者可以自己进行分析。所以需要进一步规范化为下面两个关系。

关系五 关系六
班级 班主任 初一 张老师 ? ?

这样经过规范化，彻底消除了插入、删除异常、修改复杂和数据冗余等
问题。
在关系规范化的过程中，还要考虑多值依赖的情况。

2.关系数据库的设计


　　数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建 立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需 求。数据库设计的目标是能够正确反映现实世界。
　　数据库设计属于软件工程的范畴。一个大型数据库的设计是一个庞大的 工程，涉及到多种技术和多学科，主要是计算机科学、程序设计、软件工程、 数据库理论与技术等。数据库设计应与应用系统的设计相结合。数据库设计 的目标大致有以下几点：
·减少有害的数据冗余，提高共享程序；
·消除异常插入、删除；
·保存数据的独立性，可修改，可扩充；
·访问数据库的时间要短；
·数据库的存储空间要小；
·要保证数据的安全性和保密性；
·易于维护。

1.数据库设计方法
　　有相当长的一段时间，数据库设计主要采用手工试凑法。数据库的设计 水平和与设计人员的经验有直接关系。数据库设计只是一种经验的反复实 施，而不能称为是一门科学，缺乏科学分析理论基础和工程手段的支持，所 以设计质量很难保证。以至于数据库投入运行后，才发现很多问题，需要不 断地从头修改，这样，就增加了成本，也带来很多的隐患。此后，人们努力 探索提出了许多数据库设计方法。这些方法主要应用了软件工程的成果，提 出了一系列的设计规范，形成了规范设计法。
　　规范设计法主要是将设计的步骤分为需求分析、概念设计、逻辑设计和 物理设计等向个步骤，并采用了许多规范化的手段和工具完成每个阶段的任 务。比如基于 E-R 模型的数据库设计方法，基于 3NF（第三范式）的设计方 法，基于抽象语法规则的设计方法等，就是在数据库设计的各个过程中采用 的具体的技术与方法。
　　规范设计法仍旧是一种手工方法。现在，人们进一步研制了很多系统， 用于数据库设计，甚至应用编程。前提是设计人员必须采用规范化的设计手 段，规范化的设计会给后期的开发带来很大的方便。对于一个大型的项目而 言，设计阶段的工作量，远远大于开发和维护阶段的工作量。对于大型的项 目，规范化是必须遵循的设计思想。
　　

2.数据库的设计步骤
　　数据库的设计过程与应用系统的设计是不能隔离的。一个数据库设计人 员对程序设计技术完全不懂是不行的。数据库的设计过程也是应用系统的设 计过程。在这个过程中，充分利用软件工程的研究成果，与用户充分地交流， 搞清楚应用环境，把数据和数据处理的需求收集、分析、抽象、设计等工作 在各个设计阶段都相互参照和相合补充，以完善两方面的设计。
按照上述原则和规范化的设计方法，数据库设计步骤分为六个阶段。
　　（1）需求分析。这个阶段的工作是要充分调查研究，了解用户需求；了 解系统运行环境，制定将要设计的系统的功能；收集基础数据，包括输入、 处理和输出数据；在这个过程中，要从系统的观点出发，既要调查数据，又 要考虑数据处理，也就是数据库和应用系统同时进行设计。
　　结构化分析方法（SA）是常用的分析用户需求的规范化的方法，表达用 户需求的是数据字典和数据流图（DFD），这些文档成为下个阶段的概念设计 的基础，也是将来系统维护的基础。对规范化的设计来说，这些文档是必不 可少的。
　　（2）概念结构设计。概念结构是整个系统的信息结构。它是现实世界的 真实反映。包括实体与实体之间的关系。概念结构同时是易于理想的，可以 拿它和用户交换意见，而用户的意见是至关重要的。概念结构是独立于各种 数据模型的，它是各种数据模型的基础，易于向关系、网状、层次模型转换。 概念结构设计的有力工具是 E-R 图。
下面是几个 E-R 图的例子。在 E-R 图中，长方形表示实体，椭圆形表示
实体的属性，菱形表示实体间的关系。 概念结构设计的第一步是对需求分析阶段收集到的数据进行分析，参照
数据流图和数据字典，逐步确定实体、实体

　　的属性、实体间的联系（一对一或一对多等），设计出局部 E-R 图。第 二步是将多个分 E-R 图逐步集成。集成的过程是一个合并调整的过程，在这 个过程中，要消除各种冲突，例如，年龄的表示，在各个分 E-R 图中可能有 不同的表示方法，有的用年龄，有的用出生日期；又如同一个实体，有不同 的名字，或反过来，不同的实体用了同一个名字。还要消除冗余的数据和联 系，冗余会给系统的维护带来困难。最后生成基本 E-R 图。
　　（3）逻辑结构设计。这个阶段的任务是将概念结构转换成与所选用的 DBMS 所支持的数据模型相符合的过程。一般情况下，应该是向适合概念模型
　　
的数据模型转换，然后再挑选合适的软件 DBMS 和机器。但是实际情况往往不 是这样当概念模型向数据模型转化时，一个实体型转换为一个关系模式，而 是实体的属性就是关系的属性，联系转换为一个关系模式。
　　数据库逻辑设计的结果不是唯一的，还要对数据模型进行优化，优化是 指适当地修改、调整数模型的结构，提高数据库应用系统的性能。主要措施 有记录的垂直分隔、水平分隔、适当增加冗余（提高速度等）。
　　规范化理论就是用于优化数据库的逻辑设计。广泛地用于逻辑结构结构 设计阶段，用模式分解的概念和算法指导设计。用规范化理论分析关系模式 的合理程度。
　　（4）数据库物理设计。这个阶段的任务是为一个给定的逻辑数据模型选 取一个合适的物理结构，并对物理结构进行评价。评估的内容包括存储空间、 响应时间等，如符合要求，则转向物理实施；不符合要求时，还要从前面的 某一阶段开始再次重复上述过程，修改数据模型、重新设计、修改物理结构
等。
　　在进行物理设计时，必须要了解 DBMS 的功能，了解应用环境，理解设备 的特性，扬长避短。物理设计的主要内容有数据库的存放策略、数据库结构 等。在设计完成后，还要进行性能评估和预测。物理设计过程需要对时间、 空间效率、维护代价和各种用户要求进行权衡，对多种方案进行比较和细致 的评价，最终选择一个较好的方案。
（5）数据库实施和维护。进入这个阶段后，就要按照逻辑设计和物理设
计的结果利用 DBMS 的数据定义语言把数据库描述出来，采用某种设计语言设 计应用程序，经过反复调试生成目标模式，然后组织数据入库并试运行。
（6）数据的载入。数据的载入是一个复杂的工作。可以人工输入，也可
以利用原来的数据转录，但是数据质量的控制是很重要的，这种检验由应用 程序和数据库完整性检查来完成。试运行的主要工作是检查应用程序的功 能，测量系统的性能指标，在物理设计阶段所做的评估是否正确，此时可以 得到检验。在试运行时，数据量一定要从小到大，以免不必要的重复劳动。 试运行时发现问题，随时改正问题，并且不断增加数据，一个系统从试运行 到稳定运行是需要一定的时间的。
当数据库正投入运行之后，数据库的开发任务完成，数据库的运行和维
护阶段开始。投入运行并不表示万事大吉了。此后的主要工作还有：系统性 能监视、改进，系统的转储和恢复，数据库的重组，调整数据库运行等。数 据库的维护是整个数据库设计过程的一个有机的组成部分，丝毫也不亚于任 何其他阶段的工作，不能认为是附属的不重要的而予以轻视。

第五章 分布式数据库


　　70 年代中期以来，由于计算机网络通信的迅速发展，以及地理上分散的 公司、团体和组织对于数据库更为广泛引用的需求，在集中式数据库系统成 熟技术的基础上产生和发展了分布式数据库系统。分布式数据库管理系统是 数据通讯和数据库管理相结合的成果。现在，在这个领域里，分布式数据库 系统的技术已逐步成熟，产品化的时代已经到来。在 J.马丁（James Martin） 的专著《数据库管理的基本原理》中，称 70 年代为数据库年代。而今有更多 的专家确信 80 年代是分布式数据处理的年代。事实表明，处理机和存储器的 成本继续下降，基于光纤技术的低成本的通讯、微波和卫星通讯等的发展， 已经并且还将进一步加速分布系统的开发和广泛使用。

1.数据通讯


　　这一节的目的不是深入讨论数据通讯的问题，而只是帮助读者理解数据 通讯的一些基本问题，提供必须的背景资料。

1.基本概念
　　采用适当的通信手段，把地理上分散的多个计算机系统连接起来，使它 们彼此进行通信和相互利用资源，这就构成了计算机网络，为分布数据处理 系统提供了物质基础。计算机网络可以认为是有节点和连接节点的通信路径 所构成。
节点是指处理部件，它既有加工能力又有存储能力。它可以是大型计算
机，或微型计算机。在节点上，运行的软件必须包括某些通信软件，通常还 有支撑软件（操作系统和数据库管理系统）。
分布系统中的另一类部件是连接各个节点的通信路径或链路。通信路径
的两个主要指标是带宽和通讯方式。 带宽是每秒钟线路能够传输的信息量（bps）。通信方式有单工通信方式、
半双工通信方式、全双工通信方式。
　　单工线路的成本相对便宜，但使用不够灵活。两种双工方式由于能往每 一个方向传输，这就提供了较多的灵活性。半双工方式在改变传输方向时会 引起延迟。全双工方式虽然比较昂贵。但不会引起延迟。拨号线路通常是半 双工的，租用专线是全双工的。
　　与整个系统相关的另外一些性能方面的特点还有传输速率、路径建立时 间、网络延迟和可靠性等。用户根据需要确定系统的性能，确定哪些因素对 他们是最重要的。

2.通信技术
　　通信技术的重要性表现在不同的技术所能提供的性能/价格方面的不 同。推动分布处理特别是分布式数据库管理的因素之一就是在处理和通信之 间的性能价值方面的权衡。对于采用音频级线路的通信系统和采用光纤技术 为基础的通信系统，所考虑的因素就大不一样，系统设计的差别也是悬殊的。 通信技术有三级。第一级是机内通信，它所涉及的是单个计算机的各个 部件之间数据的传送。这样一类的通信通常是在计算机系统中每一对部件之
　　
间进行，是很高速的、位并行的、同步的。这样的通信需要昂贵的计算机电 缆，长度受限制。这种通信用于特殊情况，分布系统一般都不采用。但由于 新技术的发展，这种情况也在变化之中。
　　通信技术的发展正在使局部网络成为第二级通信方式。这种方式性能/ 价格方面是机内通信和远程网络的折中，这些网络地理上是局限于大学、工 厂、公司、政府大楼等。由于局域网采用较昂贵的技术实现较好的性能，所 以这些技术难于用于大规模的网络系统。局部网络技术的发展，应用的迅速 推广和日益受到人们的重视，是与微型机和通讯技术的发展分不开的。计算 技术的发展，其趋势是从集中化走向分散化。以局部网络为基础的分布数据 库系统，从 70 年代末开始受到人们的广泛注意。
　　第三类通信系统及时通常所说的分布处理所采用的。这些相对低速的技 术，用在公共通信系统中。这些系统称为远程网络。上述这些通信系统和处 理技术的性能/价格比将差异决定分布系统采取什么样的设计方案。

2.分布处理


　　分布处理一词通常是用来描述具有多个处理机的系统。分布处理必须要 有数据通讯。然而，分布处理所包含的方面远远超过数据通讯的范围。分布 数据库管理系统只是分布处理的一种类型。所以，在了解分布数据库管理系 统之前，有必要先掌握分布处理的比较广泛的概念。

1.分布计算机系统
　　分布计算机系统是由多个分散的计算机经过互连网络构成的统一计算机 系统。其中各个物理和逻辑资源元件既相互配合，有高度自治地在全系统范 围内实现资源管理和在动态基础上实现任务或功能分配，且能并行地运行分 布式程序。
由此可见，分布式计算机系统具有：
　　（1）模块性。系统的多个分布物理资源和逻辑资源经过互连网络连成单 一系统，既相互独立，又互相联系，使系统具备整体控制的条件。
（2）并行性。既分散的系统元件可以合作起来解决一个公共问题，在一
个高级操作系统的控制下，实现资源重复或时间重叠等不同形式的并行性。
　　（3）自治性。既系统资源是高度自治的，不存在主从控制，又能利用处 理的局部化原则以减少各节点之间的数据通讯量。
分布处理的主要技术目标是改善下列性能。
　　（1）可靠性和坚定性。由于模块性系统容易实现资源和路径的冗余；由 于自治性，系统避免了集中控制所造成的薄弱环节；加之系统的动态重构能 力，使得系统遭受局部损害的情况下仍能继续运行。例如航空订票系统，连 续运行是至关重要的。集中式处理通过多处理机或双机系统来提高可靠性， 但是，当碰到火灾等破坏性事故时，集中式处理仍不能保证系统安全。使系 统分布于不同场地，提供适当的数据冗余，就能提供更好的可靠性。提供路 径的冗余。一个节点或一条通讯线路的故障，不会防碍任何功能的执行。
　　（2）快速响应和较低的费用。分布处理使计算机资源更加靠近用户。分 散的小用户能获得计算机的快速响应和直接服务，大用户可充分利用整个系 统的能力，从而实现大型机的处理能力和小型机的使用方便两方面的特点。
　　
在通讯费用是昂贵的前提下，常见的手段是将局部性的数据放在最常用的节 点上，还有把数据在各个节点上加以复制，由于可以实现局部的检索，就能 提供较快的响应时间和较低的开销。问题是更新要保持同步。如果更新的频 率高于检索的频率，那么保持同步所要的开销将抵销由于能够局部地实现检 索的效益，那么，分布式处理就得不到什么好处了。
　　（3）增量式地扩展处理能力和系统规模。当用户需求增长，需要扩展规 模或更新设备时，可以以低廉的价格以模块作为扩展增量，方便地纳入系统。

2.分布处理的方案
　　影响分布处理的体系结构的因素有许多。包括数据分布的类型，分布在 许多节点的数据是否重复，因为没有重复就没有多重副本需要同步；数据的 通讯，要在通讯费用和延迟之间作出折中，要在通信费用和处理费用之间进 行权衡。此外，还有系统支持的数据模型和语言，应用的类型等，不同类型 的问题需要不同类型的分布系统，这一点尤其要强调。
　　（1）具有远程作业录入的集中式的处理和存储。计算机刚刚问世的时 候，所有的处理、存储、输入和输出都必须在中心场地来完成。最初只是将 打卡机和打印机加以分布，利用远程的作业录入在各个局部场地可以直接读 取程序和数据，并传输到中心场地进行处理。然后，输出被直接送到各个局 部场地。但作业的递交与完成仍然以批处理方式为基础。
（2）具有联机终端的集中式处理和存储。对于这种事务处理系统，所有
的处理和存储资源仍旧是集中式的，在任何位置的用户都能请求并引用中心 场地的任何处理能力和资源。因为所有的数据和请求都要传送到中心场地， 然后再将结果传送回来，所以通信费用是很高的。现在这种情况很少见了。
（3）具有分布数据录入的集中式处理和存储。在前面方法的基础上，将
终端改为具有一定处理能力的智能终端或微机。大多数数据录入和编辑由本 地节点完成。当准备登录和加工时，才被送往中心场地并更新数据库或文件。 在中心场地处理时，需要进一步的编辑，这类编辑有核查字段值的合理性， 几个字段值的一致性，核查数据与数据库是否一致，比如，新顾客号码是否 唯一。
（4）具有中心数据库局部分隔的分布式数据录入和编辑。这种方法是前
面的简单的扩充。在某个节点上提供附加的存储能力。所有的编辑工作在局 部完成。推迟该节点与中心场地通信的时刻。这种方法，数据库的一部分仅 仅因为编辑的目的而局部地存放。所有实际的处理和更新都仍然是在中心场 地进行。局部副本只是特定时刻部分数据库的快照（快照是数据库部分数据 的副本）。与中心数据库并不同步修改。
　　（5）局部与中心场地链接的分布处理和存储。对上一种处理作一些改 善，把局部副本作为某一时刻的快照对待，避免复杂的更新同步的问题，对 某些应用来说，不需要副本的秒级同步。新方案是把数据库的一部分永久性 地放在局部。这种情况，节点具有局部处理能力，有相当规模的次级存储， 数据和程序均可以永久性地存储。仓库管理系统就是一个例子，每一个仓库 都存储和维护自己的库存数据。按一定的周期把更新发送到中心场地，修改 公司的记录。限制是任何通信都是在局部节点和中心之间进行的，节点之间 没有通信。
（6）局部节点互连的分布处理和存储。上一种方案的逻辑扩充就是允许

各个局部节点相互通信。例如，某仓库有一项订货要 100 件，库存只有 50 件，就要从另外的仓库调来 50 件。在前述系统中，要将请求发往中心，再转 发给第二个仓库。允许局部场地之间通信，会有一些收益。在大多数情况下， 用户必须知道数据存放在何处以及如何去存取它们。系统并不具有确定数据 存放位置和自动存取它们的专门的支撑软件，这一层次的增加是属于将系统 发展成为分布式数据库管理系统的一部分工作。在没有分布式数据库管理系 统能力的情况下，用户必须一次一次分别向每一个仓库发出询问，查看是否 有足够的存货，当用户找到一个具有足够熟练的仓库之后，就可以请求填写 订货单了。
　　（7）分布式数据库管理系统。这个方案需要有最大量的软件支持。用户 应当能存取系统内任何地方的数据，而无需指定它们的位置。在前面的例子 中，分布式数据库管理系统允许用户请求其库存至少有 100 件的仓库。系统 向许多局部场地发出请求以便找到一个这样的仓库，并且请求那个仓库提供 全部工具。系统作了大量的工作，而用户仅仅是发出了需要 100 件的请求。 即使对于这种方案，系统对用户的支持也有着许多不同的层次。一个具体的 分布式数据库管理系统的设计允许或不允许数据的重复，然而，一般都有重 复，这就要求有许多处理来维护各个副本之间的一致性。下一节将详细介绍 分布式数据库管理系统的一些概念。

3.分布式数据库管理系统


　　下面我们对当今日益重要起来的分布式数据库管理系统做一个简单的介 绍，而对分布式数据库系统的体系结构、模式结构，分布式数据库系统的设 计与实现，包括数据分片、功能分片、更新同步、查询处理与优化、分布事 务管理和并发控制等技术细节，不作详细介绍。
1.什么是分布式数据库管理系统。什么样的数据库系统才算是分布式数
据库系统呢？分布式数据库是由一组数据组成的，这些数据分布在计算机网 络的不同节点（亦称场地）上，逻辑上是属于同一系统的。网络中的每个节 点具有独立处理的能力（称为场地自治），可以执行局部应用。同时，每个 节点也能通过网络系统执行全局应用。这个定义强调了以下几个方面：
（1）分布性。数据库的数据不是存储在同一场地，更确切地讲，不存储
在同一计算机的存储设备上。这是和集中式数据库相区别的。
　　（2）场地自治性和自治场地之间的协作性。每个场地是独立的数据库系 统：它有自己的数据库，自己的一组终端，自己的中央控制器，运行自己的 局部 DBMS，执行局部应用，具有高度的自治。同时又相互协作组成一个整体， 这种整体性的含义是，对于用户来说，一个分布式数据库系统逻辑上看如同 一个集中式数据库系统，用户可以在任何一个场地执行全局应用。如图 5.1。
　　

　　图中的三台计算机，每台都有自己的数据库系统，三台计算机之间用网 络相连。每台计算机有自己的若干终端，用户可以通过终端对本节点中的数 据库执行某引起应用（局部应用），也可以通过终端对二个或二个以上节点 中的数据库执行某些应用（全局应用或分布应用）。这样的系统是分布式数 据库系统，而不支持全局应用的系统不能称为分布式系统。一个典型的全局 应用的例子是银行转帐。这个应用要求从一个分行的帐户（DB1）中转若干到 另一个分行的帐户（DB2）中去，因此要同时更新两个节点上的数据库。

2.分布式数据库系统的特点
　　分布式数据库系统是在集中式数据库系统成熟技术的基础上发展起来 的，但不是简单地把集中式数据库分散地实现，它具有自己的性质和特征。 集中式数据库系统的许多概念和技术，如数据独立性、数据共享和减少冗余 度、并发控制、完整性、安全性和恢复等在分布式数据库系统中都有了不同 的、更加丰富的内容。
（1）数据独立性。数据独立性是数据库方法追求的主要目标之一。在集
中式数据库中，数据独立性包括两方面：数据的逻辑独立性和物理独立性。 其意义在于程序和数据的逻辑结构和数据的存储结构无关。在分布式系统 中，数据库独立性除了上面所说之外，还有数据分布独立性亦称分布透明性， 即用户不必关心数据的逻辑分片，不必关心数据的物理位置分布的细节，也 不必关心重复副本（冗余数据）的一致性问题。有了分布透明性，用户的应 用程序书写起来就如同数据没有分布一样。在集中式数据库中，数据的独立 性是通过系统的三级模式和它们之间的二级映象得到的。分布式数据库，分 布透明性是由于引入新的模式和模式之间的映象得到的。
（2）集中与自治相结合的控制结构。数据库是供用户共享的，在集中式
数据库中，为保证数据的安全性和完整性，对数据库的控制是集中的。由数 据库管理员（DBA）负责监督和维护系统的正常运行。
　　在分布式数据库中，数据的共享有两个层次：一是局部共享，即在局部 场地上存储局部用户的共享数据。二是全局共享，即在分布式数据库的各个 场地也存储可供网络中其他场地的用户共享的数据，支持全局引用。因此， 相应的控制结构也具有两个层次：集中和自治。各局部的 DBMS 可以独立地管 理局部数据库，具有自治的功能。同时，系统又设有集中控制机制，协调各 局部 DBMS 的工作，执行全局应用。
　　（3）适当增加数据冗余度。在集中式数据库中，尽量减少冗余度是系统 目标之一。其原因是，冗余数据浪费存储空间，而且容易造成个副本之间的 不一致性。减少冗余度的目标是用数据共享来达到的。而在分布式系统中却 希望增加冗余数据，在不同的场地存储同一数据的多个副本。其原因是提高
　　
系统的可靠性和性能，当某一场地出现故障，系统可以对另一场地上的相同 副本进行操作，不会造成系统的瘫痪。系统可以根据距离选择离用户最近的 数据副本进行操作，减少通信代价。但是增加冗余会碰到集中式数据库同样 的问题，即不利于更新，增加了系统维护代价，需要在这些方面作出权衡。
　　（4）全局的一致性、可串行性和可恢复性。分布式数据库中各局部数据 库应满足集中式数据库的一致性、可串行性和可恢复性。除此以外，还要保 证数据库的全局一致性、可串行性和可恢复性。例如，在前面提到的银行转 帐事务中，包括两个节点上的更新操作，当其中一个节点出现故障，应使全 局事务回滚，在一个节点撤销已经执行的操作等。

3.分布式数据库系统的目标
　　研制分布式数据库系统的动机、目的，主要包括技术和组织两方面的目 标。
　　（1）降低费用。使用数据库的单位在组织上往往是分布的（部门、科室）， 在地理上也是分布的。分布式数据库系统的结构符合这种分布的要求。允许 用户在自己的本地录用、查询、维护等操作，实行局部控制，降低通信代价， 提高响应速度。
（2）提高系统可靠性。将数据分布于多个场地，并增加适当的冗余度可
以提供更好的可靠性。在一些可靠性要求高的系统中，这一点尤其重要。避 免了因为某个场地的故障而造成全部瘫痪的后果。
（3）保护投资。当在一个企业中已经建成了若干个数据库之后，为了相
互利用资源，为了开发全局应用，就要研制分布式数据库系统。否则，就要 把现有的数据库集中起来重建一个更大的集中式数据库，将是困难和不经济 的。所以，利用分布式数据库充分利用现有数据库资源，提高利用率。
（4）易于扩展处理能力和系统规模。当一个企业增加了新的部门时，分
布式数据库系统的结构可以很容易地扩展系统，甚至是唯一的途径：在分布 式数据库中增加一个新的节点，不影响现有系统的正常运行。这样比扩大集 中式系统要灵活经济。在集中式系统中扩大系统和系统升级，由于有硬件不 兼容和软件改变困难等缺点，升级的代价常常是昂贵和不可行的。

4.现状与前景
　　尽管在过去的时间里，分布式数据库已经取得了很显著的研究成果，但 是，成功地进入商品化运行的软件却仍为数不多。
　　集中系统的数据库设计是比较复杂的，而分布式数据库的设计就更为复 杂了。它除了集中式数据库设计的所有复杂性，还有数据分布的决策、更新 同步以及查询分解等的复杂性。另外，还有设计通信系统的问题。
　　大多数的数据库管理系统也许走一条从集中到分布的道路。首先是跨越 数个节点定义数据库，避免不同节点数据的更新同步问题，许可局部和远程 查询，回避了复杂的查询处理问题。进一步的工作是增加有限的重复，如果 最新的数据并不是最重要的情况下，这样提高了检索的性能。最后，就是完 全的分布式数据库管理。系统的功能能够处理复杂的查询，有较好的并发控 制机制和保证数据的更新同步。
　　对分布数据管理的研究有两个方面。一是单项的研究。比如数据的分布 问题，通信问题等。在研究一个问题时，假定其他因素是不变的，得出研究
　　
成果。此处还要研究的是要将各种因素综合起来，研究它们的相互作用和结 果。数据库设计和更新同步之间就有密切的联系，对于更新要求，依据不同 的更新同步方案，对通信系统的要求也随着不同。因此，就要对这些因素综 合地考虑。
　　分布式数据库系统的研究领域还包括对计算机网络的研究。计算机网络 技术的迅速发展，已经很大程度地影响到了数据库和分布数据库的领域。不 管是在远程网络还是局域网领域，都发生了很多的变比。局域网和远程网之 间的处理差别，必然会导致处理数据库和分布数据库问题的显然不同的一些 原则和方法。
　　
第六章 面向对象数据库

1.面向对象数据库


　　面向对象的思想首先出现在程序设计语言中。“面向对象”是一种认识 客观世界和模拟客观世界的方法，它将客观世界看成是由许多不同种类的对 象构成的，每个对象都有自己的内部状态和运动规律，不同对象之间的相互 联系和相互作用就构成了完整的客观世界。面向对象方法学所引入的对象、 方法、消费、类、实例、继承性、封装性等一系列概念，为我们认识和模拟 客观世界，设计和实现大型软件系统奠定了坚实的基础。
　　随着研究的深入和发展，现在面向对象技术已经应用到计算机软件的各 个领域，如面向对象的分析、面向对象的设计、面向对象的操作系统、面向 对象的数据库系统、面向对象的专家系统、面向对象的开发工具、面向对象 的用户界面等。
　　数据库系统是信息系统的核心。一般地说，综合的信息系统就是大型数 据库应用系统。
　　将面向对象技术应用到数据库系统中，这是数据库应用发展的迫切需 要。也是面向对象技术和数据库技术发展的必然结果。面向对象技术在数据 库系统中的应用主要体现在数据库管理系统和数据库应用开发工具两个方 面，即面向对象的数据库系统和面向对象的数据库应用开发工具。
数据库管理系统是建立信息系统的基础。
　　将面向对象技术应用到数据库管理系统中，使数据库管理系统能够支持 面向对象数据模型，这对于提高数据库系统模拟客观世界的能力，扩大数据 库应用领域具有重要的意义。
数据库应用开发工具是信息系统开发的必备环境，将面向对象技术应用
到数据库应用开发工具中，使数据库应用开发工具能够支持面向对象的开发 方法并提供相应的开发手段，这对于提高应用开发效率、增强应用系统界面 的友好性、系统的可伸缩性、可扩充性等具有重要的意义。

1.面向对象的数据库系统
　　（1）面向对象数据库乃是面向对象技术与数据库技术相结合的产物。在 涉及面向对象数据库的论题之前有必要先考察一下“面向对象”的含义。
“面向对象”是近年来计算机领域中的一个出现频率颇高的词汇，在软
件工程实践者看来，它常常与如下一些概念密切相关：数据抽象、封装性、 继承性、多态性、可扩充性、类属程序设计、信息隐蔽、代码重用、模块化 等等，甚至还可以列出更多的相关概念，但最终到底什么是“面向对象”还 是不清楚。
　　往往一谈到“面向对象”，人们就自觉或不自觉地将它与面向对象的程 序设汁语言关联起来，而面向对象的程序设计语言有许许多多，而且风格迥 异，所以单从语言角度出发来理解“面向对象”是不行的。
不少计算机专家认为，“面向对象”是一种世界观和方法论。 首先，“面向对象”是一种认识客观世界的世界观，这种世界观将客观
世界看成是由许多不同种类的对象构成的，每个对象都有自己的内部状态和 运动规律，不同对象之间的相互联系和相互作用就构成了完整的客观世界。

　　其次，“面向对象”是从结构组织去模拟客观世界的一种方法，这种方 法的基本着眼点是构成客观世界的那些成分——对象。
　　用面向对象的观点去认识世界，用面向对象的方法去模拟客观世界就构 成了“面向对象”的完整含义。从系统实现的角度看，“面向对象”的实质 也许可以看成是支持“数据抽象”，而且是“分层的数据抽象”。
　　所谓“数据抽象”，粗略地说，就是把数据对象的内部表示和它所允许 的操作汇集并封装起来，使得对于数据对象的访问只能通过引用其接口中所 规定的外部可见的操作来进行。
　　把“面向对象”概念融合到数据库中去就形成了所谓“面向对象数据库”。 但是，把哪些概念融合进去以及怎么融合进去？到目前为止都是未解决的问 题，看法很不一致，以致于难以面向对象数据库下一个准确的定义。
　　（2）应用的需求。数据库技术自 60 年代后期问世以来，无论从理论上、 技术上，还是应用上，都经历了一个飞速发展的过程。现在，大型信息系统 一般都是以数据库系统作为其核心的。
　　从数据库系统采用的数据模型来看，70 年代广为流行的是网状模型和层 次模型的数据库系统。自 80 年代以来，由于关系模型有严格的数学基础，概 念简单清晰，非过程化程度高，数据独立性，因此关系型数据库系统的发展 非常迅速，所以，计算机厂商新推出的数据库管理系统几乎都是支持关系模 型的。
随着数据库技术的发展，数据库应用领域已从传统的商务数据处理扩展
到许多新的应用领域，例如计算机辅助设计（CAD）、计算机辅助软件工程
（CASE）、图象处理、超文本应用等，关系数据库管理系统很难适应这些新 应用领域中模拟复杂对象，模拟对象的复杂行为的需求。甚至在传统的商务 数据处理应用中，也提出了新的处理需求，例如存储和检索保险索赔案件中 的照片、手写的证词等，这些要求也是传统的关系数据库系统难以满足的。 新的应用需求的主要特征是：
1）数据模型要能描述复杂对象，能表达更丰富的语义。
　　2）数据类型从单一的格式化数据扩展为多媒体（图象、图形、声音）等 非格式化的多种类型。
3）支持长事务（以小时、天计）、版本管理和动态模式修改等。
　　数据库工作者为了给新的应用建立适合的系统，进行了艰苦的探索。所 采用的办法一是对传统的 DBMS 针对不同应用进行不同的扩充。但结果表明， 这种办法，系统效率常常不能令人满意，而且发现应用开发中关系查询语言 和程序设计语言之间不协调、不匹配的问题，为此人们试图把逻辑程序设计 和数据库相结合，把函数程序设计和数据库相结合。最近发现把面向对象的 程序设计方法和数据库相结合是最有希望的方法。它提供了表示、管理程序 的数据两者的统一框架。把面向对象的方法和数据库技术结合起来建造向对 象的数据库系统（Object-Oriented Database Systems，简称 OODBS）。
　　OODBS 在逻辑上和物理上都从面向记录或元组上升为面向对象——面向 具有复杂结构的一个逻辑整体。它允许以自然方法并且结合数据抽象机制在 结构和行为上对复杂对象建立模型。从而大幅度地提高管理效率，降低用户 使用复杂性，并为版本管理、动态模式修改等功能的实现创造了条件。数据 库的许多新领域都和面向对象的领域有关系，这些领域包括：语义数据模型、 嵌套关系、可扩展的数据库系统、数据库程序设计语言等等。
　　
　　（3）面向对象数据库系统的特性。面向对象数据库系统的研究始于 80 年代中后期，对 OODB 的研究，实际上是沿着不同的方向、采用不同的方法进 行的。例如 OODB 数据模型的研究是沿着三条路线展开的：一条是以 RDB 和 SQL 为基础，扩展关系模型（ERM）；一条是以面向对象的程序设计语言为基 础，扩充 OO 模型（EOM）；一条是建立新的 OODB 数据模型（ODM ）。因此在
80 年代中后期，关于 OO 概念、OODB 概念、OODB 数据模型和语言等一系列基 本概念、术语的定义和理解呈现了百花齐放、百家争鸣的局面。
　　对于什么是面向对象的数据库系统，目前尚缺乏权威性的统一标准。然 而，对于面向对象数据库系统应该具备的基本特性，国际数据库学术界已取 得了大体一致的共同认识。
　　首先，OODB 必须支持面向对象的数据模型，具有面向对象的特性。这些 特性主要包括：支持复杂对象，具有对简单对象运用各种对象构造符组成复 杂对象有的能力；具有对象标识，对象独立于它的值而存在；具有封装性， 数据库对象中既封装数据又封装程序，从而达到信息隐蔽，同时也是逻辑数 据独立性的一种形式；支持类型和类的概念，类型概括具有相同特性的一组 对象的共同特性；支持类或类型的层次结构，从而支持继承性这一有力的建 模工具；允许过载，即将同一名字用于不同类型上的数据操作；通过与现有 程序设计语言的合理连接来达到计算完备性；并具有可扩充性。
其次，OODB 必须是一个数据库管理系统，具有数据库管理系统的基本功
能。主要包括：持久性，数据库中的数据是持久保存的；外存管理，包括索 引管理、数据聚集、数据缓冲、存取路径选择、查询优化等；并发性，系统 应该提供和目前的数据库管理系统同样级别的，对多个用户并发操作数据库 的支持；故障恢复，系统应该提供和目前的数据库管理系统同样级别的，将 数据库从故障后的错误状态恢复到某一正确状态的功能；以及即席查询功 能，查询功能应该是非过程化的、高效的、独立于应用的。
面向对象的数据库系统除了必须具备上述面向对象特性和数据库管理系
统基本功能外，最好还能具备新应用领域所需要的一些进一步的特性，例如 模式演化、版本管理、长事务和嵌套事务、分布式计算等。
（4）面向对象数据库系统的优越性。面向对象数据库系统将面向对象的
能力赋予了数据库设计人员和数据库系统的应用开发人员，从而可以大大扩 展数据库系统的应用领域，并且提高开发人员的工作效率和应用系统的质 量。
1）复杂对象构造能力使得对于客观世界的模拟能力强、方式自然。
　　关系数据库系统强迫用户多个关系的元组来表示层次数据、嵌套数据或 复合数据。例如，职工有职工号、姓名、性别、工资、部门等属性，而部门 又有部门号、部门名、部门性质、部门经理等属性。关系数据库中属性的取 值只能是基本数据类型，这样，职工元组中的部门属性取值只能是部门号。 要查询某职工及其所在部门的信息就需要做“职工”和“部门”这两个关系 的连接。这样的表示方式既不自然，又影响查询的速度。面向对象数据库中 对象的属性的取值可以是另外一个对象，一个职工对象的部门属性的取值就 可以是该部门对象，实际储存的是该对象的对象标识，这样的表示方式自然、 易理解，而且在查询某职工及其所在部门的信息时可以通过该部门的对象标 识直接找到那个部门，提高了查询的速度。
2）封装性向开发人员和最终用户屏蔽复杂性和实现细节，降低了数据库

应用系统开发和维护的难度。 对象封装将程序封装在一起作为存储和管理的单位，也是用户使用的单
位，从外部只能看到它的接口，而看不到实现的细节，对象内部实现的修改 不影响对对象的使用，因此使应用系统的开发和维护都变得更加容易。关系 数据库系统现在支持存储的过程，即允许程序用某种过程性语言编写并存入 数据库中以备以后装载和执行。但是，存储的过程并不和数据封装在一起， 即它们不和任何关系或关系的元组相关联，构成一个整体，其信息隐蔽和易 维护性显然不如 OODB 中封装起来的对象。
3）继承性使得数据库设计和应用编程成为可重用的。 在面向对象的数据库系统中，类的定义和类库的层次结构体现了系统分
析和数据库设计的结果，即体现了客观世界中对象的内部结构及对象之间的 联系。同时，类定义中封装的方法保存了数据库应用编程的结果。应用开发 人员可以在已建立的类库的基础上派生出新的类，继承已存在的类的属性和 方法。例如定义“销售人员”类作为已存的“职工”的职工号、姓名、性别 等属性，重用了数据库设计的结果，还可以继承“职工”的计算工资额、显 示奖惩记录等方法，重用了应用编程的结果，数据库设计和应用编程的重用 对于建立大型复杂的数据库应用系统具有重要意义。
（5）RDB 与 OODB。传统关系数据库中管理的是一张张的二维表，表中每
一项是一个元组（记录），而面向对象数据库中管理的是对象的集合，也可 以看成是一张张的二维表，但表中每一项是一个对象。
关系数据库中表达现实世界的实体及其联系都是用表，而面向对象数据
库中表达现实世界的对象用表，而联系用直接引用机制，这种直接引用机制 是通过对象标识符加上（复杂对象）索引机制来实现的，这导致了面向对象 数据库与关系数据库相比有很大不同。
用关系数据库表示非传统应用（例如 CAD、CASE、OIS 等）领域中的复杂
实体就很不方便而且效率太低，因为元组之间的联系必须通过 JOIN 运算运态 地建立，要访问一个复杂对象需经历大量的 JOIN 运算，造成系统效率严重下 降，所以再用关系数据库就不行了。而面向对象数据库采用了直接引用机制， 所以在存取一个复杂对象时避免了大量的 JOIN 运算。此外，关系数据库的传 统应用是短事务应用，即每个事务的执行时间都非常短，所以可以采用封锁 机制来实现并发访问。
非传统应用有长期性和合作性的特点，例如；一个设计事务可能要延续
很长时间，而且可能两个人在设计同一个子系统，其中只要有一个人的设计 事务正确提交就算整个事务正常完成（提交）。在这种情况下，关系数据库 中并发控制的封锁策略就不再适用了，因为一个事务若长期封锁一部分对象 将导致别的事务长期等待，这是不允许的。
　　此外，事务的原子性（事务不能嵌套）也不再适用了，因为非传统应用 在很多场合下都可以表现成嵌套事务的执行。从设计方法学的角度看，人们 已经普遍认识到面向对象的方法学优于过去常用的所谓“自顶向下、逐步求 精”的基于功能分解的方法学，如果用户使用面向对象的方怯进行系统的分 析与设计，而我们还只能为他们提供关系数据库，则势必在设计与实现之间 造成一个语义断层，导致方法应用的不连贯性和语义丢失问题。所以用面向 对象的数据库来支持整个面向对象的方法学的应用是必然的要求。
　　
2.面向对象的数据库应用开发工具
　　（1）应用的需求。为提高应用开发人员的生产率，增强数据库应用系统 的界面友好性、可维护性、易扩充性，就必须有数据库应用开发工具来支持 数据库应用系统的开发。
　　十余年来，数据库厂商和工具开发商在数据库应用开发工具上投入了大 量的人力和物力，推出了若干个建立在关系数据库系统之上的应用开发工 具。早期的开发工具多是字符界面的、集中式的（非客户机/服务器结构的）， 一般是与特定的 DBMS 配套的。
　　随着客户机/服务器体系结构的发展，以及对全企业范围数据库应用系统 的需求，数据库应用开发人员对应用开发工具提出了新的要求，要求它们支 持图形化用户界面（GUI）开发，软件部件重用，开发组的工作方式，应用系 统的可伸缩性、可扩充性等。与这些要求相呼应，数据库厂商和工具开发商 开始研究将面向对象技术应用到数据库应用开发工具中，并开始推出面向对 象的数据库应用开发工具。
　　（2）面向对象的数据库应用开发工具的特性。面向对象数据模型具有丰 富的语义。一方面这使得用户能够对具有复杂数据结构的应用建模，另一方 面却又使对数据库的逻辑设计和物理设计变得复杂。
由于 OODB 模式具有类层次结构和聚合结构，在 OODBS 中查询和更新语义
比 RDB 复杂，这给应用开发和用户使用带来了难度。以上两个方面的原因说 明，要使 OODBS 实用化，与 RDBS 相比更需要数据库设计的辅助工具，更需要 在核心层外开发工具层，以提高用户的生产率。
近年来，许多公司在 OODBS 产品中均作了努力。
　　与关系数据库查询语言有 SQL 标准不同，数据库应用开发工具五花八 门，没有统一的标准，当然更没有面向对象的数据库应用开发工具的统一标 准。然而，我们还是可以列举出它应该具备的一些基本特性。
首先，作为数据库应用开发工具，它应该提供对应用开发的全面支持，
包括图形化的界面描绘工具，应用建立工具，高度工具，图示工具，以及强 有力的数据库访问能力和浏览工具等。
其次，作为面向对象的开发工具，它应该支持面向对象的开发方法，包
括一个可扩充的面向对象编程语言定义、类的层次结构、继承性、多态性等。 此外，这样的开发工具还应该是客户机/服务器结构的，最好具有与多种 数据库服务器的开放联接。以及支持开发组的工作方法，支持应用分割等进
一步特性。
　　面向对象的数据库应用开发工具形成了这样一种环境，允许先进的面向 对象技术与成熟的关系数据库技术在同一环境中工作，支持数据库应用系统 的开发。

2.面向对象数据库的现状与未来趋势

1.面向对象数据库系统的现状与发展趋势
　　近十年来，面向对象数据库系统一直是数据库学术界和工业界研究的热 点之一。
　　自从 1987 年以来，已陆续有多个 OODB 产品投入市场。这些产品中的某 些已经占有一定的市场，另一些尚处于评估和初步的原型应用开发阶段。总
　　
的说来，当前世界 OODB 市场只占整个数据库产品市场的很小一部分。作为数 据库产品 OODB 还是不够成熟的。原因是缺乏某些数据库基本特性，例如完全 非过程化的查询语言、视图、授权动态模式变化、参数化的性能调整等。这 些都是数据库用户已经熟知的，因而希望提供的。此外，关系数据库产品还 提供触发器，元数据管理，数据完整性约束等，而目前大多数的 OODB 产品不 提供这样的支持。
　　尽管面向对象数据库有很吸引人的潜力和市场，但是存在于其中的难题 非常之多，主要表现在两个方面，其一是理论方面，包括：面向对象数据模 型的数学基础是什么？查询模型、优化模型、并发控制模型、存储模型是怎 么样的？等等。理论方面的难点集中在有结构的类型系统和对象中的行为抽 象部分。其二是技术方面，由于表示的灵活性导致了系统操作语义的复杂性， 这种复杂性对实用性造成了严重威胁。随着产品的面市，甚至现在数据库厂 商们正在逐步放弃“面向对象的”这一术语，而且，它们越来越重视自己的 关系数据库产品如何支持新的、非关系型数据类型。
　　面向对象数据库系统的实际工作效率到目前为止还是一个令人头痛的问 题。特别值得一提的是面向对象数据库系统损失了关系数据库系统的很多优 点，这种损失有些是由于技术尚未成熟而造成的，有的则是由于方法本身使 得事情本质上困难了。
目前 OODB 产品的应用还很不普遍，主要应用在一些特殊的行业，特殊的
应用领域中。而在传统的商务处理中很少应用。
　　现在人们普遍认为，OODB 和 RDB 关系不同于 70 年代初 RDB 与网状层次 数据库的关系。那时的争论是在同一主要应用领域（即商业事务应用）中究 竟用关系数据库还是非关系数据库，也就是谁取代谁的问题。现在，是在肯 定关系数据库基本适合商业事务处理的前提下，对非传统的应用用 OODB 来弥 补其不足。OODBS 将成为一代数据库系统的典型代表，并和 RDB 共存（而不 是替代）。新一代数据库系统应是包括面向对象特性的，与关系数据库系统 兼容的（即其语言必须是 SQL 的超集）成熟的数据库系统。它们将在不同的 应用领域支持不同的应用要求。

2.面向对象数据库应用开发工具的现状与发展
　　如上所述，面向对象数据库系统现在应用还很不广泛，将来的趋势也不 是取代关系数据库系统。关系数据库系统在现在和将来的相当长时间内仍将 是应用的主流。因此，基于关系数据库系统的面向对象应用开发工具对于数 据库应用的发展具有十分重要的意义。
　　目前，已有一些面向对象的数据库应用开发工具推向市场，并由于它们 出色的特性而受到用户的欢迎。例如因弗米克斯（Informix）公司的 Informix NewEra，宝兰德
　　（Borland）公司的 Delphi，威力软件（Powersoft）公司的 Power-Builder 等。预计还会有新的面向对象的数据库应用开发工具陆续推出，并且这些工 具在在向对象特性的支持、与多种数据库服务器连接的能力、高效性、易用 性等方面将有进一步改进和提高，从而为在关系数据库系统的应用开发中采 用面向对象技术提供更有力的支持。
　　
第七章 数据库技术的发展

1.数据库技术发展综述


　　60 年代，由于计算机的主要应用领域从科学计算转移到数据事务处理， 促使数据库技术应运而生，使数据管理技术出现一次飞跃。E.F.科德提出关 系数据库模型，在数据库技术和理论方面产生了深远的影响。经过大批数据 库专家十余年的不懈努力，数据库领域在理论和时间上取得令人瞩目的成 就，它标志着数据库技术的逐渐成熟，使数据管理技术出现了又一次飞跃。 然而，人类前进的步伐是不会停止的，数据库技术正面临着新的挑战。

1.数据库技术面临挑战
　　（1）信息爆炸可能产生大量垃圾。随着社会的信息化进程的加快，信息 量剧增，大量的信息来不及组织和处理。例如，美国宇航局近年来从空间收 集了大量的数据，美国“陆地”卫星每两周就可以拍摄一次整个地球表面， 该卫星运行近 20 年来的 95％的信息还没有人看过。现在还没有这样的数据 库可供存储和检索如此大量的数据。再有，美国国会通过一个 30 亿美元的计 算，准备构造全人类基因组的 DNA 排列图谱。每个基因组的 DNA 排列长达几 十亿个元素，每个元素又是一个复杂机构的数据单元、据估计，人类的基因 组约有 5～6 万种，如何表示、访问和处理这样的图谱结构数据，是数据库面 临的难题。进入 90 年代，像这样的数据并不罕见，传统的数据库技术受到了 挑战。
（2）数据类型的多样化和一体化要求。传统的数据库技术基本上是面向
记录的，以字符表示的格式化数据为主，这远远不能满足多种多样的信息类 型需求。新的数据库系统应能支持各种静态和动态的数据，如图形、图象、 语音、文本、视频、动画、音乐等。
在许多计算机应用中，例如地图、地质图、空间或平面布置图、机器人
控制、人工视觉、无人驾驶、医学图象等，常涉及到许多空间属性，例如方 向、位置、距离是否覆盖或重叠等。目前，这类数据的表示和处理都由应用 程序解决，数据库给予的直接支持很少。两者之间缺少亲近性，随着这类应 用的增多，数据量的扩大和共享程度的提高，有必要由数据库系统来管理， 这就需要发展相应的数据模型、数据语言和访问方法。
更为重要的，人们对信息的使用常常是综合性的，图形、图象、语音、
文本、数据之间常常发生交叉调用，需能运多种手段（图标、声音、表格、 命令、语言）综合进行存储检索、管理，这是计算机系统和信息系统逐步走 向多媒体化的自然要求。从数据库系统来说，要解决多媒体数据的管理问题。 DBMS 虽然以支持多媒体数据作为其研制的主要目标之一，但是投入实用还有 相当大的困难，尤其在性能上还很难满足多媒体数据一体化处理的要求。目 前，多媒体数据基本上靠嵌在关系模式中的文件系统或记录来支持，但数据 量大了，数据结构复杂了，共享的要求高了，靠文件系统显然是很难适应的。 研制实用化的多媒体数据库对关系数据模型和单一数据类型提出了严峻的挑
战。
　　（3）当前的数据库技术还不能处理不确定或不精确的模糊信息。目前， 一般数据库的数据，除空值外都是确定的，而且认为是现实世界的真实反映。
　　
但是实际生活中要求在数据库中能表示、处理不确定和不精确的数据。例如， 有些数据不知道确定值，只知道它属于某一集合或某一范围；也有些数据是 随机性的，只知道它的不同值出现的概率；还有些数据是模糊的，它的值只 是它的“可能”值，或者用自然语言值表达。推而广之，一个元组、一个关 系，甚至整个数据库都可能是模糊的。要支持这类数据，必须对确定数据模 型做相应的扩展，甚至要对数据库理论来一场革命。人们对数据库查询的要 求也不再是简单的有解（完全符合查询条件的结果）和无解，而可能是模糊 解或不确定解，提供模糊查询结果。
　　（4）数据库安全。数据库系统的发展方向是在大范围内集成，向广大用 户提供方便的服务。今年来便携式计算机大量涌现，因特网扩展延伸，用户 将可通过计算机网随时随地访问数据库，这就带来严重的数据库安全和保密 问题。不解决这个问题，上述的目标将无法实现。现有的数据库安全措施远 不能满足这个要求。在数据库安全模型、访问控制、授权、审计跟踪、数据 加密、密钥管理、并发控制等方面都还没有形成明确的主流技术策略。例如， 不管是按数据对象分别给用户授权，还是按数据级和用户密级决定能否访 问，都不能可靠地防止泄密。比较可靠的办法是数据加密。但在最近，美国
的 RSA 数据安全公司，为迫使美国政府放松密码产品的出口限制，发起了一 项名为“秘密密钥挑战”的竞赛。因特网上有数万人加入到破解密码的行动 中，采用穷举方法，终于在 96 天之后破解了 56 位 DES 加密算法。这令舆论 哗然，也令使用这种加密方法的公司、机构不寒而栗。数据库管理系统的安 全机制还涉及到对操作系统安全的要求。
（5）对数据库理解和知识获取的要求。目前，粗略地说，全世界平均每
天诞生 100 个数据库，每 5 年信息量就要翻一番。正如奈斯比特在《大趋势》 一书中所描述的：“我们正在被信息所淹没，但我们却由于缺乏知识而感到 饥饿。”但是，我们对数据库的使用还停留在操作员查询一级，只能利用数 据库去查询已经存放在库中的一些具体的特定的数据。即使这样，查询前用 户还必须熟悉有关的数据模式及其语义，为了了解这方面的情况常常要向数 据管理员（DBA）请教。这样无法解决语义的歧义问题，更不能为决策者理解 数据库的整体特性服务。高层决策者常常希望把自己的数据库作为知识源， 从中提取一些中观的、宏观的知识，希望数据库具有推理、类比、联想、预 测能力，甚至能从中得到意想不到的发现，希望数据库能主动而不是被动地 提供服务。如商品数据库能根据销售量主动提出调整价格的建议，或者提醒 采购库存量已经很少的货物。

2.数据库技术的研究方向
　　近年来硬软件，特别是硬件的发展，为迎接上述挑战提供了技术基础。 对数据库技术来说，下面的技术是有意义的：盘、磁盘组、大规模并行处理 技术、光纤传输和高速网、高性能微处理器芯片、人工智能和逻辑程序设计、 多媒体技术的发展和推广、面向对象程序设计、开放系统和标准化等。近年 来在数据库技术方面形成了下面四个主攻方向：
　　（1）分布式数据库系统。由于通用操作系统对 DBMS 性能的限制，以及 硬件价格的下降和高速网的发展，用专用数据库服务器已变得越来越合理 了。专用数据库服务器的操作系统是面向数据库的，因此可以减少许多不必 要的开销，可以支持大量的实时事务处理。为了提高服务器的性能，可以采
　　
用磁盘组和大规模并行处理技术。多个数据库服务器连网，也可以构成分布 式数据库系统。
　　分布式数据库系统有两种：一种是物理上分布的，但逻辑上却是集中的。 这种分布式数据库只适宜于用途比较单一的、不大的单位或部门。另一种分 布式数据库系统在物理上和逻辑上都是分布的，也就是所谓联邦式分布数据 库系统。由于组成联邦的各个子数据库系统是相对“自治”的，这种系统可 以容纳多种不同用途的、差异较大的数据库，无全局数据模式概念，比较适 宜于大范围内数据库的集成。
　　构成联邦式分布数据库系统的成员可以是集中式数据库、数据库服务 器、逻辑集中式分布数据库，也可以是另一个联邦式分布数据库系统，也就 是联邦中还可以有联邦。从这个意义上说，联邦式分布数据库系统结构是分 布式数据库系统的普遍结构。90 年代，分布式数据库系统将被普遍使用。形 形色色的分布式数据库系统都可以被看成上述普遍结构的一个实例。
　　（2）面向对象的数据库管理系统。数据库管理系统历来是数据库技术的 凝聚点，也是数据库技术研究的排头兵，要迎接上述挑战，在现有 DBMS 的基 础上改进几乎是不可能的，但现在还没有到研制新一代 DBMS 产的时候，在此 之前还需要新一轮的基础研究。
当前在 DBMS 方面，最活跃的研究是面向对象数据库系统。1984 年班西
仑（Bancilhon）等人发表面向对象数据库系统宣言是一个重要标志。它将数 据与操作方法一体化为对象的概念，数据和过程一起封装。现已出现了一些 借鉴了面向对象程序设计的思想和成果的原型和产品，可以看成是在 DBMS 中革新数据模型的重要的尝试和实践；在数据模型方面，对象、封装、对象 有识别符、类层次、子类、继承概念和功能已初步形成；在数据库管理方面， 提出了持久性对象、长的事务处理、版本管理、方案进化、一致性维护和分 散环境的适应性问题；在数据库访问界面上，提出了消息扫描、持久性程序 设计语言、计算完备性等概念。总之，面向对象数据库系统的形象正逐步明 朗起来。
（3）多媒体数据库。多媒体数据库从本质上说，要解决三个难题。第一
是信息媒体的多样化，不仅仅是数值数据和字符数据，要扩大到图形、图象、 语音、视频、动画、音乐数据等，形成超文本。当前市场上各种多媒体卡（视 频卡、语音卡等）侧重解决实时处理和信息压缩两个问题，并没有解决多媒 体数据的存储组织、使用和管理，这就需要提出与之相关的一整套新的理论， 作为关系数据库基石的关系代数理论远远不够了。第二要解决多媒体数据集 成或表现集成，实现多媒体数据之间的交叉调用和融合。集成粒度越细，多 媒体一体化表现才越强，应用的价值也才越大。如果输入和输出的媒体形式 是一样的，只能称之为记录和重放。第三是多媒体数据与人之间的实时交互 性。没有交互性就没有多媒体，要改变传统数据库查询的被动性，而以多媒 体方式主动表现。显然，像 SQL 查询语言是过分的单调和远远的不适应了。 例如，能从数据库检录出某人的照片、声音及文字材料，对其音容笑貌有个 综合形象，也许还是多媒体数据库的初级应用。通过交互特性使用户介入到 多媒体数据库中某个特定条件（范围）的信息过程中，甚至进入一个虚拟的 现实世界（VirtualReality），这才是多媒体数据库交互式应用的高级阶段。
　　（4）数据库中的知识发现。人工智能和数据库技术相结合是很重要的发 展趋势，各种各样的智能数据库、演绎数据库和专家系统，促进了数据库中
　　
的知识发现（KDD）研究。特别是从 1989 年开始，国际上已形成了一个朝气 蓬勃的主攻方向，用数据库作为知识源，把逻辑学、统计学、机器学习、模 糊学、数据分析、可视化计算等学科成果综合到一起，进行从数据库中发现 知识的研究，使得数据库不仅仅能任意查询存放在库中的数据，而且上升到 对数据库中数据的整体特征的认识，获得一些与数据库数据相吻合的中观或 宏观的知识。这不仅有利于数据库自身的增长和管理，而且大大提高了数据 库的利用率，使之有可能成为决策支持系统的基础，特别是使用模糊学和自 然语言值，通过隶属云和语言原子模型来沟通定性分析和定量分析。例如通 过一个地区人口普查数据库可望得出有助于人口控制的政策；通过一个商品 数据库发现有利于价格调整的知识；通过一个公安局刑事犯罪数据库，提出 对新案例的侦破建议等。KDD 方法绕过了专家系统中知识获取的瓶颈，充分 利用了现有的数据库技术成果，形成了用数据库作为知识源的一整套新的策 略和方法。在这个领域，目前讨论的热点集中在数据仓库和数据挖掘。
　　（5）专用数据库系统。在地理、气象、科学、统计、工程等应用领域， 需要适用于不同的环境，需要解决不同的问题，在这些领域应用的数据库管 理完全不同于商业事务管理，并且日益显示其重要性和迫切性。工程数据库、 科学与统计数据库等近年来得到了很大的发展，这是由于常规的商用数据库 系统不能有效地支持这些应用，而常规数据库的研究出发点又不是专业数据 库必须支持的。这些领域数据各具特色，必须专门地去研究和开发。目前它 们已经取得了很大的进展。
正是计算机科学、数据库技术、网络、人工智能、多媒体技术等的发展
和彼此渗透结合，不断扩展数据库新的研究和应用领域。上述的四个主攻方 向不是孤立的，它们彼此促进，互相渗透。人们期待着 21 世纪在信息处理技 术上新的重大突破，数据管理技术的第三次飞跃即将到来。

3.数据库系统结构的发展
几十年来，运行数据库的计算机系统结构依次发生了下面的变化。
　　（1）主机式系统。大型机、小型机和高性能工作站被用来作数据库的原 始宿主机。在宿主机中包括多用户的操作系统，DBMS 本身，访问数据库的各 种应用程序，与用户终端之间发送接受数据的通信设施等。用户终端多是由 没有处理能力的哑终端充当，或是由承担些处理屏幕图形和用户输入的 PC 机充当。所有的处理工作在宿主机的集中式系统中完成。
和集中式的运算模式相匹配的数据库系统称为集中式数据库系统，在这
样的传统平台上建立的数据库管理系统就是人们一般了解的集中式数据库系 统，如 SQL/DS DB2 早期版本的 lngres 和 Oracle 等。
（2）文件共享式系统。80 年代流行将很多 PC 机互联成一个局域网
（LAN），LAN 中要共享的数据放在网上的一台计算机——文件服务器上。在 这种方式下，所有的数据工作是在运行数据库应用程序的 PC 机上完成，文件 服务器只是负责搜索文件并将其发送给合适的用户。为了维护数据的完整性 和安全性，用户要更新、修改记录或数据文件时要加锁，当同时有多个用户 要访问数据库时，会发生用户间的使用冲突。又因为是对整个文件进行传送， 当对数据库的访问频繁时，网络负担加重，形成网络传输瓶颈。随着用户的 增加，并发事务的处理冲突，网络的传送限制，和 PC 机的处理能力限制，都 导致系统性能下降和复杂行增加。目前广泛使用的 Novell 局域网就是这种模

式的典型。
　　（3）C/S 结构系统。C/S 数据库的一般形式是将数据的处理分成两个部 分：客户机和服务器。前者通常由 PC 机来担任，运行访问、更新、删除数据 库的应用程序。后者由 UNIX（RISC）工作站、小型机、超级服务器或高档 PC 机担任。运行网络操作系统（NOS）和全部或部分 DBMS，操作数据库的更新、 查询、删除、传送等。文件服务器继续为应用程序提供可代享的数据，也可 以和数据库服务器用一台机器。客户机利用 PC 机的运算能力，采用良好的
GUI 界面，处理所有的输入输出，以及部分查询算法的优化、转化，查询结 果的排序、报表生成等功能。DBMS 服务器完成客户机的查询、磁盘访问、返 回查询结果等操作。C/S 方式下，处理工作恰当地分布在客户机和服务器两 端，充分利用网上的各种机器资源，网上传送的不再是整个文件，而是查询 与查询结果，流通量减少。
　　在典型的客户机/服务器结构中，把数据库的工作，例如数据修改、分类， 安全性确认，事务恢复和对共享数据的访问管理，全部放在服务器上进行。 这样一来，事务逻辑所涉及到的安全性、数据完整性和逻辑完整性都可以集 中在服务器上来统一由系统解决，而不是让访问该数据的每个应用程序自己 解决，从而有利于提高性能和完善控制，并减少应用程序开发和维护的开销。
（4）分布式处理。当 C/S 数据库系统需要和其他 C/S 系统或中心宿主机
共享数据时，就形成了分布式处理系统。在一个分布式处理系统中，用户只 要向本地数据库服务器发出请求，本地服务器确定它没有该数据后，就把该 请求送入网络，从适当的数据库服务器中取得数据，并把数据和本地机上的 数据一起发回给用户。
和运算模式的变化相关，数据库系统经历了集中式数据库系统
（Centralized DBS）、分散式数据库系统（DistributedDBS）、C/S 式数据 库系统和分布式数据库系统的演变。在数据库应用领域，由于集中式数据库 系统要求终端和主机不能相隔太远，而在实际应用中，却有这种要求，比如 东城储蓄所和西城储蓄所之间，解决这个问题的是分散式数据库系统。在分 散式数据库系统中，每个节点有自己的数据库系统，中心计算机只保留一些 类似存款总数等的关键性帐目，而不保留每个节点的帐目副本。
像分散式 DBS 一样，分布式（Dietributed DBS）DBS 也是由计算机网络
联结的一组结点组成。不同的是这组网络联结的一群结点共同构成了一个统 一的分布式数据库，由一个统一的 DDBMS 来管理。对 DDBS 来说，其每一个结 点上都是一个多用户系统。将 PC 机联网，由于每个结点上都是单用户的 DBMS，不能算真正的 DDBMS。某结点上的一个用户所存取的数据可能物理地 存放在网络上的其他结点上，甚至该用户所提交事务的计算工作也是在某个 另外的结点上完成。但是该用户感觉不到这种物理上的分布性。这就是结点 透明性（Site Tranparency）。无论用户在哪个结点上，他都感到整个 DDBS 就处于他所在的结点。
　　容易想象，这样的分布式数据库系统是非常复杂而庞大的软件系统。国 际上对 DDBMS 的研究始于 70 年代中期，最有名的先驱系统是美国计算机公司
（CCA）公司为美国国防部制的 SDD-1 系统。对此后全球的 DDBMS 的研制产生 了决定性的影响。这种完全透明的 DDBMS 是完全分布式的，不存在任何中心 控制。例如 SDD-1 控制上百个军事基地，若其中某些军事基地被炸毁则余下 的部分照常运转。反过来若要增加一些基地，则整个系统也立即可平滑地扩