高校数据中心走向集成

高校数据中心走向集成（精选7篇）

高校数据中心走向集成 篇1

1 引言

近年来, 随着互联网应用与信息化技术的快速发展, 高校的财务、教务、招生、后勤等各职能部门逐渐建立了相应的业务管理信息系统。各个信息系统的建设有效提高了办公效率, 促进了高校管理工作的规范化, 在高校改革发展中发挥了不可或缺的支撑作用。

随着校内各部门之间联动性的不断增强, “信息孤岛”的问题亦日渐突出, 各业务系统之间的数据不能充分共享与直接利用。如笔者所在的财务部门在学生学杂费管理工作中, 与教务、后勤等部门进行业务数据交换过程中, 常常会遇到数据传递不完整、不及时和重复维护等问题, 既影响数据的准确性, 也影响工作效率。

可见, 在高校“局部信息化”迈向“全面信息化”进程中, 焦点将逐步转移到业务的管理精细化和协同化, 信息集成和应用集成是大势所趋, 而在信息集成的过程中, 如何实现数据的集成无疑是重点。因此, 研究、构建适用于高校内部异构系统间的数据集成与交换平台则显得十分必要而有意义, 它是消除数据孤岛、实现各项业务数据有效交互的基础, 也为日后开展管理决策、建立门户信息服务打下坚实基础。

2 高校信息化的现状与问题

当前, 各高校信息化工作历经了“诺兰模型” (由美国哈佛大学教授查理·诺兰提出) 的初始、推广、控制阶段, 基本建成高速校园网, 高校各部门广泛地将信息系统应用在辅助教学、科研、行政等管理工作中。随着业务的深化和管理要求的提高, 现有信息化建设模式逐渐暴露出许多难以解决的问题和亟待突破的瓶颈, 主要体现在以下几个方面:

(1) 因缺乏统一规划, 不同时期建设的业务管理信息系统, 在技术平台、系统架构等方面都存在众多差异, 系统开放性、规范性和可扩展性均不可预料, 系统间横向协同的能力较差。

(2) 各业务管理信息系统建设时处于各自为政的状态, 缺乏统一的数据规范, 信息编码方式、数据的格式及数据的存储方式各异, 信息系统越建越多, 却逐渐陷入信息共享困难、数据无法有效集成的窘境。

(3) 信息维护的方式差异大, 不仅信息维护的途径和工具多种多样, 甚至许多业务仍然采用电子表格人工维护等方式, 数据的及时性、一致性和规范性均无法保证。需要应用这些信息和数据时, 往往出现不可靠、不可信或者不完整的情况, 校核这些数据又需要耗费巨大的工作量。

3 解决思路和步骤

针对高校信息化建设的现状和问题, 从尽可能保障现有业务正常开展、尽可能保护现有信息系统投资的角度出发, 必须构建面向异构数据的数据集成与交换平台, 以解决数据交互的难题;同时, 为了避免新建的信息系统重蹈覆辙, 还应逐步建立高校的信息化建设标准, 指导将来的信息系统建设。

(1) 建立高校信息化标准体系, 包括基础设施建设、信息编码规范、系统接口规范、信息系统建设框架等标准规范。对于新建的信息系统, 要求必须依照统一的高校信息系统建设规范, 从技术架构、数据架构和应用架构上确保有规划地建设;对于现已建成的信息系统, 遵照信息编码规范重新梳理信息编码, 在统一的系统接口规范下, 建设适配接口, 为数据交换与信息共享提供基础。

(2) 构建高校数据集成与交换平台, 用于高校内各信息系统数据的抽取、汇聚、清理、转换和交换;通过搭建数据总线和服务总线, 为各信息系统的数据交互打通渠道。在构建数据集成与交换平台时, 除了提供数据交换功能外, 还必须建立数据质量管理的机制, 确保平台数据的权威性和可信度。

(3) 为保障数据集成与交换平台的正常运行, 还应建立配套基础设施和管理制度, 包括:网络规划和硬件资源、安全防护、运行维护管理等。

4 平台建设的重点

4.1 高校信息化标准体系建设

信息化标准体系的建设是一个长期的过程, 需要各业务部门密切配合、持续完善才能起到实效。各项标准与规范主要包括基础设施的规范要求、应用系统建设的规范要求、信息编码的规范要求以及面向用户的交互规范要求等。在构建标准体系的过程中, 也可参考IT行业和软件工程的相关标准, 结合自身的业务特点, 形成符合高校信息化建设实际要求的标准规范。

(1) 开展业务流程调查, 结合校内各业务流程和数据产生特点, 编制各项业务的数据字典。若已有信息系统, 则需按规范格式提供数据, 为数据交换提供统一的依据。

(2) 信息编码规范设计。针对公共的数据集成与交换平台, 从整个高校的角度出发, 为公共的数据编制统一的信息编码, 避免多个业务系统之间“同物异码、同码异物”的情况。

(3) 建立数据交换标准。采用Web Service、XML作为数据传输的标准, 协助各业务部门建立数据传输与数据交换规范, 实现不同的业务数据之间的交互基础, 并且充分考虑扩展性。

(4) 建立信息系统的文档数据规范。各业务信息系统必须依据文档数据规范出具系统建设的过程文档, 对非结构化的数据要提供交互、检索的基础依据。

4.2 数据集成与交换平台的实现

4.2.1 数据集成与交换平台框架

数据集成与交换平台的框架结构如图1所示:

如图1所示, 各业务信息系统处于数据来源层 (数据提供层) , 基于信息系统的数据接入要求, 在适配层建立统一、规范的数据适配接口, 将各业务信息系统的数据抽取到数据交换层的临时数据存储区和操作数据存储区;操作数据存储区经过转换、清理, 成为正则的数据存放到数据仓库中, 此时已经将冗余的数据剔除。最后, 针对数据访问层, 即业务应用层的需求, 构建不同业务主题的数据集市, 将数据提供给各项业务, 实现数据的交换与共享。

4.2.2 数据适配接口的实现

数据适配接口主要采用Web Service的方式, 通过统一的数据规范, 以XML为载体, 实现多个业务系统之间的数据适配。在这个过程中, 特别强调交互数据格式的统一性和规范性, 数据来源层中的各业务系统在提供数据时, 必须遵循这个交互的规范。接口开发主要涉及XML、XSD、Web Service、SOAP、WSDL等关键技术。

XML即可扩展标记语言, 它使用一系列简单的标记描述数据, 是互联网环境中跨平台、依赖于内容的技术, 是一种处理结构化文档信息的有力工具。在高校数据集成与交换平台中应用XML技术, 在制定基于XML交换的规范和标准基础上, 可通过统一数据接口将各类数据源转化成XML格式, 以便与不同的信息系统实现数据交换。另外, 平台提供XML到XML的映射转换工具, 实现不同的业务系统之间的数据映射与格式转换。

XSD定义了一套标准数据类型, 并给出语言扩展该数据类型。Web Service平台即采用XSD作为其数据类型系统。当用某种语言, 例如C#来构造Web Service时, 为符合Web Service标准。使用的数据类型必须转换为XSD类型。

Web Service (Web服务) 是开放的基于因特网标准, 具有松散藕合、可重用、可编程访问、自适应和自描述等特质的Web组件。它具有模块化、良好描述、实现独立、可访问性和互操作性好等优势。Web服务由WSDL、SOAP和UDDI三个基本结构单元组成, 它们解决了Web服务的描述、通信和发布等基本问题, 是构建Web服务的核心与基础。Web服务协议栈进一步对Web服务的互操作、路由、安全和服务质量等进行了规范。

SOAP (简单对象访问协议) 基于XML和XSD, XML是SOAP数据编码方式。SOAP提供类似XML的能通过HTTP描绘参数和返回数值的方法, 可运行在任何传输协议上。

WSDL (Web Service描述语言) 能用机器阅读方式提供的正式描述文档, 用于描述Web Service及其函数、参数和返回值。因基于XML, 所以人可阅读。

4.2.3 数据存储结构

交换数据临时存储区是用来保证数据交换过程中安全隔离和临时存储的存储区。该存储区按业务系统创建, 负责临时存放从各业务系统采集上来的数据, 在数据采集策略上, 一般采用先删除后新增的更新方式, 不保存历史数据;若有特殊的要求时, 也可将历史数据做短期暂留。

操作型数据存储区存放集成的、可更新的、近实时的业务数据。主要用于交换数据临时存储区的明细数据整合后、导出数据文件进入数据交换区前的存储。操作型数据存储区按业务主题创建, 按查询需求保存一段时间内的数据, 可新增、删除、修改。

4.2.4 数据抽取 (ETL) 和转换

ETL是数据抽取 (Extract) 、转换 (Transform) 、清洗 (Cleansing) 、装载 (Load) 的过程, 是构建数据仓库的重要一环, 它直接通过内部机制把根据用户需求从数据源 (关系数据库、平面数据文件等) 抽取出的所需数据, 经过数据清洗, 最终按照预先定义好的数据模型, 将数据加载到目的数据库中去。数据集成与交换平台的开发工作可以直接面向这个数据库进行开发, 开发者可以很方便地利用该数据库的优越特性进行性能上的优化, 或者数据结构的调整, 从而不影响到底层的业务系统的数据。ETL还应具有丰富、灵活的数据转换策略, 能够把底层的数据库数据重新转变成更符合业务逻辑的数据。具备数据采集流程控制, 提供管理监控流程的措施, 使得数据从来源端到目的端的传输有条不紊地运行。

在数据采集过程中, 因ETL的实时性相对较弱, 需要使用ETL工具自身的一些采集机制定时到各数据源中获取数据, 以实现数据的同步。数据采集的过程中应能够分不同的时间颗粒度, 如按小时、分钟、日、月、年采集不同数据库的数据。在自行定制的ETL工具中也可具备更好的同步机制, 其“复制”的机制能够分时段同步指定范围的数据, 源端数据的改动能够快速地反映到目的数据库中。

数据转换机制方面, 实现映射的手段通常有三种。第一种是数据源直接映射, 它是指按照源数据库的原始结构采集进入数据集成与交换平台的数据库, 与源数据库的结构完全保持一致。此种手段是最简单的映射手段。第二种是数据源策略转换映射。这种方式完全改变源数据库的结构, 反映在数据集成与交换平台上的数据结构是全新的数据结构, 利用ETL工具的各种策略把源数据库的数据进行转化, 产生新数据体, 并存储进入数据库。第三种是上述两种方式的融合, 即:该映像除了包含与源数据库一致的结构外, 还加入了经过策略算法形成的新结构。例如:两表间的数据合并、表格式的转置等, 此种映射手段将随着数据集成应用的逐渐深入而变得日益广泛。尤其是在为数据集成与交换平台提供综合报表分析的时候, 采用这样的手段会越来越多。

根据ETL的特点可知, 对于海量的数据挖掘, ETL优势极为明显, 它可以为历史数据的分析工作提供更佳的底层数据基础。

4.2.5 数据清理

数据清理是ETL的一个重要内容, 该环节负责把冗余数据、不规范数据实现规范化, 保证数据的正确性、完整性、一致性、完备性、有效性、时效性和可获取性。

4.3 数据质量管理和评估

数据质量管理是采用科学的方法, 对数据集成与交换平台中存储数据的准确性进行判断, 对存在的数据质量问题进行核实, 并最终确认的过程。数据质量是数据集成应用的“生命线”, 质量差的数据即便可以共享, 也达不到预期目标, 所以在建立数据交换平台时, 必须时刻将数据质量摆在第一位。在数据交换过程中, 通过数据质量评估, 及时掌握各类数据的可靠程度或差错率的大小, 系统查找影响数据质量的因素, 并有针对性地采取措施, 持续提高数据质量。对于具体数据的质量检查模式可采用以下几种方法:

(1) 记录数检查法。通过比较记录条数, 对数据情况进行概括性验证, 主要是检查数据表的记录数是否为确定的数值或在确定的范围内。这个方法的适用范围是:对于数据表中按日期进行增量加载的数据, 每个加载周期递增的记录数为常数值或可以确定的范围时, 必须进行记录条数检验。

(2) 关键指标总量验证法。对于关键指标, 对比数据总量是否一致。指标总量主要是指具有相同业务含义, 从不同维度统计汇总逻辑的检查, 适用范围包括:同表内对同个字段从不同的维度进行统计, 存在汇总关系时, 必须进行总量检验。例如:某表的字段与其它表中的字段具有相同的业务含义, 从不同的维度统计, 存在汇总关系, 且两张表的数据不是经同一数据源加工得到。满足此条件时必须进行总量检验。

(3) 历史数据对比法。通过历史数据观察数据变化规律, 从而验证数据质量, 通常以同比发展速度进行判断。评估时应根据各种指标发展特点, 重点对同比发展速度增幅 (或降幅) 较大的数据进行审核。历史数据对比法包括同比和环比两种方式。历史数据对比法的适用范围是:不能进行记录数检查法、关键指标总量验证法, 且事实表的记录数小于1000万条时必须进行历史数据对比法。

(4) 值域判断法。确定一定时期内指标数据合理的变动区间, 对区间外的数据进行重点审核。其中数据的合理变动区间范围是直接根据业务经验来确定的。当事实表中的字段可以确定取值范围、同时可以判定不在此范围内的数据必定是错误的, 满足此条件必须进行值域判断法。

(5) 经验审核法。针对报表中指标间逻辑关系仅靠计算机程序审核无法确认、量化, 或有些审核虽设定数量界限, 但界限较宽不好判定的情况, 需要增加人工经验审核。适用范围:以上方法都不适用的情况下, 可以使用经验审核法, 在计算机自动校核的基础上, 由人工聚焦某些问题数据进行审核。

(6) 匹配判断法。与相关部门提供或发布的有关数据进行对比验证。适用范围:与有相关部门提供或发布的有关数据口径一致的, 可以使用匹配判断法。匹配判断后, 应当具备经验累积机制, 在确立某个数据口径为标准后, 自动遵循该项规则。

数据质量是一个长期性的问题, 要解决这个问题, 除了技术手段保障外, 还是必须从产生数据的源头抓起。根据经验, 70%的数据质量问题都是由用户输入产生的。因此, 在信息系统建设过程中要规范用户的使用方式, 保证数据的录入是按照定义的标准流程和方式进行维护;其次, 系统要严谨的对各数据项进行约束, 按照规范要求设计, 保证关联数据的一致性。

4.4 配套基础设施和管理制度

数据集成与交换平台的建设, 还可参考以下几个工作要点:

(1) 按照“科学规划, 合理布局”的原则有序建设高校网络。根据不同时期的信息化需求, 充分考虑业务量、数据量和应用增长情况, 配备适当的硬件设施, 为避免初期投入过大造成浪费, 可根据数据和业务的实际增长量, 分步持续扩充。在系统硬件设施规划方面, 要以保障系统的可用率和可靠性为出发点, 充分考虑关键设备的冗余, 避免单点故障带来的影响。

(2) 为高校各业务管理信息系统制定配套的系统运行维护管理规范, 主要包括网络、设备、数据、软件维护要求以及机房管理、运维质量管理要求等管理规范。通过IT运行维护流程的规范化管理, 不断提高系统运行保障能力, 保证高可用的平台环境。在日常管理的过程中, 还应编制配套的应急预案, 定期演练, 以应对突发的故障。

(3) 制定高校信息系统安全保障措施, 抵御外部对高校信息系统资源的非法的访问和使用, 保证高校信息系统的软、硬件和数据不因偶然或人为因素而遭受破坏、泄露、修改或复制, 确保信息安全。一是在管理层面, 明确高校信息化工作的职责与分工, 成立相应的领导工作机构, 制定信息系统安全管理制度, 利用行政管理防止安全事故的发生。二是在技术层面, 通过采取各种相应的技术手段, 包括防火墙技术、数据加密技术、身份认证技术、访问控制技术、漏洞检测、数据存储、数据备份和安全恢复等;保障网络环境、应用系统、通信环境的安全性。

(4) 针对高校数据交换和信息系统应用的特点, 配套建设数据集成与交换平台的运行管理工具, 例如监测平台数据通道的健康状况、平台运行日志的主动分析等功能, 增加平台运行的健壮性, 也为持续的运行维护带来便利, 节省人工成本。

5 结语

综上所述, 在建立高校信息化标准体系的基础上, 构建面向异构数据的高校数据集成与交换平台, 对数据质量进行管理与评估, 将从根本上解决数据质量差, 数据交互难的问题, 逐步实现高校数据资源共享与应用集成, 对高校自身发展及进一步推动教育信息化发挥积极作用。显而易见, 高校数据集成与交换平台建设是一项复杂、长期的系统工程, 而随着高校事业的不断发展及信息领域新技术的不断涌现, 平台建设势必也是一个动态、变化、发展的过程。本文提出的高校数据集成与交换平台建设方案, 需在实际运行和服务实践中不断完善升级, 最终形成一个高效、标准的, 能充分满足高校信息化工作需要的数据集成与交换平台。

参考文献

[1]黄松.基于诺兰模型的高校信息化建设趋势分析与展望[J].江汉大学学报:自然科学版, 2013, (1) :71-75.

[2]李幼军, 张广庆, 刘炳兴.高校信息化建设中信息标准的确立及应用[J].计算机时代, 2008, (10) :66-68.

[3]胡致涌.基于信息整合的数据中心平台的研究[J].制造业自动化, 2011, 33 (18) :69-71.

[4]高江锦.基于XML和Web Service的高校数据交换平台设计[J].软件导刊, 2012, 11 (8) :141-143.

高校数据中心走向集成 篇2

目前,随着信息技术的不断深入以及高校改革的深化,数字化校园建设迫在眉睫。然而,在高校的信息化建设过程中,现有的教育信息资源管理系统都是“应需式”的软件开发,如教务管理系统、学籍管理系统、实验室预约系统以及OA办公系统等。其开发工具、数据库的异构及系统模块间的紧耦合导致了软件之间数据的不连通性,并形成了一个个的“数据孤岛”。消除“数据孤岛”并对各种不同数据源的异构数据进行共享和访问已成为制约高校信息化建设的瓶颈。面向服务的体系架构(SOA)作为一种新兴的软件架构思想为解决此类问题提供了良好的方案。[1]

作为SOA的三大核心技术(SCA、SDO和DAS)之一,服务数据对象(SDO)最先是由IBM和BEA公司提出。SDO是一种规范各种数据源类型中的数据编程的编程模型,它可以对常见应用模式进行有力的支持,并允许应用程序、工具和框架快速的查询、绑定、更新并内省数据。虽然Java2平台和Java EE提供了大量的数据编程模型和应用程序接口,但是这些技术都是分散的,往往不能服从于工具和框架。并且其中的一些技术难以使用,功能亦不够丰富,无法支持常见的应用需求。SDO旨在创建一个统一的数据访问层,以一种可以服从工具和框架的简易方式为高校数据集成平台提供一种数据访问解决方案。[2]

1 SDO相关技术分析

SDO为各数据源运用了对应用程序数据的统一访问和公共编程模型,而不管数据存储在何地以及如何存储。SDO采纳了XML的简易操作的特性,摒弃了XML模式语言的复杂性或序列化的问题。同时通过使用服务数据对象,可以从业务逻辑中将系统编程分离开来,且将其封装在可重用的服务中,而无须所有编程人员都掌握这些技能。在未陷入技术及实现细节的情况下简化业务应用程序的编程,防止技术改变产生的不良影响。有了服务数据对象,业务应用程序即为名副其实的业务应用程序。SDO主要包含三个组成部分:[3]

(1)异构数据源:异构数据源以不同的格式保存数据。只有数据访问服务访问各异构数据源,SDO应用程序并不直接访问异构数据源。SDO应用程序只使用数据图中的数据对象。[4]

(2)数据访问服务(DAS):数据访问服务负责从各异构数据源生成数据图,并依据数据图的变化更新各异构数据源。

(3)SDO客户机:SDO客户机使用SDO框架处理各种数据。SDO客户机使用的不是特定于技术的应用程序接口和框架,而是SDO编程模型和API。SDO客户机处理SDO数据图,不需要了解所处理的数据是如何持久保存或者序列化的。

2 SDO在高校数据集成平台的应用

2.1 高校数据集成平台的设计研究

系统的开发、运行需要相应的软硬件环境,这是系统实现的基础。本系统采用B/S结构,基于MVC模式开发。

2.1.1 J2EE框架———MVC

模型—视图—控制结构是目前最常见J2EE应用所基于的体系结构,MVC主要适用于交互式的Web应用,尤其是存在大量页面及多次客户访问及数据显示;相比而言,一个工作流体系结构更多应用于过程控制和较少交互的情况下;除了体系结构外,J2EE的设计模式同样很适合于解决应用系统的设计。

2.1.2 集成开发环境———Net Beans6.0

Net Beans是Sun推出的开放源代码的集成开发环境(IDE)。它是一个纯Java实现的开发工具,可运行在任何支持Java2的平台上。Net Beans具有标准化、模块化的特点,它的很多功能都是以模块的形式挂载在内核上实现的。任何第三方开发者都可以遵循Net Beans的标准插入自己的模块以扩展NetBeans的功能或者去除一些不需要的模块来定制自己的Net Beans。Net Beans除具有IDE的基本功能如:编辑、调试、语法彩色与错误高亮显示、项目管理等之外,还提供了方便的模块插入功能与界面定制功能,为用户提供一个方便快捷的开发环境。NetBeans是一个外挂式的IDE,需要外接编译器、调试器来支持程序编译与调试。因此Net Beans支持多种语言的开发,如Java、C++等。

2.1.3 应用服务器———Tomcat 6.0

Tomcat是一种有JSP环境的Servlet的容器。Servlet容器是代替用户管理和调用Servlet的运行时外壳。

高校数据集成平台的设计包含两个关键因素:应用的整合和数据的集成。其中,数据的集成是高校数据集成平台中最为重要的问题。功能流程如图一所示。

2.2 SDO在高校数据集成平台的应用实现

学校IT架构中现有多个运行的软件系统,由于学校发展历史的原因,各个部门系统的开发与运行是分阶段孤立进行的。然而随着学校规模的不断壮大以及办学理念的变迁,各软件系统间的许多应用又存在相互交叉的联系,这就导致了现行各系统间的互不连通性,高校各业务部门间的数据不能实现高效的访问和利用,数据之间的更新也不能及时反馈。例如:教务管理系统使用的是Micro Soft SQL Server数据库,而学工部门使用的是MyS QL数据库。最初,各职能部门间的信息无法得到传递,因为两种后台数据库所使用的操作语言不尽相同。随着数据库技术的不断发展,主要通过XML数据交换技术实现了异构数据库间的数据交换。在本文中,通过使用SDO规范及数据访问服务,可以更方便高效的对异构数据库进行访问,从而真正的实现业务与数据的分离。

在客户端,用户可通过Web浏览器向异构数据库系统发送数据操作命令,如查询、修改和删除等。客户端则根据各操作命令自动到数据库操作模块去匹配相对应的服务模块,这里的服务模块是指图一所示数据库操作模块中的命令,即查询命令—查询服务模块(包含所有底层服务中的数据查询操作);添加命令—添加服务模块(包含所有底层服务中的数据添加操作)。然后数据库操作模块根据客户端传递来的用户输入参数,分析该对其中何种异构数据源进行操作,根据其分析结果,调用相应的底层服务,即底层异构数据源所提供的服务,对异构数据源进行具体的操作。数据操作结果由底层异构数据源通过服务数据对象及数据库操作模块传送到客户端,按照用户需要的方式反馈给访问者。

3 结束语

SOA架构思想是未来发展的趋势,设计基于SDO的高校数据集成平台,以期整合学校现有的软件系统,实现对学校各种教育资源的统一、规范化管理。通过分析数据集成平台所实现的功能,对系统的数据模型进行分析和设计。

为了解决高校数据集成平台涉及到的数据异构、不统一以及对异构数据源进行操作的问题,提出了基于服务数据对象模型的异构数据集成的策略。设计基于SDO的编程模型,为服务和应用提供一个统一的数据模型,通过服务数据对象模型,实例化用户输入的信息并保存在其对应的SDO数据图中,然后按照用户的要求对SDO实例中的数据图进行相关操作,并通过数据访问服务连接相应的数据源,结合数据图中的更改摘要,对数据源进行相应的增、删、改、查操作,最后将操作后的数据更新到数据源中。

参考文献

[1](美)Thomas Erl,著.王满红,陈荣华,译.SOA概念、技术与设计[M].北京:机械工业出版社,2007.

[2]王滨,黄永锋,许晓东.基于SOA的应用程序框架研究与实现[J].计算机工程与设计,2006,27(07):1198-1200,1207.

[3]王迪.IBM提升在SOA领域的地位[J].世界电信,2004,17(06):61-61.

高校数据中心走向集成 篇3

关键词：数据精简,数据整合,共享池

0引言

高校数据集成是目前高校信息共享工程中的一个核心的构成,而信息集成前的异构数据含有大量冗余数据,这些冗余数据在数据库中以重复字段的形式存在, 重复数据直接影响数据的质量,进而影响到信息决策的准确性和成本的投入量。 本文以高校信息系统的数据库属性级、记录级的脏数据为研究对象,展开研究并提出了一套建立数据精简整合系统的范式。

1相关工作

范式是符合某一种级别的关系模式的集合, 在本文中 “范式” 指的是数据集成过程中对异构数据库中的冗余数据进行精简的处理流程、逻辑顺序和处理对象的关系集合。 目前国内外对数据库的数据精简范式的研究较少, 主要着眼于数据精简算法的效率和复杂度的优化,相关技术主要涉及以下几个方面。

1.1 单表数据库的数据精简算法研究

目前的研究主要针对单数据源进行, 采用统计方法来对单一数据库内的记录检测数值型数据的属性, 通过对字段值的均值和标准差, 并设置每个字段的置信区间来识别异常字段和记录。 主要集中于算法的研究上。 缺少对多数据源环境下的数据精简和整合, 而高校信息集成系统的数据必然是来自于多数据源的,因此本文将单数据源去重算法应用于多数据源,并将精简的结果汇集到共享库,以满足高校数据集成环境下的应用需求。

由于多表精简还涉及字段之间的对应, 已有方案是手动对字段进行匹配,工作量大且容易出错,因此本文引入了SOM-BP网络在预处理结束后对各个异构库之间的相似字段进行自动匹配,提高了工作效率。

1.2 特定领域的数据精简

不少数据精简方案和算法都是针对特定应用问题的, 例如在求取相似度算法中的递归的字段匹配算法, 与应用领域密切相关,只适用于较小的范围。 在复制记录检测中的SNM(排序邻居算法)中,需要抽取键值进行排序,如果键值包含错误,排序的结果将不如人意,进而影响到复制记录检测的效果,当前的工作中通用的、与应用领域无关的算法和方案较少。 所以本文探讨使用二步聚类法:第一步粗聚类,采用倒排检索方法和TF-IDF算法求相似度进行,第二步为精确聚类,采用编辑距离算法求取相似度,并用Canopy聚类技术进行记录配对。 由于倒排检索方法的粗聚类不需要抽取键值进行排序, 而是把整个数据记录看成文本,所以避免了键值抽取不当带来的排序误差。

2数据精简整合系统范式建立的步骤

2.1业务理解

业务理解指的是从业务角度理解数据精简的目的和需求。主要任务是把项目的目标和需求转化为一个数据精简问题的定义和实现这些目标的初步计划。 这一阶段包含的一般性任务如下:

2.1.1 确定业务对象

即系统的处理对象是什么,对于本项目而言,业务对象是高校信息管理系统中的脏数据, 这些脏数据包括了数据库中的属性级的不一致、不完整和错误数据及重复数据。

2.1.2 评估环境

指的是对数据精简应用场景, 包括软件和硬件两方面的资源、约束、假设和其他因素进行详细分析和评估,以便下一步确定数据目标分析和项目计划。

2.1.3 确定数据精简目标

对于本项目而言, 数据精简的目标是对高校异构数据库中的重复记录、重复属性进行去冗余。 使得校园信息系统的运转效率提高,节约资源占用。

2.2 数据理解

数据理解是对数据精简所需数据的全面调查。 它包括以下步骤:

2.2.1 收集原始数据

对于本方案而言数据精简系统的处理对象根据其粒度区分可以分为两个方面,一是属性级的脏数据,即来自各个异构数据库中的字段和属性值, 异构数据库根据其平台的不同可以分为Oracle、SQL Server等。 一个是记录级的脏数据,记录由属于不同字段的属性值所构成。 其他包括所需要整合到共享池中的所有异构库的数据源格式、拥有者、存储方式、字节数、物理存储方式、隐私需求等。

2.2.2 描述数据

调查各个异构数据库中的所有字段, 包括其数据类型、长度、是否为空、精度、小数位数、标准差。 这些参数归一化后将作为字段自动匹配计算的指标。

2.2.3 检验数据质量

这一步骤主要是检查数据是否满足数据精简的需求。 例如数据中空值的多少,错误率的高低,过多空值和高错误率的数据不可用。

2.3 建立模型

确立精简系统的输入和输出,以及实现这些输入、输出的模块和顺序。 对于本系统而言,输入是异构数据库的脏数据,输出就是精简系统对脏数据进行处理后的输出的干净数据。 这些干净数据应具有如下特征:

(1)共享库中的记录应是完全没有重复的。

(2)共享库中的字段是完全无重复的。

(3)共享库的数据结构应该是标准化的,能够提供给校园网中的各个子系统作为共享资源。

2.4 评价

对数据精简的效率和成果进行评估。 数据精简系统的评价标准包括了用召回率和查准率对数据精简的结果和传统的精简模型进行比较检验。

3高校信息系统共享池的精简框架

目前在高校的信息系统应用中兴起了数据集成的热潮,所谓的数据集成,就是把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中,使这些异构信息在共享池中存放,从而为高校提供全面的数据共享。 共享池与各个异构数据库间的关系如图1 所示。

我校的信息集成系统是以共享池作为信息集成和共享的中介,各个部门的异构数据库的数据在共享池中汇集,完成字段和记录的重组。 共享池的建立首先要经历的步骤是对遗留数据的清洗,将有价值的信息保存在共享池中,数据清洗的步骤也包括了数据精简,使共享池中的每一条记录都具有唯一性。 第二步才是将原先各个系统的以各自信息资源库为存储对象转换为以共享库为存储对象,也就是在共享池建立之后,所有部门都将这个共享池作为数据源,各个部门不再拥有各自的独立数据源。

数据集成中存在的问题就是脏数据的困扰, 所谓脏数据就是不一致或不准确数据、 不完整数据以及人为造成的错误数据以及冗余数据等。 具体的按照脏数据的粒度粗细,可以分为属性级和记录级两个层面,属性级的脏数据包括空缺值、噪音值和不一致值,记录级的脏数据主要是指重复记录,重复记录指的是那些客观上表示现实世界同一实体的,但是由于在格式、拼写上有些差异而导致数据库管理系统不能正确识别的记录。 数据精简就是对属性级和记录级脏数据进行处理, 纠正可以纠正错误的数据,补充遗漏的数据,将不一致的数据统一格式,去除数据仓库中冗余的记录,从而得到数据共享池所需要的数据集合。

如图2 所示为高校信息集成精简环境下的精简系统的框架结构,它大致可以分为预处理、表内数据精简、异构数据库的字段匹配、记录级精简这4 个环节,下面分别介绍。

3.1 预处理

预处理目的是在进行记录级精简之前对记录中的空白值、异常值和不一致值进行处理, 这些脏数据可能会对求取相似度和匹配的运算造成负面影响。 由于这些处理主要是针对各个记录中的具体属性值的, 所以也称为属性级精简以区别于记录级精简。

3.1.1 空白值的处理

在数据输入的时候, 可能由于漏输入的原因导致有的字段属性值为空。 这些空值必须被填充才参与后续的匹配度计算。 所以我们可以采用最接近空白值的值来替代空白值, 本文采用聚类法的方式对空白值求取近似值。

1首先对原始数据集进行数据筛选: 剔除具有较多缺失数据的属性,因为这样的属性作为后续的匹配依据是不合适的。 并且将有较多缺失值的记录提交给用户, 让用户手工对这些数据进行处理, 因为具有较多缺失值的记录使用算法处理可能产生较大误差。 2将原始数据集分为完整数据集Dc和不完整数据集Di。 3对完整数据集使用CANOPY算法进行聚类, 产生K个聚类。 4计算不完整数据集Di中每条记录和Dc中的K个聚类重心的相似度, 将Di中的记录赋予距离该记录最近的那个重心所属的聚类, 并且用该聚类的均值或出现频率最高的值来填充该记录的空白值。 如果无法填充该记录则对此记录进行删除。

对于数值型数据,空白值取距离最近的那个聚类的平均值,Ai为该空白值最接近的聚类的所有成员,n为该聚类的成员总数。 当空白值为离散型数据时,空白值取最接近的聚类的出现频率最高的成员值。

5最终将经过填充后的Di′和完整数据集Dc整合为新的完整数据集。

3.1.2 异常值的处理

记录中可能存在姓名在输入的时候的拼写错误, 属于异常值。 这里用一个包含完全正确的数据的外部文件来作为判别依据。

由于高校管理信息系统中,一般记录都包含有学号,而学号具有唯一性,所以,我们可以将学号作为主键,也就是以学号为依据与外部文件进行对比。 1对于在数据库中有的学号,在外部文件中找不到,将记录提交给用户判断处理。 2对于字段的键值间对应关系和外部文件中的对应关系有出入的,采用领域权值的方式计算数据表记录与外部文件记录的相似度。 如果相似度大于等于阈值则认定数据库记录和外部文件记录是同一个实体,用外部文件记录替代数据库记录。 如果低于阈值,则提交用户判断处理, 判断是否应该采用外部文件的属性值进行替换或者保留原值。 领域相似度用编辑距离算法得出。

3.1.3 不一致值的处理

不一致数据是指由于系统和应用的不同在数据类型、格式、粒度和编码方式上的不同。本文中这部分工作由一个标准化字符集转换完成,将各个异构库中的属性值转换为标准的字符集,以便于后续的相似属性、相似字段的比较。例如有的异构数据库中的“男”“女”用“M”“F”表示,有的用“man”“woman”表示,我们可以通过标准化信息标准将这些代码转换为“1”“0”表示。这样做的好处是方便后续的字段相似度比较和记录相似度的比较。另外,如果万一后期各个异构数据库中对这些字段属性值有新的表达方式,也可以通过这个映射表变更映射关系很容易地实现键值定义的转换。

3.2 表内数据精简

由于在各个异构数据库的内部可能存在有大量的重复实体记录, 这些实体记录在后续的表间记录匹配合并的工作中可能带来困难。 所以需要对各个异构数据库各自的数据进一步的精简以去冗余。

把整个数据记录看成文本,采用倒排检索方法,粗糙、快速地把数据分成一些重叠的子集,称为Canopy。 然后是一个更严格的阶段,这个阶段对Canopy内的点用精确的计算方法进行再次聚类。

最后,按照一定规则对相似记录进行剔除或保留。

3.3异构数据库的字段匹配

在经过前面的表内数据精简后,各个异构数据库中的数据已经具备了可以进行相似度运算的条件,接下来的工作是用SOM(Self-organizing feature Map,自组织特征映射)-BP(Back Propagation,前馈)网络对各个异构数据库中的字段建立匹配关系。

如图3 所示,SOM-BP网络的作用主要是对异构数据库数据表中的相似字段进行匹配,提供给共享池,作为共享池字段。这个过程的步骤包括:

1从异构数据库中抽取属性的特征向量, 包括数据模式和数据内容统计。 特征向量就是如属性值的数据类型、长度、是否为空、精度、小数位数、标准差这些参数。 这些特征向量将作为SOM-BP网络运算匹配度的参数。 2将特征向量归一化。 3建立SOM网络模型,将属性特征向量进行分类,分为M类。 4 建立BP属性匹配模型,用样本数据库对SOM分类后的每一类别(共M个类别)进行训练直至收敛,保存BP网络权值和阈值,建立M个BP网络模型。 5同样,目标库数据通过123步骤完成输入向量分类,分为M类,将分M类后的数据对应M个BP网络进行模拟,完成相似度匹配。6将完成匹配的数据库属性按照匹配的结果在共享数据库中添加“表名”“库名”字段,使匹配工作中被识别为同一属性的异构属性能够实现快速对应。 7将上述完成匹配的字段匹配情况作为后续求记录相似度的特征字段选择依据。

从表1 我们看到, 当各异构库中的字段被SOM-BP网络发现相似的时候,这个匹配结果将提交给人工,由人工选择保留哪个数据源作为共享池中的字段,当字段没被发现匹配对象,即这个字段为唯一字段时,将此字段作为共享池中的字段。

3.4 记录级精简

在上一步确定在共享池中需要保留的字段之后, 接下来是将各个异构库中存在的相同实体记录进行精简, 保留唯一实体记录存入共享池,使得共享池中的记录都属于完全不同的实体。

3.4.1字段选择

字段选择的目的是作为进行相似度比较的记录的标识,一个记录可能包含有许多相似属性, 我们不能全部作为比较的内容,必须对其进行选择。 考虑特征字段,应考虑进行比较的两个异构数据库中都有的语义相同的字段,如字段“ID”和“XH”都指的是学号,还要考虑到字段的“重要性”,在记录与记录之间区别越大的字段属性值越能够更好的标识一个记录。 例如,“学号”字段比“性别”字段能更好的标识记录,因为相对于比较“性别”字共享池中字段段,“学号”字段的取值更能够唯一地标识一个记录。 综上所述特征字段选择的依据包括:

1SOM-BP匹配的结果。 我们要对异构数据库记录进行比较首先要找到在两个数据库中都存在的能够比较的属性值,前期SOM-BP网络已经得出异构数据库间的字段匹配结果, 例如XH和ID都指的是 “学号”这一属性。 所以教务处表中的XH和学工处表中的ID这一对就可以选为教务处表—学工处表要进行记录匹配的特征字段。 2字段排序的结果:对字段属性的值域进行统计,值域越大的字段,说明其属性值越多,更具有区分性。从属性值值域由高到低对字段进行排序的结果: 选择前k个属性组成属性集。 后续的相似度计算就针对这k个字段进行。

3.4.2 粗聚类

粗聚类是将字段聚类形成Canopy簇, 图4 中V1m表示A属性值粗聚类后的聚类集合,V2m表示A’属性簇聚类后形成的聚类集合。

第一阶段粗聚类,对于案例中的数据库D1 和D2 而言,首先抽取若干特征字段来表征不同的记录,建立表L1 和L2,并定义相似距离阈值H1>=H2。 将L1 和L2 融合成为一个整体的表L,接下来借用信息检索中倒排检索方法,采用基于TF-IDF相似度的计算方法来计算记录与记录之间的相似度, 选取与相似距离小于等于H1 的(d,d’)放到一个Canopy中,之后从中心点列表中删除已经使用过的中心点d和与d点相似距离小于H2 的点d’…… 如此反复,直到中心点列表为空集,停止操作。 最后得到的是诸多围绕各个中心点d的d’的集合(Canopyi)。 这样的粗聚类对大数据集特别有效,减少了全表逐个比较对内存的大占用,提高了系统运行的效率。

3.4.3 精确聚类

使用精确聚类提取匹配记录。 就是对第一步粗聚类形成的每一个Canopy中的所有记录用编辑距离算法计算相似度。 假设Canopyi中一共有n(n>=2)个点,di和dj为Canopyi中的任意两点,将每一点作为一类,在每一个Canopy中求这任意两类gi和gj间的最小距离,取最小值,当每一个Canopy中的类的个数大于1 且类间的最小距离小于k时, 标记满足最小距离小于k的两个类(gi,gj)作为匹配结果输出,并从Canopyi中剔除掉已经建立匹配关系的(gi,gj), 接下来再计算Canopyi中其余的类间距离,判断是否小于k,一直到Canopyi中的类个数小于等于1 或者类间最小距离大于k为止, 此时跳出循环并返回最终的匹配对。

3.4.4 匹配结果注入共享池

找到匹配对之后的操作就是将同属同一实体的数据注入共享池。 例如在教务处数据库中学号N101121011 下有该生各学年的成绩,但是没有该生的籍贯、违纪情况的信息,这些信息分别存放在学生处、后勤处的数据库中,那么在经过上述的聚类算法匹配后,学生处、后勤处的数据被辨识到属于该生,接下来的操作就是将这些属性值合并到同一条目中,并存放在共享池中。

4实验环节

本文所有的程序均用JAVA语言编写, 并在CPU为INTEL Core i5,主频为2.5GHz,内存为8GB的机器上运行,所用的操作系统为Windows 7,数据结构采用链表存储复制记录。 数据表存放于SQL Server中。

实验比较的对象是传统的排序—删除算法的代表SNM算法和Canopy聚类算法在多表精简中的应用,实验数据共有500条记录,对比的两个表分别来自教务处和学生处。5000 条记录有1000 条重复记录。 教务处数据表中的特征字段为ID ( 学号)、NAME(姓名)、NMPY(姓名拼音)、ADDRESS(地址),对应的学生处中的特征字段为XH(学号)、XM(姓名)、XMPY(姓名拼音)、ADD(地址)。

那么考察的指标就是对两种方法与是否叠加预处理的组合对教务处和学生处两个表重复记录识别的召回率和查准率,取10 组数据,重复10 次试验后求平均值得出召回率和查准率。 借此判断哪种方法在召回率和查准率上的表现更优秀。

从表2 可以看出, 经过预处理的复制记录检测方法的准确率要高于未经过预处理的复制记录检测方法,在本实验中,经过预处理的Canopy聚类的复制记录检测方法的查准率高于经过预处理的排序邻居方法, 且Canopy方法具有更高的召回率,表明它能得到更多的复制记录,算法效率更高。

5结语

本文提出了基于共享池的高校信息集成环境下的共享池精简范式。 通过预处理提高记录匹配的准确性,通过Canopy聚类算法作为数据库记录求取相似匹配的基础算法。 该算法不局限于特定应用领域具有较好的普遍适应性, 且比较传统的排序—比较法,聚类法的运算量较小,召回率和准确率较高。 经过实验,本框架达到了预定的设计要求。

在高校信息系统中, 不仅存在着数据库的重复记录类型的冗余数据,还有不同部门/ 相同部门的信息系统中的重复文件,以及在数据备份的过程中由于全局备份产生的大量冗余数据, 这部分重复数据的识别与精简,被称为文件级的精简,这将是下一阶段研究的课题。

参考文献

[1]戴东波,汤春蕾,熊簧.基于整体和局部相似性的序列聚类算法[J].软件学报,2010,21(4):702-717.

高校数据中心走向集成 篇4

本文提出的基于SOA的动态数据集成框架正是很好的应对了高校数字化信息系统的数据集成要求, 为异构异型的数据进行集成和共享提供了一种面向服务体系结构的解决办法, 实现了跨平台的数据共享、实时数据交换和数据随需应变等功能。

1. 研究背景

高校数字化信息系统通常拥有许多业务系统, 由于每个业务系统都是按照自身的业务流程需要编制应用程序或者购买成熟的软件产品, 因此均对应了独立的数据库系统结构和标准, 这使得各业务系统之间存在异构数据源。当系统中实现数据资源共享、各业务系统协同工作、业务流程出现变更时, 系统会存在数据转换复杂, 不易共享, 冗余数据无法同步更新等问题。

而基于SOA的面向服务的松耦合构架, 能够方便的将Web服务整合集成, 以提供系统级的数据集成和转换, 具有良好的延展性和灵活性, 能很好的实现系统中各业务系统的异构数据共享, 灵活应对业务流程变更。因此, 文本以此作为高校数字化信息系统的数据集成框架。

2. 构建基于SOA的数据集成框架

基于SOA的动态数据集成服务框架的技术体系结构主要包含5个层次, 分别是数据源适配器、服务包装器、SOA运行引擎、XML视图引擎、XML视图。

其中, 数据源适配器是同各业务系统提供的异构数据源进行交互的桥梁。它负责把存储在各个数据源的原生数据转换成标准的XML文档, 动态加载到系统中。服务包装器是将数据源适配器包装成标准的Web服务。SOA运行引擎是框架的核心, 通过它调度服务的执行, 驱动数据集成的处理。XML视图引擎则主要将多个异构的数据源表示为单一的即时虚拟数据库, 解析并传达用户请求, 返还结果。XML视图是对数据集成的元信息描述, 由它表达集成后的效果, 用户查看XML视图就能了解其表达的数据集成模式。

在基于SOA的数据集成框架结构中, 用户可以通过服务存取信道访问包装了XML视图引擎的服务, 而用户的请求在这里被解析成为一系列能直接访问数据底层服务的查询计划, 并通过缓存实现查询计划的可重用。存取信道管理模块则提供对服务存取信道的运行管理, 例如访问请求合并、优先级排队、信道复用等。

框架中的存取控制模块为用户使用服务和访问数据的安全提供基础。一个高校数字化信息系统的用户通过单一登陆就可以访问如办公自动化系统、教务管理系统、图书管理系统等异构数据源, 极大简化了用户访问模式。存取控制模块还将处理用户访问会话的生命期, 使得用户在一段特定时间内访问系统, 提高系统安全性。

用户在通过登陆认证后, 通过服务接口对服务进行存取, 由服务管理器查找到用户请求访问的服务, 管理服务的生命周期, 检查服务的运行情况, 调度服务的运行、注册服务等。服务工厂会根据服务注册信息启动服务, 如果服务包装的底层数据源不可得, 则该服务将企图装载在本地的缓存数据。

用户通过服务接口可以访问自己需要的服务, 而在数据集成框架中主要的服务包括:1) 内置服务, 包含框架运行必须具备的服务功能。2) 插件服务, 将提供数据的各种数据源包装成服务, 并以可插拔的方式植入框架中。3) 代理服务, 是一种扩展的插件服务, 由它提供诸如第三方应用如ERP、CRM等数据源的包装以及对XML视图引擎的包装。

用户在对服务进行访问过程中, 系统以Web服务作为统一的数据接入接口, 即通过一个数据源封装注册管理工具, 将高校数字化信息系统中各种异构、分散的数据源封装成标准得Web服务, 用以屏蔽数据源之间的差异, 提供统一的数据访问方法。

由于数据源是包装成服务以可插拔方式植入框架的, 业务系统的流程作为标准的Web服务可从框架中移出或移入, 便于应对业务扩展或流程变更。另外, 服务发布/订阅接口提供了同框架异步通讯的机制, 各种服务可以在这里订阅需要的消息。

框架中作为统一数据接口的标准Web服务可以定义为, 通过SOAP协议, 在网络上提供服务, 使用WSDL来描述这种服务, 并通过UDDI注册服务使得使用者能够找到服务。

3. 数据集成框架的优势

在高校信息系统中采用基于SOA动态数据集成框架的优势在于:1) 充分利用已有数据资产和业务系统;2) 降低开发和维护成本;3) 统一的数据, 更好的支持共享和决策;4) 随需应变, 快速响应变更。

4. 结束语

基于SOA的动态数据集成为高校数字化信息系统中异构数据的共享和变更提供了一个面向服务体系结构的框架, 它利用了SOA构架所具有的平台、软件无关性和松耦合特性, 以XML技术为基础, 动态集成为手段, 实现高校信息系统中众多业务系统之间的数据集成, 实现跨平台的数据共享, 达到数据资源整合的目的, 实现了信息的相互联通, 极大地推动了高校数字化校园建设进程, 成为未来高校信息系统发展的重要趋势。

摘要：由于各业务系统提供异构数据源和存在需求变更, 高校数字化信息系统需要一个有效的数据集成框架来支持数据共享和业务流程变化。采用基于SOA的动态数据集成框架能够更好的实现高校数字化信息系统中各业务系统之间的数据整合, 为系统提供灵活、强大的数据支撑服务。

关键词：SOA,数据集成,Web服务

参考文献

[1]易峥荣, 卜炜, 葛序风, 刘颖娜.基于SOA的数据协同模型[J].计算机工程, 2009, (2) .

[2]余小华.基于SOAP网关的Web Services安全模型[J].研究与设计, 2009, (3) .

[3]Dink Krafzig等著, 韩宏志译.Enterpirse SOA中文版[Z].清华大学出版社, 2006.7.

高校数据中心走向集成 篇5

高校中结构或者形式不一样的多个数据源构成了高校异构数据源。比如说, 教务处的数据库是关系型数据库SQL SERVER, 财务处的数据库是简单数据库ACCESS, 而人事处的数据则是文本数据、XML数据等等, 当校长需要了解某教师的基本情况时, 从这三处得到的数据不能及时整合到一起, 因为它们是来自不同数据源的数据, 构成了异构数据源。

1.1 系统异构

数据源所在的业务应用系统, 数据库管理系统以及操作系统的差异性。

1.2 模式异构

数据源在存储模式上的不同, 数据源可能采用文档模式, 关系模式, 对象模式以及对象关系模式等模式中的任意一种 (其中关系模式是现在主流存储模式) 。同时, 即便是同一类存储模式, 它们的模式结构可能也存在着差异。

2 解决高校异构数据源集成的方法

1) 给各种异构数据源分别建立不同的用户交互接口, 不进行任何模式的集成。这种方法实现最为简单, 但用户不能透明访问数据, 而且增加新的异构数据源时, 必须增加新的访问接口, 不利于系统的扩充。

2) 采用联邦数据库系统结构。联邦数据库系统是由一组互相协作的但保持各自自治性的成员数据库系统组成, 通过数据源之间的数据交换格式进行一一映射, 也就是说, 不同的数据源之间使用数据转换接口来实现数据互访, 从而实现任意两个数据源可以相互访问的目的。如果有a个异构数据源需要相互访问, 那么就需要构造a* (a-1) 个映射程序来支持这a个异构数据源之间的相互访问。这些成员数据库系统可以不同的程度集成。这种方案的优点是容易实现, 缺点是工作量大, 扩展性差。

3) 使用数据仓库。它是把来自于多个数据库的数据副本都存储在单一的数据库中。在这种结构中, 所有数据库的数据都被抽取出来, 通过预处理、转换, 以符合数据仓库的模式, 并存储在数据仓库中, 用户可以通过统一的数据接口对历史数据访问。这种方案的优点是用户使用查询就像是在原来单一的数据源中查询一样, 便于进行联机分析和数据挖掘, 缺点是数据需要定期更新, 否则就会发生数据源和用户使用的数据仓库中数据不一致的问题。

4) 利用中间件集成异构数据源[1]。中间件实际上是一种软件组织, 位于异构数据库源系统数据层和应用程序应用层之间, 用户的查询先提交给中间件, 中间件将用户的查询翻译成一个或者多个对数据源的查询, 再将数据源对查询的响应进行综合处理, 构造出用户需要的数据模式。该方法不需要改变原始数据的存储和管理方式[2]。

基于以上对异构数据源集成方法的对比分析, 其中以中间件的方案最优。以下将讨论基于XML的异构数据源集成中间件的设计方案。

3 基于 XML异构数据源集成中间件设计

3.1 XML的优越性[3]

XML (Extensible Markup Language) 是W3C组织于1982年2月发布的标准。它已经成为基于Internet 应用的事实上的数据格式标准。XML 文档不是传统意义上的文档, 而是一种数据库化的文档。面向内容的标记, 使计算机很容易理解数据的含义。这一特性使它可以应用于 Web 数据和电子数据交换 (EDI) 中。

1) XML是一种半结构化的数据模型, 它的自我描述性质能够很好地表现许多复杂的数据关系, 结构简单明了。

2) 数据与格式无关性。XML的数据存储格式不受显示格式的制约。XML把文档的三要素, 即数据、结构和显示方式独立开来, 分别处理。首先把显示格式从数据内容中独立出来, 保存在样式单文件 (StyleSheet) 中, 这样如果需要改变文档的显示方式, 只要修改样式单文件就行了。

3) 便于数据查询。XML的文档描述的语义非常清楚, 而且很容易就可以将它和关系数据库中的属性一一对应起来。

3.2 基于XML异构数据源集成中间件设计

中间件就像实际存在的物化的数据库一样, 支持虚拟数据库。中间件模式不存储任何数据, 而是将用户的查询翻译成一个或者多个对数据源的查询。

XML异构数据库中间件主要实现两个功能:一个是查询任务的分配, 另一个是查询结果的集成。

3.2.1 查询任务的分配

当有具体查询请求时, 将查询分配到已有的某个或多个数据源的包装器, 然后再由包装器将查询转换成不同数据源能够识别的格式, 发送到相应数据源。具体分配过程如下:

首先需要依据用户的查询请求去查询各个数据库在中间件中的注册信息, 以此进行判断是哪个数据源的查询任务。这里采用的数据提取工具是ADO技术, 整个数据库的链接对于用户来说是透明的, 针对不同的数据源生成不同的数据库连接串, 完全屏蔽了数据库的异构性。各个异构数据源在异构数据源数据共享集成中间件中的主要注册信息有:数据库类型;数据库连接信息如主机名、端口号、用户名、密码等;共享数据表及权限等。根据注册信息即可知道需要把查询发送到哪个或哪些数据源的包装器。除了进行任务分配外, 根据异构数据库注册时生成的权限信息, 中间件还将对用户提交的数据请求进行权限判断。如果通过查询发现此用户无此使用权限将禁止这次查询操作的执行, 这样可以避免很多无效的操作。如果等到真正对数据源进行查询时再进行权限的检查, 发现用户无此权限时, 中间过程产生的数据都被视为无效, 就会多做很多无用功[4]。

3.2.2 查询结果的集成

把从多个数据源查询得到的结果集成在一起发送给用户。这是一个映射过程, 具体的映射集成过程如下:

在数据交换时, 当源数据中要导出的表名和属性名与目标数据库之间的表名和属性名不完全匹配时, 需要建立表名和属性名之间的映射关系, 根据映射关系生成XSL样式表模板文件, 通过XSL T分析器将源交换XML文件转换成与目标数据库结构一致的形式, 这一过程称为映射建模[5]。数据映射工具通过映射器分析源模式信息和目标模式信息, 建立起源、目标数据库之间表和字段的对应关系, 生成映射模板文件, 在XSL T分析器分析出的映射规则对应下, 将源交换文件转换成目标交换文件, 即查询结果, 最后将完整统一的查询结果返回给用户。异构数据库的集成如图1 所示。

4 结论

4.1 异构数据源集成前的数据交换

信息化的发展使得学校各部门间的信息数据交换显得日益频繁, 包括各类人员数据和常用的业务数据等。在没有建立高校异构数据源集成平台前, 各部门之间进行信息数据交换时的访问示意如图2所示。

4.2 异构数据源集成后的数据交换

在建立高校异构数据源集成平台后, 各部门之间进行信息数据交换时的访问示意如图3所示[6]。

4.3 访问接口数量的比较[7]

依据图1所示, 异构数据源集成前各部门间进行信息数据交换时的接口数量为:当部门数量a=5时, 总接口数量b=2P2a=40;当a增加到8时, b=2P2a=112。

依据图2所示, 异构数据源集成后各部门间进行信息数据交换时的接口数量为:无论部门数量a是多少, 总接口数量始终是1。

可以看出, 异构数据源的集成将大大减少数据访问时的交换频率和对服务器、网络等的数据传送压力。这样就很好地降低了系统间数据交换的成本, 同时还增加了数据交换的命中率。

在高校异构数据源的访问中涉及多个业务子系统, 如学生管理系统、数字图书管理系统、成绩管理系统、后勤管理系统等, 每个系统都可能有不同的后台数据库。基于XML的异构数据源集成中间件的设计理念, 屏蔽了数据交换中复杂的内部过程, 实现了高校异构数据源的透明访问和共享以及互通互连。

摘要：高校信息系统需要访问异构数据源中的数据, 因此, 需要一种新的系统架构来解决多个异构数据源的信息访问问题。首先对高校信息化建设过程中遇到的异构数据源问题进行了分析, 并比较了目前已有的异构数据源集成方法的优劣性, 在比较的基础上介绍了XML技术的优越性, 进而提出了XML框架下异构数据源集成中间件设计的数据集成方案。最后总结了异构数据源集成前后不同系统访问时接口数量的变化。

关键词：异构数据源,联邦数据库,数据仓库,中间件,XML

参考文献

[1]栗华军, 宋顺林.异构数据库集成系统的研究与实现[J].计算机工程与设计, 2008, 29 (15) :4026-4028.

[2]姚敏.XML技术在高校一卡通异构数据库中间件的应用[J].微计算机信息, 2009, 25 (12) :205-206.

[3]曾小宁, 黎明.基于XML的数据交换中间件的研究与实现[J].计算机工程与设计, 2007, 28 (12) :2999-3002.

[4]唐智勇, 吴刚, 黄宏斌.基于Web Service的动态可调整的异构数据集成[J].微电子学与计算机, 2009, 26 (9) :5-8.

[5]Sanjay Madria, Kalpdrum Passi, Sourav Bhowmick.An XML schema integration and query mechanism system[J].Data&Knowledge Engineering, 2008 (65) :266-303.

[6]胡能发, 唐为萍.基于XML的通用异构数据交换模型[J].计算机工程与设计, 2010, 31 (8) :1743-1749.

高校数据中心走向集成 篇6

随着信息化进程, 高校已经安装了许多先进的设备, 如远程抄表系统, 这些系统在方便管理的同时, 也产生了大量的数据, 而当前对这些数据的使用却是非常的有限, 同时使用用户的局限性也不能充分发挥高校信息化给整个高校带来的好处。

面对实际存在的问题, 本文通过使用数据仓库, 以及WebGIS技术来解决这些问题, 通过数据仓库技术使历史数据发挥它的价值, 并同高校其它部门结合, 分析出有用的信息;同时通过与WebGIS平台将这些信息合适地展现给全校的用户。

1高校WebGIS

将WebGIS技术应用于校园房产管理系统中, 能够把校园房产的属性数据和图形数据发布于互联网, 让更多的非管理人员了解学校的布局及房屋的分布, 并能使得一些信息通过网络提供给其他用户使用, 从而提高系统的服务范围和利用率。

笔者所在学校已经成功实施了WebGIS校园房产管理系统, 并有意向数字校园扩展。在这个系统的基础上, 如何把后勤部门的电力数据也作为房产的属性数据集成到WebGIS系统中去, 让更多的人可以通过WebGIS系统来分享这些学校不同部门系统的数据将是文章的重点。

2数据仓库

当下, 随着高校信息系统的建设, 能源管理部门 (如后勤部门) 积累了丰富的用户信息资料和高校总体需求。由于这些部门在电子化初期没有实现集中控制, 加上高校各组织信息系统的独立性, 使大量历史数据处于脱机状态, 不能进行在线集中分析处理。

笔者调研了本校后勤部门, 该部门的远程抄表系统仅仅只是将当前电量在计算机信息平台上显示以及一些简单的分析统计, 对于历史产生的海量历史数据根本没有加以利用, 更不用说利用其内包含的信息了, 而解决这一问题的方法就是利用数据仓库技术, 并同联机分析处理系统相结合, 通过数据转移工具将位于不同操作系统平台、不同数据组织形式中的数据按一定规则集中在一个数据仓库中, 从而保证数据仓库中数据的完全一致, 达到充分利用各种数据源的目的, 使当前及历史数据成为查询和决策分析的更有效工具。本文笔者使用的数据仓库工具为SAP公司的BI (商务智能) 产品。

3集成平台的实现

图1展现了整个业务场景。左边方框内是在平台实现前的情况:学校的后勤集团物业管理中心根据规划, 对全校建筑进行了特殊电表的安装, 然后完成远程抄表系统相关软硬件的安装与配置, 最终可以在后勤信息平台的网页上实时查看任意建筑的用电情况, 以及作一些简单的分析处理。

在平台实现后, 所有的用户可以通过校园网统一进入, 使用并查看相关内容, 并且查看的内容将是以使用用户的角色相关的一些内容, 这些内容将是跨各个部门的一些信息, 不仅仅是后勤集团提供的电能信息。围绕图1, 下面作一些具体的说明。

3.1数据处理ETL过程

3.1.1 数据集成

数据集成层的主要作用是为了保证进入数据仓库的数据是规范的统一的, 否则进入数据仓库的数据是杂乱矛盾的, 基于这样的数据进行的分析是没有任何意义的, 比如要统一规范“建筑”编号, 使后勤集团信息系统与房产处等其他部门在数据仓库中的编号一致。

3.1.2 数据存储

“干净”的数据进入数据仓库后, 首先是作为“业务数据”存放在数据仓库内部, 这一阶段的数据与源系统端的数据在内容上没有大的区别, 唯一的区别就是作了清洗和规范。这一部分是通过SAP BI系统中的数据对象DSO来实现存储。再进一步将是主题数据的存储, 根据数据仓库主题建模结束以后, 必须进行相关主题域数据的准备, 相关主题内容的数据就必须通过综合、汇总以及其他一些必要的操作进行数据重处理, 在这一阶段也是通过DSO数据对象来进行实现。多维数据存储主要是存储的一些多维数据集, 如一些从主题DSO抽取生成的一些信息立方体 (SAP InfoCube) 等。

3.1.3 实时数据的获取SAP RDA

SAP RDA (Real-Time Data Acquisition) 是SAP处理实时数据获取的一种技术。

图2两种数据流是两种场景的体现, 左边就是常规的数据进入数据仓库的最简单的流程, 右边是实时数据采集最简单的数据流情况。最低层是各源数据内容。InfoPackage即信息包, 是SAP BI中一个包含各种精确抽取源数据及更新配置的数据对象, 是一个运行时的对象, 它负责将源数据从源系统中传输到SAP数据仓库系统中的PSA表中。PSA是持续数据加载区 (Persistent Staging Area) 的缩写, 来自源系统的数据在进入SAP BI中, 首先是存放在数据源 (DataSource) 中, 更准确的说是存储在数据源对应的PSA表中的, 系统为每一个数据源都自动生成数据结构相同的PSA表。最后通过DTP (Data Transfer Process) 将数据从PSA表中传输到最终的数据存储对象DSO或InfoCube (SAP 多维信息立方体) 中去。

SAP实时处理RDA 的控制与调度是通过Daemon来实现的, Daemon是SAP系统定义的一个系统处理模块, 它的功能是负责在一确定的时间间隔内触发或执行相关的系统任务, SAP BI Daemon执行大致上分三个步骤:

(1) 触发Service API (SAPI, 适用于源系统为SAP系统) 或通过WebService Push使InfoPackage将实时数据从源系统抽取到SAP数据仓库系统中的PSA表内;

(2) 跟踪从源系统传输数据的状态;

(3) 触发SAP DTP将PSA数据更新到相关的数据存储对象 (DSO) 中去。

3.2OLAP多维分析

OLAP (联机分析处理) 是一类软件技术, 它使分析人员、经理、管理人员通过对信息的多种可能的观察形式进行快速、稳定一致和交互式的存取, 以便管理决策人员对数据进行深入观察。通过多维视图能使最终用户从多角度、多侧面、多层次直观的考察数据仓库中的数据, 从而深入地理解包含在数据中的信息及其内涵。在高校电力分析中, 可以展现与用电的许多不同维度, 比如建筑用电的部门维度、类型维度、空间维度等等, 这些信息内容相当部分是高校其它部门的数据, 如房产处、信息办等部门, 通过基于数据仓库的OLAP分析, 可以很直观的分析他们之间的关系, 为相关决策作支持。

3.3与WebGIS的集成

WebGIS平台是高校不同角色都可以根据自身权限登陆的一个平台, 也是数字校园的一个基础平台, 将电力分析展现集成到WebGIS平台上, 使更多的人和部门“主动地”去了解高校或与自己身边的能源消耗情况, 且同时也方便今后与其它系统的集成。

笔者所在校园WebGIS平台已经成功使用, 该平台是通过Adobe Flex同WebService技术实现的基于RIA的应用, 它的功能模块都是通过Webservice实现, 所以, 可以将OLAP分析数据或直接的实时数据通过SOAP消息发送给WebGIS系统的功能服务模块实现相关内容的集成。而发布在数据仓库系统端的XMLA接口正好满足了这样一个需求。

XML for Analysis (XMLA) 是一种基于简单对象访问协议 (SOAP) 的XML API, 并且定义了两种方法:Disocver和Execute, 这两种方法使用并发送XML, 以发现并控制无状态数据。在Execute方法中, 可以处理OLAP的多维查询语句MDX, 可以将多维分析的结果集以XML数据格式输出。 MDX是Multi-Dimensional Expressions (多维表达式) 的简写形式, 是一种专门为检索多维信息而设计的基于SQL的语言。

4实例过程验证

4.1历史数据的存储

远程抄表系统的常规历史数据由SAP BI的DB Connect接口, 然后通过图2左边的流程, 将后勤部门的电力历史数据存储到SAP BW的DSO数据对象中去, 这部分是常规数据仓库处理过程, 本文不作详细说明, 下面将会对实时数据的获取进行说明。

4.2实时数据获取

在SAP BI端完成下面的具体操作, 完成图2右边的数据流程:

(1) 在SAP系统中定义好WebService类型的源系统;

(2) 定义数据源 (DataSource) , 定义服务端接口数据结构;

(3) 定义DSO数据存储对象, 定义暂存端实时数据的数据结构;

(4) 定义PSA (数据源) 到DSO的影射及转换 (Transformation) ;

(5) 定义Infopackage, 此时设定Request关闭时间, 为一天;

(6) 定义RDA类型的DTP;

(7) 通过Daemon工具实现定时的操作, 将定时暂设为7分钟。

启动Daemon, 等待外部系统 (后勤信息系统) 的WebService方式触发, 运行时的Infopackage与DTP进程在图4中都可以看到, 并且可以通过监控工具进行实时调度。

4.3确定主题域, 数据仓库模型设计

围绕主题, 进行房产处、教务处、财务处、信息办等其他部门的数据集成汇总, 进行相关的主题数据准备, 实例以简单的建筑用电主题进行OLAP多维模型设计:

维度的确定:根据分析的要求, 确定了以下几个维度:建筑部门维度、房产维度、房产类型维度等。指标值的确定:原型确定了指标为电使用量 (具体的用电分类略) 。完成星型模型的构建, 如图5所示。

4.4WebGIS集成

在WebGIS系统端的服务模块中, 增加电力查询分析的处理服务, 该WebGIS功能模块服务包含:面向WebGIS界面需求的接口定义与预处理;调用发布在数据仓库平台端的服务XMLA;处理XMLA返回的实时数据或多维分析数据;封装成友好的、WebGIS系统支持的数据格式作为该功能服务的返回结果。图6是其中一实时服务的部分简化处理代码, 可以通过“FunField”接口参数去调用XMLA服务, 将结果返回给WebGIS前台系统。

4.5效果展现

WebGIS系统前台根据设计的逻辑处理流程, 可以将功能服务模块传过来的服务结果进行展现, 具体效果见下图:图7展现了具体建筑信息和实时数据的结合展现;图8展现的是数据仓库分析数据和直观WebGIS的结合展现。

5结束语

本文主要通过使用SAP数据仓库和学校已经成功实施的WebGIS系统的接口, 将学校后勤部门的电力数据抽取到数据仓库平台进行分析处理, 并在WebGIS平台上展现, 从而从一定程度上有效的利用了后勤部门的历史数据, 让高校其他用户都可以关注和自己相关的这些学校处级部门内部的数据, 同时为其他部门的信息化、集成化提供了借鉴。

参考文献

[1]文永明.基于WebGIS的校园房产管理系统研究与设计[D].华北电力大学, 2007.

[2]游进国.一种OLAP可视化方法的研究及其实现[D].昆明理工大学, 2005.

[3]孙鸣乐.分布式实时远程抄表系统设计与实现[J].电测与仪表, 2005, 42 (5) .

[4]陈永杰.SAP商务智能完全解决方案[M].北京:机械工业出版社, 2008.

[5]于宁.高校教学决策支持系统数据仓库的研究与实现[J].哈尔滨工程大学, 2006.

[6]杜军华.基于WebService的Web地图服务设计与实践[J].测绘科学技术学报, 2007.

从物业管理走向集成运维 篇7

物业管理行业是房地产行业的一个重要组成部分,良好的物业管理已经成为楼盘销售的重要因素,也成为业主或租户选择物业的重要考虑因素。

随着物业管理行业的市场化程度越来越高,出现了一批大型物业管理企业,这些大型物业管理企业设立有总公司、区域公司、管理处等三级或多级组织机构,实行集团化运作。另外,以城市综合体为代表的商业地产的兴起,也对高端物业管理提出了新的要求。

目前,市场上大多数的物业管理软件主要是针对单一管理处的应用模式设计的,在产品功能上基本没有考虑多个管理处集中式应用的需要。软件技术架构落后,而且缺乏平台化开发技术,无法解决集中式应用方案必须解决的性能、安全性和稳定性问题,也难以满足物业管理公司的个性化需求。

2 物业管理信息化的新趋势

2.1 集中式应用成为主流的应用模式

首先,软件系统的产品功能从单一管理处应用模式升级为总公司、区域公司和管理处多级组织架构的集中式应用模式。在目前主流的物业管理信息化系统中,组织机构作为主线贯穿于整个系统,实现“集中管理、分权运作”的应用模式。软件系统既能够满足各个管理处日常业务操作层面的要求,也能够满足公司进行实时监控、流程化管理和报表的自动统计分析等管理层面的要求。

其次,软件系统的部署方式由单机或局域网应用模式升级为互联网应用模式。软件产品能够支持基于互联网的云计算模式,通过互联网将总公司、区域公司和各个管理连接到一起,所有数据集中在一个数据库中,能够实时共享,部署和使用成本较低。

此外,由于物业管理公司的各个项目通常分布在不同地域,因此通过工作流驱动的方式实现跨地域、跨部门的协同工作,以完成客户服务、采购计划申请、合同签批等工作也成为必要的工作模式。目前主流的物业管理信息化系统能够通过工作流驱动技术来提高工作效率,并通过固化企业的业务流程来降低企业扩张时的管理成本。

2.2 产品功能的广度和深度不断提高

传统的物业管理软件是以收费管理为核心,主要是满足物业管理公司财务核算方面的要求。受限于软件系统的产品功能和技术架构,传统的物业管理软件对于协同办公、经营管理、客户服务、工程管理、物料管理、人力资源管理、成本控制和企业门户等业务缺乏深入的管理功能,只能够进行一些简单的记录和统计。现代物业管理信息化系统中,通过多组织架构集中式管理、互联网直联和工作流驱动等先进的产品理念和技术,产品功能的广度和深度得到了全面的提高。

2.3 发展历程(表1)

3 新基点集成运维系统

基于对现代物业和智能建筑领域发展趋势的了解,深圳市新基点智能技术有限公司研发了基于数据集成和商务智能(BI)的集成运维系统KEEPERMAX产品,能够满足高档写字楼、大型商业综合体等对于资产管理、运营管理以及数据集成与分析等多方面要求,帮助物业管理方实现精细化管理,提升物业的经营绩效。

如图1,新基点KEEPERMAX集成运维系统包括资产管理、运营管理、智能数据集成等多个业务子系统以及协同办公、客户服务和综合查询等多个支撑子系统。各个子系统均基于新基点智能化集成基础平台,使用相同的技术架构和基础数据,在产品功能和业务流程等方面都实现了完全的集成应用。

在部署上,新基点KEEPERMAX集成运维管理系统完全支持基于云计算模式的方式,只需要部署一套服务器连接到互联网,同时区域公司和各项目部通过专线或者公网VPN方式即可实现集中式应用。

KEEPERMAX系统的主要特点如下:

(1)全资产管理和全成本核算

KEEPERMAX集成运维系统将传统物业系统中的“不动产”概念延伸到资产,将机电设备、智能化子系统等一一纳入到管理范围中来。系统按照全成本核算的理念来设计,对运营成本进行多层次、全方位的管理,有效地支持运营管理部门来做开源节流。

(2)基于多级组织的集中式管理模式

KEEPERMAX集成运维系统打破了传统的部门独立和地域分散的限制,通过互联网连接将公司总部、各个区域公司和各个项目部连接到一起,所有数据集中储存在一个数据库中,能够实时共享,为企业领导和各级管理人员提供一个及时掌握业务全貌的信息处理平台。主要特点表现在:

1)所有数据集中存放在一个统一的数据库中,避免存在多个数据孤岛。通过统一的数据库实现真正的集团管控,包括合同签报、实时查询各种管理报表和业务报表等功能。

2)支持多级组织架构。集中式应用下的多组织架构不能是扁平式而应该是层次结构的,应包括总公司、区域公司和项目部等多种组织机构类型,从而构成多级组织架构。当组织架构调整时,软件系统能够快速地进行调整,并且数据会自动按照新的组织架构进行统计和汇总。

(3)工作流驱动

KEEPERMAX集成运维系统中内置了强大的工作流系统,能够以图形化的方式定义和监控业务流程,支持直流、分流、条件流、并发流、自动转发等多种流程模式,提供了强大的会审功能和扩展流程服务等高级功能。

KEEPERMAX集成运维系统中的OA子系统与其他业务子系统无缝集成,既可以在业务子系统中发起流程,也可以在协同办公子系统中发起流程。通过先进的工作流驱动技术,能够实现合同审批、客户服务等业务的流程化管理。

(4)运营绩效导向的财务管理和租赁管理

KEEPERMAX支持设定多个关键运营绩效(KPI),系统具有强大的财务管理功能,在费用管理上支持多种收费项目和多种收费标准,支持各种类型的仪表,支持复杂的公摊表和总表的分摊计算,并且能够与目前主流的财务管理软件实现数据接口,达到数据流一体化的目的。

4 KEEPERMAX用户案例

(1)重庆国际博览中心

使用组件:物业管理系统、访客门户、移动客户端。

(2)广州广晟国际大厦

使用组件:物业管理系统、云服务门户、访客门户。

(3)广州珠江城大厦

使用组件:物业管理系统、云服务门户、招商门户、访客门户、移动客户端。

摘要：本文分析了物业管理信息化的趋势,指出了目前市场上大多数物业管理软件的不足,最后重点阐述了新基点研发的集成运维系统KEEPERMAX的特点和优势。