一种异构数据库的解决方案.doc

《一种异构数据库的解决方案.doc》由会员分享，可在线阅读，更多相关《一种异构数据库的解决方案.doc（6页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、（注意要用（注意要用 WORD 2003！）！）发发表的表的杂杂志：志愿一、志愿二、志愿三志：志愿一、志愿二、志愿三一种异构数据一种异构数据库协库协同的解决方案同的解决方案作者姓名1单位 邮编摘要：企业和部门迫切需要整和信息资源，联合异构数据库，解决异构数据库的协同，成为一个很有意义的研究课题。提出一种异构数据库协调的解决方案，该方案吸纳了数据库元数据、中间件、LDAP 目录服务等思想。它采用 CSCW 体系结构中的联邦结构，对应用中输入的要求，在通信处理器的支持下，由协调控制器调用数据库元数据目录服务，协同查询处理、事务管理、完整性约束模块，访问底层数据库，较好地屏蔽了异构性，其中协调控制器

2、以基于 Agent 的三层协作模型来实现,数据转换可以采用统一的数据转换格式 XML 文档,工作方式为多线程。关关键词键词：异构数据：异构数据库库 CSCW 中中间间件件 元数据元数据1 引言引言随着计算机技术的不断发展，大多数的企业和部门部署了各式各样的异构的数据库系统，这些数据 库在历史上发挥了很大的作用。今天人们对数据处理和信息系统的要求越来越高，过去各自为营的异构 数据库所形成的“信息孤岛” ，已带来很多不便。企业和部门迫切需要整和信息资源，联合异构数据库。 解决异构数据库的协同，成为一个很有意义的研究课题。2 基于基于 Agent 的三的三层协层协作模型作模型实现协调实现协调控制器控

3、制器解决异构数据库问题，可以采用 CSCW 的联邦结构。当应用需要访问某一数据库时，首先向协调控 制器发出请求，不直接同所要访问的数据库发生作用。协调控制器负责各数据库之间的联系与消息传输。 它是一个特殊的主体，是各数据库的神经中枢，负责协同数据库间的消息转换、任务的规划、分解和管 理。 在计算机支持的环境中（CS） ，一个群体协同工作完成一项共同的任务（CW）异构数据库协同， 是一个复杂的过程，可模仿人们协同工作的方式。比较可行的方法是，用对单一数据库操作的任务，作 为异构数据库协同共作的基本运行单位与控制单位。若干任务采用联邦结构加以协调，以便克服冲突， 达到共同完成协同工作的目的。任务可

4、分为若干子任务，即应用任务分层的思想。同时任务还有其任务 上下文。 采用一种基于 Agent 的三层协作模型8来实现协调控制器，它符合现实世界人们协同工作的特点， 是一种模型运行控制机制，可以描述协作机制中的各种协同工作，以及支持各种协同方式。 将视协调控制器中参与 CSCW 协同工作处理过程的自主实体为 Agent， 将 CSCW 协同工作过程看 作是若干 Agent 相互协作的活动序列，通过描述 Agent 的动作、行为及其相互关系来描述 CSCW 应用 系统的协作过程，这样更加符合现实世界中的人们的协同工作的特点。 以基于 Agent 的协作模型来实现协调控制器，其核心是组件化任务的管理

5、与监控，实现异构数据库 系统各成员间组件化任务的协作，具有任务指派、任务确认、任务查询与结果返回等功能。在整个协作 模型中，所有 Agent 按其所提供的服务类型可分为三层（见图 1 ）： （1）任务管理与监控层。任务管理与监控 Agent，相当于一个协同任务引擎，它根据一定的规则把 异构数据库系统的协同过程模型中的共同任务划分为多个关联的子任务，并建立起它们之间的逻辑和时 序关系，同时它要把各个子任务分门别类地分配给各个任务协作 Agent 去执行。 任务管理与监控 Agent 要协调、监控各个任务协作 Agent 的运行，如果运行中出错，还要有相应的1 蔡斌杰，男，蔡斌杰，男，1968.5

6、.30-，讲师，硕士学位，浙江长江职业技术学院，研究方向：计算机软件工程（如下格式进行修改），讲师，硕士学位，浙江长江职业技术学院，研究方向：计算机软件工程（如下格式进行修改）故障恢复机制，从而保证整个 CSCW 系统的正常运行. 任务管理与监控 Agent 要有以下知识:协同任务域 的模式；完成整个协同任务的知识，如把任务分解为各个任务步的知识、任务步的排序等； 为了完成整 个任务，它要包含协调与管理的各个任务协作代理和信息存取代理的知识；故障检测与处理的知识。 （2）任务协作层 任务协作层中，每个任务协作 Agent 完成某一项特定的任务， 它们之间相互协 作，从而解决了 CSCW 系统中

7、的冲突或集成信息到系统中。当任务协作 Agent 接收到管理与监控 Agent 传来的一个指定任务时，它根据自身包含的知识库中的规则把指定任务分解为一些子任务， 并指派其它 相应的任务协作 Agent 辅助该协作 Agent 完成。在任务执行过程中，任务协作 Agent 向信息存取 Agent 请求执行中所需的信息。 任务协作 Agent 要包含以下知识: 任务所属的领域、如何完成任务的知识、如何收集任务中用到的 信息、哪些任务协作 Agent 和信息存取 Agent 与之相协作、与其它 Agent 协作的协议以及解决冲突和信息 融合的策略等。 （3）信息存取层.信息存取层中 Agent 的行

8、为是由上层任务协作 Agent 启动的，它们相互协作为上 层任务协作 Agent 提供所请求的信息。而信息来自许多功能各异的数据。这里的数据是一个广义的概念， 它既包括普通信息的数据，也包括完成一定功能的软件组件数据。信息存取 Agent 需要包含以下知识： 它所与之关联的数据库的信息、如何访问数据库、如何解决冲突和信息融合的策略以及与其它 Agent 协 作的协议等。任务管理与监控Agent任务协作 Agent 1任务协作 Agent 2任务协作 Agent n信息存取 Agent 1信息存取 Agent 1信息存取 Agent n图 1 基于 Agent 的三层协作模型3 异构数据异构数据

9、库库的一种解决方案的一种解决方案首先构建一个数据库元数据目录服务，有了它应用才可能以统一访问接口透明地访问不同数据库的 资源。这个服务可采用以下方法实现：先将各个数据库的位置和元数据信息注册到 LDAP 目录中，这样， 用户通过目录服务便可查询到所需要的数据库资源位置和元数据信息，然后根据需要去访问各个数据库。 因为主流数据库都属于关系型，结构上是同构的，所以元数据信息大体上相似，这为以统一方式获取和 保存元数据提供了可能。图 2 表示了执行过程。协调控制器数据库元数据目录服务其它模块数据库1数据库2数据库34 调用 控制1 注册元数据信息2 查询元数据信息3 返回记录5 5 访问数据库图 2

10、 执行过程本解决方案采用 CSCW 体系结构中的联邦结构，对应用（可视化界面）中输入的要求，在通信处理 器的支持下，由协调控制器调用数据库元数据目录服务，协同查询处理、事务管理、完整性约束模块， 访问底层数据库，较好地屏蔽了异构性，其中协调控制器以基于 Agent 的三层协作模型来实现。中间的 数据转换可以采用统一的数据转换格式 XML。解决方案的结构如图 3 所示：应用（可视化界面）协调控制器数据库元数据目录服务查询处理事务管理完整性约束通信处理器联邦结构的CSCW数据库中间件OracleSQL ServerSybase图 4 方案结构框图 工作过程如下：用户在可视化界面输入操作要求，应用程

11、序将其提交至联邦结构的 CSCW 数据库中 间件，中间件的协调控制器在通信处理器的支持下，调用数据库元数据目录服务，协同查询处理、事务 管理、完整性约束等模块，向不同的数据库发出操作指令，将取得的结果返回给应用。3.1 关于数据关于数据库库元数据信息需注意的元数据信息需注意的问题问题为了保证用户查询到的是最新的数据库元数据，在数据库和目录之间必须有一个实时动态的注册过 程，负责将元数据的注册更新。用户也要遵循 LDAP 协议查询目录服务。这对用户来说，要求比较高。 我们可以知道每个数据库在目录结构中是一个节点，它可以有多个属性（attribute）来描述其信息， 如名称、描述、创建时间、管理员

12、、DBMS、类别和版本等等，另外还需要有操作系统信息和访问参数信 息。这些在 LDAP 中用文件的形式定义下来，然后归类成一些“对象类（Object Class） ” ，每个“对象类 （Object Class） ”代表一类属性的集合。每个节点都有一些特定的属性，这些就是所谓的数据库元数据。 这种树状结构对于查询来说是比较复杂的，有一些需注意的问题，比如： （1）如果要查询某个数据库的 DBMS 信息，需先得到目录的基本结构，再确定查找的范围，然后利 用 LDAP 的搜索命令来查找。这需要一个过程。 （2）如果想将数据库中的某些动态信息，如当前某个数据库的总数据量大小，存入 LDAP，应自动

13、算出该数据库的数据量总和，然后填入 LDAP，不要人工干预。 （3）对于动态实时信息，程序生成后自动填入到 LDAP 中，保证用户查询的时候是最新的，要采用 某种程序调用机制来保证实时性。3.2 中中间间件的数据件的数据转换转换中间件的数据转换由接口、包装器、解析器组成。中间件向外表现为一个统一的接口，通过接口接 受异构数据库的访问请求。在中间件内部，由包装器把从接口得到的访问请求包装为 XML 文档，再由解 析器将 XML 文档解析为对应的被访问异构数据库的语言格式。被访问的异构数据库将结果数据返回，由 包装器转换为 XML 文档，然后由解析器把结果数据转换成相应格式，最后返回给发出请求的数

14、据库。如 图 3。具体的关系数据库文件与 XML 文档双向映射方法请见 3 节。包装器解析器XML文档XML文档关系数据库文档关系数据库文档中间件的数据转换图 3 中间件的数据转换3.3 查询处查询处理模理模块块查询处理模块是系统中的重要部分。用户输入的 SQL 查询语句是针对全局的，要分解成在局部数据 库上执行的 SQL 语句。查询处理模块的功能是将通过语法检查的全局查询请求分解，转换成多个数据源 上的子查询，优化效率、并行处理后将子查询的结果汇总返回。 查询处理3包含下列步骤： 1、 语法检查：首先需要进行语法检查，确认正确后方能进行下一步处理。语法检查进行如下处理， 对全局查询语句进行关

15、键字析出和语法判别，并对应全局数据字典检查涉及的表名和字段名称。出错则 终止并将错误信息返回给系统。 2、 分解翻译：将正确的全局查询语句分解为面向各局部数据库的查询语句，包括表名、列名、相 应函数的替换，生成对应各局部数据库的查询语句。 3、 查询优化：提高查询效率是重要目标，尤其是对涉及多个异构数据库的连接查询。可以采用启 发式方法，寻找一个最优方案。 4、 并行处理：各局部数据库接收到分解翻译后的子查询语句后，应互不干扰地并行执行，但须保 证任意一个发出多个局部查询的应用中的处理串行性，即只有在一个局部数据库完成其局部查询语句的 执行后，另一局部数据库方才开始工作。这会导致系统资源的浪费

16、和效率的降低。 5、 结果汇总：结果汇总就是将从各局部数据库得到的查询结果进行汇总，且以统一的数据形式输 出。应用获得的是统一包装的全局数据形式的数据，不必关心其在具体数据库的形态。3.4 事事务务管理模管理模块块事务可分为两类：局部事务和全局事务。局部事务就是局部数据库的本地应用向本地 DBMS 提交的 事务。全局事务就是全局应用向数据库中间件提交的事务。 虽然数据库中间件屏蔽了各个数据库的异构性与不同，但仍要维护各局部数据库事务的作业独立性。 因而局部事务照旧直接提交给局部 DBMS 就够了，无需通知数据库中间件或征得其同意。对于局部数据 库来说，原有的事务管理器仍能保证其事务的 ACID

17、 特性。 从全局应用角度来看，全局应用提交的事务需要分解成一组子事务，然后将这些子事务提交给局部 数据库管理系统执行。当所有的子事务均完成后，这个全局事务才成功结束。如果其中某一个子事务终 止（Abort）了，则该全局应用原则上宣判失败了。 这些子事务是全局事务的一部份，为了并发执行和可靠提交，应协同工作各相关的局部数据库的本 地事务管理。应将本地事务与全局事务整体考虑，如可串行化、优先级、恢复等操作须各组件数据库协 同工作。另外全局应用还有间接冲突、死锁等问题。 局部读协议在满足下面条件时，可以保证强正确性： 局部事务可以访问局部数据项，也可以读取存储在本地的全局数据项。 （但是不能写全局数

18、据项） ； 全局事务只能访问全局数据项；不存在含有值依赖的事务。3.5 完整性完整性约约束模束模块块数据库的完整性3是指数据的正确性和相容性。加在数据库之上的语义约束条件称为数据库完整性约 束条件，它们作为模式的一部分存入数据库中。DBMS 中检查数据是否满足完整性条件的机制称为完整 性检查。协同多数据库的完整性约束，可能会产生问题。一种解决办法是依据各局部数据库的完整性约 束规则重新生成新的全局完整性约束规则，并存入系统字典，从某一点开始强制执行。3.6 通信通信处处理器模理器模块块负责各模块之间的通信，要求响应快、可靠性高、延迟短、数据抖动不明显、Qos(Quality of Servic

19、e) 好。其功能有：（1）向协调控制器提供多种通信方式和通信服务；（2）采用双向、单向、面向连接和 非连接等快速安全的通信协议，来满足不同速率、不同质量的通信要求；(3)通过驱动不同传输介质的收 发单元，适应和使用不同传输介质构成的系统。3.7 应应用模用模块块为应用提供一个可视化操作界面。人通过界面完成一次与系统的交互，所进行的操作尽可能少；界 面的各个部分及各个层次，在术语、风格、交互方式、操作步骤等方面尽可能保持一致且与当前潮流一 致；能够启发和引导用户正确、有效地进行界面操作；使人在与系统交互时不必记忆大量的操作规则和 对话信息， “应该是给机器编程序，而不是给人编程序”5；减少重复的

20、输入；对用户的误操作有容忍能 力或补救措施；系统应及时地给出反馈信息；界面友好、结果显示清楚直观、适宜用户操作，具一定的 艺术性、趣味性、风格、视感等。3.8 多多线线程程在中间件中,采用为每个用户提供一个服务线程的方式实现，主要包括 4 类线程: 服务监听线程; 服务线程; 空闲管理线程; 状态监控线程。其中监听线程、空闲管理线程和状态监控线程是服务器中 始终存在的三个线程;服务线程是根据客户的请求而产生和消失的,其数量不定。图 5 显示了服务线程的工 作流程。服务监听线程始终在监听服务请求。一旦有来自客户端的服务请求,服务监听线程就生成一个服 务线程,传递必要的参数,然后继续监听请求。新生

21、成的服务线程首先对用户进行认证,然后根据认证结果继 续运行。一旦连接建立起来后,客户就直接和相关的服务线程相关,而与其它的服务线程无关。空闲管理线 程定期在后台运行, 检查物理连接的使用状态,如某个物理连接已经长时间未用(超时) ,则断开连接以释放 资源。由于一个服务线程只为一个用户服务,失败的用户不会影响服务线程对其他客户的响应。服务生成监听建立连接身份认证等待命令执行命令退出中断连接，释放资源图 5 服务线程的工作流程4 应应用用举举例例某大型中医药开发研究数据分析中心，采用该异构数据库的解决方案，基于数据库元数据目录服务， 联合多种分布式的异质异构中医药数据库，实现了多数据库系统上的分布

22、式的中医药信息处理。到目前 为止，已有专业数据库约 20 个，总数据量达 80 多 GB，其目标是实现数据共享与医药科研人员之间的协 同工作。 该中心的体系结构共分为三层：应用层、中间件、底层数据库。 应用层通过中间件访问底层数据库。 中间件为联邦结构的 CSCW 数据库中间件，中间件的协调控制器是“大脑”，调用数据库元数据目录服务， 协同各个模块的工作。数据库元数据目录服务采用 LDAP，具有数据库信息的注册、数据库信息的存储和 维护、数据库信息的查询等功能。 应用结果表明该异构数据库的解决方案能够很好地适用于异构数据库环境中。在此方案出台之前， 数据分析中心也尝试了其他的解决方案，典型的如

23、建立应用工作接口、构建联邦数据库等，但是由于它 们的种种原因，应用非常有限，不能满足数据分析中心的需求，而该解决方案融合了异构异质分布式的 数据库，可以完全胜任一般异构数据库环境。结结束束语语本文尝试在异构异质分布式数据库环境下，针对数据库资源共享操作，提出一种基于 CSCW、数据库 元数据、中间件、LDAP 目录服务、XML 等思想上的应用服务解决方案，目的是研究在现有的理论与技术 基础上实现数据访问、集成和共享的复杂性和可行性。实际上，可以实现异构分布式数据库的统一访问， 首先要有统一的中间件架构，在底层实现局部各异的访问，中间层实现统一的中间件操作，高层应用才 能进行透明访问。采用 CS

24、CW 体系结构中的联邦结构方式，数据库元数据目录服务，Agent 的三层协作模 型,以及统一的中间数据转换格式 XML 等来解决异构数据库是可行的，而且复杂程度是可以接受的。参考文献参考文献1宋晓柒，刘东生，许满武，中间件及其在三层客户机/服务器模型中的应用，计算机应用，1999, 19(7): 7-9.2周云鹏,叶勇，石竹. 基于数据库中间件开发烤烟质量评价系统软件J. 计算机辅助工程 2005.06. 第 14 卷第 2 期 3944.3王宁,王能斌 异构数据源集成系统查询分解和优化的实现J. 软件学报，2000,11(2): 222-228.4AVI SILBERSCHATZ, HENRY F.KORTH, S.SUDARSHAN. Database System Concepts (Fourth Edition) M. New York: The McGraw-Hill Companies, 2001. 5T.A.HOWES, M.C.SMITH, G.S.GOOD. Understanding and Deploying LDAP Directory Services (2nd Edition) M. New York: Macmillan Publishers, 1999. 6邵维忠,杨芙清.面向对象的系统设计M. 北京：清华大学出版社, 2003.