共享数据集成

共享数据集成（精选八篇）

共享数据集成 篇1

当前,随着信息技术的飞速发展,全国各高校都加快了数字化校园建设进程,从而造成了校园网中应用系统的数量飞速的增长,由于这些应用系统中的数据存储结构与存储方式不尽相同,势必会造成各个应用系统间的异构数据相互独立,共享性差,导致校园网中“信息孤岛”的发生,从而严重制约了校园网的运行效率,阻碍了高校的信息化进程。为了解决上述问题,实现校园网的异构数据库中数据资源的集成与共享,本文利用XML技术,提出了一种基于XML的数据集成中间件的解决方案。

1 基于 XML 数据集成模型

XML( Extensible Markup Language,可扩展标记语言) 是一种标记语言,具有自我描述性,允许用户自定义标签,非常适合于存储和传输信息,而不是显示信息,因此通过XML技术可以很方便的构建一种异构数据集成与共享模型,如图1所示,基于XML的数据集成模型,其体系结构从上到下分为五个层次,即应用层、业务层、接口层、中间件层、数据源层。

应用层的作用是通过各种应用系统,比如教师信息综合查询平台、数据集成中间件管理平台,以及数据挖掘平台等,直接与用户进行交互,完成用户的需求,而对于用户而言,使用上述平台,就和使用普通应用系统一样,比如要完成某个查询操作,用户只需要关心查询内容,而并不必要关心查询结果分布于哪些数据库,需要指出的是,数据集成中间件管理平台的作用是完成数据集成中间件的设置与元数据库的维护,只面向于中间件的管理人员,不面向于校园网中的普通用户。

业务层包括所有的与中间件访问、管理、安全等有关的功能组件,包括业务功能组件,比如全局数据源管理组件、局部数据源管理组件等,以及中间件访问组件、安全组件、XML结果转换组件四大部分。业务层的工作流程为,通过安全组件接收应用层提交的HTTP请求,过滤其中可能存在的攻击行为,比如SQL注入攻击,并将中间件的访问请求提交中间件访问组件,中间件的管理请求提交业务功能组件, 其中中间件访问组件对于数据集成中间件的访问需要调用接口层中基于Web Service的中间件访问接口实现,并且业务功能组件对于元数据库的访问也需要调用接口层中的元数据库访问接口实现,同时业务层接收接口层返回的对数据集成中间件或元数据库的操作、查询结果,并将查询结果提交应用层供用户浏览。

接口层中定义了基于Web Service的中间件访问接口和元数据库访问接口,分别用于提供给业务层中的相应组件调用,实现访问中间件或对元数据库进行读写操作等,并将查询或操作结果返回业务层的相应组件中,这样无论数据集成中间件,还是元数据库对于用户来说都是隐藏的,都不能通过用户直接操作,提升了系统的安全性。

中间件层包括数据集成中间件的全部功能模块,是异构数据集成的核心部分,其由查询分配器、包装器、结果集成器三大组件构成,其中查询分配器中又包括查询分析器、查询分解器、子查询管理器三部分构成,结果集成器包扩XML结果接收器、XML结果重组器两部分构成。中间件层的主要工作流程为,通过查询分配器接收接口层提交的SQL全局查询请求,并结合元数据库中全局数据源同局部数据源的映射信息,将SQL全局查询请求分解为若干个针对局部数据源的查询请求,通过包装器完成对局部数据源的查询,并将查询结果以XML的形式发送到结果集成器,结果集成器将所有局部数据源的XML查询结果整合成统一的全局XML查询结果, 并将其转换成浏览器可直接显示的XSL样式形式, 逐层返回到应用层,供用户浏览。

数据源层包含了校园网中所有需要进行数据集成的异构数据库,比如人事信息库,课程资源库、科研信息库等,数据库的类型可以是SQL Server、Oracle等形式,访问驱动类型可以是基于ODBC、JDBC等多种途径。

2 数据集成中间件的设计

数据集成中间件是基于XML数据集成模型的核心部分,也是实现校园网中异构数据集成与共享的关键,本文中的数据集成中间件采用基于. NET Framework4. 0架构的C #. NET开发,主要由元数据库、查询分配器、包装器、结果集成器四部分组成,其功能介绍和实现原理如下。

2. 1 元数据库

本文中的元数据库是一系列XML文档构成的一种虚拟数据库,它属于一种中间形式的数据库,其中并不真正地存储用户所要查询的数据资源,而是主要存储着全局数据源到局部数据源之间的映射信息、全局数据源的基本信息,以及局部数据源的基本信息和结构信息,用户所要查询的数据资源仍存储于各自的局部异构数据库中,由于上述信息基于XML文档方式进行存储,因此本文采用XMLSchema的方式对XML文档的格 式进行规 定,通过XMLSchema标准可以为XML文档中的元素限定数据类型等约束信息,并且可以检查XML文档的有效性,以及实现到关系模式的转换等,并且元数据库在全局数据查询中主要起到路由的作用,由于元数据库中记录着全局数据源到局部数据源之间的映射关系,以及局部数据源的基本信息,就可以在全局数据查询分解中,为数据集成中间件中的查询分配器提供正确的局部数据源路径选择,从而实现全局数据查询到局部数据查询的正确分解。

元数据库的写入、维护等操作只能由经过身份认证的管理员,通过数据集成中间件管理平台进行操作,元数据库的一般由全局数据字典、系统数据字典、映射关系字典、局部数据字典四部分构成,元数据库中的数据字典信息均记录于XML文档当中, XML文档的结构格式通过XMLSchema规定,XML文档的查询可以通过XPath实现,各数据字典的详细介绍如下:

全局数据字典中记录了全局数据库的结构信息,包括全局数据表的构成,表中的字段,字段的数据类型等信息,因为元数据库是一个虚拟数据库,所以全局数据字典中只记录全局数据库的结构信息, 全局数据表中不记录任何的数据信息,对于全局数据库的查询请求,都会根据全局数据库同局部数据库的映射关系,分解为针对一个或多个局部数据源的查询请求。

系统数据字典中记录了数据集成中间件管理员的登录信息、中间件运行的参数信息等基本信息。以系统数据字典中的管理员登录信息表为例,介绍一下系统数据字典中表单的XMLSchema描述形式:

从上述XMLSchema描述可知管理员登录信息表的结构形式为,名称login_admin,包括id、adminname、password等字段,上述字段的类型均为字符串型,主键为id,管理员信息表中数据的XML存储形式如下:

映射关系字典中记录了全局数据源到局部数据源之间的映射信息,比如全局数据表到局部数据表的映射,以及全局数据表中的字段到局部数据表中字段的映射信息等,映射信息的具体的XML存储形式如下:

上述内容中gbtable代表全局数据表的名称, gbfield代表全局表中全局字段的名称,dbname代表局部数据源的名称,table代表局部数据表的名称, field代表局部数据表中局部字段的名称,上述内容中的映射关系为全局数据表个人信息表grxx同局部数据表教师信息表js_info之间的映射,以及个人信息表grxx中的全局字段工号gh同局部数据表js_ info中的局部字段工号gh之间的映射。

局部数据字典中记录着数据集成中间件所引用的全部局部数据源的信息,数据集成中间件在引用局部数据源时,都会为每个数据源创建一个记录有数据源结构信息的XML文档,而局部数据字典中主要记录的信息包括局部数据源的名称、访问信息,比如IP地址、驱动类型、访问用户名、密码等信息,实际就是记录了局部数据源访问的连接字符串,以及存储局部数据源结构信息的XML文档路径,而记录着局部数据源结构信息的XML文档中, 则记录着局部数据源中所包含的表单信息,以及表单中的字段、数据类型等信息,不括表单中记录的数据信息。

2. 2 查询分配器

查询分配器的作用是将全局查询请求分解成一个或多个针对于局部数据源的子查询,并提交给相应局部数据源的包装器,从而完成局部数据查询。查询分配器由查询分析器、查询分解器、子查询管理器三部分构成。

查询分析器通过访问元数据库,并结合元数据库中全局数据源同局部数据源之间的映射关系,分析全局数据查询中的局部数据源分布情况,并将分析结果提交查询分解器。

查询分解器根据查询分析器传来的全局数据查询的分析结果,将全局数据查询分解为若干个针对于局部数据源的局部子查询,并将这些子查询提交给子查询管理器。

子查询管理器根据先进先出原则,通过. NET中的System. Collections. Queue类,构建子查询管理队列sub SQLQueue,同时根据查询分解器提交的子查询请求,为每个子查询请求分别构建子查询对象sub SQLObject,sub SQLObject中记录着局部数据源的访问信息,如IP地址、数据库名称、类型、用户名、密码,以及对于局部数据源的子查询请求,子查询管理队列sub SQLQueue通过其中的Enqueue方法对生成的所有sub SQLObject子查询对象进行逐一的入队操作,每个新插入的sub SQLObject对象,都将插入到sub SQLQueue队列尾端,当所有子查询对象都入队完毕后,子查询管理器将生成子查询调度线程sub SQLThread,子查询调度线程sub SQLThread通过子查询管理队列中的Dequeue方法,将子查询管理队列sub SQLQueue中的子查询对象sub SQLObject, 进行逐一的出队操作,并发送到相应的包装器中。

2. 3 包装器

包装器的主要作用是接收查询分配器传输的子查询对象sub SQLObject,并对子查 询对象sub SQLObject进行解析,从中提取局部数据源的连接信息和针对局部数据源的子查询SQL语句,根据上述信息,查询局部数据库,并将局部数据源返回的查询结果转换成XML形式,最后发送到结果集成器。

2. 4 结果集成器

结果集成器包括XML结果接收器和XML结果重组器两部分构成。XML结果接收器的作用是接收各个包装器发送的XML形式的局部数据库查询结果,并将这些查询结果发送到XML结果重组器, XML结果重组器将接收的所有局部数据源XML形式的查询结果进行重组,构建出一个XML形式的全局查询结果,并将这个全局查询结果通过接口层中的相应接口,返回到业务层中的XML结果转换组件,XML结果转换组件此时将不能在浏览器中直接呈现的XML文档内容,根据预先定义好的XSL样式表,转换成可以在浏览器中直接呈现的XML文档内容,供用户浏览全局查询结果。

3 结束语

本文提出了一种基于XML的数据集成体系结构,并根据上述体系结构设计并实现了基于XML的数据集成中间件,实现了校园网中的异构数据资源进行无缝的集成与整合,为解决校园网中的“信息孤岛”问题提供了一种有效的途径。

摘要：文中利用XML技术,构建了基于XML的数据集成模型,并根据上述模型,设计并实现了基于XML的数据集成中间件,重点介绍中间件的体系结构、基本原理、构建过程以及组成模块,通过上述中间件的实现,解决校园网不同应用系统中异构数据库之间的数据集成与共享问题,避免了校园网中“信息孤岛”的发生。

集成共享平台项目的范围管理论文 篇2

3月，我参与了某公司网管支撑系统一体化支撑服务的集成共享平台项目的建设。本项目属于工具平台级的应用，服务器为虚拟机，数据库为oracle，操作系统为Redhat。项目大量接口采用WebService方式，为解决系统间的耦合性问题，平台本身高度开放，采用标准协议如SOAP1.1等，采用松耦合的集成架构，系统间通过总线交互，消除蜘蛛网。本项目采用矩阵型组织结构，从各职能部门抽调主干人员，组成专门的项目团队。根据需求，本项目人力资源配置为：1名项目经理，8名程序开发工程师（4名高级，2名中级，2名初级），3名测试人员，1名QA，1名配置管理人员。该集成共享平台项目主要实现以下功能模块：消息处理引擎，服务接入网关，接口能力池，接入适配，服务治理，服务质量。该项目还提供了三种安全机制：用户请求服务时的用户身份识别；服务提供开表加载动态访问控制；个别服务实现基于证书的信任传递。由于本项目的顺利上线涉及到各系统间的互操作和共享服务，涉及的项目干系人较多，因此，在本项目中，范围管理尤为重要。在本项目中，我作为项目经理，对于范围管理，主要做好了以下几点工作。

一、制定范围管理计划

在本项目中，我特别重视范围管理计划的编制。范围管理计划的编制，需要合理、有效的根据，因此，在正式编制计划前，我通过已有的组织过程资产，找出了制定范围管理计划的模板，根据项目合同、建设单位独特的环境因素，再结合以往的项目经验，制定出了一份初步的管理计划。计划制定后召集所有相关干系人，在全员参与下，通过讨论修改，制定了一份相对科学、详细的范围管理计划。

二、范围定义

定义详尽的项目范围说明书对于项目的成功是至关重要的。为了实现这一点，在项目的早期阶段，我带领我的团队到了客户现场收集需求，确定产品范围和项目范围。负责网管系统的网管中心员工大都具备一定的开发能力，又对建设单位所属领域的业务特别熟悉，所以他们对需求的描述相对清晰、透彻，但其他系统所属的业务部门的员工就难于沟通了。比如负责客服中心系统的客户，他们无法明确他们究竟想要实现什么功能，也不清楚要处理的业务数据的来源，因此，在彼此的沟通上很难有一个透彻的理解。基于这种情况，我与甲方领导进行了沟通，提出了用户参与全过程开发的开发原则，让网管中心的员工全程参与开发。这些员工既以甲方代表身份出现（可监控项目的状态和进展），又因成为了真正的开发人员，这样他们不但能学到一些基本的技术和维护方法，等我们撤退后，一些不难的操作就可自己做或自己开发。甲方领导非常认可这一举措。有了网管中心员工的参与，与其他业务系统用户的交流变得简单起来。基于需求文件，我们团队召集项目的主要干系人进行了开会讨论，同时邀请了各系统的最终用户代表对系统功能做出了评价。从他们的角度出发，发现并改进了系统的功能，最终形成了完整的项目范围说明书。

三、创建工作分解结构

通过工作分解结构，把项目范围分解开来，使项目相关人员对项目一目了然，都能通过WBS，把握项目、了解项目过程。工作分解结构还便于责任的划分和落实。因此，基于项目范围说明书，我们团队采用列表型结构开始对项目范围进行分解。在分解前，我通过组织过程资产，找出了WBS模板和WBS中工作包的格式模板，在按照滚动波式计划进行分解的同时，我们团队严格遵守创建WBS的八大原则。如参照8/80原则细化具体的工作包，在“粗”与“细”之间进行权衡，严格控制每个工作包的大小。对于每个工作包，都指定唯一的负责人和其负责的工作内容。

四、范围确认

范围确认贯穿项目的始终。我们要根据项目工作的进展，不断与甲方进行范围确认，完成阶段性验收。范围确认通常通过“检查”来实现。在我们开发完消息处理引擎功能模块，找相关负责人进行确认的时候，客户表示自己不熟悉不了解，无法确认。针对这种情况，我们请全程参与开发的网管中心员工出面，用他们的声音去向其他系统主管部门作出介绍。这样的桥梁作用，既有益于网络中心员工的学习（对他们进行沟通培训），也有益于各业务部门对范围的认可和信任。当然，还是有个别部门对项目质量信心不足，怕承担责任，怕以后使用不便，因此不愿签字。针对这种情况，我们给客户做出了承诺：虽然范围确认是正式的，但不意味着不能再修改了。

五、范围确认

范围确认不是一经定义就一成不变的，项目干系人根据业务需求，总会有一些需求变更。为确保对范围的有效控制，我定期召开状态审查会，通过对照范围基准，进行偏差分析，严格杜绝范围蔓延。如在一次阶段评审会上，我发现某开发人员的功能介绍中多了一个“增加综资订单接口”的功能，但合同和需求里都没有，也没有相关变更记录。仔细询问得知因业务需求，各系统需共享处理综资订单，于是直接跟开发人员提出了这个要求。针对这种情况，我专门开会强调了变更控制的重要性，要求相关人员提交正式变更申请，走正常变更控制流程，一定要进行分析、审核、批准才可以实施，不能擅自改动。

面向资源共享的信息系统集成 篇3

随着信息化系统建设的发展,因时间先后而研制的多个信息系统会分别在不同应用领域履行使命、发挥效益。但由于各信息系统建设时间先后不同,使命任务不同,且受当时技术发展水平影响,难免会出现顶层设计滞后于系统建设。一方面,已有系统不能适应信息化条件下信息保障的新需求;另一方面原有系统作为遗留系统,基本上不能进行修改和进化以满足新的变化了的业务需求[1]。

上述问题技术上可以通过信息系统综合集成来解决。如果要做到既满足新需求又尽可能保留已有系统,就要首先明确综合集成的目标。系统综合集成技术可实现各系统共性业务软件资源的统一管理及按需服务、信息共享及面向新作战使命任务的柔性重组等多种目标,而其中,资源共享是所有集成目标实现的基础。

1 信息系统集成领域技术发展现状

信息系统综合集成问题是属于最近国内外研究的非常热门的EAI领域问题,简单地说,当企业实施的IT支持系统多于一个,并且系统相互间要进行数据或信息交流时就有不同系统的集成问题。EAI能够将业务流程、应用软件、硬件和各种标准联合起来,在2个或更多的企业应用系统之间实现无缝集成,使它们像一个整体一样进行业务处理和信息共享。

因各企业现状及集成的需求不同,企业应用集成的策略和方案也就不同。从集成的深度方面考虑,集成策略和方案依次从数据集成、应用系统集成再到面向过程的集成[2,3],集成的难度和能够取得的效益都是不同的,不管怎样,企业应用集成的目的是实现在企业内外任何相连的应用系统和数据源间无限制的分享数据和业务过程。

2 综合集成总体框架

结合当前信息系统建设现状及集成需求,这里主要从应用集成层次提出综合集成总体框架。

下面以资源共享为目标确定综合集成总体框架,实现软件和信息资源的共享及服务。总体上,建立信息服务中心,统一管理各类软件资源,并为业务人员提供统一的软件资源访问门户;采用SOA理念基于消息总线的技术体制实现软件资源间的信息交互。软件集成框架如图 1所示。

集成框架主要包括如下功能,各业务功能的实现为SOA架构模型的应用组件,以实现网络化分布部署、组合和使用[4]。

① 统一管理各类软件资源。建立软件资源库,统一管理各类软件资源。包括被集成信息系统的已有业务软件、为基于被集成系统进行可重用业务设计的构件及服务。

② 统一软件资源访问入口。建立信息服务中心,提供软件资源库访问门户。为业务人员提供基于网络环境的软件资源统一获取入口,实现一次登录,网络任一节点使用。

③ 统一授权访问控制。提供业务人员的统一身份标识和管理,为管理员提供基于统一身份标识的用户权限管理;为各软件资源提供统一的访问控制手段,实现业务人员网络任一节点登录环境下,基于权限的软件资源的访问控制。

④ 提供软件资源应用集成总线。提供基于消息总线的松耦合交互方式,为业务软件、构件及服务间的信息交互提供应用支撑;提供基于服务总线的软件资源共享方式,为业务软件、构件及服务的分布共享提供应用支撑。

2.1 资源共享门户

软件资源库统一存储管理各系统业务软件、构件及服务,并通过门户提供给用户统一入口。主要包括用户管理、软件资源管理、业务流程定制及用户界面定制[5]。

2.1.1 用户管理

用户管理为业务人员提供用户注册、发现的管理工具,其功能结合身份认证服务及访问控制服务提供的接口实现。具体包括:

① 用户注册及管理。为业务人员提供用户注册功能,包括创建新用户、修改及删除已有用户等。

② 用户登录及授权。为业务人员提供已注册用户登录功能,用户通过登录获取用户信息及用户权限,软件资源门户可通过用户权限实现软件资源的访问控制,并进行用户界面的定制。

2.1.2 软件资源管理

软件资源管理为业务人员提供软件资源描述、上传、下载及检索功能,软件资源管理由用户访问控制服务提供授权访问功能。具体包括:

① 软件资源注册。为业务人员提供软件资源注册功能,包括建立软件资源目录、软件资源的更新、移动和删除功能,完成资源注册到物理资源映射管理。由资源注册发现服务提供支撑。

② 软件资源搜索。为业务人员提供软件资源搜索功能,包括基于分类的浏览查询、基于关键字的条件检索及组合条件检索。由资源注册发现、用户访问控制服务提供支撑,按用户权限对软件资源进行过滤。

③ 软件资源获取。为业务人员提供软件资源获取功能,包括提供业务人员使用的业务软件及构件资源下载、客户端应用及供业务重组的构件及服务资源调用的功能。

2.1.3 业务流程定制

业务流程定制为业务人员提供业务流程定制及基于业务流程的服务组合,同时提供业务过程建模、管理、监控和分析等全生命周期的管理职能。业务流程定制主要功能包括工作流服务和自动业务流程服务。业务流程定制可为面向过程的系统集成提供工具,本文不再详述。

2.1.4 用户界面定制

提供业务人员按工作需要定制软件资源服务界面的功能,包括按照用户需求选取软件资源、定制界面布局风格。定制工具由用户访问控制服务提供授权访问功能。

2.2 应用集成

被集成应用系统的各类业务软件、应用构件及应用服务资源通过系统消息总线和系统服务总线实现各软件资源的信息交互和分布式共享。

2.2.1 系统软件资源服务

系统软件资源服务通过系统服务总线提供后台软件资源管理等功能的应用支撑,主要包括软件资源注册、软件资源发现和软件资源目录管理功能。软件资源注册主要包括软件资源注册申请、发布功能;软件资源发现主要为软件资源管理应用进行软件资源搜索提供搜索引擎;软件资源目录管理为软件资源管理应用提供后台服务支撑,包括按需求进行软件资源目录组织,提供软件资源目录同步更新等功能。

2.2.2 系统消息服务

因待集成遗留系统软件体系结构各不相同,接口种类繁多,适合采用以系统消息总线为核心的应用集成技术体制实现各应用软件、构件及服务的信息互通;采用系统服务总线提供的应用服务器技术实现各应用服务分布式调用和应用[6];应用服务间也可在应用服务器基础上接入系统消息总线,实现信息互通。应用集成总线包括系统消息总线、消息代理、消息适配及系统服务总线。应用集成体系结构如图2所示。

(1) 系统消息总线

系统信息交换采用消息总线的拓扑结构设计,为分布式应用提供高效、可靠、跨越不同操作系统、不同网络的消息/文件传送服务。系统消息总线主要包括消息管理、传输管理和系统管理功能。消息管理主要有5种对象:消息、消息池、消息管理器、消息数据库和消息日志;传输管理主要实现结点间的消息传输,通过消息管理模块提供的读取和投递消息的接口,读取及投递消息;系统管理提供维护系统配置参数的功能,为应用程序和管理配置工具提供管理和配置的接口。

(2) 消息代理

应用通过消息代理与系统消息总线连接,实现信息的订阅发布。对采用不同消息传输技术体制的应用,通过消息代理实现信息向消息总线的转换。其中,注册管理服务用于管理和存储各类管理信息,并进行各种管理控制。管理信息包括:发布源信息、订阅客户信息、订单信息和配置信息。各种管理控制功能包括发布源和订阅客户权限验证、注册服务、订单接收和发放。发布端部分是由发布源和发布源代理组成。发布源是信息生成应用程序,负责产生最新的处理数据,然后通过发布源代理全部发布出去。订阅客户端部分是由订阅客户和订阅客户端代理组成。订阅客户是各个订阅信息的应用程序,提出订阅信息要求,并获得订阅内容的应用。订阅客户端代理将订阅端的要求提供给订阅发布注册管理服务,并从发布源获取发布的信息,提供给订阅客户。

(3) 消息适配

消息适配为被集成的各应用系统提供向统一消息总线的接入,包括实现对被集成系统内部消息总线到系统消息总线的接入;实现内部点对点消息传输到系统消息总线的转换。转换后消息通过消息代理接入系统消息总线。

3 结束语

以信息系统综合集成为需求,在对各类信息系统集成策略及方案分析的基础上,重点针对信息系统集成的基本目标,进行了面向资源共享的信息系统集成框架分析研究。基于此框架,各信息系统可在对遗留系统不做大量改造的前提下实现软件资源的获取及信息的分布和共享,为针对遗留系统的信息系统集成提供了技术参考框架,并可满足基于该框架的系统集成扩展要求。以此为基础,可进一步研究对各信息系统业务流程的集成,从而实现在面向任务的柔性重组目标。

参考文献

[1]张萍,顾国强.基于SOA企业遗留系统集成的研究和应用[J].计算机应用与软件,2011,28(10):103-105.

[2]彭武良,周丽,王雷.企业应用集成技术综述[J].计算机应用研究,2007,24(9):13-16.

[3]张莹.基于Web服务的企业应用系统柔性集成研究[D].武汉:华中科技大学,2009:8-12.

[4]龙丽萍.ESB-SOA架构在企业应用集成中的研究和应用[D].长沙:中南大学,2009:5-6.

[5]蔡鸿明.面向企业应用集成的企业资源服务建模研究[D].上海:上海交通大学,2010:17-18.

共享数据集成 篇4

跨组织的合作与协同已成为全球化经济时代现代制造企业发展的主题。建立面向跨组织协同制造的资源集成共享方法与相关使能技术是当前乃至今后若干年内制造业所面临的最紧迫的任务之一。近20年来在敏捷制造、网络化制造、面向服务的制造等先进制造理念与思想指导下,国内外众多研究机构与组织对虚拟企业、协作网络、制造网格、应用服务提供商等先进制造模式开展了大量的研究与实践,取得了一定的研究成果并实现了一些典型应用,但其固有存在的服务模式问题、制造资源的共享与分配技术问题和安全问题阻碍了相关研究成果的扩大深化应用[1]。

云制造通过云计算、物联网、云安全、面向服务的网络信息等技术融合,实现跨组织分布、自治、异构的制造资源统一、集中的智能化管理与经营,一方面提高了资源服务提供方的资源利用率,实现增值增效;另一方面通过任务分解、自动寻租、检索匹配和协同服务等技术实现资源需求方的低碳绿色制造。云制造目标是基于专业核心竞争力共享,实现敏捷化整合社会制造资源,其本质是一种具有面向服务和需求、透明集成、主动多用户参与、按需使用与付费、低门槛外包式制造模式。云制造是一个新概念,当前众多研究者从概念、模型、体系结构等角度对云制造进行了研究。云制造环境下资源共享和应用过程是基于任务驱动资源而形成共享服务链的过程,而目前对实现云制造环境下任务与服务间的动态映射及动态服务链的构建尚缺乏系统解决方案[2]。

因此,本文根据云制造的概念和特点引入资源服务链的概念,并基于时序约束关联的原子任务链驱动的资源服务链构建,来实现云制造环境下资源集成共享,对云制造环境下资源服务模型、资源与任务建模及资源的虚拟化封装、协同制造任务的自动分解、资源服务链的构建等关键技术进行研究。

1 云制造资源共享过程模型

本文提出的资源服务链是指服务于云制造总任务分解形成的时序与约束关联的原子任务执行过程中各种制造资源所构成的资源链。因此,通过资源服务链的构建与运行,能有机地集成和处理云制造中资源集成共享所涉及的资源建模、检索匹配、选择评价、调度、监控等一系列问题,从而形成一个系统性的综合方案;而资源服务链本身又是在云制造过程中各项具有时序与约束关联的原子任务链驱动下构建形成的,因而能在全局和系统层面实现跨组织协同制造中资源的集成共享。因此,复杂的跨组织协同制造中资源的集成共享问题自然转化为任务链驱动的资源服务链的构建问题。基于上述认识提出云制造模式下资源共享的过程模型,如图1所示。该过程模型的核心是:

(1)基于面向服务的思想,利用网络信息技术把分布、自治、异构的云制造资源转化为标准规范的资源服务,并通过面向服务技术将其封装适配到集成共享平台中。

(2)利用面向服务技术,把不同类型和粒度的云制造总任务经一定的分解策略转化为时序约束关联的原子任务链,并把标准规范化描述的原子任务注册发布到集成共享平台中。

(3)基于原子任务和约束的云制造资源服务检索匹配与选择评价算法,获得各原子任务的候选制造资源服务对象集合。

(4)通过基于时序约束关联的原子任务链驱动的云制造资源服务链构建来实现跨组织资源集成共享与优化配置。

上述云制造环境下的资源集成共享过程模型具有以下几个显著特点:

(1)实现了云制造环境下协同制造任务分解,时序约束关联原子任务链构建,基于语义本体的资源虚拟化封装、资源注册、发现、匹配和交易等全过程的优化管理,从而为求解大规模复杂问题的协同制造及资源共享提供了可能。

(2)充分体现了云制造“分散资源集中使用,集中资源分散服务”的服务模式与思想。

(3)通过时序约束关联原子任务链驱动资源服务链构建实现业务链动态生成,为实现云制造环境下更广域范围、更深、更灵活的资源集成共享提供了有效的解决手段。

2 云制造资源与任务建模及资源服务化封装

2.1 云制造资源与任务建模

分布、自治、异构且类多量大的云制造资源与任务标准化描述是实现资源集成共享的前提与基础。由于云制造模式下资源与任务类多量大,为便于云制造资源的集成共享和组织管理,首先要对云制造过程中可能用到的各种资源与任务建立统一分类体系,从而使云制造模式下的资源与任务在描述、表达和理解上具有一致性。在云制造模式下,资源分为设备类、人力类、软件类、知识类、物料类、服务类和信息类等类型,任务分为分析设计类、加工制造业类、物流配送类和资源应用类等类型。其次,对云制造各类资源与任务从数据层、语义层和逻辑层均分别采用可扩展标记语言(extensible markup language,XML)、Web服务本体描述语言(Web service ontology language,OWL-S)和统一建模语言(unified modeling language,UML)来建立相应的可扩展描述模板,由此建立云制造资源与任务建模参考标准。其中,基于OWL-S的语义模板适于基于语义本体资源服务检索匹配,基于XML的数据模板适于网络传输与解析,基于UML的对象模板适于跨组织资源与任务层次化分类定义,而各类资源模板之间的逻辑映射关系通过有向弧方式建立,从而使跨企业制造资源与任务形成具有分层的有向网络图结构。在此基础上可通过扩展基于Web Service标准技术体系的通用描述、发现与集成服务(universal description,discovery and integration,UDDI)的数据结构和应用程序编程接口(application programming interface,API)来建立云制造资源与任务的管理组织方案。基于语义对象的云制造加工类任务本体结构如图2所示。在图2中,对云制造加工任务基于本体从概念、属性和关联关系等角度进行了全面系统的抽象描述。通过任务编号、名称、提交方、类型、状态和时间等信息描述了任务本体概念。通过加工任务的约束属性、特征属性和评价属性定义实现了加工任务的属性描述。通过多种关联属性定义了加工任务之间的关系定义。

不同类型的云制造任务按图2所示的方式详细定义好本体结构后,根据描述模板通过OWL-S进行制造任务语义描述,OWL-S使得云制造加工制造类任务具备机器可理解性和易用性,从而支持自动的、动态的云制造资源服务发现、执行、组合和互操作。云制造资源建模方法与任务建模方法主要的区别为云制造资源建模方法在具体建模时需要考虑资源类型、应用场景、状态和能力等关键属性信息。基于语义对象的云制造设备类资源服务本体结构如图3所示。图3中,基于本体从概念、属性和关联等角度对云制造设备类资源进行了全面系统的抽象定义。通过对设备的名称、类型、型号、供应厂家、所属企业、购置日期和状态等基本信息描述定义了设备类本体的概念;通过能力属性、约束属性、评价属性和接口属性定义实现了对设备类资源本体信息描述;通过多种关联关系定义描述了设备类资源本体的关系定义。而对设备类资源本体属性约束可以通过OWL-S的关键词实现取值约束、基数约束、继承约束、定义域约束、值域约束、关系约束和特性约束。

按上述方法建立各类云制造任务与资源本体结构后,采用斯坦福大学开发的Protégé本体建模工具,通过人机交互可视化建模方式编辑各类任务和资源的概念、属性和关联等本体元素,建立基于语义对象的云制造资源与任务描述模型,并运用其中的验证、评价机制对模型进行校验。采用Protégé本体编辑工具建立云制造资源与任务的概念模型和特征信息后,通过ProtégéOWLPlugin工具编辑和校验,并将本体模型自动转换成对应的OWL-S描述模型。通过对云制造资源与任务的本体建模和语义描述,为解决异构资源与任务的组合、互操作、检索匹配等奠定语义基础。

2.2 云制造资源服务化封装

为屏蔽云制造环境下资源的异构性和复杂性,并将物理资源转化为逻辑制造资源,解除物理制造资源与其应用之间的紧耦合关系,使其对外呈现统一的调用接口,需将云制造资源封装为有状态的Web服务资源。本文提出基于Web服务资源框架(Web service resource framework,WSRF)实现云制造资源服务化封装,其封装结构如图4所示。WSRF不仅定义了跨组织资源的共享机制及管理机制,而且提供了使用Web服务资源(WS-Resource)的方法和状态资源(Stateful Resource)建模的能力。WS-Resource方法有利于服务之间的互操作,为不同服务提供者和服务使用者描述、访问和管理有状态资源提供了一种通用方法[3,4]。

根据图4,云制造标准化资源的封装分为Web服务封装和Stateful资源封装。其中,Stateful资源封装了制造资源的属性信息。根据制造资源属性信息的特点及实现方式的不同将其分为三类:静态属性信息、动态属性信息以及任务队列信息。静态属性信息描述资源的基本信息、约束信息、关联信息、能力信息和评价信息等,它相对比较稳定,不需要频繁的被访问和修改。动态属性信息描述制造资源在执行制造任务的过程中实时变化的信息,主要分为资源状态信息和当前任务状态两部分,其中资源状态信息记录了制造资源在执行任务状态下的动态属性信息,而当前任务状态则描述了当前任务的执行情况。任务队列信息描述了在制造资源上执行过的、正在执行的以及计划执行的任务信息,它为云制造资源的预留提供了依据。

云制造资源Web服务化封装实现首先基于前文定义的本体结构模型将特定资源根据本体概念使用XML格式描述成无歧义的服务数据;其次把服务接口和操作抽象出来描述为WSDL文件,对其访问接口和操作方法进行定义,并用相应的编程语言实现访问接口,从而形成满足WSRF技术规范的资源服务;再次采用Web服务部署描述(Web services deploy description,WSDD)文件来定义Web服务部署所需要的参数,它包括一个服务地址(wsa:Address)、与服务地址关联的元数据(如WSDL服务描述信息)以及与使用服务相关的策略信息(wsa:ReferenceProperties),从而可以定义一个在端点地址上与Web服务关联的有状态资源的实例。最后使用Globus Toolkit中的部署工具将已封装好的服务部署到Globus容器中,当容器启动后资源请求者就可以通过地址调用所需的制造资源服务。

3 云制造任务分解与原子任务链构建

云制造任务具有多样性、多层次性、多路径、多资源协作和多约束条件等特点,另外云制造任务的分解分配与传统制造模式下的任务分解分配在分配对象、分配目标、分配策略、分配范围和约束条件定义等方面都有很多不同。本文提出先根据产品形成过程各阶段任务的特点、约束、概念和关联等进行抽象分析,并从成本、周期和技术方案等约束角度对影响云制造任务分解粒度的关键因素进行详细分析,然后基于产品结构和合作案例库建立跨组织协同制造任务分解模型,按功能与结构相结合的方式将总任务分解成多个子任务,图5给出了云制造加工制造类任务分解过程。

(1)假设云制造产品BOM共有n层,初始化BOM的层次i=1,i∈[1,n],根据市场客户订单和库存文件确定BOM第0层(产品层)的任务周期和数量。

(2)检索案例库,查询针对该任务是否有成功的历史合作案例,所谓成功是相对的,如果案例库中双方的合作评价值大于任务请求方的期望值就是成功的。如有成功的历史合作案例,就执行(3);若无则执行(4)。

(3)检索到针对第i层任务的成功合作案例,与资源提供方基于合同进行商务洽谈。若洽谈成功,则该第i层的制造任务tai为分解后的子任务之一。

(4)若检索到针对第i层任务无成功合作案例,则将其确定为带分解任务,并对其相应制造对象根据产品BOM进行物料类型判断。若为采购件或外协件则将第i层的制造任务tai作为分解后的子任务之一。

(5)若根据产品BOM第i层的待分解任务所对应的加工对象物料类型为自制件,则根据相应任务周期企业的生产能力和生产计划进行能力平衡判定。若平衡则将该第i层的制造任务ti确定为企业自制任务,执行(6);若不平衡则将确定超能力的制造任务并将其发布为分解后的子任务之一。

(6)若产品BOM第i层共有m项任务,则初始化j=1,j∈[1,m]并按照上述步骤(1)~(5)循环判断待分解任务taij是否作为分解后的子任务,直至j=m即第i层所有任务分解完毕。

(7)按产品BOM遍历直至i=n。

分解后的任务是一种层次的树状结构,采用任务结构树来描述。分解后的各个任务之间的联系采用基于Steward的设计结构矩阵(design structure matrix,DSM)思想和产品工艺路线而提出的任务结构矩阵(task structure matrix,TSM)的形式表示:

结构矩阵的维数代表分解后任务个数,对角线上的元素代表任务活动本身,TSM的每一行表示完成该活动所对应的任务需要其他各列任务的支持信息。利用结构矩阵可以十分方便地进行云制造协同任务的规划和管理,同时也可以帮助各参与者认识任务的本质和规律。通过判定分解后所形成任务矩阵的稀疏性和耦合性来确定各子任务的执行顺序,任务结构矩阵通过量化模式和聚类算法实现任务间关联类型、特征及重要程度的分析。同时,对云制造总任务所需满足的QoS约束(即总任务约束)进行分解形成各原子任务约束,其分解原理如图6所示。针对特定云制造任务,根据上述分解后形成的任务矩阵、各原子任务约束、任务工艺路线,可基于Petri网和商业流程执行语言(Business Process Execution Language For Web Services,BPEL4WS)建立云制造原子任务链。

4 云制造资源服务链构建

4.1 单原子任务驱动云制造资源服务检索匹配

单原子任务驱动云制造资源服务检索匹配阶段的关键是要搞清采用何种算法和机制快速有效地找到满足任务需求的资源服务。本文从类型、文本语义、I/O参数和QoS约束等角度提出单原子任务驱动的制造资源检索匹配算法:

其中,u1~u4分别为检索匹配过程中类型匹配值TypeMatch(TP,RP)、语义匹配值SemMatch(TP,RP)、输入输出参数匹配值IOMatch(TP,RP)和QoS约束匹配值QoSMatch(TP,RP)相应的权重。类型匹配TypeMatch(TP,RP)的目的是确定制造任务所需的资源服务类型和资源服务自身所声明的在类型上的相似性,其中TP代表任务提交方(task provider),RP代表资源提供方(resource provider)。语义匹配SemMatch(TP,RP)通过计算服务请求和资源服务的名称、描述的语义相关度来完成,目的是确定两者在描述上的相似性。输入输出参数匹配IOMatch(TP,RP)通过综合计算制造任务和资源服务输入输出类型和语义的相关度,确定两者在功能上的相似性。QoS约束匹配QoSMatch(TP,RP)通过计算QoS相关度完成,QoS相关度基于制造任务和资源服务中的评价指标来计算,其目的是确定两者在操作能力上的相似性。式(2)中TypeMatch(TP,RP)、SemMatch(TP,RP)、IOMatch(TP,RP)和QoSMatch(TP,RP)的计算模型参见文献[4]。

4.2 多原子任务驱动的云制造资源服务链构建

云制造资源服务链是根据特定的制造原子任务检索匹配情况,由时序与约束来关联多原子任务驱动而形成的结果。本文提出将时序关联的多任务驱动的云制造资源服务链构建问题抽象为多目标约束的最短路径选择问题,建立相应的目标函数如下:

其中,α和β分别为任务提交方对时间和成本因素的综合权重,α+β=1且α,β∈[0,1];T为云制造资源服务链运行时间函数,包括资源服务准备时间、执行时间以及资源服务间的周转时间;C为云制造资源服务链运行成本函数,包括资源服务执行成本与资源服务间的周转成本等。T和C的数学模型分别如下:

在时间函数T中,n为总候选资源数量,m为网络化制造任务链中存在子任务并行执行的数量,k为网络化制造任务链中每处并行的子任务数。表示(n-mk)个串行任务tai针对相应的资源服务所需的加工时间的累加。表示分别对m处k个并行的任务所需加工时间取最大值并累加。表示对相继执行的(n-mk)个串行任务的(n-mk-2)个连接时间累加。表示分别对m处前继任务taj-1与其后继k个并行任务连接时间取最大值并累加。表示分别对后继任务tajk与其前继k个并行任务连接时间取最大值并累加,统一用j表示m处并行任务的起始编号。

在成本函数C中,表示n个任务针对相应资源服务的加工成本累加;表示对相继执行的(n-mk)个串行任务的(n-mk-2)个连接成本累加;表示先对m处前继任务taj-1与其后继k个并行任务的连接成本进行累加,累加值赋值给ch,然后对m个ch值进行累加。表示先对m处后继任务taj-1与其前继k个并行任务的连接成本进行累加,累加值赋给ca,然后对m个ca值进行累加。

5 仿真算例

某模具制造企业接到一大型注塑模具加工订单,批量为5件,报价为40万元,交货期为20天,需通过云制造资源服务平台外协合作完成。假设该模具制造企业根据本文方法对加工订单进行分解,并已将所分解形成需外协合作原子任务基于特定描述的模板在云制造资源服务平台发布注册,而平台中的资源服务库中已存在相关可提供外协服务的模具加工资源。根据单任务驱动的资源服务检索匹配算法(式(2)),除开始时的ta0任务和结束时的ta7任务,每个原子任务各有两个候选云制造资源服务,经云制造任务分解所形成的各个候选云制造资源任务与服务的结构如图7所示。

上述算例各原子任务候选资源间的加工时间成本及连接时间成本等性能参数如表1所示。

该算例基于前文所述的目标函数,采用蚁群算法在MATLAB 7.0中仿真求解,具体实现技术与过程参考文献[5]。设置蚁群算法基本初始化参数如下:总信息素量Q=100,蚂蚁数量m=40,启发因子α=1,β=3,信息素残留系数ρ=0.5,启发式期望值常量C=30。经计算,该企业模具云制造资源服务链基于成本最低构建结果如图8所示,此时该模具云制造完成时间为62.4d,总制造成本为107.1千元。

基于时间最短构建结果如图9所示,此时总制造完成时间为52.3d,总制造成本为131.4千元。

基于时间成本综合最优结果如图10所示,此时目标函数式(3)中的时间成本权重均为0.5,该模具云制造完成时间为54.2d,总制造成本为120千元。因此,调整目标函数中时间成本权重值可优化得到不同的模具云制造任务分配结果。

6 结束语

制造资源集成共享一直是国内外众多学者的研究热点与难点,云制造以实现敏捷化、服务化、智能化的绿色低碳制造为目标,同时作为面向服务的网络化制造新模式,为实现跨组织制造资源的集成共享与优化配置、促进制造资源的增值增效,进而增强制造企业核心竞争力提供了新的解决思路。

本文在对云制造相关研究工作进行分析的基础上,深刻把握云制造资源集成共享与优化配置本质———时序关联任务驱动云制造资源服务链构建,以云制造资源服务链构建为研究视角,系统深入地分析云制造资源集成共享所涉及的关键技术问题,并提出了相应的解决方案,如云制造资源共享过程模型、云制造资源与任务建模及资源服务化封装、云制造任务分解及原子任务链构建、云制造资源服务检索及资源服务链构建等,并通过仿真算例证明了相关研究成果的有效性与可行性。

参考文献

[1]李伯虎,张霖,王时龙,等.云制造——面向服务的网络化制造新模式[J].计算机集成制造系统,2010,16(1):1-7,16.

[2]尹胜,尹超,刘飞,等.云制造环境下外协加工资源集成服务模式及语义描述[J].计算机集成制造系统,2011,17(3):525-532.

[3]牛涛.基于WSRF.NET的网格服务研究开发[D].沈阳:沈阳工业大学,2011.

[4]王正成.网络化制造资源集成平台若干关键技术研究与应用[D].杭州:浙江大学,2009.

共享数据集成 篇5

1.全球化进程的加快带来了企业生产关系与供应战略的改变, 也使得供应链集成引起了研究者与企业组织者的重视。在他们看来, 供应链集成可以追溯到波特的价值链模型, 都是在强调要在能够创造价值的企业之间建立关联网络。随着供应链集成理论的流行, 协调供应链成员与其伙伴之间关系的价值共享体系发挥了优势。供应链活动既包含了一个企业组织对外部供应商、顾客以及其他供应链中的若干主动性功能, 尤其重要的是, 确保协调信息从供应商到制造商与顾客的流动以及从顾客与制造商反馈回供应商的信息。正确的供应链关系是基于与供应链其他成员之间的战略合作的, 然后才有了供应链集成, 以便于更好的地使信息能够更及时、准确, 确保质量。然而, 尽管有文献把供应链集成定义为信息共享与信息集成之间的互补, 那就意味着供应链集成可以使信息更有效率的更快速的流动, 也有研究表示, 要提高供应链绩效, 就得充分利用供应链集成处理信息的科学力量。

2.供应链集成提高了供应链成员间合作程度, 因此把公司内的策略、进程与实践活动变成了组织之间的同步的活动, 达到了信息共享。因为动态变化的环境对上游供应链成员的技术与管理资源的要求较高, 而顾客与供应商之间的同步的关系, 使得供应链成员间之间技术与管理资源的差异得到了缓解, 也因此实现多个供应链合作伙伴的竞争能力的提高, 并且, 提高这些能力, 并没有耗费像以往那么多的成本。因此, 供应链集成可以指导合作的各方如何才能有更广阔的合作基础, 如何才能把来自不同方的核心信息资源放到一个通用的平台上, 达到信息共享的目的。基本上所有关于供应链集成的文献都达成了一个共识, 那就是供应链成员之间的联系越紧密, 越能够提高供应商经营活动的透明程度。而通过这些商业主体之间的信息交流, 就可以使得透明度可以存在于上文提到的这样一个平台之上。所以, 也可以说, 供应链集成在供应商之间信息交流中是扮演了提供以及强化基础设施这样的一个作用。

3.供应链集成还可以通过强化人与人之间的信任关系来达到提高信息共享的目的。深化以信任为基础的各方之间的关系, 延长供应链伙伴之间的合同期限, 鼓励有效地解决冲突, 这些最终通过刺激产生成员产生归属感来达到信息共享的目的。信任是当变故发生时, 一个公司愿意相信他的合作伙伴的程度。这种情况下你还认为对方是诚实的, 那么就会给彼此之间的关系带来一个缓冲, 而这种缓冲可以使成员间产生更长期的、稳定的合作关系。供应链关系网中关键价值成员之间长期稳定的关系, 对能否通过他们自身力量来维护供应链整体的决策、应对措施是至关重要的, 因为这些都是取决于他们对与彼此合作关系的信任程度。顾客在一定程度上可以影响供应商的决策, 这是因为随着彼此之间信任程度的增加, 当有效地资源提供更多的时候, 团体的成员也会提供物质与财务以及信息方面的分享。总之, 就是供应链集成通过增加供应链伙伴之间的信息流, 增强了顾客对供应链活动的参与程度。

4.此外, 供应链集成也为每个成员都专注于自身的核心竞争力和特定的专业领域提供了一个机遇, 因为供应链成员间总是具有不同的资源, 特定的领域、技术知识和技能。供应链集成, 究其本质, 指的是在供应链伙伴之间通过合作与协调结构、流程、技术和实践, 建立一个无缝的渠道, 以便于能够使信息、原材料和制成品都能准确及时地在彼此之间流通。这种程度的交流是对于不能及时获得自身缺乏资源的一种替代, 降低了交易的成本以及谈判的成本与合同书写的成本, 从而使企业获得了共同利用资源与功能的益处。双方能更好到底了解彼此的业务, 从而在整体上提高了供应链的性能。反过来说, 每个成员伸出的援助之手则转变成供应链网络中每个成员都可以共享的好处, 因为大家都可以通过弥补对方的不足来提高自己的技能和经验。这种无缝式的信息流是通过来自不同专业与能力的供应链成员促使生成的。这一切, 都是供应链集成提供的连通性来达成的。因此, 供应链集成可以说是由于允许了适当的信息流通而加强了供应链成员的专业化。

5.结语:供应链集成通过在供应链成员之间提供一种无缝式的连接而促使了各个成员间的更深入更顺畅的交流, 这种交流包括了信息沟通、资源技术共享以及对自身核心竞争力的认识与提高。本文仅仅是分析了一般商品生产的供应链集成的几点优越性, 但是对于供应链集成如何运用在不同的生产关系中, 比如, 不同于商品生产供应链的工程项目供应链, 就没有进行阐述。希望更多的学者能对这方面进行深入的研究。

参考文献

[1]Salih Zeki, Halit Keskin.The effect of supply chain integration on information sharing:Enhancing the supply chain performance[C].Procedia Social andBehavioral Sciences24 (2011) 1630-1649

信息系统集成与数据集成策略研究 篇6

一般情况下,数据集成采用的方法包括数据格式的定义、数据的整理、规则的描述等几种,可以有效解决不同数据源在同一平面被共享和运用的问题,以实现不同数据库系统中各种内容的整体显示。因此,数据的查询必须非常简单、快速,以在集成范围内进行统一标识。根据信息系统集成的实际情况可知,网络集成是非常重要的硬基础,而数据是信息系统的重要软基础,必须实现获得各种数据,才能为信息系统的构建提供参考依据,从而实现企业各种资源的最优化配置和最有效利用。所以,在企业的管理系统中,比较典型的数据集成模型是由系统功能层、用户界面层、数据存储层组成的。

由于数据集成是为了实现各个异构数据源之间的数据共享,因此,在为企业制定各种决策提供比较全面的信息资源的前提下,需要改进和优化各个数据库之间存在的局限,采用压缩保存、转化为资产等方法进行数据资源的利用,才能真正为企业不断发展提供重要支持。在信息技术和网络技术不断更新的大环境下,企业数据集成应用的模式已经有很多,其中,基于中间件模型、联邦式、数据仓库等是最常见的三种,在不同情况下可以实现数据共享,最终为企业制定各种决策提供可靠支持。本文就上述三种模式进行简单介绍,一般联邦数据库系统是某些互相联系但又独立存在的单元数据库的集合,可以按照不同的依据对数据库系统进行不一样的集成。因此,数据在互相共享时,联邦数据源之间会相互提供可访问的接口,其分布情况有集中数据库系统、分布式数据库系统和其他数据库系统等多种。在这种情况下,其主要分为两种形式:松耦合、紧耦合。在实际应用中,联邦数据库主要包括数据库、数据、命令、映射、模式和处理器几个部分。与其相比,中间件模式一般是在统一全局数据模型后进行web资源、异构数据库等的访问,因此,其主要存在与应用程序和异构数据源系统两者之间,可以为各种应用、数据访问提供连通接口,也能有效协调各种数据源。另外,数据仓库通常是指企业决策、管理时面对的各种数据集合,如与时间相关的、不能修改的数据,因此,数据是比较广义的,不可重复的。由此可见,在实际应用上述几种模式时,为了降低数据之间转换的误差,需要根据企业决策的实际情况和数据管理情况来确定,以免出现更严重的管理问题。

2 异构数据源之间的数据转换策略

根据信息系统集成与数据集成的整体情况来看,数据源出现异构是由数据库管理系统、应用系统、存贮模式、操作方式等不一样引起的,因此,其可以分为系统上的异构、模式上的异构两种,而数据的存贮模式主要有对象关系模式、对象模式、关系模式等多种,其中,关系模式是最常用的模式。在实践应用中,异构数据源之间的数据转换策略主要包括如下几种:首先,软件工具的合理运用。通常情况下,数据库管理系统都有着将外部数据转移到自身数据库表的相关工具,其有着一定专用性、特定性等特点。已建成,数据库转换的数据必须与数据库对应,才能在合理运用软件工具的基础上,避免数据更新存在不同步问题,最终保证数据库转换的完整性和准确性。其次,中间数据库的有效转换。在进行两个具体的数据库的转换时,可以根据关系定义来确定数据转换模式,从而对数据源的数据进行准确读出,从而在中间件数据的转换下被写入到目的数据库中。虽然采用这种方法进行数据库转换需要的模块比较少,扩展性也较好,但需要的空间比较大,整个过程也比较复杂,需要谨慎使用。最后,数据库组件的科学运用。在科学运用目的数据库、源数据库组件的情况下,数据可以得到直接转换。如果出现源数据库、目的数据库有着不同类型的数据的情况,则需要将他们转换成统一类型的数据,才能确保双方赋值的准确性和可靠性。

3 结束语

综上所述,在社会和经济不断发展的新形势下,信息系统集成是高科技技术不断创新的产物,是服务方式现代化、信息化发展的重要体现,对于实现企业各种数据的优化管理有着极大作用。因此,充分利用信息系统集成与数据集成策略,不但能最大限度的提高企业决策的可行性,还能促进企业更长远发展,是企业经济效益不断增长的重要支持。

摘要：在企业信息化建设力度不断加大的情况下,各种数据急剧增多,需要采用合适的信息系统对这些数据进行集成化管理,才能确保企业各项活动的有序开展。因此,充分了解信息系统集成与数据集成之间的关系,并掌握信息系统集成与数据集成策略,对于推动企业更长远发展有着重要影响。

关键词：信息系统集成,数据集成,数据源

参考文献

[1]焦汉科,马林兵,邓孺孺,等.多源遥感数据管理与远程处理集成实现[J].测绘科学,2015(11):131-136.

[2]刘博,夏新,陈彦东.基于信息集成平台的业务整合与数据共享方案[J].医疗卫生装备,2013(7):46-48.

共享数据集成 篇7

民航行业系统从客户的角度看就应该是一个连续的单一系统, 而目前从管理上划分为:空管、机场、航空公司、航油和航空城附属区域等多个子行业、子区域和子系统, 旅客服务实际上常发生接续不畅、甚或服务被分解为片段, 产生不良的用户体验。

2 民航信息集成共享系统的构想

2.1 旅客需求

对一位旅客来说, 他面对的民航系统在他眼里应该是一个整体在为他服务, 在他的旅程碰到延误时, 最需要和最希望得到的消息什么?是飞机的信息:“她”现状如何? (“她”在哪儿?能不能起飞?能飞的话何时起飞?不能飞的话怎么处理?对我的影响是什么?给我提出可能的选择方案!)

从航班延误处置为切入点看民航信息集成共享需求:

由于大雾、雨雪等极端天气原因, 航空公司原因, 航路或航管原因, 机场原因甚至旅客自己等原因都会会造成航班延误, 随之此航班计划就被迫更改甚至取消等一系列连锁反应:作为后续客户 (所有客户:下站的机场、旅客也包括了保障人员) , 最需要和最希望得到的消息是什么?是飞机的信息:“她”现状如何? (“她”在哪儿?能不能起飞?能飞的话何时起飞?不能飞的话怎么处理?对我的影响是什么?给我提出可能的选择方案?) 航空公司要及时向旅客提供航班延误情况通报, 安抚旅客焦躁的情绪, 做好退改签机票的工作, 提供现场餐食, 安排旅客住宿或者乘坐交通工具离开机场。[1]机场工作人员需要了解实时航班信息、延误旅客人数, 配置适当人员进行处置工作, 当航班恢复时, 有助于增开应急值机柜台快速办理值机和行李托运手续。[1]机场指挥中心人员对航班的动态掌握尤其重要, 因为他们需要根据保障需求调整资源计划, 也就是根据飞机起飞顺序, 合理分配廊桥、登机口、机位等。[1]作为机场管理决策者, 需要相关信息来支持决策, 以便协助航空公司进行旅客食宿、交通、医疗等方面的安置, 合理安排好应急设备和物资储备, 做好保障工作。[1]这说明, 航班延误应对措施的基础是需要各项数据的实时共享, 使得不同客户都能及时得到相关数据信息, 以便做出及时、科学地决策, 合理配置资源, 维持民航运输工作的持续进行。然而, 这些有关航班、旅客和空域资源的数据信息是分散的。空域流量状况由空管部门收集信息, 航班运力计划由航空公司负责, 地面保障资源由机场负责。[1]空管部门主要负责对空中流量进行管控, 掌握航班流量和航班管制时间。[1]航空公司掌握着运力的安排和调配数据, 主要掌握航班计划、航班配载信息、机组人员信息等数据。航班延误后, 航空公司要及时调配运力、调整航班计划。[1]中航信的销售系统和离港系统, 掌握旅客信息。[1]而机场主要负责地面各项资源的调度, 掌握着行李信息、值机柜台、安检通道、登机口、廊桥、牵引车、旅客班车、配餐、机内清洁等资源信息, 机场也需要根据其他驻场单位提供的数据来分配资源。[1]现实中大量数据是分散在不同的责任主体单位, 没有实现数据共享。随着民航运输客流量和航班量快速增长, 需要更全面、及时的数据支撑业务、提供决策依据。所以, 目前从机场、航空公司、旅客、社会其他环节, 都对规划建设民航数据集成共享平台, 整合空管、航空公司、机场及外部单位的数据, 共享生产数据和资源, 从而为日常生产运营、应急指挥和经营管理决策提供有力的信息支持和保障提出了迫切需要。

2.2 民航信息集成共享系统构想

2.2.1架构的核心元素

信息源、信息流类:空管、航空公司、机场、航油、联检等信息服务对象类:直接:旅客、行邮货, 间接:公交、社会服务等。2.2.1.1核心元素的信息内容分析。空管:主要负责对空中流量进行管控, 掌握航班流量和航班管制时间。 (1) 当前状况信息。a.区域、航路、飞机 (区内全体、个体) 空中;b.气象实况 (全国、区域、本场等) 。 (2) 短期未来信息:a.区域、航路、飞机 (区内全体、个体) 空中;b.气象预报 (全国、区域、本场等) 。航空公司:掌握着运力的安排和调配数据, 主要掌握航班计划、航班配载信息、机组人员信息等数据。航班延误后, 航空公司要及时调配运力、调整航班计划。 (1) 当前状况信息:航班计划、航班配载、机组人员、已分配运力、备用运力。 (2) 短期未来信息:机组人员、已分配运力、备用运力。机场 (航油、联检) :主要负责地面各项资源的调度, 掌握着行邮货信息、值机柜台、安检通道、站坪、登机口、廊桥、牵引车、旅客巴士、配餐、机内清洁等资源信息, 机场也需要根据其他驻场单位提供的数据来分配资源。 (1) 当前状况信息:旅客状况 (当期累计、当期数、利用率%、可供资源) 、行邮货、值机柜台、安检通道、站坪、登机口、廊桥、牵引车、旅客巴士、配餐、机内清洁等资源信息 (已供油量、可供油能力, 已联检信息、可供使用资源量) 。 (2) 短期未来信息:行邮货信息、值机柜台、安检通道、旅客巴士 (按原始计划而不是动态计划分配、可能释放的资源) 。旅客 (行邮货) :按计划旅行 (随行行李, 快递货邮等) (1) 当前状况信息:正常全流程, 延误或变更 (未到机场、延误起飞、中途延误、延误变更等) 。 (2) 短期未来信息:除本人主动变更外, 其他均不确定。2.2.1.2核心元素的信息流图。为直观显示说明信息流的关系, 做了信息流图见图1。从前述的各核心元素信息内容解释加上图中各核心元素的控制、从属、反馈关系上进行梳理: (1) 旅客、航空公司、机场等信息源, 集中处理后提交给空管的是相对静态信息。 (2) 其后空管掌握着这些静态信息的动态演变过程。 (3) 航空公司、机场、旅客只能接收空管的指令执行, 并把结果 (空管相关部分) 反馈给空管。 (4) 空管再次发出下一步指令, 周而复始。 (5) 目前信息的相对不对称性 (空管掌握动态、静态信息源, 其他单位只接收到有限的、局部的信息) , 制约了最终旅客获得所需信息 (有效的、及时的、有用的) 。由此推论出:民航信息集成共享需求的核心点———空管。从空管这个核心元素中的核心源头出发, 建立民航信息集成共享系 ( (转转下下页页) ) 统, 将对全民航的服务水平的提高、运行效率的提高起到画龙点睛的作用。

3 架构实现的思考

3.1 组织领导。民航局统领, 空管局牵头, 各航空公司, 航信, 机场等部门共同参与建设和分享。

3.2 技术保障。

以空管或民航局为主, 建设安全网络 (冗余、虚拟化) 、安全信息中心 (行业云、灾备) , 各航空公司、航信、机场设节点 (虚拟网节点;链接行业云或兼有本地私有云) , 客户端 (虚拟客户端方式支持pc、平板、移动终端、手机等)

3.3 效益初探。

(1) 行业信息流完整性、业务逻辑合理性的大幅提高, 动态信息应用范围得以大幅扩展到下游和社会的方方面面, 极大提高和满足客户的信息服务需求; (2) 新架构具有超强数据集成、业务集成共享能力, 进一步扩展完善各层面业务模块、业务流程后, 可以延伸覆盖到各个航空公司、机场、社会团体, 也许最终会到达直接服务最终客户而逐步取消现有的专门服务部门, 其社会效益非常大。

4 展望

随着民航业的飞速发展, 勇于创新、谋求发展, 充分满足客户需求是民航业的重要课题。通过建设集成、统一的数据共享平台, 有效整合空管、航空公司、机场等单位的数据资源, 实现数据信息资源的高效利用, 提高民航业的运行效率, 保证给旅客提供优质服务, 进一步助力民航业快速健康的发展。

参考文献

基于数据元的数据集成技术研究 篇8

近年来,基于本体[2—5]的数据集成方法研究受到了高度的关注。基于本体的数据集成方法是建立全局本体和具体数据源的局部本体,以及全局本体和局部本体、局部本体之间的映射关系,完成异构数据源之间语义上的映射,最后将这种语义上的对应关系转换为数据查询,完成数据集成。但是基于本体的研究方法仅考虑了模型概念的外延即概念之间的关系,没有考虑概念的内涵,对实体属性的语义只能依靠自然语言描述或分析模型的结构,缺少对数据模式元素进行精确描述的语义方法。本文提出的基于数据元的数据集成方法,通过对概念的内涵进行形式化的语义描述,可以实现不同模型之间,乃至实例级的语义映射。

1数据元简介

数据元是用一组属性描述定义、标识、表示和允许值的数据单元,是在一定的环境下不必要再细分的最小数据单位。数据元是可识别和可定义的,每个数据元都有其基本属性,如:名称、定义、数据类型、精度、值域等。一个数据元由数据元概念和表示两部分组成。数据元概念(Data Element Concept)是能以数据元的形式表示,且以任何特定的表示法无关的一种概念。当一个表示被联合到一个数据概念时就能够产生一个数据元。按照国家标准,数据元分为数据元概念、通用数据元、应用数据元。通用数据元提供的是一般的内容,而非具体内容,具体内容则由应用数据元提出。如通用数据元可指“日期”、“姓名”,而引伸出来的应用数据元可以更为具体,如“考试日期”、“入学日期”、“学生姓名”、“教师姓名”等。应用数据元规定为一个独立应用的数据范畴。一个应用数据元必须来自某个通用数据元,遵循通用数据元给出的框架。一个数据模型中的数据项由于限定于数据模型的应用范围,因此是一个应用数据元。图1描述了用于数据元结构的术语与传统的数据建模术语的关联,在数据模型中,一个数据项可以等同于一个数据元,数据模型的数据元名称的典型形式是实体名称和实体属性名称的合成,如图2所示。

2 数据元的语义树[6]描述方法

基于数据元的数据集成需要解决的一个关键问题是语义的描述方法,本文采用的是语义树的描述方法,语义树提供了一种形式化的语义描述方式,可以方便地描述数据元的语义。

如图3所示,在数据元的语义树中,描述数据元“表示”的节点是叶子节点,不再受其它节点限定。抽象语义树通常对应一个通用数据元,通过附加规则节点可派生各种应用数据元。在数据元的语义树中,特定节点是根节点,对象类可被其它限定词进一步限定。在对数据模型中的数据项进行描述时,由于数据项与具体应用场景有关,所以在相应的数据元的语义描述上增加应用场景约束,才能真正地描述该数据项在数据模型中的语义。数据项数据元以属性、实体、约束为中心,通过对实体进行直接限定和间接限定,构成对数据模型数据项语义的完整描述,图4所示。

3 基于数据元语义树的映射实现

3.1 语义树中各节点的权值分配规则

设N为语义树T中的任意一个节点,以N为根的子树记为sub(N),N的子节点数为n,N的第i个子节点记为child(N,i),节点N的权记为W(T,N),子树sub(N)的权记为W(sub(N))。语义树中各节点的权值分配规则如下:

(1) W(T)=1;

undefined

undefined

从上可以看出,一棵语义树的权为1,等于语义树中所有节点的权值之和。子树的根节点占子树权的一半,兄弟节点代表的子树具有相同的权。可见,离语义树的根节点越近权越大,代表的语义概念越重要,这符合一般概念定义的逻辑。

3.2 数据元语义树的映射实现举例

假设两个同类数据项X与数据项Y,分属于实体t1和t2,X和Y的语义树分别为Tx和Ty,对Tx和Ty进行比较,结果如图5所示。

比较结果由Tx∩Ty、Ty-Tx、Tx-Ty三部分组成:

(1) Tx∩Ty:数据项相同的部分,是X和Y具备同类性的基础。

(2) Ty-Tx:给出了数据项Y独特的语义约束部分。如Z∈Ty,Z∉Tx,则Z∈Ty-Tx。当Ty-Tx为空时,表示数据项X下的实例只是数据项Y实例的一部分;当Ty-Tx不为空时,表明数据项Y下的实例数据只是数据项X下实例数据的一部分;Ty-Tx用来选择数据实体集。

(3) Tx-Ty:给出了数据项X独特的语义约束部分。如Z∈Tx,Z∉Ty,则Z∈Tx-Ty。当Tx-Ty为空时,表示数据项Y的实例是数据项X实例的一部分;当Tx-Ty不为空时,表明数据项Y下的实例数据只是数据项X下实例的一部分;Tx-Ty用来决定数据项Y的实例筛选条件。

例如,学生信息数据库除了存储全体学生的基本信息外,为了研究男女生英语成绩的差异还建立了男生成绩表和女生成绩表。

(1) 表“学生信息”是用来存放学生基本信息的数据表,其每一个实例描述一个学生的基本信息,包括主键学号、姓名、院系等,院系的值是一组枚举值,包括石油工程学院、化学化工学院、计算机学院、电子科学学院、外国语学院、艺术学院等。

(2) 表“男生英语”用来记录所有院系男生的英语成绩,其中字段学号是外键,引用表“学生信息”中的学号。

(3) 表“女生英语”与表“男生英语”的结构相同,但表中的实例记录的是所有院系女生的英语成绩,其中字段学号是外键,引用表“学生信息”中的学号。

现在,我们需要统计“计算机学院全体学生的英语成绩”,把“计算机学院全体学生的英语成绩”记为X,则其对应的语义树Tx如图6所示:

首先用X的语义树Tx与各数据项语义树进行比较,得到两个侯选数据项:“男生英语.成绩”、“女生英语.成绩”。令Y为“男生英语.成绩”,则对应的语义树Ty如图7所示。

比较X、Y的语义树Tx、Ty。比较结果Tx∩Ty、Tx-Ty、Ty-Tx分别在图6、图7中用虚线框标出。在图6中Tx-Ty中,可以构成路径data_value.achievement.student.department.identifier="计算机学院",而表“男生英语”的其它数据项的路径都没有与之完全匹配的,但外键“学号”与之部分匹配,由于“男生英语.学号”对应的主键是表“学生信息”中的学号,因此在表“学生信息”中查找相应的数据项,得到数据项“院系”的路径与之匹配。因此得到约束条件“学生信息.院系=′计算机学院′”和关联条件“男生英语.学号=学生信息.学号”,两者相与就得到筛选条件“男生英语.学号=学生信息.学号and学生信息.院系=′计算机学院′”。

同理,与图8中的数据项“女生英语.成绩”的语义树比较,得到筛选条件“女生英语.学号=学生信息.学号 and 学生信息.院系=′计算机学院 ′”。将以上结果用关系数据库SQL语句表达,结果是:

(1) select 男生英语.成绩 from 男生英语,学生信息 where男生英语.学号=学生信息.学号 and学生信息.院系=′计算机学院′;

(2) select 女生英语.成绩 from 女生英语,学生信息where女生英语.学号=学生信息.学号 and 学生信息.院系=′计算机学院 ′。

把两个查询结果合并在一起,可以得到“计算机学院全体学生英语成绩”需要的全部数据。

4 结论

由于数据元语义树的子树本身也是一棵树,因此容易处理子映射。在上节的例子中,“计算机学院全体学生英语成绩”不仅映射到了概念相似的数据项“男生英语.成绩”和“女生英语.成绩”,而且映射到了相关的实体和属性“学生信息.院系”,因此相关概念的映射保证了映射概念的语义完整性。在实际项目中,对7 000多条数据元进行了语义描述,通过映射计算,均能得到正确的映射结果。

参考文献

[1] Maurizio L.Data integration:a theoretical perspective.Proceedingsof the ACM SIGACT-SIGMOD-SIGART Symposium on Principles ofDatabase Systems,2002

[2]周刚,郭建胜,石磊.基于本体的异构数据源集成系统分析与设计.北京联合大学学报(自然科学版),2007;21(1):45—48

[3]张磊,吴笑凡,谢强,等.基于Ontology的多数据源语义集成研究.信息系统,2005;28(6):656—659

[4] Irina P,Heli H,Juha T.Semantic interoperability information integra-tion by using ontology mapping in industrial environment.Proceedingsof the 10th International Conference on Enterprise Information Sys-tems,ICEIS 2008,2008;5:465—468

[5]鱼滨,郑娅峰.基于本体的异构数据集成方法及其实现.计算机应用与软件,2007;24(9):30—33