一种异构数据库的解决方案-上海职业经理人事务所

合集下载

数据库分布式事务解决方案

数据库分布式事务解决方案

数据库分布式事务解决方案随着数据量的不断增长和应用系统的复杂性日益提升,单体数据库往往难以满足高并发、高可用、数据一致性等需求。

为了解决这些问题,分布式数据库逐渐成为了一种常见的解决方案。

然而,在分布式数据库中,事务处理一直是一个具有挑战性的问题。

本文将介绍一些常见的数据库分布式事务解决方案,并探讨它们的优缺点。

一、两阶段提交协议(2PC)两阶段提交协议是一种经典的分布式事务解决方案。

它通过协调器(Coordinator)和参与者(Participant)的角色来实现数据的一致性。

具体流程如下:1. 准备阶段:协调器向参与者发送事务准备请求,并等待参与者的响应。

2. 提交阶段:如果所有参与者都准备就绪,协调器向参与者发送提交请求,参与者在接收到请求后提交事务并释放相关资源。

3. 中断阶段:如果任意参与者在准备阶段失败或超时,协调器将发送中断请求给所有参与者,要求它们进行事务回滚。

2PC具有良好的一致性保证,但缺点也非常明显。

主要问题包括:1. 阻塞:在提交阶段,所有参与者都需要等待协调器的指令,造成阻塞和性能瓶颈。

2. 单点故障:协调器是整个协议的核心,一旦出现故障,整个系统将无法正常工作。

3. 丢失消息:在协议执行过程中,可能会存在消息丢失的情况,导致一些参与者未能收到最新的指令。

二、三阶段提交协议(3PC)为了解决2PC的一些问题,三阶段提交协议应运而生。

它相较于2PC,增加了超时机制和事务状态的细化,使其更具有容错性。

具体流程如下:1. 准备阶段:和2PC类似,协调器向所有参与者发送事务准备请求,并等待参与者的响应。

2. 执行阶段:在所有参与者都准备就绪后,协调器向参与者发送可以提交事务的请求,并等待参与者的响应。

3. 提交阶段:如果所有参与者确认可以提交事务,则协调器向参与者发送提交请求,否则发送回滚请求。

3PC相比于2PC的优点是减少了阻塞时间,降低了单点故障的风险。

但它依然存在一些问题,例如:1. 同步阶段仍然存在阻塞问题,特别是在网络延迟较高的场景下。

数据库解决方案

数据库解决方案

数据库解决方案
《数据库解决方案:构建稳定高效的数据存储架构》
随着信息化时代的到来,数据的管理和存储成为了企业发展中不可忽视的重要环节。

数据库解决方案在这个时候变得尤为重要,它能够帮助企业构建稳定高效的数据存储架构,确保数据的安全性和可靠性。

首先,数据库解决方案能够帮助企业选择合适的数据库管理系统(DBMS)。

不同的企业对数据库的需求不同,有些可能需要传统的关系型数据库,而有些可能更适合使用NoSQL数据库。

数据库解决方案能够对企业的实际需求进行深入了解,帮助企业选择最合适的DBMS,从而确保数据的存储和管理能够高效有效。

其次,数据库解决方案能够帮助企业进行数据库架构设计和优化。

一个合理的数据库架构能够提高数据库的性能和可靠性,减少因为数据库设计不合理而导致的问题。

数据库解决方案能够通过对企业的数据结构和需求进行深入分析,设计出最适合企业的数据库架构,从而提高数据库的效率和稳定性。

此外,数据库解决方案还能够帮助企业进行数据库的备份和恢复方案设计。

在信息化时代,数据安全性变得尤为重要,一旦数据库发生意外,很可能会对企业造成严重的损失。

数据库解决方案能够帮助企业设计出合适的备份和恢复方案,确保数据库的数据能够长期存储并且能够在出现问题时迅速恢复,从而保障企业的数据安全性。

综合来看,数据库解决方案在信息化时代变得尤为重要,它能够帮助企业选择合适的DBMS、进行数据库架构设计和优化、以及设计数据库的备份和恢复方案,从而帮助企业构建稳定高效的数据存储架构,确保数据的安全性和可靠性。

随着信息化的不断发展,相信数据库解决方案将会在企业中发挥越来越重要的作用。

异构数据集成中的数据备份与灾备技术

异构数据集成中的数据备份与灾备技术

异构数据集成中的数据备份与灾备技术随着信息技术的飞速发展,各行各业都积累了大量的数据,这些数据对于企业的决策和发展起着至关重要的作用。

然而,由于企业内部各系统之间存在着异构性,不同系统之间数据格式和存储方式不同,导致了数据集成变得异常困难。

在进行异构数据集成时,如何有效地进行数据备份与灾备技术是一个重要而又复杂的问题。

本文将对异构数据集成中的数据备份与灾备技术进行深入研究,并提出相应解决方案。

一、异构性问题分析1.1 异构性问题概述在企业内部系统中存在着多种不同类型和格式的数据库,如关系型数据库、非关系型数据库、文本文件等。

这些数据库之间存在着结构和存储方式上的差异,使得在进行跨系统之间的数据集成时变得异常复杂。

1.2 异构性问题带来的挑战由于不同类型和格式数据库之间存在差异,在进行跨系统之间的数据传输时需要进行相应转换,并确保转换后的数据能够被目标系统正确解析。

此外,在跨系统传输数据时还需要考虑数据的一致性和完整性,避免数据丢失或错误。

二、数据备份技术2.1 数据备份的重要性数据备份是企业保障业务连续性和灾难恢复能力的重要手段。

通过定期对企业的关键数据进行备份,能够在系统故障或灾难发生时快速恢复业务运行,保证企业正常运营。

2.2 数据备份技术分类常见的数据备份技术包括完全备份、增量备份和差异备份。

完全备份是将整个数据库进行复制,适用于小规模数据库;增量备份是只对发生变动的部分进行复制,适用于大规模数据库;差异备份是将上一次完全或增量备份后发生变动的部分进行复制。

2.3 数据一致性保证在异构系统中进行数据集成时,需要考虑不同系统之间的数据一致性问题。

在进行跨系统之间的数据传输时,可以通过使用事务来保证多个操作之间具有原子性、一致性、隔离性和持久性。

三、灾备技术3.1 灾难恢复计划灾难恢复计划是企业在遭受重大灾害或系统故障时能够快速恢复业务的详细步骤和措施。

在制定灾难恢复计划时,需要对企业的关键业务和系统进行全面的分析,确定关键数据和系统的备份策略以及灾难发生时的恢复步骤。

异构数据集成思路总结

异构数据集成思路总结

异构数据集成思路总结1.数据源识别和选择:这一步需要确定数据整合的目标和需求,明确需要整合哪些数据源,以及这些数据源分别有哪些特点和格式。

在选择数据源时,还需要考虑数据的质量和可靠性,确保选取的数据能够提供有价值的信息。

2.数据预处理:由于来自不同数据源的数据往往具有不同的格式和结构,因此在进行数据整合之前,需要对数据进行预处理。

这包括数据清洗、去重、格式转换等,以确保数据的一致性和可用性。

3.数据对齐和映射:在进行数据整合时,可能会面临不同数据源之间存在不一致的问题,比如数据字段命名不同,甚至存在数据缺失的情况。

为了解决这些问题,需要对数据进行对齐和映射,将不同数据源中的相同或相似的数据映射到一起。

4. 数据集成和转换:在完成数据对齐和映射后,就可以对数据进行集成和转换了。

数据集成的方法有很多种,可以采用ETL(Extract-Transform-Load)工具或者编写自定义脚本来实现。

在数据集成过程中,还可以进行数据转换,比如计算新的指标、生成新的表格等,以得到更高层次的数据。

5.数据质量控制:异构数据集成的过程中,可能会存在数据质量问题,如数据错误、缺失或不一致等。

因此,需要进行数据质量控制,对数据进行检查、验证和纠正,以确保数据的准确性和可靠性。

6. 数据存储和访问:完成数据整合后,需要选择合适的存储方式来保存整合后的数据。

可以选择关系数据库、数据仓库、Hadoop等存储系统,根据需要选择最合适的存储方式。

同时,还需要设计合适的访问方式和权限控制,以保证数据的安全性和可访问性。

7.数据分析和应用:异构数据集成的最终目的是为了进行数据分析和应用。

通过对整合后的数据进行分析和挖掘,可以得到有价值的信息和洞察,帮助企业做出更好的决策和优化业务流程。

总之,异构数据集成是一个复杂的过程,需要综合考虑数据源的选择、数据预处理、数据对齐和映射、数据集成和转换、数据质量控制、数据存储和访问等多个方面的因素。

数据库事务管理中的并发冲突与解决方案分析

数据库事务管理中的并发冲突与解决方案分析

数据库事务管理中的并发冲突与解决方案分析数据库事务管理中的并发冲突是一个常见的问题,它可能导致数据一致性和完整性的问题。

本文将分析数据库事务管理中的并发冲突以及一些解决方案。

一、并发冲突的定义和原因并发冲突指的是在数据库中同时执行的多个事务相互干扰,导致数据不一致或完整性受损的情况。

并发冲突主要由以下原因引起:1. 丢失更新:两个事务读取相同的数据,在没有锁定的情况下,同时对该数据进行更新操作,导致其中一个事务的更新结果被覆盖。

2. 脏读:一个事务读取另一个事务尚未提交的数据。

如果后续事务回滚,读取到的数据就是脏数据。

3. 不可重复读:一个事务多次读取同一数据,在读取过程中,其他事务对该数据进行了修改,导致前后两次读取的数据不一致。

4. 幻读:一个事务根据某个条件查询数据集,然后另一个事务插入了符合该条件的新数据,导致前一个事务再次查询时出现新增数据。

以上冲突都是由于多个事务在同时操作数据库,而没有进行合理的协调与管理。

二、解决并发冲突的常见方案为了保证数据库中的数据一致性和完整性,需要采取一些解决并发冲突的方案。

下面介绍几种常见的方案:1. 锁机制:锁机制是最常见的解决并发冲突的方式之一,主要通过对数据库中的数据进行锁定,来限制事务的访问。

常见的锁包括共享锁和排他锁,共享锁允许多个事务同时访问数据但不允许修改,而排他锁只允许一个事务独占访问并且可以修改数据。

2. 事务隔离级别:数据库提供了不同的事务隔离级别,可以通过设置合适的隔离级别来控制并发冲突。

常见的事务隔离级别包括读未提交、读已提交、可重复读和串行化,不同的隔离级别对并发冲突的处理方式和可见度有所不同。

3. 乐观并发控制:乐观并发控制是一种基于冲突检测的策略,它假设事务之间很少发生冲突,因此允许多个事务并发执行,并在事务提交时检测冲突。

常用的乐观并发控制技术包括版本控制和时间戳。

4. 冲突检测与解决:在并发冲突发生时,可以通过冲突检测和解决来处理。

数据库管理中的数据同步与异构处理(三)

数据库管理中的数据同步与异构处理(三)

数据库管理中的数据同步与异构处理1. 引言在当今信息化时代,数据的处理与管理对于企业来说至关重要。

而数据库作为最常用的数据管理工具之一,其数据同步与异构处理更是一项核心任务。

本文将从数据同步与异构处理的意义、现实挑战以及解决方案等方面进行探讨。

2. 数据同步的意义数据同步是指将不同数据库之间的数据进行一致性更新和互相复制的过程。

其意义在于实现数据的实时更新和不同数据库之间的数据一致性。

在多用户、多场景的情况下,数据同步能够确保各个数据库之间的数据一致,提高系统的可靠性和稳定性。

3. 数据同步的现实挑战然而,在实际应用中,数据同步面临着许多挑战。

首先,不同数据库之间的数据格式和结构可能不同,导致数据同步的困难。

其次,不同数据库的操作方式和功能差异也增加了数据同步的难度。

此外,大规模数据的同步和高并发访问对系统性能提出了更高的要求。

这些挑战使得数据同步成为数据库管理中的一个关键问题。

4. 异构数据库处理的意义与数据同步类似,异构数据库处理也是数据库管理中的一个重要问题。

异构数据库是指由不同的数据库管理系统组成的数据库系统。

由于不同数据库管理系统的特性和功能差异,将它们整合在一起进行管理和处理是一项巨大的挑战。

异构数据库处理的意义在于实现跨数据库管理系统之间的数据转换和交互,提高数据共享和系统的整体性能。

5. 异构数据库处理的现实挑战然而,异构数据库处理也面临着许多现实挑战。

首先,不同数据库管理系统的语法和查询方式不同,导致数据转换和交互困难。

其次,数据类型和数据存储方式的差异增加了数据处理的复杂性。

此外,对于大规模异构数据库的处理,系统的容错性和性能也是需要考虑的因素。

这些挑战使得异构数据库处理成为数据库管理中的一项难点。

6. 解决方案为了解决数据同步和异构处理带来的挑战,需要采取科学有效的解决方案。

首先,可以借助数据同步工具和技术,实现不同数据库之间的数据同步和更新。

其次,可以采用ETL工具和技术,实现异构数据库之间的数据转换和交互。

大数据时代下的异构数据融合

大数据时代下的异构数据融合在大数据时代,数据量的增加已经成为了一个不可避免的趋势。

随着各种应用的不断出现,数据也呈现出了多样化、异构化的特征。

如何将这些异构数据进行融合,成为了一个亟待解决的问题。

异构数据的定义和挑战异构数据,是指数据来源、结构、存储方式、格式、语义等方面存在差异的数据。

例如,在一个企业中,会有各种类型的数据,如结构化数据(比如数据库表格中的数据)、半结构化数据(比如XML、JSON 格式)、非结构化数据(比如文本、图像、音频、视频等)。

这些数据有着不同的表示形式、访问方式和使用方法,如何综合利用这些异构数据,成为了数据管理与处理领域内的一个研究热点。

异构数据的管理和融合面临着多方面的挑战。

首先是数据的复杂性和多样性。

不同来源的数据有着不同的结构、语义、单位等。

这些数据要想进行融合,需要进行数据抽象、集成、对齐等操作。

其次是数据的质量问题。

由于数据的采集、存储和传输过程中,可能会出现数据缺失、错误和冗余等问题,这些问题会影响数据的可靠性和有效性。

再次,是数据的隐私和保密问题。

在进行数据融合的过程中,需要保护敏感数据的隐私和安全,防止泄露或被非法使用。

异构数据融合的技术路线异构数据融合的技术路线可以分为三个阶段,分别是数据抽象、数据集成和数据应用。

数据抽象。

数据抽象主要是将异构数据进行概念上的统一和抽象,生成一个共享的数据模型。

这个数据模型可以是面向对象的、关系型的、XML 的等形式。

通过数据抽象,可以解决不同数据源之间的语义差异和结构差异。

数据集成。

数据集成主要是将数据抽象后的共享数据模型映射到真实的数据源中,形成一张全局的数据视图。

数据集成过程包括数据对齐和数据转换两个主要的操作。

数据对齐是指将不同数据模型的元素对齐起来,建立元素间的映射关系。

数据转换是指将元素从一个数据源的格式转换成为另一个数据源的格式。

数据应用。

数据应用则是利用已经完成集成的异构数据,进行多种不同的数据分析、挖掘和智能应用。

电子商务平台数据库异构问题解决方案


集 成信 息的只读 访问 , 同时提 供很好 的数 据可用 性 、 可 的扩 展性 方面有所 不 同。这些 实现 倾 向于使用 最典 型
伸缩性 和性 能 提供 各种转 换功 能 . 以处 理不 同数据 源之 间的 冲 电子 商务 平 台项 目要求 将各个 部 门 的数据 信息 通 过 We b技术 在 网络上发 布 , 现信 息共享 。各 个部 门 突 . 实 并将 源数据 重建为 所需 的 目标数 据模 式 。 在建设 自己的信 息系统 时 . 建 了大量 的数据 库 . 创 这些 分 离对 集成 目标 数据 的 访 问与将 不 同来 源 的数 数据库被 独立地 创建 和管理 .物理 上和逻 辑上 都存 在 据集 成 和转 换到 目标 的过程 .以提供好 的 可伸缩 性和
1 问 题 陈 述 、
开发和 改进 . 以至对于 相 同类 型 的数 据 , 它们使 用 了截 31设 计 时 特 性 . 在设 计 的过 程 中 .关 键 的任务 是 指定从 数 据源 到 然不 同的表示方 式 。 构性可 能出现在 实例级 , 如缺 异 例 少 公共 的键 ( 因为使用 了不 同的格式 )或模 型级 , 如 目标 的数据 流 .即如何 重建并 将源模 型合并 到 目标 模 , 例 将 相 同的 现 实世 界 实 体 建模 为各 种 不 同的 数 据 库 实 型 中。 假设 在应用数 据整合 模式 时 。 据流管 理员或 开 数 发人 员 已深 入地 了解 数据 源 的可用访 问接 口、源数 据 体。 电子商务共 享平 台使 用者不 必 了解基 础异 构性 , 但
数据 整 合方 法包 括 三个 主要 阶段 在 第一 个 阶段 整合 服 务 器 ( 现 数 据 整合 模 式 的组 件 ) 实 收集 ( 或 () 3 数据 库结构及 语义异 构 。各个 不 同的数据库 应 中 , 用系统 采用不 同的数据 结构和语 义表达 方 。 “ 取” 来 自不 同数 据 源的数 据 。接下来 , 源数 据进 提 ) 对 () B 4 D MS本 身 的异构 可 以是 同为关 系型数据 库 行集 成并将其 转换 为 目标 模型 ,这 可能需 要 多步操作 如 0 rc , B , Q evr S b s l D 2 S LS re, y ae等 。 也可 以是不 来完成 。 ae 最后 . 整合 服务器 将经 过转换 的数据应 用 于 目 标 数据存 储 同数据 模 型 的数据 库 。 如关 系 、 式 、 次 、 模 层 网络 、 面 这 个 过 程可 以按 时 间计 划 ( 复 地 ) 行 , 者 由 重 运 或 向对 象等数 据库 。 业 务流 程或任何 其他 服务使 用者 作为 服务 ( 重复 地 ) 调 当在 目标 中加载或 刷新 了集成 数据 之后 , 以将整 可 电子 商 务平 台使用 者请 求需 要访 问来 自多个 异构 用 。 数据源 的信息 的服务 。 这些 数据源经 过 了独地设 计 、 合 信息公 开为服务 提供 给使用 者 。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

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

关键词:异构数据库 CSCW 中间件 元数据

1 引言 随着计算机技术的不断发展,大多数的企业和部门部署了各式各样的异构的数据库系统,这些数据库在历史上发挥了很大的作用。今天人们对数据处理和信息系统的要求越来越高,过去各自为营的异构数据库所形成的“信息孤岛”,已带来很多不便。企业和部门迫切需要整和信息资源,联合异构数据库。解决异构数据库的协同,成为一个很有意义的研究课题。

2基于Agent的三层协作模型实现协调控制器 解决异构数据库问题,可以采用CSCW的联邦结构。当应用需要访问某一数据库时,首先向协调控制器发出请求,不直接同所要访问的数据库发生作用。协调控制器负责各数据库之间的联系与消息传输。它是一个特殊的主体,是各数据库的神经中枢,负责协同数据库间的消息转换、任务的规划、分解和管理。 在计算机支持的环境中(CS),一个群体协同工作完成一项共同的任务(CW)——异构数据库协同,是一个复杂的过程,可模仿人们协同工作的方式。比较可行的方法是,用对单一数据库操作的任务,作为异构数据库协同共作的基本运行单位与控制单位。若干任务采用联邦结构加以协调,以便克服冲突,达到共同完成协同工作的目的。任务可分为若干子任务,即应用任务分层的思想。同时任务还有其任务上下文。 采用一种基于Agent的三层协作模型[8]来实现协调控制器,它符合现实世界人们协同工作的特点,是一种模型运行控制机制,可以描述协作机制中的各种协同工作,以及支持各种协同方式。 将视协调控制器中参与CSCW 协同工作处理过程的自主实体为Agent, 将CSCW 协同工作过程看作是若干Agent 相互协作的活动序列,通过描述Agent 的动作、行为及其相互关系来描述CSCW 应用系统的协作过程,这样更加符合现实世界中的人们的协同工作的特点。 以基于Agent 的协作模型来实现协调控制器,其核心是组件化任务的管理与监控,实现异构数据库系统各成员间组件化任务的协作,具有任务指派、任务确认、任务查询与结果返回等功能。在整个协作模型中,所有Agent 按其所提供的服务类型可分为三层(见图 1 ): (1)任务管理与监控层。任务管理与监控Agent,相当于一个协同任务引擎,它根据一定的规则把异构数据库系统的协同过程模型中的共同任务划分为多个关联的子任务,并建立起它们之间的逻辑和时序关系,同时它要把各个子任务分门别类地分配给各个任务协作Agent去执行。

1 蔡斌杰,男,1968.5.30-,讲师,硕士学位,浙江长江职业技术学院,研究方向:计算机软件工程(如下格式进行修改) 任务管理与监控Agent要协调、监控各个任务协作Agent 的运行,如果运行中出错,还要有相应的故障恢复机制,从而保证整个CSCW系统的正常运行. 任务管理与监控Agent 要有以下知识:协同任务域的模式;完成整个协同任务的知识,如把任务分解为各个任务步的知识、任务步的排序等; 为了完成整个任务,它要包含协调与管理的各个任务协作代理和信息存取代理的知识;故障检测与处理的知识。 (2)任务协作层 任务协作层中,每个任务协作Agent完成某一项特定的任务, 它们之间相互协作,从而解决了CSCW 系统中的冲突或集成信息到系统中。当任务协作Agent 接收到管理与监控Agent 传来的一个指定任务时,它根据自身包含的知识库中的规则把指定任务分解为一些子任务, 并指派其它相应的任务协作Agent 辅助该协作Agent 完成。在任务执行过程中,任务协作Agent 向信息存取Agent请求执行中所需的信息。 任务协作Agent 要包含以下知识: 任务所属的领域、如何完成任务的知识、如何收集任务中用到的信息、哪些任务协作Agent和信息存取Agent与之相协作、与其它Agent协作的协议以及解决冲突和信息融合的策略等。 (3)信息存取层.信息存取层中Agent 的行为是由上层任务协作Agent 启动的,它们相互协作为上层任务协作Agent 提供所请求的信息。而信息来自许多功能各异的数据。这里的数据是一个广义的概念,它既包括普通信息的数据,也包括完成一定功能的软件组件数据。信息存取Agent需要包含以下知识:它所与之关联的数据库的信息、如何访问数据库、如何解决冲突和信息融合的策略以及与其它Agent协作的协议等。

任务管理与监控Agent

任务协作Agent 1

任务协作Agent 2任务协作

Agent n

信息存取Agent 1

信息存取Agent 1信息存取

Agent n

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

协调控制器

数据库元数据目录服务其它模块

数据库1数据库2数据库3

4 调用 控制

1 注册元数据信息2 查询元数据信息

3 返回记录

5 访问数据库

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

应用(可视化界面)

协调控制器

数据库

元数据目录服务

查询处理事务管理完整性约束

通信处理器

联邦结构的CSCW数据库中间件OracleSQL ServerSybase 图4方案结构框图 工作过程如下:用户在可视化界面输入操作要求,应用程序将其提交至联邦结构的CSCW数据库中间件,中间件的协调控制器在通信处理器的支持下,调用数据库元数据目录服务,协同查询处理、事务管理、完整性约束等模块,向不同的数据库发出操作指令,将取得的结果返回给应用。

3.1 关于数据库元数据信息需注意的问题 为了保证用户查询到的是最新的数据库元数据,在数据库和目录之间必须有一个实时动态的注册过程,负责将元数据的注册更新。用户也要遵循LDAP协议查询目录服务。这对用户来说,要求比较高。 我们可以知道每个数据库在目录结构中是一个节点,它可以有多个属性(attribute)来描述其信息,如名称、描述、创建时间、管理员、DBMS、类别和版本等等,另外还需要有操作系统信息和访问参数信息。这些在LDAP中用文件的形式定义下来,然后归类成一些“对象类(Object Class)”,每个“对象类(Object Class)”代表一类属性的集合。每个节点都有一些特定的属性,这些就是所谓的数据库元数据。 这种树状结构对于查询来说是比较复杂的,有一些需注意的问题,比如: (1)如果要查询某个数据库的DBMS信息,需先得到目录的基本结构,再确定查找的范围,然后利用LDAP的搜索命令来查找。这需要一个过程。 (2)如果想将数据库中的某些动态信息,如当前某个数据库的总数据量大小,存入LDAP,应自动算出该数据库的数据量总和,然后填入LDAP,不要人工干预。 (3)对于动态实时信息,程序生成后自动填入到LDAP中,保证用户查询的时候是最新的,要采用某种程序调用机制来保证实时性。

3.2中间件的数据转换 中间件的数据转换由接口、包装器、解析器组成。中间件向外表现为一个统一的接口,通过接口接受异构数据库的访问请求。在中间件内部,由包装器把从接口得到的访问请求包装为XML文档,再由解析器将XML文档解析为对应的被访问异构数据库的语言格式。被访问的异构数据库将结果数据返回,由包装器转换为XML文档,然后由解析器把结果数据转换成相应格式,最后返回给发出请求的数据库。如图3。具体的关系数据库文件与XML文档双向映射方法请见3节。 包装器解析器XML文档XML文档关系数据库文档关系数据库文档中间件的数据转换

图3中间件的数据转换 3.3查询处理模块 查询处理模块是系统中的重要部分。用户输入的SQL查询语句是针对全局的,要分解成在局部数据库上执行的SQL语句。查询处理模块的功能是将通过语法检查的全局查询请求分解,转换成多个数据源上的子查询,优化效率、并行处理后将子查询的结果汇总返回。 查询处理[3]包含下列步骤: 1、 语法检查:首先需要进行语法检查,确认正确后方能进行下一步处理。语法检查进行如下处理,对全局查询语句进行关键字析出和语法判别,并对应全局数据字典检查涉及的表名和字段名称。出错则终止并将错误信息返回给系统。 2、 分解翻译:将正确的全局查询语句分解为面向各局部数据库的查询语句,包括表名、列名、相应函数的替换,生成对应各局部数据库的查询语句。 3、 查询优化:提高查询效率是重要目标,尤其是对涉及多个异构数据库的连接查询。可以采用启发式方法,寻找一个最优方案。 4、 并行处理:各局部数据库接收到分解翻译后的子查询语句后,应互不干扰地并行执行,但须保证任意一个发出多个局部查询的应用中的处理串行性,即只有在一个局部数据库完成其局部查询语句的执行后,另一局部数据库方才开始工作。这会导致系统资源的浪费和效率的降低。 5、 结果汇总:结果汇总就是将从各局部数据库得到的查询结果进行汇总,且以统一的数据形式输出。应用获得的是统一包装的全局数据形式的数据,不必关心其在具体数据库的形态。

3.4事务管理模块 事务可分为两类:局部事务和全局事务。局部事务就是局部数据库的本地应用向本地DBMS提交的事务。全局事务就是全局应用向数据库中间件提交的事务。 虽然数据库中间件屏蔽了各个数据库的异构性与不同,但仍要维护各局部数据库事务的作业独立性。因而局部事务照旧直接提交给局部DBMS就够了,无需通知数据库中间件或征得其同意。对于局部数据库来说,原有的事务管理器仍能保证其事务的ACID特性。 从全局应用角度来看,全局应用提交的事务需要分解成一组子事务,然后将这些子事务提交给局部数据库管理系统执行。当所有的子事务均完成后,这个全局事务才成功结束。如果其中某一个子事务终止(Abort)了,则该全局应用原则上宣判失败了。 这些子事务是全局事务的一部份,为了并发执行和可靠提交,应协同工作各相关的局部数据库的本地事务管理。应将本地事务与全局事务整体考虑,如可串行化、优先级、恢复等操作须各组件数据库协同工作。另外全局应用还有间接冲突、死锁等问题。 局部读协议在满足下面条件时,可以保证强正确性: 局部事务可以访问局部数据项,也可以读取存储在本地的全局数据项。(但是不能写全局数据项);全局事务只能访问全局数据项;不存在含有值依赖的事务。

相关文档
最新文档