中国科学院研究生教学丛书

分布式数据库系统及其应用

（第二版）

邵佩英　编著

北　京

内　容　简　介

　　本书在第一版的基础上做了较大的修改，增加了与分布式数据库技术密切相关

的、新的网络与数据库的接口技术，基于组件的新的软件开发方法，ＷＷＷ 数据库，移动

数据库，数据仓库和数据挖掘等内容，反映了分布式数据库技术和应用开发的新的发展

趋势。本书还增加了习题和部分习题的参考答案。本书对分布式数据库系统的基本内容

提供了翔实的讲解，对一些有争议的问题进行了开放式讨论，但对深奥的理论没有采用

繁琐的证明方法，而是采用大量的图示和实例做浅显的解释，从而增加了它的知识性和

易理解性。本书可作为计算机专业高年级本科生的选修课教材，特别适合作研究生的专业课

教材，也可作为从事计算机信息处理研究或相关应用开发人员的参考书。

　图书在版编目（ＣＩＰ）数据

　分布式数据库系统及其应用／邵佩英编著．－２版．北京：科学出版社，２００５　（中国科学院研究生教学丛书）　ＩＳＢＮ ７０３０１５１１３５　Ⅰ．分…　Ⅱ．邵…　Ⅲ．分布式数据库数据库系统　Ⅳ．Ｔ Ｐ３１１．１３　中国版本图书馆 ＣＩＰ 数据核字（２００５）第 ０１６５２６ 号

责任编辑：鞠丽娜／责任校对：刘彦妮

责任印制：吕春珉／封面设计：槐寿明

出版北 京 东 黄 城 根 北 街 １ ６ 号

邮 政 编 码 ： １ ０ ０ ７ １ ７ｈ ｔ ｔ ｐ ：／／ｗ ｗ ｗ ．ｓｃ ｉｅ ｎ ｃ ｅｐ ．ｃｏ ｍ

印刷

科学出版社发行　各地新华书店经销

２０００ 年 ６ 月 第　一　版　　开 本 ：７８７× １０９２ １／１６２００５ 年 ３ 月 第　二　版　 印 张 ：２５ ３／４２００５ 年 ３ 月 第 五 次 印 刷　　　　　字 数 ：６０８ ０００

印 数 ：８ ００１— １２ ０００定价：３８．００ 元

（如有印装质量问题，我社负责调换枙新欣枛）

销售部电话 ０１０－ ６２１３６１３１　　编辑部电话 ０１０－６２１３８９７８－８００２

枟中 国 科 学 院 研 究 生 教 学 丛 书 枠 总编委会

主　　任： 白春礼

副 主 任： 余翔林　师昌绪　杨　乐　汪尔康　沈允钢

黄荣辉　叶朝辉　李　佩

委　　员： 朱清时　匡廷云　叶大年　王　水　冯克勤

冯玉琳　刘政凯　龚　立　侯建勤

枟中 国 科 学 院 研 究 生 教 学 丛 书 枠技 术 学 科 编 委 会

主　　编： 师昌绪

副 主 编： 冯玉琳

编　　委： 刘政凯　徐至展　陈先霖　王占国　马颂德

吴承康　史忠植

枟中国科学院研究生教学丛书 枠序在 ２１世纪曙光初露，中国科技、教育面临重大改革和蓬勃发展

之际，枟中国科学院研究生教学丛书枠——这套凝聚了中国科学院新

老科学家、研究生导师们多年心血的研究生教材面世了。 相信这套

丛书的出版，会在一定程度上缓解研究生教材不足的困难，对提高

研究生教育质量起着积极的推动作用。２１世纪将是科学技术日新月异，迅猛发展的新世纪，科学技术

将成为经济发展的最重要的资源和不竭的动力，成为经济和社会发

展的首要推动力量。 世界各国之间综合国力的竞争，实质上是科技

实力的竞争。而一个国家科技实力的决定因素是它所拥有的科技人

才的数量和质量。我国要想在 ２１世纪顺利地实施“科教兴国”和“可持续发展”战略，实现小平同志规划的第三步战略目标——把我国

建设成中等发达国家，关键在于培养造就一支数量宏大、素质优良、结构合理，有能力参与国际竞争与合作的科技大军，这是摆在我国

高等教育面前的一项十分繁重而光荣的战略任务。中国科学院作为我国自然科学与高新技术的综合研究与发展

中心，在建院之初就明确了出成果出人才并举的办院宗旨，长期坚

持走科研与教育相结合的道路，发挥了高级科技专家多，科研条件

好，科研水平高的优势，结合科研工作，积极培养研究生；在出成果

的同时，为国家培养了数以万计的研究生。当前，中国科学院正在按

照江泽民同志关于中国科学院要努力建设好“三个基地”的指示，在建设具有国际先进水平的科学研究基地和促进高新技术产业发展

基地的同时，加强研究生教育，努力建设好高级人才培养基地，在肩

负起发展我国科学技术及促进高新技术产业发展重任的同时，为国

家源源不断地培养输送大批高级科技人才。质量是研究生教育的生命，全面提高研究生培养质量是当前我

国研究生教育的首要任务。研究生教材建设是提高研究生培养质量

的一项重要的基础性工作。 由于各种原因，目前我国研究生教材的

建设滞后于研究生教育的发展。 为了改变这种情况，中国科学院组

织了一批在科学前沿工作，同时又具有相当教学经验的科学家撰写

研究生教材，并以专项资金资助优秀的研究生教材的出版。 希望通

过数年努力，出版一套面向 ２１世纪科技发展，体现中国科学院特色

的高水平的研究生教学丛书。 本丛书内容力求具有科学性、系统性

和基础性，同时也兼顾前沿性，使阅读者不仅能获得相关学科的比

较系统的科学基础知识，也能被引导进入当代科学研究的前沿。 这

套研究生教学丛书，不仅适合于在校研究生学习使用，也可以作为

高校教师和专业研究人员工作和学习的参考书。“桃李不言，下自成蹊。”我相信，通过中国科学院一批科学家的

辛勤耕耘，枟中国科学院研究生教学丛书枠将成为我国研究生教育园

地的一丛鲜花，也将似润物春雨，滋养莘莘学子的心田，把他们引向

科学的殿堂，不仅为科学院，也为全国研究生教育的发展作出重要

贡献。

· ｉｉ· 分布式数据库系统及其应用

前　　言

本书作为中国科学院研究生教学丛书之一已经出版四年多了。据有关部门反映，这是

一本备受欢迎的数据库系统教材。 它全面、系统地阐述了分布式数据库系统的基本理论、概念原理、结构特点、存在问题、设计思想、技术方法；重点论述了分布式数据库的查询优

化、事务管理、并发控制、可靠性、安全性和目录管理；讨论了客户机／服务器模式的概念、结构、工作方式以及与分布式数据库系统的关系；展望了分布式数据库系统的发展前景。

现代数据库管理技术在当前信息社会中的关键作用已经变得更加清晰，毕竟

Ｉｎｔｅｒｎｅｔ 仅仅是一个通信系统，它的真正价值是从数据库中读取或存入数据和信息。 因

此，随着 Ｉｎｔ ｅｒｎｅｔ 和无线技术的发展，特别是 ＷＷＷ 建立以来，它们与分布式数据库有着

极其紧密的关系。从特定意义上说，整个 Ｉｎｔｅｒｎｅｔ 就是一个巨大的“分布式数据库”。同时，随着时间的推移，本书中的内容，特别是后面部分的内容，已经有了相当大的变化。与分布

式数据库技术密切相关的、新的数据库与网络的接口技术、新的软件开发方法、ＷＷＷ 数

据库、移动数据库的产生和应用，以及数据仓库、联机分析处理（ＯＬＡ Ｐ）和数据挖掘已经

成为了数据库技术研究、开发和应用最活跃的热点之一。考虑到上述原因，作者根据本人的教学实践和有关反馈信息，对第一版中的内容做了

如下几个方面的修改。对第一至四章的修改主要是调整结构、补充和进一步完善有关内容。对第五至七章，除修改、补充和进一步完善外，新增加的内容包括分布式事务管理的

可串行化调度测试，两阶段封锁协议的实现方法，基于时间戳排序的多版本技术，采用验

证锁的多版本两阶段封锁技术；关于分布式可靠性协议中的网络分割与提交协议；分布式

数据库安全中的用户账户和数据库审计，统计数据库的安全性，数据加密技术，目录管理

的重要性等内容。对第八章的修改除调整结构、补充和进一步完善外，新增加了客户机／服务器计算模

式的远景展望，创建基于客户机／服务器模式系统的自动化设计工具，创建基于客户机／服务器模式系统的技术和方法，基于组件的软件开发技术，异构数据源访问接口技术和方法

等内容。删除了第一版的第九章，本书新增加的第九章是：分布式数据库与 ＷＷＷ 数据库和

移动数据库。这两类数据库与分布式数据库有着极其紧密的关系，研究支持它们的基本技

术，并考察它们将会如何影响分布式数据库系统。对第十章的修改除调整结构、补充和进一步完善外，新增加了对象关系数据库系统

的产生和发展，重点介绍 ＳＱ Ｌ ３语言对对象关系数据库系统的支持，讨论嵌套关系模型。本书增加了第十一章：数据仓库与数据挖掘。本章概括地论述了数据库技术的最新应

用领域：数据仓库、联机分析处理和数据挖掘的关键概念、数据模型、功能结构、技术方法，通过实例给出支持决策的方法，以及介绍了一些预期的研究方向。数据仓库可以看成是要

求事先进行多种活动的一种过程；数据挖掘可以认为是从现存的数据仓库中发现知识的

一个活动。本书增加的章后练习习题涉及了概念、理论、算法、技术和方法。给出章后练习习题的

目的在于使学生们能对每一章学到的知识进行复习、回顾和系统化，有的习题还要求将所

学知识应用到一个小的、实际的，但有约束的例子中，以进一步巩固所学的知识。本书第二版继续保持了第一版的特点。所有概念都以一种技术上完备，而又易于理解

的方式表达，并尽量减少各种符号的使用。 它没有采用繁琐的证明方法，而是采用了大量

的图示和实例描述概念和预期的结果，从而进一步增加了它的知识性和易理解性。本书内

容涵盖了分布式数据库研究领域的各个关键问题，并以真实的实例系统引入分布式数据

库的设计技术和方法。书中对分布式数据库技术的基本内容提供翔实的讲解，对深奥的理

论做了浅显的解释，对一些有争议的问题进行了开放式的讨论，并充分反映了分布式数据

库技术和应用开发的新的发展趋势。通过本书的学习，读者可以对分布式数据库系统的整

体结构、设计技术和关键问题有深入的认识和理解，同时可以熟识分布式数据库系统的理

论基础和应用方法。作者认为应当用一年的时间来学习这门课程。但是如果仅仅有一个学期的时间，可以

选择本书的第一至七章进行系统学习，而将八至十一章作为参考资料。本书适合作为计算机专业高年级本科生的选修课教材，特别适合作为研究生的专业

课教材，还可作为高校教师及从事计算机信息处理研究或相关应用开发人员工作和学习

的参考资料。 在学习本书之前，读者应具有数据库的基本概念和基础知识。罗晓沛、孙淑玲、李伯民、陈伯飞仔细审阅了全书；宋纲、陈铭、王辉、祝孔强、阚劲松、

颜涯等同学为本书提供有关资料。 科学出版社的有关工作人员为本书的出版做了大量工

作，在此一并表示衷心的感谢。

邵佩英

２００４ 年 １２ 月

· ｉｖ· 分布式数据库系统及其应用

目　　录

第一章　分布式数据库系统概述 １……………………………………………………………１．１　分布式数据库系统的由来与发展 １………………………………………………　　１．１．１　分布式数据库系统的由来 １……………………………………………………　　１．１．２　分布式数据库系统的发展 １……………………………………………………１．２　分布式数据库系统的定义与分类 ４………………………………………………　　１．２．１　分布式数据库系统的定义 ４……………………………………………………　　１．２．２　分布式数据库系统的分类 ６……………………………………………………１．３　分布式数据库系统的体系结构和组成成分 ８……………………………………　　１．３．１　分布式数据库系统的体系结构 ８………………………………………………　　１．３．２　分布式数据库的组成成分 ９……………………………………………………　　１．３．３　分布式数据库中数据的分片与分布 ９……………………………………………　　１．３．４　分布式数据库的模式结构 １２……………………………………………………　　１．３．５　分布式数据库管理系统的功能结构 １５…………………………………………　　１．３．６　分布式数据库管理系统的一种参考模型 １７……………………………………１．４　分布式数据库系统中数据的独立性与分布透明性 ２５……………………………　　１．４．１　分布式数据库系统中数据的独立性与分布透明性概述 ２５………………………　　１．４．２　分布式数据库简单查询与分布透明性 ２６………………………………………　　１．４．３　分布式数据库复杂查询与分布透明性 ２９………………………………………　　１．４．４　分布式数据库更新应用与分布透明性 ３１………………………………………１．５　分布式数据库系统的优点和存在的技术问题 ３４…………………………………　　１．５．１　分布式数据库系统的优点 ３４……………………………………………………　　１．５．２　分布式数据库系统中存在的技术问题 ３５………………………………………１．６　本章小结 ３７…………………………………………………………………………习题 ３８……………………………………………………………………………………

第二章　分布式数据库系统的设计 ３９………………………………………………………２．１　分布式数据库系统设计概述 ３９……………………………………………………　　２．１．１　分布式数据库系统的创建方法 ３９………………………………………………　　２．１．２　分布式数据库系统设计的内容 ４１………………………………………………　　２．１．３　分布式数据库设计的目标 ４１……………………………………………………　　２．１．４　分布式数据库设计的方法 ４３……………………………………………………２．２　自顶向下设计分布式数据库 ４４……………………………………………………　　２．２．１　自顶向下设计分布式数据库的步骤和内容 ４４……………………………………　　２．２．２　数据的分片设计 ４４……………………………………………………………

　　２．２．３　数据库片段的位置分配设计 ４９…………………………………………………２．３　ＤＡ Ｔ ＡＩＤＤ 方法 ５２………………………………………………………………　　２．３．１　ＤＡＴ Ａ ＩＤＤ 方法概述 ５２………………………………………………………　　２．３．２　分布要求分析阶段 ５３…………………………………………………………　　２．３．３　分布设计阶段 ５４………………………………………………………………２．４　实例研究：飞机订票系统 ５５………………………………………………………　　２．４．１　实例研究概述 ５５………………………………………………………………　　２．４．２　飞机订票系统中的分布要求分析 ５７……………………………………………　　２．４．３　飞机订票系统中的分布设计 ５９…………………………………………………２．５　自底向上设计分布式数据库 ６１……………………………………………………　　２．５．１　自底向上设计分布式数据库要解决的问题 ６１……………………………………　　２．５．２　构造全局模式的设计问题和解决方法 ６２………………………………………　　２．５．３　自底向上综合的一个例子 ６５……………………………………………………２．６　本章小结 ６６…………………………………………………………………………习题 ６７……………………………………………………………………………………

第三章　分布式数据库中的查询处理和优化 ６９……………………………………………３．１　分布式查询优化概述 ６９……………………………………………………………　　３．１．１　分布式查询优化的目标 ６９……………………………………………………　　３．１．２　分布式查询优化的准则和代价估算 ６９…………………………………………　　３．１．３　分布式查询策略的重要性 ７０……………………………………………………３．２　分布式查询优化中的基础知识 ７２…………………………………………………　　３．２．１　用关系代数表达式和 ＳＱＬ 语句表示一个查询 ７２………………………………　　３．２．２　查询树 ７３……………………………………………………………………　　３．２．３　等价变换规则的概念和术语 ７４…………………………………………………　　３．２．４　等价变换规则 ７５………………………………………………………………３．３　分布式查询的分类与层次结构 ７６…………………………………………………　　３．３．１　分布式查询的分类 ７６…………………………………………………………　　３．３．２　分布式查询处理的层次结构 ７８…………………………………………………３．４　基于关系代数等价变换的查询优化处理 ７９………………………………………　　３．４．１　基于关系代数等价变换查询优化处理的基本原理和实现方法 ７９…………………　　３．４．２　基于关系代数等价变换的查询优化处理举例 ８０…………………………………３．５　基于半连接算法的查询优化处理 ８３………………………………………………　　３．５．１　采用半连接方法表示连接操作 ８３………………………………………………　　３．５．２　采用半连接算法优化连接操作的基本原理和步骤 ８４……………………………３．６　基于直接连接算法的查询优化处理 ８５……………………………………………　　３．６．１　利用站点依赖信息的算法 ８５……………………………………………………　　３．６．２　分片和复制算法 ８７……………………………………………………………　　３．６．３　站点依赖和数据复制结合 ８９……………………………………………………

· ｖｉ· 分布式数据库系统及其应用

　　３．６．４　Ｈａｓｈ 划分算法 ９０……………………………………………………………　　３．６．５　不同方法的比较 ９２……………………………………………………………３．７　直接连接操作的常用策略 ９２………………………………………………………　　３．７．１　直接连接操作的一般常用策略 ９２………………………………………………　　３．７．２　利用并行性的直接连接操作策略 ９３……………………………………………３．８　本章小结 ９４…………………………………………………………………………习题 ９５……………………………………………………………………………………

第四章　分布式数据库中的事务管理和恢复 ９７……………………………………………４．１　分布式事务概述 ９７…………………………………………………………………　　４．１．１　分布式事务定义和特性 ９７……………………………………………………　　４．１．２　分布式事务的结构和事务状态 ９９………………………………………………　　４．１．３　分布式事务管理的问题和目标 １０２……………………………………………４．２　分布式事务的执行与恢复 １０４……………………………………………………　　４．２．１　分布式事务管理的抽象模型 １０４………………………………………………　　４．２．２　分布式事务执行的控制模型 １０５………………………………………………　　４．２．３　分布式数据库系统中的故障 １０７………………………………………………　　４．２．４　事务故障恢复的基本概念 １０８…………………………………………………　　４．２．５　事务故障的恢复 １１１…………………………………………………………　　４．２．６　分布式事务的执行与恢复举例 １１３……………………………………………４．３　两阶段提交协议 １１４………………………………………………………………　　４．３．１　两阶段提交协议的基本思想和内容 １１４…………………………………………　　４．３．２　两阶段提交协议的通信结构 １１７………………………………………………　　４．３．３　两阶段提交协议与故障恢复 １２２………………………………………………４．４　分布式数据库中的数据更新 １２４…………………………………………………　　４．４．１　多站点的数据更新 １２４…………………………………………………………　　４．４．２　主文本更新法 １２５……………………………………………………………　　４．４．３　快照方法 １２６…………………………………………………………………４．５　分布式事务增强数据库一致性 １２７………………………………………………　　４．５．１　业务规则的一致性 １２７…………………………………………………………　　４．５．２　冗余数据的一致性 １２８…………………………………………………………４．６　本章小结 １３０………………………………………………………………………习题 １３０……………………………………………………………………………………

第五章　分布式数据库中的并发控制 １３１……………………………………………………５．１　并发控制的概念和理论 １３１………………………………………………………　　５．１．１　并发控制的概念 １３１…………………………………………………………　　５．１．２　事务可串行化理论的基本概念 １３３……………………………………………　　５．１．３　分布式事务的可串行化理论 １３４………………………………………………　　５．１．４　分布式事务的可串行化调度测试 １３６…………………………………………

目　　录 · ｖ ｉｉ·

　　５．１．５　并发控制机制的常用方法及其分类 １３９…………………………………………５．２　分布式数据库系统并发控制的封锁技术 １４１……………………………………　　５．２．１　基于封锁的并发控制方法概述 １４１……………………………………………　　５．２．２　两阶段封锁协议 １４７…………………………………………………………　　５．２．３　两阶段封锁协议的实现方法 １５０………………………………………………　　５．２．３　多粒度封锁与意想锁 １５２………………………………………………………５．３　分布式数据库系统中的死锁处理 １５６……………………………………………　　５．３．１　全局死锁与等待图 １５６…………………………………………………………　　５．３．２　死锁的预防方法 １５８…………………………………………………………　　５．３．３　死锁的检测和解决方法 １５９……………………………………………………５．４　分布式数据库系统并发控制的时标技术 １６２……………………………………　　５．４．１　基于时标的并发控制方法 １６２…………………………………………………　　５．４．２　基本时标法 １６４………………………………………………………………　　５．４．３　保守时标法 １６４………………………………………………………………５．５　分布式数据库系统并发控制的多版本技术 １６６…………………………………　　５．５．１　基于时间戳排序的多版本技术 １６６……………………………………………　　５．５．２　采用验证锁的多版本两阶段封锁 １６７…………………………………………５．６　分布式数据库系统并发控制的乐观方法 １６８……………………………………５．７　本章小结 １７０………………………………………………………………………习题 １７１……………………………………………………………………………………

第六章　分布式数据库中的可靠性 １７３………………………………………………………６．１　分布式数据库可靠性的概念及其度量 １７３………………………………………　　６．１．１　分布式数据库可靠性的概念 １７３………………………………………………　　６．１．２　平均故障间隔时间和平均修复时间 １７４…………………………………………６．２　分布式数据库系统的故障原因和容错技术 １７５…………………………………　　６．２．１　分布式数据库系统中系统失败的原因 １７５………………………………………　　６．２．２　基本的容错方法和技术 １７７……………………………………………………６．３　分布式数据库的可靠性协议 １７９…………………………………………………　　６．３．１　分布式数据库可靠性协议的组成 １７９…………………………………………　　６．３．２　两阶段提交协议的演变 １８０……………………………………………………　　６．３．３　事务阻断与终结协议 １８１………………………………………………………　　６．３．４　两阶段提交协议的终结协议 １８２………………………………………………　　６．３．５　两阶段提交协议的恢复协议 １８５………………………………………………　　６．３．６　三阶段提交协议 １８７…………………………………………………………６．４　网络分割与提交协议 １９０…………………………………………………………　　６．４．１　网络分割概述 １９０……………………………………………………………　　６．４．２　网络分割的提交协议 １９１………………………………………………………６．５　不一致性的检测和解决方法 １９７…………………………………………………

· ｖｉｉｉ· 分布式数据库系统及其应用

　　６．５．１　决定网络的状态 １９７…………………………………………………………　　６．５．２　不一致性的检测和解决方法 １９９………………………………………………　　６．５．３　检查点和冷启动 ２０１…………………………………………………………６．６　本章小结 ２０３………………………………………………………………………习题 ２０４……………………………………………………………………………………

第七章　分布式数据库的安全性与目录管理 ２０６……………………………………………７．１　数据库安全性概述 ２０６……………………………………………………………　　７．１．１　数据库安全性的概念 ２０６………………………………………………………　　７．１．２　分布式数据库的不安全因素 ２０７………………………………………………　　７．１．３　分布式数据库安全需求和安全措施分析 ２０８……………………………………　　７．１．４　分布式数据库的用户账户和数据库审计 ２１０……………………………………７．２　安全数据模型与多级安全数据库 ２１１……………………………………………　　７．２．１　数据库安全术语与基本概念 ２１１………………………………………………　　７．２．２　基于授予／收回权限的自主访问控制 ２１３………………………………………　　７．２．３　多级安全 ＢＬＰ 模型 ２１７………………………………………………………　　７．２．４　基于多级安全性分类级别标记的强制访问控制 ２１９……………………………７．３　统计数据库的安全性 ２２２…………………………………………………………７．４　数据加密 ２２３………………………………………………………………………　　７．４．１　数据加密概述 ２２３……………………………………………………………　　７．４．２　公开密钥加密算法和数据签名 ２２４……………………………………………７．５　计算机系统与数据库管理系统的安全评估标准 ２２６……………………………　　７．５．１　计算机系统的安全评估标准 ２２６………………………………………………　　７．５．２　数据库管理系统的安全评估标准 ２２７…………………………………………　　７．５．３　当前流行的几种 ＲＤＢＭ Ｓ 安全机制 ２２８…………………………………………７．６　分布式数据库的目录结构和管理 ２３１……………………………………………　　７．６．１　分布式数据库目录的重要性 ２３１………………………………………………　　７．６．２　分布式数据库目录的内容及用途 ２３２…………………………………………　　７．６．３　分布式数据库目录系统的组织方式及逻辑结构 ２３４……………………………　　７．６．４　分布式数据库目录的分布方式 ２３６……………………………………………　　７．６．５　具有站点自治性的对象命名和目录管理 ２３７……………………………………７．７　分布式数据库中权限保护和用户识别 ２３８………………………………………　　７．７．１　分布式数据库中的权限和保护 ２３８……………………………………………　　７．７．２　分布式数据库中权限规则的分布 ２３９…………………………………………　　７．７．３　分布式数据库系统中的用户识别和分类 ２３９……………………………………７．８　本章小结 ２４０………………………………………………………………………习题 ２４１……………………………………………………………………………………

第八章　分布式数据库与客户机／服务器模式 ２４２…………………………………………８．１　客户机／服务器计算模式 ２４２………………………………………………………

目　　录 · ｉｘ ·

　　８．１．１　客户机／服务器计算模式概念 ２４２………………………………………………　　８．１．２　客户机／服务器环境下应用成分的分布和开放性 ２４４……………………………　　８．１．３　客户机／服务器模式的体系结构 ２４６……………………………………………８．２　客户机／服务器模式的定位 ２４９……………………………………………………　　８．２．１　计算环境演变的分析 ２４９………………………………………………………　　８．２．２　客户机／服务器模式的定位 ２５３…………………………………………………８．３　客户机／服务器模式的特性和优缺点 ２５４…………………………………………　　８．３．１　客户机／服务器模式的特性 ２５４…………………………………………………　　８．３．２　客户机／服务器模式的优点与不足 ２５５…………………………………………８．４　客户机／服务器模式的远景展望 ２５６………………………………………………８．５　分布式数据与分布式访问 ２５９……………………………………………………　　８．５．１　从集中式到分布式数据的转移 ２５９……………………………………………　　８．５．２　数据分布的基本形式 ２６０………………………………………………………　　８．５．３　数据分布的技术 ２６４…………………………………………………………　　８．５．４　分布式数据的访问 ２６６…………………………………………………………８．６　创建基于客户机／服务器模式的数据库系统 ２６９…………………………………　　８．６．１　创建客户机／服务器系统的自动化设计工具 ２６９…………………………………　　８．６．２　创建客户机／服务器系统的技术和方法 ２７４……………………………………　　８．６．３　基于组件的软件开发技术和方法 ２７５…………………………………………　　８．６．４　异构数据源访问接口技术和方法 ２７８…………………………………………８．７　本章小结 ２８１………………………………………………………………………习题 ２８１……………………………………………………………………………………

第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库 ２８３………………………………９．１　ＷＷＷ 数据库系统的产生及其运行环境 ２８３……………………………………　　９．１．１　ＷＷＷ 数据库系统的产生 ２８３…………………………………………………　　９．１．２　统一资源定位器和超文本传输协议 ２８３…………………………………………　　９．１．３　超文本标记语言和主页 ２８５……………………………………………………９．２　ＷＷＷ 数据库系统的体系结构 ２８７………………………………………………　　９．２．１　概述 ２８７………………………………………………………………………　　９．２．２　ＷＷＷ 浏览器 ２８８……………………………………………………………　　９．２．３　ＷＷＷ 服务器 ２８９……………………………………………………………９．３　ＷＷＷ 数据库 ２９０…………………………………………………………………　　９．３．１　ＷＷＷ 数据库的建立和访问 ２９０………………………………………………　　９．３．２　ＷＷＷ 数据库接口 ２９２…………………………………………………………　　９．３．３　ＷＷＷ 数据库面临的问题 ２９５…………………………………………………９．４　移动数据库系统概述 ２９６…………………………………………………………　　９．４．１　移动数据库的产生背景 ２９６……………………………………………………　　９．４．２　移动计算环境的体系结构 ２９７…………………………………………………

· ｘ· 分布式数据库系统及其应用

　　９．４．３　移动数据库系统的参考模型 ２９９………………………………………………９．５　移动数据库系统的数据管理问题 ３００……………………………………………　　９．５．１　移动应用中的数据 ３００…………………………………………………………　　９．５．２　移动计算环境下的数据管理问题 ３０１…………………………………………９．６　移动数据库系统实现技术和应用研究 ３０２………………………………………　　９．６．１　移动数据库数据的同步复制 ３０２………………………………………………　　９．６．２　移动数据库数据的移动事务管理 ３０４…………………………………………　　９．６．３　移动数据库系统的微型化 ３０５…………………………………………………９．７　间歇同步移动数据库 ３０６…………………………………………………………９．８　本章小结 ３０６………………………………………………………………………习题 ３０８……………………………………………………………………………………

第十章　分布式数据库系统的发展趋势 ３０９…………………………………………………１０．１　并行数据服务器与分布式数据库系统 ３０９………………………………………　　１０．１．１　并行数据服务器体系结构 ３０９…………………………………………………　　１０．１．２　并行数据服务器数据定位 ３１２…………………………………………………　　１０．１．３　并行操作处理的算法 ３１５……………………………………………………　　１０．１．４　并行查询处理的算法 ３２１……………………………………………………１０．２　分布式知识库系统 ３２２……………………………………………………………　　１０．２．１　知识库 ３２２……………………………………………………………………　　１０．２．２　逻辑查询处理 ３２５……………………………………………………………　　１０．２．３　并行递归查询处理 ３２７………………………………………………………１０．３　分布式面向对象数据库 ３３２………………………………………………………　　１０．３．１　面向对象数据库 ３３３…………………………………………………………　　１０．３．２　分布式对象管理 ３３５…………………………………………………………１０．４　对象关系数据库 ３３７……………………………………………………………　　１０．４．１　对象关系数据库系统产生背景 ３３７……………………………………………　　１０．４．２　对象关系数据库系统的特点 ３３８……………………………………………　　１０．４．３　ＳＱＬ ３ 标准对对象关系系统的支持 ３３９………………………………………　　１０．４．４　扩展类型系统的实现以及相关问题 ３４１………………………………………　　１０．４．５　嵌套关系数据模型 ３４２………………………………………………………１０．５　本章小结 ３４４………………………………………………………………………习题 ３４５……………………………………………………………………………………

第十一章　数据仓库和数据挖掘 ３４７…………………………………………………………１１．１　数据仓库 ３４７………………………………………………………………………　　１１．１．１　数据仓库的定义、特征和结构 ３４７……………………………………………　　１１．１．２　数据仓库的元数据 ３５１………………………………………………………　　１１．１．３　数据仓库的数据模型 ３５３……………………………………………………　　１１．１．４　数据仓库的设计 ３５７…………………………………………………………

目　　录 · ｘ ｉ·

　　１１．１．５　数据仓库实现中的困难和开放问题 ３６２………………………………………１１．２　联机分析处理 ３６３…………………………………………………………………　　１１．２．１　ＯＬＡＰ 的数据组织 ３６３………………………………………………………　　１１．２．２　ＯＬＡＰ 的衡量标准和多维数据分析功能 ３６５…………………………………　　１１．２．３　ＯＬＡＰ 的多层结构 ３６８………………………………………………………１１．３　知识发现和数据挖掘 ３７０…………………………………………………………　　１１．３．１　知识发现和数据挖掘的概念 ３７０………………………………………………　　１１．３．２　数据挖掘技术概述 ３７１………………………………………………………　　１１．３．３　关联规则 ３７４…………………………………………………………………　　１１．３．４　其他数据挖掘问题 ３７７………………………………………………………　　１１．３．５　数据挖掘的应用 ３７９…………………………………………………………　　１１．３．６　商业化数据挖掘工具 ３８０……………………………………………………１１．４　本章小结 ３８１………………………………………………………………………习题 ３８２……………………………………………………………………………………

习题参考答案 ３８３………………………………………………………………………………主要参考文献 ３９５………………………………………………………………………………

· ｘｉｉ· 分布式数据库系统及其应用

第八章　分布式数据库与客户机／服务器模式

可以支持前面讨论过的所有功能类型的 ＤＤＢＭＳ 还没有完全开发成功，然而，分布式

数据库应用正在发展成为基于客户机／服务器模式的应用。实际上，基于客户机／服务器模

式的系统可以看作是真正意义上的分布式系统的一种特殊情况。更确切地说，一个基于客

户机／服务器模式的系统是这样的一个分布式系统：１） 某些站点是客户机站点，而另一些站点是服务器站点；２） 所有的数据都驻留在服务器站点；３） 所有的应用都在客户机站点运行；４） 一般不提供完全的位置透明性，即“存在接缝”。本章将着重讨论 ＤＤＢＭＳ 环境中的基于客户机／服务器模式的系统。

８．１　客户机／服务器计算模式

８．１．１　客户机／服务器计算模式概念

　　客户机／服务器（ｃｌｉｅｎｔ／ｓｅｒｖｅｒ）这一概念 早用于描述软件的体系结构，表示两个程

序间的关系，即一个是提出请求的应用程序，另一个是服务程序，它们之间的交互不需要

任何通信设施。 此时，它们可能就是在同一台机器上运行的调用和被调用程序，而且请求

／服务交互可以是不同步的。从概念上讲，客户机／服务器模式可定义为一种特殊的协作式处理模式，客户机和服

务器两者都参与同一个应用程序的处理，其中软件成分相互协作以完成特定的应用程序

功能，而硬件资源则提供软件成分相互协作的设施。所以，可以把客户机／服务器模式的定

义扩展到不仅包括软件成分间的协作处理，而且包括硬件成分间的交互作用。 这样一来，术语“客户机／服务器模式”就有两种含义：一种是客户机和服务器软件成分间的协作处

理，另一种是硬件“客户机”工作站和“服务器”计算机系统间的联系。 如果不考虑硬件成

分，软件成分间的协作处理有时称作请求／服务模式，而把考虑硬件作用的模式视为客户

机／服务器模式。 由此可见，客户机／服务器模式的定义强调协作处理，如图 ８．１ 所示。在一个 ＤＤＢＭ Ｓ 环境中，客户机／服务器模式的协作式处理是一种特殊的分布式处

理。 它把一个计算机应用系统分成如下的三个基本组成部分：１） 服务器：专门从事提供某项服务功能的计算机系统，称为服务器。数据库服务器软

件负责站点上的局部数据管理，很像集中式的 ＤＢＭＳ 软件。２） 客户机：面向 终用户，完成各自业务处理及用户界面的计算机系统，称为客户

机。 客户机软件负责大部分的分布应用功能，它从 ＤＤＢＭ Ｓ 目录访问数据分布信息，处理

要求访问多于一个站点的请求，并且客户机软件也处理所有的用户接口。

图 ８．１　客户机／服务器模式

３） 中间件：连接服务器和客户机的部分，称为中间件，也称连接件。包括通信软件，如网络协议、开放数据库互联（ＯＤＢＣ）等，有时与分布式操作系统相结合。 提供通信原语，为客户机用户在所需的服务器间传送命令和数据。

两种极端情况：１） 哑客户机：主机处理系统。 客户机是哑终端，服务器是主机本身。２） 哑服务器：局域网上的服务器（只负责存储文件或打印）和全部客户机。总之，一个支持客户机／服务器模式的分布式数据库管理系统应该具有：服务器要有

数据管理、处理能力，能提供网络传输优化能力，以保证网络上负载的可调和均衡处理；客户机不但要提供多种工具帮助用户生成应用界面，而且还应有很强的网络适应能力，以保

证应用系统在网络上的正确运行；此外，还应提供连接客户机和服务器的中间件。大量的关系 ＤＢＭ Ｓ 产品都已采用了这种方案。 它们为客户机提供了一个 ＳＱ Ｌ 服务

器，每一个客户机必须配置合适的 ＳＱ Ｌ 查询，并为用户提供用户接口和编程语言接口功

能。 因为 ＳＱＬ 是相关的标准，不同厂商提供的多种的 ＳＱＬ 服务器一般都可以接受 ＳＱ Ｌ命令。 客户机可以引用存放在各种 ＳＱＬ 服务器中的包含数据分布信息的数据字典，还可

以访问模板，将一个全局查询分解为若干局部查询，那些局部查询可以在不同的站点上执

行。 在 ＳＱＬ 查询的过程中，客户机和服务器之间的互动可能按如下步骤进行：１） 客户机分析一个用户查询，并将其分解成为若干独立站点的子查询，每个站点的

查询被送到相应的服务器站点。２） 每个服务器处理局部查询，并将结果数据送回到客户机站点。３） 客户机站点合并各子查询的结果，并生成原先提交的查询的结果。在这里，ＳＱＬ 服务器也被称为事务服务器（ｔ ｒａｎｓａｃｔｉｏｎ ｓｅｒｖ ｅｒ ）或数据库处理器

（ｄａｔａｂａｓｅ ｐｒｏ ｃｅｓｓｏｒ，ＤＰ ）或后端机 （ｂａｃｋｅｎｄ ｍａｃｈｉｎｅ），而客户机被称为应用处理器

（ａｐｐｌｉｃａｔ ｉｏｎ ｐｒｏ ｃｅｓｓｏｒ，ＡＰ ）或前端机（ｆｒｏｎｔｅｎｄ ｍａｃｈｉｎｅ）。 客户机与服务器之间的交互

可以由用户在客户机层说明，或者凭借一个专门的 ＤＢＭ Ｓ 客户机模块说明，该专门的

ＤＢＭ Ｓ 客户机模块是 ＤＢＭ Ｓ 包的一部分。 例如，用户也许会知道每个服务器中存储的数

·３４２·第八章　分布式数据库与客户机／服务器模式

据，人工地将一个查询请求分解成为若干个站点上的子查询，并且向不同的站点提交相应

的单个子查询，再由客户机层的用户的进一步查询将结果表显式地合并起来。另一种方法

是使客户机模块自动地执行这些操作。８．１．２　客户机／服务器环境下应用成分的分布和开放性

１．客户机／服务器环境下应用成分的分布

　　通常，一个典型的数据库应用程序可分解为四个组成成分，如图 ８．２ 所示。

图 ８．２　组成数据库应用程序的四个成分

（１） 界面表示逻辑

这是与用户交互的应用代码，界面表示逻辑完成屏幕格式化、屏幕信息读写、窗口管

理、键盘及鼠标管理等任务。 流行的界面表示逻辑设施是各种图形用户界面（ＧＵ Ｉ）。（２） 业务处理逻辑

这是使用输入数据来完成业务处理和规则的应用代码，这些代码通常是用第 ３代语

言（３ＧＬ ）或第 ４代语言（４ＧＬ ）编写的。（３） 数据处理逻辑

这是应用程序中负责数据逻辑（事务逻辑），如完整性判别等的代码，在关系数据库管

理系统上的数据操作一般使用 ＳＱ Ｌ 语言编写。 ＳＱＬ 语言可以嵌入编程语言中，也可以为

编程语言提供调用级接口。（４） 数据库管理

这是应用程序中由 ＤＢＭ Ｓ 来完成实际数据存取处理的程序。 在理想的情况下，ＤＢＭ Ｓ 的数据管理相对于应用的业务处理来说是透明的。虽然 ＤＢＭ Ｓ 不属于应用程序本

身，但它是分布式处理的基本组成部分。在 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 环境下，通常把界面表示逻辑和业务处理逻辑驻留在 ｃｌｉｅｎｔ 上，而把

数据处理逻辑和 ＤＢＭ Ｓ 功能驻留在 ｓｅｒｖ ｅｒ 上。图 ８．３是支持和不支持 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 模式

的 ＤＢＭ Ｓ 情形。因此，设计建立在 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 模式上的一个数据库应用程序，应该在 ｓｅｒｖｅｒ 端完成

·４４２· 分布式数据库系统及其应用

的是数据的管理、组织和处理，即提供数据服务；在网络上传输的应该是客户机的请求和

服务器返回的结果或信息；在 ｃｌｉｅｎｔ 端完成的是业务处理的表示和用户交互的界面。

图 ８．３　支持和不支持 Ｃ／Ｓ 结构的 ＤＢＭ Ｓ 情形

２．客户机／服务器模式的开放性

客户机／服务器模式的内部结构如图 ８．４所示。 它是一个开放式的模式，使得数据库

不仅要支持开放性，而且还要开放系统本身，这种开放性包括用户界面、软硬件平台和网

络协议。利用开放性在客户机一侧提供应用程序接口（Ａ ＰＩ）及网络接口，使得用户仍然可

按照他们所熟悉的、流行的方式开发客户机应用。 在服务器一侧，通过对核心关系数据管

理系统的功能调用，使网络接口满足数据完整性、安全性及故障恢复等要求。有了开放性，数据库服务器就能支持多种网络协议，运行不同厂家的开发工具，而对某一个应用程序，开发工具也可以在不同的数据库服务器上运行并存取不同数据源中的数据，从而给应用

系统的开发提供了极大的灵活性。

图 ８．４　客户机／服务器模式的内部结构

·５４２·第八章　分布式数据库与客户机／服务器模式

８．１．３　客户机／服务器模式的体系结构

在客户机／服务器环境下，客户机、服务器和中间件构成了客户机／服务器模式的基础

结构，如图 ８．５所示。

图 ８．５　客户机／服务器模式体系结构示意图

１．服务器

服务器 典型的任务是提供数据服务。一般而言，服务器应能提供高速大容量的存储

能力、强大的数据处理和管理能力，以及并发运行多个进程的能力。还应提供包括通信、电子邮件和事务处理等能力。服务器按功能类型和简单与复杂程度，可以分为：文件服务器、数据库服务器、事务服务器、文档服务器和其他服务器。

（１） 文件服务器提供文件访问

文件服务器管理着数据文件。 如图 ８．６所示，客户机包含 ＧＵ Ｉ（图形用户界面）和应

用程序代码。用户操纵 ＧＵ Ｉ 同应用程序对话。应用程序对服务器发出对文件的访问请求。服务器复制所请求的文件，并将其返回给客户机，在客户机上由应用程序进行处理。

（２） 数据库服务器提供数据库访问

数据库服务器只对客户机发送所需的数据纪录，从而降低通信费用。图 ８．７ 说明客户

机同数据库服务器之间的对话过程。 客户机由 ＧＵ Ｉ 和应用程序代码组成，应用程序提出

对数据库查询请求，并把这样的请求传送到服务器。 一般情况下，查询是用 ＳＱＬ 提出的。数据库服务器接收并执行来自多个客户机的 ＳＱＬ 查询。 数据库服务器在执行 ＳＱ Ｌ 请求

时，只选择满足 ＳＱ Ｌ 查询条件的数据，然后把选出的数据传回发出请求的客户机，数据在

那里由应用程序进行处理。数据库服务器减少了从服务器到客户机的数据传输量。 数据库服务器通常还要提供

各种辅助功能，如用户识别与认证，实施安全约束，实施业务规则，记载日志，以及自动数

·６４２· 分布式数据库系统及其应用

图 ８．６　文件服务器

图 ８．７　数据库服务器

据库备份等。（３） 事务服务器支持事务处理

事务服务器是一种数据库服务器，它能够本地或远程执行应用程序专用代码（事务）。图 ８．８说明事务服务器由面向应用程序的事务和一个数据库服务器组成，由程序员指定

事务服务器中那些包含应用程序专用代码的事务。 客户机包含 ＧＵ Ｉ，以及构成事务调用

的那部分应用程序，这种调用被传送给服务器。 事务是在事务服务器上执行，这样就可以

保证事务的 Ａ ＣＩＤ 性质。通过对事务以及调用事务的客户机应用程序的仔细设计，程序员可以把客户机和服

务器之间的通信代价减到 小限度。 一般说来，为了设计事务和客户机应用程序，要求程

序员具备熟练的技能。

·７４２·第八章　分布式数据库与客户机／服务器模式

图 ８．８　事务处理服务器

（４） 文档服务器支持文档访问

许多应用部门都要生成所谓“文档”的输出。 如字处理文档、电子数据表、电子绘图和

电子图表、演示图表和“电子幻灯片”、数据库查询结果，以及由不同应用程序生成的报

表等。文档服务器为多用户管理文档。 事实上，文档服务器就是保存电子文档的电子文件

柜。客户机使用户通过指定文档的属性值就能访问文档。当用户访问文档时，客户机即自

动调用创建文档的应用程序，所以用户可以查看文档和编辑文档。某些文档服务器还具备

这样一种功能，用户只要指定文档中所包含的特定单词就能访问文档。大多数文档服务器

支持关键词搜索功能，由用户指定的特定单词来定位文档。（５） 其他数据服务器

１） 支持访问公告牌。公告牌是一种数据库，其中保存有关一般性通告和新闻的消息。从用户的角度来看，这种数据库就像一块公告牌，从那里可以浏览和查找张贴的各种告

示，用户也可以在其中贴出自己的告示。２） 支持访问新闻。 有几家通讯社通过广域网将源源不断的电子新闻向全世界传播，

其中包括美联社、合众国际社和路透社的新闻服务，道· 琼斯股票交易所则播发股票行

情。一个新闻服务器要采集和存储广播信息，当用户需要时可以从中检索信息。 用户访问

新闻服务器的信息是通过他们的桌面客户机系统进行的。除采集新闻之外，新闻服务器可

以筛选新闻条目，按用户个人的要求选择特殊的新闻，这种选择以是否符合预先作出规定

的用户描述文件为准，并把选出后的新闻条目放进用户的“入选箱”。数据服务器通常还应提供数据访问以外的支持。 多数服务器还支持或提供多任务处

理、安全保障、计量措施、实施业务规则、位置透明性、横向可伸缩性等功能。

·８４２· 分布式数据库系统及其应用

２．客户机

客户机／服务器应用是以客户机为中心的，客户机可以观察和体会到服务器提供的服

务。 按照客户机／服务器模式中应用功能的分布，所有的客户机主要完成界面表示和一些

业务逻辑（一部分或全部）功能。界面表示逻辑一方面反映应用程序的业务处理逻辑，另一

方面提供 终用户的使用接口，用户通过客户机接口访问各种服务器，得到相应的服务，还包括与所有外设（终端）和其他 Ｉ／Ｏ 设备的交互。 客户机类型包括：

１） 非图形化用户接口：包括条形码、扫描器、传真机、仿真终端、测试仪、机器人等；２） 图形化用户接口：大都基于 Ｗｉｎｄｏｗ ｓ 的软件和设备（如 ＰＣ 机、工作站等）；３） 面向对象接口（ＯＯＩ）：可视化、多媒体处理软件及其设备。一般来说，客户机软件的类型包括：１） 公共应用程序：如字处理软件、报表编制软件、图形软件及项目管理软件等；２） 数据库前端软件：如 Ｓｙｂａｓｅ 的 ｉＳＱＬ ，Ｏｒａｃｌｅ 的 ＰＬ／ＳＱ Ｌ…；３） 应用生成和开发软件：如 Ｐｏｗ ｅｒＢｕｉｌｄｅｒ， Ｖ ｉｓｕａｌＣ＋＋， ＶｉｓｕａｌＢａｓ ｉｃ，…。使用界面开发工具开发 终用户使用界面（人机接口）和业务处理逻辑程序。３．中间件

中间件（ｍｉｄｄｌｅｗ ａｒｅ）是个飞速发展的领域，是软件技术的大杂烩，也是开发客户机／服务器应用的关键。 中间件泛指 ｃｌｉｅｎｔ 和 ｓｅｒｖｅｒ 之间的软件，也称客户机／服务器的接口

软件。中间件分为通用中间件和专用中间件。 通用中间件如各种网络操作系统（ＮＯＳ）、各

种网络传输协议。 专用中间件有：１） 数据库连接中间件：基于 ＳＱ Ｌ 的异构数据库互联操作，如 ＯＤＢＣ，ＪＤＢＳ 等；２） 事务处理中间件：基于 ＲＰＣ 等，共享不同服务器资源；３） 组件中间件：电子邮件及 Ｌｏ ｔｕｓＮｏ ｔｅｓ 等；４） 对象中间件：允许 Ｃｌｉｅｎｔ 调用驻留在远程服务器上的对象；５） ＤＤＳＭ 中间件：允许管理者与代理进行对话等。

８．２　客户机／服务器模式的定位

客户机／服务器模式技术可以降低软件开发和维护成本，增强应用的可移植性，改善

网络和系统的性能，提高用户的工作效率，保护用户的投资，甚至可以减少对小型机和大

型机的需求。 我们通过对计算环境演变的分析来定位客户机／服务器模式。８．２．１　计算环境演变的分析

１．主机处理系统

　　客户机／服务器计算模式实现了一种协作式处理：客户机发出请求到达服务器，服务

·９４２·第八章　分布式数据库与客户机／服务器模式

器处理请求并将结果返回到客户机。客户机／服务器这种协作式处理其实就是一种特殊的

分布式处理，资源分布于两个或更多的分离的计算机系统上。分布式系统的驱动力之一来

源于主机处理系统，这种驱动力业界称之为“向下优化（ｄｏｗ ｎ ｓｉｚｉｎｇ）”。在主机系统中，如图 ８．９所示，所有程序都在一个主机上运行，包括 ＤＢＭ Ｓ、应用程

序，以及负责向终端发送和接收数据的通信设施。 所有数据都存储在主机上，用户通过本

地或远程终端来访问主机，终端仅由屏幕、键盘以及和主机通信的设施组成，通常是“哑”的，本身没有或仅有一点处理能力。使用智能终端，构成所谓的主从方式，也只不过完成一

些屏幕显示和用户输入管理方面的简单任务。 还有一种情况，把大型机／小型机系统作为

大型数据库平台，把 ＰＣ 系统通过软硬件技术实现与主机系统的通信，这种混用方法可能

胜过单纯的哑终端主机方式。当然，一台独立的 ＰＣ 机，也可视作主机系统，一种单用户主

机系统。

图 ８．９　主机处理环境

主机处理系统的主要优点是集中式、安全性和海量数据存储设备的管理能力。 此外，主机系统支持大量的并发用户。一台 ＩＢＭ 大型机（如 ＩＢＭ ＥＳ／９０００）上的数据库能同时支

持超过 １ ０００个用户的访问。主要缺点是系统的采购和维护费用过大，大型系统需要特殊

的支持设施，如对计算中心机房的要求苛刻，专业人员的培训也需要付出代价。 近几年，企业对部门级小型机的需求日益旺盛，它们的成本和维护费用相对较低，适合中小型企业

或大型企业的部门信息处理，而且能与大型机联网。２．文件处理系统

客户机／服务器计算模式的另一种驱动力来自 ＰＣ 及 ＬＡＮ ，业界称之为“向上优化

（ｕｐｓ ｉｚｉｎｇ）”，意思是指将独立的 ＰＣ 机以部门或工作组为单位用网络连接起来，ＰＣ 机一

般情况下不再孤立工作。 初，ＰＣ 机是为了共享文件以及昂贵的外设如激光打印机、磁带机等而连接到 ＬＡＮ 上，构成文件处理系统。

在文件处理系统中，如图 ８．１０所示，所有应用处理包括数据处理都发生在 ＰＣ 工作

站一端，文件服务器仅负责从硬盘查询所需要的文件，并通过网络把它发送给用户的 ＰＣ机。数据处理通过 ＰＣ 上的 ＤＢＭ Ｓ 进行，处理完的结果以整个文件的形式再送回文件服务

·０５２· 分布式数据库系统及其应用

器，由服务器再把文件存储在硬盘上。

图 ８．１０　文件共享处理环境

文件处理系统的缺点是，用户所获得的计算能力局限于本地的 ＰＣ 工作站，而不管文

件服务器的速度有多快，安全性有多高，能力有多强。 尤其是当多用户同时访问一个共享

的数据文件时，同一个文件不得不发送到每个 ＰＣ 上，这不仅导致网络开销增加，并发控

制也相当困难。 因此，文件处理系统的性能往往存在问题，通常只能满足小规模的工作组

应用需求。文件处理系统的另一个问题是，ＰＣ 上的 ＤＢＭ Ｓ 大多数实际上是一个文件管理系统，

如 Ｘｂａｓｅ 系列，Ｆｏｘ 系列均是 ＤＯＳ 环境下的文本（．ＴＸＴ ）文件， ＩＮ ＦＯＲＭ ＩＸ－ ＳＥ 是

Ｕ ＮＩＸ／ＸＥＮ ＩＸ 环境下的 Ｃ－ ＩＳＡＭ 文件。 因此，在数据完整性、系统安全性等方面不可要

求过高。３．客户机／服务器处理系统

业界把 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 模式称为“恰到好处的规模（ｒ ｉｇ ｈｔ ｓｉｚｉｎｇ）”，意指 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 将应用资源在 ｃｌｉｅｎｔ 和 ｓｅｒｖｅｒ 之间进行恰到好处地分配。 ｃｌｉｅｎｔ 通过网络请求服务，ｓｅｒｖ ｅｒ提供服务。 在这个开放环境里，一个 ｃｌｉｅｎｔ 可以是一台 ＰＣ 机或图形工作站；一个 ｓｅｒｖ ｅｒ可以是一台高档 ＰＣ 工作站，也可以是一个主机系统，不同厂商提供的服务器可以很好

共处。ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 模式 典型的应用是数据库技术，如图 ８．１１所示。 在一个基于 ｃｌｉｅｎ ｔ／

ｓｅｒｖ ｅｒ 的数据库系统中，应用被分成两个部分，数据库应用程序运行在 ＰＣ 机上（称作前

端系统），负责用户界面和 Ｉ／Ｏ 处理；ＤＢＭ Ｓ 部分（负责数据处理和硬盘存取）运行在

ｓｅｒｖ ｅｒ 上（称作后端系统）。ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 系统通过将应用资源在前端和后端系统间的分离，降低了网络上的开

销。 因为在 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 系统中，网络上传送的一般是请求（如 ＳＱＬ 语句）和结果（如记

录），而不是整个文件。集中式 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 技术已广泛使用，几个流行的数据库厂商，如 Ｓｙｂａｓｅ，Ｏｒａｃｌｅ 以

及 Ｉｎｆｏｒｍ ｉｘ 等均提供解决方案，它们适合于中小型企业以及大型企业的部门级应用。

·１５２·第八章　分布式数据库与客户机／服务器模式

图 ８．１１　客户机／服务器处理环境

４．多服务器处理系统

ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 本身就是一种分布式处理技术，这里的“多服务器处理系统”为了和前

述 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 处理系统相区别，专指存在两个或两个以上 ｓｅｒｖｅｒ 的 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 系统，如图 ８．１２所示，这种系统伸缩性更强，实现及管理也更复杂。

图 ８．１２　多服务器处理环境

集中式 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 系统在一个 ＷＡＮ 环境下显然存在问题：一个部门的用户可能

需要共享地理上遥远的其他部门或总部主机上的部分信息，而且希望“信息随手可得”，将数据在不同的主机或地点进行分布不可避免，这就导致多服务器 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 系统的

出现。在多服务器系统中，用户从本地 ｓｅｒｖｅｒ 请求数据；如果本地 ｓｅｒｖｅｒ 发现本地没有需

要的数据，就通过 ＬＡ Ｎ 或 ＷＡＮ 向其他 ｓｅｒｖｅｒ 发出请求，通过“ｓｅｒｖｅｒ 对 ｓｅｒｖ ｅｒ 的对话”处理数据， 后将数据返回给用户。整个过程中，除了响应有一点延迟感觉，用户并不知道

·２５２· 分布式数据库系统及其应用

数据来自其他系统，全部 ｓｅｒｖｅｒ 对 ｓｅｒｖ ｅｒ 间的数据处理细节对 ｃｌｉｅｎｔ 系统透明。多服务器系统的设计和实现还是一个新领域，市场上的很多产品还不完善，可互操作

性也差。多服务器处理系统被定位于企业级的大型应用平台。５．对等处理系统

对等系统被认为 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 系统的 终归宿，是分布式处理的极限。 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ系统的两个不同的部分，即请求服务的 ｃｌｉｅｎｔ 和处理请求的 ｓｅｒｖ ｅｒ ，发展到对等服务阶

段，将脱离主从结构，实现完全等同，如图 ８．１３ 所示，即在网络上每个站点既是 ｃｌｉｅｎｔ 又是 ｓｅｒｖ ｅｒ 。 在对等系统中每个站点都是平等的，进一步说，每个站点的计算机都要负责对

自己资源的管理和访问，并有对任何其他站点计算机上的资源的同等访问权。

图 ８．１３　对等处理环境

８．２．２　客户机／服务器模式的定位

从上述对计算环境演变的分析和客户机／服务器模式各类处理系统的讨论可见，采用

客户机／服务器模式的系统是介于集中式与分布式数据库系统之间。 集中式 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ处理环境中，数据是集中的而处理是分布的，一个应用是通过客户机请求和服务器响应的

协作方式来完成的；多服务器 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 处理环境中，处理和数据都是分布的，一个应

用可以涉及多个服务器上的数据，一个服务器上的数据也可以被多个客户机访问，但是完

成一个应用同样必须通过客户机请求和服务器响应的协作方式来完成；对等 ｃｌｉｅｎ ｔ／ｓｅｒｖ ｅｒ 处理环境中，处理和数据都是分布的，由于实现完全等同，所以每个站点不但可以

访问其他站点上的数据，完成全局应用，而且还可以访问本站点上数据，以完成本地应用。考虑 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 处理环境中若包括多个数据库服务器的情形，将引出许多与分布

式数据库系统相同的问题。首先面临的问题是站点自治性和透明性，不同的站点间应相互

独立，用户或应用可以不知道甚至不必关心数据在物理上存储于何处，不管数据是在本地

·３５２·第八章　分布式数据库与客户机／服务器模式

还是在远程。 其次是数据完整性问题，目前的实现技术是两阶段提交协议，还有强制实施

跨站点的业务规则等问题。 这也是为什么我们把客户机／服务器模式也放在本教程中的

原因。如果每个站点是一个单数据库服务器的 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 结构，服务器之间通过网络连

接，每台数据库服务器有自己的若干客户机。用户可以通过客户机对本地数据库服务器执

行某些应用（局部应用），也可以提高客户机对多个站点上的数据库服务器执行某些应用

（全局应用），这样的系统也是分布式数据库系统，如图 ８．１４所示。 目前，许多分布式数据

库系统采用这样的结构，当前流行的几种 ＲＤＢＭ Ｓ 支持这样结构的分布式数据库系统。

图 ８．１４　每个站点是一个单数据库服务器的 Ｃ／Ｓ 结构的 ＤＤＢＳ

８．３　客户机／服务器模式的特性和优缺点

８．３．１　客户机／服务器模式的特性

　　采用客户机／服务器模式结构的系统大都具有如下特性。（１） 按功能划分

ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 首先是在两个不同机器上运行的进程间的一种关系。 ｓｅｒｖ ｅｒ 进程是服

务的提供者，ｃｌｉｅｎ ｔ 进程是服务的消费者。实质上，ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 根据服务的观点对功能进

行了明确划分。（２） 共享资源

一个 ｓｅｒｖｅｒ 可以在同一时刻对许多 ｃｌｉｅｎｔ 进行服务，并且协调它们对于共享资源的

访问。

·４５２· 分布式数据库系统及其应用

（３） 不对称协议

在 ｃｌｉｅｎｔ 与 ｓｅｒｖ ｅｒ 之间存在一种多对一的主从关系。一般来说，客户通过请求与服务

器主动对话，而服务器则是被动地等待客户请求。（４） 定位透明性

ｓｅｒｖ ｅｒ 是一个进程，它可以与 ｃｌｉｅｎｔ 位于同一台机器上，也可以位于网络上的另一台

机器上。 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 软件通常都要在 ｃｌｉｅｎｔ 方屏蔽掉服务器的地址信息，这是通过重新

定向服务调用来实现的。 一个应用程序可以是 ｃｌｉｅｎｔ 或 ｓｅｒｖｅｒ 或两者兼之。（５） 混合与匹配

理想的 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 软件应该独立于硬件或操作系统软件平台，应该能够混合与匹

配 ｃｌｉｅｎｔ 和 ｓｅｒｖｅｒ 平台。（６） 基于消息的交换

ｃｌｉｅｎｔ 和 ｓｅｒｖｅｒ 是一对耦合的系统，它们通过消息传递机制互相协作。 消息是服务请

求与响应的媒介。（７） 服务封装

一个消息告诉 ｓｅｒｖ ｅｒ 所请求的服务，由 ｓｅｒｖ ｅｒ 来决定如何完成这项作业。 只要发布

的消息接口没有变化，ｓｅｒｖｅｒ 的版本升级对 ｃｌｉｅｎｔ 没有任何影响。（８） 可扩展性

ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 系统可以水平地或垂直地扩展。 水平扩展是指添加或移去客户工作站

对性能影响很小。 垂直扩展是指移植到更大的或者更快的 ｓｅｒｖ ｅｒ 机器或多 ｓｅｒｖｅｒ。（９） 完整性

对集中式 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 处理环境，ｓｅｒｖ ｅｒ 代码和 ｓｅｒｖ ｅｒ 数据是集中维护的，它带来了

较低的维护开销，并保持了数据的完整性和独立性。这里所描述的 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 特性也是与其他模式结构软件的区别，这些特性还为设

计基于网络且松散组合的应用程序提供了一种框架。８．３．２　客户机／服务器模式的优点与不足

１．客户机／服务器模式的优点

　　实现对等服务是 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 模式的理想，但目前市场上还没有产品声称支持全功

能的对等服务，还有一大堆技术问题需要解决。 虽然如此，ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 计算模式在构造

多服务器应用系统时成为很好的方式，可以为今天的企业解决方案带来很好的效益。１） ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 模式提高了投资效率，用户不但能够从自己桌面上的 ＰＣ，访问和操

纵大型计算机上数据库中的数据。同时，使用 ＰＣ 和工作站可以提供过去大型机才具有的

计算能力，而且只有大型机价格的几分之一。２） ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 模式使得处理和被处理的数据更加接近。所以，网络开销和响应时间

极大降低，从而减少对网络带宽和成本的需求。３） ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 模式改变了由“哑”终端提供的单调的单色屏幕用户界面，而代之以

支持具艺术性的图形用户界面的 ＰＣ。 ＧＵ Ｉ 具有丰富的可视化界面表示技术，易学易用，而且具有很好的一致性。用户在培训和教育方面的投资得以充分利用， 终用户对新产品

·５５２·第八章　分布式数据库与客户机／服务器模式

的抵触情绪可得到缓解。４） ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 模式支持和倡导标准化和开放系统。 ｃｌｉｅｎｔ 和 ｓｅｒｖ ｅｒ 都可以在不同

的硬件和软件平台上运行，使用户从专有的体系结构中解放出来。 价格低廉，易于组合的

体系结构，解决了可根据应用需要而进行系统伸缩的问题。５） ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 模式能使多个用户共享硬件资源，如打印机、扫描仪、传真机等。显而

易见，共享贵重的硬件比为每个用户购买相同硬件设备省钱。２．客户机／服务器模式的不足

当然，ｃｌｉｅｎ ｔ／ｓｅｒｖ ｅｒ 计算模式并不是十全十美的，其不足之处在于：１） 在集中式 ｃｌｉｅｎ ｔ／ｓｅｒｖ ｅｒ 环境下（传统的方式），如果应用逻辑的主要部分移到

ｓｅｒｖ ｅｒ 上，ｓｅｒｖ ｅｒ 就会像传统主从结构的主机一样成为瓶颈，随着用户数的增加，资源有

限的 ｓｅｒｖ ｅｒ 可能不堪负荷。２） 多服务器应用系统的设计和实现，比集中式系统复杂得多。无论应用开发，运行环

境维护，还是管理这些多服务器环境的工具，都是如此。还有一些对 ｃｌｉｅｎｔ／ｓｅｒｖ ｅｒ 模式的认识也有待纠正。例如，有人认为 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 模式

要求非专业的用户成为专业的软件开发者，另外一些人认为 ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 终将把大型

和小型机赶出历史舞台等，都言过其实。总之，ｃｌｉｅｎｔ／ｓｅｒｖｅｒ 模式有助于减少软件的维护费用，提高软件的可移植性和可伸缩

性，提高网络性能，甚至有助于提高软件开发人员的生产力和缩短开发周期。但是，ｃｌｉｅｎ ｔ／ｓｅｒｖ ｅｒ 模式仍然存在某些问题和缺陷，需要进一步研究和解决。

８．４　客户机／服务器模式的远景展望

技术的进步正迅速影响着客户机／服务器计算模式。 根据几年前可用的技术，很难预

示当前客户机／服务器计算处于何种状态，同样也难以预测今后几年技术发展的趋势。 在

确定客户机或服务器或两者的功能时，起主要作用的因素有：硬件和软件的发展，网络协

议，ＬＡＮ／ＷＡＮ 技术和通信管道。降低这些因素的代价会使得“每一美元的投资得到更多

的计算能力”继续成为可能。 这些激励因素激励着有关公司不断升级它们的计算环境。当 前，在业界 中 传统的 客户机／服务器模 式结构被称 作两层结 构 （ｔ ｗ ｏｔ ｉｅｒ

ａｒｃｈｉｔｅｃｔ ｕｒｅ），我们描述的 ＤＤＢＭ Ｓ 方式符合这种结构。 服务器（或服务器群）存储数据，客户机群存取数据，这种体系结构中，服务器扮演着支配的角色。 这种两层结构系统的优

点在于它的简单性，以及与现存传统系统的无缝兼容。 但在这种结构中，所有的表示逻辑

和应用逻辑等重头戏均在客户机上完成，所有客户机都必须安装应用软件和工具，因而使

得客户机变得很“肥”，俗称“肥客户机”。 而服务器仅负责响应用户请求，全局数据的访问

和管理，因而使得服务器相对较“瘦”，俗称“瘦服务器”，这使得应用系统的性能较差。“瘦”且具有强大计算功能的计算机的出现，改变了客户机和服务器的角色，因此，两层结

构系统渐渐移向三层或多层结构系统。目前，正在涌现的客户机／服务器模式结构是三层结构（ｔｈ ｒｅｅｔｉｅｒ ａｒｃｈ ｉｔｅｃｔｕ ｒｅ）。在这

·６５２· 分布式数据库系统及其应用

种模式中，主机、服务器和客户机表示了逻辑上相互独立的三个“层”，即数据层、功能层和

表示层。 数据层就是 ＤＢＭ Ｓ，驻留在主机上，负责数据库数据的管理和存取操作。 功能层

由服务器实现，它是应用逻辑处理的核心，实现具体的业务，所以也称应用服务器。它扮演

着媒介物的角色，存储着商业规则（过程或约束），这些商业规则用于从主机存取数据。 表

示层由客户机实现，客户机是应用的用户接口，包含 ＧＵ Ｉ 接口和一些附加的具体应用商

业规则。因此，服务器的作用如同管道，从主机到客户机传递（部分地）已处理的数据，客户

机对数据进行进一步的处理／筛选，并以 ＧＵ Ｉ 格式呈现给用户。所以，用户接口、规划和数

据存取也是三层。 客户机通常通过 ＬＡＮ 与服务器相连，服务器通过 ＷＡＮ 与主机相连，远程客户机也可以通过ＷＡＮ 与服务器相连。这种系统很适合大型公司，那里的集中式数

据库被存储在公司的主机上，采用 新的技术可以管理和优化为该组织机构中的每一个

部门构建 ＬＡＮ 和 ＷＡＮ 的费用。在定义作为客户机的机器时，操作系统的发展扮演着重要的角色。 例如，几年前，

Ｗ ｉｎｄｏｗ ｓ３ｘ 为 桌面 计 算 机引 入 了 一 种新 的 计 算方 法，接 下 来 是 Ｗ ｉｎｄｏｗ ｓ９５ 和

Ｗ ｉｎｄｏｗ ｓ９８。 虽然 Ｗｉｎｄｏｗ ｓＮ Ｔ 是为服务器设计的，但在网络商业环境中，高端的客户机

采用 Ｗｉｎｄｏｗ ｓＮ Ｔ 的越来越多。 Ｗ ｉｎｄｏｗ ｓＮＴ 包括网络管理和容错的特性，因此提高了系

统的稳定性。这些，再结合硬件计算能力的改进，使得今天的桌面 ＰＣ 成为强大的客户机。ＧＵ Ｉ 已成为客户机事实上的接口。 现在，智能接口是业界的标准，它利用技术和工具

的优势，使用户能更好更快地完成他们的工作。 Ｗｅｂ 门户工具就是一个例子，它允许经理

们把他们所关注的信息的视图定义成 Ｗｅｂ 门户，他们可以从这里登录，执行基于 ＤＤＢＳ的细节操作。 此外，计算机内存和磁盘存储空间成本的减少，增进了用户拥有的计算能力

和快速处理能力，从而改变了客户机的角色。 这些将使用户有能力规划数据请求，局部地

存储和分析查询结果，显示、报告信息。多媒体在应用开发中也扮演着主要的角色。使用视频、图形、音频作为数据，要求更大

量的存储空间，更高带宽的数据传输。 通信技术的进步和光纤网络的发展，为服务器上的

带宽瓶颈提供了解决方案，城域网（ｍｅｔｒｏｐｏｌｉｔａｎ ａｒｅａ ｎｅｔ ｗ ｏｒｋｓ，Ｍ ＡＮ ）和异步传输模式

（ａｓｙｎｃｈｒｏｎｏｕｓ ｔ ｒａｎｓｆｅｒ ｍｏｄｅ，ＡＴ Ｍ ）就是两个例子。存储量的增加和处理速度的加快，也使得关键的多媒体数据能够局部地存储在客户机上，从而通过降低查找频率的方式来减

少网络上的通信量。图 ８．１５是用于 Ｉｎｔｅｒｎｅｔ 环境的数据库应用系统的三层结构，在这里，主机是数据库

服务器，服务器是 Ｗｅｂ 服务器，客户机是浏览器。 每一层可以运行在不同的操作系统上，例如，数据库服务器运行在 ＵＮ ＩＸ 上，Ｗｅｂ 服务器运行在 Ｗ ｉｎｄｏｗ ｓ ２０００或 Ｗ ｉｎｄｏｗ ｓ Ｎ Ｔ上，浏览器则可分别运行在 Ｗｉｎｄｏｗ ｓ ９８， ＵＮ ＩＸ， Ｍ ａｃｉｎｔｏ ｓｈ， Ｗｉｎｄｏｗ ｓ ２０００ 上。同样，数据库服务器可以运行从 Ａ ｃｃｅｓｓ 到 ＩＢＭ ＤＢ２的各种数据库管理系统，常用的 Ｗｅｂ 服务器

有微软的 Ｉｎ ｔｅｒｎｅｔ 信息服务器 ＩＩＳ，Ｎ ｅｔｓｃａｐｅ服务器和 Ａ ｐａｃｈｅ，常用的浏览器有 ＮｅｔｓｃａｐｅＮ ａｖｉｇ ａｔ ｏｒ 和微软的 Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏ ｒｅｒ。

对于日益发展的某些应用，三层客户机／服务器模式结构在 Ｗｅｂ 服务器上负担会过

重。 因为，这些 Ｗｅｂ 服务器不仅要作为 ＨＴ Ｔ Ｐ 服务器响应可能是成千上万的请求，而且

需要建立和管理与数据库服务器的连接，产生和传送 ＳＱＬ 请求，收集 ＳＱＬ 结果，执行业

·７５２·第八章　分布式数据库与客户机／服务器模式

图 ８．１５　三层客户机／服务器模式结构及各层的功能

务逻辑并维护业务规则，还要格式化响应返回给客户端。 这样，Ｗｅｂ 服务器很可能成为系

统性能的瓶颈。 解决这个问题的一种方法是把 Ｗｅｂ 服务器只用于处理 ＨＴ Ｔ Ｐ 请求和响

应，而把其他工作交给其他服务器去做，如图 ８．１６所示那样。显然，还有更多的方法，随着

应用的发展，会积累更多的经验，可能出现其他的多层客户机／服务器模式结构。

图 ８．１６　多层客户机／服务器模式结构

随着新技术的出现，服务器不断地变得更加强大。现在，服务器可以是一部台式机，然而它有能力做甚至超过几年前中型机所做的工作，例如并行处理、多任务和多线程的特性

·８５２· 分布式数据库系统及其应用

使得服务器变得更快和更有效。 另外，处理器和磁盘存储成本的下降，使得服务器具有双

处理器和冗余磁盘变得更容易，这也使得服务器更加可靠和健壮。加密和解密技术的进步，使得从服务器到客户机传输加密的敏感数据更加的安全，数

据将在客户机端被解密，这可以通过硬件或改进的软件来做。这一技术提高了数据的安全

性层次，但网络安全性问题仍然是主要的焦点。 多种数据压缩技术有助于大量数据的传

送，这些数据通过有线和无线的网络从服务器传到客户机。未来有着高带宽网络的客户机／服务器系统的应用将包括视频会议、远程医疗以及远

程学习。 我们将在以后各章中讨论一些新出现的技术和数据库应用，在那些应用中基于

ＤＤＢＳ 的客户机／服务器将是一个集成部件。

８．５　分布式数据与分布式访问

在一个分布式数据库系统中，无论是传统意义上的分布式系统，还是基于多客户机／服务器模式的协作式分布式数据库系统，其数据总是物理地分布于不同的站点。数据的分

布势必使数据管理逻辑也必须随数据一起分布，形成数据的分布式访问。８．５．１　从集中式到分布式数据的转移

以往，大多数用户在大型中央主机上开发和运行应用程序，这些程序以及它们所访问

的数据都存储在主机上的共享设备中。随着应用的发展，使用这种大型中央主机作集中式

应用处理的成本越来越高，尤其与 ＰＣ 机的高性能价格比相比。 今天，用户的兴趣已经转

移到分布式数据和分布式访问上，主要原因在于：１） 希望通过降低操作成本和分散操作过程，提高竞争能力和对客户应用的响应

能力；２） 客户机／服务器计算模式的迅速发展；３） 网络及分布式数据库技术和产品的成熟，尤其是 ＤＤＢＭ Ｓ 的新进展。分布式数据库管理系统的主要优点是数据物理分布在网络的多个站点中，且这种分

布对 终用户具有位置透明性。同时，分布式数据库管理系统保证大部分数据位于实际使

用数据的本地。 一个理想的分布式数据库应允许每个站点都配置管理驻留于该站点的大

量数据、复杂的用户应用程序以及处理多个用户的能力。 随着应用程序和用户数的增加，相应的数据需求也增长。 而升级一个分布式环境看来要比升级一个相应的集中式系统容

易且便宜，而且在实现上可以对 终用户透明。 显然，在多个站点上分布数据还带来以下

好处：１） 通过将关键数据的多个拷贝置于不同的站点，提高数据的可用性，避免“单点失

败”现象，提高系统的可靠性和可用性；２） 增加并行度，高效的只读数据访问，改进数据管理性能；３） 很容易增加应用程序、用户数目和扩大规模；４） 把数据存放在 接近产生数据或使用数据 频繁的站点，以减少传输，提高效率。

·９５２·第八章　分布式数据库与客户机／服务器模式

８．５．２　数据分布的基本形式

分布式数据存在着六种不同的基本形式：１） 复制数据（ｒｅｐｌｉｃａｔ ｅｄ ｄａｔａ）；２） 子集数据（ｓｕｂｓｅｔ ｄａｔａ）；３） 重新组织的数据（ｒｅｏｒｇ ａｎｉｚｅｄ ｄａｔ ａ）；４） 分区数据（ｐａｒｔｉｔ ｉｏｎｅｄ ｄａｔ ａ）；５） 独立模式数据（ｓｅｐａｒａｔｅ－ ｓｃｈｅｍａ ｄａｔ ａ）；６） 不相容数据（ｉｎｃｏｍｐａｔｉｂｌｅ ｄａｔａ）。１．复制数据

复制数据是指相同数据在不同的站点存储的几个相同的副本，如图 ８．１７ 所示。 这样

做的主要原因是通过重复的存储的数据，避免了系统之间的数据传输，减少查询数据的代

价，并且还可以提高并行度，提高系统的可靠性和可用性。 只有当查询数据的频率大大高

于更新数据的频率时，这样组织才有意义。大量复制的数据一般是不变数据或很少变化的

数据，因为更新数据会增加开销。

图 ８．１７　复制的数据

由于小容量的存储设备的价格要比远程通信的价格下降快得多，因此，采用复制数据

的方法越来越有经济上的吸引力。２．子集数据

存储在地区计算机中的数据常常是存储在一个大型中央计算机中数据的子集。 这样

做有两个基本的原因，其一是这些数据是在那个地区建立的，其二是各地区频繁地使用本

地数据。 子集数据是复制数据的一种形式，区分它是因为它通常是整体数据的一部分，如图 ８．１８所示。

·０６２· 分布式数据库系统及其应用

图 ８．１８　子集数据

一般情况下，对以层次方式组织的机构来说，数据的全集（该机构的整体数据）是保存

在较高层机器中。 当在较低层机器改变数据时，这种改变必须向上传送到较高层机器中，有时是立即传送，有时是等到下一个更新周期再传送。

较低层的机器中可以存放一些较高层机器中的数据，也可以存放一些从来不向较高

层机器传送的它们自己的数据。 例如，较低层机器就保存有关顾客的地址和一般信息，这些庞大的数据是较高层系统所不需要的，然而，较高层系统可以存储顾客的编码、姓名、有关顾客信用等方面的信息和订贷的细节。较低层机器也存储这些数据，但对它们的任何修

改都必须向上传送到较高层机器中，以保证数据库的一致性和完整性。３．重新组织的数据

一个信息系统或是一个决策支持系统通常包含一些如日常业务处理系统中的相同数

据，对这些数据可以使用倒排表、辅助索引，或用多层次关键字进行信息检索的结构形式

组织起来的。也就是说，这些数据是由另外一些数据生成或导出的，称为重新组织的数据，如图 ８．１９所示。

在某些系统中的数据，都可以从其他机器（甚至是同一机器）的数据库（或文件）中选

取，对数据可以进行摘录、编辑等。为了能够令人满意地做好这件工作，必须注意两者的数

据库模式必须相同，即应有相同的数据域表示形式，它们应是从同一数据模型和字典表示

中导出的。４．分区数据

分区数据也称分片数据，是指同一模式在两个或多个站点的机器中使用，每台机器存

储不同的记录，但是它们的构造形式是完全相同的（水平分片）。数据的分区形式是一种普通而又有价值的形式。 系统在地区 Ａ 保持 Ａ 的数据，在地

区 Ｂ 保持 Ｂ 的数据，如此等等，如图 ８．２０所示。 在一个组织机构中，每一个分支机构，每

·１６２·第八章　分布式数据库与客户机／服务器模式

一个零售店，每一个仓库或是其他业务场所，都可以有独立的计算机，它们都使用相同的

程序，大多数交易在这里产生并被处理，这些交易所用的数据也在这里处理。 这些交易也

许需要少量别处的数据，这些数据不是传送到数据存储区就是传送给它们。

图 ８．１９　重新组织的数据

图 ８．２０　分区数据

５．独立模式数据

使用独立模式数据，不同的计算机含有不同模式的数据和不同的程序，并且它们是由

不同的业务小组安装的。例如，一个系统可以处理生产数据，另一个系统处理营销数据，再另一个系统处理财务数据等，如图 ８．２１ 所示。

虽然它们的模式不同，但是这些独立的数据系统应该是一个公共的、自顶向下规划

的一部分，否则，就会产生有害的冗余和数据不一致。 一个站点的计算机常常需要发送一

些事务到另一个站点的计算机，或者向另一台计算机请求数据。例如在一个工厂范围内的

生产系统，提出购物的申请，并把这些申请传送给采购系统，而采购系统和生产系统所产

·２６２· 分布式数据库系统及其应用

图 ８．２１　独立模式数据

生的数据必须送到财务系统。６．不相容数据

不相容数据是指由不同机构建立的独立的计算机系统或设计时未经协调的部门之间

的数据，如图 ８．２２ 所示。

图 ８．２２　不相容数据

有时，在这些独立系统中，数据没有统一设计和统一规划。 一个用户需要通过计算机

网络去访问多个独立开发的系统时，他们必须熟悉每一台计算机所存储的数据和如何访

问以及如何使用这些数据。因为这些系统是由不同的机构为了不同的目的而建立的，像这

样的许多系统通过分组交换网是可访问的，例如 ＡＲＰＡＮＥＴ 和 ＣＨＩＮ ＡＮ ＥＴ 。 这些系统

的确可在一个公司内存在而且是不相容的，虽然它们没有自顶向下的规划。

·３６２·第八章　分布式数据库与客户机／服务器模式

８．５．３　数据分布的技术

常用的有 ５ 种数据分布技术：人工抽取（ｍａｎｕａｌ ｅｘ ｔｒａｃｔ ）、 快照（ｓｎａｐｓｈｏ ｔ ）、 复制（ｒｅｐｌｉｃａｔ ｉｏｎ）、 分片（ｆｒａｇｍｅｎｔ

ａｔ ｉｏｎ）和数据分布分析（ｄａｔ ａ ｄｉｓ ｔｒ ｉｂｕｔ ｉｏｎ ａｎａｌｙｓ ｉｓ）。１．人工抽取

在集中式、非分布的环境下，所有数据都集中于一个中央站点（例如，大型机上的共享

数据库）。在分布式环境下，数据分布于多个站点。但是，被分布的数据逻辑上仍属于一个

集中的共享数据源，那么如何及何时把数据从逻辑的中央站点数据源中“取出”，又如何选

择合适站点进行数据分布，这是分布式数据库系统设计者要考虑的问题。分布数据 简单的一种方法就是让用户或操作人员手工地将数据从中央站点拷贝到

其他站点，这种数据分布方法叫做人工抽取。 例如，仍考虑一个银行应用程序，如图 ８．２３所示。

图 ８．２３　分布式数据的银行应用系统

２．快照

为使人工抽取的用户操作自动化，数据分布的任务应由 ＤＤＢＭ Ｓ 自己来完成。随着数

据分布需求复杂性的增加，ＤＤＢＭ Ｓ 的智能化程度和复杂性也相应增加。在 ＤＤＢＭ Ｓ 所执

行的任务中，自动快照是 简单的任务之一。快照的定义、用途及优缺点在前面的分布式数据更新和并发控制中已经给出。 例如：　 ＣＲＥＡＴ Ｅ ＳＮ ＡＰＳＨＯＴ ＜ｎａｍｅ＞ ＡＳ ＳＥＬＥＣＴ …… Ｔ ＩＭ Ｅ ＜ｈｈ∶ｍｍ∶ｓｓ＞，　　　　　　　 ＩＮＴ ＥＲＶＡ Ｌ ＜ｈｈ∶ｍｍ∶ｓｓ＞

·４６２· 分布式数据库系统及其应用

在自动快照过程中，用户可以定义对哪个（些）表、哪些字段建立快照，规定自动快照

的刷新时间和频率（如在晚间，或每隔 ４个小时刷新一次）。由 ＤＤＢＭ Ｓ 负责自动完成所需

要做的工作。自动快照功能被设计用于分布相对静止的信息（不经常改变）。例如，汇率表

就是使用自动快照的例子，因为汇率每天 多改变一次。 一般，自动快照通常限于只读

访问。３．复制

数据复制实际上是对同一数据复制多个副本，根据需要将各副本存放在不同站点中，以提高查询处理的本地性。对于那些需要对分布的数据进行多点更新问题，ＤＤＢＭ Ｓ 系统

通过支持以下特点来完成所谓的复制功能。１） 在多点创建和维护数据的副本（复制）；２） 在多个副本间保持数据的一致性（同步或异步）。４．分片

数据复制所处理的对象是往往是整个表，而数据分片的处理对象是表的部分数据。可以说复制是分片的一种特殊情况，数据分片是一种更加复杂的数据分布技术。

分片技术用于关系数据模型 为容易解释，其数据表允许被水平或垂直地进行分片。如何进行数据分片，在分布式数据库设计中已经阐述，这里不再重复。

５．数据分布分析

数据分布分析是一种数据统计方法。 设计者根据应用需求决定哪些资源需要进行分

布，以及这些资源应该存储在哪些地点。分布式数据地点分析的一种简便易行的方法即模

拟一个分布环境的交互作用，以下的例子可以说明这种模拟。假设一个银行应用系统的分

布环境由两个站点构成：中央银行（ＣＢ）和分行（ＰＢ）。 进一步假设客户表整个存放于中央

站点，而在 ＰＢ 站点存有部分数据复制（如水平分片）。 为维护客户信息的一致性，对任何

一个站点的客户表的修改都得复制到另一个站点上，而只读操作可以本地执行。假设 ＣＢ 站点的客户表有 １００００条记录，每天读取 ２ ０００次和更新 ５００次。ＰＢ 站点的

客户表有 １０００条记录，每天读取 １０００次和更新 １００次。如果所有客户数据都存储于其中一个站点，那么另一个站点对数据的访问就必须通

过连接这两个站点的网络来进行。 如果所有客户数据在 ＣＢ，那么来自／到达 ＰＢ 的网络开

销是 １１００条消息（１０００个读取加 １００个更新）。 相反，如果所有客户数据在 ＰＢ，那么网络

开销达 ２５００条消息（２０００个读取加 ５００个更新）。 由此分析看来，客户数据似乎应该驻留

于中央站点 ＣＢ。 但是，很容易证明，在这两个站点进行数据分布将使网络开销更低，这从

图 ８．２４的分析就可看出。 注意，网络开销来源于对非本地数据的读取和保持数据所有副

本的同步更新。在三种配置（所有数据在 ＣＢ，所有数据在 ＰＢ，数据分布于 ＣＢ 和 ＰＢ）中，从网络开销

来看第三种配置是 优化的（网络开销相当于 ６００ 条消息，来自 ＣＢ 的 ５００个更新加上来

自 ＰＢ 的 １００ 个更新）。

·５６２·第八章　分布式数据库与客户机／服务器模式

从上面的分析方法可以得出以下结论：１） 分布式数据的位置取决于逻辑数据和处理（读取和更新）模式、数量以及其他一些

特征。２） 数据分布是降低整个分布式系统开销的有效措施。

操作站点

ＣＢ ＰＢＲＥＡ Ｄ ２０００ １０００Ｕ ＰＤＡ Ｔ Ｅ ５００ １００

　配制方式

数据分布站点

ＣＢ ＰＢ网络开销

１ Ｙ Ｎ １１００２ Ｎ Ｙ ２５００３ Ｙ Ｙ ６００

图 ８．２４　分布式数据位置矩阵

８．５．４　分布式数据的访问

当数据被分布于几个站点时，所有或部分数据管理逻辑也必须随数据一起分布，至少

局部数据库处理逻辑（ＤＢＭ Ｓ）应该与数据库本身驻留于同一系统。不管采用何种数据分布方法，分布式 ＤＢＭ Ｓ 提供的数据访问都应对 终用户和应用

程序透明。 在一个真正的分布式环境中， 终用户和应用程序并不关心数据是如何分

布的。分布式数据的访问主要有： 远程请求、 远程事务、 分布式事务和分布式请求。１．远程请求

远程请求是只涉及单个远程服务器的单个请求。 例如：ＳＥＬＥＣＴ ＦＲＯＭ ＳＥＲＶＥＲ１．ＢＡＮＫＤＢ．ＣＵ ＳＴ ＯＭ ＥＲ　　　　 ＷＨＥＲＥ ＳＥＲＶＥＲ１．ＢＡＮＫＤＢ．ＣＵ ＳＴ ＯＭ ＥＲ．ＣＩＴ Ｙ ＝ ＂Ｂｅｉｊｉｎｇ＂考虑 简单的单客户机／单服务器环境，客户机应用程序 基本的任务就是访问服务

器的数据。这种由应用程序发出单个的数据请求，而在单一的远程站点完成处理的情况就

叫做远程数据请求。通常，这种单一请求就是一条单一的访问远程站点上数据的 ＳＱ Ｌ 语句。 仍以银行应

用程序为例。 如果客户表整个置于中央站点的 ＳＥＲＶ ＥＲ１，分行 ＰＢ（远程）就可以用一条

远程 ＳＱＬ 请求语句来读取客户信息。 分布式 ＤＤＢＭ Ｓ 支持透明地存取远程数据，用户应

用程序不用说明数据位置，如图 ８．２５ 所示。 远程数据请求可用于执行数据分布方法中的

手工抽取法。２．远程事务

远程事务处理允许在一个事务中包含多个数据访问请求，这些请求都引用同一个远

程服务器站点上的数据。通常，一个远程事务可包含多个 ＳＱＬ 语句，如图 ８．２６所示。远程

事务的用途与远程访问相似，通常用于手工抽取。例如：

·６６２· 分布式数据库系统及其应用

图 ８．２５　远程数据请求

图 ８．２６　远程事务处理

ＢＥＧＩＮ ＴＲＡＮＳＡ ＣＴ ＩＯＮ ＷＯＲＫ　　　 ＳＥＬＥＣＴ ＦＲＯＭ ＳＥＲＶＥＲ１．ＢＡＮＫＤＢ．ＣＵ ＳＴ ＯＭ ＥＲ　　　　 ＷＨＥＲＥ ＳＥＲＶＥＲ１．ＢＡＮＫＤＢ．ＣＵ ＳＴ ＯＭ ＥＲ．ＣＩＴ Ｙ ＝ ＂Ｂｅｉｊｉｎｇ＂　　 Ｕ ＰＤＡ Ｔ Ｅ ＳＥＲＶ ＥＲ１．ＢＡＮＫＤＢ．ＢＲＡＮ ＣＨ　　　　 ＳＥＴＰＯＳＴ ＥＤ－ ＩＮＤ ＝ ＂Ｙ ＥＳ＂ＣＯＭ Ｍ ＩＴ ＷＯＲＫ３．分布式事务

分布式事务处理允许一个事务包含多个数据请求，但每个数据请求只能访问单个服

务器站点，而不同的数据请求可访问不同的远程服务器站点，如图 ８．２７所示。例如：　　 ＢＥＧＩＮ ＴＲＡＮＳＡ ＣＴ ＩＯＮ ＷＯＲＫ

·７６２·第八章　分布式数据库与客户机／服务器模式

图 ８．２７　分布式事务处理

　　　 ＳＥＬＥＣＴ ＦＲＯＭ ＳＥＲＶＥＲＢ１．ＢＡＮＫＤＢ．ＥＭ ＰＬＯＹＥＥ　　　　　ＷＨＥＲＥ ＳＥＲＶＥＲＢ１．ＢＡＮＫＤＢ．ＥＭ ＰＬＯＹＥＥ．ＥＤＬＥＶ ＥＬ ＝ ＂Ｍ ＢＡ＂　 ＳＥＬＥＣＴ ＦＲＯＭ ＳＥＲＶＥＲＭ．ＢＡＮＫＤＢ．ＥＭ ＰＬ －Ｍ ＥＤ　　　　　ＷＨＥＲＥ ＳＥＲＶＥＲＭ．ＢＡＮＫＤＢ．ＥＭ ＰＬ －Ｍ ＥＤ．ＢＲＡＮ ＣＨ ＝ ＂ＰＢ＂ＣＯＭ Ｍ ＩＴ ＷＯＲＫ４．分布式请求

分布式请求是分布式数据访问中 复杂的方法。 分布式请求允许一个事务包含多个

数据请求，而且每一个请求都可引用驻留于多个服务器站点的数据，如图 ８．２８所示。

图 ８．２８　分布式数据请求

·８６２· 分布式数据库系统及其应用

例如：　　 ＢＥＧＩＮ ＴＲＡＮＳＡ ＣＴ ＩＯＮ ＷＯＲＫ　　　 ＳＥＬＥＣＴ ＦＲＯＭ ＳＥＲＶＥＲＢ１．ＢＡＮＫＤＢ．ＥＭ ＰＬＯＹＥＥ Ｂ１，　　　　　　　　 ＳＥＲＶ ＥＲＭ．ＢＡＮＫＤＢ．ＥＭ ＰＬ －Ｍ ＥＤ Ｍ　　　　 ＷＨＥＲＥ Ｂ１．ＥＭ ＰＬ － ＩＤ ＝ Ｍ．ＥＭ ＰＬ － ＩＤ Ａ ＮＤ　　　　　　 Ｂ１．ＥＤＬＥＶＥＬ ＝＂Ｍ ＢＡ＂　 Ｕ ＰＤＡ Ｔ Ｅ ＳＥＲＶ ＥＲ１．ＢＡＮＫＤＢ．ＢＲＡＮ ＣＨ　　　　　 ＳＥＴ ＲＥＰＯＲＴ ＥＤ ＝ ＂ＹＥＳ＂　　　　 ＷＨＥＲＥ ＳＥＲＶＥＲ１．ＢＡＮＫＤＢ．ＢＲＡＮ ＣＨ ＝ ＂Ｂ１＂ＣＯＭ Ｍ ＩＴ ＷＯＲＫ

８．６　创建基于客户机／服务器模式的数据库系统

基于客户机／服务器模式的数据库系统 适合处理以下环境：具有大量 ＰＣ、工作站、文件服务器、打印机、数据库服务器、Ｗｅｂ 服务器，以及其他通过网络连接在一起的设备，其思想是为专用服务器（ｓｐｅｃｉａｌｉｚｅｄ ｓｅｒｖ ｅｒ ）定义特定的功能。 例如，有可能把大量 ＰＣ 或

小型工作站作为客户机，并与文件服务器或数据库服务器相连，文件服务器上保存着这些

客户机的文件，数据库服务器上保存着这些客户机的数据。另一台机器可以被指定为打印

机服务器（ｐｒｉｎｔ ｅｒ ｓｅｒｖｅｒ），它与各种打印机相连，因此，客户的所有打印请求都提交到这

台机器上。 Ｗｅｂ 服务器或邮件服务器（Ｅｍａｉｌ ｓｅｒｖｅｒ）也属于专用服务器的范畴。这样，专用服务器提供的资源可以被多个客户机访问。 客户端机器为用户既提供了利用这些服务

器的适当接口，又提供了运行本地应用程序的本地处理能力。 这个概念也可以延续到软

件，那些专用软件，诸如 ＤＢＭ Ｓ 或 ＣＡＤ（计算机辅助设计）软件包，被存储在特定的服务

器上，并且对多个客户机来说是可访问的。８．６．１　创建客户机／服务器系统的自动化设计工具

在数据库技术诞生之初，大部分数据库设计工作由专门的设计人员手工进行，在设计

过程中，设计人员充分利用了个人经验和知识。但是，在数据库应用高度发展的今天，创建

客户机／服务器系统（也包括创建分布式系统或大型集中式系统）至少有如下两个因素表

明，若条件允许还是要尽量使用自动化设计工具。１） 随着应用所涉及的联系和约束的复杂程度越来越高，对相同信息进行建模的选择

方法，以及不同的设计策略数目也会相应增加。手工设计必然很难应对这样的复杂度及相

应的设计选择。２） 某些数据库涉及数百个实体类型和联系类型，这使得对设计进行手工管理几乎是

不可能的。 另外，和设计过程相关的元信息数据形成了另一个数据库，也必须对该数据库

进行相应的创建、维护和查询。创建开发客户机／服务器应用系统有一系列的辅助工具，这里将简要介绍主要的工具

以及它们是如何适用于开发客户机／服务器系统的。

·９６２·第八章　分布式数据库与客户机／服务器模式

１．ＣＡ ＳＥ 工具

ＣＡ ＳＥ 是“计算机辅助软件工程”的英文缩写，意指帮助完成创建计算机程序任务的

计算机程序。广义的定义可以包含用来创建程序源文件的文本编辑器，和用来将源程序翻

译成可执行程序的编译器之类的程序。 但术语 ＣＡＳＥ 更大程度上是用来指那些使程序开

发过程的各方面自动化的更复杂的程序。当 ＣＡ ＳＥ 工具 早被提出来时，人们希望它能够使整个程序开发过程彻底自动化，

这样，数百万的 ＣＯＢＯＬ 程序员就可以“解放”了。 但 ＣＡＳＥ 工具 多能够提高计算机程

序员的效率，使他们能比以前创建更大、更复杂的系统。ＣＡ ＳＥ 工具通常包含以下功能的组合：１） 图形表示（ｄｉａｇ ｒａｍｍ ｉｎｇ）：设计人员可用工具专用符号表示法画出数据库概念设

计的模式图（例如 ＥＲ 图）。 大部分符号表示法都包括实体类型、联系类型、基数约束、属性、码等，有些工具还能表示继承层次，并用附加的符号来表示部分和全部、不相交和覆盖

特性。 这些图形作为概念设计的内容被内部存储，并可修改或用于生成报表、交叉参照列

表及其他。２ ） 模型映射 （ｍｏｄｅｌ ｍａｐｐｉｎｇ ）：映射通常是和特定系统相关的，大部分工具为

Ｏ ｒａｃｌｅ，ＤＢ２，Ｉｎｆｏｒｍ ｉｘ ，Ｓｙｂａｓｅ 及其他 ＲＤＢＭ Ｓ 生成用 ＳＱ Ｌ ＤＤＬ 表示的模式。 工具的这

部分功能是 适合于自动化的。必要的话，设计人员还可以对得到的 ＤＤＬ 文件进行编辑。３） 设计规范化（ｄｅｓｉｇｎ ｎｏ ｒｍａｌｉｚａｔｉｏｎ）：这里用到了概念设计阶段或在逻辑设计过程

中获得关系模式以后所提供的一个函数依赖集。 使用分解算法把现有的关系分解为具有

更高范式的关系。一般，这些工具都缺乏生成 ３ＮＦ 或 ＢＣＮ Ｆ 可选的方法，以及缺乏允许让

设计人员基于他们的准则去选择例如 小关系数目或 少存储量这样的要求。大部分 ＣＡ ＳＥ 工具都支持某些形式的物理设计，包括索引的选择，还提供一整套工

具对系统性能进行监控和测量。 而大部分设计调整或数据库实现的问题仍然需要人工

解决。在此不对 ＣＡＳＥ 工具进行具体的阐述，只提一下好的 ＣＡ ＳＥ 工具应当支持的特性。１） 易于使用的界面（ａｎ ｅａｓｙｔ ｏｕｓｅ ｉｎｔ ｅｒｆ ａｃｅ）：这个特性非常重要，它使开发人员只

需集中于自己的任务，而不用在设计工具的了解方面花费过多的精力。图形化和点击式是

目前应用比较广泛的界面形式。 一些工具使用了自然语言输入，如法国的 ＳＥＣＳＥ 工具。还应根据不同的用户对界面进行定制，如初级开发人员和专家级开发人员的界面应该是

不同的。２） 分析组件（ａｎａｌｙ ｔｉｃａｌ ｃｏｍｐｏｎｅｎｔｓ）：自动化工具应当为难以手工执行的任务提供

分析组件，如评估物理设计的不同策略或检测视图之间的约束冲突。这是目前大部分工具

的薄弱环节。３） 启发式组件（ｈｅｕｒｉｓ ｔｉｃ ｃｏｍｐｏｎｅｎｔｓ）：对于设计中难以精确量化的部分，通过在设

计工具中输入启发式规则对不同设计方案进行评估，从而实现相应工作的自动化执行。４） 权衡分析（ｔｒａｄｅｏ ｆｆ ａｎ ａｌｙ ｓｉｓ）：无论何时，只要工具为用户提供了多个选择，设计

工具就应当为用户提供充分的比较分析。此外，还应提供关于概念设计到物理设计全过程

·０７２· 分布式数据库系统及其应用

所涉及的设计改变的分析。由于在确定的系统中存在多种可能的物理设计选择，因此要得

到这样一个分析结果是很困难的，目前大部分工具都不支持该功能。５） 设计结果的显示（ｄｉｓｐｌａｙ ｏｆ ｄｅｓｉｇｎ ｒｅｓｕ ｌｔｓ）：设计结果（比如模式）通常被显示为

图表的形式。若想自动生成一个既美观又具有合理布局的图表是很困难的，易于阅读的多

页设计布局是面临的另一个挑战。设计结果的其他类型可能被表示为表格、列表或报表等

易于解释的形式。６） 设计确认（ｄｅｓｉｇｎ ｖｅｒｉｆ ｉｃａｔｉｏｎ）：设计人员非常希望工具能够提供该功能，其目标

是确认所获得的设计结果是否满足 初的需求。 除非可把获得的需求表示为某种可被分

析的形式，否则无法对设计进行确认。２．可视化程序设计工具

可视化程序设计工具是一种完整的程序设计环境，使得程序员能够通过把按钮、文本

框、菜单等（称为“控件”）屏幕元素组装到空白的“窗体”（ｆｏ ｒｍ）上，然后填写与各控件相

关联的处理过程细节，从而快速构造一个 ＧＵ Ｉ 程序。有许多种可视化程序设计产品。尽管有些提供了较高级的特色功能，但它们的工作方

式都是相似的，下面就是一些常见的产品。（１） Ｖｉｓｕａｌ Ｂａｓｉｃ（ＶＢ）和 Ｖｉｓｕａｌ Ｂａｓｉｃ专业版（Ｍ ｉｃｒｏｓｏｆｔ ）这很可能是 广泛使用的可视化程序设计环境。专业版常用于客户机／服务器应用程

序开发。 正如它们的名字所指，这两种程序设计语言是 Ｂａｓ ｉｃ的一种派生物。 Ｖ ｉｓｕａｌ Ｂａｓｉｃ只能在 Ｗ ｉｎｄｏｗ ｓ 下运行。

（２） ＶｉｓｕａｌＡ ｇｅ Ｔ ｅａｍ ｆｏｒ ＯＳ／２（ＩＢＭ ）如果在为 ＯＳ／２ 寻找可视化程序设计环境，ＶｉｓｕａｌＡ ｇｅ 就是一个可以使用的产品。 唯

一的不足是其程序设计语言是基于 Ｓｍａｌｌｔａｌｋ 的，这是一种特为面向对象程序设计而开

发的语言。这一点会使纯粹面向对象的支持者们感到高兴，但却让大多数受过训练的程序

员在初次接触时感到扫兴。（３） Ｄｅｌｐｈｉ（Ｂｏｒｌａｎｄ）Ｄｅｌｐｈｉ 是 Ｂｏｒｌａｎｄ 公司用来对付 Ｖ ｉｓｕａｌ Ｂａｓｉｃ 的“杀手锏”。 Ｄｅｌｐｈｉ 的程序设计语言

是基于 Ｐａｓｃａｌ 的，使用真正的编译器（而非解释器），这使得 Ｄｅｌｐｈｉ程序运行速度较快。Ｄｅｌｐｈｉ还提供了一种台式机版本和一种客户机／服务器版本。

（４） Ｐｏｗ ｅｒＢｕｉｌｄｅｒ（Ｐｏｗ ｅｒｓｏ ｆｔ 公司产品，该公司已并入 Ｓ ｙｂａｓｅ公司）这是 在 Ｗ ｉｎｄｏｗ ｓ 下 建造 客 户机／服 务器 应 用 程序 的 常 用前 端 工 具之 一。

Ｐ ｏｗ ｅｒＢｕｉｌｄｅｒ 使用的程序设计语言叫做 Ｐｏｗ ｅｒＳ ｃｒｉｐｔ ，其结构与 Ｂａｓｉｃ 相似。３．硬核程序设计工具

如果可视化程序环境不能提供足够的灵活性和效率，您可以使用一种老式的程序设

计语言来开发客户机／服务器程序。 这种方法很可能产生一个 高效的程序，但同时需要

·１７２·第八章　分布式数据库与客户机／服务器模式

具有更多的专业技能，需要的时间也更长。 硬核程序设计工具主要包括：（１） Ｃ 和 Ｃ＋＋这是 流行的程序设计语言。 Ｃ 早是作为一种用来写 ＵＮ ＩＸ 操作系统的程序设计

语言而被发明的。 Ｃ＋＋是 Ｃ 的新的、面向对象的版本。 Ｃ＋＋编译器可用来编译 Ｃ 或

Ｃ＋＋程序，可从 Ｍ ｉｃｒｏｓｏｆ ｔ、Ｂｏｒｌａｎｄ、Ｗａｔ ｃｏｍ 和 Ｓ ｙｍａｎｔ ｅｃ 公司获得。Ｍ ｉｃｒｏ ｓｏ ｆｔ 的 Ｖ ｉｓｕａｌＣ＋＋ 包含了一个称为“Ｍ ｉｃｒｏ ｓｏ ｆｔ Ｆｏｕｎｄａｔｉｏｎ Ｃｌａｓｓ”（或 ＭＦＣ）的类库，它可用于构造

Ｗ ｉｎｄｏｗ ｓ 应用程序。 Ｂｏｒｌａｎｄ Ｃ＋＋ 提供了一种相似的类库，名为 ＯＷＬ （ｏｂ ｊｅｃｔ ｗ ｉｎｄｏｗ ｓｌｉｂｒａｒｙ）。 注意，Ｖ ｉｓｕａｌ Ｃ＋＋ 不是一个类似于 Ｖ ｉｓｕａｌ Ｂａｓｉｃ 或 Ｐｏｗ ｅｒＢｕｉｌｄｅｒ 的可视化程

序设计环境，它只是一个基于 Ｗｉｎｄｏｗ ｓ 的 Ｃ＋＋编译器。（２） ＣＯＢＯＬＣＯＢＯＬ 也许已经老了，但它并未被遗忘。 Ｍ ｉｃｒｏＦｏｃｕｓ 销售的一种 ＰＣ，采用高级

ＣＯＢＯＬ 软件包，使设计人员能够建立 Ｗ ｉｎｄｏｗ ｓ 或 ＯＳ／２界面，并访问 ＳＱＬ 数据库。在那

些采用 ＩＢＭ 的 ＣＩＣＳ 事务处理系统作为事务监控器的客户机／服务器系统中，ＣＯＢＯＬ 是

经常使用的。４．套装应用程序

套装软件的概念近来已变得流行起来。 一个套装软件是一组功能齐备的程序的所谓

“集成”化集合，通常包括字处理器、电子表格、数据库、图形演示及其他一些产品。 尽管这

些套装软件本身不是客户机／服务器产品，但它们可用于创建客户机／服务器系统的客户

一方。例如 Ｍ ｉｃｒｏ ｓｏ ｆｔ Ａｃｃｅｓｓ （Ｍ ｉｃｒｏ ｓｏ ｆｔ 的 Ｏｆｆｉｃｅ套装软件中含有的数据库程序）可被用

来从一个 ＳＱＬ 数据库服务器上访问数据。 目前市场上主要有三种套装软件。１） Ｍ ｉｃｒｏｓｏｆｔ Ｏ ｆｆｉｃｅ（Ｍ ｉｃｒｏｓｏｆｔ ）；２） Ｐ ｅｒｆｅｃｔＯ ｆｆｉｃｅ（Ｎｏｖｅｌｌ）；３） ＳｍａｒｔＳｕｉｔ ｅ（Ｌ ｏｔ ｕｓ）。表 ８．１ 列出了每个套装软件中所包含的各个应用程序。

表 ８．１　 套装软件及其包含的应用程序

组成部分 Ｍ ｉｃｒｏ ｓｏｆ ｔ Ｏ ｆ ｆ ｉｃｅ Ｌ ｏ ｔｕｓ Ｓ ｍ ａｒｔＳｕｉｔ ｅ Ｎ ｏｖ ｅｌｌ Ｐ ｅｒ ｆ ｅｃｔＯ ｆ ｆ ｉｃｅ文字处理 Ｗ ｏｒ ｄ Ａｍ ｉ Ｐ ｒｏ Ｗ ｏｒ ｄＰ ｅｒｆ ｅｃｔ电子表格 Ｅｘ ｃｅｌ １２３ Ｑ ｕａｔ ｔ ｒｏ Ｐ ｒｏ图形演示 Ｐｏｗ ｅｒ Ｐ ｏｉｎｔ Ｆ ｒ ｅｅｌａｎｃｅ Ｇ ｒａｐｈｉｃｓ Ｐ ｒｅｓｅｎｔ ａｔ ｉｏ ｎｓ数据库 Ａ ｃｃｅｓｓ Ａ ｐｐｒ ｏａｃｈ Ｐ ａｒａ ｄｏ ｘ邮件 Ｍ ａｉｌ （无） Ｇｒｏ ｕｐＷｉｓｅ

个人信息管理 （无） Ｏｒ ｇａ ｎｉｚｅｒ Ｉｎｆ ｏ Ｃｅｎｔ ｒａｌ

·２７２· 分布式数据库系统及其应用

　　每种套装软件都允许使用 ＯＬＥ２和各个组成部分的程序设计能力将功能集成起来，创建定制的应用程序。 Ｌ ｏｔ ｕｓ 的 Ｓｍａｒｔ Ｓｕｉｔ ｅ 提供与 Ｎ ｏｔｅｓ 的紧密集成；ＰｅｒｆｅｃｔＯ ｆｆ ｉｃｅ 包含

了一种称为 Ｐｅｒｆｅｃｔ Ｓｃｒ ｉｐｔ 的脚本（ｓｃｒ ｉｐｔ ｉｎｇ）语言，它能与该套中的任一个应用程序一起

工作。５．测试工具

对于任何软件项目来说，测试都是一项艰巨的任务。而对于客户机／服务器系统，它就

更复杂了，因为又增加了好几层复杂度。 Ｗｉｎｄｏｗ ｓ 本身使得测试变得困难，因为用户的输

入是无法预料的。测试的问题在于它必须反复进行。每次对系统作了修改，整个系统就必

须被重新测试，以确保这一变化不会带来任何未曾料到的副作用。这种重复进行的测试叫

“回归测试”（ｒｅｇｒｅｓｓ ｉｏｎ ｔ ｅｓ ｔ ）。 有一些软件能使回归测试简化，这些产品包括：１） Ａ Ｔ Ｆ（Ｓｏｆ ｔｂｒ ｉｄｇ ｅ）。 ＡＴ Ｆ 代表“自动测试工具”。２） ＳＱＡ Ｔ ｅａｍＴ ｅｓ ｔ （ＳＱ Ａ）。 ＳＱＡ 代表“软件质量保证”。 Ｔ ｅａｍＴ ｅｓｔ 是专为测试客户

机／服务器 ＧＵ Ｉ 系统而设计的。 ＳＱＡ 还为测试 Ｐｏｗ ｅｒＢｕｉｌｄｅｒ 应用程序提供一个特殊

版本。３） Ｍ ｉｃｒｏｓｏｆｔ Ｔ ｅｓｔ （Ｍ ｉｃｒｏｓｏ ｆｔ ）。 Ｍ ｉｃｒｏ ｓｏｆ ｔ Ｔ ｅｓ ｔ 是一个用于创建自动测试程序文本，

并在 Ｗ ｉｎｄｏｗ ｓ 下运行的工具，能够用它创建测试程序。６．版本控制工具

在集中式大型机计算的时代，版本控制相对简单。对客户机／服务器系统来说，因为软

件不是都在一个中央地点，而是被分布到各个地方。 它的一部分可以在局域网服务器上，一部分在大型机上，一部分在各个用户的 ＰＣ 机上。 将客户机／服务器系统的软件升级工

作进行分布是很困难的，而跟踪哪台计算机有哪个版本就更加困难，因此使用版本控制软

件工具就显得很重要。版本控制软件工具主要有：ＣＭ ＶＣ（ＩＢＭ ，是“配置管理版本控制”之意 ）， Ｄｅｌｔ ａ （Ｍ ｉｃｒｏ ｓｏ ｆｔ ）， ＶＰＣＳ （Ｉｎｔ ｅｒｓｏｌｖ，是 “Ｐｏｌｙｔ ｒｏｎ 版 本控 制 系统” 之意）， ＣＣＣ／Ｍ ａｎａｇｅｒ（Ｓ ｏｆｔ ｏｏ ｌ）， Ｓｏｕｒｃｅｓａｆｅ（Ｏｎｅ Ｔ ｒｅｅ），Ｖｅｒｓｉｏｎｓ（Ｓｔａｒｂａｓｅ）。

目前，人们越来越重视数据库系统自动化设计工具的作用，在创建大型数据库系统的

设计时，自动化设计工具已经变得不可或缺。人们也逐渐意识到模式设计和应用设计应当

同时进行，ＣＡ ＳＥ 工具目前的趋势是同时提供对这两个领域的设计问题的支持。 某些厂

商，比如 Ｐｌａｔ ｉｎｕｍ，提供了数据建模和模式设计的工具（ＥＲＷ ｉｎ），以及过程建模和功能设

计工具（ＢＰＷ ｉｎ）。其他一些工具使用专家系统技术，通过规则形式的专家经验来指导设计

过程。需求的收集和分析通常是一个非常艰苦的过程，专家系统技术在需求收集和分析阶

段也是非常有用的。对于复杂数据库，目前的趋势是同时使用元数据存储和工具以获得更

好的设计，在此不再一一列举。 表 ８．２列出了一些著名的数据库设计和应用建模工具，表中公司以字母顺序排列。

·３７２·第八章　分布式数据库与客户机／服务器模式

表 ８．２　目前的一些自动化数据库设计工具

公司 工具 功能

Ｅｍ ｂａｒｃａｄｅｒ ｏ ＥＲ Ｓｔｕｄｉｏ 使用 ＥＲ 和 ＩＤＥ Ｆ１Ｘ 进行数据库建模

Ｔ ｅｃｈｎｏ ｌｏ ｇ ｉｅｓ ＤＢ Ａ ｒｔ ｉｓａｎ 数据库管理及空间和安全性管理

Ｏ ｒａｃｌ ｅ Ｄｅｖｅｌ ｏｐｅｒ ２０００ 和 Ｄｅｓ ｉｇｎｅｒ ２０００ 数据库建模 、应用开发

Ｐｏ ｐｋｉｎ Ｓｏｆ ｔｗ ａｒｅ Ｓｙ ｓ ｔ ｅｍ Ａ ｒｃｈｉｔ ｅｃｔ ２００１ 数据建模 、对象建模 、过程建模、结构化分析

／设计

Ｐ ｌａｔ ｉｎｕｍ Ｔ ｅｃｈｎｏ ｌｏ ｇ ｙ Ｐ ｌａｔ ｉｎｕｍ Ｅ ｎｔｅｒｐｒｉｓｅ Ｍ ｏｄｅｌ ｉｎｇ Ｓｕｉｔ ｅ：Ｅｒ ｗ ｉｎ，ＢＰＷ ｉｎ 和 Ｐａｒ ａｄｉｇｍ Ｐ ｌｕｓ 数据 、过程和业务组件建模

Ｐｅｒ ｓ ｉｓｔ ｅｎｃｅ Ｉｎｃ． Ｐｏｗ ｅｒｔ ｉｅｒ ＯＯ 关系模型映射

Ｒａｔ ｉｏ ｎａｌ Ｒａｔ ｉｏｎａｌ Ｒｏ ｓｅ Ｕ Ｍ Ｌ 建模、生成应用的 Ｃ＋＋或 Ｊａ ｖａ 代码

Ｒｏ ｇ ｕｅ Ｗ ａｒ ｅ ＲＷ Ｍ ｅｔ ｒｏ ＯＯ 关系模型映射

Ｒｅｓｏ ｌｕｔ ｉｏ ｎ Ｌ ｔｄ． Ｘｃａ ｓｅ 包括概念建模、代码维护

Ｓ ｙｂａｓｅ Ｅｎｔｅｒ ｐｒ ｉｓｅ Ａ ｐｐｌｉｃａｔ ｉｏｎ Ｓｕｉｔ ｅ 数据建模、业务逻辑建模

Ｖ ｉｓ ｉｏ Ｖ ｉｓ ｉｏ Ｅ ｎｔｅｒｐｒｉｓｅ 数据建模、设计及 ＶＢ 和 Ｖ Ｃ＋＋的再设计

８．６．２　创建客户机／服务器系统的技术和方法

创建应用系统这里指的是在计算机上创建一个基于客户机／服务器模式的数据库应

用系统，创建应用系统的过程或步骤包括系统规划、分析、设计、实施、测试、部署、运行和

维护的全过程。 本节并不讨论关于创建应用系统的所有问题，只是讨论一下在基于客户

机／服务器模式的数据库应用系统的创建中的一些有用的技术和方法。１．用户界面设计

客户机／服务器应用系统的成功很大程度上依靠其用户界面的质量。 对终端用户来

说，用户界面就是应用程序。 用户对数据模型是第几范式不感兴趣，也不想知道是否使用

了两阶段提交的协议。在大多数 ＧＵ Ｉ 系统中，界面包括含有界面对象或控件的一个或多个“窗体”，这些控

件有按钮、输入域、下拉式列表、滚动条等。 用户界面设计就是确定需要哪些窗体，以及何

种顺序，并将它们用适当的控件实现，包括菜单命令、工具栏按钮、键盘快捷键、拖放特

性、ＯＬＥ 实现等事情。用户界面设计成为一个客户机／服务器应用程序设计中 复杂的方面。尽管对用户界

面设计来说，没有严格、高效的规则，但 Ｍ ｉｃｒｏｓｏｆｔ 为开发 Ｗｉｎｄｏｗ ｓ ＧＵ Ｉ 出版了一本设计

指南，目前，设计用户界面大多用它作为指导。２．业务规则设计

应用系统业务规则设计的关键是确定必须被实现的业务规则，并将它们从程序的其

他方面尽可能地分离出来。 这样，如果规则变化了，则只有实现规则的那些模块需要被改

·４７２· 分布式数据库系统及其应用

变。理想的情形是，每个业务规则仅仅应该在一个可由任何程序使用的共享模块中被实现

一次，但实际上业务规则经常是在多个程序中反复实现，以致于如果业务政策改变了，业务规则也跟着变，这样往往有许多个程序都要被修改。使用面向对象的程序设计技术能使

业务规则的分离及重用得到 好的实现。３．可视化程序设计

可视化程序设计是一种事件驱动的程序设计，它是贯穿客户机／服务器模式结构的应

用开发所有讨论中的一条通用线索。一个客户机／服务器模式结构的系统无论在后端使用

什么工具，前端（即客户端）几乎总是使用某种可视化程序设计工具来创建的。理解可视化程序设计的概念的关键是，将基于 ＤＯＳ 或基于主机的过程化程序设计转

向Ｗ ｉｎｄｏｗ ｓ 的面向对象的、事件驱动的程序设计环境。在过程化程序设计中，由程序控制

着处理的流向，用户不可以违背程序设计的路径，至多能按程序设计的路径做些选择。 但

在可视化程序设计中，用户可以通过选择在窗口中的对象来控制处理的流向。４．分布式组件技术

分布式组件是独立于特定的程序设计语言和应用系统，可重用和自包含的软件成分。组件是基于面向对象的，支持拖拽（ｄｒａｇ ａｎｄ ｄｒｏｐ）和即插即用（ｐｌｕｇ ａｎｄ ｐｌａｙ）的软件开

发概念。 组件是一个可重用的，提供某一服务或完成一定任务的软件，具有开放性、易升

级、易维护等优点。 它是以组合（原样重用的现存组件）、继承（扩展的重用组件）、设计（制作领域专用组件）组件为基础，按照一定的集成规则，分期、递增式创建应用系统。

分布式组件的基本思想或出发点是开发人员可以用已建好的组件来组装应用系统，从而大大提高应用系统的开发效率，缩短开发周期，提高系统的可靠性或可维护性。 在开

发过程中遵循以组件为核心原则、组件实现透明原则及增量式设计原则。８．６．３　基于组件的软件开发技术和方法

基于组件的软件开发（ｃｏｍｐｏｎｅｎｔｂａｓｅｄ ｓｏｆｔ ｗ ａｒｅ ｄｅｖｅｌｏｐｍｅｎｔ，ＣＢＳＤ）不只是一种

新的分布计算技术，也是一种具有广泛适应性的体系结构，它支持整个软件生命周期，包括需求分析、设计、编码、测试和软件提交。

ＣＢＳＤ 的高度重使用性和互用性，使它将影响应用程序构成的各个方面，例如各种类

型的客户机、应用服务器和数据库服务器等。 ＣＢＳＤ 将对应用程序开发的各个方面产生深

刻的影响。 在数据库应用系统的开发中，ＣＢＳＤ 技术具有更突出的优势。随着成熟的组件标准和新的基础设施建立，为实现组件的互操作性和可移植性，单独

式组件发展成为分布式组件。 但是，现阶段组件的基础设施很不完善，ＣＢＳＤ 仍然是低级

的、零散的。 即使是这样，ＣＢＳＤ 应受到广泛重视，在信息系统的开发中被普遍采用。目前，在组件技术标准化方面，主要有以下三个比较有影响的规范。１） 微软公司推出的 ＣＯＭ／ＤＣＯＭ／ＣＯＭ＋；２） ＯＭＧ 起草与颁布的 ＣＯＲＢＡ ；３） ＳＵ Ｎ 发表的 ＪａｖａＢｅａｎ。

·５７２·第八章　分布式数据库与客户机／服务器模式

１．ＣＯＭ／ＤＣＯＭ／ＣＯＭ＋ＣＯＭ （Ｃｏｍｍｏｎ Ｏｂｊｅｃｔ Ｍ ｏｄｅｌ ）是个开放的组件标准，有很强的扩充和扩展能力。

ＣＯＭ 规定了对象模型和编程要求，为组件互操作提供了二进制标准，使 ＣＯＭ 对象可以

与其他对象相互操作。这些对象可以用不同的语言实现，其结构也可以不同。 值语句和流

控制语句等。 桌面系统中基于 ＣＯＭ 的组件叫做 Ａ ｃｔ ｉｖｅＸ 控件。ＤＣＯＭ （ｄｉｓｔ ｒ ｉｂｕｔｅｄ ｃｏｍｍｏｎ ｏｂｊｅｃｔ ｍｏｄｅｌ）是 Ｍ ｉｃｒｏ ｓｏ ｆｔ 与其他厂商合作提出的一种

分布式组件对象模型，它是 ＣＯＭ 在分布计算方面的延续，提供了分布在网络不同节点的

两个 ＣＯＭ 组件互操作的基础结构。ＤＣＯＭ 增强 ＣＯＭ 的分布处理性能，支持多种通信协

议，加强组件通信的安全保障，把基于认证 Ｉｎｔ ｅｒｎｅｔ 安全机制同基于 Ｗ ｉｎｄｏｗ ｓ Ｎ Ｔ 的 Ｃ ２级安全机制集成在一起，但 ＤＣＯＭ 内部机制仍然采用 ＣＯＭ 模式。 ＣＯＭ 和 ＤＣＯＭ 大

的不同在于 ＣＯＭ 组件是运行在单机上，而 ＤＣＯＭ 组件则是分布在网络上。ＣＯＭ＋倡导一种新的设计概念，把 ＣＯＭ 组件提升到应用层，把底层细节留给操作

系统，使 ＣＯＭ＋与操作系统的结合更加紧密。 ＣＯＭ＋的底层结构仍然以 ＣＯＭ 为基础，但在应用方式上则更多地继承了 ＭＴ Ｓ（ｍｉｃｒｏ ｓｏ ｆｔ ｔｒａｎｓａｃｔｉｏｎ ｓｅｒｖ ｅｒ）的处理机制，包括

Ｍ Ｔ Ｓ 的对象环境、安全模型、配置管理等。 ＣＯＭ＋把 ＣＯＭ 、ＤＣＯＭ 和 Ｍ Ｔ Ｓ 三者有机地

统一起来，同时也新增了一些服务，如负载平衡、内存数据库、事件模型、队列服务等，形成

一个概念新、功能强的组件体系结构，使得 ＣＯＭ＋成为真正适合于企业应用的组件技

术。 它们之间的结构关系如图 ８．２９所示。

图 ８．２９　ＣＯＭ／ＤＣＯＭ／ＣＯＭ＋之间的关系

２．ＣＯＲＢＡＣＯＲＢＡ （ｃｏｍｍｏｎ ｏｂｊｅｃｔ ｒｅｑｕｅｓｔ ｂｒｏｋ ｅｒ ａｒｃｈｉｔ ｅｃｔｕｒｅ，公共对象请求代理体系结构）

是 ＯＭ Ｇ（ｏｂｊｅｃｔ ｍａｎａｇｅｍｅｎｔ ｇ ｒｏｕｐ 创建于 １９８９年，是一个庞大的、非盈利性的国际计算

机工业联盟）推出的一个重要规范。 ＣＯＲＢＡ 的主要目标是解决完全异构分布式系统中软

件的互操作问题，并提供分布式计算所需的一些其他服务。 ＯＲＢ 是 ＣＯＲＢＡ 平台的核心，

·６７２· 分布式数据库系统及其应用

它用于屏蔽与底层平台有关的细节，使开发者可以集中精力去解决与应用相关的问题，而不必自己去为创建分布式计算基础平台而操心。 ＣＯＲＢＡ 是一种公共对象请求代理调度

程序的体系结构，在它的规范定义中，允许在应用系统之间可以互操作，即使它们是用不

同语言编写的，或者是运行在互异操作系统的不同计算机上时也能如此。不管应用系统放

在何处，ＣＯＲＢＡ 都允许它们之间能够进行通信。ＯＭＧ 推出的 ＣＯＲＢＡ ３．０是一个非常重要的版本，它将实现 ＣＯＲＢＡ 与 Ｉｎｔ ｅｒｎｅｔ 的

彻底集成。 它引入的新技术主要包括：ＣＯＲＢＡ 组件模型（ＣＯＲＢＡ ｃｏｍｐｏｎ ｅｎｔ ）、ＣＯＲＢＡ的消息服务（ＣＯＲＢＡ ｍｅｓｓａｇ ｉｎｇ）和通过值传递对象（ｏｂ ｊｅｃｔｓ ｂｙ ｖａｌｕｅ）。此外，ＣＯＲＢＡ 在

实时系统和嵌入式系统中的应用也会有所突破。在 ＯＭ Ａ 参考模型中定义了 ＣＯＲＢＡ 的四个主要部分。１） 应用对象（ａｐｐｌｉｃａｔｉｏｎ ｏｂ ｊｅｃｔｓ）：应用对象是指所有以 ＣＯＲＢＡ 为运行环境的

应用；２） 对象服务（ｏｂｊｅｃｔ ｓｅｒｖ ｉｃｅｓ）：它定义了为分布对象所提供的系统级的基本功能；３） 公共设施（ｃｏｍｍｏｎ ｆａｃｉｌｉｔ ｉｅｓ ）：公共设施定义了能够直接被应用对象所使用的

功能；４） 对象请求代理（ｏｂｊｅｃｔ ｒｅｑｕｅｓ ｔ ｂｒｏｋ ｅｒ，ＯＲＢ）：ＯＲＢ 是 ＣＯＲＢＡ 规范的核心，它定

义了 ＣＯＲＢＡ 的对象总线。ＣＯＲＢＡ 规范给出了 ＯＲＢ 的基本结构及其各部分的功能描述，它包括接口定义语言

（ＩＤＬ ）、静态调用接口（ＩＤＬ Ｓ ｔｕｂ）、ＯＲＢ 界面、动态调用接口（ＤＩＩ）、静态框架接口（ｓｔ ａｔｉｃｓｋｅｌｅｔｏ ｎ ）、动 态 框 架 接 口 （ＤＳ Ｉ ）、对 象 适 配 器 （ ｏｂｊｅｃｔ ａｄａｐｔｅｒ ）、界 面 库 （ ｉｎｔ ｅｒ ｆａｃｅｒｅｐｏｓ ｉｔｏ ｒｙ ）、对象 实现 库 （ ｉｍｐｌｅｍｅｎｔ ａｔｉｏｎ ｒｅｐｏｓ ｉｔｏ ｒｙ ）和 ＯＲＢ 间 互操 作协 议 ＩＩＯＰ。ＣＯＲＢＡ 的组件模型包含四个彼此一致的对象模型：抽象组件模型（ａｂｓｔ ｒａｃｔ ｃｏｍｐｏｎｅｎｔｍｏｄｅｌ ）、打 包 模 型 （ｐａｃｋａｇ ｉｎｇ ｍｏｄｅｌ ）、配 置 模 型 （ｄｅｐｌｏｙｍｅｎｔ ｍｏｄｅｌ ）和 容 器 模 型

（ｃｏｎｔａｉｎｅｒ ｍｏｄｅｌ）。 它们相互协作，构成了完整的企业服务器计算体系结构。 ＣＯＲＢＡ 组

件模型能够支持多界面、基于事件等特性，这与其他的组件技术相一致和相互兼容。 对于

Ｊａｖａ 程序员，ＣＯＲＢＡ 组件模型与 ＪａｖａＢｅａｎ 模型兼容，所以不需要任何协同工作的机制。ＣＯＲＢＡ 组件也有像 ＪａｖａＢｅａｎ 的自我核查和 ＢｅａｎＩｎｆｏ 的描述功能，从而依靠可视化开发

工具能够将组件集成在一起。 对于其他语言来说，可以把 ＣＯＲＢＡ 组件看作集成

ＪａｖａＢｅａｎ 组件模型一样对待。３．ＪａｖａＢｅａｎＪａｖａＢｅａｎ 描述了基于 Ｊａｖａ 的软件组件模型 （ｓｏ ｆｔ ｗ ａｒｅ ｃｏｍｐｏｎｅｎｔ ｍｏｄｅｌ ），简称

Ｂｅａｎ。 按照 Ｊａｖａｓｏ ｆｔ 给出的定义，Ｂｅａｎ 是能够在构造工具中进行可视化操作的可重用软

件。 ＪａｖａＢｅａｎ 的组件模型包含组件和容器两个基本要素，这与 Ａ ｃｔｉｖ ｅＸ／ＤＣＯＭ 技术相

同。作为组件模型，Ｊａｖ ａＢｅａｎ 具有属性、方法、事件、自我检查、定制和永久性等特征。其中

属性、方法、事件三个特征是面向对象的组件必须满足的基本要求，属性和方法保证 Ｂｅａｎ成为一个对象，而事件可以描述组件之间的相互作用以及组件与容器之间相互感兴趣的

·７７２·第八章　分布式数据库与客户机／服务器模式

事情。通过事件的生成、传播和处理，组件相互之间关联在一起，共同完成复杂的任务。 自

我检查、定制和永久性三个特征主要侧重于对 ＪａｖａＢｅａｎ 组件性质的刻画。 自我检查用于

暴露与发现组件接口。 使用自我检查机制，可以使组件的使用者了解到组件的属性、方法

和事件。随着企业级应用的发展，ＳＵ Ｎ 公司又提出了企业级 ＪａｖａＢｅａｎ（ｅｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎ，

ＥＪＢ），其结构完全采用基于软件组件模型的分布对象计算体系。 与 ＪａｖａＢｅａｎ 组件模型不

同的是，ＥＪＢ 模型只是有意于服务器组件，而且用来设计支持多层、分布式和可伸缩的应

用系统。 ＥＪＢ 组件在一个 ＥＪＢ 服务器上运行，这个服务器支持线程、状态管理、并发性、资源共享、固有的事务的其他的功能。 通过把这些建立到组件模型中，它使得开发人员能够

以很简单的方式完成复杂 ＡＰ Ｉ 程序的编码工作。 企业级 Ｊａｖ ａＢｅａｎ 各组成部分的含义为

基于 ＳＱ Ｌ 标准 Ｊａｖａ 数据库连接 ＪＤＢＣ（ｊａｖａ ｄａｔ ａｂａｓｅ ｃｏｎｎｅｃｔ ｉｖｉｔ ｙ），其基本功能和设计与

ＯＤＢＣ 相似。８．６．４　异构数据源访问接口技术和方法

在网络环境下，特别是分布式系统（包括客户机／服务器系统）中，异构数据源的访问

是一个不可避免的问题，采用 ＳＱＬ 语言的异构数据库为解决相互访问问题提供了可能。每个支持分布式的数据库引擎都带有自己的、包含用于访问数据库的 ＡＰＩ 函数的动态连

接库 ＤＬＬ ，应用程序可以利用它们访问和操作数据库中的数据。 如果应用程序直接调用

这些动态连接库，称为“固有调用”，因为这种调用对于特定的数据库产品来说是“固有的

或专用的”。 固有调用接口的优点是执行效率高，由于是“固有”的，编程实施也比较简单。但它的缺点是不具有通用性。对于不同的数据库引擎，应用程序必须连接和调用不同的专

用的动态连接库，这对于分布式数据库系统的应用是极不方便的。除了“固有调用”这种异构数据源访问接口技术外，目前 有影响的有两种标准：１） Ｍ ｉｃｒｏｓｏｆｔ 公司的 ＯＤＢＣ；２） 以 Ｓｕｎ 和 ＪａｖａＳｏ ｆｔ 公司为代表的 ＪＤＢＣ。１．ＯＤＢＣＯ ＤＢＣ （ｏｐｅｎ ｄａｔａｂａｓｅ ｃｏｎｎｅｃｔｉｖ ｉｔｙ）是 Ｍ ｉｃｒｏ ｓｏ ｆｔ 公司推出的开放式数据库接口，已

获得越来越多第三方厂商的支持，并得到广泛应用，使得异构数据库的访问更加便利。ＯＤＢＣ 为应用程序和驱动模块提供了一种满足各自需要的 ＡＰ Ｉ 方法，并且保持了与

ＳＱＬ 标准的一致性。 ＯＤＢＣ 接口定义了一个函数库，应用系统通过 ＳＱＬ 访问 ＤＢＭ Ｓ。ＯＤＢＣ 接口对不同的 ＤＢＭ Ｓ 提供半透明的存取，这样开发人员便能在虚拟数据库上展开

工作，通过加载的驱动程序将逻辑结构映射到具体的 ＤＢＭ Ｓ。 在图 ８．３０ 中，ＯＤＢＣ 是

Ｗｅｂ 服务器（或其他数据库使用者）与数据库服务器之间的接口，它包括一组标准，可以

用来发出 ＳＱＬ 命令和接收返回的数据和信息。ＯＤＢＣ 允许应用程序访问它支持的不同的数据源，实现数据源驱动的是 ＯＤＢＣ 函数

·８７２· 分布式数据库系统及其应用

图 ８．３０　ＯＤＢＣ 的作用

调用的动态链接库。 ＯＤＢＣ 数据源由数据及其相应的 ＤＢＭ Ｓ 或文件管理器、操作系统和

网络软件组成，它负责为应用程序存储和管理数据。 ＯＤＢＣ 所提供的一套 ＳＱＬ 数据库访

问函数屏蔽了底层 ＤＢＭ Ｓ 的不同，成为一种调用级接口，可访问来自多种 ＤＢＭ Ｓ 的数据。在数据源和 ＯＤＢＣ Ａ ＰＩ 之间起联系作用的是为不同数据库专门开发的 ＯＤＢＣ 驱动

程序。 它的主要作用包括：连接数据管理，错误处理管理，数据类型转换，以及对各种

ＤＢＭ Ｓ 以不同方式提供表、列及其他对象进行访问管理。 现有 ＯＤＢＣ 驱动程序既包括

Ｍ ｉｃｒｏｓｏｆｔ 公司提供的标准件，也包括数据库厂商为支持 ＯＤＢＣ 而自己开发的驱动程序

产品。ＯＤＢＣ 驱动程序有单层和多层之分，单层驱动程序位于数据源之上，并处理 ＯＤＢＣ

调用和 ＳＱＬ 语句，即单层驱动程序包含了用来管理数据源文件和目录表的数据访问软

件。多层驱动程序处理函数调用，并把 ＳＱＬ 请求传送给数据库引擎进行处理，多层驱动程

序不包含用来直接管理数据的数据访问软件。２．ＪＤＢＣＪＤＢＣ 是支持基本 ＳＱ Ｌ 功能的一个通用的底层 ＡＰＩ。 它在不同的数据库功能模块的

层次上提供了一个统一的用户接口，使得独立于 ＤＢＭ Ｓ 的 Ｊａｖａ 应用程序开发工具和产

品成为可能，同时提供了多样化的数据连接方式。与 ＯＤＢＣ 相似，ＪＤＢＣ 也是建立在 Ｘ／Ｏｐｅｎ ＳＱ Ｌ ＣＬ Ｉ（ｃａｌｌ ｌｅｖ ｅｌ ｉｎ ｔｅｒ ｆａｃｅ）基础之上

的。 ＪＤＢＣ 定义了一个友好的 Ｊａｖａ 接口来与 Ｘ／Ｏｐｅｎ ＳＱ Ｌ ＣＬＩ 中定义的基本抽象层和基

本概念进行连接。 ＯＤＢＣ 是一个 Ｃ 语言的接口，因此不能直接应用到 Ｊａｖａ 中，而 ＪＤＢＣ 建

立在 Ｊａｖａ 语言基础之上。 在确保“１００％纯 Ｊａｖａ”的解决方案情况下，ＪＤＢＣ 应用无需像

·９７２·第八章　分布式数据库与客户机／服务器模式

ＯＤＢＣ 应用那样进行客户机的安装和管理。 但是，如果不能保证“１００％纯 Ｊａｖａ”的解决方

案的话，应需要在客户机上安装相应软件。ＪＤＢＣ ＡＰＩ 定义了 Ｊａｖａ 中的类，表示数据库连接、ＳＱＬ 指令、结果集合、数据库图元

数据等。它允许 Ｊａｖａ 程序员发送 ＳＱＬ 指令并处理结果。通过驱动程序管理器，ＪＤＢＣ Ａ ＰＩ可利用不同的驱动程序连接不同的数据库系统。ＪＤＢＣ 驱动程序既可全部采用 Ｊａｖａ 编程，作为 Ａ ｐｐｌｅｔ 的一部分下载；也可利用桥接方式（ＪＤＢＣＯＤＢＣ ）连接到已存在的数据库存

取数据。

图 ８．３１　ＪＤＢＣ 的组成部件

ＪＤＢＣ 完成三项工作：建立与数据库连接，发送 ＳＱ Ｌ 语句和处理结果。ＪＤＢＣ 主要有两种接口：面向程序开发人员的 ＪＤＢＣ Ａ ＰＩ 和面向底层的 ＪＤＢＣ 驱动程

序 Ａ ＰＩ。 ＪＤＢＣ ＡＰＩ 是一系列抽象的接口，它使得应用程序员能够进行数据库连接，执行

ＳＱＬ 查询，并且得到返回结果。ＪＤＢＣ 驱动程序 ＡＰＩ 是面向驱动程序开发商的编程接口。 对于大多数数据库驱动程

序而言，仅实现 ＪＤＢＣ Ａ ＰＩ 提供的抽象类就可以了。 ＪＤＢＣ 驱动程序管理器负责管理连接

到不同数据库的多个驱动程序。 ＪＤＢＣ 驱动程序可以分成以下四类：采用 ＪＤＢＣＯＤＢＣ 桥

方式，内置 ＡＰＩ 的部分 Ｊａｖａ 驱动程序方式，独立于 ＤＢＭ Ｓ 的全 Ｊａｖａ 网络驱动程序方式

和 ＤＢＭ Ｓ 内置协议的全 Ｊａｖａ 驱动程序方式

前两种方式是由于未获得“１００％纯 Ｊａｖａ 驱动程序”而采取的妥协方案。 由于要求客

户机安装部分程序，对不同操作平台的机器实现互联网络数据共享设置了障碍。后两种方

式是通过 ＪＤＢＣ 访问数据库的较优方式。 它们充分利用了 Ｊａｖａ 语言的优势，可以不预先

进行客户端安装，而由 Ａｐｐｌｅｔ 从服务器端下传 ＪＤＢＣ 驱动程序。图 ８．３１ 总结了 ＪＤＢＣ 的组成部件。实用程序创建连接、语句、结果集和结果元数据对

象，这些对象的调用由驱动程序管理器发送到相应的驱动程序，再由驱动程序对数据库进

·０８２· 分布式数据库系统及其应用

行访问。 图中的 Ｏｒａｃｌｅ 数据库可以通过 ＪＤＢＣＯＤＢＣ 桥或纯 ＪＤＢＣ 驱动程序访问。

８．７　本 章 小 结

本章首先对客户机／服务器模式进行了较全面和系统的介绍；给客户机／服务器模式

在计算机系统体系结构的发展历程中进行定位，讨论了客户机／服务器模式，特别是多服

务器和对等客户机／服务器模式；分析了客户机／服务器模式的特性、优缺点和远景展望；讨论了客户机／服务器模式与分布式数据库系统共同的关键问题：分布式数据和分布式访

问；阐述创建基于客户机／服务器模式的应用系统的自动化设计工具、技术和方法；给出了

基于组件的软件开发技术和方法，以及异构数据源访问的接口技术和方法。尽管客户机／服务器模式已经成为计算机领域中流行的技术，但它毕竟是还处在发展

过程中的事物，与分布式数据库系统一起，还存在许多问题有待于进一步研究和解决。 鉴

于客户机／服务器模式在现有的计算机应用中已产生重要的影响，相信客户机／服务器模

式对未来的计算机发展和应用也会有不可忽视的重要影响。

习　　题

８．１　为什么说基于客户机／服务器模式的系统可以看作是协作式的分布式系统？８．２　概述在 ＤＤＢＭ Ｓ 环境中，一个基于客户机／服务器模式的计算机应用系统的三

个基本组成部分及各部分的功能。８．３　概述客户机／服务器模式结构的发展历程及远景展望。８．４　为什么说分布式数据和分布式访问是客户机／服务器系统与分布式数据库系统

共同的关键问题？ 综述数据分布的基本形式和分布式数据访问的基本技术。８．５　概述你使用过（或正在使用）或你所知道的主要的自动化设计工具，以及它们是

如何适用于创建客户机／服务器系统或分布式数据库系统的。８．６　概述你使用过（或正在使用）或你所知道在基于客户机／服务器模式应用系统的

创建中有哪些有用的技术和方法？８．７　目前在组件技术标准化方面，主要有哪些比较有影响的规范？８．８　概述目前 有影响的两种异构数据源访问接口技术 ＯＤＢＣ 和 ＪＢＤＣ 的工作原

理。８．９　以下面给出的 ５ 个关系为基础，给出创建一个基于二层的客户机／服务器模式

的简单的教学管理系统的设计方案。 教学管理数据库中的 ５ 个关系是（带下画

线的属性为主码）：

·１８２·第八章　分布式数据库与客户机／服务器模式

学生关系 Ｓ学号

ＳＮＯ姓名

ＳＮ Ａ Ｍ Ｅ年龄

Ａ ＧＥ性别

ＳＥ Ｘ籍贯

ＢＰＬＡ ＣＥ　

课程关系 Ｃ课程号

ＣＮＯ课程名

ＣＮ ＡＭ Ｅ学分

ＣＲＥＤＩＴ

任课关系 Ｃ Ｔ课程号

ＣＮ Ｏ教师号

Ｔ Ｎ Ｏ班级

Ｃ ＬＡ ＳＳ学生数

ＳＮ Ｕ Ｍ Ｂ　

选课关系 Ｓ Ｃ学号

ＳＮ Ｏ课程号

ＣＮ Ｏ成绩

Ｇ ＲＡＤＥ

教师关系 Ｔ教师号

Ｔ ＮＯ教师名

Ｔ Ｎ Ａ Ｍ Ｅ年龄

Ａ ＧＥ职称

ＰＣ

８．１０　以第 ８．９ 题中给出的教学管理数据库中的 ５ 个关系为基础，设计一个基于三

层客户机／服务器模式的简单的教学管理系统的实现方案。

·２８２· 分布式数据库系统及其应用

第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

本章的内容由ＷＷＷ 数据库和移动数据库两部分构成。它们虽然不是真正意义上的

分布式数据库，但它们也是通过计算机网络访问和操作远程站点上的数据，只是要求用户

应清楚地知道数据是存储在哪个远程站点上的，需要采取相应的操作。随着 Ｉｎｔ ｅｒｎｅｔ 和无

线技术的发展，特别是 ＷＷＷ 建立以来，它们与分布式数据库有着极其紧密的关系。从特

定意义上说，整个 Ｉｎｔ ｅｒｎｅｔ 就是一个巨大的“分布式数据库”。本章将研究支持它们的基本

技术，并考察它们会如何影响分布式数据库系统。

９．１　ＷＷＷ 数据库系统的产生及其运行环境

９．１．１　ＷＷＷ 数据库系统的产生

　　进入 ２０世纪 ９０ 年代后，由于信息技术的发展和信息量的急剧膨胀，信息的全球化打

破了地域的界限，ＷＷＷ 技术以惊人的速度发展。ＷＷＷ （ｔｈｅ ｗ ｏｒｌｄ ｗ ｉｄｅ ｗ ｅｂ，ＷＷＷ ）俗称 ＷＷＷ 网，也简称为 Ｗｅｂ。是由瑞士的 ＣＥＲＮ 于 １９９０年搭建的，作为大规模超媒体信

息服务系统，用于在物理学家之间提供信息共享。 经过十几年的发展，今天，ＷＷＷ 已经

是一个基于超媒体的信息网络，它通过超链接的方式浏览 ＷＷＷ 网上的信息。 只要接入

ＷＷＷ 网，任何人都可以享受到这项技术带来的方便，分享 ＷＷＷ 网上无穷无尽的信息。但是，在 Ｗｅｂ 服务器 中，信 息以文本 或图像 文件的 形式 进行存 储，所以，单纯 的

ＷＷＷ 查询 速度 很慢、检索 机制很 弱，尤其是 基于 内容和 基于 结构 的检 索。 它不 像

Ｓ ｙｂａｓｅ，Ｏｒａｃｌｅ，Ｉｎｆｏｒｍ ｉｘ 等专用数据库系统，能对大批量数据进行有序的、有规则的组织

与管理，只要给出查询条件便能很快得到查询结构果。 因此，ＷＷＷ 数据库系统应运而

生，它将 Ｗｅｂ 技术与分布式数据库技术有机结合，同时具有超文本功能和数据库功能。利用数据库技术来组织与管理 ＷＷＷ 上数据，利用 ＷＷＷ 的超文本、超链接功能查询数据

库中的数据。ＷＷＷ 数据库系统是指在 ＷＷＷ 环境下运行的数据库系统，它的数据库分散配置在

ＷＷＷ 的不同节点（或称站点）上，能够为 ＷＷＷ 用户提供远程数据访问服务，是一种特

定的分布式数据库系统——网络数据库系统。现在，ＷＷＷ 数据库系统已经成为 Ｉｎｔ ｅｒｎｅｔ上 现实的、 受欢迎的、 为流行的，也是应用 广泛的、采用超文本、超媒体方式进行

信息存储与传递的特定的分布式数据库系统。９．１．２　统一资源定位器和超文本传输协议

１．统一资源定位器

　　在 ＷＷＷ 上存储的文档 常见的类型是超文本标记语言格式的超文本文档，ＨＴ Ｍ Ｌ

文档包含文本、字体描述和其他格式的指令。指向本地或远程的其他文档的链接可以与文

本域结合在一起，图像也可以用适当格式的指令来引用。 因此，一个超文本系统必须能够

存储指向文档的指针。在 ＷＷＷ 上，指针的功能用统一资源定位器（ｕｎｉｆｏ ｒｍ ｒｅｓｏｕｒｃｅ ｌｏｃａｔｏ ｒ，ＵＲＬ ）来实

现。 它把网络上的信息有效地组织在一起。 ＵＲＬ 是一个由反斜杠符号分隔的目录名的字

符串，以一个文件名结尾。 譬如，大家可以在下面的 ＵＲＬ 查到关于本书的参考资料之一

的枟Ｆｕｎｄａｍｅｎｔａｌｓ ｏｆ Ｄａｔａｂａｓｅ Ｓ ｙｓ ｔｅｍｓ枠一书的内容介绍：　　 ｈ ｔｔｐ：／／ｗｗｗ．ａｗ．ｃｏｍ／ｃｓｅｎｇ／ａｕｔｈ ｏｒｓ／ｅｌｍａｓｒｉ／Ｄｂａｓｅ３ｅ／Ｄｂａｓｅ３ｅ．ｈ ｔｍ ｌＵ ＲＬ 的 开 头 部 分 通 常 是 一 个 超 文 本 传 输 协 议 （ｈｙｐｅｒｔ ｅｘ ｔ ｔ ｒａｎｓｐｏ ｒｔ ｐｒｏ ｔｏ ｃｏｌ，

ＨＴ Ｔ Ｐ ），这是 Ｗｅｂ 浏览器所使 用的协议，用 来与网络服务器进行 通信。 浏览器解 释

ＨＴ Ｍ Ｌ 文件并将内容呈现给用户。常用的浏览器有微软公司的 Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ 和网景

公司的 Ｎｅｔｓｃａｐｅ Ｎａｖ ｉｇ ａｔｏｒ 。 第二部分给出在整个 ＷＷＷ 网上唯一的机器名或网站名。ＷＷＷ 网服务器上包括多个 ＨＴ Ｍ Ｌ 文件以及其他可通过 ＵＲＬ 访问的文件集合，称为

Ｗｅｂ 网站（Ｗｅｂ ｓｉｔ ｅ）。 在上面的 ＵＲＬ 中，ｗｗｗ．ａｗ．ｃｏｍ 称为 Ａｄｄｉｓｏｎ Ｗｅｓｌｅｙ 出版社的

网站。 Ｕ ＲＬ 的其他部分是这个文件在这个网站上的路径名。由此可见，ＵＲＬ 给出了从 Ｗｅｂ 系统可访问的每个文档全球唯一的名字。 由于 ＵＲＬ

是用户可读的，所以用户可以直接使用它来访问所需要的文档，而不必从一个预先定义的

位置一步一步地浏览过去。也由于 ＵＲＬ 允许使用 ＷＷＷ 网上的机器名，所以它们是全球

范围内的，并且用户可以使用 ＵＲＬ 创建跨机器的连接。另外，ＨＴ Ｍ Ｌ 文档可以同时显示文档和目录，并且可以指明系统中的文件，所以任何

用户在与 ＷＷＷ 网连接的机器上都可以容易地创建文档，而其他用户可以通过 ＷＷＷ对它们进行访问。 也就是说，ＷＷＷ 是开放的，任何用户都可以在 ＷＷＷ 上创建文档，并且可以将 ＵＲＬ 告诉别人。 实际上，这也导致 ＷＷＷ 几乎处于无政府状态，ＷＷＷ 上没有

任何中央权威机构进行管理。 现在许多 ＷＷＷ 网用户在 ＷＷＷ 上都有自己的主页（稍后

详述），这些主页常常包含用户的个人信息和工作生活信息。２．超文本传输协议

超文本传输协议是 ＷＷＷ 客户机（浏览器）与 ＷＷＷ 服务器之间的应用层传输协

议。ＨＴ Ｔ Ｐ 是 Ｗｅｂ 的主要基础，允许在支持 ＨＴ Ｔ Ｐ 的客户机与服务器之间执行与平台无

关的通信。 ＨＴＴ Ｐ 客户机通过 ＵＲＬ 的命名机制访问驻留在 ＨＴ Ｔ Ｐ 服务器中的数据源。ＨＴ Ｔ Ｐ 协议是一种面向对象的协议，为了保证 ＷＷＷ 客户机与 ＷＷＷ 服务器之间通信

不会产生二义性，ＨＴＴ Ｐ 协议正确定义了请求报文和响应报文的格式。 ＨＴ ＴＰ 协议会话

过程包括以下四个步骤：１） 连接（ｃｏｎｎｅｃｔｉｏｎ）；２） 请求（ｒｅｑｕｅｓｔ ）；３） 应答（ｒｅｓｐｏｎｓｅ）；４） 关闭（ｃｌｏｓｅ）。ＨＴ Ｔ Ｐ 协议有如下两个非常具吸引力的功能：第一个是 ＨＴＴ Ｐ 的作为消息可传输复

·４８２· 分布式数据库系统及其应用

杂数据类型的功能，并且 Ｗｅｂ 服务器可以为客户机提供与 ＨＴ ＭＬ 文档集成在一起的文

本、图形、声音及视频信息。 一些 ＨＴ ＴＰ 客户机可以直接显示各种各样的数据类型，如声

音 及视 频图像 等。 支 持多 媒体的 ＨＴ ＴＰ 客户 机图 形界面 的出 现，诸 如 Ｍ ｉｃｒｏ ｓｏ ｆｔ 的

Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏ ｒｅ 或 Ｎ ｅｔ ｓｃａｐｅ 的 Ｎ ａｖｉｇ ａｔ ｏｒ／Ｃｏｍｍｕｎｉｃａｔ ｏｒ，已经实现了这些功能。第二个关键的功能是 ＨＴ Ｔ Ｐ 便于在 ＨＴ Ｔ Ｐ 客户机之间及使用不同网关的其他协议

之间通信的功能。ＵＲＬ 命名方案不但确定了查找所需资源的必需位置，并且规定了协议。这样可为 ＨＴ Ｔ Ｐ 客户展现一个几乎无缝的，将 ＨＴＴ Ｐ 服务器与其他流行的 Ｉｎｔｅｒｎｅｔ 服

务，诸如 ＳＭＴ Ｐ 邮件、基于 ＮＮ Ｔ Ｐ 的网络新闻、基于 ＦＴ Ｐ 的文件传输、Ｇｏｐｈｅｒ 信息服务

器以及 ＷＡ ＩＳ 信息服务器集成在一起的环境。 浏览器在一个单独的客户机程序中将所有

好的，为 终用户在 Ｉｎｔ ｅｒｎｅｔ 上所使用的协议包装在一起。用户仅仅需要学习一个单一

的软件，即可访问 Ｉｎｔ ｅｒｎｅｔ 网上提供的几乎任何可用的信息。图 ９．１ 以图形方式说明了这

个方案。

图 ９．１　ＨＴ Ｔ Ｐ 适于各种各样的数据类型及协议

９．１．３　超文本标记语言和主页

１．超文本标记语言

　　在 ＷＷＷ 服务器中存储的页面采用超文本标记语言书写成的，是一种结构化的文

档。 凡是通过浏览器来显示的文档就必须要求它符合 ＨＴ Ｍ Ｌ 的标准。 ＨＴ Ｍ Ｌ 语言是

ＷＷＷ 上用于创建超文本链接的基本语言，它可以定义格式化的文本、色彩、图像与超文

本链接等，主要被用于 ＷＷＷ 主页的创建与制作。 由于 ＨＴ Ｍ Ｌ 编写制作的简易性，使它

对促进 ＷＷＷ 的迅速发展起到了重要的作用，并且作为 ＷＷＷ 的核心技术在 ＷＷＷ 网

中得到了广泛的应用。 由于 ＨＴ Ｍ Ｌ 的标准化和规范，使得不同厂商开发的 ＷＷＷ 浏览

·５８２·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

器、ＷＷＷ 编辑器、ＷＷＷ 转换器等各类软件可以按照同一标准对页面进行处理，这样用

户就可以自由地在 ＷＷＷ 网上漫游了。ＨＴ Ｍ Ｌ 文档的主要特点是可以包含指向其他文档的链接项，即其他页面的 ＵＲＬ ，这

样，用户便可以通过一个页面中的链接项访问其他服务器中的页面或同一个服务器中的

其他页面。 图 ９．２ 为页面之间链接示意图。 ＨＴＭ Ｌ 文档的另一个特点是可以将声音、图像、视频等多媒体信息集成在一起，用户在单一的浏览器界面中既可以阅读到文字信息，也可以欣赏到各种图片、动画等，同时浏览器也会根据 ＨＴ Ｍ Ｌ 文档中所集成的声音和视

频信息的类型激活相应的播放程序。其实，ＨＴ ＭＬ 文档本身并不包含多媒体数据，它仅包

含指向这些多媒体数据的链接项。通过这些链接项，浏览器就能够知道到哪里可以找到这

些多媒体数据。用户仅仅需要用鼠标在一个链接项上执行单击操作，就可以移动到另一个

新的文档中去，而不管该文档是什么类型的，也不管它位于何处。

图 ９．２　页面之间链接示意图

使用 ＨＴ Ｍ Ｌ 语言开发的 ＨＴ Ｍ Ｌ 超文本一般具有．ｈｔｍ 或．ｈｔｍ ｌ 后缀。通常利用一些

专门的工具软件，就可以完成各种类型文件向 ＨＴ Ｍ Ｌ 文件的转换。ＨＴ Ｍ Ｌ 语言的特点有：１） 通用性：ＨＴ Ｍ Ｌ 作为 ＷＷＷ 网上的标准语言和通用信息描述方式，可以把分布广

泛的不同类型的信息资源联系在一起，为所有的信息系统提供了一个真正的、公开的

接口。２） 简易性：ＨＴＭ Ｌ 文档制作简单，并且随着 ＨＴ Ｍ Ｌ 版本的升级，在功能更加灵活、

复杂的情况下，仍然保持其使用简单的特点。３） 可扩展性：ＨＴ Ｍ Ｌ 的广泛使用带来了加强功能，增加标识符等要求，因此采用了

子类元素的方式作为系统扩展的保证。４） 与平台无关性：ＨＴ Ｍ Ｌ 可以用在各种不同的操作系统之上。５） 支持用不同方式创建 ＨＴ ＭＬ 文档：文本编辑器和专用的 ＨＴ ＭＬ 编辑器都可以用

·６８２· 分布式数据库系统及其应用

来创建 ＨＴ ＭＬ 文档。２．主页

主页（ＨＰ）是一种特殊的 Ｗｅｂ 页面。 通常，主页是指包含个人或机构基本信息的页

面，用于对个人或机构进行综合性介绍，是访问个人或机构详细信息的入口点，用户通过

主页上所提供的链接便可以进入到其他页面，访问关于该个人或机构的详细信息。因而用

户只要了解到个人或机构的主页的 Ｕ ＲＬ ，便可以访问与该主页直接链接或间接链接的

页面。对于一个机构来说，主页通常是 ＷＷＷ 服务器的缺省页面，即用户在输入 ＵＲＬ 时只

需要给出 ＷＷＷ 服务器的主机名，而不必指定具体的路径和文件名，ＷＷＷ 服务器会自

动将其缺省页面返回给用户。例如，访问中国科学院研究生院的主页，只需要输入 ｈｔ ｔｐ：／／ｗ ｗｗ．ｇ ｓｃａｓ．ａｃ．ｃｎ，则服务器 ｗｗｗ．ｇ ｓｃａｓ．ａｃ．ｃｎ 会检索到它的缺省页面返回给用户。 但

是，有一些主页并不是 ＷＷＷ 服务器的缺省页面，特别是一些个人主页，通常需要指定页

面的路径及文件名。目前，几乎所有连接到 ＷＷＷ 网的公司、机关、学校和企事业单位都有自己的主页，

主页已经成为他们形象的标志和对外的窗口。

９．２　ＷＷＷ 数据库系统的体系结构

９．２．１　概述

　　ＷＷＷ 数据库系统虽然不是真正意义上的分布式数据库系统，但是它所基于的客户

机／服务器体系结构，它的数据的物理分布性，以及通过计算机网络访问和操作远程站点

上的数据，说明它与分布式数据库系统有着极其紧密的关系，是一种特定的分布式数据库

系统。ＷＷＷ 数据库系统是 基于 ＷＷＷ 网的数据库系 统，在 Ｗｅｂ 上 发布数据 库信息。

图 ９．３是 Ｗｅｂ 数据库的体系结构图。将客户机或 Ｗｅｂ 浏览器设计为能解释用户输入的 ＨＴ ＭＬ 格式化的文档。在 ＨＴ Ｍ Ｌ

文档中嵌入 ＵＲＬ 链接，建立 Ｗｅｂ 资源之间的链接。 当浏览器选择了一个 ＵＲＬ 链接时，一个请求传给网络中相应的 Ｗｅｂ 服务器，以检索并组织由客户机显示所引用的资源。 而

且，一个单独的 ＨＴ ＭＬ 文档可能涉及相同服务器中的其他页面或者遍布世界的不同服

务器中的页面，对用户而言在很大程度上是透明的。这个在资源之间建立灵活链接的能力

提供了 Ｗｅｂ 超文本的本质，同时为分布式数据库应用展现了一个巨大的机会。 因为作为

一种资源，一个分布式数据库或多个数据库可分布到世界各地，组成一个网络数据库

系统。Ｗｅｂ 数据库体系结构中的数据库服务器是由数据库及其相应的 ＤＢＭ Ｓ 组成，它的功

能我们已经相当熟识，这里不再赘述。

·７８２·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

图 ９．３　Ｗｅｂ 数据库的体系结构图

９．２．２　ＷＷＷ 浏览器

ＷＷＷ 的客户程序在 Ｉｎｔｅｒｎｅｔ 网上被称为 ＷＷＷ 浏览器，它是用来浏览 Ｉｎｔ ｅｒｎｅｔ 网

上的 ＷＷＷ 页面的软件。１．ＷＷＷ 浏览器工作原理

在 ＷＷＷ 数据库系统中，ＷＷＷ 浏览器负责接收用户的请求，并利用 ＨＴ Ｔ Ｐ 协议将

用户的请求传送给 ＷＷＷ 服务器。 当服务器将请求的相应结果页面返回到该浏览器后，它将结果页面进行解释，并显示于用户的屏幕上。

ＷＷＷ 浏览器的主要组成部分如图 ９．４ 所示，它由一系列的客户单元、一系列的解

释单元和一个控制单元组成。控制单元是浏览器的中心，它协调和管理客户单元和解释单

元，并接收用户的键盘或鼠标输入的请求，进行分析后转交给相应的客户单元。 客户单元

负责将根据控制单元转交来的用户请求，将请求发送给相应的服务器，调用其他相关单元

完成用户的指令。 例如，用户键入了一个 ＵＲＬ ，或用鼠标单击了一个超链接，控制单元接

收并分析这个命令，然后调用相应的 ＨＴ Ｍ Ｌ 客户单元，ＨＴ Ｍ Ｌ 客户单元通过网 络向

ＷＷＷ 服务器发出请求，当 ＷＷＷ 服务器返回 ＵＲＬ 指定的页面后，控制单元再调用

ＨＴ Ｍ Ｌ 解释单元解释这个页面，然后将解释的结果通过显示驱动显示在用户的屏幕上。通常，利用 ＷＷＷ 浏览器，用户不仅可以浏览 ＷＷＷ 服务器上的页面，而且可以访

问 Ｉｎｔ ｅｒｎｅｔ 网上其他服务器的信息和资源，例如可以访问 ＦＴ Ｐ 服务器、Ｇｏｐｈｅｒ 服务器

等。 当用户访问这些服务器和资源时，控制单元将调用其他的客户单元和其他的解释单

元，完成其资源的请求和解释工作。２．ＷＷＷ 浏览器的基本功能

目前，ＷＷＷ 浏览器通常具备的基本功能有：１） 查找、启动与终止链接；２） 通过按钮与菜单项进行链接；

·８８２· 分布式数据库系统及其应用

图 ９．４　ＷＷＷ 浏览器的主要组成部分

３） 使用历史得到以往访问过的页面的地址列表；４） 使用书签提供更多的页面的地址；５） 自由设定屏幕窗口；６） 选择起始页面，即当用户打开窗口时第一个出现在屏幕上的页面；７） 改变浏览器界面的式样、字体与色彩；８） 查看内嵌图像与外部图像；９） 保存和打印主页。

９．２．３　ＷＷＷ 服务器

ＷＷＷ 数据库系统是一种异质异构的计算环境，与这一环境相适应，ＷＷＷ 数据库

系统在客户机／服务器两层结构之间增加了中间层——Ｗｅｂ 服务器层。 Ｗｅｂ 服务器层的

作用是集成、转换多个数据源的数据。通常，ＷＷＷ 服务器组成的主要部分包括应用程序、驱动程序管理器和 ＤＢＭ Ｓ 驱动

程序，如图 ９．５所示。 当 Ｗｅｂ 服务器接收到一个浏览器的请求后，它执行相应的应用程

序，并将生成的 ＨＴ Ｍ Ｌ 文档返回。应用程序负责向数据源（指数据库及其相关的 ＤＢＭ Ｓ）请求建立链接，发出请求命令

并接收结果，进行错误处理，启动、提交和回滚事务。 驱动程序管理器处于应用程序和

ＤＢＭ Ｓ 驱动程序之间。 当应用程序请求链接时，驱动程序管理器确定所请求的 ＤＢＭ Ｓ 的

类型，并把相应的驱动程序装入内存（如果它未被装入内存）。驱动程序管理器还处理一些

初始请求，并验证从应用程序收到的请求的格式和顺序。 驱动程序管理器由 Ｍ ｉｃｒｏｓｏｆｔ 公

司提供，包含在 Ｗｉｎｄｏｗ ｓ 中。驱动程序处理请求，并向指定类型数据库服务器上的数据源

发出请求。 不同的数据源有不同的驱动程序，例如 ＩＢＭ ＤＢ２，Ｏｒａｃｌｅ，Ｓ ｙｂａｓｅ，Ａｃｃｅｓｓ 以及

所有支持 ＯＤＢＣ 的产品都有自己的驱动程序。驱动程序是由 ＤＢＭ Ｓ 提供商或独立的软件

公司提供的。

·９８２·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

图 ９．５　ＷＷＷ 服务器组成的主要部分

请求的格式除了简单的文档外，Ｗｅｂ 服务器允许 Ｗｅｂ 浏览器可以在传输文档名的

同时传递其他参数，这样它们可以在程序执行时作为参数传递。 Ｗｅｂ 服务器在生成文档

时可以根据传入参数的不同而生成不同的文档。由此可见，这些特性使得 Ｗｅｂ 服务器可以很容易地作为多种信息服务器的前端服务

器。 如果需要在 Ｗｅｂ 上提供一种新的服务，人们只需要创建并安装一个提供该种服务的

可执行的应用程序即可。如果需要在 Ｗｅｂ 上提供一种新的数据源，人们只需要编写（或得

到）并安装一个访问该种数据源的驱动程序即可。

９．３　ＷＷＷ 数据库

９．３．１　ＷＷＷ 数据库的建立和访问

１．ＷＷＷ 数据库的创建

　　ＷＷＷ 数据库驻留在 ＷＷＷ 网络的各个节点上，它可以是独立的集中式的数据库，这与在计算机网络环境下运行的真正意义上的分布式数据库系统是有本质区别的。所以，ＷＷＷ 数据库的创建基本上类似于集中式数据库的创建，所不同的是应当考虑网络环境

的影响。除了关系数据库的经典问题（如关系规范化等）之外，在数据库设计中还应考虑处

理功能与数据在客户机和服务器间的合理平衡的分布与配置，认真分析处置客户机和服

务器间的通信方法、通信频度及数据量，既要保持客户机和服务器的高独立性，又使得对

数据库的访问效率 高，数据在网络上的传输量 小，此外还应考虑系统的安全性、可控

性、成本等。在基于客户机／服务器模式的分布式数据库系统中，数据的完整性管理是极为重要

的。常见的情况是，在数据库服务器上配置全局数据库，在客户机上配置局部数据库，局部

数据库中的基础数据是全局数据库中同一数据的一个拷贝。应当设计一些维护程序，定期

自动检测客户机上的局部数据库与服务器上的全局数据库中的数据是否一致，若不一致，则从全局数据库中复制回 新的数据。 这项工作也可以利用专用的数据库复制服务器

（ｒｅｐｌｉｃａｔｉｏｎ ｓｅｒｖ ｅｒ）进行，但需要耗费资金配备数据库复制服务器软件，将增加系统的额

外投资。

·０９２· 分布式数据库系统及其应用

在数据库服务器上建立数据库一般需经过以下步骤。１） 建立数据库的逻辑分区或数据库存储文件。数据库逻辑分区是指在硬盘上划出来

的一个存储空间，用于存放数据库的数据。 数据库逻辑分区在 Ｏｒａｃｌｅ 系统中称为分区

（ｐａｒｔｉｔｉｏｎ）；在 Ｓｙｂａｓｅ 系统中称为设备（ｄｅｖ ｉｃｅ），它们都是一个数据文件；在 ＳＱＬ Ｓｅｒｖｅｒ中则直接称为文件（数据库文件和事务日志文件）。

在建立数据库逻辑分区或数据库存储文件时，需要定义它的名称、空间的大小，以及

存储方式等参数。２） 创建数据库。 在指定的数据库服务器上给出数据库的名称、所在的逻辑分区或数

据库存储文件的名称和大小等参数。３） 建立用户自定义数据类型。 除了使用系统预定义的数据类型外，有时用户需要自

行定义一些数据类型。４） 建立数据库基本表、视图和索引。５） 装入数据。上述各项工作可以用 ＤＢＭ Ｓ 所提供的系统命令，以及 ＤＤＬ ，ＤＭ Ｌ 语言进行。 现在的

数据库管理系统，一般都伴随有一些数据库的设计和建立的辅助工具，可以很方便地完成

创建数据库的各项任务。２．ＷＷＷ 数据库的访问

为支持用户进行查询处理、报表生成等请求，除支持对文件系统的存取外，还应该允

许用户对 ＷＷＷ 上数据库及其 ＤＢＭ Ｓ 进行访问。现在，Ｗｅｂ 上数据库管理系统一般是关

系型 ＤＢＭ Ｓ，它们都支持标准 ＳＱ Ｌ ，并且在其交互式语言中扩充了数据操纵的能力，例如

Ｓ ｙｂａｓｅ的 Ｔ ｒａｎｓａｃｔＳＱ Ｌ ，Ｏｒａｃｌｅ 的 ＰＬ／ＳＱ Ｌ 等。同时在其交互式语言中都提供对存储过

程和触发器的支持，用于操纵和管理数据。由于 ＷＷＷ 数据库可以是一种特定的异构分布式数据库，而且它的数据驻留在网络

上的具体位置，对用户是不具透明性的，这与在计算机网络环境下运行的真正意义上的分

布式数据库系统也是有本质区别的。所以，用户必须清楚地知道数据是存储在哪个远程站

点上的，在访问数据库之前，需要建立或选定数据源，然后才能访问数据库。（１） 建立数据源

在 ＷＷＷ 数据库系统中，可以配置多个平台的多个数据库，客户应用系统可以根据

需要链接到不同的数据库。为了建立客户应用系统与数据库服务器之间的链接，方便访问

数据库，需要在客户端和数据库服务器端设置相同的数据源（ｄａｔ ａ ｓｏｕｒｃｅ）。ＷＷＷ 数据库

系统中 的数 据源 可以 是多 种类 型的 数据 库，因 为 ＷＷＷ 服 务器 使 用公 共网 关接 口

（ｃｏｍｍｏｎ ｇａｔｅｗ ａｙ ｉｎｔｅｒ ｆａｃｅ，ＣＧＩ）作为中间件，为访问异构的多数据库提供接口。 数据源

所含的数据库引擎完成所需的数据库操作。（２） Ｗｅｂ 上数据库访问的方法

现有对 Ｗｅｂ 上数据库及 ＤＢＭ Ｓ 进行访问的方法可以分为如下两类：１） 使用 ＣＧＩ 脚本的存取方法：数据库服务器通过 ＣＧＩ 与 Ｗｅｂ 服务器进行交互。 图

９．６ 是一个使用 ＣＧＩ 脚本的 Ｗｅｂ 数据库存取体系结构示意图，可以用 Ｐｅｒｌ，Ｔ ｃｌ 或者 Ｃ

·１９２·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

来编写 ＣＧＩ 脚本程序。这种解决方案的主要缺点是，对于每一个用户请求，Ｗｅｂ 服务器必

须启动一个新的 ＣＧＩ 进程，每当一个新的 ＣＧＩ 进程和 ＤＢＭ Ｓ 建立链接时，Ｗｅｂ 服务器必

须等待，直到那个 ＣＧＩ 将结果返回服务器。 即使对用户请求进行分组，也无法获得效率的

改善。另外，脚本程序只能集中存放于 ＣＧＩｂｉｎ 子目录下，这将导致潜在的安全问题。如果

脚本程序分散存储，对脚本程序的管理又成为一个棘手的问题。ＣＧＩ 也没有专门的开发语

言，必须借助 Ｐｅｒｌ，Ｔ ｃｌ或者 Ｃ 进行 ＣＧＩ 脚本的编程，这也是 ＣＧＩ 技术一个很大的不足。

图 ９．６　使用 ＣＧＩ 脚本实现 Ｗｅｂ 数据库存取

２） 使用 ＪＤＢＣ 的存取方法： ＪＤＢＣ 通过执行 ＳＱ Ｌ 语句对关系数据库进行存取。 与数

据 库 进 行 链 接 时， ＪＤＢＣ 无 需 为 每 个 用 户 请 求 启 动 新 的 进 程。 ＪＤＢＣ 使 用 Ｊａｖａ 类

ＣｏｎｎｅｃｔｉｏｎｂＳｔ ａｔｅｍｅｎｔ 和 ＲｅｓｕｌｔＳ ｅｔ 进行数据库链接，传递 ＳＱ Ｌ 请求并获得查询结果。利用 Ｊａｖａ 的平台无关性，用户应用可运行在任何 Ｊａｖａ 兼容的浏览器上，Ｊａｖ ａ 代码从服务器

端传送到 客户机的浏览器上执 行。 Ｊａｖ ａ 代码是 ＤＢＭ Ｓ 透明的，由 服务器端 ＤＢＭ Ｓ 的

ＪＤＢＣ 驱动程序执行与 ＤＢＭ Ｓ 的交互。 使用 ＪＤＢＣ 的缺点是，其效率取决于 Ｊａｖａ 虚拟机

的固有效率。除 ＣＧＩ 外，其他 Ｗｅｂ 服务器厂商也提供自己的中间件产品，以支持对异构的多种数

据 库 的 链 接，包 括 微 软公 司 的 Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｅｒ ＡＰＩ （ＩＳＡＰＩ ）和 网 景 的 Ｎ ｅｔｓｃａｐｅ Ａ ＰＩ（ＮＳＡＰＩ）。 ＤＢＭ Ｓ 厂商也都已经或将要提供对 Ｗｅｂ 数据库的存取方案。９．３．２　ＷＷＷ 数据库接口

ＷＷＷ 的迅速发展，使其成为全球信息传递与共享的日益重要和 具潜力的资源，如何使用和管理 ＷＷＷ 上的大量数据，以满足用户不断增长的信息需求？ 近年来大量的

研究致力于研究数据库与 ＷＷＷ 的接口，将分布式数据库技术应用于 Ｗｅｂ 上数据的管

理和查询，使得查询可以在更细的粒度上进行，并集成多个数据源的数据。 实质上，ＸＭ Ｌ

·２９２· 分布式数据库系统及其应用

为 Ｗｅｂ 上数据的集成和数据管理提供了新的模型，可以预见，很多成熟的分布式数据库

技术将进入 Ｗｅｂ 数据处理领域，形成 ＷＷＷ 数据库系统，把 Ｗｅｂ 变为一个巨大的分布

式数据库。这种变化给分布式数据库研究带来了极好的机会，使得将分布式数据库技术的

研究和应用扩展到 Ｗｅｂ 领域成为现实。１．数据库与 Ｗｅｂ 接口的重要性

数据库与 Ｗｅｂ 的接口的重要性有以下两个方面：第一，随着 Ｗｅｂ 上电子商务等应用

的发展，用于事务处理的数据库必须链接到Ｗｅｂ 上。因为 ＨＴ Ｍ Ｌ 表格界面对事务处理来

说十分简便，用户可以在订单表格中填写详细的信息，然后按提交按钮就能传送给服务器

了。与该订单表格相关的程序会在服务器上执行，然后在服务器端的数据库上执行一个事

务。 事务执行的结果可以表示成 ＨＴ ＭＬ 的格式并显示给用户。数据库与 Ｗｅｂ 接口的第二个重要性是可以通过动态生成 Ｗｅｂ 文档，解决依用户的

不同而使显示的 Ｗｅｂ 文档也不同（个性化），以及当数据更新时 Ｗｅｂ 文档也应该同步更

新的问题。当请求一个文档时，可以有一个程序在服务器端运行，它查询数据库，并根据查

询结果生成文档。这样就可以根据保存在数据库中的用户信息，针对不同用户显示不同的

Ｗｅｂ 文档。Ｗｅｂ 文档中的数据可以由数据库查询来定义，这样，不论什么时候数据库中的

相关数据更新了，Ｗｅｂ 文档就会随之被更新。２．数据库的 Ｗｅｂ 接口方式

客户应用系统访问 ＷＷＷ 数据库的接口方式有多种，有的在前面已经阐述过。 这里

将简单综述一下几种常用的数据库的 Ｗｅｂ 接口方式和技术。（１） 固有调用方式

每个数据库引擎都包含自己的、用于访问数据库的 ＡＰＩ 函数的动态链接库 ＤＬＬ ，应用程序可利用它存取和操纵数据库中的数据。应用程序可以直接调用这些动态链接库，所以称它为“固有调用”，因为该调用对于特定的数据库产品来说是“固有”（专用）的。

固有调用接口方式的优点是执行效率高，由于是“固有”，编程实现较简单。 它的缺点

是不具通用性。 对于不同的数据库引擎，应用程序必须链接和调用不同的、专用的动态链

接库，这对于 ＷＷＷ 数据库系统的应用是不方便的。（２） ＯＤＢＣ 方式

ＯＤＢＣ（ｏｐｅｎ ｄａｔ ａｂａｓｅ ｃｏｎｎｅｃｔｉｖ ｉｔｙ）是“开放式数据库互联”的简称。 它是 Ｍ ｉｃｒｏ ｓｏ ｆｔ公司提出的应用程序通用编程接口（ＡＰ Ｉ）标准，用于对数据库的访问。

ＯＤＢＣ 实际上是一个数据库访问函数库，使应用程序可以直接操纵数据库中的数据。ＯＤＢＣ 是基于 ＳＱＬ 语言的，是一种在 ＳＱＬ 和应用界面之间的标准接口，它解决了嵌入式

ＳＱＬ 接口非规范核心，免除了应用软件随数据库的改变而改变的麻烦。 ＯＤＢＣ 的一个

显著的优点是，用它生成的程序与数据库或数据库引擎无关，为数据库用户和开发人员屏

蔽了异构环境的复杂性，提供了数据库访问的统一接口，为应用程序实现与平台的无关性

和可移植性提供了基础，因而 ＯＤＢＣ 获得了广泛的支持和应用。

·３９２·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

（３） ＪＤＢＣ 方式

ＪＤＢＣ 是 ＳＵ Ｎ 公司针对 Ｊａｖ ａ 语言提出的与数据库链接的 ＡＰＩ 标准。与 ＯＤＢＣ 类似，ＪＤＢＣ 是特殊类型的 ＡＰＩ，这些 ＡＰ Ｉ 支持对数据库的链接和基本的 ＳＱ Ｌ 功能，包括建立

数据库链接，执行 ＳＱ Ｌ 语句，处理返回结果等。 与 ＯＤＢＣ 不同的是，ＪＤＢＣ 为单一的 Ｊａｖａ语言的数据库接口。

ＪＤＢＣ 的结构同样有一个 ＪＤＢＣ 驱动程序管理器作为 Ｊａｖａ 应用程序与数据库的中

介，它把对数据库的访问请求转换和传送给下层的 ＪＤＢＣＮ ｅｔ 驱动程序，或者转换为对数

据库的固有调用。更多的实现方式是通过 ＪＤＢＣＯＤＢＣ 桥接驱动程序，转化为一个 ＯＤＢＣ调用，进行对数据库的操作。

（４） ＡＳＰ 方式

Ａ ＳＰ 是 ａｃｔｉｖ ｅ ｓｅｒｖｅｒ ｐａｇｅｓ （动态服务器主页）的缩 写，是微软 为 ＩＩＳ ３．０（ｉｎｔ ｅｒｎｅｔｉｎ ｆｏｒｍａｔｉｏｎ ｓｅｒｖ ｅｒ）以上服务器及单机开发的动态网页设计技术，是一个 Ｗｅｂ 服务器端

的脚本编程环境。 Ａ ＳＰ 可以与 ＨＴ Ｍ Ｌ 集成，后台可与 Ｗ ｉｎｄｏｗ ｓ Ｎ Ｔ 系统上配套的 ＳＱ Ｌ数据库相连， 只需编写少量的代码，即可在页面上执行一系列的数据库访问操作。 使用

Ａ ＳＰ 所提供的内置组件对象，配合 ＨＴ ＭＬ ，Ｖ ＢＳｃｒｉｐｔ 和 Ｊａｖａｓｃｒｉｐｔ ，可实现各种复杂功

能，并使主页呈现丰富多变的风格，从而建立一个动态的、功能强大的 Ｗｅｂ 应用系统。 它

可以根据浏览器端提出的不同申请，动态地生成相应的 ＨＴ Ｍ Ｌ 页面，可根据用户的需要

方便地获取数据。在结构关系上，ＡＳＰ 通过 ＯＤＢＣ 与数据库打交道，因而向上可以兼容各类数据库系

统，而对于下层，ＡＳＰ 产生的 ＨＴ Ｍ Ｌ 对客户端的浏览器有广泛的适应性。 由于 ＡＳＰ 在服

务器端执行，因此很好地保证了浏览器／服务器结构中数据的一致性。 此外，使用 ＡＳＰ 开

发的 Ｗｅｂ 应用程序，返回到前端是纯 ＨＴＭ Ｌ 语言，不依赖于浏览器和操作系统，更方便

维护，且具有较好的保密性。（５） ＪＳＰ 方式

ＪＳＰ （Ｊａｖａ ｓｅｒｖｅｒ ｐａｇｅｓ）是由 ＳＵ Ｎ 公司倡导，许多公司参与建立的一种动态网页技

术标准。 在传统的网页 ＨＴＭ Ｌ 文件（．ｈｔｍ，．ｈｔｍ ｌ）中加入 Ｊａｖａ 程序片段（ｓｃｒ ｉｐｔｌｅｔ ）和 ＪＳＰ 标记（Ｔ ａｇ），就构成了 ＪＳＰ 网页（．ｊｓｐ）。 Ｗｅｂ 服务器在遇到访问 ＪＳＰ 网页的请求

时，首先执行其中的程序，然后将执行结果以 ＨＴ Ｍ Ｌ 格式返回给客户。 网页程序可以操

作数据库，重新定向网页以及发送 Ｅｍａｉｌ 等，这就是建立动态网站所需要的功能。 所有程

序操作都在服务器端执行，通过网络传送给客户端的仅是得到的结果，对客户端浏览器的

要求很低。ＪＳＰ 可以轻松地与多种数据库相连，通过 ＪＳＰ 网页可以添加、删除、修改和浏览数据

库中的数据。ＪＳＰ 链接数据库可以通过两种方法：一种是通过 ＪＤＢＣ Ｄｒｉｖｅｒ，另一种是通过

ＪＤＢＣＯＤＢＣ 桥。实际上，常用的 ＷＷＷ 数据访问接口是 ＯＤＢＣ 与 ＪＤＢＣ。 ＯＤＢＣ 屏蔽了异构环境的

复杂性，提供了数据库访问的统一接口，为应用程序实现与平台的无关性和可移植性提供

了基础。 ＪＤＢＣ 则为单一的 Ｊａｖａ 语言的数据库接口。 而 ＡＳＰ 与 ＪＳＰ 是开发动态网页的两

种重要的环境。Ａ ＳＰ 使用 ＯＤＢＣ 通过 ＡＤＯ 链接数据库，而 ＪＳＰ 通过 ＪＤＢＣ 技术链接数据

·４９２· 分布式数据库系统及其应用

库；Ａ ＳＰ 适用于 Ｗｉｎｄｏｗ ｓ 环境，ＪＳＰ 配合 Ｊａｖａ 可跨平台应用。 另外，调用级接口 ＳＱ Ｌ ／ＣＬ Ｉ 规定了一批标准接口函数，用于访问 ＳＱＬ 数据库。ＳＱ Ｌ ／ＣＬ Ｉ 可以代替嵌入式 ＳＱ Ｌ ，实现对数据库的操作。９．３．３　ＷＷＷ 数据库面临的问题

在规划企业内部的计算环境时，Ｗｅｂ 是非常重要的考虑因素，既要考虑到为企业系

统提供外部接口，也要考虑为顾客、供应商等提供方便的信息服务。基于安全性考虑，某些

组织的雇员在内部网的操作是受限的，无法在子网以外的地方自由操作。 在内部网和

ＷＷＷ 网的应用中，电子商务也成为主要的数据库应用领域。 对电子仓库、电子产品目

录、电子书店等提供支持的数据库应用逐渐普遍。ＷＷＷ 数据库的管理面临着很多挑战，包括：１） Ｗｅｂ 技术需要进一步与对象技术相融合。 ＷＷＷ 网可以看做是分布式对象系统，

ＨＴ Ｍ Ｌ 页面执行对象的功能。２） 对于复杂的应用需求，ＨＴＭ Ｌ 的功能过于简单，需要扩展 ＨＴ Ｍ Ｌ 标记。 通常，

ＨＴ Ｍ Ｌ 需要扩充其如下几个方面的功能：① 使 Ｗｅｂ 客户机整合来自多个异构数据库的数据，执行应用前台终端的功能；② 使 Ｗｅｂ 客户机为不同用户提供同一数据的不同视图；③ 通过提供数据挖掘功能，使 Ｗｅｂ 客户机“智能化”。３） 把“行为”看作对象，为网页添加更多的行为，使网页内容更加动态化。从这个角度

来讲，客户机和服务器对象（ＨＴ Ｍ Ｌ 页面）可以进行交互，可把网页看作可编程对象集，客户机代码能够动态地访问并且操作这些对象。

４） 对一个海量数据库（可能是几十个 Ｇ）进行查询时，必须能够对大量用户进行支

持，所提供的响应时间必须是用户可接受的，这将是 ＷＷＷ 数据库面临的一个主要挑战。这个问题要由 Ｗｅｂ 服务器和底层的 ＤＢＭ Ｓ 共同解决。

Ｗ ３Ｃ （ｗ ｏｒｌｄ ｗ ｉｄｅ ｗ ｅｂ ｃｏｎｓｏ ｒｔｉｕｍ ）正在设计 Ｗｅｂ 对象模型（ｗ ｅｂ ｏｂｊｅｃｔ ｍｏｄｅｌ），以解决目前数据建模的限制所带来的问题。 Ｗ ３Ｃ 建议用扩展标记语言（ＸＭ Ｌ ）进行网上结

构 化文 档的 交 换。 ＸＭ Ｌ 定义 了标 准通 用 标记 语言 ＳＧＭ Ｌ （ｔ ｈｅ ｓ ｔａｎｄａｒｄ ｇｅｎｅｒａｌｉｚｅｄｍａｒｋｕｐ ｌａｎｇｕａｇｅ），支持标记语言和特定应用标记的定制。凭借其灵活性，ＸＭ Ｌ 已经迅速

地 发展起来。 Ｗ ３Ｃ 的文档对象模型（ｄｏｃｕｍｅｎｔ ｏｂｊｅｃｔ ｍｏｄｅｌ，ＤＯＭ ）为 Ｗｅｂ 客户机的

ＨＴ Ｍ Ｌ 和 ＸＭ Ｌ 文件定义了一个面向对象的 ＡＰ Ｉ。 Ｗ ３Ｃ 定义的元数据模型标准可对

ＷＷＷ 网资源进行描述。ＷＷＷ 数据库的建立以及检索的技术，正经历着一个巨大的革命。 总而言之，某些数

据库必须提供 ２４×７ 的应用。 为确保数据库操作的可靠性，Ｗｅｂ 服务器必须具备足够的

强健性。 在财务和医药数据库的应用中，安全性仍然是一个关键问题。 而且，从目前的数

据库应用环境向Ｗｅｂ 环境迁移时，必须充分支持用户对现行操作方式的延续。另外，在处

理系统间的数据迁移时要避免不一致性问题。 为支持基于 Ｗｅｂ 的应用，传统的数据库查

询及事务处理功能也必须采取适当的改进。 移动数据库系统便是一个很好的例子。

·５９２·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

９．４　移动数据库系统概述

随着无线技术和分 布式数据库技术的发 展，在数 据通信领 域中出现 了一项新 技

术——移动计算（ｍｏｂ ｉｌｅ ｃｏｍｐｕｔｉｎｇ）。 移动计算环境促进了无线技术与分布式数据库应

用的融合，形成了移动数据库系统（ｍｏｂｉｌｅ ｄａｔ ａｂａｓｅ ｓｙ ｓｔ ｅｍ ）。 移动数据库系统展现了日

益广阔的应用前景，并在越来越多的领域中发挥了不可替代的作用。移动数据库技术正在

给信息产业带来一场深刻的变革，并逐渐成为以应用驱动为主要特征的新技术浪潮的主

角之一。９．４．１　移动数据库的产生背景

分布式数据库系统作为传统的基于网络的数据库系统，是建立在持久的网络链接和

固定节点（站点）环境下的。 近年来，随着网络技术、移动通信技术和分布式数据库技术的

发展，以及移动设备的广泛应用，移动计算环境逐渐成为分布式数据库技术新的研究和应

用环境，移动计算环境下的分布式数据库系统也就应运而生。移动数据库的产生是如下两种因素交互作用的结果。１．应用需求是移动数据库技术发展的源动力

一切技术的发展都离不开应用需求的推动。随着信息社会的飞速发展，人们对使用信

息的场合、时间、方式、方法都提出了越来越多的全新概念，这些需求的出现是移动数据库

技术发展的源动力。 主要体现在：（１） 对活动范围的扩展

人们不再满足于传统的局限在有限空间里的办公室方式，而希望将办公的地点延伸

到广阔的地理区域，如山谷、野外、海域、岛屿；人们也不再满足于固定的办公时间，而希望

可以随时随地办公，甚至在移动的过程中办公，如在旅途中处理日常办公事务，在购物时

随时查询商品行情等。（２） 商务领域的需求

随着信息通信技术（ＩＣＴ ）不断引发革命性的变化，“电子商务”的概念正受到“移动商

务”（ｍｏｂｉｌｅ ｃｏｍｍｅｒｃｅ）的挑战。 近来在德国召开的信息与通信技术展示会 ＣｅＢＩＴ 上，“电

子商务”的概念不再占据重要位置，“移动商务”成为 新、 具前瞻性的话题。 这是由于

“移动商务”的概念与商务运作无所不在的特点有着天然的耦合性，行家预测，它将在 １０年之内覆盖传统的“电子商务”。这不仅意味着人们口袋里的手机、掌上电脑、ＰＤＡ 等的功

能会越来越强，而且意味着嵌入式软件和移动计算技术将会给企业应用模式带来彻底的

变革。（３） 数字化信息服务的发展

股市行情分析信息、天气预报、交通信息、即时导航信息等的接收与查询不再受时间

和场合的限制。

·６９２· 分布式数据库系统及其应用

（４） 军事领域的特殊要求

战场医疗、实时指挥控制、高可用的协同联络等军事领域对嵌入式软件和移动计算技

术也提出了特殊的要求。２．通信、硬件技术及相应软件技术的发展为移动数据库的产生提供了强有力的技术

保障

　　近年来，通信技术和硬件技术的发展呈加速的趋势，相应的软件技术也获得了巨大的

发展，这使得移动数据库技术有了可靠的技术保障。 主要体现在：（１） 无线通信技术的发展

近年来，模拟蜂窝通信系统、数字蜂窝通信系统、无线广域网、无线局域网、红外技术，以 及卫星通 信技术都 获得了巨 大的发展。 无线 Ｉｎｔ ｅｒｎ ｅｔ 的发展，更是 掀起 了第二 代

Ｉｎｔｅｒｎｅｔ 流行热潮。（２） 硬件技术的发展

信息技术的发展使得与移动数据库技术相关的各种硬件设备的处理能力及存储容量

等有人估计每 １８个月就翻一番。 移动电话、掌上电脑、手持电脑、ＰＤＡ、ＧＰＳ 卡、无线通信

卡等琳琅满目，形成了一个济济一堂的大家族。（３） 相应软件技术的发展

各种支持移动计算的操作系统、数据库系统、通信软件系统、软件包和中间件等不断

完善和迅速发展。 据资料显示，目前专为掌上电脑开发的软件就有 ５０００ 余种之多。在以上两种因素交互作用下，移动数据库技术已经在许多领域中获得了巨大的成功，

并涌现出了许多令人耳目一新的实用系统。 如新加坡 Ｃｏｍ ｆｏ ｒｔ Ｓ ｅｒｖ ｉｃｅ 中心基于 ＧＰＳ 的

出租车自动派遣系统，ＩＢＭ 公司、Ｒａｎｋ Ｘｅｒｏｘ 公司、Ｓｅａｒｓ 公司的技术服务人员派遣及实

时数据采集系统等。 除此之外，移动数据库技术还在下列领域显示着广阔的应用前景。１） 零售业。 销售人员可以通过手持设备帮助用户了解他们希望了解的信息，随时填

写订单，及时反馈给总部，为用户提供更周到细致的服务。２） 制造业。工程师无须携带大量的资料即可到现场维修服务。以航空制造业为例，技

术人员在进行飞机检修时，通过手持设备即可随时获得正被检修的这架飞机的详细资料，迅速解决问题。

３） 金融业。 经纪人或个人用户可以利用手持设备随时随地查询金融信息，并及时地

将自己的交易提交给主服务器，动作迅速，减少错误。４） 医疗卫生。利用手持设备，医生在出诊时可以避免携带大量的病历，也可以在家中

随时获取病人的信息，及时作出诊断。掌上电脑配合无线移动通信和 ＧＰＳ 技术，可以用于智能交通管理，大宗货物运输管

理，消防现场作业等。此外，移动数据库技术还可广泛用于机顶盒、手机等领域，实现基于 Ｉｎｔｅｒｎｅｔ 的信息

访问和存储。９．４．２　移动计算环境的体系结构

图 ９．７展示的是移动平台的通用体系结构。这是一个分布式结构，计算机通过高速有

·７９２·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

线网络互联，这些计算机称为固定主机（ｆｉｘ ｅｄ ｈｏ ｓｔ ｓ，ＦＳ）或基站（ｂａｓｅ ｓｔａｔ ｉｏｎｓ，ＢＳ）。ＦＳ 是

通常意义上的计算机，通过设置能够实现对移动设备的管理。ＢＳ 具有无线接口，可以管理

移动设备并进行数据通信。

图 ９．７　移动平台的通用体系结构

１．移动单元

移动单元（ｍｏｂｉｌｅ ｕｎｉｔｓ，Ｍ Ｕ 或者说 ｈｏｓ ｔｓ），它与基站（ＢＳ）通过无线信道进行通信，其带宽明显低于有线网络。 ＢＳ 借助下行链路（ｄｏｗ ｎｌｉｎｋ ｃｈａｎｎｅｌ）向 Ｍ Ｕ 发送数据，Ｍ Ｕ借助上行链路（ｕｐｌｉｎｋ ｃｈａｎｎｅｌ）向 ＢＳ 发送数据。 新的便携式无线应用产品，使用红外接

口传输率可达 １ Ｍ ｂ／ｓ，使用无 线通信传输率可达 ２Ｍ ｂ／ｓ，使用 移动电话 的传输率 为

９１４ｋｂ／ｓ。 比较起来，以太网可以提供更高的传输率，比如 １０Ｍ ｂ／ｓ 快速以太网，ＦＤＤＩ 能

够提供 １００Ｍ ｂ／ｓ 的传输率，ＡＴ Ｍ 的传输率高达 １５５Ｍ ｂ／ｓ。Ｍ Ｕ 是 使用 电 池供 电 的便 携 式 计 算机 等 移 动 设备，可在 地 理 位 置移 动 性 区 域

（ｇｅｏｇ ｒａｐｈｉｃ ｍｏｂｉｌｉｔｙ ｄｏｍａｉｎ ）内自由移动，地理位置移动性区域是指由无线通信信道有

限的带宽所确定的区域。 地理位置移动性区域被划分为更小的区域——信元（Ｃｅｌｌ），以便

对移动设备进行管理。移动设备的移动受限于地理位置移动性区域（信元内移动），但移动

中信息存取连续性（ａｃｃｅｓｓ ｃｏｎｔｉｇｕｉｔｙ ）要求移动设备在穿越信元的边界时，要保证信息检

索过程的连续性。移动计算平台类似于客户机／服务器结构，移动设备有时被看作客户机或用户，把 ＢＳ

当作服务器。 每个信元由一个 ＢＳ 管理，ＢＳ 由发送器（ｔｒａｎｓｍｉｔｔｅｒ）和接收器（ｒｅｃｅｉｖ ｅｒ）组成，用以响应信元内客户的信息处理请求。 在此假定：平均查询响应时间小于用户物理穿

·８９２· 分布式数据库系统及其应用

越一个信元所需时间。客户机和服务器通过无线信道进行通信。客户机和服务器之间的通信链接模型，可以

是多数据信道（ｍｕｌｔ ｉｐｌｅ ｄａｔａ ｃｈ ａｎｎｅｌｓ），也可以是单信道（ｓｉｎｇ ｌｅ ｃｈ ａｎｎｅｌ）。２．移动环境的特性

移动数据库环境中数据的更新很快，用户需要保持对数据更新的追踪，以确保数据的

及时更新。此类例子不胜枚举，如股市信息、气象数据、航班信息等。 数据库由独立的外部

进程进行异步更新。移动用户随机地进入或离开信元。 用户在信元内的平均停留时间称为停留延迟

（ｒｅｓ ｉｄｅｎｃｅ ｌａｔｅｎｃｙ，ＲＬ ），通过观察用户在信元内的停留时间，可得到用户的 ＲＬ 。 因此，每个信元都有一个 ＲＬ 值。 用户的行为呈现局部化特征，例如，用户习惯频繁地访问数据库

中的某个固定部分。 服务器无需对客户机链接、断开的信息进行维护，也无需维护客户机

专用的数据请求信息。无线网络在很多方面区别于有线网络。 有线网络上的数据库用户可以一直保持和网

络的链接，并具有持续的电源供给，因此，响应时间是 为关键的性能指标。但在无线网络

中，响应时间和电源供给都很重要。 当移动设备正处于在线接收或发送状态时，称其处于

活动状态。 目前，对于具有 ＣＤＲＯＭ 的便携式电脑而言，电池只能支持其维持三个小时

的活动状态。 为节省耗电量延长电池寿命，客户机移动设备可以切换至休眠状态（ｄｏ ｚｅｍｏｄｅ）。 当服务器和客户进行通信时，客户机被从休眠状态中唤醒。９．４．３　移动数据库系统的参考模型

建立在移动计算环境中的数据库系统的体系结构没有确定的模型，图 ９．８ 给出的是

一个移动数据库系统的参考模型。

图 ９．８　移动数据库系统的参考模型

移动数据库系统由两部分组成：一部分俗称移动部分或客户机，运行在嵌入式移动设

备（移动节点）上，包括嵌入式移动应用、移动数据库管理系统（Ｍ ＤＢＭ Ｓ）及其同步接口，

·９９２·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

以及移动数据库；另一部分俗称固定部分或服务器，是在主机或基站上运行，包括主数据

库及其数据库管理系统，其他异构数据源及 ＯＤＢＣ 和同步服务器及同步协同器。 它们两

部分之间通过网络进行通信，嵌入式移动设备与网络的链接通常是无线链接。移动部分也是一个可以单独运行的、功能完善的数据库系统。它的数据库中数据是根

据嵌入式移动应用的要求，取自主机或基站上的主数据库或数据源的数据。它所包含的同

步接口提供了与主数据库或其他数据源进行数据同步复制的功能。固定部分中所包含的同步服务器和同步协同器是完成系统数据同步的 重要的构

件，它们处理移动部分发出的数据同步请求，检测和解决同步冲突，返回同步结果。同步服

务器还具有与异构数据源链接和主动同步的功能。 同步协同器主要完成事务日志记录等

辅助的同步功能。

９．５　移动数据库系统的数据管理问题

移动数据库系统是在移动计算环境下的数据库系统。 充分发挥移动计算的强大作用

必须先解决一些软件和硬件的问题。有些软件问题源于分布式数据库系统，这些问题涉及

数据管理、事务管理以及数据库恢复等技术。 但在移动计算环境中，类似这些的问题同样

存在，而且更加难以解决，主要是由于无线通信信道带宽较窄、移动设备的电源问题，以及

所需信息来源位置的变化（有时在缓存中，有时存于服务器端）等。 除此之外，移动计算本

身还存在具体的结构问题。９．５．１　移动应用中的数据

移动计算环境使用户借助移动应用，在移动活动中仍然可以与其他用户建立联系，进行个人通信，实现移动办公，或者进行信息的实时更新等。 移动应用可以分为如下两类：

１） 垂直应用：在垂直应用中，用户在确定的信元内对数据进行操作，该信元之外的用

户无法访问数据。例如，医疗卫生行业用户可以获得其信元内医院或急救中心所处的位置

信息，出租车司机可以获得其信元所提供的停车场地信息等。２） 水平应用。在水平应用中，用户协同完成某项工作，他们对系统内分布的数据进行

操作。水平应用的市场前景非常广阔，常见的两类应用包括电子邮件应用和面向移动用户

的信息服务。移动应用具有不同的数据，大致可以归为如下三类。１） 私有数据：单个用户享有数据的所有权及使用权，其他用户无权访问。２） 公有数据：任何人都可以使用这些数据，但只有一方享有数据更新的权限，如天气

预报、股票信息等。３） 共享数据：多个用户共同享有对数据进行读写操作的权利，如公司内产品的库存

数据，某校的课程设置信息等。公有数据多用于垂直应用中，共享数据常在水平应用中使用。共享数据的拷贝可能存

储于移动节点（ｍｏｂｉｌｅ ｓ ｉｔｅ，Ｍ Ｓ）和基站中。 这给事务的一致性管理、完整性管理以及结构

的可扩充性带来难题。

·００３· 分布式数据库系统及其应用

９．５．２　移动计算环境下的数据管理问题

１．移动计算环境下的数据管理功能

　　与传统的网络环境相比较，移动计算环境具有如下不足之处：网络链接可靠性差，通信质量差，网络条件多种多样，计算节点的移动性，通信的上下行链路的通信能力不均衡，移动计算环境的可靠性差等。由于移动计算环境的这些缺点，在其中的数据库管理系统除

了具有一般数据库管理系统所具有的数据库管理功能外，还必须具有如下功能：１） 数据的同步复制功能。 保证移动设备上的数据库数据与主机数据库数据保持

一致。２） 移动事务管理功能。移动计算环境中的节点的移动性和网络通信质量差导致了移

动数据库系统中全局事务管理的复杂性。３） 故障的恢复能力。移动设备的不稳定性必然导致系统的故障率高，因此，良好的故

障恢复能力就成为移动计算环境下的数据库管理系统的必须要求。４） 系统数据的安全备分功能。 这是保证在移动计算环境下数据安全的必需。５） 微型化系统。 由于通常的移动设备中资源有限，因此数据库及其数据库管理系统

所占用的空间必须足够小。２．移动计算环境下数据的分布式管理问题

从数据管理的角度来看，移动计算可以看做是分布式计算的变形。 在下述两种情况

下，移动数据库可以看做是分布式数据库。１） 整个数据库主要分布于有线组件（固定主机和基站）当中，每个组件可能拥有全部

或部分数据库的备份。 ＢＳ 上的 ＤＢＭ Ｓ 管理自己的数据库，同时还提供附加功能，以确定

移动设备的位置，支持查询和事务管理，以满足移动环境下的应用需求。２） 数据库分布于有线和无线组件（移动节点）中，由 ＢＳ 和 Ｍ Ｓ 共同进行数据管理。因此，在考虑到以下问题时，我们在前面几章中所讨论过的分布式数据管理也可以用

于移动数据库。１） 数据的分布和复制：数据在 ＢＳ 和 Ｍ Ｓ 中的分布是不均衡的。一致性约束增加了缓

存管理的难度，缓存试图为移动设备提供被频繁访问或更新的数据。２） 事务模型：在移动环境中，事务的容错和纠错变得更为棘手。一个移动事务在几个

ＢＳ 上顺序执行，由于移动设备的移动特性，执行过程可能会涉及多个数据集合。此时缺乏

对事务执行的中央协调，尤其是在上述第二种情况时。 因此，需要对传统事务的 Ａ ＣＩＤ 性

质进行修正，定义新的事务模型。３） 复制查询处理：数据的存储位置非常重要，这影响到查询处理的性能价格比分析。

当把查询结果返回移动设备时，这些移动设备可能正处于移动当中，或者正在穿越信元边

界，但用户接收到的查询结果必须是正确、完整的。４） 恢复和容错：移动数据库环境必须解决地址错误、介质失败、事务失败以及通信失

败所导致的问题。ＭＵ 的地址错误常常是由电池电量不足引起的。如果 Ｍ Ｕ 自行关闭，这

·１０３·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

不应被视为失败。移动设备在穿越信元时常会发生事务失败。 Ｍ Ｕ 失败会影响路由算法。５） 移动数据库设计：由于移动性以及频繁的关机，可能引起信息的丢失和不一致性，

而且执行查询时全局命名解析问题变得更为复杂。 移动数据库设计必须考虑到元数据的

管理问题，例如，位置信息的更新，数据版本信息的管理等。另外，由于移动计算环境与传统的分布式环境不同，在分布式环境中选择分布式查询

策略时，必须考虑通信代价，而移动性导致了通信代价的动态变动，使得移动环境下的查

询优化变得更加复杂。 除了考虑通常意义下的通信代价外，还需要考虑金钱与能源的代

价，例如股市信息之类的发布采用广播方式要比点对点方式便宜得多。下面一些因素对通

信代价同样重要。１） 用户时间在许多商务应用中是十分重要的；２） 链接时间在某些移动系统中是决定收费的单位；３） 传输信息的字节数或包数也是计算收费的单位；４） 某些系统基于每日不同时段的收费标准也不同，通信发生在高峰时段收费高于非

高峰时段；５） 电池能源是珍贵的资源，必须优化使用，注意接收信息的能耗要比发送信息的能

耗要少。

９．６　移动数据库系统实现技术和应用研究

移动数据库系统的实现技术主要包括：数据的同步复制、移动事务管理，以及数据库

系统的微型化。９．６．１　移动数据库数据的同步复制

数据的同步复制是移动数据库管理系统的 重要的功能之一。通过数据同步，移动数

据库管理系统可以完成移动节点数据库与中心节点数据库之间的数据交换，并提交移动

事务，检测移动节点数据的合法性等。１．数据同步复制的内容

数据同步包含的内容很多，不仅仅是数据的传递，还包括：１） 数据复制的冲突检测和冲突解决；２） 同步过程中事务原子性的保证，以便保持数据库的完整性和一致性；３） 主动同步的实现；４） 与异构数据源同步，以及与异构数据源之间数据类型的转换；５） 数据的快速复制等。２．数据同步复制的冲突

移动设备上的嵌入式数据库在与主数据库进行同步时，在数据完整性上可能发生的

数据冲突事件的类型主要有：

·２０３· 分布式数据库系统及其应用

１） 在对移动设备上的嵌入式数据库在进行 ＩＮＳＥＲＴ 操作时，违反主关键字约束。２） 在对移动设备上的嵌入式数据库在进行 Ｕ ＰＤＡ ＴＥ 操作时，违反主关键字约束。３） 在对移动设备上的嵌入式数据库在进行 Ｕ ＰＤＡＴ Ｅ 操作时，使用了一个不存在的

主关键字。４） 在对移动设备上的嵌入式数据库在进行 Ｕ ＰＤＡＴ Ｅ 操作时，Ｕ ＰＤＡ Ｔ Ｅ 操作中的

旧值与主数据库中的当前值不匹配。５） 在对移动设备上的嵌入式数据库在进行 ＤＥＬＥＴ Ｅ 操作时，ＤＥＬＥＴＥ 操作中的旧

值与主数据库中的当前值不匹配。用户可以通过指定以主数据库数据为主，或以移动设备上的嵌入式数据库数据为主，

来解决主数据库与嵌入式数据库两者之间在数据同步过程中的冲突。 如果用户指定以主

数据库数据为主，则当发生同步数据冲突时，系统将根据主数据库数据来更新移动设备上

数据库中的数据，而主数据库中的数据不做改动；反之，如果用户指定以嵌入式数据库数

据为主，则系统将根据嵌入式数据库中的数据来更新主数据库中的数据，而嵌入式数据库

中的数据不做改动。当用户需要进一步对同步冲突进行更为灵活的、更符合特定业务规则

的解决时，可以通过应用编程来实现。３．数据同步复制的方法研究

传统的数据复制技术主要包括冲突的检测和解决技术、快速刷新技术、缓存（Ｃａｃｈｅ）技术等。对于移动计算环境来说，除了传统的复制技术外，由于其网络链接不稳定的特点，还必须使用一些特殊的方法。近年来，在移动数据库的数据同步方面已经做了许多研究工

作，归纳起来大致有：（１） 两层复制

一些早期的研究给出了数据复制的模型。 移动设备上的嵌入式数据库是数据复制对

象的集合，数据的主副本在称为主对象所在的主节点上的数据库中。这个模型采用两层的

复制模式，一层在移动节点上，另一层在主节点上。 在移动节点这一层上操作的所有事务

被认为是暂时的，必须在移动设备链接到主节点时，通过一个可以接受的认证，应用到主

对象和第二层上，而且在移动设备上的所有事务都必须在主节点上进行提交。（２） 文档复制

复制的数据是整个数据文档的一个本地拷贝，当两个数据文档链接后，需要进行数据

更新协调。数据更新协调是通过回滚这两个链接文档的所有的数据更新，并按时间戳顺序

重做所有的数据更新，包括冲突检测和冲突解决。这种方式要求应用指定数据更新时冲突

的检测和解决方法。（３） 依靠应用系统的语义来进行协调

这是通过分割数据对象来实现的。设计者把应用所涉及的复杂而庞大的数据对象，按语义分割成较小的片段。当服务者接收到一个移动设备的请求时，就把与这个请求有关的

片段复制，以满足该请求对数据的需要，这样移动设备就可以对接收到的片段进行离线的

操作。另外，还有一种称为“影子跟踪”。 主数据库的影子（ｓｈ ａｄｏｗ ）记录了上次同步时主数

·３０３·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

据库的状态，移动设备上的影子记录了其上的子集数据库上次同步的状态。当将子集的变

化同步到主数据库时，比较影子和子集数据库，创建包含更改信息的日志。 然后链接时将

日志转入主节点，并根据其内容更改主数据库和它的影子。但是这种方法将移动设备上的

数据库扩大了一倍，在嵌入式移动设备上是不可取的。以上这些研究工作的重点是如何避免数据同步冲突，实际上，数据同步冲突是无法完

全避免的。 并且，在移动数据库的具体应用中，冲突解决还需要满足一定的业务规则。 为

此，有人提出将主动数据库系统的主动服务机制 ＥＣＡ （ｅｖｅｎｔ ｃｏｎｄｉｔ ｉｏｎ ａｃｔｉｏｎ）规则和软

件的主动性技术应用到移动数据库系统中，提供更加灵活的数据同步冲突解决策略。９．６．２　移动数据库数据的移动事务管理

如何对移动事务进行管理，是移动数据库管理的另一个重要研究课题。移动事务进行

管理的方法也很多，目前比较有效的有：１．基于事务代理技术的移动事务管理

在一些已经推出的移动数据库产品中，采用了事务代理这种方法。 例如 Ｏｒａｃｌｅ 公司

推出的 Ｍ ｏｂｉｌｅ Ａｇｅｎｔ 就是一种支持移动数据库访问主数据库的事务代理，移动用户通过

“客户机／Ｍｏｂｉｌｅ Ａｇｅｎｔ／服务器”的结构访问主数据库。 移动用户启动事务时通知 Ｍ ｏｂｉｌｅＡ ｇｅｎｔ ，由 Ｍ ｏｂｉｌｅ Ａｇｅｎｔ 完成移动用户的事务，并返回事务执行的结果。 采用这种方法可

以使移动设备不用随时链接服务器，有效地减少了通信时间。２．基于移动事务局部化技术和数据复制技术的事务管理

与基于事务代理技术方法不同，Ｓｙｂａｓｅ 公司采用的是另外一种基于移动事务局部化

技术和数据复制技术的事务管理机制。 在 Ｓｙｂａｓｅ 的嵌入式数据库产品 ＡＳＡ （ａｄａｐｔｉｖ ｅｓｅｒｖ ｅｒ ａｎｙｗ ｈｅｒｅ）中，所有的数据库事务都是在嵌入式设备上完成，并在需要时把已经完

成的局部事务向主节点上数据库提交。Ａ ＳＡ 采用的方法也是目前大多数已经推出的移动

和嵌入式数据库系统采用的方法，例如，ＩＢＭ 公司的 ＤＢ２ Ｅｖｅｒｙｗ ｈｅｒｅ。 这种基于数据复

制的局部化事务的方法不需要进行复杂的移动事务控制，适合目前大多数的移动应用

系统。我国东北大学的 ＯｐｅｎＢＡ ＳＥ Ｍ ｉｎｉ也采用了对移动事务进行局部化并结合数据同步

复制的方法，实现了对移动节点事务的管理功能。 在这个系统中，移动节点上的所有事务

都是在移动节点内完成。利用数据同步系统，移动节点可以在需要时把已经完成的局部事务向主节点上数据

库提交，由于使用了事务日志，在对移动节点做局部事务提交时，只需要对上次提交以来

的事务进行提交。主数据库同样使用了事务日志，因此，当移动节点需要更新数据时，也只

需要获得主数据库上一次提交以来的变化数据。这样就可以大大减少数据的通信量，加速

数据交换的过程。移动节点事务的局部化避免了全局事务，在传统的真正分布式数据库系统中，有局部

事务和全局事务之分。全局事务需要各个节点（站点）的协调才能完成，事务涉及的任何一

·４０３· 分布式数据库系统及其应用

个节点有错误都会使该全局事务执行失败。对于移动计算环境来说，由于其各个节点的移

动性和通信质量的影响，使得任何一个全局事务都具有较高的失败率。 而且，对移动计算

环境来说，全局事务需要比传统的分布式环境更加复杂的控制和协调。 因此，采用基于移

动事务局部化技术和数据复制技术的移动事务管理具有一定的实际意义。９．６．３　移动数据库系统的微型化

微型化技术是实现移动系统的一项重要技术。从目前的应用趋势来看，移动节点使用

的设备都趋于小型化，ＨＰＣ，ＰＤＡ 和智能手机等灵活而小巧的移动设备取代了笔记本电

脑，成为移动计算环境下新的硬件平台。 而这些设备通常具有的资源都非常有限，尤其是

存储空间更加有限。 例如，通常情况下只有几兆到十几兆，这与桌面系统动辄几千兆的存

储空间和几十兆的内存空间有天壤之别。 因此移动数据库的微型化就成为实现移动数据

库管理系统的关键。移动数据库系统的微型化主要包括两个方面内容：１） 移动数据库的微型化；２） 数据库管理系统的微型化。１．移动数据库微型化

移动数据库的微型化目前主要采用的就是根据应用对数据库的模式进行分解。此外，数据的压缩存储也是节省数据存储空间的一种有效方法。

对数据库的模式进行分解是对数据库模式进行优化的常用方法。 模式分解分为模式

的水平分解、模式的垂直分解和模式的混合分解。 所谓混合分解是先水平分解，再垂直分

解或先垂直分解，再水平分解。模式的水平分解是根据条件把关系中的元组分成若干子集合，每个子集合定义为关

系的一个片段。 在某个移动设备上，经常使用的数据只是一个关系中的某个或某些片段。因此，可以采用模式的水平分解方法把经常使用的数据分解出来，形成一个子关系，这样

可以有效地减少数据的存储量，从而达到移动设备上的嵌入式数据库的微型化。模式的垂直分解是把一个关系中经常使用的属性分解出来，形成一个独立的子关系

（片段）。模式的垂直分解同样可以有效地减少数据的存储量，提高事务的执行效率。但是，如何保证模式垂直分解后的关系片段集合（子模式集合）与原关系模式等价是一个问题。检验垂直分解后获得的子模式集合与原模式是否等价的原则，就是检验子模式集合是否

具有无损链接和保持函数依赖性。２．数据库管理系统的微型化

对于数据库管理系统的微型化使用的主要方法是以功能换空间的策略，如去掉一些

应用不需要的数据库管理系统功能来减少系统的大小。 目前的移动数据库产品使用的系

统精简技术中，Ｓｙｂａｓｅ 公司的 Ｕ ｌｔｒａｌｉｔｅ 技术 具特色。 所谓 Ｕ ｌｔｒａｌｉｔｅ 技术实际上就是一

种数据库和数据库系统的精简技术。 Ｕ ｌｔ ｒａｌｉｔｅ 技术的核心是一个被称为 Ｕ ｌｔｒａｌｉｔｅ 分析器

的工具，通过这个工具，数据库系统可以分析出一个特定的应用系统需要哪些数据库管理

·５０３·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

系统的功能，并能根据实际需要对中心数据库的模式进行精简，并把精简后的数据库系统

和应用一起传递到移动设备上，建立更为精简的移动应用系统。

９．７　间歇同步移动数据库

近年来，人们逐渐开始通过移动办公进行事务处理，这些事务包括：销售，特别是消费

产品、工业部件等；法律实施；保险、财务咨询和计划、房地产及财产的管理行为等。一个新

的应用领域逐渐发展起来。 在这类应用中，由一个或一组服务器对中央数据库进行管理，大部分时间用户利用具有 ＤＢＭ Ｓ 软件的便携式电脑或掌上电脑进行各种操作。客户通过

网络或拨号上网，甚至是无线链接方式，与服务器链接，通常是短会话，比如 ３０ 或 ６０ 分

钟。 客户把更新发送给服务器，服务器随之将更新输入中央数据库，中央数据库必须保证

数据的实时更新，为系统的所有客户机提供适当的数据拷贝。因此只要客户机和服务器进

行链接，数据更新就被输入本地数据库。这类应用的 显著特征是客户机经常处于断开状

态，服务器并不能总是和客户机保持通信。 这就遇到了与分布式数据库和客户机／服务器

数据库类似的问题，但也产生一些新问题。我们将这一应用领域称为间歇同步数据库环境

（ｉｎｔ ｅｒｍ ｉｔ ｔｅｎｔｌｙ ｓｙｎｃｈｒｏｎｉｚｅｄ ｄａｔ ａｂａｓｅ ｅｎｖ ｉｒｏｍｅｎｔ ，ＩＳＤＢＥ），相应的数据库称做间歇同步

数据库（ｉｎｔｅｒｍ ｉｔｔ ｅｎｔｌｙ ｓｙｎｃｈｒｏｎｉｚｅｄ ｄａｔａｂａｓｅ，ＩＳＤＢ）。ＩＳＤＢ 的以下特性使其区别于以上讨论过的移动数据库。１） 客户机获取服务器上的更新数据或将更新发送给服务器时，或者事务处理需要非

本地数据时，客户机和服务器才进行链接。 这样的通信可以是单点传送方式（ｕｎ ｉｃａｓｔ ），服务器和客户机之间一对一通信；也可以是多点传送方式（ｍｕｌｔｉｃａｓｔ ），发送者周期性地和一

组接收者进行通信，或服务器周期性对一组客户机进行更新。２） 服务器不能随意和客户机进行链接。３） 链接是无线链接还是有线链接，以及电源的问题并不重要。４） 客户机处于断开状态时，仍然可以方便地管理自己的数据和事务，在某种程度上

也可自行进行恢复操作。５） 客户机和服务器的链接方式是多种的，在多个服务器的情况下，基于临近原则、通

信节点的状态等，客户机可选择与特定服务器进行链接。由于存在以上区别，有必要对 ＩＳＤＢ 进行进一步研究，包括服务器数据库设计，客户

机和服务器数据库事务处理，以及升级处理的一致性管理，服务器带宽的有效使用，ＩＳＤＢ环境下的可扩充性等。

９．８　本 章 小 结

ＷＷＷ 数据库系统和移动数据库系统与分布式数据库系统有着极其紧密的关系。 它

们虽然不是真正意义上的分布式数据库系统，但是，它们所基于的客户机／服务器体系结

构，数据的物理分布性，以及通过计算机网络访问和操作远程站点上的数据，表明它们与

分布式数据库系统有着极其紧密的关系，它们是一种特定的分布式数据库系统。随着网络

·６０３· 分布式数据库系统及其应用

技术、移动通信技术和微处理器技术的发展，很多成熟的分布式数据库技术将是支持

ＷＷＷ 数据库和移动数据库的基本技术；同样，它们也会影响分布式数据库系统，使得将

分布式数据库技术的研究和应用扩展到 ＷＷＷ 和移动数据处理领域，给分布式数据库技

术的研究和发展带来了极好的机会。可以预见，把整个 Ｉｎｔ ｅｒｎｅｔ 变为一个巨大的、可移动、异构的分布式数据库系统已经不再是幻想。

ＷＷＷ 数据库系统是指在 ＷＷＷ 环境下运行的数据库系统。 它将 Ｗｅｂ 技术与分布

式数据库技术有机结合，同时具有超文本功能和数据库功能。 Ｗｅｂ 上的信息存放在借助

ＨＴ Ｍ Ｌ 开发的 Ｗｅｂ 页面中，一个 Ｗｅｂ 网页是文本、图像、声音、图形、视频等形式的集

合，ＵＲＬ 把网络上的信息有效地组织在一起。 ＷＷＷ 数据库系统是一种异构异质的计算

环境，与这一环境相适应，ＷＷＷ 数据库系统采用 ＷＷＷ 浏览器／Ｗｅｂ 服务器／数据库服

务器组成的三层客户机／服务器结构，Ｗｅｂ 服务器层的作用是集成、转换多个数据源的数

据。创建 Ｗｅｂ 上数据库时应当考虑网络环境的影响。由于ＷＷＷ 数据库的数据不具透明

性，这与真正意义上的分布式数据库系统有本质区别，所以用户需要建立或选定数据源后

才能访问数据库，常用的 ＷＷＷ 数据访问接口是 ＯＤＢＣ 与 ＪＤＢＣ。 虽然 ＷＷＷ 数据库技

术以惊人的速度发展，但仍面临着很多挑战：信息建模以及检索问题，数据库操作的可靠

性问题，数据库的安全性和一致性问题，从目前数据库的应用环境向 Ｗｅｂ 环境迁移问题，在处理系统间的数据迁移时的不一致性问题等。另外，为支持基于 Ｗｅｂ 的应用，也必须对

传统的数据库查询及事务处理功能进行适当的改进。移动数据库系统是移动计算环境下的数据库系统。 移动计算环境与真正的分布式数

据库系统环境不同，后者是建立在持久的网络连接和固定节点环境下的。 近年来，随着网

络技术、移动通信技术和微处理器技术的发展，以及移动设备的广泛应用，移动计算环境

逐渐成为数据库技术新的研究和应用环境，移动数据库系统也就应运而生。移动计算环境

促进了无线技术与数据库应用的融合，移动数据库技术已经在许多领域中获得了巨大的

成功，并涌现出了许多令人耳目一新的实用系统。移动数据库系统由运行在移动设备上的

移动部分（客户机）和运行在通过高速有线网络互联的 ＦＳ 或 ＢＳ 上的固定部分（服务器）两部分组成，嵌入式移动设备与网络的连接通常是无线连接。这种计算环境比传统的网络

计算环境更为复杂和灵活。 计算平台的移动性、连接的频繁断／接性、网络条件的多样性、网络通信的非对称性、系统的高伸缩性和低可靠性，以及电源能力的有限性等因素，使得

研究和开发移动计算环境下的数据库技术面临许多新的特点和困难。从本质上讲，移动数

据库技术是一种支持移动计算环境的分布式数据库技术，涉及网络通信技术、硬件技术、数据库技术等多学科技术，具有很高的研究起点。 正因为上述的种种复杂性，方兴未艾的

嵌入式移动数据库技术的研究工作尚处于起步阶段。 许多关键性的技术如移动计算环境

下的同步复制技术、移动事务管理技术、系统微型化技术和查询优化处理策略等都有待进

一步的研究。另一个新的应用领域——间歇同步移动数据库环境及其相应的间歇同步数据库也逐

渐发展起来，对于它的研究也正在进一步展开。

·７０３·第九章　分布式数据库与 ＷＷＷ 数据库和移动数据库

习　　题

９．１　给出 ＷＷＷ 数据库系统与真正分布式数据库系统相同和不同的主要特征。９．２　给出移动数据库系统与真正分布式数据库系统相同和不同的主要特征。９．３　给出移动数据库系统与间歇同步移动数据库系统相同和不同的主要特征。９．４　简述 ＷＷＷ 数据库系统的体系结构，Ｗｅｂ 浏览器和 Ｗｅｂ 服务器的主要功能。９．５　简单阐述用户应用与 ＷＷＷ 数据库的接口方式。９．６　什么是移动计算环境？说明：固定主机、基站、移动单元、信元、上行链路、下行链

路的主要功能。９．７　用你自己的语言描述 ＷＷＷ 数据库系统是一种什么样的系统。９．８　用你自己的语言描述移动数据库系统是一种什么样的系统。９．９　简要说明移动数据库系统的数据同步复制、移动事务管理和系统微型化三种主

要的实现技术。９．１０　简要说明移动计算环境下数据管理的主要问题。

·８０３· 分布式数据库系统及其应用

第十章　分布式数据库系统的发展趋势

在前面的章节中，所说的分布式数据库系统技术是基于如下三点假定：其一，网络中

的每个站点都是既运行应用程序，又实现分布式数据库管理功能的通用计算机。 其二，网络中既有广域网也有局域网。其三，数据库管理是基于关系模型的。 这些假定对于大多数

分布式数据库是合适的。 但是，新的应用需求导致计算机体系结构和数据库技术的发展，对于分布式数据库 明显的影响是高性能工作站和并行计算机的应用，以及与面向对象

技术的结合，酝酿着分布式数据库系统发展的新趋势，从而需要适当改变上述的假定。对第一个假定的改变是使每个站点上的计算机可以不是通用计算机，而是专用工作

站或服务器。 为了增强系统性能，数据服务器可以是一台并行计算机，以利用并行处理性

的优势来进行数据库管理。 对第二个假定的改变是在并行数据服务器中利用分布式数据

库技术。 数据库技术的发展推进了对于新应用领域的支持。 特别是关系数据库技术不断

改进，成功地支持了商务数据处理的应用。 然而，现在又有一类新的应用对于数据库管理

提出新的挑战，例如，计算机辅助设计（ＣＡＤ）、办公信息系统（ＯＩＳ）、人工智能（ＡＩ）。 这些

应用领域需要多方面性能的改进：知识性、主动性、面向对象概念以及对象关系数据模

型。这样，对第三个假定的改变产生了新的研究领域：分布式知识库、分布式对象数据库和

分布式对象关系数据库。分布式数据库技术新的发展趋势向数据库研究提出了新课题。 在这章中将介绍上述

每一种新趋势及其面临的新问题，同时讨论可能解决的方法，当然这些研究还是非常不成

熟的。

１０．１　并行数据服务器与分布式数据库系统

本节将展现并行体系结构的计算机如何有效地应用于分布式数据管理，从而建成并

行数据服务器。 着重讨论利用并行数据服务器体系结构的哪一类结构实现分布式数据库

系统，以及讨论这种结构的关键问题是数据库定位策略和数据库操作的并行算法。１０．１．１　并行数据服务器体系结构

１．单处理器结构的局限性

　　计算机硬件的发展对数据服务器体系结构有很大影响。 早计算机主要用于进行有

效的数学运算，其体系结构为单处理器结构的冯· 诺依曼计算机。由于其 大性能的发挥

受到其顺序运算结构的限制，使这种结构不适合于数据库管理。 这有如下两个原因：１） 它不能发挥在很多应用中存在的内在可并行处理的特性。关系操作提供了多种并

行处理的机会，例如，连接查询中的多个子查询可并行处理，单个查询中的多步操作也有

可能并行执行，内部操作可以分为几个子操作并行执行等。２） 在冯· 诺依曼计算机中，数据库管理性能受到 Ｉ／Ｏ 瓶颈的很大影响。例如，受到比

内存存取速度慢 １ ０００倍的硬盘速度的制约。 一个直接而又简单的解决 Ｉ／Ｏ 瓶颈的办法

是将整个数据库保存在稳定的内存中，这就可以完全排除 Ｉ／Ｏ 瓶颈。 但是，保存整个数据

库在主存中的高成本使这个方案不适用于大型数据库，对中、大型数据库还是应该存放在

磁盘中。所有的技术预测显示，硬盘将继续作为中、大型数据库存储器的主要选择。对Ｉ／Ｏ瓶颈问题的解决途径是通过提高磁盘存取的并行性增加其带宽。 整个数据库不再只存放

在一个或少数几个高容量的磁盘上，将使用可并行存取的很多个小磁盘，以实现磁盘并行

存取。 这样，磁盘的存取时间就可按磁盘个数成倍减少。

图 １０．１　完全共享资源系统结构

２．多处理机结构的两种极端情况

解决这些问题的一个通用办法是使用多处理机结构。 多处理机结构是通过高速通信

介质连接的多个可独立处理的单元构成，各个独立处理单元都可独立执行各种查询、操作

或子操作，管理独立的磁盘和支持磁盘的并行存取。一个多处理器系统可以自然地通过分

配查询、操作和子操作到不同的处理单元，从而以并行执行方式完成互联查询、内部查询

和各种内部操作。多处理机的体系结构按其资源的共享性可分为很多种，其中存在两种极端情况，即完

全共享资源结构（简称全共享结构）和完全不共享资源结构（简称全不共享结构或独占结

构）。下面将讨论这两种结构，重点是完全不共享资源结构，因为这种结构更依赖于分布式

数据库技术。在完全共享资源结构中，如图 １０．１ 所示，所有的处理器通过高速通信线路访问每一

主存模块或磁盘单元。一个紧耦合的多处理机系统是一个完全共享资源结构的特殊例子。由于对数据项的每次简单存取都要经过公共通信线路，这种结构会因为争夺通信总线而

引起通信瓶颈。解决这个问题的办法是限定高功能处理机的数量。一般来说，由于元信息

（目录）和控制信息（如锁表）可以被所有处理机共享，所以在这种机器上编写应用软件，如

·０１３· 分布式数据库系统及其应用

数据库管理系统，与在冯· 诺曼计算机上编写没有什么太大差别。完全共享结构与集中式

ＤＢＭ Ｓ 的主要不同在于其数据库的操作可以并行处理，可以为数据库管理提供较高

性能。在完全不共享结构中，每一个处理器对一个或多个内存处理模块或磁盘单元，只能进

行互斥访问。 一个典型的全不共享结构如图 １０．２所示。 每一个站点包括一个处理机，一个本地高速缓存（ｃａｃｈｅ ｍｅｍｏｒｙ），和一个磁盘单元以及本地内存。 无盘站点可以用于与

应用服务器接口或处理中间结果。不共享资源的概念指的是站点之间不共享主存和／或磁

盘，唯一的共享资源是网络，站点间通过网络交换信息。

图 １０．２　完全不共享资源系统结构

３．完全不共享结构与分布式数据库系统

一个基于开关线路的多处理器系统是一个完全不共享结构的特例。 完全不共享结构

也可以看成是实现分布式数据库系统的特殊例子，其目的在于高功能计算机系统可以由

几个较小和功能较弱的计算机系统代替。 这种方法与分布式数据库相似之处在于每一个

站点可以由相同的局部系统管理；每一个站点都要设法实现全局数据目录，分布数据定义

和控制，分布查询处理和分布事务管理。 与分布式数据库系统的主要不同在于，多处理机

站点不能运行用户应用程序，应用程序是运行在应用服务器上的，应用服务器通过特定的

网络和多处理机系统相连。完全不共享结构比其他结构更能到达两个重要的目标：分布式数据库性能和可扩展

性。通过高速互联总线和并行处理，可以增强性能，即提高吞吐率，吞吐率可以每秒处理联

机事务的个数来度量。由于这指标与数据的分片站点个数成线性关系，数据分片站点个数

增加一倍将导致吞吐率增加一倍。 这一性能的改进可以通过采用如下两个方案得到。 第

一，数据应该被精心地分片和定位于多个站点上，这样在处理分布式查询时可以达到 大

程度的并行性。 第二，分布式数据管理应该利用分布式数据库操作系统有效地进行支持。

·１１３·第十章　分布式数据库系统的发展趋势

可扩展性是指当增加新站点时能平滑地扩展系统。与同构分布式数据库系统类似，由于完全不共享结构中的各个成员也是一致的，不管它们的规模大小，都可采用同样的数据

库管理系统来管理。１０．１．２　并行数据服务器数据定位

１．与分布式数据库系统的相似性

　　在一个高速并行化的完全不共享数据服务器体系结构中，其数据定位与分布式数据

库中的数据片段的定位具有相似性。 一个相似性是数据分片可以用于增加并行性和负载

平衡，所谓负 载平衡即负 载等同 地分布 到所 有的站 点上。 在下 面，我们用 “分 簇

（ｄｅｃｌｕ ｓｔｅｒ ｉｎｇ）”的概念替代数据的水平分片；与其相对的操作，即在一个站点上将关系的

片段聚集起来，称为“聚簇（ｃｌｕｓｔ ｅｒ ｉｎｇ）”。 同样，关系的垂直分片也可以增加并行性和有利

于负载平衡。另一个相似性在于，由于数据比程序大得多，程序应该尽可能地在数据存储的站点上

运行。 因此，数据的定位策略会影响系统的性能，数据定位策略的目标应该是 大限度地

保证系统的性能，即使系统完成一个操作所花的代价 小而响应时间 快。 例如，对分片

后的关系进行内查询的并行处理和进行互查询的并行处理时，要考虑因分片而造成的额

外通信开销。为了减少通信量，有必要时，可对程序所需的数据片段进行聚簇。所以，对于

数据的定位策略要根据具体情况确定。 一般来说，如果要提高响应速度和内查询并行度，则进行分簇；如果要进行综合查询或减少系统总体运行代价，则要进行聚簇。 在分布式数

据库系统中，这种情况由数据库管理员根据对片段的使用情况检测，进行调整，包括移动

片段和重组。２．与分布式数据库系统的区别

并行数据处理服务器的系统与分布式数据库系统方案有三个重要的不同。（１） 应用目标不同

在并行数据处理服务器的系统中，由于用户并不是专门使用某个特定的站点，所以没

有必要苛求 大程度的本地性处理。（２） 实现方式不同

在并行数据处理服务器的系统中，为了充分利用各个站点上的各种资源，各站点间采

用高速网络互联（传输速率可达 １００Ｍ ｂ／ｓ 以上），站点间数据传输代价相对较低。 因此站

点间的工作负载可以通过高速网络互相调节，从而实现整个系统的负载平衡。 但是，站点

数量越大，负载平衡实现越困难，主要的问题是要避免影响整个系统的资源争夺。 如果程

序在数据所在地运行，就可使用本地资源，所以数据分布也就涉及性能的问题。（３） 各站点的地位不同

在并行数据处理服务器的系统中，不存在全局应用和局部应用的概念。各个站点是完

全不独立的，在数据处理中，它们只能发挥协同作用，而无局部应用。

·２１３· 分布式数据库系统及其应用

３．数据定位的策略

数据定位的一种策略是“全分簇”，即将关系进行水平分片，把片段分布到系统中所有

有磁盘的站点上。为了确保数据分布的均匀性，可以通过关系的某个属性采用散列算法分

片。这种策略允许在处理一个查询时，与选择属性精确匹配的子查询得以在一个站点上处

理，而所有其他子查询在其他站点上得以并行处理。 实践可得，对于大范围多用户工作负

载，全分簇方法的性能 好。但是，在处理复杂查询（如包含多个连接）时，聚簇方法具有显

著优势。尽管全分簇有明显的性能优势，但在复杂查询包括多个连接时，高度并行执行会引起

一系列的性能开销。 例如，在一个有 １０２４ 站点的结构中，完成一个无选择的二元连接，坏情况时，消息传递数量将达到 １０２４２。 因此，在执行复杂查询时，应采用聚簇方式处理。此外，全分簇方法不适合只占几个磁盘块的小关系。这些缺点表明需要在聚簇和全分簇之

间找到一个折衷的方法，这种方法就是“可变分簇（ｖａｒｉａｂｌｅ ｄｅｃｌｕｓｔ ｅｒ ｉｎｇ）”。可变分簇方法是依据“分簇度”对关系进行分片，换句话说，分簇度是关系数据分片的

站点数量，它是关系大小和存取频率的函数。 这种方法比聚簇和分簇方法更显复杂，因为

数据分布的改变可能导致结构重整。 例如，初始分布在 ８个站点上的一个关系，如果由于

插入新元组而使关系的元组数量增加一倍，在这种情况下，它应该被分布在 １６个站点上。在一个采用可变分簇的高并行系统中，如果负载是动态变化的，或者更新操作较多，

为了负载均衡，需要频繁地进行结构重整。这种重整应该对运行在数据服务器上的已编译

的程序保持透明。 为了实现这种独立性，对分布式数据查询可采用关联查询（ａｓｓｏｃｉａｔｉｖ ｅａｃｃｅｓｓ）。 这与传统分布式数据库系统所采用的方法不同，传统方法的关联存取是由查询

处理器在编译时利用数据目录完成的；在并行系统中，关联存取的一个解决方案是把“全局索引”复制到每一个站点上。全局索引确定了关系在各个站点的分布情况。从概念上说，全局索引是一个两级索引。一级为关于关系名的“主聚簇”，另一级为关于关系中某些属性

的“次聚簇”。这个全局索引支持可变分簇，每个关系有不同的分簇等级。 这个索引结构可

以基于散列法或 Ｂ 树实现。 这样，对于精确匹配查询可以只在单个站点上处理；但是，对于范围查询，使用散列法，要访问所有包含查询关系数据的所有站点；而使用 Ｂ 树索引

（通常远多于散列索引）能更有效地处理范围查询，因为只访问那些包含指定数据的站点。例 １０．１　图 １０．３ 提供了工程数据库的全局索引的例子。 这个数据库由下列关系

组成：　Ｅ （ＥＮＯ ，ＥＮＡＭ Ｅ，ＤＥＰＴ ，Ｔ ＩＴ ＬＥ）　Ｓ （Ｔ ＩＴ ＬＥ，ＳＡＬ ）　Ｊ （ＪＮ Ｏ，ＪＮＡＭ Ｅ，ＢＵ ＤＧＥＴ ）　Ｇ （ＥＮＯ ，ＪＮ Ｏ，ＲＥＳＰ ，ＤＵＲ）假设我们希望通过 ＥＮＯ＝“Ｅ５”来定位在关系 Ｅ 中的元组。 第一级关于关系名索引

映射名字“Ｅ”到关系 Ｅ 的 ＥＮＯ 属性的索引上。接着第二级关于属性的索引进一步映射值

“Ｅ５”到站点 ｊ。每个站点的本地索引也必须映射一个关系到站点的一组磁盘块上。本地索

引也分两级，即关于关系名的主簇和若干关系属性的次簇。本地索引的次簇属性是和全局

·３１３·第十章　分布式数据库系统的发展趋势

索引的次簇属性相同。这样基于（关系名，簇）的相关路径从一个站点到另一个站点不断得

到改进。图 １０．４对图 １０．３的同一个站点 ｊ提供了本地索引的一个例子。第一级关系名索

引映射名字 Ｅ 到关系 Ｅ 的属性 ＥＮＯ 的索引上，正像为全局索引所做的那样。第二级索引

进一步映射蔟值“Ｅ５”到 ９１ 号磁盘块上。

图 １０．３　全局索引例子

图 １０．４　在站点 ｊ 上的本地索引例子

Ｃｏｐｅｌａｎｄ 等提供了由短事务组成的工作负载的可变分簇的实验结果。这个结果表明

当分簇数量被增加时，系统的短事务的吞吐量也持续地增加。 但是，对于包括几个连接的

复杂事务时，太细的分簇反而由于通信开销而降低了吞吐量。

·４１３· 分布式数据库系统及其应用

１０．１．３　并行操作处理的算法

分簇方式的数据分布是数据库查询进行并行处理的基础。 在一个采用分簇数据分布

的系统中，一个重要的议题是并行算法，为了有效地执行数据库操作（如关系代数操作）和由这些操作组成的数据库查询，就要给出一个合适的并行算法。 由于既要达到并行性，又要降低通信成本，并行算法因要妥善处理这对矛盾而变得困难。因为关系代数操作的并行

操作是通过建立必要的并行查询处理子模块来实现。因此，在这一小节中首先介绍并行操

作处理的算法，在下一小节中介绍并行查询处理的算法。１．并行操作处理

并行操作处理主要利用关系操作内部的并行性。为便于讨论，集中介绍数据库操作的

ＳＥＬＥＣＴ 和 ＪＯ ＩＮ 的并行算法，因为所有其他的二元操作（如 ＵＮＩＯＮ ）都类似于 ＪＯＩＮ 的

处理。 在一个分簇数据分布的数据库中，对 ＳＥＬＥＣＴ 操作的处理与分片的分布式数据库

是一样的，依赖于 ＳＥＬＥＣＴ 谓词，操作可以在单一站点上执行（在精确匹配谓词的情况

下），或者对任意复杂谓词，在关系分簇所在的所有站点上执行。如果全局索引采用类似 Ｂ树结构进行组织，则对带有范围谓词的 ＳＥＬＥＣＴ 操作只在存储相关数据的站点上执行。

ＪＯＩＮ 的并行处理比 ＳＥＬＥＣＴ 更加复杂。 采用高速网络环境的分布式 ＪＯＩＮ 算法，可成功地在分簇数据库中应用。 此外，在系统运行时，利用全局索引可有效地并行执行。 下

面将介绍三种基本的分簇数据库的并行 ＪＯＩＮ 算法：并行嵌套循环（ＰＮ Ｌ ）算法，并行关联

连接（ＰＡＪ）算法和并行散列连接（ＰＨＪ）算法。 描述算法将使用三个主要构造：ｄｏｉｎｐａｒａｌｌｅｌ，ｓｅｎｄ 和 ｒｅｃｅｉｖｅ。 ｄｏｉｎｐａｒａｌｌｅｌ 指定其后的动作块是并行执行的。 例如：

　　　ｆ ｏｒ Ｉ ｆ ｒｏｍ １ ｔｏ ｎ ｄｏ ｉｎ ｐａｒａｌｌｅｌ ａｃｔｉｏｎ Ａ表明动作 Ａ 将被 ｎ 个站点并行执行。 ｓｅｎｄ 和 ｒｅｃｅｉｖ ｅ是在站点间传输数据的基本通

信原语。 ｓｅｎｄ 使数据能从一个站点向另一个或多个站点发送，目标站点从全局索引中获

得。 ｒｅｃｅｉｖ ｅ接收发向一个特定站点的数据内容。２．并行操作处理的算法

在下面考虑的算法中，假定是对关系 Ｒ 和 Ｓ 进行连接。 Ｒ 和 Ｓ 分别被分簇到 ｍ 个和

ｎ 个站点上。 为简便起见，关系 Ｒ 的片段所在的站点称为 Ｒ 站点，同样，关系 Ｓ 的片段所

在的站点称为 Ｓ 站点。 而且假设这 ｍ 个 Ｒ 站点和这 ｎ 个 Ｓ 站点是不同的站点，连接的结

果在 Ｓ 站点上产生。算法的输入为关系 Ｒ 的片段（Ｒ １ ，Ｒ２ ，…，Ｒｍ ）、关系 Ｓ 的片段（Ｓ １ ，Ｓ ２ ，…，Ｓｎ）和连接谓

词 ＬＰ。算法的输出为在 ｎ 个 Ｓ 站点上的结果片段 Ｔ １ ，Ｔ ２ ，…，Ｔ ｎ 。（１） 并行嵌套循环算法

并行嵌套循环（ｐａｒａｌｌｅｌ ｎｅｓ ｔｅｄ ｌｏ ｏｐ，ＰＮＬ ）算法是 普通和 简便的。 它并行地按笛

卡儿乘积连接关系 Ｒ 和 Ｓ。然而，对任意复杂的 ｊｏｉｎ 谓词都可以支持。这个算法列出如下，可分为两步进行。

·５１３·第十章　分布式数据库系统的发展趋势

算法 １０．１　ＰＮ Ｌ　　　ｉｎ ｐｕｔ：　Ｒ １ ，Ｒ ２ ，…，Ｒｍ ： ｆｒａｇｍｅｎｔｓ ｏｆ ｒｅｌａｔ ｉｏｎ Ｒ；　　　　　　　Ｓ １ ，Ｓ ２ ，…，Ｓ ｎ： ｆｒａｇｍｅｎｔｓ ｏ ｆ ｒｅｌａｔ ｉｏｎ Ｓ ；　　　　　　　ＪＰ： ｊｏｉｎ ｐｒｅｄｉｃａｔｅ　　　ｏｕｔｐｕｔ ： Ｔ １ ，Ｔ ２ ，…，Ｔ ｎ： ｒｅｓｕｌｔ ｆ ｒａｇｍｅｎｔｓ　　　ｂｅｇ ｉｎ　　　　　 ｆ ｏｒ ｉ ｆｒｏｍ １ ｔ ｏ ｍ ｄｏ ｉｎ ｐａｒａｌｌｅｌ　　　　　　　　ｓｅｎ ｄ Ｒ ｉ ｔｏ ｅａｃｈ ｎｏｄｅ ｃｏｎｔａｉｎｉｎｇ ａ ｆｒａｇｍｅｎｔ ｏｆ Ｓ　　　　　 ｅｎｄ－ ｆｏ ｒ　　　　　 ｆ ｏｒ ｊ ｆｒｏｍ １ ｔ ｏ ｎ ｄｏ ｉｎ ｐａｒａｌｌｅｌ　　　　　 ｂｅｇ ｉｎ　　　　　　Ｒ ← ∪ ｉＲ ｉ ｉ＝１，２，…，ｍ ｛ ｒｅｃｅｉｖｅ Ｒ ｉ ｆｒｏｍ Ｒｎｏｄｅｓ；　　　　　　　　　　　　　 Ｒ ｉｓ ｆｕｌｌｙ ｒｅｐｌｉｃａｔｅｄ ｏｎ ｅａｃｈ ｎｏｄｅｓ ｏｆ Ｓ ｝　　　　　　Ｔ ｊ← ＪＯＩＮ （Ｒ ｉ，Ｓｊ，ＪＰ） ｛ ＪＯＩＮ ｉｓ ｇｅｎｅｒｉｃ ｆｕｎｃｔｉｏｎ ｝　　　　　 ｅｎｄ－ ｆｏ ｒ　　　ｅｎｄ．｛ＰＮ Ｌ ｝

第一步：Ｒ 的每个片段被复制，并发送到每个包含 Ｓ 片段的站点上（有 ｎ 个这样的站

点），如果通信网络具有广播功能，效率就会很高。 在这种情况下，Ｒ 的每个片段可以用广

播方式一次发送到 Ｓ 的 ｎ 个站点，全部片段发送完成的总通信成本为 ｍ 个消息报文，否则，需要（ｍ ｎ）个消息报文。

第二步：每个 Ｓ 站点 ｊ接收关系 Ｒ 的所有片段，而且在本地完成 Ｓｊ 与 Ｒ 的局部连接，对此，ｎ 个站点可并行执行。局部连接可以由集中式的 ＤＢＭ Ｓ 完成。根据不同的局部连接

算法，连接处理可以在数据一收到时就开始，或者等到数据全部接收到后再进行。 在第一

种情况（例如采用嵌套循环连接算法），连接处理可以在 Ｒ 元组一到达就开始。 在第二种

情况（例如采用排序合并连接算法），已经排序的关系的连接必须在所有的数据都收齐后

才能开始。总之，并行嵌套循环算法可以看成把操作 Ｒ ∞ Ｓ 换成：∪ ｊ（Ｒ ｉ∞Ｓｊ）ｉ＝１，２，…，ｎ例 １０．２　图 １０．５显示了并行嵌套循环算法的应用，假定 ｍ＝ｎ＝２。（２） 并行关联连接算法

并行关联连接（ｐａｒａｌｌｅｌ ａｓｓｏ ｃｉａｔｉｖ ｅ ｊｏ ｉｎ，ＰＡＪ）算法，如算法 １０．２所示。 ＰＡＪ 算法适用

于等值连接情况，而且连接属性是分簇属性。 为了简化算法的描述，假设Ｒ．Ａ＝Ｓ．Ｂ，此外，关系 Ｓ 已经在连接属性 Ｂ 上使用散列函数 ｈ（Ｂ）分簇。 并行关联连接算法将使用 Ｒ 分

簇与 Ｓ 分簇的局部连接来完成 Ｒ 和 Ｓ 的连接，在 Ｓ 站点生成连接结果分簇。算法 １０．２　ＰＡ Ｊ　　　　　ｉｎ ｐｕｔ ：　Ｒ １ ，Ｒ ２ ，…，Ｒｍ ： ｆｒａｇｍｅｎｔｓ ｏｆ ｒｅｌａｔ ｉｏｎ Ｒ；　　　　　　　　　Ｓ １ ，Ｓ ２ ，…，Ｓ ｎ： ｆｒａｇｍｅｎｔｓ ｏ ｆ ｒｅｌａｔ ｉｏｎ Ｓ ；

·６１３· 分布式数据库系统及其应用

图 １０．５　并行嵌套循环例子

　　　　　　　　　ＪＰ： ｊｏｉｎ ｐｒｅｄｉｃａｔｅ　　　　　ｏｕｔｐｕｔ： Ｔ １ ，Ｔ ２ ，…，Ｔ ｎ： ｒｅｓｕｌｔ ｆ ｒａｇｍｅｎｔｓ　　　　　ｂｅｇ ｉｎ　 ｛ ｗ ｅ ａｓｓｕｍｅ ｔｈａｔ ＪＰ ｉｓ Ｒ．Ａ＝Ｓ．Ｂ ａｎｄ ｒｅｌａｔｉｏｎ Ｓ ｉｓ ｆｒａｇｍｅｎｔｅｄ

ａｃｃｏ ｒｄｉｎｇ ｔ ｏ ｆｕｎ ｃｔｉｏｎ ｈ（Ｂ）｝　　　　　 ｆ ｏｒ ｉ ｆｒｏｍ １ ｔ ｏ ｍ ｄｏ ｉｎ ｐａｒａｌｌｅｌ ｛ｓｅｎｄ Ｒ ａｓｓｏｃｉａｔｉｖ ｅｌｙ ｔ ｏ ｅａｃｈ Ｓｎｏｄｅ｝　　　　　　　 ｂｅｇ ｉｎ　　　　　　　　　　Ｒ ｉｊ← ａｐｐｌｙ ｈ（Ａ） ｔｏ Ｒｉ　（ ｊ ＝ １，２，…，ｎ ）　　　　　　　　　　ｆ ｏｒ ｊ ｆｒｏｍ １ ｔ ｏ ｎ ｄｏ　　　　　　　　　　　　 Ｓ ｅｎｄ Ｒ ｉｊ ｔｏ ｔｈｅ ｎｏｄｅ ｓｔ ｏｒ ｉｎｇ Ｓｊ　　　　　　　　　　ｅｎｄ－ ｆｏ ｒ　　　　　　　 ｅｎｄ－ ｆｏ ｒ　　　　　　　 ｆ ｏｒ ｊ ｆｒｏｍ １ ｔ ｏ ｎ ｄｏ ｉｎ ｐａｒａｌｌｅｌ ｛ｐｅｒｆ ｏｒｍ ｔｈ ｅ ｊｏ ｉｎ ａｔ ｅａｃｈ Ｓｎｏｄｅ｝　　　　　　　 ｂｅｇ ｉｎ　　　　　　　　 Ｒ ｊ← ∪ ｉ Ｒ ｉｊ（ｉ ＝１，２，…，ｍ）｛ｒｅｃｅｉｖｅ ｏｎ ｌｙ ｔｈｅ ｕｓｅｆｕｌ ｓｕｂｓｅｔ ｏｆ Ｒ｝　　　　　　　　 Ｔ ｊ← ＪＯＩＮ （Ｒ ｊ，Ｓｊ，ＪＰ）　　 ｅｎｄ－ ｆｏ ｒｅｎｄ．｛ＰＡ Ｊ｝这个算法分为两步：第一步，将关系 Ｒ 按属性 Ａ 的 ｈ 函数分簇，并发送到每个相关的 Ｓ 站点。这保证了具

有散列值 ｖ 的 Ｒ 元组只被发送到包含相同值的 Ｓ 站点上。 它不同于并行嵌套循环算法，这里关系 Ｒ 的元组虽被分簇但不复制到所有 Ｓ 站点。

第二步，每一个 Ｓ 站点 ｊ 并行接收 Ｒ 的相关子集（例如 Ｒｊ），并且把它和片段 Ｓｊ 局部

连接。 局部连接处理方法同并行嵌套循环算法。例 １０．３　图 １０．６显示了并行关联连接算法的应用，假定 ｍ＝ｎ＝２。 填充内容相同的

方框表示具有相同散列函数值匹配的元组的片段。

·７１３·第十章　分布式数据库系统的发展趋势

图 １０．６　并行关联连接算法例子

（３） 并行散列连接算法

并行散列连接（ｐａｒａｌｌｅｌ ｈａｓｈ ｊｏ ｉｎ，ＰＨＪ）算法，如算法 １０．３所示。 可以看成并行关联

连接算法的概括。它也适用于等值连接，但与关系的分簇方法无关。 其基本思想是把关系

Ｒ 和 Ｓ 分成同样数量的 ｐ 个互不相交的子集（片段）Ｒ １ ，Ｒ ２ ，…，Ｒｐ 和 Ｓ １ ，Ｓ ２ ，…，Ｓｐ。算法 １０．３　ＰＨＪ　　　　　ｉｎ ｐｕｔ ：　Ｒ １ ，Ｒ ２ ，…，Ｒｍ ： ｆｒａｇｍｅｎｔｓ ｏｆ ｒｅｌａｔ ｉｏｎ Ｒ；　　　　　　　　　Ｓ １ ，Ｓ ２ ，…，Ｓ ｎ： ｆｒａｇｍｅｎｔｓ ｏ ｆ ｒｅｌａｔ ｉｏｎ Ｓ ；　　　　　　　　　ＪＰ： ｊｏｉｎ ｐｒｅｄｉｃａｔｅ　　　　　ｏｕｔｐｕｔ： Ｔ １ ，Ｔ ２ ，…，Ｔ ｎ： ｒｅｓｕｌｔ ｆ ｒａｇｍｅｎｔｓ　　　　　ｂｅｇ ｉｎ　 ｛ ｗ ｅ ａｓｓｕｍｅ ｔ ｈａｔ ＪＰ ｉｓ Ｒ．Ａ＝Ｓ．Ｂ ａｎｄ ｈ ｉｓ ａ ｈａｓｈ ｆｕｎｃｔｉｏｎ ｔ ｈａｔ

ｒｅｔ ｕｒｎｓ ａｎ ｅｌｅｍｅｎｔ ｏ ｆ ［１，ｐ］｝　　　　　　　 ｆ ｏｒ ｉ ｆｒｏｍ １ ｔ ｏ ｍ ｄｏ ｉｎ ｐａｒａｌｌｅｌ　　　　　　　 ｂｅｇ ｉｎ　　　　　　　　　　Ｒ ｉｊ← ａｐｐｌｙ ｈ（Ａ） ｔｏ Ｒｉ（ ｊ ＝ １，２，…，ｐ ）　　　　　　　　　　ｆ ｏｒ ｊ ｆｒｏｍ １ ｔ ｏ ｎ ｄｏ　　　　　　　　　　　　 Ｓ ｅｎｄ Ｓ ｉｊ ｔ ｏ ｔ ｈｅ ｎｏｄｅ ｊ　　　　　　　　　　ｅｎｄ－ ｆｏ ｒ　　　　　　　 ｅｎｄ－ ｆｏ ｒ　　　　　　　 ｆ ｏｒ ｊ ｆｒｏｍ １ ｔ ｏ ｎ ｄｏ ｉｎ ｐａｒａｌｌｅｌ ｛ｈａｓｈ Ｓ ｏｎ ｔ ｈｅ ｊｏｉｎ ａｔ ｔｒ ｉｂｕｔ ｅ｝　　　　　　　 ｂｅｇ ｉｎ　　　　　　　　　　Ｓ ｉｊ← ａｐｐｌｙ ｈ（Ｂ） ｔ ｏ Ｓｉ（ ｊ ＝ １，２，…，ｐ ）　　　　　　　　　　ｆ ｏｒ ｊ ｆｒｏｍ １ ｔ ｏ ｐ ｄｏ　　　　　　　　　　　　 Ｓ ｅｎｄ Ｓ ｉｊ ｔ ｏ ｔ ｈｅ ｎｏｄｅ ｊ　　　　　　　　　　ｅｎｄ－ ｆｏ ｒ

·８１３· 分布式数据库系统及其应用

　　　　　ｅｎｄ－ ｆｏ ｒ　　　ｆ ｏｒ ｊ ｆｒｏｍ １ ｔ ｏ ｐ ｄｏ ｉｎ ｐａｒａｌｌｅｌ ｛ｐｅｒｆｏ ｒｍ ｔｈｅ ｊｏ ｉｎ ａｔ ｅａｃｈ Ｓｎ ｏｄｅｓ｝　　　ｂｅｇ ｉｎ　　　　Ｒ ｊ← ∪ ｉ Ｒ ｉｊ（ｉ ＝１，２，…，ｐ）｛ｒｅｃｅｉｖｅ ｆｒｏｍ Ｒｎｏｄｅｓ｝　　　　Ｓ ｊ← ∪ ｉ Ｓ ｉ ｊ（ｉ ＝１，２，…，ｐ）｛ｒｅｃｅｉｖ ｅ ｆｒｏｍ Ｓｎｏｄｅｓ｝　　　　Ｔ ｊ← ＪＯＩＮ （Ｒ ｊ，Ｓｊ，ＪＰ）　　　 ｅｎｄ－ ｆｏ ｒｅｎｄ．｛ＰＨＪ｝如同 ＰＡＪ 算法，Ｒ 和 Ｓ 的分片可以基于相同的散列函数，并以连接属性作为散列变

量。 在 ｐ 个 Ｓ 的站点上并行地执行局部连接（Ｒ ｊ∞ Ｓｊ），连接的结果在 Ｓ 的 ｐ 个站点上产

生。 这 ｐ 个站点实际运行时可根据系统的负载情况进行动态选择。 与 ＰＡＪ 算法的主要不

同是 ＰＨＪ 对 Ｓ 的分片是必需的，而且结果产生在 ｐ 个 Ｓ 站点而不是在 ｎ 个 Ｓ 站点上。例 １０．４　图 １０．７显示了并行散列连接算法的应用，假定 ｍ＝ｎ＝２。 假设结果在站点

１和 ２上产生。 一个从站点 １到站点 １或从站点 ２到站点 ２的箭头表明一个本地传送。

图 １０．７　并行散列连接算法例子

ＰＨＪ 算法分为三步执行：第一步，对关系 Ｒ 按照散列函数确定属性 Ａ 分簇，并发送到相关的 ｐ 个 Ｓ 站点；第二步，对关系 Ｓ 按照散列函数确定属性 Ｂ 分簇，并发送到相关的 ｐ 个 Ｓ 站点；第三步，在 ｐ 个 Ｓ 站点上并行地接收了来自 Ｒ 或 Ｓ 站点的子集后，对它们分别进行

局部连接，局部连接处理方法同并行嵌套循环算法。（４） 各种并行算法的代价

上述这些并行连接算法的并行度可以达到 ｎ 或 ｐ，每一算法分别适应不同情况，但都

至少要求移动一个操作数关系后方可进行局部连接。 各种并行算法的代价是该种算法的

总成本，它是通信代价 Ｃｃ ｏ ｍ与局部处理代价 Ｃｐ ｒ ｏ之和。Ｃｏｓｔ （Ａｌｇ．） ＝ Ｃｃ ｏ ｍ （Ａ ｌｇ．） ＋ Ｃｐｒ ｏ（Ａｌｇ．）

为简单起见，Ｃｃｏ ｍ不包括初始化和终止本地任务的控制信息。使用 ｍｓｇ（＃ ｔｕｐ）表示从

·９１３·第十章　分布式数据库系统的发展趋势

一个站点到另一个站点传送＃ ｔ ｕｐ 元组的成本。使用函数 ＣＬ Ｏ Ｃ （ｍ ，ｎ）表示连接两个元组个

数分别为 ｍ 和 ｎ 的关系的本地处理成本。 假设不使用网络广播功能，局部处理代价对三

个并行连接算法是相同的， 后假定所有站点的工作负荷是均匀的，那么有

１） 对于并行嵌套循环 算法传送 ｍ ×ｎ 个消息，每个 消息包含的元组个数 为

ｃａｒｄ（Ｒ）／ｍ，则有

Ｃｃｏ ｍ （ＰＮＬ ）＝ ｍ × ｎ × ｍｓｇ（ｃａｒｄ（Ｒ）／ｍ）　每个 Ｓ 站点上需要连接所有 Ｒ 与 Ｓ 的片段的代价为

Ｃｐｒ ｏ （ＰＮＬ ）＝ ｎ × ＣＬ Ｏ Ｃ （ｃａｒｄ（Ｒ），ｃａｒｄ（Ｓ）／ｎ）２） 对于并行关联连接算法要求在每个 Ｒ 站点上，把 Ｒ 的片段划成为大小为 ｃａｒｄ

（Ｒ）／（ｍ×ｎ）的 ｎ 个子片段，并且发送到 ｎ 个 Ｓ 站点上，则有

Ｃｃ ｏ ｍ （ＰＡＪ）＝ ｍ × ｎ × ｍｓｇ（ｃａｒｄ（Ｒ）／（ｍ × ｎ））Ｃｐｒ ｏ （ＰＡＪ）＝ ｎ × ＣＬ Ｏ Ｃ （ｃａｒｄ（Ｒ）／ｍ，ｃａｒｄ（Ｓ）／ｎ）

３） 对于并行散列连接算法要求关系 Ｒ 和 Ｓ 被划分成 ｐ 个片段，并发送到 ｐ 个站点

上，然后在这 ｐ 个站点上执行连接，则有

Ｃｃ ｏ ｍ （ＰＨＪ）＝ ｍ × ｐ × ｍｓｇ（ｃａｒｄ（Ｒ）／（ｍ × ｐ））＋ ｎ × ｐ × ｍｓｇ（Ｃａｒｄ（Ｓ）／（ｎ × ｐ））Ｃｐｒ ｏ （ＰＨＪ）＝ ｎ × ＣＬ Ｏ Ｃ （ｃａｒｄ（Ｒ）／ｍ，ｃａｒｄ（Ｓ）／ｎ）

首先假定 ｐ＝ｎ。在这种情况下 ＰＡ Ｊ 和 ＰＨＪ 算法的连接处理成本是相等的。由于在每

个 Ｓ 站点上都必须与 Ｒ 连接，所以 ＰＮ Ｌ 算法的成本较高。 从上面的等式，很清楚 ＰＡＪ 算法的通信成本较小。 而 ＰＮ Ｌ 和 ＰＨＪ 算法的通信成本依赖于关系元组的个数和分簇的程

度。 如果选择 ｐ 比 ｎ 小，ＰＨＪ 算法的通信成本减少，但连接处理代价增高。 例如，若 ｐ＝１，就按集中方式处理连接。

综上所述，ＰＡ Ｊ 算法更具优势，应尽可能采用。对 ＰＮ Ｌ 和 ＰＨＪ 算法的选择要求根据 ｐ的 佳值来估算总成本。并行连接算法可以被算法 １０．４所示的过程 ＣＨＯＯＳＥ－ ＪＡ 概括。

算法 １０．４　ＣＨＯＯＳＥ－ ＪＡｉｎ ｐｕｔ： ｐｒｏ ｆ（Ｒ），ｐｒｏ ｆ（ｓ）： ｒｅｌａｔｉｏｎ ｐｒｏ ｆｉｌｅｓ；ＪＰ ： ｊｏ ｉｎ ｐｒｅｄｉｃａｔ ｅｏｕｔｐｕｔ ： ＪＡ： ｊｏｉｎ ａｌｇｏ ｒｉｔｈｍｂｅｇ ｉｎ　　　ｉｆ ＪＰ ｉｓ ｅｑｕｉｊｏｉｎ ｔ ｈｅｎ　　　　　 ｉｆ ｏｎ ｒｅｌａｔ ｉｏｎ ｉｓ ｄｅｃｌｕｓｔ ｅｒｅｄ ａｃｏ ｒｄｉｎｇ ｔ ｏ ｊｏ ｉｎ ａｔｔ ｒ ｉｂｕｔ ｔ ｈｅｎ　　　　　　　ＪＡ ← ＰＡ Ｊ　　　　　 ｅｌｓｅ ｉｆ Ｃｏ ｓｔ （ＰＮ Ｌ ）＜ Ｃｏｓ ｔ（ＰＨＪ） ｔ ｈｅｎ　　　　　　　ＪＡ ← ＰＮ Ｌ　　　　　　　　ｅｌｓｅ　　　　　　　ＪＡ ← ＰＨＪ　　　　　　　　ｅｎｄ－ ｉｆ　　　　　 ｅｎｄ－ ｉｆ　　　ｅｌｓｅ

·０２３· 分布式数据库系统及其应用

　　　　　ＪＡ ← ＰＮ Ｌ　　　ｅｎｄ－ ｉｆｅｎｄ．｛ＣＨＯＯＳＥ－ ＪＡ ｝

１０．１．４　并行查询处理的算法

并行查询处理主要指在并行数据服务器上的查询处理，其处理方式与分布式查询处

理相类似。 并行查询处理的目标是使操作内部和操作之间的并行度 高。 提高操作内的

并行度可以使用上述这些算法，提高操作间的并行度可以采用一些分布式数据库技术，例如，采用枚举法。通过枚举法，枚举出所有可能的执行的策略，从中选出一个并行数据服务

器完成该查询的 佳策略。 另外，还应考虑到如何发掘连接操作和内部操作的并行性，关键因素是使解题的空间增大。例如，当查询涉及多个连接操作时，优化自身的代价就很大。为了避免这个问题，可在枚举法中使用启发式。 启发式可在运行时动态完成，也可以在编

译时完成。“支点（ｐｉｖ ｏｔ）”算法是一种在编译过程中进行启发式处理的算法。 现在以包含 ｓｅｌｅｃｔ

ｐｒｏ ｊｅｃｔｊｏ ｉｎ 操作的查询处理为例加以说明。支点算法把数据库物理模式分为三种：基本关系、辅助索引和连接索引。 一个基本关

系是对逻辑关系的直接映射，借助元组标识符（Ｔ ＩＤ）和将外键替换成相应的元组标识符。基本关系以 Ｔ ＩＤ 聚簇。 辅助索引是一个二元关系，由属性值和与该值相匹配的元组标识

符组成，它按属性值聚簇。 连接索引也是一个二元关系，由满足连接谓词的两个关系相匹

配的 Ｔ ＩＤ 组成，它在其中的一个 Ｔ ＩＤ 上聚簇。如果连接索引包含一个外键，它在外键对应

的 Ｔ ＩＤ 上聚簇，以提供对基本关系的直接访问。支 点 算 法 由 四 步 组 成：选 择，支 点，值 具 体 化 （ ｖａｌｕ ｅ ｍａｔ ｅｒｉａｌｉｚａｔｉｏｎ ）和 组 合

（ｃｏｍｐｏｓ ｉｔｉｏｎ）。１．选择

在连接前执行所有的 ｓｅｌｅｃｔ 操作，并且返回包含所选元组标识符组成的关系。由于这

些选择可并行执行，这一步达到了有效的操作间的并行度，以及依据所选关系的分簇方

式，还可达到一定程度的操作内并行度。２．支点

执行查询的 ｍ 路连接，利用有关的连接索引，将所选元组的 Ｔ ＩＤ 与用来产生 终结

果所需的元组 Ｔ ＩＤ 进行合并。 这个连接顺序可以采用传统方法确定。 这步的输出是一组

二元关系，每个二元关系都包含一个公共 Ｔ ＩＤ（称为支点 Ｔ ＩＤ）和其属性将投影在结果关

系中的元组 Ｔ ＩＤ。 根据上述的并行连接算法，这步可以达到有效的操作内并行度，以及依

据选定的连接顺序，还可达到一定的操作间并行度。 此外，在两个站点间移动的操作量较

小。 这将使消息的尺寸达到 小，从而使通信代价 小。３．值具体化

对于每个二元关系，值具体化通过相应的投影（ｐｒｏｊｅｃｔ ｅｄ）属性替换了每个非支点

·１２３·第十章　分布式数据库系统的发展趋势

Ｔ ＩＤ。 这是通过连接每个二元关系与 Ｔ ＩＤ 上对应的投影关系来实现的。 这步达到较高的

操作之间并行度，因为所有连接操作都可以并行地执行，以及通过并行连接算法到达很高

的操作内并行度。４．组合

在支点 Ｔ ＩＤ 上连接所有在前步产生的关系，可以通过并行连接算法达到较高的操作

内并行度。总之，支点算法可导致很高的操作间和操作内并行度。 另外，其他启发式方法可以方

便地与并行连接算法合并使用，以避免对一个关系的多次访问。

１０．２　分布式知识库系统

直观地看，一个知识库为数据库补充了从已有信息演绎新信息的能力。它比一般数据

库的功能更强，特别是知识库系统的查询处理能力远比关系数据库系统强得多。不论是新

的应用领域，如专家系统，还是传统数据库应用领域，如事务处理，分布式知识库系统更具

有广阔的发展前景。 在这一节中将简单介绍知识库系统的目标，着重介绍数学逻辑，也称

逻辑数据库或演绎数据库（ｄｅｄｕｃｔｉｖｅ ｄａｔ ａｂａｓｅ），它们可以被看成是关系数据库系统的扩

展。 还将讨论一个重要问题：递归查询处理。 后，为了更好地理解分布式数据库系统和

知识库系统的关系，举例说明一个并行数据服务器是如何有效地通过并行执行技术支持

知识库管理。１０．２．１　知识库

数据库是数据表现事实的集合。在关系数据库中，事实通过元组模型化。 关系查询语

言（如关系代数）使用户找到元组，并把它们组合成新的（结果）元组。这些新元组不能提供

比存储在数据库中的数据更多的信息，只不过通过用户希望的不同方式表现出来而已。数据库系统缺少从已有事实中推导出新事实的推理能力，例如数据分析和规划、专家

系统就需要这样的能力。 这些应用一般都基于数据库之上，利用提取事实的编程语言建

立。推理是基于知识的，比数据要抽象得多。 例如，谓词“斯密斯是人”是一个事实，同时谓

词“所有的人都是要死的”是事实，这样一个新事实就推导出来了：“斯密斯是要死的”。 由

于知识库系统具有对知识共享、控制和管理的能力，因而可以大大减少应用程序的规模和

复杂程度。１．知识库的基本概念

知识库的简单定义：知识库是存储常用知识（命题和规则等）的内涵数据库和存储事

实（基本数据）的外延数据库的联合体。知识库方法主要是通过分解常用知识来解决难题，这很类似数据库方法中的模式分解。

知识库系统的接口：用户查询通过外延数据库隐含地使用存储在内涵数据库中的知

识。用户查询可以通过简明的方法表达，同时通过知识进行强化，使之变得更复杂和高效。

·２２３· 分布式数据库系统及其应用

数据分析可以通过语义数据控制信息（它规定了基本的知识），加强查询的实现。内涵数据

库中的知识基本上是比语义数据控制信息更加通用。知识库系统的设计和实现中存在的困难和问题： 重要的问题是有关知识的表示，知

识的一致性和知识库的查询处理。如同数据库设计中的概念数据模型，要求知识模型在表

达和操纵知识时要独立于其在计算机中的物理表示。与知识模型相关的是知识操纵语言，它使得知识管理员能管理内涵数据库。 由于知识需求的增加，内涵数据库需要不断更新，但是，更新频率比外延数据库小。为了防止破坏知识更新的一致性，需要有一个机制，这比

语义完整性控制更为复杂。 后，知识库的查询处理要求具有推论性处理能力，以便从已

有知识推导出新知识。 大量事实表明，推论性处理的效率对知识库系统的性能是至关重

要的。２．知识表示

在人工智能中，有四类知识表达方法，它们是：产生式规则、框架、语义网络和数学逻

辑。 数学逻辑是用来表示人类思维和推理的 理想方法，也为知识库提供了 好的基础，这有两个原因。第一，关系演算语言是基于一阶谓词的。 这样知识库系统可以通过扩展关

系数据库系统来建立。第二，逻辑提供了必要的推论性机制，从已有知识中导出新的知识。这种机制在人工智能中被用来证明定理，即从已知公式（公理）中导出新公式。

因此，一般认为知识库是基于知识逻辑的数据库，或称为逻辑数据库和演绎数据库，并假定它们都是基于关系数据库之上的。

称为 Ｈｏｒｎ 子句（Ｈｏｒｎ Ｃｌａｕｓｅ）的一种特殊公式是逻辑数据库的基础。 一个 Ｈｏｒｎ 子

句的形式为

设 Ａ 和 Ｂ１ ，Ｂ２ ，…，Ｂｎ 是肯定的原子公式，即形式为 Ｐ （ｔ １ ，ｔ ２ ，…，ｔ ｎ ）的谓词，采用逻辑

隐含符号“→”，那么一个 Ｈｏｒｎ 子句一般写成

Ｂ１∩ Ｂ２∩ …∩ Ｂｎ→ Ａ一个 Ｈｏｒｎ Ｃｌａｕｓｅ 对应于一个规则。 Ａ 称为规则的头，Ｂｉ 的积称为规则的体。 不为空

的规则称为基本子句。一个空句是具有空体的规则，一个事实是没有变量的基本子句。 因

而，一个逻辑数据库可以定义成规则的一个集合，规则的谓词名字对应关系名或函数名，变量名对应于属性名，常数对应于属性值。一个逻辑数据库可以被解释为元组集合所能满

足的全部谓词。此时，关系和谓词可以认为是对等的。谓词变量涉及的领域类似关系演算。对逻辑数据库的查询是一个简单的谓词，它的名字是某个规则的头部。一个查询的回答是

一组使得查询谓词为真的元组。体不为空的谓词能导出新元组，它们可以被看成是对视图

导出规则的概括。在逻辑数据库的规则中，一个重要类型的规则被称为递归规则，其头部和体部具有相

同的谓词（递归谓词）。 一个规则被称为线性递归，要求递归谓词在其体中只出现一次。下面在逻辑数据库的两个例子中，变量用斜体表示，谓词名字用加重体表示；常量用

小写体表示，查询用谓词前缀？ 表示。例 １０．５　这是一个逻辑数据库的典型例子，它基于父辈和祖先谓词。　　　ｐａｒｅｎｔ（ｊｏ ｈｎ．ａｎｎ）

·３２３·第十章　分布式数据库系统的发展趋势

　　　ｐａｒｅｎｔ（ｃａｔ ｈｙ，ｊｏ ｈｎ）　　　ｐａｒｅｎｔ（ｍｉｃｈａｅｌ，ｊｏ ｈｎ）　　　ｐａｒｅｎｔ（ｓａｒａｈ，ｃａｔ ｈｙ）　　　ｐａｒｅｎｔ（ｊｕｌｉｅｔ ｔｅ，ｃａｔｈｙ）　　　ａｎｃｅｓ ｔｏ ｒ（Ｄ，Ａ ） ← ｐａｒｅｎｔ （Ｄ，Ａ ）　　　ａｎｃｅｓ ｔｏ ｒ（Ｄ，Ａ ） ← ｐａｒｅｎｔ （Ｄ，Ｐ）， ａｎｃｅｓｔ ｏｒ （Ｐ，Ａ）逻辑数据库包含五个事实，定义了 ｐａｒｅｎｔ 关系（或 ｐａｒｅｎｔ 谓词），还有两个规则定义

了 ａｎｃｅｓ ｔｏ ｒ 关系（或 ａｎｃｅｓ ｔｏ ｒ 谓词）。 ｐａｒｅｎｔ 关系联系着一个孩子（第一属性）与他的父亲

（第二属性）指定了外延数据库。 例如，ｐａｒｅｎｔ 关系的元组（ｃａｔｈｙ，ｊｏｈｎ）可以翻译成 ｐａｒｅｎｔ谓词是（ｃａｔ ｈｙ，ｊｏ ｈｎ）对为真，即 ｊｏｈ ｎ 是 ｃａｔ ｈｙ 的父亲。 模式的 ａｎｃｅｓ ｔｏ ｒ 关系（ｄｅｓｃｅｎｄａｎ ｔ，ａｓｃｅｎｄａｎｔ）是导出关系，并且指定了内涵数据库。 例如，线性递归规则：

ａｎｃｅｓ ｔｏ ｒ（Ｄ，Ａ ） ← ｐａｒｅｎｔ（Ｄ，Ｐ），ａｎｃｅｓｔ ｏｒ （Ｐ，Ａ ）可以被翻译成：如果有三个概念 Ｄ、Ｐ 和 Ａ ，这样 ｐａｒｅｎｔ（Ｄ，Ｐ）为真，ａｎｃｅｓｔ ｏｒ （Ｐ，Ａ ）为

真，那么 ａｎｃｅｓ ｔｏ ｒ（Ｄ，Ａ ）也为真。这两个规则定义了 ａｎｃｅｓｔ ｏｒ 关系把 ｐａｒｅｎｔ 关系作为输入

来导出 ａｎｃｅｓ ｔｏ ｒ 关系。 现在给出几个查询事例的答案。　　　？ ｐａｒｅｎｔ（ｃａｔｈｙ，Ｐ ）　　　　　 ｒｅｔｕｒｎ（ｃａｔ ｈｙ，ｊｏ ｈｎ）　　　？ ｐａｒｅｎｔ（ｃａｔｈｙ，ｂ ｉｌｌ）　　　　　　　ｒｅｔｕｒｎ ｆａｌｓｅ　　　？ ｐａｒｅｎｔ（Ｃ，Ｐ）　　　　　　　　　ｒｅｔｕｒｎｓ｛（ｊｏｈ ｎ，ａｎｎ），（ｃａｔｈ ｙ，ｊｏｈ ｎ），　　　　　 （ｍｉｃｈａｅｌ，ｊｏ ｈｎ），（ｓａｒａｈ，ｃａｔｈｙ），（ｊｕｌｉｅｔｔ ｅ，ｃａｔ ｈｙ）｝　　　？ ａｎｃｅｓｔ ｏｒ （ｃａｔ ｈｙ，Ａ ）　　　　 ｒｅｔｕｒｎｓ｛（ｃａｔｈ ｙ，ｊｏｈ ｎ），（ｃａｔｈｙ，ａｎｎ）｝　　　？ ａｎｃｅｓｔ ｏｒ （ｊｕｌｉｔ ｅｔｔｅ，Ａ）　　　 ｒｅｔｕｒｎｓ｛（ｊｕｌｉｅｔｔ ｅ，ｃａｔ ｈｙ），　　　　　　　　 （ｊｕｌｉｅｔｔｅ，ｊｏｈｎ），（ｊｕｌｉｅｔ ｔｅ，ａｎｎ）｝例 １０．６　考虑关系：

ｐａｒｔ（ｐｎａｍｅ，ｗ ｅｉｇｈ ｔ，ｓｕｐｐｏｒｔ － ｐｎａｍｅ）其中 ｐｎａｍｅ 和 ｓｕｐｐｏ ｒｔ － ｐｎ ａｍｅ 具有相同的域，ｗ ｅｉｇｈｔ 是 ｐｎａｍｅ 的重量。 ｓｕｐｐｏｒｔ － ｐｎａｍｅ是组装到（支持）ｐｎａｍｅ 中去的零件名。 如果 ｐ １ 零件支持 ｐ ２ ，则 ｐ １ 的总重量是 ｐ １ 和 ｐ ２ 单独重量之和。

逻辑数据库的另一个例子是（空值用 ｎｕｌｌ 表示）：　　 ｐａｒｔ（ｐ １ ，３０，ｐ ２ ）　　 ｐａｒｔ（ｐ ２ ，２０，ｐ ３ ）　　 ｐａｒｔ（ｐ ３ ，１０，ｎｕｌｌ）　　 ｐａｒｔ（ｐ ４ ，１０，ｎｕｌｌ）　　 ｔ ｏｔ ａｌ－ ｐａｒｔ （ｐ，Ｗ ，Ｓ） ← ｐａｒｔ（ｐ，Ｗ ，Ｓ）　　 ｔ ｏｔ ａｌ－ ｐａｒｔ （ｐ，Ｗ ，Ｓ） ← ｔ ｏｔ ａｌ－ ｐａｒｔ（ｐ，Ｗ １ ，ｐ １ ）， ｔｏ ｔａｌ－ ｐａｒｔ（ｐ １ ，Ｗ ２ ，Ｓ），　　　　　　　　ｓｕｍ（Ｗ ，Ｗ １ ，Ｗ ２ ）外延数据库由 ｐａｒｔ 关系组成（４个事实）。内涵数据库由同样模式的导出关系组成，它

给出了每一零件的总重量。 ｓｕｍ（Ｗ，Ｗ １ ，Ｗ ２ ）是一个谓词，当 Ｗ 是 Ｗ １ 和 Ｗ ２ 之和为真时，

·４２３· 分布式数据库系统及其应用

递归规则使得可以从一个零件导出被其传递支持的所有零件，例如，有　　　？ ｐａｒｔ（ｐ ２ ，Ｗ ，Ｓ）　　　　　　ｒｅｔ ｕｒｎ（ｐ ２ ，２０，ｐ ３ ）　　　？ ｔｏ ｔａｌ－ ｐａｒｔ（ｐ ２ ，Ｗ ，Ｓ）　　　 ｒｅｔ ｕｒｎ｛（ｐ ２ ，２０，ｐ ３ ），（ｐ ２ ，３０，ｎｕｌｌ）｝　　　？ ｔｏ ｔａｌ－ ｐａｒｔ（ｐ １ ，Ｗ ，ｎｕｌｌ）　　 ｒｅｔ ｕｒｎ（ｐ １ ，６０，ｎｕｌｌ）３．知识库语言

ＰＲＯＬＯＧ 语言是一种基于一阶谓词的逻辑程序语言。在人工智能和知识库的实现技

术中具有重要的作用。 ＰＲＯＬＯＧ 是基于 Ｈｏｒｎ 子句的。 但是，ＰＲＯＬＯＧ 虽然是一种基于

一阶谓词的逻辑程序语言，但它不是纯逻辑语言，而且不能用作逻辑数据库，这有两个

原因。１） 其谓词的调用是逐个地且与其在 Ｈｏｒｎ Ｃｌａｕｓｅ 中的位置有关，从而使 Ｈｏｒｎ ｃｌａｕｓｅ

的处理结果也与上述的顺序有关；２） ＰＲＯＬＯＧ 推理机制不区分事实和规则，它们必须都驻留在内存中，因而限制了其

在小型内涵数据库中的应用。逻辑数据库的另一种语言是 ＤＡＴ Ａ ＬＯＧ ，那是一个纯粹的基于 Ｈｏｒｎ Ｃｌａｕｓｅ 的语

言。它是用于非程序定义规则的语言。事实上，ＤＡ ＴＡ ＬＯＧ 语言是针对一阶谓词逻辑公式

的表示方法不够规范，不宜在计算机中使用和处理的缺点，经过一定的改造、扩充，而发展

起来的一种新型的逻辑语言。ＤＡ ＴＡ ＬＯＧ 语言的致命缺点是它不带函数，建模能力差，较难描述现实世界的实际

问题。 因此 ＤＡ Ｔ ＡＬＯＧ 语言还停留在理论研究层次上和主要用于建立知识库的实验系

统中，在实用上尚存在一些困难。相比之下，ＰＲＯＬＯＧ 语言尽管存在难以处理密集型数据

和知识的缺点，但通过 Ｈｏｒｎ 子句，其功能上得到了改进，已大大扩充了该语言的能力，并提高了效率，成为被广泛接受的知识库语言。１０．２．２　逻辑查询处理

在这一节中将讨论用 ＤＡ Ｔ ＡＬＯＧ 语言表达的逻辑查询处理。 因为 ＤＡ ＴＡ ＬＯＧ 是关

系演算的超集，从关系查询优化中获得的经验是有用的，但还不够。特别，对涉及递归规则

的查询，称为递归查询，是研究中遇到的新的困难问题。为了能有效地处理和估算逻辑查询，人们提出了很多不同的技术。下面讨论一种称为

自底向上的估算技术。这一技术从事实开始，运用有关规则导出查询答案。 这个技术由于

能在查询编译时运用关系查询优化而具有优势。内涵数据库可以被看成是参数查询的一个集合，每一个参数查询被出现在规则头上

的谓词所定义。在逻辑数据库中的查询是一个带有实际参数值的谓词，谓词中的变量与常

数捆绑（用常数替换）。 自底向上处理逻辑查询可以分为如下两个主要步骤进行。第一步，如果查询规则的头或体引用了查询谓词，就将查询和相关规则合并。 相关规

则的快速存取可以通过某种形式的索引机制达到，如谓词连接图（ｐｒｅｄｉｃａｔｅ ｃｏｎｎｅｃｔ ｉｏｎｇ ｒａｐｈ）。 查询中的这种捆绑可以在规则体中传播。 这一步产生了已捆绑的规则程序。

第二步，将规则程序翻译成一个以逻辑数据库系统的内部语言表示的优化程序。为了

·５２３·第十章　分布式数据库系统的发展趋势

使用关系查询优化技术，内部语言可以选择含有控制语句，如“ｗ ｈｉｌｅ ｔ ｏ”和“ｉｆ ｔｈｅｎ”的关

系代数。例 １０．７　考虑工程数据库中的查询要求：“寻找在 ＣＡＤ／ＣＡＭ 项目上工作的雇员”，

这可以用如下的 ＳＱＬ 语句表达：ＳＥＬＥＣＴ　ＥＮＡＭ Ｅ，ＪＮ ＡＭ Ｅ ＦＲＯＭ Ｅ，Ｇ ，Ｊ　　　　ＷＨＥＲＥ Ｅ．ＥＮＯ ＝ Ｇ．ＥＮＯ ＡＮＤ　Ｇ．ＰＮＯ ＝ Ｊ．ＪＮＯ　　　　　　　　ＡＮＤ ＪＮ ＡＭ Ｅ ＝“ＣＡＤ／ＣＡＭ＇＇抽象这个查询需要一个规则（其中‘－ ’表示忽略）：Ｒ（ＥＮＡＭＥ ，ＪＮ ＡＭ Ｅ） ← Ｅ（ＥＮＯ，ＥＮＡＭ Ｅ，－ ），Ｇ（ＥＮＯ，ＪＮＯ ，－ ，－ ），　　　　　　　　Ｊ（ＪＮ Ｏ，ＪＮＡＭ Ｅ，－ ）这个查询可以表达成

？ Ｒ（ＥＮＡＭ Ｅ，“ＣＡＤ／ＣＡＭ ”）查询处理的第一步产生：Ｒ（ＥＮＡＭＥ ，“ＣＡＤ／ＣＡＭ ”） ← Ｅ（ＥＮＯ ，ＥＮＡＭ Ｅ，－ ），Ｇ （ＥＮＯ ，ＪＮ Ｏ，－ ，－ ），　　　　　　　　Ｊ（ＪＮ Ｏ，“ＣＡＤ／ＣＡＭ ”，－ ）第二步，它可以翻译成关系代数表达式：

πＥ Ｎ Ａ Ｍ Ｅ ， ＪＮ Ａ Ｍ Ｅ （（（σＪＮ Ａ Ｍ Ｅ ＝ ′Ｃ Ａ Ｄ／Ｃ Ａ Ｍ ′（Ｊ））∞ ＪＮ Ｏ Ｇ）∞Ｅ Ｎ Ｏ Ｅ ）在上面的例子中，把逻辑查询处理降级成关系查询处理。对于递归查询这样做就不可

以了，它们不能直接映射成关系代数，因为关系代数没有递归或重复操作符。采用自底向上估算方法，这是一个采用重复“ｗ ｈｉｌｅ ｄｏ”操作符和关系代数来处理递

归的简单技术。这项技术称为自然估算（ｎａｔ ｉｖｅ ｅｖａｌｕａｔｉｏｎ），重复应用规则以导出新元组，直到所有元组都被完全导出。 这个自然估算方法体现在算法 １０．５中，其中 Ｔ 是通过递归

规则导出的关系，Ｒ 是存储外延知识的关系，ｆ （Ｔ ）为根据规则体对 Ｔ 进行关系代数运算

所产生的新关系的函数。算法 １０．５　ＮＡＩＶＥ　　　ｉｎ ｐｕｔ： Ｒ：ｏｐｅｒａｎｄ ｒｅｌａｔ ｉｏｎ　　　ｏｕｔｐｕｔ ： Ｔ ：ｏｕｔ ｐｕｔ ｒｅｌａｔｉｏｎ　　　ｂｅｇ ｉｎ　　　　　 Ｔ ←Ｒ　　　　　 ｗ ｈｉｌｅ Ｔ ｉｓ ｎｏ ｔ ｅｍｐｔｙ ｄｏ　　　　　　　　Ｔ ←Ｔ ∪ ｆ（Ｒ）　　　　　 ｅｎｄ．｛ＮＡ ＩＶ Ｅ｝例 １０．８　考虑例 １０．５的逻辑数据库和查询：　　　？ ａｎｃｅｓｔ ｏｒ （Ｄ，Ａ ）这要求计算所有的（ｄｅｓｃｅｎｄａｎ ｔ，ａｓｃｅｎｄａｎｔ）对。这个 ａｎｃｅｓ ｔｏ ｒ 关系的自然估算可以表

示成：　　 Ｔ ← ｐａｒｅｎｔ　　 ｗ ｈｉｌｅ Ｔ ｉｓ ｎｏ ｔ ｅｍｐｔｙ ｄｏ

·６２３· 分布式数据库系统及其应用

　　　　 Ｔ ← ∪πｐ．ｃｈ ｉｌｄ ， Ｔ ．ｐ ａ ｒ（ｐａｒｅｎｔ ∞ ｐ ａ ｒ ＝ ｃ ｈ ｉｌ ｄＴ ）其中：ｐ．ｃｈｉｌｄ 表示父亲关系的第一个属性，Ｔ ．ｐａｒ 表示 Ｔ 关系的第二个关系。

第一次迭代连接父亲关系和它自己，产生：Ｒ １＝ ｐａｒｅｎ ｔ ∪｛（ｃａｔ ｈｙ，ａｎｎ），（ｍｉｃｈａｅｌ，ａｎｎ），（ｊｕｌｉｅｔｔｅ，ｊｏｈｎ），（ｓａｒａｈ，ｊｏ ｈｎ）｝第二次迭代产生：Ｒ ２＝ Ｒ １∪｛（ｊｕｌｉｅｔｔ ｅ，ａｎｎ），（ｓａｒａｈ，ａｎｎ）｝自然估算方法的主要缺点是产生冗余工作。 因为在一次迭代中，函数 ｆ （Ｔ ）计算了前

一次迭代推导出的元组，即在每次迭代中重复了元组的推导过程。 在例 １０．８ 中四个元组

在第一次迭代中产生，在第二次中又产生。半自然（ｓｅｍ ｉｎａｔｉｖ ｅ）估算方法是对自然估算方法的改进，在每个迭代中仅考虑那些

新导出的元组，其主要方法是利用增量关系。 用 ＤＲ 表示每次迭代后产生的新元组，并且

把 ｆ （Ｔ ） 置换成 ｄｆ（Ｔ ，ＤＲ），ｄｆ 是 ｆ 的增量。 算法 １０．６描述了半自然估算方法。算法 １０．６　ＳＥＭ ＩＮＡ ＩＶ Ｅ　　　ｉｎ ｐｕｔ： Ｒ： ｏｐｅｒａｎｄ ｒｅｌａｔ ｉｏｎ　　　ｏｕｔｐｕｔ ： Ｔ ： ｏｕｔ ｐｕｔ ｒｅｌａｔｉｏｎ　　　ｄｅｃｌａｒｅ　　　　　 ＤＲ： ｒｅｌａｔ ｉｏｎ　　　ｂｅｇ ｉｎ　　　　　 ＤＲ←Ｒ　　　　　 Ｔ ←Ｒ　　　　　 ｗ ｈｉｌｅ ＤＲ ｉｓ ｎｏｔ ｅｍｐｔ ｙ ｄｏ　　　　　 ｂｅｇ ｉｎ　　　　　　　　ＤＲ←ｄｆ （Ｒ，ＤＲ）　　　　　　　　Ｔ ←Ｔ∪ＤＲ　　　　　 ｅｎｄ－ ｗ ｈ ｉｌｅ　　　ｅｎｄ．｛ＳＥＭ ＩＮ ＡＩＶＥ ｝

例 １０．９　关系 ａｎｃｅｓｔ ｏｒ 的半自然估算可表示为

　　　ＤＲ ← ｐａｒｅｎｔ　　　Ｔ ← ｐａｒｅｎｔ　　　ｗ ｈｉｌｅ ＤＲ ｉｓ ｎｏｔ ｅｍｐｔ ｙ ｄｏ　　　ｂｅｇ ｉｎ　　　　　ＤＲ ← πｐ ．ｃ ｈ ｉｌ ｄ ，Ｄ Ｒ ．ｐ ａ ｒ（ｐａｒｅｎｔ ∞ｐ ａｒ ＝ ｃ ｈ ｉｌ ｄ ＤＲ）　　　　　 Ｔ ←Ｔ∪ＤＲ　　　Ｅｎｄ

１０．２．３　并行递归查询处理

通过把知识库和分布式数据库技术的有机结合得到分布式知识库，使知识库管理的

·７２３·第十章　分布式数据库系统的发展趋势

性能可以得到显著改进。 例如，考虑在一个完全不共享数据服务器上建立一个逻辑数据

库，由于递归查询的复杂性使得并行查询处理变得更加困难。下面集中讨论并行递归查询

处理问题。首先介绍传递闭包的两个基本算法：迭代传递闭包（ＩＴ Ｃ ）和传递闭合关系的传递闭

包（Ｔ ＣＣＲ）。 接着简单描述两个并行传递闭包算法：支持并行操作的传递闭包（Ｔ ＣＰＯ）算法和支持并行程序的传递闭包（Ｔ ＣＰＰ）算法。 假定基本关系分簇在多个站点上，以便于数

据库操作的并行处理。１．迭代传递闭包算法（ＩＴ Ｃ）为便于描述 ＩＴＣ 算法，设基本关系 Ｒ 为一个具有属性 Ａ 和 Ｂ 的二元关系，Ａ 和 Ｂ 在

同一值域上定义。 关系 Ｒ 可以被看成一个有向图边的集合，Ｒ 的元组（ａ，ｂ）表示从站点 ａ到站点 ｂ 的一条边。 Ｒ 的元组个数称为 Ｒ 的深度，标记为 ｄｅｐｔ ｈ（Ｒ），即图中的 长路径，或边的个数。 Ｒ 的传递闭包，记作 Ｒ＋ ，等价于相应图的传递闭包。换句话说，元组（ｘ，ｙ）在Ｒ＋ 中，当且仅当在图中有一条从 ｘ 到 ｙ 且长度大于零的路径。 用表示两个二元关系

Ｒ（Ａ，Ｂ）和 Ｐ （Ｂ，Ｃ）的组合，其所有的属性都在一个域上定义，并且把 Ｒ ｉ 作为关系 Ｒ 的第

ｉ次幂，即，Ｒ １＝Ｒ Ｒ ｉ＝Ｒ ｉ１Ｒ。 这样：Ｒ Ｐ ＝ ｛（ａ，ｃ）│（ｂ）（ａ，ｂ）∈ Ｒ ａｎｄ （ｂ，ｃ）∈ｐ ｝

Ｒ＋ ＝ Ｕ ｉ＞ Ｂ ＲｉＲＰ 可以通过投影操作和连接操作来实现：

Ｒ Ｐ ＝ πＡ ，Ｃ （ Ｒ ∞Ｂ Ｐ ）例 １０．１０　图 １０．８是相应于 ｐａｒｅｎｔ 关系的图，和相应于传递闭包 ｐａｒｅｎｔ ＋关系的图。

图 １０．８　ｐａｒｅｎｔ 关系的传递闭包

尽管 ＩＴ Ｃ 算法用于循环关系［例如，三个元组的循环（ａ，ｂ）（ｂ，ｃ）（ｃ，ａ）］，但仍假设 Ｒ

·８２３· 分布式数据库系统及其应用

是无环关系，即在有向图中无环路出现。 ＩＴ Ｃ 是一个采用增量关系 ＤＲ 的自然估算方法实

现的，如算法 １０．７ 所示。算法 １０．７　ＩＴＣ　　　ｉｎ ｐｕｔ： Ｒ： ｏｐｅｒａｎｄ ｒｅｌａｔ ｉｏｎ　　　ｏｕｔｐｕｔ ： Ｔ ： ｏｕｔ ｐｕｔ ｒｅｌａｔｉｏｎ　　　ｄｅｃｌａｒｅ　　　　　 ＤＲ： ｒｅｌａｔ ｉｏｎ　　　ｂｅｇ ｉｎ　　　　　 ＤＲ← Ｒ　　　　　 Ｔ ← Ｒ　　　　　 ｗ ｈｉｌｅ ＤＲ ｉｓ ｎｏｔ ｅｍｐｔ ｙ ｄｏ　　　　　 ｂｅｇ ｉｎ　　　　　　　　ＤＲ← ＤＲ Ｒ　　　　　　　　Ｔ ←Ｔ∪ＤＲ　　　ｅｎｄ－ ｗ ｈ ｉｌｅｅｎｄ．｛ＩＴ Ｃ｝

例 １０．１１　ＩＴＣ 是半自然估算方法的一种实现方法，例 １０．８ 是它的一个例子。 在

图 １０．８中，ｐａｒｅｎｔ 的子部分（１）和（２）分别在 ＩＴ Ｃ 应用的第一次和第二次迭代中产生。２．传递封闭关系的传递闭包算法（Ｔ ＣＣＲ）传递封闭关系是这样一种关系，它所对应的传递闭包不会产生新的元组。 设关系 Ｒ

可以分割为 Ｒ １ 和 Ｒ ２ （即 Ｒ ＝ Ｒ １∪ Ｒ ２ ），直接计算 Ｒ 的闭包 Ｒ＋的办法是 ＩＴ Ｃ（Ｒ＋１ ∪Ｒ＋２ ）。这将重复计算 Ｒ＋１ 和 Ｒ＋２ ，存在冗余的工作。

例如，在算法 ＩＴ Ｃ 的第一次迭代中计算：（Ｒ＋１ ∪Ｒ＋２ ）×（Ｒ＋１ ∪Ｒ＋２ ）＝（Ｒ＋１ ×Ｒ＋１ ）∪（Ｒ＋１ ×Ｒ＋２ ）∪（Ｒ＋２ ×∪Ｒ＋１ ）∪（Ｒ＋２ ×Ｒ＋２ ）

其中存在重复计算 Ｒ＋１ ＝（Ｒ＋１ ×Ｒ＋１ ）和 Ｒ＋２ ＝（Ｒ＋２ ×Ｒ＋２ ）。算法 Ｔ ＣＣＲ 计算了两个传递闭包关系的传递闭包，该算法避免了重复计算工作。 算

法 Ｔ ＣＣＲ 如算法 １０．８所示。该算法通过产生一种组合序列来计算 Ｒ＋１ ∪Ｒ＋２ 的传递闭包，如（Ｒ １×Ｒ１ ）或（Ｒ ２× Ｒ ２ ）这样的序列是不会出现的。 因为交替组合的序列不包含冗余部

分，所以 Ｔ ＣＣＲ 算法不会存在重复的工作。算法 １０．８　Ｔ ＣＣＲｉｎｐｕｔ：Ｒ １ ，Ｒ ２ ： 操作数关系

ｏｕｔｐｕｔ ： Ｔ ： 输出关系

ｄｅｃｌａｒｅ　 ＤＲ １ ，ＤＲ２ ： 关系

ｂｅｇ ｉｎ

·９２３·第十章　分布式数据库系统的发展趋势

　 ＤＲ １← Ｒ１× Ｒ ２

　 ＤＲ ２← Ｒ２× Ｒ １

　 Ｔ ← Ｒ １∪ Ｒ ２∪ ＤＲ １∪ ＤＲ ２

ｗ ｈｉｌｅ ＤＲ１不为空 ｏ ｒ ＤＲ ２不为空 ｄｏｂｅｇ ｉｎ　　　ＤＲ １←（ＤＲ１×Ｒ １ ）∪（ＤＲ １×Ｒ ２ ）　　　ＤＲ ２←（ＤＲ２×Ｒ １ ）∪（ＤＲ ２×Ｒ ２ ）ｅｎｄ－ ｗ ｈ ｉｌｅＴ ←Ｔ∪ＤＲ１∪ＤＲ ２ｅｎｄ．｛Ｔ ＣＣＲ｝例 １０．１２　以例 １０．６的 ｐａｒｅｎｔ 关系来举例说明 Ｔ ＣＣＲ。假定 ｐａｒｅｎｔ 可以分割为下面

的 ｐａｒｅｎｔ １ 和 ｐａｒｅｎｔ ２ ：ｐａｒｅｎｔ １ ： ｛（ｊｏｈｎ，ａｎｎ），（ｓａｒａｈ，ｃａｔｈ ｙ），（ｊｕｌｉｅｔ ｔｅ，ｃａｔ ｈｙ）｝ｐａｒｅｎｔ ２ ： ｛（ｃａｔ ｈｙ，ｊｏ ｈｎ），（ｍｉｃｈａｅｌ，ｊｏｈｎ）｝关系 ＤＲ １ 和 ＤＲ ２ 初始化为下面的新元组：ＤＲ １ ：｛（ｓａｒａｈ，ｊｏ ｈｎ），（ｊｕｌｉｅｔｔ ｅ，ｊｏｈ ｎ）｝ＤＲ ２ ：｛（ｃａｔ ｈｙ，ａｎｎ），（ｍｉｃｈａｅｌ，ａｎｎ）｝在算法的第一次迭代中，新的元组为

ＤＲ １ ：｛（ｓａｒａｈ，ａｎｎ），（ｊｕｌｉｅｔｔ ｅ，ａｎｎ）｝ＤＲ ２ ： 为空

后，第二次迭代没有产生新的元组，算法结束。３．并行操作的传递闭包算法

并行操作的传递闭包算法是 ＩＴ Ｃ 算法的并行版本。 关系 Ｒ 分簇于 ｎ 个站点上。Ｔ ＣＰＯ 算法采用散列连接算法来实现关系组合的连接操作，使用并（ｕｎｉｏｎ）操作来合并局

部执行的局部结果，从而来实现全局并操作，这样使得全局并操作所需的站点间通信

少。但是，其结果可能会在不同的站点包含有重复的元组，因此，需要消除那些有重复的元

组，然后求得传递闭包。为了简化 Ｔ ＣＰＯ 算法的描述，假定关系 Ｒ 和增量关系 ＤＲ 都有属性 Ａ 和 Ｂ，在 Ｒ 和

ＤＲ 上执行组合操作定义为

Ｒ × ＤＲ ＝ πＲ ．Ａ ，Ｄ Ｒ ．Ｂ （Ｒ ∞Ｂ＝ Ａ ＤＲ）此外，ｐａｒｔｉｔｉｏ ｎ（Ｒ，Ａ ）是指对关系 Ｒ 进行分割，是在属性 Ａ 上使用 ｈａｓｈ 函数 ｈ（Ａ ），

分簇于 ｎ 个站点上。 Ｔ ＣＰＯ 算法可以分为三个相继的阶段：初始阶段、处理阶段和结果阶

段。在初始阶段，操作 ｐａｒｔｉｔ ｉｏｎ（Ｒ，Ｂ）根据 Ｂ 上的 ｈａｓｈ 函数将关系 Ｒ 分布到 ｎ 个站点上。关系 Ｔ （输出关系）和 ＤＲ 也被初始化为 Ｒ。 处理阶段是并行连接操作和局部并操作的循

环。 由于 Ｒ 由作 用于属性 Ｂ 的 ｈａｓｈ 函数 ｈ （Ｂ ）来分割，并行连接 操作包括操 作

ｐａｒｔ ｉｔｉｏ ｎ（ＤＲ，Ａ ），因此，ＤＲ 的元组被移到了具有匹配元组的 Ｒ 的站点。 ＤＲ 元组在 ｎ 个

·０３３· 分布式数据库系统及其应用

站点上的分布是在每次循环中做的。 当 ＤＲ 为空时，循环终止。 因为 ＤＲ 在 ｎ 个站点上分

布，因此，终止测试必须在一个中央控制点上（是 ｎ 个站点中的一个）完成，该控制站点组

合来自于每个站点 ｉ （ｉ＝１，…，ｎ）的布尔值“ＤＲ 为空？”。 当所有的 ＤＲｉ 为空时，处理阶段

结束。结果关系 Ｔ 分布于 ｎ 个站点，并且在不同的站点上可能包含有相同的新元组。结果

阶段消除这些重复的元组，这可以通过一个并行基于 ｈａｓｈ 算法来实现。 Ｔ 首先根据一个

属性（如 Ａ）的 ｈ ａｓｈ 算法在 ｎ 个站点分片，此操作可能在 ｎ 个并行的消除操作后完成。 此

外，操作的结果分布在 ｎ 个站点上。例 １０．１３　图 １０．９举例说明了 ｎ＝４ 时，Ｔ ＣＰＯ 算法的初始和处理阶段。 处理阶段又

包括两个阶段。箭头表示了在每遍处理时站点之间的通信。从这个例子可以看出，并行执

行的度数是恒定的。

图 １０．９　带有并行操作的传递闭包

４．并行程序的传递闭包算法

将传递闭包操作分解为一组并行程序，每个程序使用 ＩＴ Ｃ 算法或 Ｔ ＣＣＲ 算法执行。Ｔ ＣＰＰ 算法分为两个阶段：初始阶段和处理阶段。 在初始阶段，使用 ＩＴ Ｃ 算法来产生传递

封闭关系；在处理阶段，使用 Ｔ ＣＣＲ 算法处理这个传递闭包关系。 在处理过程中，将 ｎ 个

传递闭包关系看做一棵二叉树，每次迭代做并操作，直到抵达树根。 与 Ｔ ＣＰＯ 算法相比

较，Ｔ ＣＰＰ 算法不需要达到恒定的并行度。 此算法使站点间的通信 少。 在初始阶段并行

度为 ｎ（关系 Ｒ 的分簇度），在处理阶段的每一遍中减半，直到为单个站点时结束操作。Ｔ ＣＰＰ 算法描述如下，为简单起见，假设 ｎ 是 ２ 的幂。 初始阶段使用 ＩＴ Ｃ 算法并行计

算 ｎ 个部分传递闭包。这 ｎ 个传递闭包关系在处理阶段使用两两合并操作进行组合，在该

操作中，ｎ 个站点被排列为一个二叉树。因此，处理阶段有 ｌｏ ｇ ２ｎ 遍，每遍对应于树的一级。在第 ｉ 遍，ｎ／２ｉ 站点接收来自于初始阶段（ｉ＝１时）或第 ｉ（ｉ＞１ 时）遍的两个传递封闭关

系，并对其实施 Ｔ ＣＣＲ 算法。 当第 ｌｏｇ ２ｎ－１遍时，只剩下两个站点，对两个传递封闭关系

·１３３·第十章　分布式数据库系统的发展趋势

实施 Ｔ ＣＣＲ 算法后，处理阶段结束。例 １０．１４　图 １０．１０举例说明了 ｎ＝４时两个处理阶段的 Ｔ ＣＣＲ 算法。箭头表示了站

点之间的通信。 为了使站点间通信 少，站点在二叉树中的安排如下，每一遍使用紧前一

遍处理使用的某些站点。 从本例可以看出，每一遍执行时并行度减半。

图 １０．１０　并行程序的传递终止

５．性能比较

在某些著作中，将并行传递闭包算法与集中式算法进行了性能的比较，所做的操作是

将所有操作数据移动到一个站点，然后操作终止。 性能比较表明，这些并行算法与集中式

算法相比，有显著的性能改善。 当站点数目较多（超过 １６个）和传递闭包将产生大量新的

元组时，改善的系数 大（可达 １ 到 ２ 个数量级）。 一般来说，算法 Ｔ ＣＰＯ（并行操作）的响

应时间比算法 Ｔ ＣＰＰ（并行程序）要好，原因是 Ｔ ＣＰＯ 的并行度始总为常数 ｎ，而 ＴＣＰＰ 的

并行度每遍都会减半。 相对于集中式算法，Ｔ ＣＰＰ 响应时间的改善为 １ 个数量级，而Ｔ ＣＰＯ 为 ２个数量级。 在综合考虑响应时间和总成本时，ＴＣＰＰ 比 Ｔ ＣＰＯ 的性能要好。

查询处理，尤其是递归查询处理，可能是识别使用逻辑知识库与关系数据库的关键。因此，近年来受到数据库研究人员的重视。前面讨论了无共享数据服务器如何通过并行来

提高递归查询的性能。 因为使用逻辑知识库是关系数据库的延伸，所以，前几章中提供的

大部分技术都可以成功使用。

１０．３　分布式面向对象数据库

面向对象数据库就是支持面向对象特性的数据库。其特殊之处在于，使用“对象”作为

基本建模原语。 面向对象的编程语言有 Ｓｍａｌｌｔａｌｋ 和 Ｃ＋＋。 面向对象数据库综合了面向

对象编程技术和数据库技术，它有下列优越性：

·２３３· 分布式数据库系统及其应用

１） 面向对象方法的强大建模能力和灵活性能够适应复杂数据库应用的设计，如ＣＡＤ 和办公信息系统等，而关系模型对此类应用的支持不佳。

２） 面向对象数据库提供高级数据库特性，如稳固的数据、面向集合的处理，以及事务

管理等。３） 也是 重要的，对于复杂的数据库应用可以完全用面向对象的数据库编程语言来

独立完成。 能够避免嵌入式查询语言中存在的失配问题，因为查询语言（例如 ＳＱ Ｌ ）是面

向集合的，通常是一次一个集合，与编程语言的一次一个记录不匹配。在传统的数据库技术中已经学习过面向对象数据库的一般概念，本节的重点放在介

绍分布式面向对象数据库技术方面。１０．３．１　面向对象数据库

与知识库相比，面向对象数据库还没有可以普遍接受的定义。在介绍分布式面向对象

数据库之前，首先回顾一下面向对象的主要特性，包括对象及对象标识、对象的封装性及

抽象数据类型、对象的继承性和操作符的多态性。１．对象及对象标识

关系数据库的一个重要特性就是使用统一的二维表方式来处理数据。 属性值是原子

单位，并用来构造结构值（元组和关系）。 在基于值的数据模型（关系模型）中，数据依靠值

来标识。 关系由名称来标识，元组由键值来标识。 这种标识数据的方法会产生一些问题，如数据冗余（外键引用），完整性约束支持，对复杂数据结构建模困难和更新的精确语

义等。在面向对象数据库中，一个典型的对象（ｏｂｊｅｃｔ ）有两个组成部分：一组实例属性值

（状态）和一组方法（行为），即该对象所能完成的操作。 因此，对象有些类似编程语言中的

程序变量，只不过典型的对象除了具有复杂的数据结构外，还包含程序员定义的具体操

作。一个属性值可以是一个对象或一个对象集合。通过聚合操作，可以构成任意复杂的对

象。每个对象都有一个对象标识（ｏｂｊｅｃｔ ｉｄｅｎｔｉｆｉｅｒ，ＯＩＤ），对象标识是永久区分一个对象与

其他对象的重要特性，ＯＩＤ 是对象的唯一名称。 对象的属性集合和方法集合表示了对象

的结构和行为。２．对象的封装性与抽象数据类型

在面向对象数据库中，对象的内容对外是透明的，外部只能通过对象接口发送消息与

其交互，而不需了解其内部的实现细节，这就是对象的封装性（ｅｎｃａｐｓｕｌａｔ ｉｏｎ）。 对象的封

装性可用抽象数据类型（ａｂｓｔ ｒａｃｔ ｄａｔ ａ ｔｙｐｅｓ， ＡＤＴ ｓ）来描述。一个抽象数据类型是通过提供具有相同结构的数据的值域来描述数据的类型，同时

也包括对该域中元素所能实施的操作。 封装是 ＡＤＴ ｓ 的抽象特性，它隐藏了操作的实施

细节，可以使用通用编程语言来编写。 ＡＤＴ ｓ 为其用户提供调用接口，包括数据结构和操

作命令，在操作中可带有输入和输出参数。例 １０．１５　假定 ＡＤＴ “ｍｏｎｅｙ”有下面的界面类型：

·３３３·第十章　分布式数据库系统的发展趋势

　　 ｍｏｎｅｙ－ ａｍｏｕｎｔ ＝ ［ｃｕｒｒｅｎｃｙ：ｓ ｔｒ ｉｎｇ，ａｍｏｕｎｔ ：ｆｌｏａｔ ］和操作：

　　 ｃｏｎｖｅｒｔ（ｓ：ｓ ｔｒ ｉｎｇ）：ｍｏｎｅｙ － ａｍｏｕｎｔ　　 ｅｘｃｈａｎｇｅ（ｍ：ｍｏｎｅｙ － ａｍｏｕｎｔ，ｃｕｒｒｅｎｃｙ：ｓ ｔｒ ｉｎｇ）：ｍｏｎｅｙ － ａｍｏｕｎｔ第一个操作转换输入字符串（如“＄９００００．９９”）为 ｍｏｎｅｙ － ａｍｏｕｎｔ，第二个操作将给

定的 ｍｏｎｅｙ － ａｍｏｕｎｔ 兑换为特定的其他类货币。 ＡＤＴ ｍｏｎｅｙ 的用户不需要了解外汇兑

换是如何实现的。ＡＤＴ ｓ 的封装性有两大优点：１） 系统提供的基本数据类型可以很容易地扩充为用户定义的数据类型；２） ＡＤＴ 操作使应用程序与其相关数据的联系更紧密。 因此，ＡＤＴ 的对象模型允许

同时对数据和操作进行建模。３．对象的继承性（ｉｎｈｅｒｉｔａｎｃｅ）具有相同结构特性和操作特性的对象可以构成对象类（ｃｌａｓｓ），对象类中的每个对象

称为该对象类中的一个事例（ｉｎｓｔ ａｎｃｅ）。 面向对象编程使得对象类可以组织为层次结构，这样就可以在对象间共享数据结构和操作。在层次结构中，上层节点是下层节点的父节点

或祖先节点，其对应的类称为超类（ｓｕｐｅｒｃｌａｓｓ）；下层节点和叶子节点对应的类称为子类

（ｓｕｂｃｌａｓｓ），它至少具有与它的父节点或祖先节点对应的类相同的数据属性和操作，这就

是继承性，还具有与其兄弟或祖先不同的特殊的属性和操作，这就是扩充性。 类层次的概

念允许使用简明方式来对类之间相同特性和不同特性进行建模，它在表达数据之间的语

图 １０．１１　对象类的继承和扩充

义关系方面比关系模型更加丰富。例 １０．１６　如图 １０．１１所示，所有文件构成一个超类，它的两个子类“可打印文件”和

“可执行文件”继承了它的所有属性：文件名，字节数，Ｃ／Ｍ 日期；和它的所有操作：显

·４３３· 分布式数据库系统及其应用

示（ ），修改（ ）。子类“可打印文件”还增加了属性：打印机，增加了操作：打印（ ）； 子类“可执行文件”增加了操作：执行（ ）。

对象的继承性从本质上消除了代码冗余，改进了程序的模块性，从而便于维护。但是，并不总是希望使用祖先类的操作，即使是在功能相同的情况下。例如，需要显示“可打印文

件”的所有属性，而不仅仅是祖先类的文件名、字节数、Ｃ／Ｍ 日期。解决这个问题的一个简

单方法是定义一个不同名称的操作，例如 ｄｉｓｐｌａｙ － ｐｒｉｎｔｆ ｉｌｅ。 这种方法要求程序员在不同

的类之间维护做相同事情的不同操作名称。４．操作符的多态性（ｐｏｌｙｍｏ ｒｐｈｉｓｍ ）另一个面向对象的特性是操作符的多态性，多态性指的是一个操作符可以被应用于

不同对象类型的能力。 在这种情况下，同一个操作符名可能对应于好几个不同的操作实

现，到底对应哪一个实现依赖于应用该操作符的对象类型。 这个特征也称为操作符重载

（ｏｐｅｒａｔｏ ｒ ｏｖ ｅｒｌｏａｄｉｎｇ）。 例如，一个计算几何对象面积的操作可能有不同的方法（实现），到底采用哪种实现依赖于几何对象的类型，也就是说依赖于这个对象是三角形、圆形还是

矩形。 这就要求在运行时刻，知道了应用操作的对象类型后，用滞后绑定（ｌａｔ ｅ ｂｉｎｄｉｎｇ）把操作绑定到适当的方法上。１０．３．２　分布式对象管理

１．分布式面向对象数据库

　　面向对象数据库和分布式数据库是两个正交的概念，两者的有机结合产生了分布式

面向对象数据库。 虽然，分布式面向对象数据库还处在幼年时期，但已显示了如下三个

优点：１） 与关系数据库相似，分布式面向对象数据库可以达到高可用性和高性能。２） 面向对象数据库的应用一般都高度分布，例如，大型应用一般会涉及互相协作的

各种人员和分布的计算设施，分布式面向对象数据库能很好适应这种环境。３） 隐藏信息的特性使得面向对象的数据库成为支持异构数据库的自然候选，而异构

数据库一般都是分布的，因此分布式面向对象数据库是其 好的选择。分布式面向对象数据库的设计将具有来自于分布式关系数据库和面向对象数据库两

方面所获得的经验，因为它们中的很多问题都是正交的。 例如，用于分布式事务管理的技

术可以用于集中式面向对象数据库中。２．分布式对象存储

分布式对象存储是负责分布式对象存储和访问的系统模块。 它可以被看作对象管理

模块的扩充，能够在分布式环境下处理物理聚簇和对象定位。 特别，局部对象的物理聚簇

和对象定位可以使用复杂对象存储方法。如何使对象分布有效和透明是很复杂的问题，大多数为分布式环境所设计的面向对象系统，采用让程序员掌握对象的位置来简化这一问

题。 但是，这种方法在分布式面向对象数据库中是不可行的，因为要实现系统的高可用性

·５３３·第十章　分布式数据库系统的发展趋势

和高性能，分布式对象管理器应该支持对象分布的位置透明性和分布式程序执行。在分布

式关系数据库中，全局对象可以被分片或分簇，使得事务可以在数据的存储站点并行执

行。对复杂对象分簇可以基于复杂对象的上层属性值或对象标识。持久对象（存储在外存

中的对象）的分布信息可以存放在全局目录中。分布式数据管理器主要负责对全局对象的

标识和对对象共享的支持。持久对象的全局标识类似于在分布式环境下的全局唯一文件名。 一种流行的方法是

使用代理来实现全局对象标识。 一个代理由对象生成站点的站点标识和该站点上计数器

值的串接组成。瞬时对象（存放在内存中的对象）的全局标识涉及面更广，主要问题在于采

用无共享结构的系统，无法提供对所有站点来说为全局的物理地址空间。 因此，使用集中

式对象管理的方法无法采用，解决这一问题的两种可能采用的方法。第一种方法是为基于瞬时对象的每个事务建立一个全局间接表（ｉｎｄｉｒｅｃｔｉｏｎ ｔａｂｌｅ ）。

当执行某个事务时，间接表被分布到与该事务执行有关的所有站点。 在事务初启时，计数

器清零，通过将对象产生站点标识和站点计数器值串接，使得瞬时对象标识 ＯＩＤ 在事务

中全局唯一。 间接表将每个瞬时对象标识与其物理标识相关联。 每个事务执行的站点都

有一个间接表，它 初只包含由本地产生的那些 ＯＩＤ。 当对象从其他站点迁移到本站点

时，在间接表中登记上该对象的 ＯＩＤ 和新的物理标识。 一个瞬时对象可能会通过不同的

路径到达相同的站点好几次。 例如，对象 ｏ 到达站点 ３两次。 这样多次进入会导致在间接

表中外来的同一个 ＯＩＤ 会有多个重复值，需要消除这些重复的 ＯＩＤ，对于按照 ＯＩＤ 散列

方式建立的间接表，这很容易实现。因为对象可以在事务执行中移动，因此，这种方法被普遍地使用。然而，它会碰到与持

久对象相类似的那些问题。 首先，间接表可能会相当大，它需要占用的空间可能会是瞬时

对象的两倍。其次，不可能在内存中对复杂对象聚簇，因为其中的对象一次只存取一个。另外，对对象共享的支持，在存在更新的情况下，可能会导致矛盾。

例 １０．１７　设对象 ｏ １ 被对象 ｏ ２ 和 ｏ ３ 共享。 假设对象 ｏ ３ （连同其子对象 ｏ １ ）被移动到

站点 ２ 并且改变了 ｏ１ 的值。 这时，在两个不同的站点，相同的对象就会有不同的值。 站点

１的值为原始值，而站点 ２有 ｏ１ 的新值，这与对象的基本定义相抵触。 如果站点 １ 和站点

２上的 ｏ １ 的值相继被使用，就会产生矛盾。解决上述问题的一个方法是在程序执行中自动更新共享对象。 在更新之后，对象 ｏ １

的新值被发送到站点 １。 然而，这会造成在站点 １和站点 ２ 上的执行程序的同步问题，因为，在站点 １上的旧值被更新期间，程序不能使用 ｏ１ 的值，而此时站点 ２ 上的新值还未被

送到站点 １。 解决此问题的另一个方法是避免可能会更新的共享对象的移动。第二种方法采用瞬时对象的对象标识建立在物理标识的基础上，并且对象迁移由数

据库语言的编译器进行限制。 这种方法避免了使用管理间接表所造成的有关花费。３．分布式对象查询

分布式对象查询处理负责有效地处理对于分布式面向对象数据库的查询。 这是一个

全新的研究领域，在这方面的可用信息很少。 采用支点算法（ｐｉｖｏ ｔ ａｌｇ ｏｒｉｔ ｈｍ）处理在并行

环境下的复杂对象。当全局对象被分片到分布式系统中的多个站点时，可以利用关系数据

·６３３· 分布式数据库系统及其应用

库的分布式查询优化技术，只需对其作少许改变。 下面将讨论在关系数据库存储，或在复

杂对象存储情形下的分布式对象查询处理。在关系数据库存储情形下，与集中方式相类似，使用关系数据库存储的分布式对象查

询处理相当简单。首先将对象上的概念查询映射到分布式关系数据库的全局关系查询；然后，余下的问题就与关系数据库的分布式查询处理相同，对全局关系的查询映射到对相应

片段的查询，从而得到优化，完成查询。在复杂对象存储情形下，查询处理算法可以基于 Ｒ中所使用的枚举方法，唯一区别

是在对复杂对象访问方法的选择上。 使用扩展的 Ｒ算法，产生线性的关系代数树（查询

树或语法树）。 换言之，二元操作（例如 ｊｏ ｉｎ）的输入 多是一个瞬时对象。 因此，不同的选

择和连接操作不能并行执行，而应串行执行。 此时可采用支点算法，以提供操作内和操作

间的并行性，只需对支点阶段作相应的修改就可以处理复杂对象。 因为单个支点 Ｔ ＩＤ 只

适用于线性或平面的情况，对于嵌套层次的情况，就不能只选择一个支点 Ｔ ＩＤ，应对每一

嵌套层都必须有一个支点 Ｔ ＩＤ。另外，因为与关系的支点算法相对而言，复杂对象很少需要进行连接操作，所以可以

使用路径索引作为辅助索引。

１０．４　对象关系数据库

前面我们已经指出，分布式数据库系统通常采用关系数据模型，分布式数据库管理系

统也通常是关系数据库管理系统。 本节讨论商业 ＤＢＭ Ｓ 新出现的类型，它们被称为对

象关系系统（ｏｂｊｅｃｔｒｅｌａｔ ｉｏｎａｌ ｓｙ ｓｔ ｅｍｓ）或增强关系系统（ｅｎｈａｎｃｅｄ ｒｅｌａｔｉｏｎ ａｌ ｓｙｓ ｔｅｍｓ），以及用于这些系统的一些基础概念。 这些系统，通常被称为对象关系 ＤＢＭ Ｓ （ＯＲＤＢＭ Ｓ ），是作为增强关系 ＤＢＭ Ｓ（ＲＤＢＭ Ｓ）性能的一种方法出现的，它们具有在对象

ＤＢＭ Ｓ（ＯＤＢＭ Ｓ）中出现的某些特征。本节将重点介绍 ＳＱＬ ３ 语言对对象关系的支持，ＳＱＬ ３ 是 ＳＱＬ 标准的一个新版本，

它通过合并对象数据库和其他特征，诸如扩展数据类型，来扩展 ＳＱＬ ２ （或 ＳＱＬ９２）。后，我们还会简要讨论嵌套关系模型，它起源于一系列的研究提议和原型实现；同时嵌套

模型还提供了一种在关系框架内部嵌入具有分层结构的复杂对象的方法。１０．４．１　对象关系数据库系统产生背景

在今天的商业应用中，有许多可用的 ＤＢＭ Ｓ 产品家族。占统治地位的有两个，它们是

ＲＤＢＭ Ｓ 和 ＯＤＢＭ Ｓ，分别支持关系数据模型和对象数据模型。传统基本关系数据模型以及早期的 ＲＤＢＭ Ｓ，面对数据库的新应用的挑战时却无能

为力。这些挑战主要包含多种数据类型的应用领域。例如，计算机辅助桌面排版系统中的

大文本，人造卫星成像或天气预报中的图像，工程设计、生物基因组信息，建筑图中复杂的

非常规数据，股票市场交易历史或卖出历史中的时间序列数据，以及地图、空气／水污染数

据和业务数据中的空间和地理数据。因此，很清楚需要设计某些数据库，它们可以开发、操纵和维护来自这些应用的复杂对象。 而且，还需要为处理表示音频和视频数据流（划分成

·７３３·第十章　分布式数据库系统的发展趋势

单独的帧）的数字化信息而要求在 ＤＢＭＳ 中存储二进制大对象（ＢＬＯＢ）。商业 ＤＢＭ Ｓ 坚固的基础结构帮助了关系模型的普及，而原本商业 ＤＢＭ Ｓ 的设计就是

用于支持关系模型的。然而，在面对上述挑战时，基本关系模型及其 ＳＱ Ｌ 语言的早期版本

被证明是不适用的。像网状数据模型这样的传统数据模型可以明确地对联系建模，但是在

执行方面它们却需要使用大量的指针，而且不具备对象标识、继承、封装这类概念，也没有

对多种数据类型和复杂对象的支持能力。 层次模型可以很好地适用于在组织中自然发生

的分层结构，但是它在数据中的内置层次路径上太过局限和固定。因此，产生了一种趋势，这种趋势是将对象数据模型的特征和语言结合到关系数据模型中，这样，关系数据模型可

以被扩展，使它能够处理今天各种新应用的挑战。１９９０ 年以 Ｍ ｉｃｈａｅｌ Ｓｔｏｎｅｂｒａｋｅｒ 为首的高级 ＤＢＭＳ 功能委员会发表了枟第三代数据

库系统宣言枠的文章，按照该篇文章的思想，一个面向对象数据库系统必须保持第二代数

据库系统的非过程化数据存取方式和数据独立性，即应继承第二代数据库系统已有的技

术，不仅能很好地支持对象管理和规则管理，而且能更好地支持原有的数据管理。对象关系数据库系统就是按照这样的目标将关系数据库系统与面向对象数据库系

统两方面的特征相结合而产生的。为了了解为什么会出现对象关系数据库系统，我们将注意力集中在对 ＤＢＭ Ｓ 应用

进行分类的方法上，它通过二维坐标轴来划分：①数据的复杂性——Ｘ维，②查询的复杂

性——Ｙ维。 我们可以将这两个坐标轴排列成一个简单的 ０１空间，它们具有四个象限：象限 １ （Ｘ＝０，Ｙ＝０）：简单数据，简单查询；象限 ２ （Ｘ＝０，Ｙ＝１）：简单数据，复杂查询；象限 ３ （Ｘ＝１，Ｙ＝０）：复杂数据，简单查询；象限 ４ （Ｘ＝１，Ｙ＝１）：复杂数据，复杂查询。传统的 ＲＤＢＭ Ｓ 属于象限 ２。虽然它们支持特别复杂的查询和更新（如同事务处理一

样），但是却只能处理简单的，可以被设计成表中的一组行的数据。许多对象数据库系统位

于象限 ３，因为它们集中管理复杂数据，但是在基于导航的查询能力方面却有所局限。 为

了要往第四象限里移动，以求能够同时支持复杂数据和复杂查询，ＲＤＢＭ Ｓ 结合了更多的

复杂数据对象，而 ＯＤＢＭ Ｓ 则结合了更多的复杂查询。从 ＲＤＢＭ Ｓ 演化而来的 ＯＲＤＢＭ Ｓ，包括 Ｏｒａｃｌｅ 公司的 Ｏｒａｃｌｅ ８，ＩＢＭ 的 Ｕ ｎｉｖｅｒｓａｌ ＤＢ （ＵＤＢ），Ｉｎｆｏ ｒｍ ｉｘ 公司的 Ｕ ｎｉｖｅｒｓａｌＳ ｅｒｖ ｅｒ，Ｈｅｗ ｌｅｔ ｔ Ｐａｃｋａｒｄ 的 Ｏｄａｐｔ ｅｒ 等属于象限 ４，因为它们结合了多种使它们成为对

象关系的特征，并以此扩展了它们的基本关系模型，使它们既支持复杂查询又能够处理

复杂数据。Ｍ ｉｃｈａｅｌ Ｓ ｔｏｎｅｂｒａｋｅｒ 还通过一个示例分析，提出他自己的观点：①对象关系 ＤＢＭ Ｓ

适合第四象限的应用；②若干年后，大部分应用在第四象限中。 他还指出“对象关系系统

是未来的发展方向。”而且，一个真正的对象关系系统首先是一个真正的关系系统。１０．４．２　对象关系数据库系统的特点

对象关系数据库系统除了具有原来关系数据库的各种特点外，还应该提供以下

·８３３· 分布式数据库系统及其应用

特点：１．扩充数据类型

目前的商品化 ＲＤＢＭＳ 只支持某一固定的类型集，不能依据某一应用所需的特定数

据类型来扩展其类型集。对象关系数据库系统允许用户在关系数据库系统中扩充数据类

型，即允许用户根据应用需求自己定义数据类型、函数和操作符。例如，某些应用涉及三维

向量，系统就允许用户定义一个新的数据类型三维向量 ｖｅｃｔｏ ｒ，它包含三个实数分量，而且一经定义，这些新的数据类型、函数和操作符将存放在数据字典中，可供所有用户共享，如同基本数据类型一样。 例如可以定义数组、向量、矩阵、集合等数据类型，以及这些数据

类型上的操作。２．支持复杂对象

能够在 ＳＱＬ 中支持复杂对象。复杂对象是指由多种基本数据类型或用户自定义的数

据类型构成的对象。３．支持继承、封装的概念

能够支持子类、超类的概念，支持继承的概念，包括属性数据的继承和函数及过程的

继承；支持单继承与多重继承；支持函数重载（操作的重载）；保持封装的优点，但针对的是

关系中的标量值而非关系本身。４．提供通用的规则系统

能够提供强大而通用的规则系统。 规则在 ＤＢＭ Ｓ 及其应用中是十分重要的，在传统

的 ＲＤＢＭ Ｓ 中用触发器来保证数据库数据的完整性。触发器可以看成规则的一种形式。对象关系数据库系统要支持的规则系统将更加通用，更加灵活，并且与其他的对象关系能

力是集成为一体的，例如规则中的事件和动作可以是任意的 ＳＱ Ｌ 语句，可以使用用户自

定义的函数，规则能够被继承等。这就大大增强了对象关系数据库的功能，使之具有主动

数据库和知识库的特性。１０．４．３　ＳＱＬ３标准对对象－关系系统的支持

本节将着重讨论 ＳＱ Ｌ ３标准扩展了 ＳＱ Ｌ９２，使它包含了面向对象的特征，以支持对

象关系系统，以及与此有关的 ＳＱＬ ３特征。 ＳＱＬ ３标准包括以下部分：１） ＳＱＬ／框架，ＳＱ Ｌ／基础，ＳＱＬ／捆绑，ＳＱＬ／对象；２） ＳＱＬ／时序，ＳＱ Ｌ／事务说明；３） ＳＱＬ／ＣＬ Ｉ（调用层接口）；４） ＳＱＬ／ＰＳＭ （永久存储模块）。ＳＱＬ／基础处理的是新的数据类型、新的谓词、关系操作、游标、规则和触发、用户定义

类型、事务性能和存储例程。 ＳＱ Ｌ／ＣＬＩ（调用层接口）提供了某些规则，用于同 ＳＱＬ 服务

·９３３·第十章　分布式数据库系统的发展趋势

器进行连接，申请和释放资源，获得诊断和执行信息，以及控制事务终止。 ＳＱ Ｌ／ＰＳＭ （永久存储模块）指定在客户机和服务器之间划分应用的设施，其目的就是通过 小化网络信

息流通量来增强性能。ＳＱＬ／捆绑包括嵌入式 ＳＱＬ 和类似于 ＳＱ Ｌ９２中的直接调用。增强

后的嵌入式 ＳＱＬ 包含了附加的异常说明。ＳＱ Ｌ／时序处理历史数据、时间序列数据和其他

时序扩展。 ＳＱＬ／事务说明规范化供 ＳＱＬ 实现者使用的 ＸＡ 接口。１．ＳＱＬ ３ 中的对象

在 ＳＱＬ／基础和 ＳＱＬ／对象的说明中，ＳＱ Ｌ ３允许用户定义数据类型、类型构造器、汇集类型、用户定义函数和过程、对大对象的支持以及触发器。 在 ＳＱＬ ３中的对象具有两种

类型：１） 行或者元组类型，它们的实例是表中的元组。 一个行类型（ｒｏｗ ｔｙｐｅ）可以使用如

下语法定义：ＣＲＥＡ Ｔ Ｅ ＲＯＷ Ｔ ＹＰＥ ｒｏｗ － ｔｙ ｐｅ－ ｎａｍｅ （枙ｃｏｍｐｏｎｅｎｔ ｄｅｃｌａｒａｔｉｏｎｓ枛）；

２） 抽象数据类型（缩写成 ＡＤＴ ），它是任意的通用类型，可以作为元组的分量。 提供

一个类似于类定义的构造，通过它用户可以创建指定的带有自身行为说明和内部结构的

用户定义类型。 一个 ＡＤＴ 定义的一般形式为

ＣＲＥＡＴ Ｅ Ｔ ＹＰＥ 枙ｔｙ ｐｅ－ ｎａｍｅ枛 （　　 带有单个类型的成员属性列表

　　 ＥＱＵＡＬ 和 ＬＥＳＳ Ｔ ＨＡＮ 函数的声明

　　 其他函数（方法）的声明

　　　　　　　　　）；２．ＳＱＬ ３ 中的继承、重载和函数的解的规则

ＳＱＬ ３ 具有处理继承（通过关键字 ＵＮＤＥＲ 来指定）、重载和函数的解的规则，可以把

它们小结如下。（１） 继承

１） 所有属性都被继承。２） 在 ＵＮＤＥＲ 子句中超类的顺序决定了继承层次。３） 子类的实例可以被用在每个使用了它的超类实例的语境中。（２） 重载

子类可以重新定义任何在它的超类中被定义的函数，但是它具有一个限制，即命名是

相同的。（３） 函数的解

１） 当一个函数被调用时， 好的匹配将基于所有变元类型的选择。２） 对于动态连接，将考虑运行时间的类型参数。

·０４３· 分布式数据库系统及其应用

３．ＳＱＬ ３ 支持汇集类型的构造器

ＳＱＬ ３ 支持汇集类型的构造器，它可以用于创建复杂对象的嵌套结构。 它支持列表、集合、多重集合作为内置类型构造器。 这些类型构造器的变元可以是任意其他类型，包括

行类型、ＡＤＴ 以及其他汇集类型。可以将这些类型的实例当作对于查询目的的表处理。通过与 ＳＱＬ ３中的导出表相关联，汇集可以是非嵌套的。

４．ＳＱＬ ３ 中的超表／子表功能

ＳＱＬ ３ 中另一个支持对象关系的功能是超表／子表功能，它并不等价于超类和子类，而且也没有假定它们是可替换的。 但是，子表继承它的超表中的每一列，子表中的每一行

对应于超表中的一行而且只是一行。在超表中的每一行至多对应于子表中的一行。插入、删除和更新操作都可传播。 例如，考虑如下定义的表 ｒｅａｌ－ ｅｓｔａｔ ｅ－ ｉｎｆｏ：

　　 ＣＲＥＡＴ Ｅ Ｔ ＡＢＬＥ ｒｅａｌ－ ｅｓｔ ａｔｅ－ ｉｎｆｏ（ｐｒｏｐｅｒｔ ｙ ｒｅａｌ－ ｅｓｔ ａｔｅ，ｏｗ ｎｅｒ ＣＨＡＲ（２５），ｐｒｉｃｅ Ｍ ＯＮ ＥＹ，）；

可以定义下列子表：　　ＣＲＥＡＴ Ｅ Ｔ ＡＢＬＥ ａｍｅｒｉｃａｎ－ ｒｅａｌ－ ｅｓ ｔａｔｅ Ｕ Ｎ ＤＥＲ ｒｅａｌ－ ｅｓｔａｔ ｅ－ ｉｎｆｏ；　　ＣＲＥＡＴ Ｅ Ｔ ＡＢＬＥ ｇｅｏｒｇ ｉａ－ ｒｅａｌ－ ｅｓｔ ａｔｅ Ｕ ＮＤＥＲ ａｍｅｒｉｃａｎ － ｒｅａｌ－ ｅｓ ｔａｔ ｅ；　　ＣＲＥＡＴ Ｅ Ｔ ＡＢＬＥ ａｔ ｌａｎｔａ－ ｒｅａｌ－ ｅｓ ｔａｔ ｅ Ｕ Ｎ ＤＥＲ ｇｅｏ ｒｇ ｉａ－ ｒｅａｌ－ ｅｓｔａｔ ｅ；

１０．４．４　扩展类型系统的实现以及相关问题

对于具有关联函数（操作）的扩展类型系统的支持，会出现不同的实现问题，现将这些

问题总结如下。１） 仅仅当需要时，ＯＲＤＢＭ Ｓ 才必须动态地将一个用户定义函数连接到它的地址空

间上。 因为，如果对所有函数库进行静态连接，ＤＢＭ Ｓ 地址空间就会以数量级的方式增

加，所以，ＯＲＤＢＭ Ｓ 中动态连接是有效的做法。２）客户机／服务器问题涉及函数的放置和激活（ｐｌａｃｅｍｅｎｔ ａｎｄ ａｃｔ ｉｖａｔ ｉｏｎ）。如果服务

器需要执行一个函数，因为将有大量的开销，所以 好在 ＤＢＭ Ｓ 地址空间中执行而不是

远程执行。如果函数需要非常集中的计算或者服务器正处理非常大量的客户机，那么服务

器可以将该函数发送给一个单独的客户机。由于安全的原因， 好在客户机端使用该客户

机的用户 ＩＤ 来运行函数。 在将来也可能会用解释语言比如 Ｊａｖａ 来编写函数。３） 应该有可能在函数中执行查询。 无论是通过应用程序编程接口执行函数，或是由

ＤＢＭ Ｓ 调用在 ＳＱ Ｌ 语句中嵌入函数，作为执行 ＳＱＬ 的一部分，函数都必须以相同的方法

操作。 系统应该支持这些“回调（ｃａｌｌ ｂａｃｋ）”的嵌套。

·１４３·第十章　分布式数据库系统的发展趋势

４） 由于在 ＯＲＤＢＭＳ 和关联的操作符中存在各种不同的数据类型，高效的存储和数

据存取是很重要的。 对于空间数据或是多维数据，可以使用新的存储结构比如 Ｒ 树、四叉

树或者网格文件。 ＯＲＤＢＭ Ｓ 必须允许定义带有新存储结构的新的类型。许多存储和搜索

选项都是在对大文本串或者二进制文件的处理中发展起来的，而且可以通过在 ＯＲＤＢＭ Ｓ内部定义新的数据类型来探索这些新的选项。

５） 关于对象关系系统的其他问题。 在这里，我们在 ＯＲＤＢＭ Ｓ 的语境中考虑其他一

些显而易见的问题：对象关系数据库设计，查询处理和优化，规则和事务的交互，触发器

的延迟执行等。１０．４．５　嵌套关系数据模型

嵌套关系模型（ｎｅｓｔｅｄ ｒｅｌａｔｉｏｎａｌ ｍｏｄｅｌ）消除了基本关系模型中第一范式（１ＮＦ ）的限

制，因此也被称为非 １Ｎ Ｆ 或非第一范式（Ｎ ＦＮ Ｆ）或 Ｎ Ｆ ２ 关系模型。 基本关系模型也被称

作平面关系模型（ｆｌａｔ ｒｅｌａｔ ｉｏｎａｌ ｍｏｄｅｌ），要求属性是单值的并且具有原子域（不可再分

性）。嵌套关系模型允许复合和多值属性，因此可以产生具有层次结构的复杂元组，这对于

表示本身就是层次结构的对象很有用处。 在图 １０．１２ 中，（ａ）部分给出了一个嵌套关系模

式 ＤＥＰＴ ，它基于的是 ＣＯＭ ＰＡＮＹ 数据库的一部分，而（ｂ）部分给出了 ＤＥＰＴ 中一个非

１ＮＦ 元组的例子。为了将 ＤＥＰＴ 模式定义成一个嵌套结构，可以编写：ＤＥＰＴ ＝ （ ＤＮＯ， ＤＮＡＭ Ｅ， Ｍ ＡＮＡＧＥＲ， ＥＭ ＰＬＯＹＥＥＳ， ＰＲＯＪＥＣＴ Ｓ，

ＬＯＣＡ Ｔ ＩＯＮ Ｓ）ＥＭ ＰＬＯＹＥＥ＝（ＥＮＡＭＥ ， ＤＥＰＥＮＤＥＮ Ｔ Ｓ）ＰＲＯＪＥＣＴ＝（ＰＮＡＭ Ｅ， ＰＬＯＣ）ＬＯＣＡ Ｔ ＩＯＮＳ＝（ＤＬＯＣ）ＤＥＰＥＮＤＥＮＴ Ｓ＝（ＤＮＡＭ Ｅ， ＡＧＥ ）首先，定义 ＤＥＰＴ 关系的所有属性。 下一步，定义所有的 ＤＥＰＴ 的嵌套属性，即

ＥＭ ＰＬＯＹＥＥＳ、 ＰＲＯＪＥＣＴ Ｓ 和 ＬＯＣＡ Ｔ ＩＯＮＳ。 然后，定义所有的第二层嵌套属性，例如

ＥＭ ＰＬＯＹＥＥＳ 的 ＤＥＰＥＮＤＥＮ Ｔ Ｓ，以此类推。 在嵌套关系定义中所有的属性名必须是不

同的。 一个嵌套属性是一个典型的多值复合属性（ｍｕｌｔ ｉｖａｌｕ ｅｄ ｃｏｍｐｏｓｉｔｅ ａｔ ｔｒ ｉｂｕｔ ｅ），因此

在每个元组内部将产生一个“嵌套关系”。 例如，在每个 ＤＥＰＴ 元组内部 ＰＲＯＪＥＣＴ Ｓ 属性

值都是一个带有两个属性（ＰＮＡＭ Ｅ，ＰＬＯＣ）的关系。 在图 １０．１２（ｂ）的 ＤＥＰＴ 元组中，ＰＲＯＪＥＣＴ Ｓ 属性包含三个具有这样属性值的元组。其他的嵌套属性可能是多值简单属性

（ｍｕｌｔ ｉｖａｌｕｅｄ ｓ ｉｍｐｌｅ ａｔｔｒ ｉｂｕｔ ｅ），例如 ＤＥＰＴ 的 ＬＯＣＡＴ ＩＯＮ Ｓ。 嵌套属性也可能同时是单

值（ｓｉｎｇ ｌｅｖａｌｕｅｄ）和复合（ｃｏｍｐｏｓｉｔ ｅ）的，虽然大多数嵌套关系模型认为这样的属性好像

应该是多值的。当定义一个嵌套关系数据库模式时，它由许多外部关系模式组成，这些外部关系模式

定义的是嵌套关系的顶层。 另外，嵌套属性也被称作内部关系模式（ｉｎｔｅｒｎａｌ ｒｅｌａｔ ｉｏｎ

·２４３· 分布式数据库系统及其应用

ｓｃｈｅｍａｓ），因为它们定义的关系结构是被嵌套在另一个关系内部的。 在这个例子中，ＤＥＰＴ 是唯一的外部关系。 其他的关系：ＥＭ ＰＬＯＹＥＥＳ， ＰＲＯＪＥＣＴ Ｓ， ＬＯＣＡＴ ＩＯＮ Ｓ 和

ＤＥＰＥＮＤＥＮＴ Ｓ，都是内部关系。 后，简单属性出现在叶子层，它们不是嵌套的。 我们可

以通过使用一个树结构来表示每个关系，如图 １０．１２（ｃ）所示，图中根就是一个外部关系

模式，叶子就是简单属性，而内节点是内部关系模式。

ＤＮ Ｏ ＤＮ ＡＭ Ｅ Ｍ ＡＮ Ａ ＧＥＲＥＭ ＰＬ ＯＹＥ ＥＳ ＰＲＯ ＪＥ ＣＴ Ｓ ＬＯ ＣＡ Ｔ ＩＯＮ Ｓ

Ｅ ＮＡ Ｍ ＥＤＥＰＥＮ ＤＥＮ Ｔ Ｓ

ＤＰＮ Ａ Ｍ Ｅ Ａ ＧＥ ＰＮ Ａ Ｍ Ｅ ＰＬ ＯＣ ＤＬＯ Ｃ

（ａ）４ ａｄｍ ｉｎｉｓｔ ｒ ａｔ ｉｏｎ ｗ ａｌｌａ ｃｅ

Ｚｅｌ ａｙａ

ｗ ａｌｌ ａｃｅ

Ｊａｂｂａｒ

Ｔ ｈｏｍ ａ ｓＪｅｎｎｆｅｒＪｅｃｋＲｏ ｂｅｔ ｒＭ ａｒｙ

８６１８１０

Ｎ ｅｗ Ｂｅｎｅｆ ｉｔ ｓＣｏｍｐｕｔｅｒ ｚａｔ ｉｏ ｎ

Ｐｈｏ ｎｅＳｙ ｓｔ ｅｍ

ｓ ｔ ａｆ ｆ ｏｒ ｄｓ ｔ ａｆ ｆ ｏｒ ｄ

Ｇ ｒｅｅｎｗ ａｙ

ｓ ｔ ａｆ ｆ ｏ ｒｄＧ ｒｅｅｎｗ ａｙ

（ｂ）

图 １０．１２　举例说明一个嵌套关系

（ａ）ＤＥ ＰＴ 模式；（ｂ）ＤＥ ＰＴ 的一个非 １Ｎ Ｆ 元组的例子 ；（ｃ）ＤＥＰＴ 模式的树表示

重要的是要意识到：在 ＤＥＰＴ 中的三个第一层嵌套关系表示的是独立信息。 因此，ＥＭ ＰＬＯＹＥＥＳ 表示为某部门工作的雇员，ＰＲＯＪＥＣＴ Ｓ 表示由某部门控制的项目，而ＬＯＣＡ Ｔ ＩＯＮＳ 表示的是不同部 门的位置。 在模式中并没有表 示 ＥＭ ＰＬＯＹＥＥＳ 和

ＰＲＯＪＥＣＴ Ｓ 之间的联系，因为它们之间是 Ｍ∶Ｎ 的联系，这很难在层次结构中被表示

出来。在嵌套关系中已经计划使用关系代数的扩展和关系计算的扩展，以及 ＳＱ Ｌ 的扩展。

这里，我们举例说明两个操作 ＮＥＳＴ 和 ＵＮＮＥＳＴ ，它们可以用于扩充标准关系代数操

作，实现在嵌套关系和平面关系间进行转换。 考虑图 １０．１３（ａ）的平面关系 ＥＭ Ｐ － ＰＲＯＪ，假定将它在 ＳＳＮ，ＰＮ ＵＭ ＢＥＲ，ＨＯＵＲＳ，ＥＮＡＭ Ｅ 属性上进行投影，得到图 １０．１３（ｂ）的关系 ＥＭ Ｐ－ ＰＲＯＪ－ ＦＬＡＴ ：

·３４３·第十章　分布式数据库系统的发展趋势

ＥＭ Ｐ－ ＰＲＯＪ－ ＦＬＡＴ ←πＳ ＳＮ ，Ｅ Ｎ Ａ Ｍ Ｅ ，Ｐ Ｎ Ｕ Ｍ Ｂ Ｅ Ｒ ，Ｈ Ｏ Ｕ Ｒ Ｓ （ＥＭ Ｐ－ ＰＲＯＪ）为了创建 ＥＭ Ｐ－ ＰＲＯＪ－ ＦＬＡＴ 的一个嵌套版本，使其中每个雇员具有一个元组，

（ＰＮ ＵＭ ＢＥＲ， ＨＯＵＲＳ）被嵌套在里面，可以使用 Ｎ ＥＳＴ 操作，得到嵌套关系 ＥＭ Ｐ－ＰＲＯＪ－ ＮＥＳＴＥＤ：

ＥＭ Ｐ－ ＰＲＯＪ－ ＮＥＳＴ ＥＤ←ＮＥＳＴ Ｐ Ｒ Ｏ Ｊ Ｓ＝ （ Ｐ Ｎ Ｕ Ｍ Ｂ Ｅ Ｒ ，Ｈ Ｏ Ｕ Ｒ Ｓ ） （ＥＭ Ｐ－ ＰＲＯＪ－ ＦＬＡＴ ）这个操作的结果是在外部关系 ＥＭ Ｐ－ ＰＲＯＪ－ Ｎ ＥＳＴ ＥＤ 里生成一个内部嵌套关系

ＰＲＯＪＳ＝（ＰＮＵＭ ＢＥＲ，ＨＯＵＲＳ）。因此，对于 ＮＥＳＴ 操作没有指定的属性，如果某些元组

在这些属性上具有相同的值，那么 ＮＥＳＴ 就会把这些元组分在一组，在这个例子中就是

ＳＳＮ 和 ＥＮＡＭ Ｅ 属性。 对于每一个这样的组，它表示一个雇员，它将创建单个的嵌套元

组，该嵌套元组带有一个内部嵌套关系 ＰＲＯＪＳ＝（ＰＮＵＭ ＢＥＲ， ＨＯＵＲＳ）。 因此，ＥＭ Ｐ－ＰＲＯＪ－ Ｎ ＥＳＴ ＥＤ 关系看上 去就像 在图 １０．１３（ ｃ）中 显示的 ＥＭ Ｐ－ ＰＲＯＪ－ Ｎ ＥＳＴ ＥＤ关系。 　　

　　ＥＭ Ｐ－ ＰＲＯＪ　ＳＳ Ｎ ＰＮ Ｕ Ｍ ＢＥＲ ＨＯ Ｕ ＲＳ ＥＮ ＡＭ Ｅ ＰＮＡ Ｍ Ｅ ＰＬＯＣＡＴ ＩＯ Ｎ　　　　　　　　（ａ）平面关系 ：ＥＭ Ｐ－ ＰＲＯＪ

ＥＭ Ｐ－ ＰＲＯ Ｊ－ＦＬ ＡＴＳＳＮ Ｅ ＮＡ Ｍ Ｅ ＰＮ Ｕ Ｍ ＢＥＲ ＨＯＵ ＲＳ

　　　　　　　　（ｂ）子关系：ＥＭ Ｐ－ ＰＲＯＪ－ ＦＬＡ ＴＥＭ Ｐ－ ＰＲＯ Ｊ－Ｎ ＥＳ Ｔ ＥＤ

ＳＳＮ Ｅ ＮＡ Ｍ Ｅ ＰＲＯＪＳＰＮ Ｕ Ｍ ＢＥＲ ＨＯＵ ＲＳ

　　　　　　　　（ｃ）嵌套关系：ＥＭ Ｐ－ＰＲＯ Ｊ－Ｎ ＥＳ Ｔ ＥＤ　　　图 １０．１３　在平面关系和嵌套关系之间进行转换

注意：嵌套与使用聚集函数的分组之间的相似性。 在前者中，每个组由一个个嵌套元

组组成；在后者中，当一个聚集函数应用于分组属性后，每个组是一个汇总元组。Ｕ ＮＮ ＥＳＴ 操作就是 ＮＥＳＴ 的逆操作。 如下的操作可以使 ＥＭ Ｐ－ ＰＲＯＪ－ ＮＥＳＴ ＥＤ 再

转换成 ＥＭ Ｐ－ ＰＲＯＪ－ ＦＬＡＴ ：ＥＭ Ｐ － ＰＲＯ Ｊ－ ＦＬＡＴ ←ＵＮＮＥＳＴ Ｐ Ｒ Ｏ Ｊ Ｓ ＝ （Ｐ Ｎ Ｕ Ｍ Ｂ Ｅ Ｒ ， Ｈ Ｏ Ｕ Ｒ Ｓ ） （ＥＭ Ｐ － ＰＲＯ Ｊ－ ＮＥＳＴＥＤ）

这里，ＰＲＯＪＳ 嵌套属性被拉平成它的成员 ＰＮ ＵＭ ＢＥＲ， ＨＯＵＲＳ。

１０．５　本 章 小 结

本章中，举例说明了分布式数据库技术发展的三个主要方向：并行数据服务器、分布

式知识库和分布式面向对象数据库。 这三个方向都是针对要求更高功能和性能的新应用

需求而提出的。每个方向都有一些对于研究有挑战性的公开问题，它们的一个共同问题就

是如何向分布式数据库系统提供高效处理能力，以提高系统的性能。 在关系数据库环境

·４４３· 分布式数据库系统及其应用

下，在处理并行性和数据管理方面已经取得了巨大的进展。 然而，在知识库和面向对象数

据库方面还有很多工作要做。面向对象数据库缺少理论的基础。与关系数据库相比，还没有能被数据库专家们普遍

接受的基于对象的模型；而且，直到 近都没有一个关于对象数据库管理系统的标准，这就导致许多原本有可能转向这种新技术的潜在用户望而却步。 对象数据管理组织（ｏｂｊｅｃｔｄａｔ ａ ｍａｎａｇｅｍｅｎｔ ｇ ｒｏｕｐ，ＯＤＭ Ｇ）曾经提出一种标准，即 ＯＤＭ Ｇ９３或者 ＯＤＭ Ｇ １．０ 标

准，已经修订为 ＯＤＭ Ｇ ２．０。 该标准由以下几部分组成：对象模型、对象定义语言（ｏｂｊｅｃｔｄｅｆｉｎｉｔ ｉｏｎ ｌａｎｇｕａｇｅ，ＯＤＬ ）、对象查询语言（ｏｂｊｅｃｔ ｑｕｅｒｙ ｌａｎｇｕａｇｅ，ＯＱＬ ）以及面向对象编

程语言的绑定。 语言绑定涉及三种面向对象的编程语言，也就是 Ｃ＋＋，Ｓｍａｌｌｔａｌｋ 和

Ｊａｖａ。 一些软件商只提供特定的语言绑定，不提供 ＯＤＬ 和 ＯＱ Ｌ 的全部能力。因此，很难定义或比较面向对象数据库系统，这些系统倾向于特定的应用。 在分布式

面向对象数据库中，对象管理和对象查询处理对性能有至关重要的影响。与知识库的查询

处理不同，目前可用的研究结果还不多。 现在，知识库和面向对象数据库被认为是分离的

甚至是对抗的两个领域。 但是，它们各自解决数据库新的应用所提出的不同问题，将来可

能会越来越紧密结合，以综合其各自的优势，推动数据库技术不断向前发展。在本章中，我们还简要地介绍了对象关系数据库系统的产生和发展；接着，我们看到

了已经加入到 ＳＱ Ｌ 标准中的 ＳＱＬ ３ 的一些特征，这些特征提供了对对象关系数据库的

支持。Ｍ ｉｃｈａｅｌ Ｓ ｔｏｎ ｅｂｒａｋｅｒ 指出“对象关系系统是未来的发展方向。” 后，简要介绍了嵌

套关系模型，它扩展了具有层次结构复杂对象的平面关系模型。习　　题

１０．１　简要说明分布式数据库技术发展的三个主要方向。１０．２　概述多处理机结构的两种极端情况，并将它们与分布式数据库系统进行比较。１０．３　什么是并行操作处理？ 概述并行操作处理的三种算法。１０．４　什么是并行查询处理？ 概述并行查询处理的支点算法。１０．５　知识库系统的设计和实现中存在哪些困难和问题？１０．６　概述知识库查询处理的主要算法。１０．７　什么是分布式面向对象数据库？１０．８　为什么说分布式面向对象数据库的设计将具有来自于分布式关系数据库和面

向对象数据库两方面所获得的经验？１０．９　概述对象关系数据库系统的产生背景和特点。 ＳＱＬ ３ 标准中包含了哪些支持

对象关系系统的内容？１０．１０　假定你受聘为某个大型汽车租赁公司设计车队的所有车辆数据库。已知对于

所有类型的车辆，数据库中包括的信息有：车辆识别号、牌照号、制造商、型号、购买日期、颜色、车辆外形、车辆性能说明等。对于如下类型的车辆还包括

特殊的信息：

·５４３·第十章　分布式数据库系统的发展趋势

１） 卡车：载重容量；２） 跑车：马力，对租用者的年龄限制；３） 厢式货车：乘客数目；４） 越野车：离地间隙、驱动类型（四轮还是两轮驱动）。说明你将推荐哪种类型的数据库（关系数据库、面向对象数据库、对象关系

数据库，不用指定某个厂商的产品）？ 并说明你的推荐是正确的。

·６４３· 分布式数据库系统及其应用

第十一章　数据仓库和数据挖掘

无论是传统的集中式数据库还是分布式数据库，通常要在数据访问需要和追求数据

完整性需要两者之间求得平衡。在现代的组织方式下，使用数据的用户常常与数据源完全

分离。很多人只需要读数据，要非常快速地访问大量数据，而且这些数据往往来自异构的、多种数据源。 目前，为了支持中高层管理的决策者们的决策过程，需要向他们提供正确的

细节或综合数据，在这方面存在大量的需求。 也由于在决策过程中的许多分析是重复的、可预言的，人们开始设计能支持这些功能要求的系统。数据仓库（ｄａｔａ ｗ ａｒｅｈｏｕｓｅ，ＤＷ ）技术，联机分析处理（ｏｎｌｉｎｅ ａｎａｌｙ ｔｉｃａｌ ｐｒｏｃｅｓｓｉｎｇ，ＯＬＡＰ ）技术和数据挖掘（ｄａｔａ ｍ ｉｎｉｎｇ，ＤＭ ）技术提供了这些功能。 本章将给出对这些技术的概述。

１１．１　数 据 仓 库

数据仓库是以关系数据库、并行处理技术和分布式技术为基础的新的数据处理技术。从目前的形势看，数据仓库技术已紧跟 Ｉｎｔ ｅｒｎｅｔ 而上，成为信息社会中获得企业竞争优势

的又一关键技术。１１．１．１　数据仓库的定义、特征和结构

１．数据仓库的定义和特征

　　自人们步入信息社会以来，一方面对信息管理技术不断地提出新的需求，推动数据库

技术飞速发展；另一方面人们发现对数据库中数据进行再加工，形成一个综合的、面向分

析的环境，能更好地支持决策分析，发挥数据的更大价值。 从而逐渐形成了数据仓库的思

想，数据仓库技术应运而生。Ｗ．Ｈ．Ｉｎｍｏｎ 在其 １９９３年发表的著作枟Ｂｕｉｌｄｉｎｇ ｔｈｅ Ｄａｔａ Ｗ ａｒｅｈｏｕｓｅ枠中指出：“数据

仓库就是面向主题的（ｓｕｂｊｅｃｔ ｏ ｒｉｅｎｔ ｅｄ）、集成的（ｉｎｔｅｇｒａｔ ｅｄ）、非易变的（ｎｏｎｖｏ ｌａｔｉｌｅ）、随时间变化的（ｔｉｍｅ ｖａｒｉａｎ ｔ）数据的集合，用以支持经营管理中的决策制定过程。”他给数据

仓库下了确切的定义，在这个定义中说明了数据仓库的四个特征和建立数据仓库的目的。建立数据仓库的目的是用以支持经营管理中的决策制定过程。数据仓库的四个特征是：（１） 主题与面向主题

主题是一个抽象的概念，是在较高层次上对操作层数据进行综合、归类、分析、利用的

抽象。 逻辑定义为某一宏观分析领域所涉及的分析对象。 面向主题是指数据的一种组织

方式，它是在较高层次上对分析对象的数据作一个完整的、一致的描述，并统一刻画分析

对象所涉及的数据项及数据项之间的联系。

面向主题与传统的面向应用数据组织方式的区别在于：１） 面向应用

① 调查重点是“数据”和“处理”；② 按业务处理流程来组织数据；③ 数据模式与实际数据存在方式和现实业务活动有很好的对应关系；④ 数据独立性（这是数据库的本意）不够，数据与应用没有完全实现分离。２） 面向主题

① 主题抽取是依据分析的需求来确定的，主题间联系是公共键；② 主题域具有独立性和完备性；③ 每一主题目前由一组关系表来实现的。例如：一个商场的信息由传统面向应用的组织方式组织为：采购子系统：订单（订单号，供应商号，总金额，日期）

订单细则（订单号，商品号，类别，单价，数量）供应商（供应商号，供应商名，地址，电话）

销售子系统：顾客（顾客号，姓名，地址，电话）销售（员工号，顾客号，商品号，数量，单价，日期）

库存子系统：领料单（领料单号，领料人，商品号，数量，日期）进料单（进料单号，订单号，验收人，收料人，日期）库存（商品号，库房号，库存量，日期）库房（库房号，管理员，地点，库存商品描述）

面向主题的组织方式分为三个主题，分别是：商品、供应商、顾客。商品固有信息：（商品号，商品名，类别，颜色等）商品采购信息：（商品号，供应商号，供应价，供应日期，供应量等）商品销售信息：（商品号，顾客号，售价，销售日期，销售量等）商品库存信息：（商品号，库房号，库存量，日期等）供应商固有信息：（供应商号，供应商名，地址，电话等）供应商品信息：（供应商号，商品号，供应价，供应日期，供应量等）顾客固有信息：（顾客号，顾客名，地址，电话等）顾客购物信息：（顾客号，商品号，售价，购买日期，数量等）（２） 数据是集成的

数据仓库中的数据经过统一和综合。 数据经过统一消除了来自不同数据源的源数据

中存在的矛盾与冲突，数据经过综合对源数据进行汇总和计算。（３） 数据是非易变的

数据仓库中的数据是非易变的，即指数据仓库中的数据是相对稳定的，一般是只供查

询的，不可更新的。 数据更新只有定期的数据加载或转载。（４） 数据随时间变化

数据仓库中的数据随时间而增加（加载）新的数据内容，随时间而删除或转载过期

（５～１０ 年）的数据内容。 数据仓库中的数据大都与时间有关，将随时间进行重新综合。 所

·８４３· 分布式数据库系统及其应用

以在数据仓库中，关系的码键一般都包含时间项，表明数据的时间性。 使用这样的数据才

能够对相应主题的历史发展和未来变化趋势，给出有效的数据信息以提供辅助决策支持。２．从数据库到数据仓库

由数据库发展到数据仓库主要在于：１） 数据太多，但信息贫乏（ｄａｔａ ｒ ｉｃｈ， ｉｎｆｏｒｍａｔ ｉｏｎ ｐｏｏｒ ）：随着数据库技术的发展，企

事业单位建立了大量的数据库，数据越来越多，但能够辅助决策的信息却很贫乏，如何将

大量的数据转化为辅助决策信息成了研究热点。２） 异构环境数据的转换和共享。 由于各类数据库产品的增加，异构环境的数据也随

之增加，如何实现这些异构环境数据的转换和共享也成了研究热点。３） 利用数据进行事务处理转变为利用数据支持决策。 数据库用于事务处理，若要达

到辅助决策，则需要更多的数据。 例如，如何利用历史数据的分析来进行预测。 对大量数

据的综合得到宏观信息等均需要海量的数据。数据库用于事务处理，也叫操作型处理，是指对数据库联机进行日常操作，即对一个

或一组记录的查询和修改，主要为企业特定的应用服务。 用户关心的是响应时间，数据的

安全性和完整性。数据仓库用于决策支持，也称分析型处理，用于决策分析，它是建立决策

支持系统（ＤＳＳ）的基础。Ｗ．Ｈ．Ｉｎｍｏｎ 在枟Ｂｕｉｌｄｉｎｇ ｔｈｅ Ｄａｔａ Ｗａｒｅｈｏｕｓｅ枠一书中，列出了操作型数据与分析型

数据之间的区别，如表 １１．１ 所示。 操作型数据与分析型数据之间的差别从根本上体现了

事务处理与分析处理的差异。表 １１．１　操作型数据和分析型数据的区别

操作型数据 （ＤＢ 数据 ） 分析型数据 （ＤＷ 数据 ）细节的 综合的 ，或提炼的

在存取瞬间是准确的 代表过去的数据

可更新 不更新

操作需求事先可知道 操作需求事先不知道

生命周期符合 ＳＤＬ Ｃ 完全不同的生命周期

对性能要求高 对性能要求宽松

一个时刻操作一单元 一个时刻操作一集合

事务驱动 分析驱动

面向应用 面向分析

一次操作数据量小 一次操作数据量大

支持日常操作 支持管理需求

　　数据仓库支持在一个机构的数据和信息上进行高性能的查询，支持联机分析处理、决策支持系统和数据挖掘等类型的应用。 ＯＬＡＰ 用来描述对数据仓库中复杂数据的分析。在熟练的使用者手中，ＯＬＡＰ 工具使用分布式计算能力进行分析，比起置于个人桌面机上

进行分析，要求更大的存储能力和更强的处理能力。 ＤＳＳ 也称为行政信息系统（ｅｘｅｃｕｔ ｉｖｅ

·９４３·第十一章　数据仓库和数据挖掘

ｉｎ ｆｏｒｍａｔｉｏｎ ｓｙ ｓｔ ｅｍｓ，ＥＩＳ），支持一个公司的主要决策制定者利用更高层次的数据进行复

杂分析，并作出重要的决定。 数据挖掘 ＤＭ 用来进行知识发现，是为了发现没有预料的新

图 １１．１　数据仓库的一般概念结构

知识而检索数据的一种过程。传统的数据库支持联机事务处理（ｏｎｌｉｎｅ ｔｒａｎｓａｃｔｉｏｎ ｐｒｏ ｃｅｓｓ ｉｎｇ，ＯＬＴ Ｐ），包括插入、

更新、删除，同时也支持信息查询。 传统的关系数据库在处理只涉及数据库一小部分数据

的查询，以及处理对某个关系的少量元组的插入或者更新事务时，是经过优化处理的，是优的。然而，它们对于 Ｏ ＬＡ Ｐ，ＤＳＳ 或者 ＤＭ 不是 优的。相反，数据仓库是以支持有效

抽取、处理、分析、展示和决策为目的而专门设计的。 与传统数据库相比较，数据仓库一般

包含来自多种数据源的海量数据，这些数据源包括不同数据模型的数据库，有时还包括来

自独立系统和平台的文件。数据仓库概念提出后，在不到几年的时间内就得到了迅速的发展。数据仓库产品也不

断出现并陆续进入市场。３．数据仓库的概念结构

图 １１．１给出了数据仓库的一般概念结构，它描述了整个数据仓库的处理过程。 这个

过程包括数据进入数据仓库前可能的清洗和重新格式化。 在数据仓库中的数据分为四个

级别：早期细节级、当前细节级、轻度综合级，高度综合级。源数据经过综合后，首先进入当

前细节级，并根据具体需要进行进一步的综合，从而进入轻度综合级乃至高度综合级，老化的数据（历史数据）将进入早期细节级。从中可以看出，数据仓库中存在着不同的综合级

别，一般称之为“粒度”。粒度越大，表示细节程度越低，综合程度越高。 在这个过程的后面

部分，使用多维分析工具、数据挖掘工具、前端应用工具等，进行 ＯＬＡ Ｐ、数据挖掘和 ＤＳＳ，

·０５３· 分布式数据库系统及其应用