空间数据集成（共11篇）
空间数据集成 篇1
近年来,随着GIS特别是WebGIS的快速发展与广泛应用,人们对地理信息资源的需求增加越来越快,但是大部分的GIS产品都有自己专用的数据格式,很难实现整个GIS系统集成以便于空间信息的共享和互操作。为了改变当前GIS应用与内部数据模型以及数据格式紧密捆绑的现状,开放式地理信息系统协会(ODC)推出了基于XML的地理标记语言,即GML(Geography Markup Language),用于地理信息的编码、传输、存储和发布。目前GML已成为Internet上地理信息表示事实上的国际标准,广泛应用于Web和分布式地理信息系统中交换和集成空间数据。
1 多源空间数据集成模式
目前对于不同格式的空间数据集成主要采取以下三种模式:
1.1 数据格式转换模式
数据格式转换模式是指通过某种特定的转换程序将各种异构数据转换成一种数据格式,并将转换后的数据复制到当前系统中。但这种模式也存在缺点,因为它首先需要将异构数据统一起来,这就使得数据间缺少了独立性,而且因为没有统一的描述方法,容易导致异构数据转换后空间数据的信息丢失[1],这样就会给以后使用这些数据构成隐患;另外由于一般空间数据量比较巨大,所以要集中这样的海量数据就显得非常困难。
1.2 数据互操作模式
数据互操作是指空间数据能够在异构数据库和分布计算的情况下交换、理解,不同GIS之间可以直接交互,透明地访问需要的信息[2]。该模式是由OGC(OpenGIS Consortium)制定的规范。数据互操作为多源数据共享与集成提供了崭新的思路,但是它更多地采用了OpenGIS协议的空间数据服务软件和客户软件,对于其它的大量非OpenGIS标准的空间数据格式的处理缺少统一的规范[3]。
1.3 直接数据访问模式
直接数据访问模式是指在一个空间信息软件中直接访问其他软件的数据格式,并且用户可以在该软件中读写多种数据格式。这种模式的优点是不但没有了复杂的格式转换,而且因为访问是发生在一个空间信息软件中,所以就不需要用户拥有主机软件,更不需要运行该软件。这种模式无疑更省人力和财力,但是实现起来对于技术要求相对高一些。
2 GML数据集成研究现状
GML(Geography Markup Language),是开放式地理信息系统协会(OGC)于1999年提出的,在日趋发展的网络环境下,它的提出正是为了成为其中地理数据的一种通用接口,它符合空间数据集成模式中的第二种即数据互操作模式[4]。使用GML对多元异构地理空间数据集成,可以很好的避免以往网络语言描述复杂的空间信息的巨大缺点,因为它对地理空间数据的描述拥有统一的数据格式,从而能够更轻松的便于数据集成。
在国内,对于GML日新月异的发展,也早就已经引起了包括复旦大学、同济大学、武汉大学等众多知名高校学者的重视。武汉大学和国家基础地理信息中心已经开始制定GML国家标准。周水庚课题组早在2003年就提出了一种新颖的方法,用于将GML文档自动转换到SVG文档,论文发表在ACM-GIS 2003[5]。从跨入21世纪以来,关佶红课题组就研究了基于GML和SVG的空间信息集成和发布、GML模式匹配、GML存储机制和查询处理以及压缩算法等[6,7,8,9]。
同时国内外众多学者对基于GML的空间数据集成也进行了大量的研究。Rancourt et al.(2001)将GML与先前所定义的空间标准进行比较,得出GML能有效的满足空间数据交换标准的要求的结论,并预测GML将在行业应用中占据主导地位[10]。旷建中等(2005)采用设计模式方法和GML技术设计多源空间数据集成模型,将数据源通过转换函数生成的GML文档,利用合成器合成GML文档,同时保存到GML数据库,实现多个系统的数据集成,为实现多源空间数据集成提供了一个切实可行的方案[11]。邬群勇等(2005)在分析GML数据格式和几何特征基础上,提出一个基于GML的空间数据动态集成框架,探讨了数据动态集成过程,并以福建省漳浦县绥安镇的林业数据为样本,进行了动态集成应用示范[12]。江卫东等(2007)描述了一个基于GML数据互操作模式的多源异构空间数据集成模型,并分析了该模型的运行机制和关键技术[13],刘占伟等(2007)提出了一个基于GML的多源异构空间数据集成模型,实现了空间数据向GML文档的转换,使用网络服务器技术,在.NET平台上设计实现了该系统,从而实现了基于GML的空间数据集成,而且通过SVG技术实现了数据可视化[14]。
但是,目前的研究工作还远不够系统和深入,实际集成应用方案较少,所提出的一些技术和算法还不能满足海量GML空间数据处理和管理的实际应用需要。因此,还需要进行进一步的研究,探索新的技术方案,开发更有效的算法。
3 基于GML的空间数据集成框架
本文借鉴已有的研究成果提出一种基于GML的多源空间数据集成逻辑框架图(如图1),并且通过使用GML技术来实现异构空间数据的集成与互操作。然而多源空间数据因为来自不同的服务器,每份数据可能拥有各自的数据类型。
1)空间数据建立的输入数据结构由于各自的物理结构不同,而且它们的储存方式也不一样,根据这样的多样性数据结构建立其应用模式。
2)基于GML的输出数据结构的语法、结构和编码模式建立模式转换规则,该规则规定了输入异构的空间数据结构应用模式如何转换成GML Schema。转换模块必须根据模式转换规则对实例模型进行转换,建立基于输出数据结构Schema的GML数据文档,并具有对数据进行编码和解码的能力。
3)虽然来自不同数据源的空间数据都已经转换成了GML数据文档,但不同用户的应用模式间可能存在各种语义或结构上的异构,在空间信息集成中造成歧义和困难。很多情况下,有相同概念的模式在结构和命名上都存在着差异;有些模式有相似的数据模型但包含不同的内容,或是用相同的词表达不同的意义。这就需要进行模式匹配了,它的功能是通过两个模式的相关元素间的匹配关系,来找出这两个模式的元素间的映射关系和集成后的模式。
4 GML模式匹配
模式匹配的目的是为了达到数据集成,而数据集成又是以模式匹配为前提。模式匹配就是指通过一定的算法,把两个模式的所有相关元素进行一一映射,经过一定的分析和对彼此元素的相似度来最终确定模式的元素间的映射关系。
GML模式匹配的基本过程是首先对文档进行数据分析,因为GML文件是遵守XML语法的,可以使用基于树的XML解析器;然后就是通过解析器提取模式文件节点生成GML模式树,生成模式树后,就可以设定算法,对两个模式进行匹配了。在匹配的过程中,最关键的就是确定两个元素的相似度,而元素间的相似度主要表现为语义相似度和结构相似度。用户可以根据具体情况设置一个最小相似度值,即阈值,只有两个元素的相似度值高于这一阈值weight,才进行匹配。
下面是该算法的描述:
MATCH(模式树t1,模式树t2)
{设置阈值weight;//0
设置叶节点的结构相似度s;
For each e1为t1的叶子
{后序遍历t1;后序遍历t2;
for each e2为t2的叶子
{计算两个叶节点的相似度值s;
如上可知算法中输入为两个树状结构的GML模式,输出为一个关于两模式间相关元素的映射关系。其中,tree1和tree2分别表示输入的GML模式树1和GML模式树2,t1和t2为模式1和模式2中的元素,tree1’和tree2’是分别对tree1和tree2进行后序遍历得到的结果。
在算法中,核心参数是确定两个树节点的相似度。在进行匹配时,对树采用后序遍历,并且相似度只确定一次以避免在匹配的过程中产生多对多的关系。当被比较的不是叶节点时,通过比较这两个节点的子节点相似度来确定它们的的相似度,即用其所有的子节点的相似度除以所有的子节点数。叶节点的结构相似度为零。
为了正确的确定两个schema树中的各个非叶节点的结构相似度,在对非叶节点进行匹配前,首先要对叶节点进行匹配,令son(e1)和son(e2)分别代表以e1和e2为根节点的子树上的节点的集合,s(a,b)为其中一个模式中的节点a与另一模式中节点b相似度,则有如下公式(1):
当然最后确定了语义和结构相似度后,需要对两者进行加权求和来获得一个最终相似度,而这个权值由用户自己根据具体情况来确定。
两个模式匹配结束后,可以通过匹配算法生成的映射关系,即模式间元素一一对应的关系来生成集成的模式。
5 结束语
GML作为一种OGC开发的基于XML的地理信息编码标准,使用GML来作为多源异构数据的描述格式,并通过使多源空间数据模式转换为统一数据格式来实现标准化数据层次集成,有利于空间信息充分共享和系统互操作。可是由于GML数据可能来自不同的数据源,导致它们的模式也可能不同,因此模式匹配是GML空间信息集成面临的最严重的挑战,如何能够更进一步的改进模式匹配算法从而简化集成过程,还需进一步的研究。
摘要：为了进一步解决多源空间数据集成问题,该文介绍了以往多源空间数据集成的几种方式,分析了目前国内外关于GML(Geog raphy Markup Language)数据集成进行的研究,并在此基础上提出了一个基于GML的多源空间数据应用集成框架,阐述了一种面向空间信息集成的GML模式匹配算法,并综合以上给出了总结。
关键词：多源空间数据,GML,集成
空间数据集成 篇2
一、多数据格式是多源空间数据集成的瓶颈
1、空间数据多源性的产生和表现
空间数据多源性的产生和表现主要可以概括为以下几个层次：
（1）多语义性
地理信息指的是地理系统中各种信息，由于地理系统的研究对象的多种类特点决定了地理信息的多语义性。对于同一个地理信息单元（feature），在现实世界中其几何特征是一致的，但是却对应着多种语义，如地理位置、海拔高度、气候、地貌、土壤等自然地理特征；同时也包括经济社会信息，如行政区界限、人口、产量等。一个GIS研究的决不会是一个孤立的地理语义，但不同系统解决问题的侧重点也有所不同，因而会存在语义分异问题。
（2）多时空性和多尺度
GIS数据具有很强的时空特性。一个GIS系统中的数据源既有同一时间不同空间的数据系列；也有同一空间不同时间序列的数据。不仅如此，GIS会根据系统需要而采用不同尺度对地理空间进行表达，不同的观察尺度具有不同的比例尺和不同的精度。GIS数据集成包括不同时空和不同尺度数据源的集成。
（3）获取手段多源性
获取地理空间的数据的方法有多种多样，包括来自现有系统、图表、遥感手段、GPS手段、统计调查、实地勘测等。这些不同手段获得的数据其存储格式及提取和处理手段都各不相同。
（4）存储格式多源性
GIS数据不仅表达空间实体（真实体或者虚拟实体）的位置和几何形状，同时也记录空间实体对应的属性，这就决定了GIS数据源包含有图形数据（又称空间数据）和属性数据两部分。图形数据又可以分为栅格格式和矢量格式两类。传统的GIS一般将属性数据放在关系数据库中，而将图形数据存放在专门的图形文件中。不同的GIS软件采取不同的文件存储格式。
2、多源空间数据集成的迫切性
随着Internet网络的飞速发展和普及，信息共享已经成为一种必然的要求。地理信息也不例外，随着信息技术以及GIS自身的发展，GIS已经从纯粹地学技术系统的圈子跳了出来，正和IT行业完全融合，人们对空间信息的需求也越来越多。GIS要进一步发展，必须完全融入大型MIS（管理信息系统）中。1998年美国副总统戈尔提出数字地球的概念，更是将地理信息技术推到了最前沿。然而地理信息要真正实现共享，必须解决地理信息数据多格式、多数据库集成等瓶颈问题。随着技术发展，GIS已经逐步走向完全以纯关系数据存储和管理空间数据的发展道路，这为GIS完全和MIS无缝集成迈出了重要的一步。但因为GIS处理的数据对象是空间对象，有很强的时空特性，获取数据的手段也复杂多样，这就形成多种格式的原始数据，再加上GIS应用系统很长一段时间处于以具体项目为中心孤立发展状态中，很多GIS软件都有自己的数据格式，这使得GIS的数据共享问题变得尤为突出。
空间数据作为数据类型的一种，同普通数据一样需要走过从分散到统一的过程。在计算机的发展过程中，先是数据去适应系统，每一个系统都为倾向于拥有自己的数据格式；随着数据量的增多，数据库系统应运而生；随着时代的发展，信息共享的需求越来越多，不同数据库之间的数据交换成了瓶颈；SQL（标准结构化查询语言）以及ODBC的出现为这一难题提供了比较满意的解决方案。但是空间数据如何引进这种思想，或者说将空间数据也纳进标准组织和标准协议进行规范和管理，从而使空间数据共享成为现实。
二、GIS多源数据集成模式比较
由于地理信息系统的图形数据格式各异，给信息共享带来了极大的不便，解决多格式数据源集成一直是近年来GIS应用系统开发中需要解决的重要问题。目前，实现多源数据集成的方式大致有三种，即：数据格式转换模式、数据互操作模式、直接数据访问模式。、数据格式转换模式
格式转换模式是传统GIS 数据集成方法（图1）。在这种模式下，其他数据格式经专门的数据转换程序进行格式转换后，复制到当前系统中的数据库或文件中。这是目前GIS系统数据集成的主要办法。目前得到公认的几种重要的空间数据格式有：ESRI公司的Arc/Info Coverage、ArcShape Files、E00格式；AutoDesk的DXF格式和DWG格式；MapInfo的MIF格式；Intergraph的dgn格式等等。数据转换模式主要存在的问题是：
（1）由于缺乏对空间对象统一的描述方法，从而使得不同数据格式描述空间对象时采用的数据模型不同，因而转换后不能完全准确表达源数据的信息。
（2）这种模式需要将数据统一起来，违背了数据分布和独立性的原则；如果数据来源是多个代理或企业单位，这种方法需要所有权的转让等问题。美国国家空间数据协会（NSDI）确定制定了统一的空间数据格式规范SDTS（Spatial Data Transformation Standard），包括几何坐标、投影、拓扑关系、属性数据、数据字典，也包括栅格格式和矢量格式等不同的空间数据格式的转换标准。许多软件利用SDTS提供了标准的空间数据交换格式。目前，ESRI在ARC/INFO中提供了SDTSIMPORT以及SDTSEXPORT模块，Intergraph公司在MGE产品系列中也支持SDTS矢量格式。SDTS在一定程度上解决了不同数据格式之间缺乏统一的空间对象描述基础的问题。但SDTS目前还很不完善，还不能完全概括空间对象的不同描述方法，并且还不能统一为各个层次以及从不同应用领域为空间数据转换提供统一的标准；并且SDTS没有为数据的集中和分布式处理提供解决方案，所有的数据仍需要经过格式转换复制到系统中，不能自动同步更新。、数据互操作模式
数据互操作模式是OpenGIS consortium(OGC)制定的规范。OGC是为了发展开放式地理数据系统、研究地学空间信息标准化以及处理方法的一个非盈利组织。GIS互操作是指在异构数据库和分布计算的情况下，GIS用户在相互理解的基础上，能透明地获取所需的信息。OGC为数据互操作制定了统一的规范，从而使得一个系统同时支持不同的空间数据格式成为可能。根据OGC颁布的规范，可以把提供数据源的软件称为数据服务器（Data Servers），把使用数据的软件称为数据客户（Data Clients），数据客户使用某种数据的过程就是发出数据请求，由数据服务器提供服务的过程，其最终目的是使数据客户能读取任意数据服务器提供的空间数据。OGC规范基于OMG的CORBA、Microsoft的OLE/COM以及SQL等，为实现不同平台间服务器和客户端之间数据请求和服务提供了统一的协议。OGC规范正得到OMG和ISO的承认，从而逐渐成为一种国际标准，将被越来越多的GIS软件以及研究者所接受和采纳。目前，还没有商业化GIS软件完全支持这一规范。数据互操作为多源数据集成提供了崭新的思路和规范。它将GIS带入了开放式的时代，从而为空间数据集中式管理和分布存储与共享提供了操作的依据。OGC标准将计算机软件领域的非空间数据处理标准成功地应用到空间数据上。但是OGC标准更多考虑到采用了OpenGIS协议的空间数据服务软件和空间数据客户软件，对于那些历史存在的大量非OpenGIS标准的空间数据格式的处理办法还缺乏标准的规范。而从目前来看，非OpenGIS标准的空间数据格式仍然占据已有数据的主体。
数据互操作规范为多源数据集成带来了新的模式，但这一模式在应用中存在一定局限性：首先，为真正实现各种格式数据之间的互操作，需要每个每种格式的宿主软件都按照着统一的规范实现数据访问接口，在一定时期内还不现实；其次，一个软
件访问其他软件的数据格式时是通过数据服务器实现的，这个数据服务器实际上就是被访问数据格式的宿主软件，也就是说，用户必须同时拥有这两个GIS软件，并且同时运行，才能完成数据互操作过程。
3、直接数据访问模式
顾名思义，直接数据访问指在一个GIS软件中实现对其他软件数据格式的直接访问，用户可以使用单个GIS软件存取多种数据格式。直接数据访问不仅避免了繁的数据转换，而且在一个GIS软件中访问某种软件的数据格式不要求用户拥有该数据格式的宿主软件，更不需要该软件运行。直接数据访问提供了一种更为经济实用的多源数据集成模式。
目前使用直接数据访问模式实现多源数据集成的GIS软件主要有两个，即： Intergraph 推出的GeoMedia系列软件和中国科学院地理信息产业发展中心研制的SuperMap。GeoMedia实现了对大多数GIS/CAD软件数据格式的直接访问，包括：MGE、Arc/Info、Frame、Oracle Spatial、SQL Server、Access MDB等(图2)。SuperMap 2.0则提供了存取SQL Server、Oracle Spatial、ESRI SDE、Access MDB、SuperMap SDB文件等的能力，在以后的版本中将逐步支持对Arc/Info Coverage、AutoCAD DWG、MicroStation DGN、ArcView等数据格式的直接访问。
三、多源空间数据格式集成的展望、文件方式和数据库方式
传统的空间数据往往采用文件方式，随着技术的进步，逐渐将属性数据移植到数据库平台上；随着技术发展，图形数据也可以和属性数据一起存放在关系数据库中。文件方式对数据管理安全性较差，存在着属性和图形分开管理的问题，不适合网络共享发展的需要；数据库方式则实现了空间数据和属性数据一体化存储和管理，便于开发两层、三层甚至多层网络应用系统。从发展趋势来看，纯关系数据库方案取代文件方案是发展的必然趋势，这也是IT发展的主流趋势。随着对信息量需求的增大以及信息需求种类增多，数据仓库的建立，将是GIS文件系统向数据库系统发展的主流。、OpenGIS、SDTS与DLG/F
OpenGIS是目前的主流标准，但SDTS并不会停滞不前，相反笔者认为SDTS将会与OpenGIS走向一体化。SDTS 可以为OpenGIS提供一个转换和存取空间数据的标准，该标准是不依赖任何一种特定GIS软件格式的，该标准中利用头文件描述格式的方式使得数据服务者不必专门提供格式说明，而数据客户也不必专门学习该格式，只需读取SDTS头文件就可获得数据服务者提供的数据格式。笔者认为利用SDTS做数据标准，利用OGC作数据互操作的标准（例如空间SQL标准），简单地说就是如果说SDTS提供了数据格式的头文件，而OGC标准则提供了读写这个头文件的标准方法。如果再采用数据库作后台，利用空间数据引擎，空间数据引擎按照SDTS存取空间数据，按照OGC标准对客户软件提供操作接口，这将是空间数据集成的理想解决方案。USGS还提供了一种称作DLG/F的标准，该标准设计了空间数据在数据库中的动态存储结构，利用该结构可以将拓扑关系动态记录下来，同时可以让用户添加自定义的空间数据类型。怎样利用DLG/F完善SDTS和OpenGIS也将是OpenGIS以及SDTS发展的方向。、统一空间实体编码
多源空间数据据格式集成还有一个很重要的方面就是如何处理不同数据库对空间实体采用的编码方式不同的问题。从理论上来说，一个系统对同一空间实体的编码应该是唯一的，实际上由于不同领域从不同视角对同一空间实体编码并不一样，甚至会出现不同空间实体具有相同编码的情况，这些编码放在同一系统中，就会出现空间实体标识的严重问题。从目前来看，OpenGIS和SDTS都是基于地理特征（Feature）定义空间实体的，但都还不能真正提供一个通用的空间实体编码体系。
参考文献
１.On spatial database integration, Thomas Devogele ,Geographical Information Science, 1998,12(4)
２.Issues and prospects for the next generation of the spatial data transfer standard(SDTS), DAVID ARCTUR, DAVID HAIR,GEORGE TIMSON, etc, Geographical Information Science, 1998,12(4)
３.Towards integrated geographic information processing，DAVID J.ABEL, BENG CHIN COOI, KIAN-LEE TAN etc, Geographical Information Science, 1998,12(4)
４.A framework for the integration of geographical information systems and modelbase management , DAVID A.BENNETT, Geographical Information Science, 1997,11(4)
大数据呼唤数据集成新思维 篇3
大数据意味着包括交易和交互数据集在内的所有数据集，其规模或复杂程度超出了常用技术按照合理的成本和时限捕捉、管理及处理这些数据集的能力。不管是大交互数据，还是大交易数据，处理分析非结构化数据一直以来都是数据处理的难点。数据集成作为挖掘数据价值的重要一步在整个数据分析中具有重要的作用。
对于绝大多数企业而言，信息系统建设通常具有阶段性和分布性的特点，该特点不可避免的导致了“信息孤岛”现象的存在。“信息孤岛”就是指不同软件间，尤其是不同部门间的数据信息不能共享，造成系统中存在大量冗余数据、垃圾数据，无法保证数据的一致性，严重地阻碍了企业信息化建设的整体进程。为解决这一问题，人们开始关注数据集成研究。
数据集成就是将若干个分散数据源中的数据，逻辑地或者物理地集成到一个统一的数据集合中。其核心任务是将相互关联的分布式异构数据源集成到一起，让用户以透明的方式访问这些数据源，以便消除信息孤岛现象。
数据集成市场正处于黄金时代
著名信息技术研究咨询公司Gartner在其发布的“2013年数据集成工具魔力象限报告”中表示，对集成选项功能完整性的需求在快速上涨。随着数据碎片化程度的不断加剧，企业希望能够有一款灵活的产品，能够快速融入到现有的数据管理投资中，并提供更多的功能。
数据集成可以满足人们不断增长的信息需求，使更多的人更充分地使用已有数据资源，减少资料收集、数据采集等重复劳动和相应费用，实现数据源的凝聚放大效应，形成以业务为驱动的动态数据价值链。
大数据技术的发展为数据管理开辟了一条新的道路，这也为数据集成创造了新的机会。在这种情况下，数据集成就从传统的数据提取、转换和加载过程（ETL）变成了更加灵活的数据提取、加载和转换的方法（ELT）。在过去，ETL形式中的数据集成通常是“一个自包含过程”，它只是简单的专注于将干净、合并的数据从源系统迁移至目标数据仓库。但是，现在情况变得不同了，现在数据可以存在于任何地方，如果用户需要在另一个系统上使用，只要在需要的时候调用就可以了。
Gartner认为，市场上对集数据集成、数据质量以及主数据管理于一体的工具需求在不断的增长。高质量的数据对于数据集成项目的成功具有关键的作用，而不关心数据质量的数据集成注定将会失败。除了与数据质量和主数据管理更好的集成以外，用户还希望工具能够支持更加广泛的数据集成风格与功能。
包括Hadoop等大数据技术，以及NoSQL数据库技术在内的技术对数据集成工具的开发都产生了重大影响。未来数据集成工具发展的重要方向就是支持分布式架构的集成。包括低成本，基于订阅模式的收费方法以及基于云在内的交付模式，也是未来数据集成市场的一个发展方向。
多方挑战考验数据集成
单纯地看，数据集成在现实应用中是一个非常简单的问题，也就是对多源数据进行清理和转换，然后将数据加载到适当的数据存储区中以便进行下一步的分析和处理。但是，事实却不是这么简单。数据集成面临着多方挑战。
首先是技术方面的挑战。最具针对性的挑战包括：多种源和多种不同的格式；结构化、半结构化和非结构化数据；在不同时间从源系统获得的数据信息；庞大的数据量。即使在理想的情况下，也必须以某种方式在一个位置获得所需的所有数据。同时，对实时性的要求增加了数据集成的困难。
其次来自组织的挑战。在大型组织中进行数据集成还会存在来自权力的压力。数据是信息，代表着一种权力，但是让人们相信数据是企业有价值的资产是一件颇具挑战的事情。要实现企业数据集成的成功，就需要所有数据源的使用者能够了解项目的用途和方向。这需要所有的组织成员能够通力合作。
最后就是经济压力。数据集成成本的增加主要是因为数据集成的过程可能会因为权力而变得缓慢而曲折，清理数据以及从多种源数据映射也会变得更加困难。当需要解决这些问题的时候，数据集成引起的额外费用都将会被记入整个数据集成体系结构。另外，随着组织发展过程中对数据入库和商业智能需求的增加，有缺陷的数据集成体系结构将变得越来越难以维护，这样总体拥有成本会增加。
虚拟化提高数据集成效率
虚拟化意味着可以不受物理条件的限制，能够迅速构建物理环境，以便支持用户在特定时刻对特定业务的需求。现在已经可以实现对服务器、存储以及网络实现虚拟化。
面对海量数据的处理需求，我们需要摆脱结构化的数据仓库。低成本的存储在业务数据存储方面可以节省成本。高昂的存储成本限制了系统处理数据的质量。对于海量数据的处理需要做到弹性存储，弹性存储意味着企业不会在期望操作的数据规模或类型上受到限制，从而可以降低使用数据仓库无法获得最佳结果的风险。
数据虚拟化可以将不同的数据连接起来，让业务运营与数据集成流程变得更加灵敏。大多数情况下，企业主要运用传统数据集成技术，从交易系统中获取数据，将其移植到数据仓库中以作商务智能和数据分析等用途。然后，对于需要实时决策的应用程序，这种方式就会面临挑战。
数据虚拟化拥有一个可置于企业应用程序、数据仓库、交易数据库、门户网站及其他数据源之上的提取层，能使企业在无需创建存储信息备份的环境下，对来自不同系统中的数据进行整合。这样一来就省去了从源系统中复制数据或移除数据的麻烦，减少了IT人员的工作量，也降低了数据出错的几率。
数据虚拟化还支持在源系统中交易数据更新的写入，这也是拥护者们看中这项技术的优势之一。正因为如此，数据虚拟化才会从数据联合与企业信息集成（EII）技术中脱颖而出。后两项为更早推出的类似技术，同样为了简化不同源阵列的数据分析流程。尽管三种技术在性能方面都有相似之处，甚至有“换汤不换药”之嫌，但是EII技术提供的是一种数据阵列与报表的只读处理方法。
其实，早在十年前就有数据联合了，其产生的用意本在于取代ETL工具和数据暂存区，不用再建立新的数据市场。可惜评论家认为数据联合从一开始就带有重大缺陷，它只能与巨型数据套件匹配，且其运行环境需要极为复杂的数据转换。更有甚者，很多人都认为数据联合与面向服务架构（SOA）的粘附性很强。
但是随着企业不再将大数据分析作为一项孤立的应用来看待，并注意使用分析结果来驱动他们的主流业务流程，数据质量和无缝上游整合就变得更为重要。并且大数据架构灵活性的提升也带来了更高级别的发展和管理复杂性，这可能需要新的流程和技巧，甚至是在IT部门中的一场文化变革。
空间数据集成 篇4
房产测绘是获取房产管理数据的主要手段, 是数字房产中空间数据和属性数据的重要来源。如果没有房产测绘的一体化集成应用, 其他集成都成了无根之草、无水之木。研究房产测绘与房产GIS的一体化集成技术, 对于解决数字房产空间数据库数据的快速获取、更新, 保证房产业务的正常进行具有重要的现实意义。本文提出了基于GIS实现房产测绘与房产GIS一体化集成的技术路线和总体框架。
1 引言
房产测绘的发展经历了从手工模式—CAD模式—CAD和GIS混合模式三个阶段, 目前正向测绘与房产GIS一体化集成阶段发展。
在手工模式阶段, 房产测绘的外业测量和内业处理都是依靠手工来完成的, 提供成果的主要形式是纸质的图形和表格。此时的房产信息化的发展还处于单机单用户的MIS阶段, 房产测绘在信息系统中的集成主要是通过手工方式将属性信息录入MIS系统, 图形成果的利用也只限于发证时将纸质图形粘贴到证书上作为证书的附页。
随着电子测量技术和CAD技术的发展, 房产测绘逐步由全手工模式进入CAD模式。外业测绘可以通过电子测量仪器 (如全站仪、GPS等) 快速获取测量数据, 同时基于CAD技术开发的房产测绘系统利用CAD软件的绘图、编辑、制图功能快速地生成房产测绘成果。
在手工模式和CAD模式的阶段, 房产测绘主要还是以制图为目的的。随着GIS技术在房产信息化建设中的应用, 人们迫切希望房产测绘系统在满足制图的前提下, 能够发挥其向信息系统提供信息的功能。特别是GIS技术应用后, 基于图形进行房产处理的模式 (以图管房) 在信息系统中占据主导地位, 房产测绘作为GIS图形数据和属性数据的重要来源, 如何J决速地实现房产测绘与信息系统的集成成为人们研究的重点, 此时房产测绘开始进入CAD+GIS混合模式阶段。在这一阶段, 基于CAD技术的房产测绘仍是主流, 可以采用实体编码技术和外挂数据库技术对原有基于CAD系统开发的房产测绘系统进行改造, 以满足向信息系统和GIS提供信息的需求。目前房产信息化的快速发展特别是数字房产的提出, 迫切需要研究房产测绘与信息系统的一体化集成的相关问题。
2 房产测绘空间数据与属性数据集成的内涵
房产测绘与信息系统一体化集成不同于CAD和GIS混合模合下通过文件交换的数据共享, 它是一种更高层次上的集成。一体化集成应包含两个层次的集成:一是房产测绘信息采集的集成;二是测绘数据与GIS数据的集成。房产测绘信息采集的集成是图形信息和属性信息的集成, 即房产测绘中图形数据和属性数据的一体化存储和采集。图形信息和属性信息的一体化存储是GIS有别于CAD系统的一个基本特征。基于CAD模式的房产测绘系统虽然解决了在计算机中快速绘图、编辑和输出的问题, 但由于CAD数据结构的限制, 图形数据和属性数据相互查询能力弱, 图形数据和属性数据的一致性维护比较困难。现有的基于CAD管理图形和外挂数据库管理属性数据的数据组织方式应向图形数据和属性数据一体化的组织方式转变。
测绘数据与房产GIS的集成是集成的最高层次。当前空间数据库技术在GIS应用系统中得到了广泛的应用, 房产测绘的最终目的就是要为房产空间数据库提供一体化的图属数据并对这些数据进行有效的更新。因此, 从这个意义上讲, 也可以把这个集成理解为房产测绘与空间数据库的集成。集成后的效果应是房产外业测绘、内业处理、成果检查、数据入库、数据更新、数据应用的流水化和程序化, 数据入库实现信息不需要二次手工处理、入库前后信息不损失。
3 基于GIS的空间数据与属性数据集成的优越性
一体化集成的房产测绘系统可以解决传统的测绘图形信息采集与属性采集分头进行而存在的关联性差、数据一致性难以维护等不足之处, 避免了数据进入信息系统所需的二次加工和处理, 提高了数据进入信息系统的效率和准确率, 可以大大缩短数据采集的周期。
一体化集成的房产测绘系统直接面向数字房产GIS需求进行数据采集, 直接生成符合GIS要求的房产测绘数据, 避免了传统测绘的CAD数据格式与GIS格式之间繁琐的转换, 可直接将数据写入信息系统GIS空间数据库, 并提供了直接基于空间数据库进行数据更新的能力, 这是传统的房产测绘系统难以实现的。一体化集成的测绘系统所具有的数据快速入库和高效更新的能力正是数字房产系统所迫切需要的。
4 基于COM GIS的测绘信息系统技术路线
基于对房产测绘信息系统的一体化集成内涵的分析, 本文研究提出了以GIS为核心的总体技术路线, 即以下几点。
(1) 采用GIS数据存储方式来存储房产测绘数据, 实现房产图形信息和房产属性信息的一体化存储; (2) 基于组件式GIS平台进行二次开发编辑和绘图功能, 实现房产图形的编辑绘制和属性信息的录入; (3) 采用空间数据库技术实现房产测绘与信息系统的数据入库与更新。
房产测绘任务分为房产基础测绘和房产项目测绘。房产基础测绘的主要内容是房产分幅平面图。房产项口测绘的主要内容是房产分丘平面图、分户平面图和房屋共有面积分摊计算。为了达到房产测绘与信息系统一体化集成的日标, 必须开发房产测绘管理系统, 以完成房产测绘成果向数字房产空间数据库的入库和更新。房产编辑绘图模块、测绘仪器联接模块和数据转换模块和参数定义模块是四个子系统的公共功能模块, 在实际编程实现中, 这四个公共功能模块实际上构成了一个具有基本测绘功能的程序框架, 在框架基础之上增加房产测绘分摊计算功能和房产测绘成果输出功能构成房产项目测绘子系统, 增加基础测绘成果输出模块构成房产基础测绘子系统, 增加测绘成果备案和成果入库功能构成房产测绘成果管理子系统。
整个系统基于组件式GIS技术来开发, 技术路线如图1所示。
系统基于组件式GIS开发平台进行功能扩充, 开发房产基础测绘系统和项目测绘系统。测绘人员测绘完毕后直接生成文件型的GIS数据格式。测绘管理人员在对测绘成果进行质量检核后, 将测绘成果入库。系统可利用空间数据库引擎将该GIS数据格式直接写入到空间数据库中, 完成数据的入库。在数据需要更新时, 再通过空间数据库引擎将选定范围内的空间数据提取成文件型的GIS数据格式再由测绘人员实施修补测。修补测完毕后, 再将成果更新入库。在系统中, 成果入库完毕后, 图形数据的更新只能由测绘和测绘管理人员来共同完成, 房产管理的业务人员只能进行读取和显示, 这样。可有效地保证房产测绘成果的权威性。
5 房产测绘信息系统总体架构
在大连市数字房产的开发中, 根据大连市房产状况, 总体结构设计如图2所示。
老数据转换子系统完成对原始测绘成果 (分幅平面图、分层分户图) 空间数据和属性数据的入库。
对新开发的房产测绘项目和需补测的房产测绘项目采用基于GIS的一体化集成的房产测绘系统, 外业采集采用基础测绘子系统, 内业分摊计算、成果输出打印等采用项目测绘子系统, 成果更新入库采用测绘成果入库子系统。
一体化集成的房产测绘系统在吉林市数字房产管理中的应用取得了很好的效果, 实现了房产图形信息和房产属性信息的一体化存储, 实现了房产测绘对空间数据库的快速入库与更新, 大大提高了数据采集更新的速度, 保证了空间数据库的现势性和权威性, 保证了房产业务的正常运行。
摘要：本文基于笔者多年从事房产测绘的相关工作经验, 以房产测绘空间数据与属性数据通过GIS手段集成为研究对象, 探讨了房产测绘空间数据与属性数据集成的内涵和优越性, 分析了基于COM GIS的测绘信息系统构建技术思路, 给出了房产测绘信息系统的总体架构, 全文是笔者长期工作实践基础上的理论升华, 相信对从事相关工作的同行有着重要的参考价值和借鉴意义。
空间数据集成 篇5
关键词：元数据；数据集成；中间件；元数据字典
中图分类号：TP311文献标识码：A文章编号：1009-3044(2007)15-30609-02
Design and Realization of Metadata Management in Database Integration Middleware System
JIANG Wei-wei, ZHAO Zhen-nan
(Engineering Institute of Engineering Corps，PLA University of Sci. & Tech.，Nanjing 210007, China)
Abstract:This paper introduce the concept of metadata and analysis the needs of heterogeneous data sources integration then puts forward the necessity of using metadata in Database Integration Middleware System, Set forth the design and realization process of metadata management.
Key words:metadata; data Integration; middleware; metadata dictionary
1 数据集成的相关概念
随着信息化建设发展，各类企业数据标准也在完善，而在各类旧系统多年的使用中，数据库中积累了大量的宝贵数据。因此，我们将面临着如何将原有的各类已趋于成熟的数据库系统纳入到新系统中的问题。如何有效地利用旧系统中存储的大量的宝贵数据和实现各个子系统之间数据的透明访问，成为我们开发数据集成系统必须解决的重要课题。
数据集成是为各种异构数据提供统一的表示、存储和管理，屏蔽各种异构数据间的差异，为用户提供一个访问异构数据源的统一接口，使用户不必考虑数据模型异构、数据抽取以及数据合成等问题。典型的数据集成技术有：
联邦数据库：是最简单的一种异构数据库集成方式，各个数据源是相互独立的，通过数据源之间的数据交换格式进行一一映射，这种方法的优点是容易实现，尤其是在集成的数据源种类和个数限定的情况下，缺点则是工作量极大，扩展性差，如果有n个异构数据源需要互连，那么我们就要去构造n*(n-1)个映射程序来支持这n个异构数据源之间的互相访问。
数据仓库集成异构数据源的策略是将来自几个异构数据源的数据副本，按照一个集中、统一的视图要求，进行预处理、转换，以符合数据仓库的模式，并存储到数据仓库中。数据仓库模式的异构数据库数据共享集成的优点是便于进行联机分析和数据挖掘，缺点是数据重复存储、难以及时更新。
中间件模式（Mediator/Wrapper模式）通过统一的全局数据模型来访问异构的数据库、遗留系统、Web资源等，如图1所示。中间件位于异构数据源系统(数据层)和应用程序(应用层)之间，向下协调各数据源系统，向上为访问集成数据的应用提供统一数据模式和数据访问的通用接口。各数据源的应用仍然完成它们的任务，中间件系统则主要为异构数据源提供一个高层次检索服务。
图1 中间件集成模式
如果系统已经按照用户的要求建立了各种数据，但是用户却没有办法知道这些数据代表了什么，如何表示才是符合要求的，它们从哪里来，经过了怎样的变换等等，将会增加用户使用系统的难度。元数据实现了业务模型到数据模型的映射，把数据以用户需要的方式“翻译”过来，从而帮助用户理解和使用数据。数据集成系统中的底层数据对用户来说是“不透明”的，用户很自然会对集成结果产生怀疑。元数据记录了数据的来源和目标，记录了转换的规则，从而使得最终用户能够很容易的了解数据产生的全过程，这对于最终用户发现数据中存在的质量问题是非常有帮助的，从而增加数据可信度，减少数据仓库中蜘蛛网现象所造成的不利影响。中间件模式中的元数据管理作为各异构数据源的“翻译”和“协调者”，考虑到最终用户的非专业性，向中间层提供了一个源数据的“介绍”和获取方式，这既避免了数据源间的直接接触又避免了对源数据的复制，简化了数据的管理过程。
2 元数据
元数据(Metadata)：“关于数据的数据”，为各层次信息内容提供规范的定义、标记、解析和利用机制。元数据的精神应该是用尽可能少而精的数据反映对象尽可能多而全的信息。
元数据的产生源于网络信息资源的快速增长，信息资源的组织与利用出现了巨大的困难，传统的信息组织方法不仅在数据加工和数据标引上费时费力，而且需要大量经过特殊培训的专业人员来操作。同时由于网络环境下的一些其他问题，如内容加密、资源庞大或资源收费等，造成资源不能被每个人直接使用，人们无法看到电子文档的实际内容。因而不可能使用传统的信息管理方法组织网上的信息。元数据是一个有效的解决方案。基于元数据的信息组织主要用于实现两个功能：一是较为准确地描述信息资源的原始数据或主题内容；二是能够实现网络信息资源的发现，即实现计算机网络定位、自动辨析、分解、提取等功能，将网络信息资源的无序状态变为有序状态。
在数据集成中间件中，元数据包含数据从哪里来，什么时间传输和传输到哪里去的一系列信息，提供给数据管理者一种追踪数据的方法。元数据被存储到服务器端，被数据库或XML文档管理，可以方便的展现给数据管理者。
3 元数据管理策略
从元数据的发展历史不难看出，元数据管理主要有两种方法：
(1)对于相对简单的环境，按照通用的元数据管理标准建立一个集中式的元数据知识库。
(2)对于比较复杂的环境，分别建立各部分的元数据管理系统，形成分布式元数据知识库，然后，通过建立标准的元数据交换格式，实现元数据的集成管理。元数据管理策略通常都包含一些基本特征：
(1)一个元数据的全局安全策略；
(2)对所有元数据源和目标以及元数据元素的确认机制；
(3)对每个元数据元素语义的一致理解；
(4)每个元数据元素的所有权；
(5)共享、修改和重新发布元数据元素的规则；
(6)元数据元素的重用目标。
4 元数据管理的实现
数据集成中间件中的元数据管理的主要任务有两个方面：一是负责存储和维护元数据库中的元数据；二是负责数据集成中间件中检索工具、数据访问接口模块、接收查询结果模块等之间的消息传递，协调各模块和工具之间的工作。本文元数据管理系统的实现过程有如下步骤：
(1)分析数据源，确定元数据映射范围；
(2)从实际系统中抽象元数据描述，加入语义层的对应，存人一个数据库中。本文采用一般的关系型数据库；
(3)确定元数据管理范围；
(4)确定元数据管理的工具。
举一个简单的例子，现有两数据库如图2所示：
图2 异构数据库示例
根据对数据源的分析，由于他们都表示了一个共同的关于企业编制的信息，因此元数据字典中可以抽象出一个全局的类“企业编制”，代表公有的领域概念。并分别用企业名称，企业编号，企业标识，企业地址，编制人数，实有人数等几个全局概念来表示“企业编制”类的属性。
本文使用元数据字典表示：各局部数据库的模式信息、集成系统的全局视图信息以及异构模式间的转换规则等。它是整个系统解决语义异构问题的核心，可确定来自不同数据库的相关数据，并将相关数据整合在全局视图上。
元数据字典通过精确表达领域内使用的公有概念以及概念的属性和它们之间的关系，能够对用户屏蔽这些异构数据的不同，使得用户的查询只根据这个元数据视图的概念进行描述。这个元数据字典描述文件如下所示。
＜?xml version="1.0" encoding="UTF-8" standalone="no"?＞
＜metadata＞
＜class name="企业编制" description=""＞
＜object name="企业A编制" id="001001" address="D1" database="sqlserver" table="bdbzwj" key="企业编号"/＞
＜property name="企业编号" type="varchar" length="10" precision="50"/＞
＜property name="企业名称" type=" varchar " length="50" precision="50"/＞
＜property name="企业标识" type="varchar" length="10" precision="10"/＞
……
＜property name="企业驻地" type="varchar" length="50" precision="50"/＞
＜property name="编制人数" type="int" length="4" precision="10"/＞
＜property name="实有人数" type="int" length="4" precision="10"/＞
＜/object＞
＜object name="企业B编制" id="001002" address="D1" database="oracle" table="bdbzmj" key="企业编号"＞
＜property name="企业编号" type="varchar" length="10" precision="50"/＞
＜property name="企业名称" type=" varchar " length="50" precision="50"/＞
＜property name="企业标识" type="varchar" length="10" precision="10"/＞
……
＜property name="企业驻地" type="varchar" length="50" precision="50"/＞
＜property name="编制人数" type="int" length="4" precision="10"/＞
＜property name="实有人数" type="int" length="4" precision="10"/＞
＜/object＞
＜/class＞
＜/metadata＞
元数据的建立，一方面，采用XML进行描述、保存与交换，保证了系统的开放性与灵活性；另一方面，采用数据库表实现基于内容与集成的检索服务，保证了系统面对大容量的数据依然能够保证优秀的查准率、查全率和快速响应，数据客户端发送来查询字符串提供给服务端的功能模块解析，解析时需要查询元数据信息。因此把元数据信息从XML文档转换并导入到数据库中。本文用SQLServer 2000来存储元数据数据库。关系数据库中建立的对象表和属性表，如图3所示：
图3 元数据数据库
对元数据数据库的管理：建立友好的用户界面，用户无需了解元数据在数据库中的具体结构就能完成元数据维护工作。本文以树控件显示元数据机构，实现了元数据的添加、修改、删除，元数据数据表的维护等操作。
5 结束语
元数据是数据之数据，因此方便用户对资源的发现和辨识，大大提高了资源被利用程度，元数据的应用领域越来越广泛和深人，元数据的格式也进一步多元化，体系更加复杂，功能更加完善，元数据格式的标准化和格式之间的整合、可互操作将是一个严峻的问题。
参考文献：
[1] Maraco Bellinaso，等. C#入门经典[M]. 清华大学出版社，2002.
[2] 刘强. 基于中间件技术的异构数据集成[M]. 郑州：河南大学, 2003.5.
[3] 王真. 数据仓库中的元数据管理[M]. 福建教育学院学报, 2004.4.
空间数据集成 篇6
目前,石油行业在生产过程中所产生的数据种类繁多,并且在可实施方案的设计中对数据有很大依赖性。在企业决策过程中要求掌握大量现实性强、真实准确的以空间信息为基础的综合性信息,并要求随时对数据快速查询、综合分析。单纯的数据报表展示方式枯燥冗长,并不利于数据有效利用,所以将数据库中可辅助决策的数据项作为单个图元元素表示,大量的数据集构成集成的数据图像,同时将数据的各个属性值以多维数据的形式表示,可以从不同的维度观察数据,从而对数据进行更深入的观察和分析[1]。使人们不再局限于通过关系数据表来观察和分析数据信息,还能以更直观的方式看到数据及其结构关系。
目前,在空间数据集成中GIS的应用占有着重要的地位,GIS以其良好的直观性和交互性以及有效合理的空间数据组织为用户提供了获取地学及相关信息的便利手段,但现今的GIS软件的数据模型都是非时态的,难以处理复杂多变的动态数据,并且构建GIS开销较大,相应速度较慢。难以提供实质性的解决方案,对辅助决策不能提供良好的支持[2]。为此采用SVG矢量图解决空间数据的集成问题,具有系统轻便、简单、传输速度快、交互强等特点,并可对变化的数据实时相应,克服了传统GIS的缺点。
油田决策支持系统的基石是各类海量信息,这些信息包括空间地理信息,也包括大量与空间信息密不可分的属性信息。通过SVG技术可直观形象的管理和查询这些信息。通过构建灵活的图形结构以及图层,集成管理大量的多专题的空间与属性数据,将开采信息、油水井措施、产液剖面、注入剖面等属性信息与油水井地理空间位置、层段地貌特征相连,以组成完整的决策信息模型[3]。利用数值模型计算与数据挖掘技术结合,使计算的结果能更形象直观的表达,从而得出隐含的重要结论,这对于石油生产领域是至关重要的。
1基于SVG辅助决策模型架构
在空间数据集成中,大体上数据分为地理空间数据和领域属性数据两类[4]。由于油田数据组织复杂、多变、关联关系较为密切,并分布在不同的关系数据实体中,这给空间数据集成造成了一定的困难。针对以上问题,设计基于SVG辅助决策模型架构(图1),将可支持辅助决策的空间数据提取,组成完整的数据中间件,并进一步通过解释器将中间件转换为可识别的图像。模型架构分为空间数据实体、基础图形部件和显示部件三部分。
1.1 空间数据实体
空间数据实体是模型的基础,它提供了基本的数据支持,是辅助决策的根据,从大类上划分为两部分。其一为表示空间实体的位置、形状、大小、地貌特征及其分布特征诸多方面信息的空间数据,在此称为地理空间数据类;其二为描述空间实体的属性的数据,如油田中油水井的产液、含水、措施、方案等。
另外,在实际生产中,基于以上两类关系密切的数据类,针对实际生产过程,需要利用已有数据计算模型或数据挖掘方法将产生一类分析结果数据,如剩余油分布情况、采收率评估、单元统计数据等,这类数据虽然是独立存在的但是对于决策的制定提供了强大的支持,同时将此类数据反映到可视化的图形上具有着重要的意义。
1.2 基础图形部件
在实体数据到SVG图形显示过程中,单一关系数据不能充分的表达实际的图形模型,对应一种图形可能由多种关系数据实体组成的。所以需要将原有的数据抽取后重新组织,得到完整、灵活、可解释的基础图形部件。
基础图形部件的作用在于形成物理上分布而逻辑上集中的整体数据视图。从实用角度出发,建立图形部件中间件是一种行之有效的空间数据集成方法。针对地理信息的特点,参考石油领域开发规范,对每一个可提供决策支持的数据创建图形对应关系,使每个分布式关系数据节点形成一个与具体空间数据集相对应图层。根据分布式数据库系统场地自治的原则,各节点负责维护本地数据库与抽取数据项目的一致性。由基础图形部件保存相应原关系数据副本,并维持信息的交换。
建立基础图形部件层不但可是信心有效的集成,并具有较强的扩充能了,如果基础数据变化,则对应修改相应的部件或增加新的图形部件即可将问题解决,而不用将时间花费在数据与显示的对应关系上。
1.3 显示部件
显示部件主要对基础图形部件进行合理的解释以及对应SVG文件格式进行转换并显示。
对于一些关键应用尤其是一些有实时性要求的应用,用户对系统的响应速度要求较高。而对于一些交互性较强的功能,如果系统构造方式比较松散,模块内部的内聚性不强,不利于模块功能的维护。为此,SVG本身的优点,如可扩充性、动态性、强交互性、网络传输速度快等很好的解决了以上问题。
在显示部件中,利用SVG技术主要应用在以下几个方面[5]。
(1) 首先,SVG提供了丰富的图形对象,可以有效的表现空间信息。SVG提供了一下基本图形元素:直线(<line>)、圆(<circle>)、图标(<symbol>)、文字(<text>)、图像(<image>)等。这些图形对象可对油田领域中井、层、地质、采出信息等基础图形做出完整的描述。
(2) 其次,SVG提供了丰富的消息触发及事件响应函数以获取用户消息。同样,SVG也提供丰富的状态事件,如数据装载完毕,就可以触发Onload事件,作一些初始化的处理。通过SVG提供的消息触发及事件相应函数,能够很容易地实现与图像的交互及控制,如图像的放大、缩小、漫游、查询、图层的控制等操作,这些在生产分析中是必不可少的。
(3) 再次,由于SVG是基于XML格式的,因此除了内置的属性外,可以对其属性进行任意扩充,以实现自定义的功能。在SVG图形中,对象的属性ID是用来惟一标识对象的编号,可以通过SVG文档对象的getElementById()方法来获取指定的对象。属性的获取或赋值是通过调用getAttribute及set-Attribute方法。
(4) SVG支持图像的分层管理。对于实际应用,油田数据的复杂多变,并且信息量庞大,将所有信息同时以图形的形式展示较为混乱,再者不同工作人员关心的数据项目也不尽相同。SVG采用基于XML的DOM文档管理结构,很方便实现图层管理,其组<g>对象就可以将其下面的所有图形管理起来。节点中的childNodes属性可以获取所有的子节点的集合,getElementsByTagName()方法可以获取某种类型对象的列表。通过采用组对象来实现图层管理功能,不同图层的对象包含在不同的组中。通过设置组的属性,就可以实现如可见性、颜色、透明度等设置以及选中、删除所有对象等操作。
2 油田辅助决策数据的组织和提取
数据组织问题实际上是构建应用系统的重要问题,在系统设计之前,全面而深人地分析数据是必不可少的环节,同时要考虑到当前已存在的数据源和由其衍生的中间数据或统计数据。根据石油行业空间数据的特征,可以把空间数据归纳为3类。
2.1 属性数据
描述空间数据属性特征的数据;包括井(采出井、注入井、探测井等)、各类措施方案(压裂、补孔、堵水、酸化、增注方案等)、开采信息(日产液、日产油、含水率、沉没度、注水量油压等)、产液剖面、剩余油分析结果等,以及与之相关的各类专业属性数据。这类点数据属于关系数据实体,有通用的模型规范(A2数据模型、开发数据库逻辑模型),具有较强的关联,所以可以直接采用关系数据提取方法,通过井ID信息做为主键提取并形成对应图形部件。
2.2 地理数据
描述空间数据空间位置和特征的数据;地理类矢量数据包括:井位坐标、层段构造、层段连通关系解释、区域地质构造图、断层分布图和各类等值图等。地理类的矢量数据采用针对空间和类别两种方法分别组织提取,即在同一平面空间分别组织各专题数据,在每类专题图幅中以图层为单位来组织管理图元数据。采用这种组织方式,系统易于针对地图数据库管理的特殊性,易于实现对跨图幅图元进行整体查询和归并检索输出,同时保证系统的快速高效性能。
各类地理数据除特殊数据项外,同时包含基础数据项目为:{项目名称、井区、层段信息、区域范围、数据描述、数据信息}。
项目名称:图像名称,用以区分各类不同图幅;
井区:以区块为单位,描述图幅的归属;
层段信息:层段信息包含油层组、小层号和细分层号,说明图幅所代表的地理深度。
区域范围:以经纬度为基础,说描述图幅跨度的区域范围。
数据描述:对数据的描述,说明数据的可用性以及完整性或数据项目和其他属性数据的关联关系。
数据关联信息:根据图幅类型的不同,数据信息表达方式也不同,多数情况建立子表或数据流文件。例如剩余油等值线则指向对应的流文件,层段构造信息则指向新建子表,在子表中具体描述数据的类型以及数据组织方法。
地理类数据需建立新的关系数据实体,并和原有数据源相关联来保证数据的一致性。
2.3 计算结果类数据
在原有的石油领域软件中,根据数模计算或数据挖掘方法会产生一部分结果类数据文件,主要以文档形式和图幅文件形式存储。如各类已有的各种工程勘察报告、含油饱和度计算结果、开采曲线等。它们多是以一个整体位对象,采用二进制形式存储于数据库中,并采用外挂属性的形式与相关的其它属性数据相关联。利用SVG可交互的特点,调入对应的数据文件。
3 图形部件的设计与解释
SVG中是以基本的图形元素构成的,在生产中单一的图形文件不足以表达实际的图形模型,所以将多种SVG图形元素组合,形成完整的展示形式。这就要求各个图形元素中的属性要建立与关系数据的对应关系,图形元素的数量决定了构成完整信息的难易程度,在此构建一种完整的中间文件,用以更好的完成信息的集成以及增强系统的扩充能力。
图形部件选用XML文件格式,利用XML扩展性、灵活性、结构性更好的建立中间数据文件,XML定义结构形式化描述如下。
在上述结构中,对于由多图形元素构成的图像分别图像名称做以区分。图层控制表示图像所属的不同层次,并对需要提取的空间数据字段建立与关系数据的对应关系,值类型的利用类样式控制。在空间数据赋值时,出于效率考虑,将涉及数据同时提取到数据集中后再分别处理。
使用图形部件层,对于复杂多变的石油生产数据,使得空间数据的集成更加灵活,如果数据变化可对应修改图形部件的格式即可。
针对图形部件,按照部件的不同进行分组,将其解释成SVG可识别图像。并根据需要,加入图像控制脚本如图形的定量缩放、图层显示控制、图形区域事件控制等,形成SVG文件格式形式如下。
4 实例分析
研究大庆油田中A2数据模型,开发数据库逻辑模型。针对可辅助决策生产数据,提取地理类数据10余种:井位坐标、断层信息、砂体分布信息、层段信息、层段连通关系、剩余油等值线数据等。属性类信息20余种:油井开采信息、水井开采信息、单井静态信息、小层静态信息、油水井生产剖面、油水井方案措施记录、油水累计统计数据、井筒信息、功图数据等。
根据实际需要,定义了15大类图形中间件,其中重点类如下表列出(表1)。
解释成SVG格式图幅中,按照不同部件分层管理,有效的控制图层的显示。对于统计类数据,定义了一种特殊的图形统计部件,包括饼图、柱状图、曲线等多种统计形式。
除SVG图形自带放大、缩小、图像品质调整功能外,利用Java脚本提供了图像定量缩放、定位区域、图形编辑处理等功能。并利用事件触发机制,快捷的链入已有文档和图幅,增加了系统的可用性和辅助决策的能力。
5 结论
基于SVG技术,针对可用于辅助决策的实际成产数据建立数据集成模型。提取关系数据实体,并利用XML文件格式形成中间图形部件,将中间图形文件合理地解释最终形成综合信息显示图幅。工作人员可根据具体工作需要,选择针对性较强的图幅显示,辅助生产决策。数据的可视化显示可直观的表现生产状态,并可进行综合的数据分析,从而较高地提高了工作效率。
参考文献
[1]陆西宁,王红芳.基于GIS的空间决策支持系统的研究.微电子学与计算机,2009;26(4):138—140
[2]乌伦,刘瑜,张晶,等.地理信息系统原理、方法和应用.北京:科学出版社,2001
[3]刘啸,毕永年.基于XML的SVG应用指南.北京:北京科海集团公司,2001
[4]徐锋.基于SVG的空间数据的网络发布.技术与创新管理,2009;30(2):237—239
空间数据集成 篇7
(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(可以在网络上免费下载)，此时就可以在两个机器的终端访问对方的数据，同时也可以下载对方的数据(格式被转换为本机兼容的格式)，在两个计算机终端基本实现了异构空间数据的集成和共享。对于坐标变换及进一步的统计分析在此就不作深入探讨。
空间数据集成 篇8
在实现生活中, 经常会发现这样的一些地理物体或者现象之间有某种联系, 例如: 通常与高尔夫球场相邻的对象是停车场; 距离植被近的电线杆塔故障率高; 林地多的地方往往耕地、 住宅用地偏少; 处于气温低区域的森林, 发生病虫灾害概率小等。 这些地理空间中对象或者现象的相互关系可以被定义为地理空间关联规则, 地理空间关联规则用于描述大量空间数据 (对象或者现象) 之间有趣的相互联系。 从哲学层面上来说, 存在于的联系不是个别事物之间暂时的、 单独的、 特殊的关系, 而是一切所有事物、 现象和过程所共有的客观的、 普遍的本质之一; 所有事物都不能孤立地存在, 都会联系其他事物。 事物多种多样的联系普遍存在于宇宙中。
大数据 (big data) , 是指目前无法在可承受的时间范围内用常规软件工具进行捕捉、 管理和处理的数据集合。 大数据其特有的性质, 在Viktor Mayer-Sch nberger编写的 《大数据时代》 中大数据指不用随机分析 (非全面调查) 这样的手段, 而是对所有数据进行分析处理。 大数据的5 个特点: Volume ( 海量) 、 Velocity ( 快速度) 、 Variety ( 多样) 、 Value ( 价值) Veracity (真实性) 。 而地理信息大数据是大数据组成一部分, 是天生的大数据。 地理信息数据是关于地理数据所蕴含和表达的地理含义, 是与地理环境位置有关的对象或者现象的定量或者定性描述总称。 地理信息数据有区别于非地理信息数据的特点, 其主要区别是具有地理空间性质即地理定位信息 (坐标或位置描述) 。 而像经典的” 啤酒和尿布” 案例只是非空间的关联规则发现, 遇到更复杂的地理空间数据就无能为力了。
地理空间关联挖掘 (发现) 是利用地理空间关联规则提取算法发现空间对象或者现象间的关联程度, 从地理空间数据集合中抽取隐含知识、 空间关系或非显式的有意义的特征或模式, 挖掘地理空间数据集合的空间特性, 如地理位置、地理方位、 地理距离、 地理几何拓扑关系、 地理空间属性 (长度、 面积等) 等。 挖掘和发现日常生活中接触到的地理空间对象之间的空间关联模式或相互关系是目前地理空间关联规则挖掘的主要目的。 在地理空间分析中, 除了传统要素之间的关联 (简单、 时序和因果等关联) 规则的发现, 关联规则分析还可用于探索存在地理空间环境中上下不同事件之间的关联性, 如某地的气候异常与该地或者其他地方的灾害之间在地理空间分布上的关联关系, 或者多种事件/现象在某个地理空间上成群出现 (空间同位) , 都是关联规则的例子。 例如, 植物学家根据共生植被的分布, 发现 “半湿润常绿阔叶林”生长的地方80%有 “兰类” 植物生长。
参考目前使用最广泛的关联规则在数据挖掘中表达, 空间关联规则的基本形式为:
该公式可解释为 “满足A地理空间的条件常常也满足B地理空间的条件”, 其中A、 B是地理空间谓词集合 (A∩B =Ø, A∪B至少包含一个地理空间谓词) , Support (A→B) 为地理空间规则的支持度, Confidence (A→B) 为地理空间规则的置信度。 一般认为地理空间谓词的形式有4 种: 表示拓扑结构的、 表示空间方向的、 表示距离的和其他的。 各种各样的地理空间谓词是地理空间关联规则构成重要组成部分。 如, 地理空间距离关系 (如Close_to (靠近) 、 Far_away (远离) ) 、 地理空间拓扑关系 (Intersect (相交) 、 Overlap (覆盖) 、 Disjoin ( 分离) ) 和地理空间关系 ( 如Left_of ( 左边) 、 East_of ( 东边) ) 。每个这种空间关系的关联性都有一个支持度或有效性的度量 (是否具有恰当维持性) , 支持度表达式:
而有效性称为置信度 (是否具有适当的信任性) , 其表达式为:
一般用最小的置信度与支持度来提取有效的规则, 满足置信度与支持度条件即可认为是数据集的待求关联规则。
在此所要讨论的是在大地理数据环境下, 选取特定区域内的地理POI (Point of Interest) 数据, 集成利用空间分析中的聚类、 凸包、 叠置等分析, 分析在空间位置上有一定关联关系的空间对象, 挖掘出该区域内符合最小的置信度与支持度的地理空间关联规则。 挖掘地理空间关联规则在现实世界中极其有价值, 已经有一些非常经典的应用。 例如: 因为某区域气候 (如海洋) 异常对某区域气候 (如陆地) 异常事件的发生具有重要的诱发作用, 可以将两者进行地理空间关联挖掘, 可以得到区域之间相关的关联关系 (如发现出 “厄尔尼诺” 空间关联现象, 就是太平洋东部和中部区域热带海洋的海水水温异常地在某时间段持续变暖, 而整个世界区域气候模式发生一系列变化, 造成某些地区偏干旱而另一些地区又降雨量过多) 。探究异常和极端气候在空间上的发生规律乃至更深层次的原因, 可以对极端气候的发生提供预警依据, 如图1 所示。
2 Apriori算法与其地理空间化
Apriori算法 (Agrawal 1993) 是一种以概率 (频率) 为度量基础、 著名的提取和发现布尔型关联规则频繁项集 (item set) 的算法, 它使用循环渐进扫描数据集合的方式以求找到数据间的关系, 以形成规则。 Apriori算法包含两个重要的步骤: (1) 连接; (2) 剪枝 (去掉那些没必要的中间结果) 。 Apriori算法中常出现项集的概念, 项集简单地说就是项的集合, 包含K个项的集合为K -项集。 项集的出现频率就是指包含项集的事务数, 称为项集的频率。 如果项集满足最小支持度, 那么称它为频繁项集, 频繁项集k-项集的集合记作Lk。 然而, 该算法主要针对非地理空间数据的挖掘, 对地理空间数据挖掘能力不足。
相对于传统Apriori算法, 地理信息数据挖掘算法较为复杂, 其主要原因在于其挖掘对象地理空间数据本身的复杂性。地理空间数据具有地理空间位置和方位、 距离、 几何拓扑等地理空间属性, 并且其本身就具有一定的相关性 (距离近的地理空间对象和现象的特征越相近) 。 因此, Apriori算法必须进行地理空间化改造后才能适合地理信息数据的关联规则发现。
空间化改造后, 地理空间关联规则发现的优化算法可通过5 个步骤实现:
(1) 根据要求获得相关的地理空间数据。
(2) 运用地理学第一定律的相邻等原则描述空间属性和特定属性。
(3) 过滤和筛选重要的数据, 剔除不满足最小支持度的地理空间谓词。
(4) 运用空间度量度 (地理面积支持度和地理相交面积确信度等) 等其他手段对数据进一步提纯。
(5) 提取和发现地理空间关联规则。
地理空间关联规则的发现关键是地理空间关联规则的提取, 地理空间关联规则的提取关键是由最小支持度和置信度的计算。 式 (1) 、 式 (2) 、 式 (3) 可知, 地理空间关联规则的支持度和置信度计算都依赖于地理空间谓词集的支持度计算, 这个计算的基础不同于非地理空间的度量 (基于统计频度) , 而是地理空间的度量 (基于地理几何面积计算) 。
对地理空间POI点集ps中的点进行聚类分析, 所得聚类的凸包分析 (轮廓) 所覆盖的区域称为满足ps的区域, 记作polygon ( ps) 。 对于POI点合集合POIS = { ps1, ps2, … , psn}, 称polygon (ps1) 、 polygon (ps2) 到polygon (psn) 的交 (叠置分析-intersection运算) 为满足POIS区域, 记作polygon (POIS) 。 进行特定区域聚类地理空间关联规则提取时, 将一个POI类别点集看作一个地理空间谓词, 将该区域所有POI类别点集看作是地理空间谓词集。 称满足特定区域地理空间谓词集相交POIS的面积与研究区域R总面积之比为POIS的聚类-凸包-叠置支持度 (Cluster-Convex hull-Over Layer support) , 记为CCOS (POIS) , 则有:
其中calc Area () 为计算面积的函数, 将式 (4) 分别代入式 ( 2) 和式 ( 3) , 就可以得到规则A →B的聚类支持度CCOS (A→B) 和聚类置信度CCOC (A→B) 公式:
要实现的具体功能是从互联网上的地理信息服务 (腾讯地图开发平台) 获取POI集, 将POI集分类进行聚类分析生成聚类集, 对聚类集生成分析外轮廓凸包面集, 将这些面集进行叠置分析后计算面积, 根据面积计算最小支持度和置信度得到POI主题以Close_to (临近) 地理空间谓词的关联规则, 最后挖掘出来的地理空间关联规则以文本、 图表、 电子地图、街景全景的方式表达展示。 功能设计框架设计如图2 所示, 空间关联规则多方式表达如图3 所示。
3 空间关联规则的提取中的面积计算
Apriori算法空间化最基本思路是地理空间的最小支持度和置信度以多边形的面积计算为基础, 因此地理几何面积计算是地理空间关联规则提取实现的一个关键点。
所取得的数据为经纬度坐标, 因此所涉及的计算是地球面上的多边形, 计算比较平面系统复杂。 程序实现将地球简化为一个球体, 在地球球面上, 两点间最短的距离是最大圆的弧线段的长度。 所谓球面上的最大圆, 指的是在球面上圆心与球面的球心重合的圆 (例如地球的经线都是最大圆, 而纬线只有赤道是最大圆) 。 连接球体曲面上两点的最短弧线称为测地线, 它是由古代的科学家们测量地球两地点之间距离时发现的。 而一个球面上的曲面n边形, 是由n条测地线段首尾相连所构成的闭合多边图形。 与平面几何的情形类似, 每条空间球体测地线段定义为曲面多边形的边, 空间球体测地线段的交点定义为顶点。 顶点处两条空间球体测地线的切线的夹角就是空间多边形的内角。
设地球的半径为R (设为6378000 米) , ABC是地球上一个球面三角形。 分别以 α, β, γ 代表地球表面3 个顶点的内角, 仍然沿用符号△ABC表示它的地理空间面积。 沿着地球球面延长该三角形的3 条边, 将其延长为完整的地球球体的大圆。 地球球面上的这两个大圆会在地理空间中有两个交点, 这两个交点是在球面上以球心为中心的一条直径的端点, 这样的两个交点称为对径点。 记A, B, C的对径点分別是A', B', C', 如图4 所示。
考察球体的球面上半圆弧ABA' 和半圆弧ACA' 包围形成的区面区域。 由于球面上关于直径AA' 是三位空间旋转对称的, 因此很容易推理出这块区面区域与整个球面的面积之比为 α/2π。 已知球面的面积公式是4πR2。 所以这块区面区域的面积是2αR2, 即
△ABC + △A' BC = 2αR2
按照同样的方法, 还可以求得出:
△ABC+△AB'C=2βR2
△ABC+△ABC'=2γR2
因为△ABC' 和△A'B'C关于球心对称, 所以它们的地理面积相等:
△ABC' = △A' B' C
又由于上述三角形的其中4 个可以拼成半个球面, 即:
△ABC + △A'BC + △AB'C + △A'B'C = 2πR2
所以根据以上5 个方程, 可以解出:
公式7 就是地球球面三角形面积公式。 它最早是由英国籍数学家托马斯.哈里奥特发现的, 以笛沙格定理命名, 因为最早地将这个公式发表的是法国籍数学家吉拉德.笛沙格。
以公式7 为基础, 球面多边形面积计算需要将经纬度坐标换算成为弧度。 球面多边形计算面积的关键在于计算多边形所有角的度数。
对于球面n边形, 所有角的和为S, 球的半径为R, 那么其面积就是
根据公式8, 空间关联规则的支持度和置信度的筛选量度中的基础—地球表面多边形面积就可以计算了。 具体代码实现如下:
4 显示地图、街景地图以及线获取POI点集
4.1 腾讯地图开发
在线获取地理信息数据与地图展示 (二维矢量和街景景) 时主要用到了腾讯地图开放平台的Java Script API V2、 Web-Service API。
Java Script API V2 可用于在网站中加入交互性强的地图, 能很好地支持PC及手机设备, 目前是免费服务, 任何提供免费访问的网站都可以调用。 Java Script API中包含街景API, 是构建在v2 版本上的全新应用接口, 对于目的地, 可以让用户足不出户, 得到直观的浏览体验。
Web Service API是基于网络服务HTTP协议的数据接口, 开发者可以使用任何开发语言在客户端、 服务器按照腾讯地图Web Service API参数规范, 按需构建HTTP请求, 并获取结果数据 (目前支持json/jsonp方式返回) 。
4.2 Java Script API V2 创建地图及添加Marker、Label、Polygon
HTML文件中用腾讯地图Java Script API创建了以武汉为中心的铺满div的地图。 HTML中包含Java Script程序, 其功能是根据参数绘制标注Marker、 标签Label及多边形Polygon等覆盖物。 绘制参数由C# 后台计算提供, Java Script负责解析并绘制地图数据。
4.3 街景地图
街景地图是一种基于街道的实景地图服务。 中国街景地图的产生比较早, 甚至早于谷歌地图。 街景地图表达地理信息比较充分和详细, 是对传统二维矢量地图的一个有力补充。由于传统地图 (包括统计的电子地图) 对地理信息进行了抽象、 综合, 会对人的地理空间认知造成一定的影响, 因此街景地图的出现是解决 “最后100 米识别” 问题一个有效工具。
文中街景主要的参数是场景 (pano) 、 视角 (pov) 。 场景 (pano) 是一个360 度的全景 ( 街景是由无数个场景组成的) , 每一个场景都有自己的一个唯一标识Pano Id。 视角 (pov) 主要由偏航角 (heading) 俯仰角 (pitch) 、 缩放 (zoom) 3 个参数构成。 在JS程序中, 还使用一个重要的API对象qq.maps.Panorama Service, 其方法get Pano (position:Lat Lng, radius:Number, callback:Function) 的功能是通过某点经纬度获取指定半径内其最近街景场景信息 (包括pano Id、 场景所在坐标等) 。
本功能实现的JS代码如下:
其中函数get Args From Href的功能是获取坐标参数, change的功能根据坐标调用pano_service街景场景服务获取当前实景。
程序运行街景地图效果如图5 所示。
4.4 利用腾讯地图Web Service API及Java Script API V2 获取POI数据、行政区域范围
(1) 使用的POI数据通过腾讯地图Web Service API的地点搜索 (Search接口) 功能获取。
(2) 使用的行政区域范围坐标数据获取通过Java Script API V1.3 中的BMap.Boundary对象的get方法, 具体实现代码为:
JS前端获取的POI及行政界线数据将返回到C# 桌面程序处理。
5 聚类分析、凸包分析、叠置分析的集成及Apriori算法空间化的实现
在大数据时代, 数据挖掘和知识发现是最有价值和关键的工作。 大数据的挖掘和知识发现是大量、 可能有缺陷的 (不完全的、 有噪声的、 模糊的、 随机的) 非样本中发现隐含在其中有价值的、 潜在有用的信息和知识的过程, 也是一种决策支持过程。 程序实现的地理空间关联规则挖掘和发现主要基于聚类分析、 凸包分析、 叠置分析、 面积计算等, 通过对地理信息大数据高度自动化地分析, 做出归纳性的推理, 实现方法的实质就是Apriori算法空间化。 地理空间关联规则分析需要进行多项前序的分析和预处理工作, 传统的非空间化的Apriori算法需要量度的空间化, 计算统计对象的面积而不是一般事务性的频度, 而计算的面积是通过多边形叠置分析得到, 叠置分析的输入—待分析Polygon (面) 集由凸包分析得到, 凸包分析的输入—待分析离散点集由聚类分析得到, 聚类分析的源数据从Internet上在线获取。 聚类分析、 凸包分析的集成是叠置分析关键的前置处理流程, 而叠置分析是与Apriori算法集成在了一起。 整个程序处理流程图如图6 所示。
5.1 聚类分析、凸包分析、叠置分析的集成
将聚类分析、 凸包分析、 叠置分析分别编译为DBSCANDll.dll、 Convex Hull Dll.dll、 Over Lay Dll等.dll文件, 然后引用到叠置分析程序的解决方案中。 聚类分析、 凸包分析、 叠置分析具体实现见文献3、 4、 5, dll文件引用方法见文献5。
5.2 空间关联规则挖掘的程序实现说明
地理空间关联规则的地理空间谓词是由C# 的Dictionary类表达的。 Dictionary是一种泛型类 (封闭不同的数据类型) , 提供了从一组键到一组值的映射。 字典中的每个添加项都由一个值及其相关联的键组成。 通过键来检索值的速度是非常快的, 接近于O (1) , 这是因为Dictionary类是哈希表。 从程序的运行效果看, Dictionary类表达地理空间谓词进行快速查找和排序都十分方便。
(1) 判断是否为频繁集, 该功能为空间关联规则提取的核心function之一
其中, Split Poly Array Intersect是叠置分析交运算的函数, Split Poly Array Area是计算经纬度多边形集面积和的函数。
(2) 根据谓词名称, 查询得到谓词对应相关图层, 可以获取图层边界坐标
该功能主要依赖Dictionary的查询和排序功能。
(3) 得到1阶的频繁POI图层集
Split Poly Array Area函数也在该部分的程序中用到, 主要也是面积计算, 因为是一元谓词, 因此不需要进行叠置交运算。
(4) 根据频繁1-谓语集得到所有频繁集
这一部分根据频繁1-空间谓语集得到所有频繁集, 是空间关联规则提取必不可少的一步。
(5) 根据所有频繁集进行连接、 剪枝, 得到候选集
本程序是找出所有空间频繁k项集的集合, 为找出k项空间频繁集做准备, 该程序分为两步空间频繁集连接和空间频繁集剪枝, 具体过程为:
1) 连接处理: 为找出Lk ( 所有的频繁k空间项集的集合) , 通过将Lk-1 (所有的频繁k-1 空间项集的集合) 与自身连接产生候选k空间项集的集合。 候选集合记作Ck。 设l1 和l2 是Lk-1 中的成员。 记li [j] 表示li中的第j项。 假设Apriori算法对空间对象或空间项集中的项按字典次序排序, 即对于 (k-1) 空间项集li, li [1] <li [2] <……….<li [k-1]。 将Lk-1 与自身连接, 如果 (l1 [1] =l2 [1]) && ( l1 [2] =l2 [2]) && … … ..&& (l1 [k-2] =l2 [k-2]) && (l1 [k-1] <l2 [k-1]) , 则认为l1 和l2 是可连接。 连接l1 和l2 产生的结果是{l1[1] , l1 [2] , … …, l1 [k-1] , l2 [k-1]}。
2) 剪枝处理: CK是LK的超集, 也就是说, CK的成员可能是也可能不是频繁的。 通过扫描所有的空间对象或者空间现象, 确定CK中每个候选的计数, 判断是否小于最小支持度计数, 如果不是, 则认为该候选是频繁的。 为了压缩Ck, 可以利用Apriori性质: 任一频繁空间项集的所有非空子集也必须是频繁的, 反之, 如果某个候选的非空子集不是频繁的, 那么该候选肯定不是频繁的, 从而可以将其从CK中删除。
(6) 根据确信度过滤频繁集, 最后得到空间关联规则
该部分根据生成的可能频繁集进行确信值的度量, 进行了叠置分析交运算Split Poly Array Intersect和面积计算Split Poly Array Area, 对是否能够确定为关联规则进行了考理, 最终确定哪些频繁集可能构成空间关联规则。
6 空间关联规则挖掘结果的多形式表达与实例测试
6.1 空间关联规则挖掘结果的表达
如何展示挖掘结果, 要看数据挖掘的结果是什么形式, 由于是地理信息数据, 因此考虑以地图与文本、 图表结果的形式, 特别是集成了街景表达。 前面地图与文本、 街景已有介绍, 这一段重点介绍图表的表达。
图表实现是基于dotnetcharting控件完成。 dotnetcharting是一个很好用的图表控件, 能画出很漂亮的报表, 一般常用到的主要有柱状图、 饼图、 折线图3 种。 具体代码如下:
(1) 根据dotnetcharting封装了一个Charting类
(2) 根据空间关联规则生成chart
其中程序可以按照参数type的设置绘制柱状图、 饼图和拆线图。
6.2 挖掘实例测试
在实例测试中, 规则挖掘的空间谓词为距离关系-Close_to (临近) , 挖掘某个中心点范围内的POI数据, 挖掘的关联模式是Co-location Pattern Discovery (同位模式挖掘) 。 它是空间关联规则挖掘的一种, 地理同位模型表达为: (POIs, Location) , 比如 ({餐馆, 咖啡店}, 关山) 。 对地理信息进行分类, 针对不同的POI类别进行同位模式挖掘, 可以挖掘出这几类不同的POI之间组合的空间关联关系, 从而可以提供地理位置的推荐服务, 比如餐馆经常和咖啡店在关山这个位置同时出现, 那么在用户查询餐馆时系统就可以推荐给用户相应的服务 (如咖啡店查询) 。 基于区域大小, 根据颗粒粗细, 空间关联关系可以分为global pattern (全局关联模型) 和local pattern (局域关联模型) , 分别指所挖掘出来的空间同位模型到底是普遍性的还是只针对某些特定的地方。 比如上面说的餐馆和咖啡店经常一起出现, 可能只在关山这个区域存在而已, 这就是local pattern, 表示这是关山地区特有的特点。 从实用来说, local pattern可能更有用的, 因为global pattern经常挖掘出来的是常识 (common knowledge) , 不具备新颖性, 一般可能无需使用data mining技术来做。
实现的程序主界面中, 待分析数据选择的参数是 “所在区域”、“挖掘地点”、“挖掘级别” 和 “最小支持度”、“最小可信度” 等5 个输入设置; 电子地图的覆盖物绘制约束是设置是否 “绘制POI”, 设置是否 “绘制规则范围”。 其中挖掘级别是设置POI类别的颗粒大小, 级别数值越大则类别越处于底层信息越详细, 越小则类别越处于顶层信息越抽象。
设置5 个输入参数分别为 “武汉”、 “武汉大学”、 “1”、“0.0005”、 “0.7”, 程序运行结果如图7 所示。
设置5 个输入参数分别为 “杭州”、 “浙江大学”、 “1”、“0.0005”、 “0.7”, 程序运行结果如图8 所示。
设置5 个输入参数分别为 “北京”、 “北京大学”、 “1”、“0.0001”、 “0.7”, 程序运行结果如图9 所示。
设置5 个输入参数分别为 “北京”、 “清华大学”、 “1”、“0.0001”、 “0.7”, 程序运行结果如图10 所示。
设置5 个输入参数分别为 “上海”、 “复旦大学”、 “2”、“0.0002”、 “0.7”, 程序运行结果如图11 所示。
从以上测试结果来看, 关联规则挖掘的结果相对比较合理, 体现与地理位置背景相关的一些特性, 与实际情况接近。测试的大学附近POI中餐饮所占比例大, 各个学校略有差异。如图7 所示, 武汉大学附近是基础设施和美食餐饮相关联; 如图8 所示, 浙江大学附近是宾馆酒店与美食餐饮相关联 (可能是由于杭州是旅游城市) ; 如图9、 10 所示, 北京大学和清华大学附近是房产小区与美食餐饮相关联; 而如图11 所示, 复旦大学附近是以冷饮与西餐等相关联 (设置了比较详细颗粒的关联运算) 。 从能够挖掘出地理空间关联规则的支持度来看, 武汉与杭州是设置的数值较小, 而北京和上海设置的数值较大。 从地理面积的意义上考察, 这反映了武汉、 杭州与北京、上海按照城市面积大小可归为两种不同的类别, 而武汉、 杭州可归为一类, 北京、 上海可归为一类。 总体来看, 程序通过分析数据挖掘规则发现了新的知识, 而通过地图、 街景地图、 图表、 文本等表达, 使规则描述更清晰、 更直观。
7 结语
介绍了关联规则的Apriori算法, 并研究了该算法, 然后对该算法进行了空间化处理。 通过程序的运行情况可以看出, 集成多种地理空间分析工具对地理信息数据进行数据挖掘和知识, 能够发现某特定区域的地理信息潜在的关联关系, 得出的结论也和其地理背景知识相一致。 故此, 认为在实际应用中, 地理地理空间关联规则的数据挖掘与知识发现对地理信息数据有着非常重要的现实意义。 例如, 数字高程模型 (DEM) 含有地理坐标 (经度和纬度) 和海拔高等地理信息, 通过对DEM数据进行数据挖掘, 采用地理空间关联分析法, 提取与果树生长环境密切相关的信息, 如坡度、 坡向、 坡位、果树生长地理纬度、 离海洋的距离等地理因子。 通过对农业气候生态及其地理分布特征的研究, 结合历史气象资料、 实地考察、 现实种植等相关情况, 进行地理地理空间关联规则发现, 实现果树种植生态区域选择和规划, 指导果树种植, 为精细化农业提供辅助决策。 该应用具有很重要的科学意义和潜在的经济价值。 目前, 这个程序只是初浅地实现了地理空间数据关联规则的挖掘功能, 最小支持度和置信度设置也不灵活, 需要人工调整, 该程序将继续改进, 集成地理信息背景知识的约束, 使挖掘的规则和发现的知识更加符合真实情况。
参考文献
[1]Koperski K, Adhihary J, Han J.Mining knowledge in geographical data[J].communications of ACM, 1999.
[2]K Koperski, J Han.Discovery of Spatial Association Rules in Geographic Information Databases[A].Procof Fourth International Symposium on Large Spatial Databases[C].Maine, 1995:47-66.
[3]董志.利用DBSCAN实现约束条件下的空间聚类分析[J].电脑编程技巧与维护, 2013, (17) :65-75+87.
[4]董志.利用Monotone Chain算法集成在线地理信息数据生成凸包[J].电脑编程技巧与维护, 2014, (20) :72-81.
[5]董志.利用空间面-面叠置分析实现在线地理数据的信息挖掘[J].电脑编程技巧与维护, 2015, (13) :5-16.
保险数据仓库之数据集成设计 篇9
一、数据集成原理概述
由于保险业务性质决定保险业务系统处理逻辑复杂, 数据量大, 再加上种种原因还保留许多历史遗留系统, 开发平台和技术规范也不统一, 给数据仓库的数据集成带来了不小的难度。因此, 在数据集成设计时, 既要考虑满足数据仓库之初管理需求的实现, 又要考虑实现数据规范的统一、避免对OLTP (联机事务处理) 数据库性能的影响、减少对OLTP库结构的修改等约束, 在保证数据抽取质量和效率的前提下, 我们提出的保险数据仓库数据集成解决方案, 如图1所示。
(一) 各数据抽取层概述
1. OLTP数据源
即所有保险联机事务处理数据库, 以及其他非结构化数据。为减少对OLTP的性能影响, 对各生产库要抽取的源数据表增加了插入、删除、修改触发器, 由触发器调用数据库内核捕获OLTP数据源的表记录变化, 并按事务处理前后将这种变化保存在轨迹库中。
2. 轨迹库
即保存反映OLTP数据变化的轨迹数据库, 与OLTP数据源是一对一关系, 且尽量选择相同数据库, 这样确保对OLTP性能影响小。它与OLTP数据库表结构的不同之处在于, 轨迹库表除比OLTP数据库表多3个字段外, 其他字段结构相同, 多的3个字段分别为:变化类型标志 (I:插入, D:删除, U:修改) 、更新时间戳、标志型字段。如一条记录在生产库中先被插入, 而后修改再删除, 这样在轨迹库中将保存三条记录。
3. 同构库
选择与后续数据仓库、ODS相同的数据库平台, 实现各异构的OLTP数据库平台的统一, 其库结构与OLTP轨迹库相同, 而记录信息除要保存删除记录外, 其他与OLTP数据源表一致。它是通过ETL工具获取OLTP轨迹库中最后记录状态信息, 仅反映生产库的当前状态。
4. 操作数据存储 (ODS)
是对多个OLTP库经过ETL (即数据抽取、转换、装载) 过程按照主题进行有效地集成, 定期刷新, 包含当前有效数据, 是数据进入数据仓库前的缓冲区。其具备4个特点:面向主题、集成性、近实时数据发布、当前数据。
5. 数据仓库 (DW) 和数据集市 (DM)
包含大量从ODS层传送来的历史数据, 传入数据一般不再修改。它是面向分析型数据处理, 支持分析决策, 不同于操作型数据库, 具备4个特点:面向主题、集成的、相对稳定的、反映历史变化。数据仓库是满足企业级管理决策需要, 而数据集市是满足部门级管理决策需要而设置, 可看成数据仓库的子集。
(二) 数据抽取层间关系
OLTP数据源到轨迹库是通过触发器方式减少数据抽取对OLTP生产库的性能影响, 而轨迹库到同构库是解决数据库平台统一问题, 将不同数据库统一到同构库中, 形成与生产库同构的数据, 同构库到ODS库是分主题的数据集成, 用于数据进入DW前的数据缓存, ODS到DW是生成代理键及映射表的过程, 由于数据进入DW生成了代理键, 不便根据业务键进行回溯关联更新, 同时从同构库到ODS中有多对一表的抽取, 情况更为复杂, 不便查错。因此设计ODS非常必要, 这样也保证ODS到DW的抽取基本上是一对一的抽取。
二、关键抽取技术设计
数据抽取主要有全量抽取和增量抽取。全量抽取比较简单, 在此不再累述;增量抽取主要有触发器、时间戳、全表比对、日志比对等方式。下文就触发器和时间戳增量抽取方式中的一些关键技术与大家进行分享。
(一) 抽取控制表的设计
本控制表存在除生产库外的所有源数据抽取端的库中, 用于增量抽取控制。其中endid和curid是自增长型的标志型字段, 如数据从生产库进入轨迹库时会产生系统时间戳和标志字段, 而通过抽取控制表可以确定本次数据抽取范围, 实现增量抽取。另外, 此处endtime和curtime的设计是增加系统的可靠性。
(二) 抽取频率及精度设计
数据增量抽取是在各抽取层间从前至后顺序流动, 为保证数据抽取的有效性和准备性, 后面抽取频率应低于或等于前面的抽取频率, 后面抽取时间戳精度应低于或等于前面抽取层的时间戳精度。同时, 只要不是最后一级数据层, 即使是到DW层, 若还有后续抽取, 则都应在各级数据层中设计时间戳 (捕获更新数据行) 和增删标志 (有效确保删除目标数据层中的删除或被修改前的数据) 字段, 以便数据正确流转。
从同构库开始后的一表对一表的数据流转方式:根据源数据层Etl Ctl控制表中的时间戳起点及源数据表中的最大时间戳确定被更新的数据范围, 抽取数据到临时表, 根据主键关联删除目标正式表中的数据, 将临时表中的数据插入正式表, 若此时正式表为最后一层数据层, 此时将临时表中增删标志不为‘D’的插入即可。另外, 因为同构库中数据与OLTP数据源中数据是同构的, 所以即使后续数据的抽取频率变低, 数据流转方式与上面的相同。
(三) 防主键修改的触发器设计
针对有主键表的增量抽取方式, 若在OLTP生产库中修改了主键值, 通常做法是通过更新触发器插入轨迹库一条更新的数据记录, 但由于有主键的后续抽取是通过主键进行判重删除的, 这样将导致同构层数据原主键记录形成垃圾, 无法删除。鉴于此种情况, 我们对OLTP生产库的更新触发器改为两条插入触发, 插入一条主键修改前原记录, 同时标志为D, 再插入一条主键修改后的新记录, 同时标志为I。这样, 在抽取包中按主键查重后, 不会因修改了主键而产生冗余垃圾记录。如对表agent_post_mclerk的更新触发器修改为:
(四) 多表对一表的数据抽取设计
多表对一表的数据抽取过程中, 往往由于源数据层的多表数据准备不同步, 有的表数据先准备好, 有的表数据后准备好, 导致进行多表数据关联抽取时数据遗漏, 从而影响后续数据抽取的正确性, 为此须采取措施保证多表数据到目标层后数据的同步性和正确性。通常做法是:先通过在Etl Ctl控制表采取左关联, 确保控制表数据不会掉, 然后用另一个表关联更新目的表所有字段。这种抽取方式虽然可以保证数据的准确性, 但不能保证数据的一致性和同步性 (同步更新) , 同时关联更新此表时必须用另一个表的全表数据更新, 查询数据量大, 效率低, 因此这种方式不可取。为了保证数据的正确性、同步性, 采取的设计原则是:只有多表的关联记录数据全部准备齐了才一同到达目标层。
考虑到生成的目标表是否要对关联的源数据多表进行聚合运算, 在此分两种情况进行分别讨论。现假设要从源数据层的A表:psn_customer (cust_id, …, upd_flag) 和B表:customer (cust_id, …, upd_flag) 中, 抽取数据到目标层的C表:c02 (cust_id, …) 中, 前面带下划线的字段为表中的主键 (此处源表的关联条件是否构成目标表的主键均没有任何影响, 将其设置为目标表主键是为了更方便理解) 。
1. 多表对一表时不进行sum, average, count等聚合运算, 但可进行distinct运算的情况
根据表间关联条件抽取数据, 并根据upd_flag值决定, 只要有一个为‘D’, 则值为‘D’, 同时不为‘D’时, 才为‘I’, 然后生成的临时表数据根据目标表主键对目标表进行先删除后插入操作。
(1) 更新抽取控制Etl Ctl表:update Etl Ctl set
2. 多表对一表抽取时进行了 (不含distinct) sum, average, count等聚合运算的情况
此时应分两步:第一步先根据有效或无效 (删除) 数据生成2个临时表 (字段为目标层表的主键) , 2个临时表的数据为第二步回溯抽取数据的条件;第二步以临时表字段为条件关联回溯抽取源多表数据 (当然原多表的关联仍然保存) , 生成对应2个新的明细临时表, 进行distinct临时表数据, 而后取合生成正式表数据, 再对正式表进行先删后插操作。
(1) 更新Etl Ctl表:update Etl Ctl set
三、结束语
空间数据集成 篇10
【关键词】大数据 学生管理 lucene
【中图分类号】G64【文献标识码】A 【文章编号】2095-3089（2015）01-0009-02
信息化的不断发展，为管理提供了便利。现已存在的教务系统、就业信息系统、学生信息采集系统等记录了学生在校期间的所有信息，数据的管理利用和查询就显得尤为重要，而目前高校在这方面还存在着不足，具体表现在以下几个方面：
一、对信息化手段掌握不足
绝大部分高校和部门仍局限在手工填写报表和简单的excel报表等。规范性较差，基础工作较薄弱。已有的原始数据资料和新增的数据资料都不完善不规范，需要数据时无法及时的提供，工作效率大大降低。
二、大数据
全球知名咨询公司麦肯锡，在“大数据”研究报告中指出，数据已经渗透到每一个行业和业务职能领域，对于海量数据的运用将预示着新一波生产率增长和消费者盈余浪潮的到来。
不同行业对大数据的定义有所区别，每种定义都有他们的共性所在： 大数据中所指的数据是全部数据。大数据最终的用途和关键点是“预测”。
“大数据”是目前呈现出的一种现象而不是一项新产生的技术。“大”有两个深层次的含义：首先是数据量大。通常定义10TB的数据量为是大型数据集，但是在现实高校与企业中，多个数据集集合在一起，就已经远远超于10TB的数量；其次是数据种类多，数据来源多。这些数据生产于不同的系统，不同的应用，不同的部门背景，并且数据的种类和格式也各种各样，呈现出多元化的特点。因此大数据并不等同于海量数据，并且处理大数据，要面临更大的挑战。
高校大数据是高校信息化中重要的进一步发展，将对高校各部门的决策支持、个性化服务、人性化管理、预警服务及预测等领域产生巨大的推动作用。
三、大数据背景下的学生信息分类
从大数据的视角入手并结合高校学生信息数据的特点，可以将高校收集的数据划分为两大类。一类存在于关系型数据库中，包括每位学生的学号，姓名，课程成绩等信息，这些信息用统一的数字类型和符号类型来表示，称为结构化业务数据；另一类存在于高校各部门办公室，或者是高校管理人员的电脑中，存在的格式也多种多样，有文本信息，图片，音频，视频等等，这些信息无法用统一的数字类型和符号类型来表示，称为非结构化业务数据，是高校大数据研究的重点。此外，高校中还有一些数据是介于这两者之间，称为半结构化业务数据，本文不做重点讨论，高校数据分类如图所示：
图1 高校信息数据分类
四、处理非结构化学生信息的方式
在高校存在的非结构化数据中，几乎是以文本信息的形式存在，管理员迫切需要一个高效的检索工具。全文检索（Full-text Retrieval）技术是一种面向全文、提供全文的新型检索技术。它克服了传统顺序索引在多文献集和和复杂查询查询条件下检索效率低的不足。文海捞针是对全文检索的形象描述，全面、准确和快速是衡量全文检索系统的关键指标。
（1）采用B/S模式
B/S模式即浏览器/服务器模式，管理员只需要一个浏览器就可以获得想到的资料，。B/S模式优于C/S（客户端/服务器）模式最大的一个特点是，无需采用专门定制的客户端，减少数据的中间访问层次，进而提高了数据的访问速度与效率。
（2）构建学生信息索引
图2高校索引机制架构图
从图中可以看到，构建索引的整个过程分为三步：将高校学生信息原始WORD格式、PDF格式、EXCEL格式的业务数据转换成文本、分析文本、将分析好的文本保存至高校学生信息索引库中这三个主要操作步骤：
将原始文档转换成文本
使用Lucene索引高校学生信息前，对索引的数据进行预处理操作，即从不同格式的业务数据中提取纯文本格式信息，以便识别该文本并建立对应的文档。即从非文本文档中提取文本信息，然后用这些提取出来的数据建立文档和域[8]。
分析文本
分析文本前，将高校学生信息进行分割成语汇单元串，对语汇单元串执行一些可选操作：如，统一将语汇单元中的英文转换为小写，方便搜索系统不对大小写敏感；去掉语汇中一些频率很高但是却没有实际意义的词，比如，的，地等等。
将分析好的文本保存至索引
对文本分析完成后，要将得到的段写入高校业务数据的索引文件库中，写入的时候要采用倒排索引的数据结构进行存放。
（3）搜索学生信息索引
图3搜索系统模型图
如上图所示，搜索子系统的作用是搜索学生信息索引，即对高校管理员输入的各种搜索命令进行搜索和响应。根据前期对西安科技大学的调研报告显示，本系统主要提供的搜索方式有如下几种：词条搜索，范围搜索，布尔搜索，模糊搜索和短语搜索。词条搜索是最基本的搜索方式；范围搜索为高校管理员提供了可供选择的关注点，缩小了搜索范围。通过选择时间段2010年到2012年，查看该时期内的学工部的文件；布尔搜索也是一种基本的搜索方式，各种复杂搜索，经过转化可以成为一个布尔搜索；模糊搜索是对西安科技大学高校管理人员需求调研后特意添加的一种搜索方式，当管理员并不是很清楚要搜索的范围时，模糊搜索是很好的选择方式，而且管理员可以在此基础上再次搜索；短语搜索是在用户输入多个词条时一种比较有效的搜索方式。
五、结语
高校信息管理手段已无法短时间内在海量信息中找到所需。本文在分析了信息集成管理存在的不足后，给出了大数据背景下学生信息的分类，介绍了大数据背景下学生信息集成管理的方法。
参考文献：
[1]吴代文，詹海生.西安市数字方志全文检索系统的设计与实现[J].计算机技术与发展.2011，10（21）.121-123.
[2]张维刚，徐永东，雷小强等.web全文检索中间件的设计与应用[J].计算机应用.2011，8（31）.2261-2263.
作者简介：
数据集成技术综述 篇11
随着信息技术飞速发展和应用领域不断拓宽,信息技术极大地提高了人们的工作效率,给人们的生活带来了诸多便利。然而在信息化建设初期,由于缺乏有效的和合理的规划和协作,造成信息化建设的大量重复和“信息孤岛”现象,随着信息量的爆炸式增长,信息化建设遭遇到巨大的浪费。针对目前情况,迫切需要一种技术用于将之前的各个独立的信息化系统集合起来,给各个“孤岛”架起沟通的桥梁,为将来各种各样的信息化建设服务。随着互联网技术的诞生,在一定的程度上可以很好的支持信息发布和信息收集,但对于之前的信息化资源的重用需求,对于日益迫切的分散数据访问和分析需求——跨地区的连锁经营销售商要求对其每天总的销售状况进行分析等,对于越来越复杂的应用环境——在线分析处理(OLAP)、决策支持系统(DSS)、数据挖掘(DM)等,人们迫切需要形成跨组织、跨领域、多应用的信息交换和共享。在这种背景下,数据集成技术应运而生。
数据集成技术是将分布的、异步的,甚至异构的独立信息源中的有用数据集成在一起,使得用户能够以透明的方式访问这些数据源,以供将来信息检索、分析处理等等应用的技术。集成是指维护数据源整体上的数据一致性、提高信息共享利用的效率;透明的方式是指用户无需关心如何实现对异构数据源数据的访问,只关心以何种方式访问何种数据,图1显示了数据集成系统模型。[1,2]
数据集成是信息系统集成的基础和关键,好的数据集成系统可以保证用户以低代价、高效率使用异构的数据。现在,越来越多的现代企业已经意识到商业数据集成在企业日常运作和管理中的重要性,全球著名的IT企业如Oracle、IBM,数据开发环境单一,工具环境无关性差等缺点。而且随着应用的不断深入,对Microsoft和Sybase等都针对自己的产品提出了数据仓库的数据集成解决方案,这些解决方案提供了方便了数据集成方法,但它们都或多或少地存在这样或那样的缺陷,比如兼容性数据集成提出更新更高的要求———任意订制需要抽取的数据、灵活而高效的数据抽取方式(实时或周期性抽取等)、数据抽取的一致性、异构信息源(包括半结构化和非结构化数据)集成和系统平台无关性等。数据集成的研究与设计必须深入,解决以前方法的局限性,提供更高的实用性,找到一种更优的维护方法等等任务。[3]
2 传统的异构数据集成方法
传统的数据集成所采用的方法基本可以分为两大类:数据复制方法和模式映射方法。
2.1 数据复制方法
数据复制方法将各个数据源的数据复制到与其相关的其他数据源上,并维护数据源整体上的一致性,提高信息共享和利用的效率。数据复制可以是整个数据源的复制,也可以是仅对变化数据的传播与复制。数据复制方法可减少用户使用数据集成系统时对异构数据源的数据访问量,提高数据集成系统的性能。最常见的数据复制方法就是数据仓库方法。该方法将各个数据源的数据复制到同一处——数据仓库,用户则直接访问数据仓库获取数据。这种方法既可用于数据集成,亦可用于决策支持查询。但是,这种对数据仓库的间接访问方式带来的问题就是数据更新不及时、数据重复存储。斯坦福大学DB Group的数据集成方案是数据复制方式数据集成方法的代表性方案。然而在应用领域中,信息源数据通常含有企业商业机密信息或政府部门公众机密信息,不能让数据集成系统访问这些信息或基表。[4]
2.2 模式映射方法:即虚拟视图的方法
模式集成(Schema Integration)是人们最早采用的数据集成方法,也是其他数据集成方法的基础。其基本思想是,在构建集成系统时,将各数据源共享的数据视图集成为全局模式(Global Schema),供用户按照全局模式透明地访问各数据源的数据。该方法不需要重复存储大量数据,能保证查询到最新的数据,比较适合于集成数据多、且更新变化快的异构数据源集成。
模式集成要解决的两个基本问题是:构建全局模式与数据源共享数据视图间的映射关系;处理用户在全局模式基础上的查询请求。模式集成过程需要将原来异构的数据视图作适当的转换,消除数据源间的异构性,映射成全局模式。全局模式与数据源数据视图间映射的构建方法有两种:全局视图法和局部视图法。全局视图法中的全局模式是在数据源数据视图基础上建立的,它由一系列元素组成,每个元素对应数据源的一个查询,表示相应数据源的数据结构和操作;局部视图法先构建全局模式,数据源的数据视图则是在全局模式基础上定义,由全局模式按一定的规则推理得到。
2.2.1 联邦数据库
联邦数据库是早期人们采用的一种模式集成方法。联邦数据库中数据源之间共享自己的一部分数据模式,形成一个联邦模式。联邦数据库系统按集成度可分为两类:采用紧密耦合联邦数据库系统和采用松散耦合联邦数据库系统。紧密耦合联邦数据库系统使用统一的全局模式,将各数据源的数据模式映射到全局数据模式上,解决了数据源间的异构性。这种方法集成度较高,用户参与少;缺点是构建一个全局数据模式的算法复杂,扩展性差。松散耦合联邦数据库系统比较特殊,没有全局模式,而是提供统一的查询语言,将很多异构性问题交给用户自己去解决。松散耦合方法对数据的集成度不高,但其数据源的自治性强、动态性能好。
2.2.2 中间件集成方法
中间件集成方法是另一种典型的模式集成方法,它使用全局数据模式。与联邦数据库不同,中间件系统不仅能够集成结构化的数据源信息,还可以集成半结构化或非结构化数据源中的信息,如Web信息。基于中间件的数据集成系统主要包括中间件和包装器,其中每个数据源对应一个包装器,中间件通过包装器和各个数据源交互。用户在全局数据模式的基础上向中间件发出查询请求。中间件处理用户请求,将其转换成各个数据源能够处理的子查询请求,并对此过程进行优化,以提高查询处理的并发性,减少响应时间。包装器是对特定数据源进行封装,将其数据模型转换为系统所采用的通用模型,并提供一致的访问机制。中间件将各个子查询请求发送给包装器,由包装器来和其封装的数据源交互,执行子查询请求,并将结果返回给中间件。中间件注重于全局查询的处理和优化,相对于联邦数据库系统的优势在于:它能够集成非数据库形式的数据源,有很好的查询性能,自治性强;中间件集成的缺点在于它通常是只读的,而联邦数据库对读写都支持。
2.2.3 peer-to-peer数据集成方法
peer-to-peer(P2P)[6]数据集成方法是在新兴的P2P计算技术的基础上,对原有的模式集成方法的扩展。P2P是一种基于对等网络的架构,是计算机系统的结构从传统的集中式发展为松散耦合分布式的新模式。在P2P数据集成方法中,参与集成的各个数据源节点分别被视作一端,每个节点可以将自己的一部分本地数据模式映射成为端共享模式,向其他节点共享自己的数据。纯粹的P2P数据集成方法没有全局数据模式,各节点可以直接通过P2P映射使用其他节点共享的数据模式,从而形成各节点之间对等的数据共享与访问机制。P2P数据集成方法已成为当前数据集成研究的一个热点。
3 异构数据集成的新技术
虽然数据集成技术已经取得了很多应用成果。但由于应用和需求的不断拓展变化。数据集成迄今仍是困扰企事业单位信息系统建设、维护和发展的难题。还远未得到很好解决。已有的数据集成方案普遍存在难以适应数据源的动态变化、难以完成动态集成以及传输成本高等缺陷。而且很多系统中的数据是从数据源向集成模式单向流动的,不能支持局部数据源之间的数据交换和共享。也不能在集成数据上进行新型跨部门综合业务的开发针对以往数据集成方案的不足,人们不断探索,新的数据集成技术也不断涌现。其中包括网格技术和本体集成技术。
3.1 网格技术
网格技术提出目的就是实现分布式环境下的资源共享和协同计算。网格(Grid)又称为虚拟计算环境。是近年来兴起的一种重要的网络信息技术网格利用计算机网络把地理上广泛分布的计算资源、存储资源、网络资源、软件资源、信息资源、知识资源等连成—个逻辑整体,然后像一台超级计算机一样为用户提供—体化的信息应用服务。实现互联网上所有资源的全面连通、全面共享。以消除信息孤岛和资源孤岛。
3.2 本体技术
数据的异构性分为两个方面:一是结构性异构,即不同数据源数据的结构不同:二是语义性异构,即不同数据源的数据项在内容和含义上有所不同或有冲突。目前,XML已经成为异构系统间数据交换的公认标准,所以,语义异构成为数据集成技术的难点。已有的各数据集成方法也都面临如何更好的解决语义异构的问题。
本体是对某一领域中的概念及其之间关系的显式描述。是语义网络的—项关键技术。本体技术能够明确表示数据的语义以及支持基于描述逻辑的自动推理,为语义异构性问题的解决提供了新的思路,对异构数据集成来说应该有很大的意义。但本体技术也存在一定的问题:已有关于本体技术研究都没有充分关注如何利用本体提高数据集成过程和系统维护的自动化程度、降低集成成本、简化人工工作。基于语义进行自动的集成尚处于探索阶段,本体技术还没有真正发挥应有的作用。
因此,可以采取本体技术和中间件相结合的方法[5]:采用中间件架构,支持虚拟视图或视图集合,且不存储任何异构数据库中的实际数据。为了更好地解决语义异构,在中间件中引入了一个本体库。
整个系统架构如图2所示,包括如下3个层次:
1)应用层
应用层为终端用户提供访问中间件层的查询接口,用户可以通过应用层的浏览器调用中间层。系统提供统一的查询检索平台,它能够显示用户可以查询的集成信息,而底层集成的数据源对用户是透明的。
2)中间件层
中间件层从更高层次上屏蔽了数据源的分布性和异构性。用户认为所有的数据都是本地的,处于同一服务域中,而具体的查询请求的处理、结果的返回都由中间层负责。中间件主要由中介器、包装器和本体库3个部分组成,其中,中介器又包括查询生成器、查询分解引擎、查询执行引擎和结果处理4个功能组件。
3)数据源层
数据源层是由分布式异构数据源组成,数据源可以是关系数据库、Excel表格,也可以是半结构化的XML文档。每一个数据源都可以位于Web上不同的服务站点,采用本地的方式对数据进行管理。
4 数据集成技术展望
鉴于异构数据集成所固有的难点。可以相信,异构数据集成技术会随着各个难题的解决而得到越来越广泛的应用。今后,数据集成的研究方向应该包括:(1)基于网格、本体语义的数据集成方案的研究;(2)多种技术相结合的数据集成方案;(3)集成数据的完整性、一致性,实时性。
5 结束语
本文从对数据集成技术需求出发,说明了数据集成技术对当前信息系统的重要性。对传统的几种数据集成技术进行了概括,并对数据集成的两种新技术进行了研究,给出了数据集成技术发展的方向
摘要：从现行信息需求出发,介绍了数据集成技术发展的必要性,讨论了已有的数据集成技术,分析了这些技术的优缺点,介绍了网格技术、本体技术两个新的异构数据集成技术。在此基础上给出了本体技术和中间件相结合数据集成解决方案。最后,提出了数据集成方法的发展方向。
关键词：数据集成,数据复制,模式集成,本体
参考文献
[1]Widom J.,"Research Problems in Data WareHousing",In Proceedings of the4th,Int'L Conference on Information and Knowledge Management(CIKM),November1995.
[2]薛惠忠,庄晓青,董逸生.数据仓库中的数据集成转换[J].现代计算机,2003.12:78-82.
[3]Ullman J D.Information integration using logical views[c]//proceeding of ICDT97,Volume1186of LNCS,1997:19-40
[4]Hammer J.,Garcia-Molina H.,Widom J.,Labio W.,Zhuge Y."The Stanford Data Warehousing Project",In IEEE Data Engineering Bulletin,1995,18(2):41-48.
[5]周刚,郭建胜.基于本体的异构数据源集成系统分析与设计[J].北京:北京联合大学学报,2007.10:45-48.
[6]周傲英,凌波.Peer-to-peer系统及其应用[J].计算机科学,2001,29(8):200-202.
[7]徐立臻,谢鸿强.数据仓库系统中源数据的提取与集成[J].小型微型计算机系统,2003,24(5):869-873.