分布式异构数据库访问（精选7篇）
分布式异构数据库访问 篇1
异构数据库的集成共享是数据共享研究领域的一个研究热点，国外Batini C(1986年)[1]和国内Y.R.Wang(1991年)[2]发表了此方面的论文。在前人的努力下，异构数据库集成共享研究取得了一些成果，主要表现为异构数据集成和共享解决方法的建立，但这些方法同时又存在着少量的缺陷，主要表现如下：
(1)按国标重新建库。该法是消除异构问题最彻底的一种方法，但是工程量大且不能保证已存数据的安全性，实际中几乎不会被采用。
(2)运用数据库访问中间件技术动态改变数据源从而达到集成效果[4]。该技术通过改变数据源最终实现各种数据的浏览和显示，但其语义不清晰。
(3)统一视图显示模式[5,6,7,8,9]。该方法下的操作不能进行统一分析，且数据完整性差。
(4)应用XML技术实现数据集成和访问[5,6,7,8,9]。以最终的显示效果为目的进行设计，相比第三种方法该技术下的数据完整性和安全性较高,但也不能解决异构数据的统一分析问题。
另外在目前的研究中，针对属性异构数据库的研究较多，针对复杂的空间数据库的较少。本文的研究以空间异构数据库为研究对象，提出一种基于“智能映射字典”的异构空间数据库集成和共享方法。
1 空间数据及空间数据库分析
图形数据是用来表示空间实体的位置、形状、大小及其分布特征诸多方面信息的数据，又称为几何数据[10]。属性数据是描述空间对象属性特征的数据，又称非几何数据。空间数据库中一般包含着属性数据和图形数据，因此解决空间异构数据库共享难题不仅要解决属性数据异构共享难题，还要解决图形数据的异构共享难题。
目前空间数据库中图形数据与专题属性数据的连接组织方式有以下几种[11]：
(1)图形数据与专题属性数据分别管理;
(2)对通用DBMS进行扩展;
(3)属性数据与图形数据具有统一的结构;
(4)图形数据与属性数据自成体系。在这几种组织方式中，第三种和第四种较为多见，在实际的解决方案中要妥善处理好属性数据和空间数据的相互关系。
2 方法设计
2.1 方法的整体设计
方法吸取了传统方法中的优点，搭建“智能映射字典”技术的中间件，系统采用C/S模式结构，见图1整个系统分三层：客户端、中间件和服务器端。服务器端集成数据源由分布于异地的异构空间数据库组成，由于各个空间数据库在进行数据组织时所选用的GIS软件可能不同，因此数据库中的数据结构也不尽相同，空间数据格式主要有Map INFO、CAD格式等，属性数据格式有VFP、Access格式等。这些异构的空间数据和属性数据以各自的形式存在并组成庞大的异构空间数据源，本方法中将每一个分布式异构空间数据库都将配置为一个服务器，并将共享数据先通过服务器XML模式将数据进行转换并存储到相应的空间数据库中，以提供给不同的客户端访问。
2.2 中间件设计
2.2.1 智能映射字典设计
本文所提“智能映射字典”是指在系统中将各个异构信息的模式映射情况、元数据等信息放入公共数据库中存储管理，当数据要共享时，系统首先访问该库并找到对应表(第一次需要人为添加)，最终实现数据的自动转换，整个过程中人为参与很少。
如图1所示，为在客户端和服务器端进行模式转换提供方便，在智能映射字典中包含有各个异构空间数据的模式映射信息，同时也记录着转换模式的模式映射信息。应用各个字典可以实现模式的方便转化，同时也方便异构库间的数据格式内容的自由增删。模式字典中的模式信息要遵循一定的执行顺序，首先将已有的模式入字典库，用户在应用时，第一次就直接在模式数据字典中查找，如果找到就直接执行以进行模式之间的匹配和转换，如果没找到就提示用户建立新字典并保存，当用户再一次用同一个模式时，因为字典信息在上次应用时已被保存，此时所用的信息就是已有信息的调用而无需用户重新建立。
在智能映射字典中主要包括4个表(见表1)，其中IMD01是对空间数据的描述，IMD02是对实物属性信息的描述，IMD03是对参数属性信息的描述，IMD04是对属性字段内容的描述。在应用中用户根据各个异构数据库确定各自的模式并将其模式存储在智能映射字典中，各模式中包含有IMD01中各个字段的对应空间信息的SVG模式表达，这些信息和图2所表示的SVG元素内容相对应。IMD02是实物属性信息的表达，由此表可以建立相应的实体属性数据库的XML模式表达，同时IMD01利用实物属性信息编号和IMD02建立关联。表IMD03是参数属性信息的表达，主要描述线形、线宽、颜色等信息，同理IMD03表可以建立相应的参数属性数据库的XML模式表达，同时IMD01利用参数属性信息编号和IMD03建立关联。对于属性信息模式的描述通过IMD04实现，另外IMD04的作用还体现在可以作为一种统一标准的工具进行智能建模。应用字典中4个表之间的关系可实现各异构库间对应关系的建立，从而实现各异构库间的模式对应关系。
2.2.2 图形数据和属性数据的表示设计
在本文中，笔者应用基于SVG技术的空间数据转换技术来构建映射字典。SVG元素是一组事先定义好的如何绘制图像的指令集，由解析器负责解释这些指令，并把SVG图像在制定的设备上渲染出来[13]。将空间数据转换而设计的对应SVG模式如图2所示，分别依次为
需要阐明的是SVG元素和相应属性元素的对应，因各元素对应自己的属性，这些属性在常用的GIS软件中常用数据库软件管理，故在实现SVG元素和属性对应时笔者应用关联索引给以实现，相应的属性库的模式用相应的XML模式给以实现。属性库中数据一般属于关系型结构，因此异构空间数据库的属性数据模式表示转化为将关系数据模式转换为XML模式的实现，我们直接借鉴前人的成果[15]解决该问题，在此不赘述。因SVG是基于XML的，故SVG文档和XML文档高度兼容，故而本方法中空间数据的SVG表示模式和属性的XML表示模式彼此兼容，二者之间的连接通过关联索引实现，整个系统内部不存在冲突。
2.2.3 异构数据应用设计
用户对异构数据的应用可以分为两种：第一，浏览数据;第二，下载数据和本地数据综合分析。对于浏览数据，方法利用了基于视图的异构集成思想，将异地的数据通过模式转换后在本地应用;对于下载的数据要和其他的异构数据进行综合分析，首先要将经映射后得到数据做进一步处理。见图3，首先对下载数据做坐标格式的转换，所有数据都统一为同一种坐标系统下的格式，然后做进一步的分析，为后续工作的开展提供必要的数据基础，至于做何种应用，应根据客户的需要而定。
3 方法的应用及结论
笔者以AutoCad和MapInfo两种数据格式在两台计算机上做试验，在转换数据格式时笔者采用了参考文献[16,17,18]所采用的方式进行，表2和表3是AutoCAD格式数据和MapInfo格式数据所对应的相应SVG格式文档。
将两个计算机都设置为服务器，安装中间件(内含有模式匹配对应关系和智能映射表)插件，另外要安装SVGViewer(可以在网络上免费下载)，此时就可以在两个机器的终端访问对方的数据，同时也可以下载对方的数据(格式被转换为本机兼容的格式)，在两个计算机终端基本实现了异构空间数据的集成和共享。对于坐标变换及进一步的统计分析在此就不作深入探讨。
本文提出“智能映射字典”构建中间件的方法来实现异构空间数据的集成和共享。方法经过小实验验证具有一定的可行性，但我们也发现方法的不足，系统对于少量数据处理比较顺利，数据稍大时的处理速度会很慢，而且转换后的数据存在一定的质量误差，这也是要进一步研究的内容。
分布式异构数据库访问 篇2
随着信息化建设和无纸化办公的不断深入,已有相当数量的企业和科研机构积累了大量的以不同形式数据库管理系统存储的数据,并且为了存储和管理这些数据持续不断地继续投资。但是这些数据库系统各成体系,不能实现彼此之间的资源共享。因而迫切需要建立一个集成系统,将异构数据库联合起来使用,来实现不同数据库之间的数据资源共享。中间件技术可以屏蔽底层分布式环境的复杂性和异构性,为上层的应用软件提供运行与开发环境。正是由于这些原因,我们选择中间件技术来实现对异构数据库进行访问。
1 XML技术
XML是W3C于1998年提出的数据文件格式标准,和HTML一样是SGML的一个子集。XML是继HTML之后发展起来的新一代Internet技术,它将SGML的丰富功能和HTML的易用性结合到WEB应用中,以一种开放的、自我描述的方式定义了数据结构,它在描述数据内容的同时能突出对数据结构的描述,并且可以体现数据之间的关系。XML语言的可扩展性、结构性和自描述性使它在异构集成系统中具有很好的应用,它不仅与平台无关,而且与厂商无关。因此我们可以使用XML作为中间语言来转化不同数据库系统之间的差异。
XML作为数据传输的中介格式,使异构数据源之间可以保持相互透明,而不需要知道对方内部存储格式,某个数据源内部的变更不会影响到其他数据源,因此XML可以为异构数据源提供一个理想的缓冲。使用DTD和Schema来对数据库模式进行映射,可以将数据源的类型映射到XML支持的数据类型,从而实现数据类型异构的集成[1]。
2 数据库中间件技术
中间件是一种独立的系统软件或者服务程序,分布式应用软件借助中间件在不同的技术之间共享资源,其程序接口定义提供了一个相对稳定的应用环境,不管底层的计算机硬件和系统软件怎么更新换代,只需将中间件升级更新,并保持中间件对外接口定义不变,应用软件几乎不用修改。
数据库中间件是所有中间件中应用最广泛、技术最成熟的一种,它处于前端客户机和后端数据库之间,负责接收客户端的数据请求,然后把请求传递给相应的后端数据库服务器,进行数据处理,最后把结果经数据库中间件返回给客户端。常用的数据库中间件技术有:微软的ODBC和OLE DB、SUN的JDBC等,以上三种最常见的数据库中间件各有其优缺点,到目前为止,数据库中间件还没有一个统一的标准,因此我们有必要继续研究数据库中间件的理论知识和相关技术。
3 CORBA技术
CORBA是一种通用的对象请求代理体系结构。它把各种对象的操作和属性封装在不同的接口之中,通过对象请求代理来调用接口中的操作,完成指定的功能。
由于CORBA的操作平台无关性、编程语言无关性及其网络协议无关性的特点,使得它渐渐被人们所重视,并且成为中间件技术的主流平台。而通用数据库访问中间件正是建立在CORBA分布式平台基础上的,由CORBA客户端根据用户的需求提出远程调用,CORBA服务端则根据请求来访问各种异构数据库。由于CORBA技术本身就是一种中间件[2],所以本文中提到的通用数据库中间件系统就是建立在CORBA中间件基础上的一种综合中间件。
4 基于XML的数据库中间件的设计与实现
本文在不改变异构数据库原始数据存储和管理方式的前提下,集中为异构数据源提供一个高层检索服务,以XML为资料转换的中介格式,将来自多个数据库的资料整合在同一个接口输出,以解决使用者必须在分布式的数据库中搜索,再手动式将所得信息拼凑的问题[3]。
本文中使用的基于XML的异构数据库访问中间件处于业务逻辑层,异构数据源处于数据层,应用程序处于表示层,如图1所示。
4.1 系统架构
本文采用XML、CORBA、Java等技术开发系统,以XML作为公共的数据模型,为用户提供统一的查询接口,最终将查询得到的结果以XML格式输出。系统的整体框架如图2所示。
4.2 系统的工作流程
本文系统中数据库中间件的工作流程分为先后两个过程:初始化过程和运行过程。
· 初始化过程 主要完成的任务是生成元数据信息。从中间件系统角度引入两类角色,中间件管理员和各数据库管理员。中间件管理员首先登录中间件定义数据的全局描述。各数据库管理员登录中间件注册自己的数据库信息以建立连接,并定义共享的内容。
系统的运行流程如图3所示。
· 系统运行过程 由CORBA客户端通过与Web服务器通信模块接受业务处理系统的请求,将请求命令存放在请求命令缓存模块中,系统根据元数据信息对请求命令进行解析和分解,分解为针对具体数据库的子查询,并调用CORBA服务器端的对象连接和操作数据库的方法,CORBA服务器端对CORBA客户端的子查询命令进行合法性验证和解析后,调用数据库访问模块,将查询后的结果转换为XML文档,并发送给CORBA客户端。CORBA客户端将多个子结果进行合并封装后,通过Web服务器通信模块交给业务层并显示在页面上。
4.3 系统的主要模块设计
由图3中我们可以看到本文系统的模块组成和具体的工作流程。在此重点介绍系统几个重要模块,包括元数据与局部数据映射模块、查询分解模块、CORBA客户端和服务器端这几个模块。
4.3.1 元数据与局部数据映射
局部数据库管理员登录系统后显示系统从元数据表存储的位置读取元数据表列表,根据数据源表名和表中字段的字面描述和详细描述判断自己的数据库中是否存在具有相同业务类型的数据表,如果存在的话,就申请注册到该元数据表对应的XML文件中。该XML文件以元数据表名命名,主要包括以下几部分内容:与该元数据表对应的局部数据表表名、该表所在数据库系统使用的IP地址、端口号、用户名、密码、数据库系统使用的驱动程序类型,以及与元数据表中字段所对应的局部表表名等项。如表1所示。
4.3.2 查询分解模块
该模块将接收到的全局查询语句分解为各个子查询语句。依据元数据中全局数据与局部数据的映射关系,将全局查询语句的字段名映射为局部数据的字段名,并获得对应的数据库的具体信息,如IP、端口、用户名和密码等,这样就将全局查询分解成了针对不同数据库的子查询。
查询分解模块得到SQL语句中的元数据表表名,然后查询系统初始化阶段生成的以元数据表表名命名的XML文件,从中查询到与业务处理系统处理的业务类型相同的局部数据库表,将SQL语句中的元数据表字段对应为相应的局部数据表字段,然后为元数据表的XML文件中每个局部表合并成一个子SQL语句,并且验证每个SQL语句的合法性。最后将它们放到子查询请求队列中,由CORBA客户端与CORBA服务器端通信接口依次发送到相应的服务器端。
4.3.3 CORBA客户端
CORBA客户端主要将业务处理系统提供的参数通过查询元数据表,由查询分解模块分解为几个子查询,通过,CORBA服务器端通信模块提交到相应数据库的CORBA服务器端,并且把CORBA服务器端返回的XML文件合并后,返回给业务处理系统。
4.3.4 CORBA服务器端
CORBA服务器端主要是为CORBA客户端的远程调用提供实现,提供多个数据库连接以满足业务处理层查询的要求,并将数据库查询得到的结果返回给客户端,以供客户端进行下一步的处理。
由于系统中可能存在大量客户进行访问,需要频繁建立和关闭连接,这样会极大地降低系统的性能,所以对连接的使用可能会成为系统的瓶颈。这里的CORBA服务器端对于数据库的访问采用了数据库连接池技术。数据库连接池的数据请求流程图如图4所示。
5 实验结果
本文中设计的异构数据库中间件系统以一个毕业生信息查询系统为例来模拟整个运行过程。每个学校都在自己的数据库里存储了本校毕业生信息,若要对全省的毕业生信息进行统一的查询,利用本文设计的数据库中间件来访问各个学校的数据库便可得到所有符合查询要求的毕业生信息。在本实验中,利用三个不同类型的数据库来模拟三个学校的数据库,设计了一个统一的查询界面。用户通过浏览器输入查询条件,数据库中间件将查询分为各个子查询并访问数据库,将得到的结果呈现给用户。实验结果证明,系统的设计是切实可行的,具有一定的应用价值。
6 结 论
本文结合目前比较流行的XML、Java和CORBA技术提出了一种异构数据库访问中间件解决方案。用户看到的只是一个全局数据库,该全局数据库由XML文档存储。实际的用户查询被系统分解为针对各数据源的子查询,子查询结果再由系统汇总返回给用户,同时,各子系统都保持自治性,具有其本地的不为全局所知的事务运行。由于CORBA的操作平台无关性、编程语言无关性及其网络协议无关性和XML的可扩展性和自描述性等优点,使该系统达到了即插即用、实现简单和可扩展数据源的目标。
本文中进行的仅仅是一些初步的研究,存在一些问题和考虑不周的地方。下一步的研究主要是对于面向对象数据库和XML数据库,全局查询语言和局部查询语言之间转换的优化和数据安全验证等方面。
参考文献
[1]张驰.基于XML的异构数据库数据交换技术研究[J].数据库与信息管理,2008,3(8):1637-1639.
[2]Oznsoy C R,Zayegh A,Kalama.AInteroperable CORBAMiddleware de-sign for substation communication systems[C].Eight IEE Internationalconference,2004.
分布式异构数据库访问 篇3
近年来, 随着信息系统集成理念和技术的发展, 数据集成或数据统一访问作为一种资源整合方式受到了相关部门的高度重视。在我军装备保障信息化建设的过程中, 各个业务口分别建立了能够满足自身业务需求的信息系统和相应的数据库生成TB级的数据。数据来源多种多样, 数据类型也有所不同, 它们大多存在于不同的硬件和软件环境中, 常常以不同的格式存储和表现出来。由于这些数据源的差异较大, 数据量庞大, 所以, 统一处理和分析这些数据成为了装备保障业务信息系统研制和综合集成过程中需要面对的首要问题。通过一个集成系统整合装备保障领域内的异构数据源, 提高资源的利用效率, 为装备保障业务信息综合集成、信息资源共享和应用提供有效的数据支持, 是现代信息系统建设面临的巨大挑战之一。
2 国内外研究现状
2.1 研究现状
经过20 多年的发展, 已经有诸多理论支持信息数据统一访问工作的实施, 研发出了相应的技术, 相关研究者也提出了有关数据访问的体系结构和实现方案。因此, 从模型上看, 数据访问体系可分为联邦方式、数据仓库和中间件方式;从集成技术上分, 异构数据库集成技术主要包括数据的迁移和转换、多数据库系统和使用中间件。综合国内外成功的应用案例可知, 采用中间件方式最稳妥、最实用, 性价比也最高。目前, 对通用数据统一访问和转换平台的研究尚处于起步阶段, 国外一些著名的数据库公司开发出了相应的中间件产品用于解决异构数据集成问题。要想广泛使用这些中间件产品, 就需要开发大量的数据接口, 但是, 它们并不能满足我军装备保障领域的数据需求和安全保密要求, 而且国内和军内对其的研究甚少, 也没有与之相配套的产品。
2.2 技术途径选择
目前, 实现大数据共享的途径有2 种, 即数据转换和数据集成。第一种途径是物理意义上的数据集中, 它不仅需要在硬件和相关软件上投入较多的资金, 而且海量数据迁移和管理也有相当大的风险, 访问速度可能不理想;第二种途径属于逻辑集中, 它能充分利用现有系统分布存储、分散管理信息资源, 统一访问接口, 以适应我军装备保障信息系统的发展, 满足其需求。
3 需求分析
3.1 功能性需求分析
装备保障异构大数据统一访问与转换平台的功能性需求如图1 所示。
从图1 中可以看出, 系统的主要功能有: (1) 用户注册数据源信息到数据处理中心; (2) 异构数据源预处理数据源中存储的全部数据; (3) 数据处理中心抽取相关异构数据源的元数据信息; (4) 数据处理中心依据元数据信息建立映射模式; (5) 数据处理中心抽取数据源中的数据信息; (6) 数据处理中心灵活转换异构数据, 并存储转换后的数据等。
数据应用主要是指数据处理中心应用转换后的数据或者对相关存储数据有特定的应用。由于异构数据源中的数据量较大, 因此, 在抽取数据信息、转换数据和存储数据的过程中, 主要借助服务数据对象编程技术Hadoop平台、分布式Map Reduce计算框架和HBase存储等技术完成高效、快速、准确的运算和存储操作。
3.1.1 数据预处理
数据预处理的目的是要保证数据的基本质量, 为数据的抽取、转换、存储等提供基础服务。数据源处理工作主要是在数据源本地完成的, 通过对数据的清洗、过滤、去重和修正等操作, 保证其基本质量, 使它能够满足数据分析抽取等工作的统一处理要求。预处理数据详细用例规约如表1 所示。
3.1.2 注册数据源信息
注册数据源信息功能允许用户将需要的异构数据源信息 (数据源访问信息, 比如数据库的访问地址、端口、数据库名、用户名、密码和权限等) 注册到数据处理中心。数据处理中心得到数据源信息后, 可以随时访问数据源, 以获取数据源的数据信息。注册数据源信息详细用例规约如表2 所示。
3.1.3 抽取数据源元数据信息
在此过程中, 允许数据处理中心抽取异构数据源的元数据信息。这些信息主要包括对数据库名、数据库表名、属性 (类型名、格式、约束等) 、主键和外键等的描述, 而标准元数据通常被用来访问分布式异构数据源。鉴于此, 可以通过服务数据对象 (Service Data Object, SDO) 、数据访问服务 (Data Access Service, DAS) API读取数据库中的元数据 (Metadata) 信息, 并提取相对应的异构资源数据库的所有表信息、视图、相关规则和语义约束 (比如主外键、唯一性约束、默认值等) 信息。抽取数据源元数据信息的详细用例规约如表3 所示。
3.1.4 建立映射模式
建立映射模式主要是为了解决数据转换中各异构数据源中数据模型的异构性, 以局部模式实体存储数据源局部模式实现映射。这样做, 既最大限度地保留了数据源中的各种信息, 又保证了映射中没有过多的冗余信息。数据源的全局模式包括数据源元数据全局模式和领域知识元数据全局模式2 种。建立映射模式的详细用例规约如表4 所示。
3.1.5 抽取数据源数据信息
抽取数据源数据信息是为了获取数据源中存储的数据信息, 以供后续的转换和应用等。在此, 可以通过服务数据对象 (Service Data Object, SDO) 、数据访问服务 (Data Access Service, DAS) API读取数据源中的数据信息。抽取数据源数据信息的详细用例规约如表5 所示。
3.1.6 转换数据
转换数据是最重要的功能之一, 它主要用于异构数据源数据之间的转换。在转换过程中, 如果异构数据源间的数据表达方式一致, 可以直接把原数据源的数据复制到目标数据源, 以供后续使用;反之, 则可以将预先定义好的数据源数据表达方式转换为目标数据源数据的表达方式, 也可以像关系数据库中的存储过程一样, 由用户转换, 将相关内容注册到数据处理中心, 然后通过主动调用完成转换。转换数据的详细用例规约如表6 所示。
3.1.7 存储数据
存储数据主要存储的是抽取的数据源元数据信息和异构数据源之间的数据转换信息等。数据的存储可以借助Hadoop平台下的HBase数据库实现。存储数据的详细用例规约如表7 所示。
3.2 非功能性需求分析
在数据统一访问和灵活转换系统中, 非功能性需求主要体现在数据质量方面。下面, 主要从4 个方面介绍数据质量的基本要素和评估要素。完整性、一致性、准确性和及时性是衡量数据质量的4 个基本要素, 它们与数据质量的关系如图2 所示。
3.2.1 完整性
完整性主要是指记录的数据和信息要完整, 无缺失。数据的缺失主要包括记录缺失和记录中某个字段信息的缺失, 两者都会影响统计结果的准确性。由此可知, 完整性是数据质量最基础的保障, 而数据质量的完整性评估也是比较容易的。
3.2.2 一致性
一致性主要是指数据的记录符合规范, 与前后及其他数据集合相统一。数据的一致性主要包括数据记录的规范和数据逻辑的一致性。数据记录的规范主要体现在数据编码和格式上;数据逻辑性主要是指指标统计和计算的一致性。在审核数据质量时, 一致性是比较重要、复杂的内容之一。
3.2.3 准确性
准确性主要是指数据中记录的信息和数据准确, 无异常情况或者错误信息。一致性出现问题的原因可能是数据记录的规则不一, 但是, 不一定存在错误;而准确性关注的是数据记录中的错误, 比如字符型数据的乱码现象也应该归到准确性的考核中。另外, 对于异常数值——异常大或者异常小的数值、不符合有效性要求的数值, 例如, 装备保障人员的年龄一般在1~100 之间、转化率为0~1 等, 在审核时可能会遇到一些困难, 这是因为没有明显异常的错误值是很难发现的。
3.2.4 及时性
及时性主要是指数据从产生到可以查看的时间间隔, 也叫作数据的延时时长。虽然对分析型数据实时性的要求不太高, 但是, 并不意味着就没有要求。装备保障数据分析可以接受某天的数据次日查看, 但是, 如果数据要延时两三天才能出来, 每周的数据分析报告就要2 周后才能出来, 那么, 分析结果就会失去时效性, 数据分析工作便是徒劳的。另外, 当某些实时分析和决策需要用到小时或者分钟级的数据时, 就会对数据的时效性提出极高的要求。由此可知, 及时性也是衡量数据质量的重要因素之一。
4 研究方案
4.1 技术路线
课题研究的技术路线如图3 所示。在此过程中, 要依据用户的要求预处理、分析数据源数据。在预处理、分析的基础上, 通过数据访问服务 (DAS) 统一访问异构数据源, 并采用基于服务数据对象 (SDO) 的技术结合基于Map Reduce的数据转换架构、基于HBase的存储技术完成海量数据的并行转换应用处理。
4.2 总体设计
基于对平台的需求分析, 得出了系统的功能和性能等要求, 并提出了平台总体设计方案。描述平台的系统数据流如图4所示。
数据源是数据处理中心的基础, 当用户向数据处理中心注册数据源信息后, 数据处理中心就会从数据源中抽取元数据信息并将其存储起来, 然后通过元数据管理模块创建异构数据源间的映射模式。用户选择了数据转换操作后, 在数据处理中心转换数据的过程中, 数据处理中心要读取元数据和相应的映射模式, 以实现异构数据的转换。所有工作完成后, 数据处理中心会将转换后的目标数据返给用户应用或者将其存储到目标数据库中。基于SDO的数据统一访问与转换平台的总体技术架构如图5 所示。
基于SDO的数据统一访问与转换平台由数据源、元数据抽取管理、数据抽取管理、数据转换管理、模式映射管理、数据存储管理和目标数据应用7 部分组成。
元数据抽取管理和数据抽取管理共同构成了数据源访问模块。它负责根据所选择的数据源类型获取元数据信息, 并在其运行时与数据源交互完成数据抽取工作。在元数据信息抽取和数据源数据信息抽取的过程中, 主要使用服务数据对象 (SDO) 和数据访问服务 (DAS) 完成相关工作。
模式映射管理和数据转换管理共同构成了数据转换管理模块。在数据转换管理模块中, 用户需要定义各转换节点的转换规则, 创建任务工作流, 依据模式映射构建从源到目标的字段映射转换等, 然后再将这些映射规则 (元数据) 存储在元数据管理模块中。当用户执行任务时, 系统会从元数据管理模块中查询转换映射规则, 并完成数据的转换。
元数据管理和模式映射管理共同构成了模式管理模块。在该模块中, 元数据管理主要负责元数据的抽取和解析。这里的元数据主要包括数据源信息描述、目标信息描述。模式映射管理主要依据元数据管理模块提供的元数据信息创建、转换和映射规则信息等。
数据存储管理主要负责模式映射管理模块创建的映射模式存储和转换规则、转换中间数据的存储等。
5 应用前景和效益分析
分布式异构数据库访问 篇4
C/S (Client/Server) 结构 , 即传统和经典的客户机和服务器模式的软件系统技术架构。它可以充分利用两端软硬件环境的技术优势, 将业务处理任务合理分配到Client端和Server端来实现, 充分利用客户端资源来开发和部署具有很强交互性的业务 实现和全 方位的网 络应用体 验 , 即具有富 客户端特性 的业务应 用系统。 从数据库 访问层面 来看 , 这种应用技 术架构的 优势是直 连数据库 访问提供 高性能数 据访问和数 据传输 ; 但是 , 劣势也很 明显 , 首先 : 数据库连 接是数据库 中关键和 有限的昂 贵资源 , 对数据库 连接的管 理显著地影 响到整个 业务应用 程序的可 扩展性、 可伸缩性 和健壮性; 其次: 随着网络跨区域的互联互通, 业务系统部署在更广范围和区域, 业务用户在不断增加, 系统并发负载在不断加重, 对数据库连接的复用显著地影响到整个业务应用程高并发性。 所以 , 基于B/S (Browser/Server浏览器和 服务器 ) 和C/S/S (Client/Application Server/Database Server) 模式的技术架构逐步发展, 优化和改造基于C/S架构直连数据库访问应用模式和应用场景。
2 分布式数据库访问技术
随着网络和分布式技术发展, 以及三层 (客户机<->应用服务器 (中间层) <->数据库服务器) 和多层软件技术架构的完善, 数据库逐步部署在业务应用的最后端, 甚至以集群的部署方式来提供高性能、高并发和高可用性的业务数据存储和处理。特别是SOA (Service-Oriented Architecture面向服务的体系结构) 分布式技术发展和成熟, 基于SOA技术的分布式数据库访问应用正在业务系统中应用, 以提供松耦合和面向服务特性的业务系统, 为C/S结构业务系统改造升级和新业务系统开发设计提供了一种成熟软件架构技术, 同时系统又不丧失Win Form程序丰富用户交互体验和系统性能。所 以 , 分布式数据库访问设计、开发和实现有其现实应用业务场景。
3 分布式数据库访问设计
3.1 设计要求
应用Microsoft .Net SOA框架的WebService或WCF (Win-dows Communication Foundation) 技术设计和开发分布式数 据库访问, 提供一种精简和通用的分布式数据库访问架构模型, 同时要具有可扩展性、高并发性和高稳定性, 以满足复杂业务应用系统开发, 以及有利于原有基于C/S技术架构业务系统的技术改造和演进。
3.2 数据库访问层接口
数据库对 数据处理 都支持select、insert、update、delete基本DML (data manipulation language) 的操作, 大型数据库都支持SQL编程, 特别是存储过程 (Stored Procedure) 的支持。存储过程是在大型数据库系统中为完成特定功能的一组SQL语句集 , 编译后存储在数据库中 , 存储过程是数据库中的一个重要对象, 具有重复使用、高性能、减少网络流量和图1数据库访问层接口设计业务处理安全性等优点。数据库访问层接口设计基于select、insert、update、delete和Stored Procedure进行抽象和设计 , 满足系统多层软件架构体系中数据库访问层设计和实现, 实现直连数据库访问的复用和管理, 并为分布式数据库访问设计和实现提供底层支持和扩展, 数据库访问通用类Execute Db-Common, 其接口设计如图1所示 , 支持和兼容多种数据访问, 如: Oracle、SQL Server、Ole Db等.Net Provider驱动。由于文章篇幅所限, ExecuteDbCommon代码略。
3.3 分布式数据库访问接口
在数据库访问层接口设计和实现基础上, 定义和设计基于SOA技术框架的分布式数据库访问, 设计如图2, 基于.Net4.0中的Wcf技术进行实现。数据库访问层Execute Db Common类应用的Db Parameter类不能序列化, 为了分布式方法调用存储过程的参数转换和安全, 设计了Db Procedure Parameter类, 与Db Parameter相对应 , 具有数据 加密或压 缩扩展特 性 , 与Db Parameter互相进行数据转换 , Db Procedure Parameter类设计如图2所示。
分布式数据库访问接口IShared Wcf Service设计含有如图3所示的4个接口定义。
IShared Wcf Service接口中的参数和返回结果可以加入压缩或加密处理机制, 保证接口调用和数据安全, ISharedWcfSer-vice主要代码为 :
4 分布式数据库访问接口实现
4.1 概述
基于.Net WCF技术和ISharedWcfService接口定义, 设计Shared Web Wcf Service类和Shared Wcf Service类 , Shared Wcf-Service类继承IShared Wcf Service接口 , 并应用数据库访问层ExecuteDbCommon类和DbProcedureParameter类实现分布式数据库访问, 提供最基本数据库业务数据操作实现, 可以应用对象二进制序列化、反序列化、压缩、加密和客户端验证等相关技术进行性能优化和接口调用安全保障。 同时, 依据实际业务系统需要进行客户端业务逻辑处理扩展、中间层服务层 (如IIS) 和数据库层进行扩展, 业务逻辑可以封装在数据库存储过程, 以提高数据处理性能和保障数据处理安全。分布式数据库访问SharedWcfService类设计和实现如图4和图5所示。Shared Web Wcf Service类继承Shared Wcf Service, 进行WCF SharedWebWcfService.svc服务部署 , 方便实现客户端验证、调用安全等机制加入。
4.2 主要服务接口实现
SharedWebWcfService类实现主要代码和结构 :
5 结语
分布式数据库访问基于.NET设计和实现方案实现了最基本的分布式数据库访问方法, 使得传统直连数据库访问以分布式SOA技术形式提供给客户端或其他业务应用。该模型很好地实现了C/S系统向分布式架构的技术演进, 且不会对原有系统带来很大冲击而实现系统的松耦合。分布式数据库访问技术成功地应用于基于.Net Win Form开发的部门预算编制、财源监控等系统升级和开发, 使系统平稳地由C/S二层系统结构升级为分布式C/S/S多层架构系统, 实现系统平稳地技术升级和演进, 并保留了原有系统丰富用户体验和高性能, 同时又具有扩展性和高并发性。
参考文献
[1]罗威.WCF编程.2版.北京:机械工业出版社, 2009.
[2]罗福强, 白忠建, 杨剑.Visual C#.NET程序设计教程.北京:人民邮电出版社, 2009.
[3]沃森 (Watson, K) , 内格尔 (Nagel, C) .C#入门经典.5版.北京:清华大学出版社, 2010.
分布式异构数据库访问 篇5
随着信息化和网络技术的飞速发展,政府及各企事业单位建立了多个不同的信息系统。但是各个系统按照自身需求采用了不同的数据模型,选用了不同的存储方式乃至不同的数据库,数据共享困难,容易形成信息孤岛。为了保证各层次共享数据的一致性,实现信息共享,快速支持业务过程变更,帮助决策者能够从全局把握目前状态和发展趋势,必须实现分布式异构数据同步集成。
XML技术以其松散、灵活、易于跨软硬件平台等优点,已成为Web服务的技术基础。本文提出了一种基于XML/JAVA的分布式数据交换构架,以XML为数据交换的载体,利用Java技术作为中间件实现平台,构建了一种跨平台的异构数据集成中间件平台,对各个系统的数据做实时同步处理,快速构建数据同步集成。
1 系统架构设计
中间件协调各数据库系统,监控数据流动,在数据库系统之间提供统一的数据模式和数据访问接口。利用中间件集成异构数据库,并不需要改变原始数据的存储和管理方式。
该系统模型分为两层:适配器层和系统边界层,系统架构如图1所示。
1) 适配器层:
提供数据抽取、清洗、打包、路由、传输、验证、解析等核心功能。以XML文件作为信息传输的载体,FTP传递数据包文件、WebService服务传递指令信息,调用远端应用完成系统功能。每一个适配器在整个系统中有一个唯一的ID,在启动配置中,这个ID与IP地址(端口号)一一对应。
2) 系统边界层:
包括业务系统、数据库和文件系统等。针对遗留的业务系统,数据库中建立触发器,提供有效的、可及时更新的数据。而对于新业务系统,业务端开发方按照同步集成的要求提供数据同步接口或在数据库系统中维护同步集成的数据库表,将同步集成逻辑加入业务系统中。
2 关键技术
2.1 数据描述
数据同步集成框架包括抽取打包、验证解析,分别表示数据库到XML的映射和XML到数据库的映射。在这两个过程中形成XML数据传递包,描述了需要同步的业务数据、监控表及字段之间的映射。
数据传递包包体文件格式[1,2]:
< xml version=″1.0″ encoding=″UTF-8″?>
<TABLE>
//表结构字段,只在测试系统的时候和第一次启动数据同步的时候传递
<T N=″DEMOTABLE″ C=″DEMOTABLE″>
<F N=″DEMODID″ T=″VARCHAR2″ L=″20″ P=″Y″ F=″N″ />
<F N=″EMAIL″ T=″VARCHAR2″ L=″400″ P=″N″ F=″Y″ />
</T>
//N-NAME,C-CONNAME,T表示一个表
//F-FIELD表示一个字段,N-NAME表示字段名称
//T-TYPE表示类型,L-LENGTH表示长度
//P-PRIMARYKEY表示是否主键, F-FILE表示是否文件字段
</TABLE>
<DATA>
<T NAME=″DEMOTABLE″>
<ROW F=″I″>
//F-FLAG表示操作标志
<DEMODID>MTIzNDU2</DEMODID>
<EMAILFileName PATH=″/upload″
NAME=″03160000000800520100420000085213.doc″>
NjM1NTI2ODQuZG9j//63552684.doc
</EMAILFileName>
</ROW>
</T>
</DATA>
首先是元数据部分(元数据是关于数据的内容、质量、状况和其他特性的信息),初始化的时候进行传输,因为元数据只是在软件初始化时验证配置文件使用的。后面的数据部分是对数据库表变动的差异进行传输,操作标志I表示这是一条插入数据,根据元数据部分“DEMODID”是主键字段,“EMAILFileName”为储存文件字段,储存的是数据库表中的文件名,PATH表示文件的相对路径,NAME表示实际的文件名。表字段的值统一使用Base64编码方式进行编码。
2.2 适配器核心模块
适配器核心模块架构分为两层:核心处理器和边缘节点(Node),如图2所示。
边缘节点分为三种类型:读节点(ReadNode)、数据过滤处理节点(ProcessNode)和写节点(WriteNode)。这三类节点分别由对应的三类连接器转换而来。针对不同的应用如JMS、WebService、HTTP等开发不同的连接器,由连接器(Reader,Writer)负责与应用系统直接交互。定义不同的规则,采用抽象方法的方式在节点层中屏蔽底层的规则。这样针对新的模式只需开发对应的连接器即可满足系统升级的需要。
连接器(Reader,Processor,Writer)的对应关系通过配置文件的方式在系统初始化的时候传入核心处理器。连接器转换为对应节点(Node)的装配关系保存在HashMap中。ReaderNode与ProcessorNode、WriterNode为一对多的关系,ProcessorNode可以连接ProcessorNode或者WriterNode,WriterNode为传输过程的终点。核心处理器负责调配整个系统的运行过程,每当有数据需要传递时,核心处理器分配给ReadNode一个线程,ReadNode启动线程并发起数据传递,将数据封装成Message通过装配关系查找下一节点,然后交给后续节点(ProcessNode或WriteNode),ProcessNode过滤清洗数据,最终数据下发到对应的各个WriteNode,WriteNode调用(Writer)写入到目的端。Message携带数据源节点信息、目的节点信息、元数据信息和事务管理信息。不同的Message携带统一的事务管理信息来保证所有WriteNode节点的事务统一提交。
3 流程实现
3.1 遗留的业务系统
在文档和系统源代码可能不全或非Java构建的系统的情况下,对其数据库和文件系统存储结构进行分析,对数据库和文件系统进行监控,感知数据库和文件系统的变化,从而捕捉变化的数据分发给其他业务系统的方式来进行处理。
1) 针对数据库变化的数据的捕捉[3],对每一个需要同步的表建立监控表(表1)并使用触发器或者影子表来感知数据的变化,并将数据的变化记录在控制表中,同时加入时间戳来确定数据变化的顺序。主表监控表只记录变动的数据的主键,通过变动的数据的主键与待同步的表进行联合操作获取变化的数据。操作标志有三种即插入、更新、删除。更新时间记录数据发生变化的时间。数据包ID用于记录由哪个XML数据传递包来处理这条变化的数据,初始为空值。处理标志记录该条记录的处理状态。
核心处理器定时扫描主表监控表,发现数据变化后,使用Reader连接器通过表连接的方式获取未处理的变化的数据,将变化的数据通过Writer连接器以XML的格式写入到XML数据传递包文件中。
将大字段提取成临时文件,而文件则直接拷贝到临时文件中,与XML数据传递包一起打包压缩加密。
2) 建立发送控制表(表2)来监控数据的传递过程,数据包ID和目的ID构成联合主键。数据写入到XML数据传递包,根据系统配置压缩加密,以FTP的方式自动发送到目的端,同时使用WebService通知目的端进行数据解析操作,将发送信息写入到发送控制表作为发送异常、超时后重新发送的依据。数据的一致性与冲突则通过制定一系列规则进行处理。针对反复重新发送仍不能成功接收到回执包的数据需要通过人工干预的方式进行处理。回执标志分为传输成功和解析成功两种。
3) 建立接收控制表(表3)监控数据的传递和解析过程,数据包ID和源ID构成联合主键。源发送端调用目的接收端的WebService服务向接收控制表中填入数据,并启动核心处理器进行数据解析操作,首先验证数据包的完整与正常,然后将源发送端发送控制表中相应回执标志更改为传输成功。核心处理器通过Reader连接器读入XML数据传递包文件,通过数据过滤筛选,使用Write连接器将数据写到目的数据库中,完成同步操作。正常写操作结束后,将源发送端发送控制表中相应回执标志更改为解析成功,完成整个操作过程。
3.2 新开发业务系统
针对新开发的业务系统需要数据集成,在业务系统中对外提供SOA接口,提供数据交互的方法[4]。两个同步系统的一方提供数据写入接口,比如WebService、JMS和FTP等等,另一方在业务系统中将核心处理器嵌入到业务系统内部,采用一定的规则间隔触发核心处理器,核心处理器使用Reader连接器从系统中用某种方式如JDBC等读出数据,经过抽取、过滤形成Message格式数据,通过Writer连接器写入到另一个系统中完成数据集成需求。
4 应用实例
根据前面的框架结构,开发核心处理器模块,作为某高校校园管理平台主要的支撑工具,在教务成绩系统和高校管理平台之间进行双向实时的成绩信息同步,共享成绩数据资源,达到一点输入全局数据共享的目的。
从教务系统方向看,系统首次启动教务管理系统中数据集成模块,核心处理器启动JDBC读连接器获取教务系统全部数据,经过数据过滤节点过滤错误格式数据编码加密,使用XML写连接器将正确数据写入到数据包中压缩,调用FTP服务将数据发送到目的端,同时使用WebService服务通知校园平台端核心处理器,校园平台端核心处理器解压启动XML读连接器读入数据,解密解码,经过数据过滤去验证数据正确性,使用JDBC写连接器将数据写入校园平台端数据库,完成启动数据同步。
经实验,在校园网环境中,首次启动教务管理系统中数据集成模块共传输数据20627条,传输时间32291ms。实现了某学院一届学生(250人左右)四年的全部成绩的导入功能。
系统运行期间,需要同步数据的规模比较小,JDBC读连接器读出数据,以“字段名->字段值”的方式存储在内存中。核心处理模块直接使用高校管理平台的WebService模块(基于CXF的数据接口)直接写入到高校管理平台的数据库中。
教务处系统进行导入等操作的时候,突发的数据量比较大时(每次传输数据300条以上),这种情况下先将数据写入到XML数据包中,调用FTP服务发送到校园管理平台端,通知校园平台端核心处理器,验证后写入数据库中。
在广域网环境中,系统会受到更多的环境因素的影响,经实验网络性能瓶颈主要在数据包的传输过程中,目前所采用的FTP的方式是比较合理与高效的,同时系统即插即拔的组件化、可扩展的设计,也支持使用其他方式进行数据传递。
5 结 语
本文构造了一种基于Java/XML的松耦合的数据同步集成关系,以XML作为数据交换集成的载体,允许用少量的或非常规的编程进行快速的商业系统集成,具有开放性、可伸缩性、可移植性、灵活性。此集成框架结构为企业信息化集成提供了一种有效的方法,使不同信息系统的整合变得简单,使不同系统间的数据分享变的更容易,实现了分布异构数据的无障碍交互。
参考文献
[1]沈敏,许华虎,季永华,等.基于XML的分布式异构数据库数据同步系统的研究[J].计算机工程与应用,2005,41(5):184-186.
[2]陶以政,唐定勇,何铁宁,等.基于Java和XML技术的异构信息系统数据集成框架应用研究[J].计算机应用研究,2004,21(5):38-40.
[3]者敬.开放式异构数据库复制框架的研究与实现[D].北京:中国科学院软件研究所,2002.
分布式异构数据库访问 篇6
关键词：异构数据库,数据交换XML
一、引言
随着网络技术的迅猛发展, 高校的校园网建设已进入一个新的阶段即数字校园的建设。所谓数字校园, 即在传统校园基础上, 利用先进的信息化手段和工具, 将校园原有的各项资源数字化, 以网络为基础, 建设基于校园网的信息系统。
基于校园网的信息系统开发不仅仅是开发新的系统, 更为关键的是对现有信息资源的有效整合, 即应用的集成。因为在信息系统开发之前可能已有很多的应用系统存在于校园网络之中, 从学校管理、行政办公到教学管理、学生管理与学习等学校的方方面面。对现有系统进行整合可以有效利用现有资源、保护前期投资、降低开发成本。
但是, 这些应用系统由于开发的时间与开发的部门不同、所使用的数据库存在差异, 导致了“信息孤岛”的产生。所以, 有效地对应用进行集成的前提就是首先要完成数据的集成与交换。这就需要在校园网上建立一套完善的基于校园网的数据集成交换平台。通过这个平台, 一方面一个部门可使用其他部门的数据;另一方面, 也可以通过该平台提供的数据交换功能有效地维护各部门间数据的一致性与完整性, 以提高工作效率。
二、异构数据交换概述
在异构数据库中主要包括数据模式异构和逻辑异构。数据模式异构显然是指采用了不同的DBMS;而逻辑异构则包括命名异构、值异构、语义异构和模式异构等。实现异构数据交换有许多方法, 常用的有:软件工具、利用中间数据库的交换和利用XML实现异构数据库间数据交换。
(一) 软件工具
使用数据库管理系统提供的将外部文件中的数据转移到本身数据库表中的数据装入工具。比如:Oracle提供的SQL Load-er, SQL Server提供的DTS等。
使用这些数据转换工具的缺点是:它们不是独立的软件产品, 必须首先运行该数据库产品的前端程序才能运行相应的数据转换工具, 通常需要几步才能完成, 且多用手工方式进行转换。如果目的数据库不是数据转换工具所对应的数据库, 数据转换工具就不能再使用。
(二) 利用中间数据库的交换
由于缺少工具软件的支持, 在开发系统时可使用“中间数据库”的办法, 转换时, 依据关系定义、字段定义, 从源数据库中读出数据通过中间数据库写入到目的数据库中。
这种利用中间数据库的转换办法, 所需转换模块少、扩展性强;但缺点是实现过程比较复杂, 转换质量不高、转换过程长。
(三) 利用XML实现异构数据库间数据交换
使用XML作为中间数据实现异构数据库之间的数据交换, 体系结构如图1所示。
这种方式源于Internet的电子商务模型, 将数据源用XML格式统一描述, 每个数据库系统具有高度的自治权。在进行异构数据库数据交换时, XML可以解决数据的统一接口问题。因此, 利用XML访问异构数据库是一种理想的解决方案。
但使用基于XML的数据交换从技术上还必须解决XML与数据库之间的数据模型映射问题, 即如何将关系数据库的数据模型准确地映射到XML文档中, 其中又有两个问题:一是模式的映射 (即关系模式的映射) ;二是数据类型的映射。
三、基于XML的异构数据库数据交换模式映射
用XML进行数据集成, 对所有的异构数据源增加一个以XML为格式的封装体, 即在不改变数据源的前提下, 用XML对数据源的定义、描述和创建等相关信息进行封装。
(一) 数据模型的映射
当把数据从数据库传送到XML文档或把数据从XML文档传送到数据库时, 是用一个具体的模型实现的, 而不是仅仅依赖内嵌SQL命令。关系数据库的理论依据是关系模型, 面向对象数据库的依据是对象模型, 而XML文档的依据是XML Schemas或DTD。基于模型驱动实现数据在数据库和XML文档间的双向传输, 关键是在数据库模式和XML Schema S或DTD之间建立双向映射。模型驱动的映射机制有基于表的映射和基于对象的映射。
其中, 基于对象的映射功能比较强大, 映射比较丰富, 可以根据需要转换成格式多样的XML文档。这种方法有了模型的支持, 可以完成XML文档和数据模式的映射。但是由于模型的引入, 也使XML文档受到了限制。一个XML文档必须符合模型所规定的结构, 才能将XML文档映射为其他类型的数据, 而从其他类型数据转换为XML文档也具有某种结构特点。所以, 基于模型的映射方法关键在于设计一个灵活的映射模型, 以尽量减少XML文档结构的限制。
目前, 关系数据库到XML的转换算法有以下三种:
1. V.T在1999年提出面向数据结构的关系模式到DTD影射算法。
2. J.sh·g·daram提出基于内嵌的关系数据到DTD的转换算法。
3. 保留语义约束的关系模式到DTD映射算法。Lee Dongwon博士首先研究了基于内嵌的关系数据到DTD的转换算法, 提出并建立了关系模式到DTD的映射约束保留机制。
(二) 数据类型的映射
从目前校园网中的应用看, 广泛使用的数据库主要包括Microsoft的SQL Server 2000、Oracle、DB2及小型的Fox Pro、Access等。这些数据库的数据类型从命名、表示范围、种类等都有差别。所以XML与关系数据库之间的数据类型、格式、表示方法等必然存在着许多不同。因此, 要实现基于XML的异构数据库之间的数据交换首先必须解决这两者之间的数据类型转换问题。
通常由数据交换程序负责完成XML和数据库数据类型的转换。常见的有两种方法:一种是程序根据数据库模型来确定数据类型;另一种是由用户明确指定数据类型, 可以由用户写出, 也可以自动从数据库模型或XML模型中产生。
DTD不支持数据类型, 但XMLSchema具有完善的数据类型体系。XML Schema定义了两种主要的数据类型:简单类型和复杂类型, 复杂类型是简单类型的组合。简单类型可以分为原子类型、列表类型和联合类型, 其中列表类型和联合类型都是由原子类型组合而成。Schema的原子类型在SQLServer2000大都有相应或相似的格式。二者的映射关系如表1所示。
四、基于XML的分布式异构数据库数据同步系统
基于对异构数据库之间数据交换技术的研究, 本文将探讨基于JMS和XML技术的跨平台、以可靠异步通讯为特征的数据同步平台DSP (Data Synchronization Platform) 。
图2给出了系统的框架结构和主要模块。
DSP Center是数据同步平台信息交换中枢, 它主要包括消息服务器 (JMS Server) 、名字服务器 (LDAP/JNDI Provider) 、管理配置中心 (ADMIN TOOL) 。
消息服务器是系统的核心, 采用遵循JMS (Java Message Server) 标准的JMS Server。DSP在JMS服务器上建立消息队列, 目前采用发布/订阅 (Pub1isher/Subscriber) 模式的消息队列。在该传送模型中, 目标类型是主题, 消息首先被传送至主题目标, 然后传送至所有已订阅此主题的接收端, 即在该模型中, 可以向主题目标发送消息的发送端的数量没有限制, 并且每个消息可以发送至任何数量的订阅接收端。
对消息服务器的访问通过名字服务器, 遵循JNDI (Java Naming and Directory Interface) 接口。通常情况下, 都是用JMS Server来实现名字服务器, 如果JMS Server没有自带名字服务器, 则将消息服务器的对象发布在LDAP服务器上。
管理配置中心负责将消息队列、用户发布到服务器上, 配置用户所具有的权限等。配置信息主要包含有连接管理, 即配置用户连接到的服务器信息;消息配置, 即建立消息队列MQ, 并发布到服务器上;用户管理配置, 即创建用户及权限的分配, 配置用户所使用的消息队列及连接信息等。
DSP Client客户端完成同构或异构的数据库的动态同步, 它不会直接去修改业务表, 而是通过建立缓存表来取得业务表的数据变化。每个DSP Client都包括发送端和接收端两部分功能, 数据库的数据被描述成XML格式, 在发送端和接收端进行传递。发送端对XML数据进行数据导出、数据加密、数据发送等任务, 接收端实现对XML数据的接收、数据解密及数据导入等任务。
五、结语
校园异构数据的集成与交换是信息系统建设必须要解决的问题。本文对基于XML的异构数据库数据交换原理与方法进行了研究, 并初步构建了“基于XML的异构数据库同步系统”, 该系统已经得到了初步的应用, 可以较好地解决信息系统建设中的“信息孤岛”问题。
参考文献
[1]鱼宾, 郑娅峰.基于XML的异构系统集成框架的研究[J].计算机应用与软件, 2005, 22 (7) .
[2]沈敏, 许华虎, 等.基于XML的分布式异构数据库数据同步系统的研究[J].计算机工程与应用, 2005, 41, (5) .
分布式异构数据库访问 篇7
随着Internet的发展,数据库和网络的结合日益密切。由于各种信息化系统实施的阶段性、技术性及其它经济和人为因素的影响,致使在企业内部,不仅数据的格式和存储方式不尽相同,数据的管理和使用系统也大不相同,于是就形成了企业异构数据源。尽管异构数据源的存在并不影响单个系统在各自领域的工作,但随着企业规模的不断扩大和技术改造的深入,新的应用系统的构建和实施往往需要访问各种不同的数据源,因此为了寻找解决异构数据源的检索、访问、查询和共享问题的方法,使用传统的数据库系统由于耦合性太强,不适合松散系统的集成,也很难实现各个部门之间的数据共享和访问。而XML技术的出现,为解决这个问题提供了有效和可行的技术基础。本文就是结合我院实际情况,利用XML中间件技术设计集成模型,实现了分布式异构数据库的检索、查询和访问,并已得到满意的结果。
1基于XML中间件的分布式异构数据库模型
传统的中间件技术为了解决异构数据源之间的集成问题,通过对数据库的模型的转换、模式转换来实现对数据库的透明访问,它提高查询的准确度、降低查询的难度。而采用如图1所示的中间件模型设计技术,能有效地提高查询效率和降低查询难度。文中的XML中间件的主要模块如下:
(1) 全局DOM树
DOM(Document Object Model)是W3C组织推荐的一组完整的XML文档结构,可用于直接访问XML文档的各个部分。在DOM中,文档被模型化为一颗树,其中每个XML语法都用一个节点表示。DOM是一种API,全局DOM树则为Web应用提供了全局接口[1]。
(2) 核心处理模块
它是XML中间件层的核心模块。在DOM树中,从根到叶子的一条完整路径分支上所有元素节点的元素标记构成一个有序集合或者其子集就是一个路径模式。从根到叶子的一条完整分支上所有元素节点组成的有序序列称为一个路径实例,它通过全局DOM树上每一条从根到叶子节点的路径实例,参照XML schema所提供的路径模式信息,按照对象树路径模式的路径实例均衡法[2]PSPIB(path schema based path instances balancing)的策略,将具有相同路径模式的路径实例平均打散到各个站点上去。本文采用的方法与PSPIB相似,利用对象树、子树的方法来实现核心处理模块,并生成如图1所示的局部DOM树。
(3) 局部DOM树
数据分片完毕后,再在各个站点上按照XML文档本身的XML schema模式信息重新组成与全局DOM树同构的一棵局部DOM树,即二者符合同样的模式但后者只是前者的部分子集,各个站点上的局部DOM树合并起来就形成了一棵全局DOM树。
(4) XML-DBMS[3]接口
每个数据源都配各自的XML-DBMS接口,它是各种分布式异构数据源的中间件。当接收到查询请求后,XML-DBMS根据该查询请求从数据源中抽取需要的数据,并把获得的数据转化为XML形式。另外,XML-DBMS还承载了DOM树与数据源的转换操作。
2 基于对象树、子树节点的数据分片法
2.1 传统的数据分片策略
分布式数据库的关键技术之一就是数据分片策略,所采用的方法主要有一维数据分片方法和多维数据分片方法,一维数据分片方法包括Round-Robin[4]、Hash[5]、Range[6]和Hybrid-Range-Partition[7]等,多维数据分片方法包括B-Tree.和X-Tree等。Round-Robin方法以轮转的方式将关系的元组分布到各个处理机上,当关系上的操作需要存取大量元组时,一般采用这种分布方法。缺点是它不能有效地支持具有低选择性谓词的查询,要求所有的处理机都启动工作,降低了系统的效率。Hash分布方法选择关系的一个属性进行Hash,然后根据Hash值将关系分布到各个处理机上。优点是可以有效地支持划分属性上精确匹配谓词的查询,但是Hash方法不能保证数据均匀地分布在各个处理机上。Range和Hybrid-Range-Partition的分布方法是将关系选择到各个处理机上。优点是有效的支持大数量存取的查询和划分属性上具有低选择性谓词的数据操作。缺点是数据在处理机上不均匀和工作负载不均匀。多维数据分片是指利用关系的多个属性对整个关系数据库进行划分并在各站点存储的方法,缺点是实现比单维数据分片复杂很多。上述的数据分布方法都是适用于某些类型的查询,而在处理其它类型的查询则效率较低,甚至会导致严重负载倾斜。而对于XML这种半结构化数据,它表示成DOM树的形式,包含了复杂的嵌套结构,将它转换成关系数据表的形式会造成大量数据冗余。而采用本文的对象树、子树的数据分片策略,能很好地解决上述问题。
2.2 与XML文档相关的对象树、子树的定义
令doc表示一篇XML文档,DOM(doc)是对应文档doc的DOM树,root(doc)是文档doc的根元素。根据说明,给出下面定义:
定义1 对象树 在XML文档中,元素中又存在元素这种性质的元素称为类元素,把类元素通过连线连接而组成的一颗树称为对象树,其中,有一个入度为0的类元素被称之为对象树的树根。对象树与DOM树相类似,但不是DOM树,它的元素本身没有像DOM树那样存在叶子这样的数据或文本。因此,我们可把DOM树中存在类元素节点的树部分称为对象树。所以,一棵DOM树可以看成是由一棵对象树和其下的一组叶子节点集合组成的一棵树。
定义2 子树 在DOM树中,树从根结点所能到达每一个叶子节点和边而得到的树称为子树。
定义3 标签化树 是每一个节点都有一条相关联的边的树。
根据定义,数据分片是以子树为单位来进行的,把子树分片到各个站点上称为分片子树。对于一棵DOM树,树的上层节点数很少,而这些节点往往出现在大部分的XML查询中,因此很自然把这些类元素节点构成的集合分配在各个站点上,形成在站点上复制的对象树的树根。对子树标签化,是因为方便查询和查找。
2.3 基于对象树、子树的数据分片的方法
基于对象树、子树的数据分片原则如下:(1)将对象树的树根复制到各个站点上,形成部分DOM树的树根。(2)将子树设置成标签化树。(3)将标签化树平均分片到各个站点上。(4)与各站点已复制的树根合并生成一棵局部DOM树。每一棵局部DOM树,其上部仍然是一棵对象树,其下部是一组叶子节点而组成的集合。这种分组的目的就是使同一组内子树具有相似的结构,方便查询,提高查询的并行性。但是,在进行数据分片和对数据查询中,也存在几个问题:(1)子树的分解问题,怎样求得每一棵子树。(2)数据查询集中在一个或几个站点上,其它站点空闲等待的问题。(3)分片对查询的性能的评价结果。
3基于对象树、子树的数据分片算法及存在问题的解决方法
3.1 子树求解
对DOM树求子树采用回溯法[8],由于问题的解向量(子树)X=(x1,x2,…,xn)中的每个分量xi(1≤i≤n)都属于一个有限集合Si={ai1,ai2,…,airi},因此,回溯法可以按某种顺序依次考察笛卡尔积中的元素。初始时,令解向量(子树)X为空,然后,从根结点出发,选择S1的第一个元素作为解向量X的第一个分量,即x1=a11,如果X=(x1)是问题的部分解,则继续扩展解向量X,选择S2的第一个元素作为解向量X的第二个分量,否则,选择S1的下一个元素作为解向量X的第一个分量,即x1=a12。依次类推,一般情况下,如果X=(x1,x2,…,xi)是问题的部分解,则选择Si+1的第一个元素作为解向量X的第i+1分量。最后求出所有的解向量。所有的解向量就是所求的子树数。subtree算法限于篇幅略。
3.2查询集中在一个或几个站点而其它站点空闲的解决采用减治方法
利用减治法中的数据平分原则,首先求出DOM树的最大树深和最小树深,若最大树深的一半比最小树深差距不是很大,就把最大树深的子树折半,然后把下一半棵子树与复制的对象树的树根结合,生成一棵新的子树,分配到一个新的站点上,若最大树深的折半子树还比最小树深的子树大很多,则重复以上步骤,对它两两折半,直到折半的子树的树深与最小树深差距不是很大,再把折半的子树与复制的对象树的树根结合生成一棵新的子树,重新分配到一个新的站点上。这样,解决其它站点空闲问题,也就解决数据查询不会集中在一个或几个站点上。减治法Decompose(i)算法限于篇幅略。
Decompose(i)是描述如何把一棵子树折半成二棵或者二的倍数的子树的减治法算法,其中,low表示DOM树中的最小树深,high表示子树的树深,high>>low表示子树的树深远远大于最小树深。
3.3 基于对象树、子树的数据分片算法
根据2.3节的数据分片原则,对于一棵DOM树,得到其算法如下:
算法partition(DOM)
3.4 分片结果对查询性能的估算
基于对象树、子树的数据分片策略的数据查询响应时间应考虑CPU、磁盘I/O和网络通信这三项基本资源开销,即通过I/O操作响应时间Ti/o、网络通信响应时间Tc和CPU平均处理时间
式中,p:一个站点上的某一棵子树满足查询条件的节点的比较次数;q:一个站点上的不同子树中满足查询条件的节点的比较次数;m:参与查询的站点个数,n:并行系统支持的站点个数;τi/o是装入一棵子树的单位时间;λ是比较一次所需时间。
Tc的时间可由式(2)估算:
式中,vnet是网速;
所以,数据查询响应时间为:
3.5 测试结果分析
为了验证提出的数据分片策略,我们采用的计算机为:intel p4 2.4GBHzCPU、256M主存、RealTek 8139 Family PCI Fast Ethernet NIC 网卡;操作系统为: Windows XP、UNIX、Windows 2003;数据库为SQL 2000、SQL 2005、Orcale等;分别在信息系办公室、网络中心、学院办公楼、图书馆和教务处等五个不同地点与PSPIB进行数据查询性能好坏对比实验,测试时采用的数据为20M、40M、60M,经测试,得出它们的性能加速比曲线由图2～图4所示。
4 结 论
从图2、图3、图4的性能加速比曲线得知:对于数据量小于40M的数据查询,采用本文提出的数据分片策略没有PSPIB查询性能好,但对于数据量大于60M,该方法比PSPIB要优越得多。在我院各部门对异构数据库数据查询中,采用本文的数据分片策略已获得满意效果。
参考文献
[1]赵君,张春海,等.基于XML中间件的分布式数据库的数据分片策略[J].计算机工程与设计,2006,27(3):466-468.
[2]Wang GR,Tang N,YX,et al.A data placement strategy for parallelXML databases[J].Journal of Software,2006,17(4):770-781.
[3]Ronald B.XML-DBMS,version 2.0,Alpha 3 Java Middleware forTransferring Data Between XML Documents and Relational Databases[EB/OL].http://www.rpbourret.com/xml dbms/readmelx.htm.
[4]Teradata Corporation.DBC/1012 Data Base Computer Concepts andFacilities.Teradata Document C02-001-05,Los Angeles,Calif,1998.
[5]Kitsuregawa M,Tanaks H,Moto-Oka T.Architecture and Performanceof Relational Algebra Machine GRACE[C]//Proc.of the Intl.Conf.onParallel Processing,Chicago,1984.
[6]DeWitt D J,et al.GAMMA:A High Performance Dataflow DatabaseMachine[C]//Proc.Of Inter.Conf.on VLDB,1986:228-237.
[7]Shahram Ghandeharizadeh,David Dewitt J.Hybrid-range-partitioningstrategy:A new Declustering strategy for multiprocessor database Ma-chine.VLDB,1990:481-492.
【分布式异构数据库访问】推荐阅读：
分布式异构数据09-24
分布式数据库系统07-18
分布式并行数据库07-13
分布式数据库技术07-30
分布式数据库安全问题06-11
分布式数据服务05-08
分布式数据处理06-14
分布式数据采集09-15
分布式传感器数据库论文06-01
分布数据库09-26