基于数据抽取与订阅实现数据共享分析及研究论文

基于数据抽取与订阅实现数据共享分析及研究论文（精选6篇）

篇1：基于数据抽取与订阅实现数据共享分析及研究论文

1.引言

早期的应用系统的建设，大都存在缺少总体、全面、系统的规划，缺乏统一的数据标准，相互之间资源难以共享的“信息孤岛”。从而造成各部门提供的数据不够完整、准确和权威。给全校范围内信息的交流和共享带来了障碍，同时产生了大量的冗余信息。因此，需要通过对各部门计算机应用系统进行统一规划，利用底层整合的信息资源，为门户、应用和信息资源整合提供数据交换、资源管理等基本服务接口，以实现各部门决策数据在应用层面的互联互通和信息共享。

为了实现数据共享，需要建设数据中心存储全校共享的数据。建设数据中心时，尽可能扩展数据的集成范围，形成大而全的数据中心，作为全校数据统计分析、智能决策支持的权威数据库；数据库能集成到数据中心运行的应用系统尽可能集成到数据中心运行，数据中心可以成为后续开发各种应用系统的通用数据库平台；对于需独立运行的应用系统，通过数据交换与共享服务平台来实现数据的集成与共享；同时制定规范的数据变更流程，实现谁产生、谁维护、谁负责的权威数据源。

本文以我校数字化校园项目建设为例，重点介绍如何规划好我校数据流，以及如何通过数据的抽取与订阅实现各业务系统数据共享。

2.数据流规划

为了实现校内各业务系统间的数据共享和保证数据的一致性，必须规划好数据流向。数据共享的总体包括了代码集的共享和数据集的共享。在这里，“代码集”主要是指在各个应用系统需要实现流转的学校标准代码，“数据集”主要是指在各个业务系统间需要进行数据共享的数据集。

每一个共享的代码集或数据集都有唯一的权威数据源，执行“谁产生，谁维护”的原则。在整个数据流转设计中，数据流都不做交叉设计，这样不会导致数据流混乱，形成误解。因些必须对各业务系统进行统一编码，设置好业务系统间数据共享流程，并对共享数据信息流细化。

2.1业务系统统一编码

根据我校所使用的各业务系统，分别采用数字对应各业务系统，“41”代表“人事系统”；“42”代表“学工系统”；“43”代表“招生系统”；“44”代表“科研系统”；“45”代表“科研系统”；“47”代表“迎新系统”；“48”代表“离校系统”；“50”代表“校友系统”；“52”代表“办公系统”；“61”代表“财务系统”；“62”代表“图书馆系统”；“63”代表“一卡通系统”；

2.2业务系统间数据共享流程

业务系统主要涉及到：招生系统、教务系统、迎新系统、学工系统、离校系统、校友系统、人事系统、财务系统、科研系统、办公系统、图书馆系统、一卡通系统；系统间各业务数据的来源及共享如下图所示：

每个带有“数字”箭头的标记分别表示数据的来源和内容及数据流向哪个业务系统，详细信息如下：

(1)新生数据

(2)新生数据（教务系统已经进行分班编学号处理）

(3)迎新结果数据

(4)学生基本信息，学籍基本信息，成绩数据

(5)学生基本信息，学生收费明细

(6)学生收费结果数据

(7)奖学金信息，资助信息，贷款信息，绿色通道信息，困难生补助信息

(8)学生奖学金发放结果，资助金额发放结果，补助发放结果，贷款处理结果

(9)学生收费数据，学生欠费数据

(10)需要办理离校手续的学生信息

(11)离校后的学生信息

(12)教职工基本信息，教职工工资明细

(13)教职工基本信息

(14)科研成果数据，论文、著作数据

(15)科研项目信息

(16)项目经费到账信息

-教职工信息

(17)-（20）教职工信息

（21）教师课程安排信息，教学质量评价信息

（22）（23）学生基本信息

3.数据抽取与订阅

3．1数据抽取与订阅的实现流程图

通过触发器、系统日志、数据变化标志位来捕捉业务系统需要共享或要交换到数据中心的数据发生变化，同步到中介库，设置中介库在业务系统数据库服务器，这样数据发生变化后同步到中介库，不需要进行数据库异构转换，而且不需要经过任何网络，这样能保证数据的实施、高效、安全的数据同步。

3．2数据抽取与订阅实现

数据中心从各业务系统中抽取需要共享的数据来保持数据同步，如需要从教务系统中取学生信息集和教学场地信息集，需要从人事系统中取教职工信息集。数据中心从业务系统整合数据的关系图如下：

先由数据中心系统管理员或各业务系统管理员进行数据抽取配置，选择从哪个系统抽取数据，再设定业务系统信息字段与数据中心信息字段的对应关系如图3所示：

4.结语

高校信息化建设是一个不断发展的过程，在这个过程中，信息资源的有效整合是一个必然的过程，通过整合可以实现现有业务系统之间的数据交换与共享。本文通过分析学校各业务系统的数据特点，规划出各业务系统的数据流向，并通过数据的抽取与订阅实现数据共享。

参考文献：

[1]金保华，和振远，张亮，李金旭，赵丽辉 基于 SOA的数据共享与交换平台分析与设计 郑 州 轻 工 业 学 院 学 报(自 然 科 学 版)2011年2月

[2]李学俭 数据共享环境下统一信息标准的建设与应用 计 算 机 技 术 与 发 展2011年5月

篇2：数据抽取及交换工具的设计与实现

出版商业智能系统是面向出版单位的综合数据分析系统, 该系统基于出版企业各业务系统的数据进行综合分析, 另一方面, 出版企业各业务系统之间也需要进行数据交换。由于出版企业采用不同公司提供的业务系统, 各业务系统采用不同的数据库, 应用较广泛的有SQL Server、Oracle, 少量有采用My SQL等其它类型数据库, 另外还有许多的外部数据以Excel、TXT、XML等文件方式存储, 本文针对出版行业的现状和应用需求, 研究了通用的商业智能系统ETL工具的数据抽取、转换和加载相关技术, 提出了面向出版行业的数据抽取及交换工具设计方案和实现方法, 通过.NET开发工具和C#开发语言开发了一套工具。

1 ETL技术综述

ETL即数据抽取、转换清洗、加载的过程, 能够按照统一的规则集成并提高数据的价值, 是数据仓库获取高质量数据的关键环节, 是从数据源获取数据并对数据进行清洗转换最终加载到数据仓库的过程, 是数据由数据源系统向目标数据源加载的主要方法。ETL工具从本质上而言是一种数据转换工具, 一般ETL工具还会设计任务管理和调度引擎[2]。

1.1 数据抽取

数据抽取是按业务需求从源数据从数据源系统抽取数据仓库系统所需的数据[错误!未定义书签。], ETL处理的数据源除了关系数据库外, 还可能是文档, 例如TXT、Excel、XML等文件数据, 这要求抽取工具采用统一的数据接口, 既满足从数据库抽取数据的需求, 也可以满足从文文本件抽取的需求。对于不同数据源、不同数据量的源数据以及不同性能要求的业务系统, 采用的实现方式不同。一般的抽取方式包括全量抽取、增量抽取、全表比对、日志比较等[8], 为保证抽取效率, 减少对生产运营的影响, 可针对不同的情况选用不同的抽取方式。

1.2 数据清洗转换

从数据源中抽取的数据不一定完全满足目的库的要求, 例如数据格式的不一致、数据输入错误、数据不完整等等, 数据转换就是完成对抽取的源数据根据数据仓库系统或目标数据库的要求, 进行数据的转换、清洗、拆分、汇总等[4], 保证来自不同系统、不同格式的数据和信息具有一致性和完整性, 并按要求装入目标数据库。一般数据转换可通过源数据与目标数据的映射关系来完成[4], 其转换规则可定义在映射表中, 转换工具根据定义的规则进行转换。转换工具可直接采用SQL语句的方式和转换组件的方式进行转换。比较而言, 直接在SQL语句中进行转换和加工更加简单清晰, 性能更高, 但一般要求操作的数据是关系型数据库。对于SQL语句无法处理的可以采用组件的方式处理。

1.3 数据加载

将清洗转换后的数据加载到目的库中通常是ETL过程的最后步骤[6], 当目的库是关系数据库时, 直接通过SQL语句进行insert、update、delete操作[8]。目的数据源是文件格式如XML、Excel、TXT等文件时, 可通过转换工具根据映射表的设置转换成要求的文件。

2 系统设计与实现

2.1 设计思想

ETL设计与开发, 需深入到业务系统内部去获取所需数据, 需定义源数据、目标数据, 数据抽取、转换和装载策略等[15]。参考ETL设计开发的基本要求, 本文对系统进行了整体设计, 下文介绍主要设计思想。

数据交换的过程如图1所示, 系统设计了三种数据交换方式:

为提高数据交换的性能, 对于源数据和目标数据都是关系型数据库的情况, 可以直接运用SQL语句的方式进行数据交换。

一般数据可通过系统的转换工具进行数据转换后直接写入目标数据源。

复杂转换需要经过中间数据表暂存数据, 通过对中间表的清洗转换处理后再加载到目标数据源[16]。

系统采用灵活定义的方式解决各种情况下的数据交换需求, 包括各种类型数据库连接的定义、源数据与目标数据的映射关系定义、数据清洗转换规则定义, 系统提供可视操作界面并将定义的结果保存到数据库表中, 整个程序将依据各种定义进行分别处理, 完成数据抽取、转换及加载的各项功能。

为了更方便用户操作各项数据交换任务, 系统提供了作业调度管理的功能, 系统按照调度计划、作业组、作业的层次关系进行管理, 以作业为最小的操作单元, 作业组可包含作业和其他作业组, 一项调度计划可包含多项作业组和作业, 对作业、作业组和调度计划系统提供界面由用户根据实际应用需要定义。系统将针对调度计划采用队列扫描的方式执行每一项作业。

为适应不同类型的数据库, 系统按照分层设计的理念对数据库的访问处理封装为一层, 在程序处理时将根据不同的数据库做出不同的处理。根据出版行业实际情况目前系统提供了对SQL Server、My SQL、Oracle的支持, 支持Excel、TXT和XML文件。该设计提供了良好的可扩展性, 对该层代码进行扩充即可适应更多类型的数据库。

系统选用.NET集成开发工具, C#开发语言进行开发实现。系统采用三层架构, 包括UI层、业务逻辑层和数据层[17], 此种设计保证系统具备良好的可扩展性。

2.2 数据库连接

用户对数据库连接属性定义, 可定义各种数据源的连接属性, 支持SQL Server、My SQL、Oracle等关系型数据库的连接, 定义的项目包括标识、服务器地址、数据库名称、用户名、密码等。系统将根据用户的定义信息动态创建数据源连接对象, 该连接对象既可以作为源数据库也可以作为目标数据库。

2.3 数据映射关系

数据映射关系定义了抽取和转换的规则, 即数据源表中的数据字段与目标库表中的对应关系定义, 映射关系采用主子表结构进行定义, 主表中需要从已定义的数据库连接中选择目标表数据源连接和源数据表连接、是否根据源数据表结构创建目标表, 子表定义相关表字段的对应关系及转换规则。

系统提供可视化界面方便用户建立源数据到目标数据的抽取映射关系。为方便用户选择, 可直接通过源数据中提取源数据表和目标数据中提取对应库表中的表及字段供用户选择, 用户直接选择对应关系, 定义转换规则, 也可以直接输入表中的字段名建立对应关系, 定义完成后的映射关系和转换规则保存到映射关系到表中。系统将根据定义的映射关系完成抽取、转换和加载。

2.4 复杂的清洗转换处理

对于复杂的数据转换, 需要由源数据抽取到中间库表, 此时可将中间表看作目标数据源, 经过专门的清洗转换处理, 形成与目标数据库一致的数据, 再定义一个由中间库表到目标数据的映射关系, 即将中间数据库看作源数据, 将规范的数据由中间表加载到目标数据的表中。

为完成专门的清洗转换处理, 用户可通过系统提供的可视化工具进行清洗转换定义, 支持SQL语句更新的方式进行数据清洗和转换, 用户可定义更新的表、更新的字段、更新的条件, 提供了对统计、计算、类型转换、字符串拆分处理等基本处理功能, 针对出版行业的需求提供了标准书号与简书号转换等特色的转换功能, 系统将根据用户定义的清洗转换规则进行转换处理。系统同时支持用户直接写SQL语句进行清洗转换, 更复杂的处理通过二次开发的方式解决。

2.5 作业管理

作业管理是整个数据抽取与交换软件的核心, 作业是指一个完整的操作过程, 作业管理包括作业定义和执行, 系统可分三类作业, 对于一项作业, 首选作业类型, 系统将根据不同的作业类型进行分别处理。

直接执行SQL语句。

直接执行SQL语, 只能针对于关系型数据库, 作业定义时, 首先选择一个数据源, 定义SQL语句, 用户可以直接输入SQL语句, 也可以通过系统提供的SQL编辑工具进行添加, 一个任务可以添加多个SQL语句。

通过映射关系定义由一个数据库抽取数据到另外一个数据库的库表中。

任务定义时, 首先需要选择已定义好的映射关系表, 同时需定义目标数据获取时所使用的条件, 设置对比标识列 (一般为表的唯一标识列, 可以是复合字段) , 同时可设置操作是完全添加、增量更新、是否反向删除等抽取方式。如果输出为文件类型, 需定义输出位置, 文件命名规则, EXCEL、XML样式等信息。

通过转换清洗规则在中间库进行数据转换处理。

系统根据用户定义的清洗规则, 自动转换为可执行的SQL语句执行该项作业。

系统支持作业组, 可将相关或功能相近多个作业定义到一个集合中。可以选择一批作业或作业组组成一个新的集合, 其中每个子项可以有任意下属子项, 子项可以为作业也可以为作业组, 但在作业组包含其他作业组时应慎重使用避免死循环。系统将保存作业组标识, 作业组描述信息, 关联的作业或作业组及执行顺序。

2.6 调度计划

调度计划是实现作业或作业组自动化运行的一种方式, 设置什么时间点来处理什么信息的一种定义。一个调度计划包括一组作业或作业组, 系统将以调度计划为单位进行调度管理。可设置一项调度计划是否启用, 是自动执行还是手动执行, 对于自动执行的调度计划, 提供可视化界面设置调度计划的运行开始时间、运行周期, 来实现作业或作业组自动化运行的定义, 参见图2。

如果配置为自动运行, 系统在程序启动时会自动加载设置为启用的调度计划, 根据计划运行频率算出每个作业下次运行时间, 自动启动运行线程, 系统将不断扫描是否有需要自动运行的任务, 如果运行时间相等则将调度编号推送到运行队列表中, 由另一线程扫描运行。系统根据调度计划定义信息, 调度中包含的作业组, 作业定义信息, 作业定义包含的抽取规则、映射关系等按照作业的顺序自动运行, 运行结果将写入日志文件。程序逻辑如图3所示:

程序启动, 主线程自动扫描调度定义, 每间隔一段时间扫描当前时间等于下次运行时间的调度, 将时间相等的调度放入到调度作业队列中。

作业执行线程每间隔一秒扫描调度作业队列, 如果有执行的调度, 将调度编号传入到调度执行类中。

调度执行类加载调度信息, 加载调度下属所包含的作业或作业组, 如果为作业组则循环加载作业组下属子项, 如是作业则执行该项作业。

作业执行:加载作业信息, 判断作业类型分别执行。

1如果执行SQL, 先加载目标数据源连接, 顺次执行所包含的SQL脚本。同时记录脚本执行状态。

2通过映射关系定义执行数据交换, 先加载作业所包含的源数据源定义连接, 根据源数据定义及作业中加载获取源数据, 根据目标数据定义及作业中定义的目标数据条件加载目标数据, 根据条件比对、更新、插入的列生成数据表。根据定义, 如果目标库为关系型数据对内存表执行添加、更新、或反向删除操作, 如果目标库为文件类型, 则据规则输出TXT、EXCEL、XML。

3根据用户定义的转换清洗规则, 自动转换为SQL语句, 在中间库进行数据转换处理。

记录日志:将作业的运行时间, 各个环节状态记录到日志表中, 如果执行出错, 系统将错误记录到日志中, 同时事务回滚。

3 结束语

针对不同数据库类型的数据交换的应用需求, 本文设计的系统通过可视化界面为用户提供灵活的定制功能, 包括数据库连接的定义、数据转换所需要的源数据库和目标数据库的连接选取、源数据表列与目标数据表列的映射和转换规则, 对复杂的清洗转换处理采用在中间库表中由用户进行自由定义规则的处理方法, 通过灵活定义的方式保证系统具有较强的适应性。同时用户可通过对调度计划、作业组、作业灵活定义的方式实现各种需求的作业和调度管理功能。该系统可满足各种不同的数据抽取、转换、加载的应用需求。

篇3：基于数据抽取与订阅实现数据共享分析及研究论文

关键词：数据传输；档案信息；共享平台；模型设计；WCF

0 引言

“档案是有史以来最早产生的文献之一，也是现代社会的核心信息资源的重要门类”[1]，有效开发和合理利用档案信息，不仅是社会技术进步的需要，更重要的是关系到档案信息创新成果能否充分运用到社会生产中。伴随着社会科技的发展，档案信息共享平台除了可以在传统的Web平台上进行信息资源共享，移动平台的档案信息共享也成为越来越重要的需求点，尤其是如何利用WCF技术进行不同平台之间的信息资源传输与共享是当前研究的重点。本文的目的在于研究一款数据传输模型，使用该模型可以便捷地在服务器端、客户端、移动终端之间进行数据交互，并实现数据传输的安全高效。

1 数据传输模型研究现状及意义

随着移动互联网技术的发展，用户除了可以通过传统的电脑进行档案信息的研究外，还能够随时随地通过移动设备接入档案信息共享平台进行研究[2]。跨平台作为档案信息的新特点，对数据传输安全与数据传输效率的要求较高。

1.1 数据传输效率。提高数据传输的效率，主要包括两个方面因素，一是取决于服务器端与客户端的网络带宽；二是如何减少数据在传输过程中产生的信息。在减少数据传输产生的信息方面，一是控制未处理的信息包含在传输的数据中，二是对传输过程中的数据格式进行优化，即同样的信息在被客户端接收后能够无损进行识别，这是数据传输效率提升的关键所在。档案信息共享平台的数据在传输过程中目前可以采用的格式有FSV格式、XML格式、JSON格式。对于这三种格式的传输效率国内外已有相关研究[3]，其中XML已经被业界广泛地使用，其在数据传输过程中采用XMLHttp方式，而JSON才刚刚开始，其作为新生代的纯文本数据格式，在Ajax 数据交换中有着得天独厚的应用优势。对于JSON数据格式比较简单，易于读写，格式都是压缩的，占用带宽小，且支持多种语言，包括C、C#、Java、JavaScript、Perl、PHP和Python等服务器端语言，便于服务器端的解析。

1.2 数据传输安全。档案信息共享平台的数据在传输过程中需要加密处理，到达目标后需要进行解密处理，这就需要采用对称加密算法对数据进行处理，数据传输的安全重点需要对适用于数据传输过程中的加密算法进行研究。在数据传输过程中利用对称密码技术[4]构造安全的数据传输协议，以及复杂的密钥分配，密钥管理协议等[5]。在公钥密码算法优化方面，优化了传统公钥密码算法中的模大数乘法和模大数的指数等基本数学运算，针对椭圆曲线密码系统中的基本运算，同样有类似的研究，采用点乘和点加的优化[6]。

1.3 数据传输技术。档案信息共享平台的数据传输技术可以采用.NET技术实现，其采用方式目前有以下几种方式：Socket、.Net Remoting、WebService、WCF。如目前比较流行的腾讯QQ、银行系统之间通讯对于Socket通讯应用比较广泛；再如前几年比较火的SOA以及当前比较火的云计算之类的应用在技术层面上采用的是WebService技术进行数据传输，对于企业内部应用.Net Remoting传输技术应用比较广泛。而现行的WCF技术对.Net Remoting、 WebService等的简化、统一，在档案信息共享平台数据传输平台上可以通过配置来切换不同的底层实现且较好地适应外部环境的变化。

1.4 数据传输模型研究意义。档案信息共享平台的发展趋势在于移动化、多平台化，这就需要有一个能够支持多平台数据实时传输与信息更新的模型。这种模型研究将有利于探索支持跨平台数据传输的最新技术，该技术能够以统一的方式支持不同平台进行数据交互，特别需要对移动平台数据交互支持；同时有有利于探索最有效的数据传输方式，能够有效地解决数据传输过程中的效率与安全瓶颈。

2 档案信息共享平台数据传输模型需求及其设计

通过对传统的数据传输模型进行研究，其在数据传输的开放性及安全性方面存在不足，对于移动互联网时代的档案信息共享平台数据传输模型需要满足高效、安全及支持跨平台的需求，其中高效是数据在传输过程中采用最少的信息，安全是确保传输的数据在应用程序级能够采用适当的加密方式不被非法用户截取并非法利用。支持跨平台是不同平台可以采用相同的方式调用该模型进行数据请求与数据接收。因此，档案信息共享平台的数据传输模型的需求与设计方式要做到数据传输高效、传输过程安全和支持跨平台传输。

2.1 数据传输高效。档案信息共享平台是开放给社会用户及相关科技工作者使用的，就会存在多用户的并发操作该平台，这样就涉及数据传输性能的问题。如果数据传输出现瓶颈，直接导致的后果是平台不能正常使用。对于档案信息共享平台首先要解决的是传输效率问题，使用户在操作的过程中能够正常使用系统，从系统开发与实践的角度看，主要是减少平台在数据交互中的传输的数据量。本数据模型在数据传输前会将需要传输的数据转换成JSON（JavaScript Object Notation），这是一种轻量级的数据交换格式，基于JavaScript（Standard ECMA-262 3rd Edition - December 1999）的一个子集[7]，到达目标后将JSON数据再次转换成需要操作的数据类型，设计流程如图1所示：

2.2 传输过程安全。档案信息共享平台在互联网上是一个开放的平台，涉及的数据包含了用户的私人信息，这部分信息应该是不被明文传输，需要将原始信息进行加密处理，即需要达到即使传输的数据被非法获取也不能被正常解密。为保证信息在传输过程中的安全，模型采用动态GUID（Globally Unique Identifier）作为密钥进行加密的方式处理，动态GUID为全局唯一标识符。在每个用户的账户通过审核后，会为其自动分配一个GUID，用户在后继的数据请求中，模型会自动将用户的GUID作为密钥进行信息传输，在数据达到用户端将采用用户自带的GUID作为密钥进行数据解密操作，设计流程如图2所示：

2.3 支持跨平台传输。移动互联网的发展使得数据传输不局限于传统的PC之间进行，同时需要数据传输能够实时支持移动客户端设备。这就要求平台的数据模型需要支持不同的平台，即实现跨平台的需求。要实现数据在不同平台共享，就需要一个支持跨平台数据通信的应用程序框架，比较流行的方式有SOA的架构模式[8]，档案信息共享平台数据传输模型采用微软的WCF（Windows Communication Foundation）服务作为中间的介质，这是因为WCF技术支持多种通信协议Http/Https 、Remoting、命名管道、TCP/UDP、MSMQ、对等网、消息可达性、事务流等[9]，在开发移动客户端上具有两个显著优点：一是向下兼容；二是安全性高。WCF技术整合了原有的windows通讯的.net Remoting，WebService，Socket的机制，并融合有Http和Ftp的相关技术，档案信息共享平台所有的数据的请求经过WCF服务进行，不同平台的信息经过WCF服务的转换可以到达相同的平台或者不同的平台，通过合理的配置，使该数据传输模型在不同平台之间自由进行数据传输与数据转换，数据请求流程如图3所示：

3 档案信息共享平台数据传输模型实现

档案信息共享平台数据传输模型采用基于WCF技术架构，使用.NET技术进行跨平台系统开发，SQL Server2008作为后台数据库。要使数据传输模型达到高效、安全及支持跨平台的要求，在WCF服务具体的相关传输模型上需要设计相关接口，供数据传输模型中具体的数据操作与访问，为了使数据传输模型具有安全高效的能力，还需要设计部分通用的过程，其中包括数据转换（JSON）、安全、通用数据操作。在此基础上，还需要考虑模型中的文件及图片信息的处理，最后需要在该模型具体实现上设计一个对外的WCF服务，该服务的使用需要经过身份验证。

3.1 数据传输模型的核心架构。数据传输模型包含三个部分：数据契约、服务契约、服务接口实现。为了实现开发的可扩展性与独立性，将这三个部分分别设为三个具体的项目，包括服务数据契约项目，该项目主要定义数据操作及数据传输的基本单元；服务契约项目，该项目预先定义模型相关方法的名称及参数，使不同的平台调用服务采用相同的定义规则；服务实现项目，该项目依赖于服务数据契约与服务契约，主要职责为实现具体传输的逻辑，及根据传入的服务及参数，经过逻辑处理传出用户需要的数据，最终通过服务提供给外界平台使用。数据传输模型采用基于WCF技术的架构，在实际的应用中根据用户的实际需求，向三个项目中添加不同的实现，这样也可以做到项目的分工，不同角色的人员维护不同的项目，具体的项目之间的关系如图4所示：

3.2 数据传输模型中的通用方法工程。正如数据传输模型核心架构所示，为了更好地重用相关具体操作，对常用的功能与传输模型的特色部分需要封装。这部分主要包含两个项目：数据访问与操作工程、通用方法工程。对于数据访问与操作工程，为了支持未来的数据库的可扩展，采用抽象工厂的模式，暂时实现了支持SQL Server数据库的访问与操作的相关方法，在实际的模型调用中将根据配置文件动态调用具体的数据库方法；对于通用方法工程中，数据传输的方式与加密处理为该工程的核心，在实际的数据传输中，需要将需要传输的信息处理成JSON格式，这就包含了生成与解析JSON字符串的通用方法，涉及用户隐私信息的部分需要进行加密传输，以确保数据传输的安全，在具体实现上在每个方法的参数上加上了一个GUID标签，根据标签验证服务访问的合法性与内容加密的证据，具体的是安全实现流程如图5所示：

3.3 数据传输模型中的WCF实现方式。在数据传输模型中，核心代码包含接口定义与接口实现，在实际的开发中需要对代码的实现进行版本控制，以便于追溯代码不同版本，本模型的开发采用了Visual Source Safe 2005作为版本控制工具，每次新功能开发开始需要从版本控制工具中将最新的代码签出进行开发，开发完成编译无误后，再将代码加上注释签入到版本控制工具。

3.4 数据传输模型中的WCF服务发布。在传输模型相关功能的开发完成之后，需要将服务发布到互联网上才能真正实现跨平台的信息传输服务。档案信息共享平台模型的发布服务每个接口提供一个服务地址，也就是需要为每个接口实现配置*.SVC文件，在WCF服务配置中采用微软的IIS7作为传输模型的核心服务器。为了便于服务的调用，还需要一个固定的IP地址作为数据模型的访问入口，为了使传输模型的平台管理服务不暴露于公共的环境，需要对服务的使用范围在服务器层面进行限定。

4 档案信息共享平台数据传输模型应用效果评估

在档案信息共享平台的数据模型实现之后，通过不同的平台进行调用并采用HttpWatch来监控数据传输过程中的信息，来确认本模型是否达到以下目标：不同平台可以调用本平台的服务、论证用户在数据传输过程中是加密的JSON数据。

4.1 数据传输模型跨平台应用效果评估。数据传输模型跨平台应用效果评估采用传统的服务器、移动客户端模拟器作为介质，其中对于移动客户端模拟器采用苹果的IOS系统，具体的流程为在Web开发的项目与移动客户端项目通过发布的WCF服务地址添加相同服务，并运用WCF服务实现用户的注册与登录功能，在Web上注册一个用户账户，然后在IOS模拟器上使用在Web平台上注册的账户进行登录，采用该模型可以顺利实现不同平台之间的数据传输。

4.2 数据传输模型安全及性能效果评估。数据传输模型的安全及性能效果评估采用HttpWatch来分析数据传输过程中的数据变化情况，具体的流程为执行一次获取指定条件的档案信息作者信息数据请求，查看在数据请求中包含了哪些信息，在数据返回给用户是以何形式来展现，其中对于档案信息返回结果数据的联系方式信息部分是采用加密的方式处理，通过该方式确认该模型能够达到传输需求，图6为监控的采用该数据传输模型的信息交互情况：

通过图6发现，①为数据请求的条件，两次请求输入的条件是一样的，但是输入条件的时间点不一样，是两次不同的登录，由于每次登录产生的动态GUID是会变化的，所以相同的请求会根据用户的登录信息产生动态的加密信息，这样可以确保加密信息只能被合法用户识别，将保证档案信息数据的高效传输及其传输过程中的安全。

5 总结

档案信息共享平台设计了从数据请求、传输数据加工到数据接收处理为一体的平台数据传输模型。与现有的数据传输模型相比，该平台建立了一个具有跨平台能力的数据传输模型，在实际的生产中具有较广的应用。模型在具有跨平台传输的能力基础上，首先将传输的内容进行独特的用户随机GUID方式加密，确保了信息传输的安全，其次将数据传输的格式转换处理为JSON格式，使传输的数据量达到最精简，最后将WCF技术引入到整个传输模型，使该模型具有了跨平台的能力。但采用该数据传输模型也存在着一些缺点，主要是需要增加系统实现的开发与后期的维护成本，对于系统需求本身比较简单的平台不适宜采用该模型进行数据传输。实践表明，该平台模型能够有效地满足档案信息共享平台未来不断扩展的数据传输需求。

参考文献：

[1]陈兆祦，和宝荣，王英玮.档案管理学基础（第三版）[J] .北京：中国人民大学，2005：10

[2]卞咸杰. 基于WCF技术的科技论文共享平台架构研究[J].情报科学，2015（1）：100～104.

[3]Ramon Lawrence.The space efficiency of XML[J].Information and Software Technology，2004，46（4）：753～759.

[4]毛黎华.基于云计算用户数据传输与存储的安全策略研究[J].电子技术与软件工程，2014（13）：234.

[5]李志永.移动互联网数据传输安全机制研究与设计[D].南京航空航天大学，2010：8～9.

[6]Cohen H，Miyaji A，Ono T.Efficient elliptic curve exponentiation using mixed coordinates [M].Lecture Notes in Computer Science，Heidelberg：Springer Berlin，1998：51～65.

[7]董伟，吕同斌.RFID技术和移动互联网在考务系统中的应用与实现[J].电脑知识与技术，2014（2）：281～283.

[8]王先平，张永芬.基于SOA 架构的分布式聚类算法的Web服务模型研究[J].数字技术与应用，2014（4）：136～137.

篇4：基于数据抽取与订阅实现数据共享分析及研究论文

科学数据的实质是记录客观世界的信息与规律, 是科学发现与创新的基础, 共享科学数据对于未来的科学发现极为重要[1]。据调查, 现在硬件、软件、数据的价值之比相当于1∶10∶100, 足以证明数据的重要性[2], 而目前随着数据量的不断增大, 传统的数据共享方式不能满足要求, 要使数据资源不成为信息孤岛, 找到一种有效的方式使这些孤立的数据共享起来变得意义重大。

随着空间技术的迅速发展, 空间数据的数据量迅猛增长且空间数据获取成本高, 数据具有很高的科研和应用价值, 如何有效地管理并共享空间数据成为急需解决的问题。对此, 利用Oracle 10g Spatial组件新的数据类型GeoRaster提供的功能 (数据导入导出、建立影像金字塔等) 以及结合文件上传下载技术, 设计了空间栅格数据共享机制并具体实现了该共享机制。

1 Oracle GeoRaster体系结构[3]

GeoRaster体系结构包括六个基本组件, 如图1所示。

①GeoRaster引擎:实现GeoRaster的核心功能, 包括对数据、元数据的组织、索引和核心的方法。

②SQL API:提供对GeoRaster对象访问的SQL编程接口。

③C/C++/Java:提供高级语言的编程接口 (API) , 通过这些接口, C/C++/Java语言可以调用GeoRaster的函数。

④浏览工具:GeoRaster提供对多种第三方浏览和分析工具的支持, 另外, Oracle还提供一个免费的浏览器。

⑤输入适配器:将标准的栅格数据文件转换并加载到GeoRaster中。

⑥输出适配器:将GeoRaster中的数据导出成标准的栅格数据。

2 Oracle GeoRaster 的数据模型[4]

GeoRaster使用一个基于组件的、逻辑分层并且多维的通用栅格数据模型。栅格中的核心数据是由栅格单元 (或像素) 组成的多维矩阵, 并且这些核心的栅格数据集可以进行分块, 用于优化存储、检索和处理。

2.1 数据模型在逻辑上分层

GeoRaster数据模型在逻辑上对核心数据集进行分层, 核心数据称为对象层或0层, 包括一个或多个逻辑层 (或子层) 。在GeoRaster中, 每层都是一个两维的单元矩阵, 包括行维和列维。对于多波段遥感影像, 这些层用于对成像波段或段进行建模, 若层的范围是1到n, 那么波段与层的关系是:层号=波段号+1[3]。图2说明GeoRaster数据模型中的逻辑层与影像数据的物理段或波段之间的关系。

2.2 影像分块存贮技术

由于栅格数据的数据量非常大, 在实际应用中更多的用户都仅仅关注于一个相对较小的区域或是原始图像的某种分辨率的图像, 因此Oracle 10g Spatial提供了数据分块创建影像金字塔的机制。

分块的策略是将原始栅格数据分割成若干大小一定的规则块状数据, 使系统可以逐块地处理数据。每个分块都通过元数据的方式进行描述, 存储在数据库中。分块之后不仅解决了单个BLOB字段的容量局限性, 而且也提高了数据处理和网络传输的速度及减少了内存消耗。分块的尺寸一般都是2的整数次幂, 如系统默认是16次幂, 即256*256。

规定金字塔的塔底为0级 (level 0) , 塔底上面任意一级的尺寸都可以通过公式 (1) [3]算出来:

r (n) = (int) (r (0) /2^n)

c (n) = (int) (c (0) /2^n) (1)

其中, 2^n表示2的n次幂, r (0) 和c (0) 分别为塔底原始影像的行、列尺寸, r (n) 和c (n) 分别为塔中第n级影像的行、列尺寸。

2.3 栅格金字塔

栅格金字塔策略就是对原始栅格数据按照某种方法进行重新采样, 以得到多种不同分辨率的栅格图像数据。不同分辨率的栅格数据被分别组织在不同的层面内, 最底层的数据是原始数据集。上层数据量仅是相邻下层数据量的1/ (2*2) (由公式 (1) 得到) , 从而随着层数的增加, 分辨率逐渐降低, 因此可以按照实际分辨率需求利用栅格金字塔策略从数据库中提取不同级别的栅格数据。栅格图像的金字塔分级与分块并不冲突, 若原始图像没有分块, 那么金字塔中的其他各层数据也都分别存储在一个BLOB中;否则, 金字塔中的其他各层数据也会按照与原始图像相同的分块尺寸进行分块存储[5]。图3为分块金字塔存储示意图。

2.4 SDO-GEORASTER对象和SDO-RASTER对象

在Oracle 10g Spatial中, 主要使用两种新的对象类型SDOGEORASTER和SDORASTER来存储栅格数据及其相关元数据。SDOGEORASTER数据对象代表栅格数据的逻辑实体。在用户定义的数据表中, 把需要存储栅格数据的字段的类型设置为SDOGEORASTER, 作为栅格数据的标识符, 代表栅格数据接受各种数据库操作, 它通过RasterID 标识符与SDORASTER对象建立联系。因为SDOGEORASTER没有存储实际的栅格数据, 因此常规表操作的响应速度不会受影响, 而对表中栅格数据的操作则可以通过SDOGEORASTER提供的对象方法很方便地实现。 SDORASTER对象是存储实际栅格数据的数据对象, 并根据此对象建立RDT表。如图4展示了GeoRaster对象的物理存储结构。

3 栅格数据共享机制的系统实现

用户主界面如图5所示。

共享机制的两个难点, 其一是栅格数据存储和不同分辨率数据的获取, 这已在Oracle GeoRaster 的数据模型中进行了详细论述, 其二是栅格数据共享机制实现方法, 以下将详细论述该实现方法。根据第2部分关于Oracle GeoRaster 体系结构的理论, 采用Web方式, 通过使用Java语言和SQL实现栅格数据与Oracle 10g GeoRaster对象进行数据交互。因为数据适配器存在于Oracle 10g中, 栅格数据与GeoRaster对象类型数据之间的转换只能在Oracle 10g中进行, 因此, 提供文件上传下载的功能, 以便将栅格数据文件上传到Oracle 10g的服务器文件系统中, 或从服务器将转换得到的栅格数据文件下载到本地。系统采用三层结构, 其系统结构如图6所示。

3.1 共享机制系统实现的前期准备

①创建标准DML触发器, 用于确保栅格表RMIMAGET与栅格数据表RDT1的协调性和完整性

exec sdogeorutl.createdmltrigger (‘rmimaget’, ‘imagefile’) 。

②创建栅格表, 其中包含SDO-GEORASTER字段类型

③创建一个栅格数据表

create table rdt1 of MDSYS.SDORASTER

(primary key (rasterId, pyramidLevel, bandBlockNumber, rowBlockNumber, columnBlockNumber) ) lob (rasterblock) store as (nocache nologging) ;

④插入相关的元数据并初始化空的 GeoRaster 对象

3.2 栅格数据的导入并生成栅格金字塔

①利用sdogeor的importFrom方法导入栅格数据到GeoRaster对象中并存储到数据库 (用户界面如图7所示) 。

select imagefile INTO geor from rmimaget where georid=vgid FOR UPDATE;

sdogeor.importFrom (geor, ‘blocksize= (512, 512, 5) , compression=default’, ‘tiff’, ‘file’, inpath) ;

update rmimaget set imagefile=geor where georid=vgid;

说明:

blocksize设定分块的尺寸 (即每块像素) , 其中参数5表示波段数, 大于原图像波段数部分填充空白, compression用来设定数据压缩方法;tiff表示文件类型为tiff文件;file表示导入数据类型为文件;inpath是文件路径的变量名。

②使用GeoRaster对象前, 利用sdogeor.validategeoraster函数验证GeoRaster对象, 检查他的栅格数据和元数据。

select upper (sdogeor.validategeoraster (imagefile) ) into vvalid from rmimaget

where georid=vgid;

③生成栅格金字塔

3.3 栅格数据的导出

用户界面如图8所示。

根据客户需要利用GeoRaster的sdogeor.exportTo方法可以获取GeoRaster的栅格金字塔产生的不同分辨率的栅格图像, 列举两个关键步骤。

①从数据库中获取GeoRaster对象数据, 结果暂时存储在geor1对象中, 其中geor1为SDOGEORASTER对象

select imagefile into geor1 from rmimaget where georid=ingeorid;

②利用sdogeor的exportTo方法导出GeoRaster对象中的栅格数据到文件中

sdogeor.exportTo (geor1, ‘pLevel=’level, ‘layerNumbers= (0-4) ’, tiff, ‘file’, inpath) ;

说明:

pLevel设定金字塔层编号, 由此获取不同分辨率的栅格图像, 其中level为自然数的数值型, 表示金字塔层数, 理论上最大产生金字塔层数为 (int) (log2 (a) ) , 其中a=min (原始影像的宽度, 原始影像的高度) [3];layerNumbers设定输出的波段层。

3.4 Web客户端上传下载

客户端的上传、下载功能是服务器与Web客户端交互的接口。采用http上传下载方式 (校园网内网络状态正常, 上传速度可达2M, 当然为提高速度可以引入其他服务器端技术, 如IPSAN或P2P等) , 因为是常用功能, 本文不详细阐述。

4 栅格数据共享系统实现实例

栅格数据共享系统实现实例如图6-8所示。

5 结束语

随着栅格影像数据库技术的不断完善和发展, 过去基于文件的影像处理及栅格数据管理的应用系统将逐步向数据库管理模式转变, 数据库管理的可伸缩性、安全性和高性能等特点将得到充分的应用[5]。数据库技术与面向对象技术相结合, 已成为当前数据库技术研究、应用和发展的一个重要方向。栅格数据共享机制利用Oracle 10g Spatial的特性并结合HTTP文件上传与下载功能实现了通过Web方式获取不同分辨率栅格影像数据的方法, 应用实践表明这种方式共享栅格数据达到了方便快捷、经济实用的效果。

参考文献

[1]中国科学院科学数据库数据共享研讨会[EB/OL].http://www.cnic.ac.cn/science/communion/200312230012.html.2003.12.

[2]范敏, 朱福成, 吴勇军.一种基于元数据的Web数据共享技术[J].绵阳师范学院学报, 2004, 4, 23 (2) :34-40.

[3]Jim Farley, Jeffrey Xie (谢青云) .使用GeoRaster管理地理栅格数据Oracle技术白皮书[R].http://www.oracle.com.technology.pub.articles.index.html.2003.

[4]Chuck Murray.Oracle (r) Spatial GeoRaster 10g Release 2 (10.2) [M].http://www.oracle.com/technology/documentation/spatial.html.2005.

篇5：基于数据抽取与订阅实现数据共享分析及研究论文

关键词:多普勒雷达;基数据;管理

中图分类号:TL822+.6 文献标识码:A文章编号:1007-9599 (2010) 04-0000-02

Design and Implementation of Information Management and Sharing System Based on Raw Data of Tibet Doppler Radar

Li Chunyan,Liu Yong,CiRen CuoMu

(Tibet Meteorological Information&Network Center,Lhasa850000)

Abstract:This paper introduces the use of computers,database technology, business-oriented research needs to establish basic data on Tibet Doppler weather radar data management and sharing system realization.

Keywords:Doppler radar;Raw data;Management

一、引言

新一代多普勒天气雷达(CINRAD)采用了目前世界上先进的雷达技术、计算机技术、数字信号处理以及图像处理等高新技术,具有全天候和高时空分辨率的探测能力,是监测跟踪中小尺度天气系统发生、发展、成熟、消亡过程的有效探测工具。对多普勒天气雷达资料的广泛应用可以大大加强对中小尺度天气系统的探测和预警能力,为开展短时灾害性天气系统及洪涝灾害的监测和预警、人工影响天气、中尺度数值预报奠定坚实基础。

随着中国气象局“新一代天气雷达发展规划”的全面实施,西藏地区已相继建成了四部多普勒天气雷达,并逐步投入业务运行。建立有效收集、管理、使用多普勒天气雷达资料系统,实现资料的共享,是最大限度地发挥新型探测设备作用的关键。

二、西藏地区多普勒天气雷达资料的管理及共享系统的实现

(一)系统设计原则

针对目前西藏地区多普勒天气雷达资料管理分散、无统一的数据管理系统、资料使用效率不高等问题,面向业务科研需要,设计合理的多普勒雷达资料管理策略,对资料进行有效的存储管理,并搭建资料管理和共享服务系统,通过网络将资料进行方便、快捷的共享。

(二)数据管理策略

多普勒天气雷达资料主要包括基数据(既雷达体扫文件,该数据含雷达反射因子Z、径向风速度V、谱宽W等信息,为二进制文件格式),还有基于基数据经过各种气象算法和数字图像处理生成的产品,如:组合反射率因子(CR)、垂直液态水(VIL)、回波顶(ET)、谱宽剖面产品(SCS)等丰富的天气雷达二次产品。由于多普勒天气雷达基数据数据量大,一个站点一天数据约为2.9G,其衍生产品可达三十多种,如何对这些资料进行有效分类,并进行科学的存储及管理是本项目需解决的重要问题之一。针对多普勒雷达资料基数据文件大、数据产品种类多等特点,系统研究制定了针对西藏地区多普勒雷达资料的管理策略:

1.根据业务需要及该资料的特点,确定资料存储管理的重点为雷达基数据资料,因为该资料为雷达运行的基础资料,其中包含天气变化信息、雷达运行状况信息、雷达所在环境信息等,所有的衍生产品均是基于此数据;

2.由于基数据为二进制数据格式,需要专业的软件才能读取其中的有用信息,为便于该资料的共享使用,系统开发后台资料处理系统,实时提取基数据中最重要的雷达反射因子Z、径向风速度V、谱宽W三种数据,并运用图形图像技术,形成直观的图像,在共享系统上共享应用;

3.根据现有资料的传输情况,对业务要求传输的资料进行存储管理及共享;

4.由于基数据量大,为便于存储,系统采用压缩技术,开发资料自动压缩处理模块,对基数据进行有效压缩后存储;

5.为便于资料的共享使用,与相关自动站站点资料结合,提供按时间和按天气类型两种方式进行资料检索;

6.为便于历史资料的使用,系统开发了针对下载后的雷达资料显示软件。

(三)技术实现

针对多普勒雷达资料特点,系统采用B/S(浏览器/服务器模式)和C/S(客户端/服务器模式)结合的方式开发,其中数据共享应用系统采用B/S方式开发,资料管理系统采用C/S方式开发。

1.系统流程

为便于资料管理,本系统按时间将资料分为实时资料和历史资料两部分进行管理。(1)实时资料库为近期雷达资料,库中含:①实时雷达基数据既雷达体扫文件;②宽带网实时传输的五种数据图;③基数据初步分析的四种数据产品图像:回波强度、谱宽、径向速度、无定证回波强度。(2)历史资料库为非实时库中所有的雷达基数据,采用压缩格式存储,以天为单位,全天数据一个压缩包。为便于使用,提供两种检索方式:①按时间检索、下载;②按天气要素检索、下载(与相关自动站资料相结合)。下图为系统资料管理流程及结构图。

图1.资料管理流程图

2.系统开发技术方法

系统开发主要分为三部分:资料管理系统、资料共享应用系统、基数据图像显示软件三部分。

(1)资料管理系统

系统采用C++BUIDER6.0作为开发工具,结合MYSQL数据接口技术、WINZIP软件的命令行工具(WZZIP.EXE和WZUNZIP.EXE)、目录监控技术以及利用MICPAS3系统中西藏各县的经纬度数据,实现了全区多普勒天气雷达资料的自动处理和存储。主要有以下模块:1)多普勒天气雷达资料的监控和接收模块。2)多普勒天气雷达基数据的显示处理模块。3)多普勒天气雷达基数据图像化处理模块。4)多普勒天气雷达基数据图像的地图叠加模块。5)多普勒天气雷达基数据图像的自动生成模块。6)多普勒雷达基数据及图形产品自动入库模块。7)雷达数据自动入库和维护。8)历史多普勒雷达基数据的压缩存贮模块。

(2)资料共享应用系统

该系统以B/S模式采用PHP、MYSQL等工具开发,实现对雷达资料的网络浏览、共享、查询及下载等功能。主要有以下模块:1)数据关联模块。2)共享系统数据演示模块。3)资料查询及下载模块。

(3)雷达基数据显示程序

以Windows系统作为操作系统系统,采用C++BUIDER6.0作为开发系统。

(四)系统主要实现的功能

1.资料管理系统:(1)实现对西藏地区多普勒雷达资料的自动收集、分类、入库,监控;(2)实时处理基数据资料,并生成四种雷达图像产品实时入库;(3)实现了对实时资料和历史资料的可控管理,既实时资料的保留时间可根据实际需要进行调节,调节范围在1-21天之间;(4)图像压缩质量可根据资料存储状况进行调整;(5)实现了对历史资料的自动按天压缩、存储、入库;(6)实现了对雷达站相关自动站资料的自动收集、入库。

2.数据共享应用系统:(1)对实时传输的5种整点图形资料的动画显示;(2)对实时传输基数据的4种分析图像产品的动画显示;(3)实时基数据的查看、下载;(4)实时库中5种整点图形资料的回放;(5)实时库中4种分析图像产品的回放。

3.资料应用软件:针对已下载解压后的多普勒雷达基数据文件,实现基数据文件的图形显示,包括单个基数据文件的图形显示和多个基数据文件的动画显示,显示包括多个要素(回波强度、径向速度、谱宽、无订正回波强度),多个显示范围(240公里、120公里、60公里、30公里),多个层次(九个层次)。

(五)运行情况

系统于2009年9月正式投入业务运行,系统运行稳定。经相关单位应用,在气象业务及科研中,发挥了较好的作用。

三、结论

(一)系统采用计算机、数据库等技术针对多普勒雷达资料特点,以CS和BS模式相结合方式开发建设系统。数据管理科学规范,易于管理和共享、应用,为面向全区雷达资料的广泛应用奠定了基础。

(二)系统采用开放式网络环境、标准化协议以及通用系统开发工具,使系统具有良好的可移植性,易于实现和其他系统的互操作,有利于系统未来的发展。

(三)应用界面友好:用户只需要浏览器即可初步使用该资料,显示、浏览、查询、下载、使用方便,操作简单、明了。

参考文献:

篇6：基于数据抽取与订阅实现数据共享分析及研究论文

数据抽取用于将数据从源数据库装载到目标数据库中, 高效、安全、通用的数据抽取过程是信息整合的关键, 然而复杂的数据源和网络环境是数据抽取效率、安全性和通用性难以提高的瓶颈问题。目前有不少商业化ETL工具用以实现数据抽取, 比较有代表性的有Ascential Software公司的DataStage、Informatica公司的PowerCenter、NCR Teradate公司的ETL Automation等。这些工具各具特色, 但价格昂贵, 并且各数据源环境不同, 他们在信息整合时耗去了大量的时间和精力, 而结果却往往是令人失望的, 同时在开放性、安全性和集成性等方面也有待加强[1]。本文采用Web Services技术通过增加一个安全的、开放的、独立于原系统的数据代理层进行数据抽取, 实现了与几乎任何现有环境的集成, 而不必处理由不兼容的应用引入的复杂性;提出了一种全量数据抽取和增量数据抽取相结合以提高抽取效率的解决方案, 使得抽取过程更高效、安全、通用。

1数据抽取方法

数据抽取有两个过程:全量数据抽取和增量数据抽取。全量数据抽取过程用于数据请求者的数据初始化, 增量数据抽取过程用于数据初始化后的增量维护。

1.1 全量数据抽取

全量数据抽取是捕获特定时刻数据源快照的过程, 可以看成是相应数据源特定时刻的视图定义。一般在数据初始化装入或需重新完全更新一张数据表时, 使用全量数据抽取过程。

1.2 增量数据抽取

增量数据抽取是在全量数据抽取过程后对数据的修正, 数据源关系的改变而导致前一个数据抽取过程过期的操作包括插入、删除和更新[2]。考虑到对异构数据源环境和增量数据抽取的通用性, 本文所讨论的增量数据抽取采用触发器和时间戳相结合的方式进行的批量增量数据抽取。在数据源中建立触发器和增量表, 触发器对数据源的插入、删除和更新操作进行记录, 并将结果存储到增量表中;在增量表中增加时间戳, 记录数据源操作的时间。增量数据抽取过程只抽取增量表中的数据, 同时清空增量表, 完成增量更新。

设全量数据抽取过程的视图定义为v=rᐅᐊs, 增量表结构中需包含视图v的所有属性。设rc为关系r中发生变化的元组集, 增量表中新增的记录vc表示为:

$v{}_{\text{c}}=r{}_{\text{c}}⊳⊲s(1)$

设增量表关系为v′, 改变后的增量表vn表示为:

$v{}_{\text{n}}=v^{\prime }{\displaystyle \cup v}{}_{\text{c}}(2)$

根据式 (1) 和式 (2) 得到:

$v{}_{\text{n}}=v^{\prime }{\displaystyle \cup (}r{}_{\text{c}}⊳⊲s)(3)$

从式 (3) 看出, 当某个r或s关系发生插入、删除和更新操作时, 增量表只记录发生变化且经过关联运算的元组集。

增量表的结构不仅包含v的所有属性, 还应增加OPERATE_TYPE和OPERATE_TIME两个属性。数据请求者在进行数据加载时, 对增量数据与目标数据的关键字进行比较, 如果目标表包含增量数据的记录, 修改对应记录的属性值;否则, 在目标表中插入此条记录。所以在增量抽取过程中可以将插入和更新操作合并为更新操作。因此增量操作只分为删除和更新两类。OPERATE_TYPE属性用 “D”和“U”表示数据源的删除和更新操作;OPERATE_TIME属性记录数据变更的时间戳。由于在两个增量抽取过程之间, 同一源数据元组可能经过了多次操作, 也就在增量表中留有多条修改记录, 但最终的修改结果只有一个。如果在数据抽取之前不对增量表进行预处理, 将会引起数据装载的异常。增量表预处理算法描述如下:

S1:按增量表关键字分组 (增量表关键字为源关系关键字集合) ;

S2:从第一组开始, 选取一组;

S3:按时间戳先后顺序排序, 删除除最后一条记录以外的其他记录;

S4:重复S2步骤, 直到处理完所有的分组。

通过上面的操作, 增量表中只保留了变更元组修改的最后记录。也就是说, 增量表捕获到源数据表中同一关键字记录的最后操作。

与触发器和时间戳相结合的方式相比, 修改原系统代码方式成本高、实现难度大;很多数据库厂商虽然提供日志分析工具, 但只能捕获基本表的变化, 而不能捕获视图的变化, 因此日志文件方式不能实现复杂的增量数据抽取;快照比较方式需要多次大数据量比较, 执行效率低、浪费存储空间。触发器和时间戳相结合的方式可以在保持原数据库结构不变的基础上相对简单地捕获较为复杂的增量数据。

2系统结构

Web Services是广泛普及的、简单的和平台中立的[3]。基于Web Services数据抽取的系统结构, 包含数据代理和UDDI注册中心两部分。在应用系统的业务层之外增加一个数据代理层, 该层可直接访问数据源, 对外提供Web Services接口, 通过在公共UDDI注册, 允许其他数据 (服务) 请求者调用相应Web服务。每个数据代理既是数据 (服务) 提供者, 也是数据 (服务) 请求者。这种结构在不修改原业务系统的情况下, 屏蔽了数据源环境的异构性, 增强了数据抽取的通用性。

3服务安全

Web Services现在都是以HTTP作为数据传输协议, 但现有的HTTP安全机制 (如SSL) 只能保证点到点的安全, 不能保证节点内部的安全[4]。WS-Security在SOAP消息中嵌入用户名/密码、XML Signature、XML Encryption等安全技术, 实现消息端到端的安全, 保证SOAP消息通过不安全的中间节点, 安全可靠地从服务请求者到达服务提供者, 弥补了HTTP协议安全机制的不足。数据抽取的服务安全包含3个方面:身份认证、加密保护和访问权限检查。

3.1 身份认证

服务提供者在本系统为每一个服务请求者分配一个惟一的Service_ID, 并为每一个Service_ID分配一个密码。服务请求者将用户名 (Service_ID) /密码信息放入WS-Security报头中用以提供认证信息, 然后将WS-Security报头加入SOAP消息中。

3.2 加密保护

透明传输没有任何安全措施的WS-Security报头, 容易遭受各种安全攻击, 显然这样构建的Web Services应用没有任何安全性可言[5]。使用WS-Security创建一个安全的SOAP消息, 可以分为两个步骤:

(1) 数字签名WS-Security报头。将密码用MD5算法加密, 对加密后的密码值进行数字签名, 并将数字签名的算法和公钥同时放到报文头中发送给服务提供者。

(2) 加密SOAP消息的敏感数据。服务提供者向服务请求者发送数据时, 为防止信息泄露, 对SOAP消息中的敏感数据进行加密。服务提供者将对称加密的算法和密钥, 使用接收到的服务请求者的加密算法和公钥进行加密, 放到SOAP消息报文头中。

3.3 访问权限检查

访问权限检查的基础是访问权限控制列表, 访问权限控制列表记录了数据请求者能够操作的数据对象。具体字段域, 如表1所示。

访问权限控制表只实现数据对象消息的管理, 而不影响系统控制消息的传递, 如收到没有权限数据申请消息后, 反馈错误消息。

4数据抽取设计

数据抽取过程为提高数据抽取效率, 并行远程服务调用获得数据。具体步骤如图1所示。

S1:定义接口类, 并将服务发布注册到UDDI中。实现的接口类应至少有以下4个服务:

以上接口中, Service_ID为数据请求者惟一标识;password为数据请求者密码;DataObject为Server_id的数据请求者有权限操作的数据对象;StartNum为数据抽取的起始行;EndNum为数据抽取的结束行。

S2:数据请求者向UDDI提出获得WSDL描述文档的请求, UDDI向申请者返回WSDL文档;

S3:数据请求者根据WSDL描述, 向服务提供者发送一个经过数字签名的SOAP消息调用getDataColumn服务, 获得抽取数据的字段属性描述;

S4:数据提供者根据安全认证列表确认身份及权限, 并将数据生成XML文档, 以SOAP作为消息格式、HTTP作为传输协议传送给数据请求者;

S5:调用getDataCount服务, 获得抽取数据的行数;

S6:根据数据行数, 开启多个进程调用getAllData或getIncrementData服务, 通过设置不同的StartNum和EndNum参数, 将数据分块并行抽取。

5系统测试

使用Java语言实现原型系统, 并进行了全量数据抽取和增量数据抽取。在实验中, 除了并行测试全量数据抽取和增量数据抽取时间外, 还测试了非并行数据抽取的执行时间。分别抽取CustomerᐅᐊOrderA和CustomerᐅᐊOrderB两批记录集, 经过关联, 每个记录集有30个属性、1万条记录。并行数据抽取时, 按照进程和CPU为2∶1的比例设置并发进程数, 每个数据抽取进程抽取400条记录。实验最终数据采用两批记录抽取执行时间的平均值, 不开启并行操作的抽取时间为110 s;并行操作的抽取时间为76 s;增量抽取假定变化的记录为10% (1 000条) , 抽取时间时间为10 s。实验结果表明, 并行数据抽取速率高于非并行的数据抽取;当增量数据远小于全量数据的情况下, 用该解决方案得到的增量数据抽取执行时间要比全量数据抽取时间少。

6结语

本文给出了基于Web Services技术数据抽取的结构, 阐述了增量数据维护的原理, 并通过构建源数据触发器、时间戳、增量数据表及增量数据预处理算法实现了增量数据抽取方法。在此基础上, 实现了以WS-Security框架的SOAP消息安全策略、并行全量数据抽取和增量数据抽取的解决方案。本文在于提供了面向Web Services的异构数据集成中数据抽取的思想和解决方案。这种方法不仅有良好的通用性, 而且传输安全并能获得较高的效率。

参考文献

[1]周志逵, 徐先传.数据仓库中数据抽取、转换及加载工具研究[J].北京理工大学学报, 2003, 23 (6) :720-723.

[2]WILLIAM HInmon.数据仓库[M].王志海, 译.4版.北京:机械工业出版社, 2006.

[3]NEWCOMER Eric, LOMOV Greg.Understanding SOAwith web services[M].徐涵, 译.北京:电子工业出版社, 2006.

[4]石伟鹏, 杨小虎.基于SOAP协议的Web Service安全基础规范 (WS-Security) [J].计算机应用研究, 2003, 23 (2) :100-102.

[5]王凡, 李勇, 朗宝平, 等.基于WS-Security构筑安全的SOAP消息调用[J].计算机应用研究, 2004, 24 (4) :121-123.

[6]马建刚.面向大规模分布式计算发布订阅系统核心技术[J].软件学报, 2006, 17 (1) :134-137.

[7]BAUMGARTNER R, FLESCA S, GOTTLOB G.Visualweb information extraction with Lixto[C]∥Processing ofthe Very Large Data Bases (VLDB) .Roma, Italy:[s.n.], 2001:119-128.

[8]LI U Wei.A survey of deep web data integration[J].Chinese Journal of Computers, 2007, 30 (9) :1475-1489 (inChinese) .

[9]WANGJi-ying, LOCHOVSKY F.Data extraction and labelassignment for Web databases[C]//Proc.of the 12th Int.Confon.World Wide Web.New York:ACM, 2003:187-19.