数据集成模型（精选十篇）
数据集成模型 篇1
对于以煤炭为主要能源的我国,矿业系统的信息化比较缓慢,拉距时间较长。受我国煤炭企业管理机制的影响,各矿业企业在信息化的应用上各自独立,研制、开发或者购买了不同的矿业管理系统,形成了各企业内部相对独立的信息系统。这些基于各种业务流程和异构数据源的应用系统虽然满足了煤炭企业某一特定时期、特定业务的需求,但因数据自身的特点,其子系统很难使用别的子系统的数据,从而在煤炭企业内部产生了信息“孤岛”,阻碍了煤炭企业信息化进程。随着信息化技术的广泛应用和矿业信息共享的迫切需要,如何在各种异构数据中进行抽取、转换和集成,是建立共享型数据平台极为关键的问题[7]。
目前,实现异构数据库的数据集成一般有3种方法,即联邦式数据库、数据仓库和基于中间件模式方法[3]。其中,采用中间件模式集成各种异构数据源,由于不需要改变原始数据的存储和管理方式,可集中为异构数据源提供一个高层检索服务,而使其成为实现异构数据集成中较为理想的解决方案[5]。
因此,根据行业领域特点, 在不改变原始数据的存储和管理方式下,采用中间件模式,笔者提出了一种基于XML和Web Service的异构数据库集成模型,可以有效地实现矿业信息异构数据的共享。
1 矿业信息异构数据库集成模型
1.1 XML技术
XML(Extensible Markup Language)是W3C于1998年发布的一种标准,它是SGML的一个简化子集,以一种开放的自我描述的方式定义数据结构,在描述数据内容的同时能够突出对结构的描述,从而体现了数据之间的关系。XML现已成为网络系统中通用的数据交换格式[9]。相对于数据库技术, XML技术在数据应用方面具有很多优点:
(1) XML文件不受操作系统、软件平台的限制;
(2) XML容易描述数据的语义,这种描述能为计算机理解和自动处理;
(3) XML不仅可以描述结构化数据,还可以有效描述半结构化、非结构化数据。
总体上看,XML在数据应用方面具有易表义、跨平台等优势,具有很强的连接能力、对数据的自描述能力,能很好地实现异构数据库之间的透明互操作,是一个不错的交互媒介。
1.2 Web Service技术
Web Service是建立可互操作的分布式应用程序的新平台,它向外界提供一个能够通过Web进行调用的API[8]。Web Service平台是一套标准,它定义了应用程序如何在Web上实现互操作性。
Web服务体系结构是基于3种角色(服务提供者、服务注册中心和服务请求者)之间的交互。交互涉及发布、查找和绑定操作[6]等内容。图1显示了这些操作、提供这些操作的组件及它们之间的交互关系。
使用Web Service技术实现异构数据库的集成有以下优点:
(1) 通用性更强。SOAP协议是Web Service的基础,SOAP协议与其它协议相比具有更多的灵活性和通用性。
(2) 结果信息处理能力更强。异构数据库的数据处理需要在语义层次上进行。Web Service的输入输出均是标准XML格式的数据,这为异构数据库查询结果的处理提供了方便。
(3) 强大的二次开发能力。开发者可以方便地开发具有特色数据库的Web Service接口。而且只要对相应的Web Service进行简单的引用就可以根据自己的需求自行设计跨库查询系统。
(4) 完善的信息源标识功能。UDDI提供标准化的、透明的、专门描述Web服务的机制,具有发布各种Web服务描述信息的能力。利用UDDI为标识检索服务提供了一种行之有效的方法,检索系统可以根据UDDI信息有效地选择数据源。
1.3 异构数据库集成模型结构
异构数据库集成模型采用3层B/S结构:数据层、数据集成中间层、用户层,如图2所示。
(1) 数据层:
数据层是整个模型的基础,由各个异构的数据源组成,在该模型中采用SQL Server、My SQL、Oracle等,它们在不同的操作系统中,是系统的数据提供者。
(2) 数据集成中间层:
该层是模型的关键,主要由查询处理块和数据集成块组成。查询处理块采用Web 服务体系结构,接收来自用户层的用户请求,经分析分解请求之后,在服务注册中心发现相应的服务,再绑定到具体的服务提供者进行数据查询。查询结果返回给数据集成块,进行数据集成,最终返回给请求用户。查询结果可能是从多个异构数据库中提取的,先经XML合成器对查询结果进行合成,再经语法分析处理,纠正语法错误,对应XSL(Extensible Stylesheet Language)转换成用户所需要的数据格式。模型中每一个异构数据源都有1个Web服务接口,使用之前在服务注册中心注册了相应的数据服务。如果有新的异构数据源加入系统中,只需注册服务即可,有效地实现了即插即用。
(3) 用户层:
由浏览器和Web应用程序组成。
2 矿业信息集成模型的技术实现
2.1 Web服务注册
有了Web服务,各个矿业企业不再是信息孤岛式的Web应用程序站点,通过Web服务可以将它们连接起来,实现矿业信息的共享。即使各个矿业管理信息系统使用不同的操作系统、不同的数据库,只要通过Web服务注册,它们就可以共享信息。
该模型采用.NET创建、注册、使用Web服务[4]。以SQL Server数据库为例,注册Web服务的代码如下:
Oracle数据库和My SQL数据库的Web服务注册方法与上面的代码类似,只是引入的命名空间和数据库连接串不同。Oracle数据库要引入“System.Data.OracleClient”,数据库连接串是“OracleConnection conn =new OracleConnection("DataSource=MyOracleDB;UserId=username;Password=passwd;IntegratedSecurity=no")”。My SQL数据库要引入“MySql.Data.MySql-Client”,数据库连接串是“MySqlConnection Conn = new MySqlConnection("Server=Server;Database=Test;Uid=UserName;Pwd=asdasd")”。
使用这些已经注册的Web服务,即绑定服务,只需在项目中添加Web引用,选择已经注册的Web服务,添加以下的代码,就可以使用已经存在的Web服务。
2.2 XML合成器
数据集成块接收来自各个Web服务的局部XML文档,将它们合成为一个全局XML文档,最后将合成的XML文档经语法分析、处理,协同XSL,依据客户端要求的文件格式返回[1,2]。由于合成的XML文档后续处理的实现方法比较简单,在这里,笔者重点介绍XML合成器的实现。XML合成器将来自各个异构数据库的XML文档合成为1个XML文档,实现了异构数据库的数据集成[8]。假设有2个XML 文档doc1和doc2,将doc2的根元素的子结点列表合并为doc1的根元素的子集,实现代码如下:
2.3 XML数据的传输
XML数据在整个系统中的传输采用SOAP协议。SOAP (简单对象访问协议)是一个基于XML的与平台无关的通信协议,使应用程序可以用被称为SOAP消息的XML文档在Internet上通信。它被定义为轻量协议,以便在松散的分布式环境中对等地交换结构化和类型化信息。SOAP协议规范了Web Service的调用机制。同时,Web 服务器将支持数据在数据层和显示层的双向刷新机制,即可接收客户端的数据,修改并存入后端数据库,亦可将后端数据库的数据变化及时传送给客户。
借助于SOAP,异构数据库集成问题将从层次上被简化。 XML 提供了跨平台的数据编码和组织方法, 而SOAP 建立在XML 之上,定义了一种跨系统平台的信息交换的简单包装方法。绑定于HTTP 之上的SOAP 协议, 可以跨语言、跨操作系统、跨防火墙进行远程过程调用(RPC),实现了编程语言和系统平台的无关性, 大大简化了异构数据库之间的交互问题。
3 具体应用
针对大型矿业集团下属煤矿分散、信息化程度不同、各个矿内部以及矿与矿之间管理信息系统异构等问题,该模型可以有效地屏蔽异构,实现矿业信息异构数据的共享。
矿业信息异构数据库集成模型的具体实现框架如图3所示。
4 结语
基于XML技术和Web Service技术的异构数据库集成模型,利用Web服务器将数据服务封装发布出去,通过ADO .NET 对XML数据进行组织和解析,并根据解析情况执行相应的业务处理,在一定程度上解决了矿业信息异构问题。但矿业异构数据在集成过程中的用户请求分解的机制问题、安全问题有待进一步的研究。
摘要：文章结合XML和Web Service技术的优势,提出了一种矿业信息异构数据库的集成模型,详细阐述了该模型的技术实现。实践证明,在不改变原始数据的存储和管理方式下,该模型能较好地实现异构数据源统一、透明的访问,保证数据的完整性、安全性和一致性,并且具有较高的开发效率。
关键词：煤矿,信息,异构数据库,XML,WebService
参考文献
[1]WU Ze-bin,WEI Jie,LI Wei-qing,et al.Hetero-geneous Data Source Unified Search Technology Basedon Web Services[J].Computer Integrated Manu-facturing Systems,2007,13(7):1 444~1 450.
[2]BRAZHNIK O,JONES J F.Anatomy of DataIntegration[J].Journal of Biomedical Informatics,2007,40(3):252~269.
[3]ZHAO Hui-min,RAM S.Combining Schema andInstance Information for Integrating HeterogeneousData Sources[J].Data&Knowledge Engineering,2007,61(2):281~303.
[4]ARDESTANI K,HOFFMAN K,XIE D.Fast TrackADO.NET C#Edition[M].北京:清华大学出版社,2003.
[5]曾小宁,黎明.基于XML的数据交换中间件的研究与实现[J].计算机工程与设计,2007(6).
[6]崔伟.基于XML和Web服务数据集成的研究[J].计算机与数字工程,2007(6).
[7]刘开南,董立红.矿业信息异构数据的共享[J].西安科技大学学报,2007(6).
[8]张倩,王晓东.基于ADO.NET与XML的异构数据库数据交互[J].计算机技术与发展,2007(8).
数据集成模型 篇2
我国夏季雨带分布类型的集成估算模型
定义了客观、定量表征我国1951-夏季3种雨带类型变化的指数,分析了它们的年代际和年际尺度的变化特征,在此基础上提出了建立雨带类型估算模型的新方法.利用估算模型分析了大气、海洋等诸多因子对雨带类型不同尺度变化的作用,并检验了估算效果.结果表明,3种雨带类型变化是由显著的年代际和年际尺度变化叠加而成的,其中年际变化主要受El Ni(n)o/LaNi(n)a事件、东亚夏季风和西太平洋副热带高压脊线位置的.影响,而年代际变化主要受到PDO,AO,ENSO,Ni(n)o3区海温和夏季风的年代际变化的控制.雨带类型集成估算模型的估算结果表明,文中提出的分尺度估算然后再做集成的估算方法,估算准确率比不进行尺度分离有了明显提高.
作 者：魏凤英 作者单位：中国气象科学研究院灾害天气国家重点实验室,北京,100081刊 名：自然科学进展 ISTIC PKU英文刊名：PROGRESS IN NATURAL SCIENCE年，卷(期)：17(5)分类号：P4关键词：雨带类型 年际变化 年代际变化 集成 估算模型
数据集成的应用 篇3
关键词：数据集成；ETL；DI；数据仓库；数据迁移；数据合并；数据同步
中图分类号：TP393 文献标识码：A文章编号：1007-9599 (2011) 08-0000-01
The Application of Data Integration
Wu Hongwen
(Xinjiang Uygur Autonomous Region Environmental Protection Information Center,Urumqi830063,China)
Abstract:At present,most enterprises still remain in the service of only a single system of many-to-application data integration architecture,data integration architecture approach that severely restricts the efficiency of enterprise information management and data sharing.By analyzing the changes in the new enterprise data services,explained the structure of enterprise data management unit system and architecture system in such a system under implementation.
Keywords:Data integration;ETL;DI;Data warehouse;Data migration;Data merged;Data synchronization
继系统集成、应用集成、业务集成之后，最头痛的数据集成（Data Integration）已渐被各大企业纷纷触及。目前国内大多数企业还仅停留在服务于单个系统的多对一架构数据集成应用，这种架构常见于数据仓库系统领域，服务于企业的商务智能。早期那些数据集成大家大都是从ETL启蒙开始的，当时ETL自然也就成了数据集成的代名词，我们不得不再次接受新一轮的DI洗脑。
数据集成，主要是指基于企业分散的信息系统的业务数据进行再集中、再统一管理的过程，是一个渐进的过程，只要有新的、不同的数据产生，就不断有数据集成的步聚执行。企业有了五年、八年的信息化发展，凌乱、重复、歧义的数据接踵而至，数据集成的空间与需求日渐迫切，企业需要一个主数据管理（Master Data Manager）系统来统一企业的产品信息、客户信息；企业需要一个数据仓库（Data Warehouse）系统来提高领导层的决策意识，加快市场战略调整行动；企业需要一个数据中心（Data Center）系统来集中交换、分发、调度、管理企业基础数据。
数据集成的必要性、迫切性不言而喻，不断被推至企业信息化战略规划的首要位置。要实现企业数据集成的应用，不光要考虑企业急需集成的数据范围，还要从长远发展考虑数据集成的架构、能力和技术等方面内容。从数据集成应用的系统部署、业务范围、实施成熟性看主要可分三种架构。一种是单个系统数据集成架构、一种是企业统一数据集成架构、一种是机构之间数据集成架构。
单个系统数据集成架构，是国内目前大兴土木所采用的架构，主要是以数据仓库系统为代表提供服务而兴建的数据集成平台，面向企业内部如ERP、财务、OA等多各业务操作系统，集成企业所有基础明细数据，转换成统一标准，按星型结构存储，面向市场经营分析、客户行为分析等多个特有主题进行商务智能体现。这种单个系统数据集成应用架构的主要特点是多对一的架构、复杂的转换条件、TB级的数据量处理与加载，数据存储结构特殊，星型结构、多维立方体并存，数据加载层级清晰。
企业统一数据集成架构，组织结构较复杂的大型企业、政府机构尤为偏爱这种数据集成的架构，因此类单位具有业务结构相对独立、数据权力尤为敏感、数据接口复杂繁多等特征，更需要多个部门一起协商来建立一个统一的数据中心平台，来解决部门之间频繁的数据交换的需求。如金融机构、电信企业，公安、税务等政府机构，业务独立、层级管理的组织结构决定了内部数据交互的复杂性。概括来说此类应用属于多对多的架构、数据交换频繁、要有独立的数据交换存储池、数据接口与数据类型繁多等特点。
机构之间数据集成架构，这种架构多是应用于跨企业、跨机构、多个单位围绕某项或几项业务进行的业务活动，或由一个第三方机构来进行协调这些企业、机构之间的数据交换、制定统一数据标准，从而形成一个多机构之间的数据集成平台。如中国银联与各商业银行之间的应用案例、各市政府信息中心与市政府各机关单位之间的应用案例、外贸EDI（海关、检验检疫局、外汇局、银行、保险、运输等）、BTOB电子商务平台等。这类应用属于跨多企业、单位多对多的架构，具有数据网络复杂、数据安全性要求高、数据交换实时性强等特点。
以上三种数据集成架构，一种是对应于某一个应用系统的多对一架构，一种是完成企业内部众多系统之间数据交换的多对多架构，一种是为多个跨企业、单位机构实现某一项或几项业务活动而建立的多对多架构，数据集成的应用差不多都是基于这三种架构，每种架构可能会对应于多种数据集成的应用。国内企业常见的数据集成应用有数据仓库、数据同步、数据交换。随着企业并购、新旧系统升级、分布系统向数据大集中看齐、电子商务的发展、多个企业单位协同作业等等众多业务需求的诞生，数据集成的应用开始纷繁异景起来。
目前大部分数据集成都是围绕数据仓库（Data Warehousing）、数据迁移（Data Migration）、数据合并（Data Consolidation）、数据同步（Data Synchronization）、数据交换（Data Hubs或者叫主数据管理：Master Data Management）这5种常见的企业应用形式来构建企业系统应用。
数据仓库（Data Warehousing）应用：数据仓库的发展在国内差不多有近10个年头，数据仓库中的数据集成应用主要是围绕ETL的功能来实现，一般来说其主要功能是将多个业务系统不同种数据类型的数据抽取到数据仓库的ODS（Operational Data Store）层，经过转换，加载存储到星型结构的DW（Data Warehouse）层，为满足不同主题的展现应用，再向关系型数据库或多维数据库进一步汇总加载，其ETL功能可由手工编程或专业工具软件这两种类型来实现。
数据迁移（Data Migration）应用：这种应用比较容易理解，对于新旧系统升级、数据大集中时的数据作迁移，使数据更能顺应新系统的结构变化而平稳迁移。
数据合并（Data Consolidation）应用：在企业并购中很容易产生数据合并的应用，如两个企业的HR系统的合并、财务系统的合并、其它业务系统的合并，当系统需要合并必然产生数据的合并，因此对企业数据进行统一标准化、规范化、数据的补缺、数据的一致性都将导致数据合并。
数据集成模型 篇4
云计算 (cloud computing) , 是一种新兴的商业计算模型, 他将计算任务分布在大量计算机构成的资源池上, 使各种应用系统能够根据需要获取计算能力、存储空间和各种软件服务。云计算服务不仅包括网络上以应用的方式提供的服务, 还包括以提供数据中心的硬件或者系统软件为内容的服务, 我们把数据中心的软件和硬件就称之为云。Web应用和web服务放置在大型的数据中心或者大型的服务器上, 然后以服务的形式发布以供别人通过网络进行访问。
云是一个虚拟计算机资源池, 实现了将计算效能作为互联网服务进行传递。它能够动态分配虚拟或者物理计算机以部署不同工作强度的计算任务并且监控实时使用的、资源从而在需要的时候对分配的任务进行重新平衡。
2. 数据访问和集成模型的设计与实现
2.1 数据访问和集成模型设计思想
目前, 网络环境中数据访问和集成大都采用访问者直接和DBS服务接口交互。这种交互方式会强迫使用人员在应用内部解决数据访问和集成问题, 使管理者或管理机构陷入数据库连接、数据格式转换等技术问题之中, 增加了管理自动化程序开发的复杂性和重复性。显然, 对于云计算中涉及到大量分布、异构数据管理自动化系统而言, 上述策略远远不能满足需求, 这样做只能偏离问题的重点。为此, 可构建一个单一联合的“虚拟数据库系统”, 在具体实现过程中云计算单元与一个虚拟DBS联系, 这个虚拟DBS拥有和单个DBS完全一样的接口, 但实际上并不存储任何数据。虚拟DBS服务的调用由服务联合模型处理, 该模型和组成联合的各个独立的DBS接口进行交互, 由它们来计算服务调用的结果。虚拟DBS和“真正”的DBS的服务接口是相同的, 因此云计算单元能够将一些“真正的”DBS和一些虚拟DBS联合构成新的虚拟DBS, 实现虚拟数据库的扩展。新的开发策略的提出, 克服了因开发标准和服务规范的改变而使系统变得不稳定的缺陷, 同时消除了服务生命周期管理所带来的数据不一致性问题, 避免了各种应用与环境中分布、异构的数据库直接连接, 实现了信息访问和集成模型的平台无关性, 增强了管理自动化系统的可移植性、健壮性。
2.2 系统体系结构
按照云计算中数据访问和集成模型的设计模式和功能需求, 以及多层体系结构所具有的优势, 采用DAI中间件的设计模式和功能需求构建了由五层组成的数据访问和集成模型的系统架构 (图1) , 包含客户层、服务层、事务逻辑层、数据访问层、资源层。
客户层是直接面向信息战单元, 由应用程序和客户端API组成。服务层与客户层进行交互, 提供用户服务接口, 接收用户的服务请求如SQL查询或Xpath查询, 同时返回用户响应文档。事务逻辑层是整个模型的核心, 用于实现用户身份验证、数据库动态定位、数据格式转换、数据和元数据提取、数据传输、XML文档解析等功能。事务逻辑层由一些基本的下部组织和服务模块组成。服务模块有数据提取模块、元数据提取模块、格式转换模块、块读写模块、信息提取模块、XML解析模块以及全局库。每一个模块自成一个单元, 完成一定的功能, 模块之间又相互调用, 完成较为复杂的功能。全局库描述网格环境中各种异构数据库的相关信息, 并与信息提取模块一起完成数据库的动态定位。数据访问层连接着资源层和事务逻辑层, 起着承上启下的作用。数据访问层提供给事务逻辑层一个统一的接口实现数据库动态连接和数据访问。资源层是指模型所能访问的一切信息数据资源。数据资源主要是指信息战环境中分布的、异构的数据库, 如关系数据库、XML数据库。信息访问和集成多层体系结构的建立, 简化了管理自动化系统设计模式, 使得信息战单元通过不同的服务调用模式就可以实现数据访问和集成。
2.3 系统功能实现
数据访问和集成模型多层体系结构的设计, 每一层都要完成不同的功能。服务器端每一层之间的相互合作, 实现了数据库定位、数据库访问、数据传输、数据格式转换和数据库集成。
2.3.1 数据库动态定位
DAI中间件以统一的服务接口对环境中各种异构数据库进行动态访问, 确定具体访问的数据库是由用户提供的数据库元数据决定的。元数据访问模式在定位数据方面的应用, 对集成数据库有重要的影响, 因为它提出了一种两步式访问数据的方法:第一步, 先搜索元数据目录, 以定位所需要的数据库;第二步, 访问数据。两步式的访问带来的一个问题是应用写入器并不知道第二步中要访问的是哪个DBMS, 这样, 应用程序必须有足够的通用性, 能够与任何从第一步返回的DBMS相连接。这就要求所有的数据都用公共的格式保存, 或者描述数据的元数据能充分支持应用以理解格式, 并解读数据。DAI中间件采用数据库元数据来动态定位用户需求的数据库。
数据库定位由查询信息提取模块和中间件配置模块共同完成。用户提供数据库元数据, 与中间件配置模块中元数据进行匹配, 即与数据资源配置文档匹配产品信息, 与角色映射文档匹配用户名、密码, 来确定用户需要的数据库。查询信息提取模块提供一个角色映射器, 用户可以通过它完成与角色映射文档的匹配。查询信息提取模块从服务接口接收到服务请求的信息之后, 锁定角色映射文档和数据资源配置文档, 由角色映射器解析配置文档, 获取由第三方签发的证书或用户访问数据库的用户名和密码, 确定用户的访问权限。用户只有通过验证, 才能获取与用户名、密码相对应的数据库访问权限。若用户名、密码或数据库元数据任一项匹配不成功, 系统抛出异常。
2.3.2 数据库访问
为了满足元数据访问模式中数据库连接的通用性, DAI中间件提供了数据库连接管理器来完成异构数据库的访问。数据库用户账户有两种方式:私有账户、公有账户。对于公用账户, 采用数据库连接池机制, 即在服务器端建立每一个数据库相对应的连接池, 将各个连接组合起来, 这意味着数据库连接在物理上并不关闭, 而是保留在一个队列中, 可以反复使用。对于私有账户, 按照不同的数据库类型由不同的接口建立数据库连接。
数据库连接管理器采用DAO访问模式, 通过数据访问对象, 用户对数据库提交操作请求时可以有两种方式:一是提交单一的数据库操作请求;二是提交批处理操作请求。根据提交命令参数的不同, 连接管理器提供不同的接口来完成。对于单一的数据库操作请求, 按照不同的操作语句连接管理器直接进行处理。在进行批处理操作时, 系统把批处理请求作为一个事务进行处理。该事务要么成功的实现它的完整性并且能够被提交, 要么在它的中间某个位置上运行失败。在这种情况下, 可在每一个操作请求执行之前设立一个存储点, 当程序运行到这个存储点时, 系统自动对前面已经执行的程序结果进行保存。若当前的操作请求能够成功执行, 则系统执行下一个操作或返回结果。若执行过程中由于某种原因导致操作不能成功执行, 程序就回滚到存储点重复执行此操作, 直到操作成功, 系统转入下一个操作步骤, 或者由于此线程超过线程最大运行时间而抛出异常。存储点的设立保证了批处理操作中每一个请求都能够执行。
2.3.3 数据格式转换
数据库访问所获得的结果数据最终都统一以XML数据格式进行交付, 因此必须对所有获取的数据进行相应数据格式转换。中间件数据的转换过程主要涉及到两个方面, XSLT转换:实现XML数据库到关系数据库数据格式的转换;WebRowSet转换:实现ResultSet对象到WebRowSet对象数据格式的相互转换。
XSLT格式转换过程中用DOM对数据源进行解析, 根据样式表述的要求, 输出的结果序列化为结果XML文档。完成转换的XSLT模板可以由用户通过查询XML数据库数据属性来进行编写, 也可以由服务器管理员事先完成各种XSLT模板的编写, 存放在指定位置, 用户在需要时只需要在程序中指定模板的相对位置即可。在转换过程中, 用户查询XML数据库获取数据, XML解析模块完成XML文档的DOM解析, 将数据写入缓存, 然后启动一个线程, 从缓存中读取数据块写入管道。程序主线程从管道中读取数据块, 按照XSLT模板的要求, 完成数据到WebRowSet数据格式的转换。整个数据转换的过程全部在内存中完成, 这样对主机环境要求比较高。
WebRowSet XML Schema规定了填充WebRowSe对象的基本内容, 所以完全拥有以自我描述的格式来填充数据库的强大选择权。WebRowSet XML Schema规定了以下内容:
·
·
·元素, 它包含了从数据返回的每一条数据记录相对应的
ResultSet对象是关系数据库查询返回的结果表, 服务器端与用户端ResultSet对象转换过程是双向的。从ResultSet对象到WebRowSet对象是一个构建过程, 相反则是一个Web Row Set XML文档的解析过程。WebRowSet对象到ResultSet对象的转换只是利用XML解析模块对WebRowSet对象进行解析就可实现数据格式的转换。
2.3.4 安全控制模块
中间件配置后加入到由其它中间件构成的数据共享网络, 通过安全控制模快配置中间件在数据共享网络中共享自身的哪些数据信息, 及数据共享到怎样的程度, 网络中哪些中间件能够访问自身等等。
3. 结论
本文在分析和研究云计算环境下中信息访问和集成需求的基础上, 提出了信息访问和集成模型实现策略——“虚拟数据库系统”, 并构建了由五层组成的数据访问和集成模型的系统架构。数据访问和集成模型不仅提高了系统访问数据的速度, 同时还具有可维护性、可扩展性、可操作性、通用标准性, 经授权认证的合法用户通过“虚拟数据库系统”提供的标准访问接口及统一数据格式对商业信息环境中各种分布的、异构的、不同种类的信息资源进行动态访问和集成, 以此来提高信息的可访性、可用性、时效性、安全性。
摘要：本文提出了一种信息访问和集成模型的实现策略, 即在不同种类的信息资源和信息应用之间构建一个中间层软件——“虚拟数据库系统”, 通过“虚拟数据库系统”提供的标准访问接口及统一数据格式对云计算环境中各种分布的、异构的、不同种类的信息资源进行动态访问和集成, 以此来提高信息的可访性、可用性、时效性、安全性。
关键词：云计算,虚拟数据库,数据访问,数据集成,信息定位
参考文献
[1]Harvey M.Deitel (美) , 等.Java Web服务高级教程[M].邱仲潘, 等译.北京:机械工业出版社, 2003.
[2]都志辉, 陈渝, 刘鹏.网格计算[M].北京:清华大学出版社, 2002.
[3]HayesB.Cloud computing[J].Commun ACM, 2008, 51 (7) :9-11.
[4]Greg Boss, Padma Malladi, Dennis Quan, etal.Cloud Computing[J].IBM White Paper, 2007.
制造业供应链集成模型研究综述 篇5
制造业供应链集成模型研究综述
对供应链集成模型进行了分类,提出了供应链的.决策层次维、职能维以及技术维三维集成模型.按三个分类维度,回顾了近年来有关供应链集成的文献,重点是有关供应链集成模型的研究,并结合制造行业的特点给出了今后研究的方向.
作 者：尹钢 作者单位：华南理工大学,自动化科学与工程学院,广东,广州,510640 刊 名：广东工业大学学报 ISTIC英文刊名：JOURNAL OF GUANGDONG UNIVERSITY OF TECHNOLOGY 年，卷(期)： 21(2) 分类号：F270.7 关键词：供应链管理 集成模型 制造业
数据集成模型 篇6
Web服务技术凭借其松散耦合性、平台无关性和语言无关性,被广泛应用于数字化校园建设当中[1,2,3],很好地解决了校园异构系统之间的数据集成的问题。虽然基于Web服务的校园数据集成系统运行于较为安全的局域网内,但从发展的眼光去看,学校的信息化建设绝不仅仅局限于校园网内,那么Web服务潜在的安全问题是不容忽视的。
目前校园数据集成安全解决方案主要依赖于传统的SSL/TLS方案,SSL/TLS是基于HTTP协议的安全保护方案,技术比较成熟,但是它本身也存在许多局限性[4],性能低下,不能实现端到端消息级别的安全保障。WS-Security能够实现端到端的SOAP消息调用的安全保护,解决了SSL/TLS方案存在的问题。本文研究了WS-Security和以其为基础的相关规范[5,6,7],结合SSL/TLS,设计了基于WS-Security的校园数据集成的安全模型,并在.NET平台上借助WSE3.0实现了该模型,对于数字化校园及企业信息集成的安全解决方案有参考价值。
1 Web服务安全性相关技术
1.1 WS-Security安全规范
WS-Security是IBM、Microsoft、VeriSign公司于2002年4月5日联合发布的安全规范。WS-Security通过SOAP消息扩展,在消息头部加入安全元素<security>及其子元素,这些子元素可以是身份标识的安全令牌,也可以是签名和加密的安全元素,分别用来提供身份认证、消息完整性、数据机密性的安全保护。
(1) 身份认证
WS-Security提供了把安全性令牌与SOAP消息相关联的通用机制,消息接收方通过验证发送方提供令牌的有效性来确认发送方请求的合法性,然后根据发送方的身份进行授权资源的访问。
(2) 消息完整性
WS-Security使用XML签名实现消息完整性保护。XML签名不同于其他签名技术在于它支持部分签名,即对XML文档中某部分(比如某元素)进行签名。
(3) 消息机密性
WS-Security使用XML加密技术实现消息机密性保护。XML加密技术支持对SOAP消息的部分加密,可以提高效率。加密数据时,可以选择使用对称加密或不对称加密。最新版本的WS-Security1.1规范,支持对称加密,提供了更好的性能。
1.2 WS-SecureConversation
在复杂的应用场景下,通信双方需要多次交换消息,建立安全的上下文是必要的,此外用于签名加密的密钥产生机制也属于安全性需要考虑的范围。
WS-SecureConversation在WS-Security的基础上提供了安全会话上下文的建立和共享,以及派生会话密钥的机制。通过派生的会话密钥,给密钥一个生存周期,使用此密钥对数据进行加密,具有更好的安全性。由于同一个共享秘密可以派生出多个共享密钥,如果用于加密和签名的密钥不同,安全性又得到进一步提高。
2 Web服务安全模型的设计
广西师范大学数字化校园建设,是以教务系统为中心的各项业务应用的集成与数据共享。各个部门内部系统采用二次开发策略,以Web服务作为其他系统或者统一信息平台访问本系统公开数据的接口。本文研究的主要问题是,如何在Web环境中对Web服务提供安全保障。
根据调研分析,本系统的安全需求及相应的安全策略设计如下:
(1) 用户身份识别 系统必须能够识别服务请求者的身份是否合法。身份验证方式的选取综合考虑安全性和管理的简易性。系统主要分为两类用户:一般学生用户和部门用户。学生用户比较多,主要操作是信息查询,数据的安全性保护要求不高,采用用户名密码令牌方式进行身份验证;而部门用户数量不大,主要完成大多数业务操作,而且对数据的安全性保护有较高的要求,应采取X.509证书进行身份验证。
(2) 不同角色用户拥有不同的系统使用权 系统应该具有授权访问控制的功能。由于系统的用户群比较大,如果为每个用户指派Web服务访问权限,那么管理起来将非常困难。本系统采用RBAC的思想,将用户进行角色分类,并将具体的用户指派为某种角色,而权限与角色关联,从而实现Web服务的访问控制功能。
(3) 保证数据的完整性 数据完整性业务有效执行的保障。比如在学生网上选课扣费过程中,课程收费标准一旦被修改,选课费用的扣除将会得出错误的结果。本系统采用WS-Security规范支持的XML签名技术保证数据的完整性。
(4) 部分敏感数据需要加密 系统进行业务处理涉及的部分敏感数据是需要机密性保护的。比如用户的账号密码、学生收费相关的信息。而对于一些譬如课程信息的非敏感信息,不需要加密保护。本系统采用WS-Security规范支持的XML加密技术可以实现数据的选择性加密。
(5) 大量数据交换时,需要建立共享安全上下文 当在复杂的应用场景下,通信双方需要多次交换消息,建立安全的上下文是必要的。比如选课扣费操作、要组合收费标准查询、所选课程信息查询等服务,其间会有多次的信息交换。Ws-SecureConversation可以有效解决共享安全上下文建立的问题。
(6) CA证书的获取与管理的安全问题 数据的签名和加密需要有效的CA证书,证书的请求和颁发的安全问题也是系统要考虑的问题之一。由于系统运行于校园网内,可采用Windows 2003 Server自带的证书服务构建一个基于校园网的私有CA。证书的请求和颁发使用SSL进行安全保障。
图1是基于以上提出的基于WS-Security及相关规范的Web服务安全模型。
3 模型的实现
本系统采用Visual Studio 2005开发环境,辅助Microsoft WSE3.0安全插件,对基于.NET平台的Web服务进行安全性设计,构建了一个安全保障模型。
3.1 WSE3.0
Microsoft 公司提供Web服务的增强开发组件Web Services Enhancements(WSE) 3.0 支持最新的WS-*安全规范,包括WS-Security1.1,WS-SecureConversation,WS-Trust,WS-Policy。WSE3.0的体系结构模型基于处理入站和出站SOAP消息的过滤器管道,它根据定义的安全断言和消息的出入方式自动选择响应的过滤器进行消息的安全处理。最为重要的是,WSE3.0具有可扩展性,支持自定义安全断言,用户根据自身的需求,定制合适的安全策略及相关的输入输出过滤器进行SOAP消息保护,使得WS-Security的灵活性得到了充分的体现。
3.2 实现步骤
(1) 证书的生成和管理
采用Windows 2003 Server自带的证书服务构建一个基于校园网的私有CA。证书的申请和颁发过程中的安全使用SSL方案。各用户获取证书后,安装到本地证书库,以便以后使用。
(2) 辅助类定义
自定义用户管理类MyUsernameTokeManager和MyX509TokenManager。这两个类分别进行用户名密码令牌和X.509证书令牌的管理,从而实现用户身份的验证功能。
(3) 创建自定义安全断言类
WSE3.0内置的安全策略断言只能满足一些简单的安全需求。对于实际应用中比较复杂的安全需求,需要制定对应的安全策略。本系统定义了PolicyChoiceAssertion、RequestMethodAssertion、PartsProtectAssertion断言类,分别用于实现不同角色用户采用不同的访问方式、不同的服务使用不同的消息保护方式、部分数据的签名加密功能。这三个类要求从系统给出的与安全特性相关的断言类SecurityPolicyAssertion中继承,并重载相关的方法实现过滤器的指定和策略文件的解析功能。
(4) 创建自定义筛选器类
创建上述自定义断言类相关的自定义筛选器类以实现不同的Web服务安全需求。在筛选其中,重载构造函数,用以获取用户的安全令牌、需要安全保护的方法列表、需要签名加密的元素或者内容。此外,在输出过滤器中,重载SecureMessage方法,实现具体的消息签名加密功能;在输入过滤器中,重载ValidateMessageSecurity方法,用以实现验证消息的功能。
(5) 策略文件的定义
一个策略文件通常可以包含多个策略,所以客户端和服务端各建一个策略文件即可,策略文件是一个XML格式的文档,该文件名默认为wse3policyCache.config。首先,在策略文件中的<extention>下加入自定义策略断言的类引用声明;然后再定义具体的安全策略元素<policy>。部分策略文件代码如下:
<policies xmlns="….">
<extensions> //斜体为自定义安全断言
<extension name="PolicyChoice" type="CustomPolicyAssertionLib. PolicyChoiceAssertion, CustomPolicyAssertionLib " />
<extension name="RequestMethod" type="CustomPolicyAssertionLib. RequestMethodAssertion, CustomPolicyAssertionLib " />
<extension name="partsProtect" type="CustomPolicyAssertionLib. PartsProtectAssertion, CustomPolicyAssertionLib " />…
</extentions>
<policy name="sPolicy">
<partsProtect>
<clientToken ……/> //客户端令牌
<serviceToken ……/> //服务端令牌
<protection requestAction="http://tempuri.org/GetStandard">
<request signatureOptions="…" encryptBody="false" /><response …../> <fault ……/></protection >
</ partsProtect>
</policy>……
</policies>
(6) 将安全策略应用到服务端和客户端
对于服务端,添加自定义安全断言类的引用,并在Web服务定义文件中,比如xfService.cs头部,类之前添入属性[Policy("sPolicy")]代码。
在客户端,添加自定义安全断言类的引用,添加Web服务引用后,自动生成Web服务的代理类,定义此代理类的实例,然后调用相关的函数。如:
XfRef.XfServiceWse xfs = new XfServiceWse();
xfs.SetPolicy("CPolicy");……… //调用web服务函数
(7) 增强Web服务器的安全
将Web服务部署到IIS服务器后,进行IIS配置和ASP.NET配置(配置身份验证,配置模拟和授权)。确保.NET平台对Web服务安全的保障。
3.3 实验结果分析
下面以查询学生信息服务public DataSet getStudent(string Xh)为例子,通过WSE3.0自带的SOAP消息追踪工具,记录实验结果,再进行SSL方案与本文所设计的方案实验结果的比较。
Service端返回的未经过安全处理的原始SOAP消息如下(简要格式):
<soap:Envelope….>
<soap:Body>…<NewDataSet xmlns=""><Table….>
<xh>2002070151</xh>
<xm>杨家艳</xm>
<class_Name>02级计算机科技</class_Name>
<wbbjh>B080680201</wbbjh>
<Acount>2103267901200911734</Acount>
<CardId>9558802103111027884</CardId>
</Table>……
</soap:Body>
</soap:Envelope>
使用了SSL方案后,在任意消息接收端(可包括中间节点)截取到的SOAP消息主体和原始消息无异,以明文的形式呈现。只是添加了头部验证信息,粗体部分。
<processingStep description="Processed message">
<soap:Envelope….><soap:header…..> <soap:header/>
<soap:Body>…<NewDataSet xmlns=""><Table….>
<xh>2002070151</xh>
<xm>杨家艳</xm>
<class_Name>02级计算机科技</class_Name>
<wbbjh>B080680201</wbbjh>
<Acount>2103267901200911734</Acount>
<CardId>9558802103111027884</CardId>
</Table>………..
</soap:Body>
</soap:Envelope>
使用本方案截取到的SOAP消息,加密的部分(粗体显示)到接收端点仍为密文形式存在,具有加密持久性,解决了SSL方案只能在传输过程中加密, 在节点以明文呈现的缺点。此外,该方案使用非对称算法(RSA)加密密钥,得出< EncryptedKey>(黑体部分),再用对称算法加密数据部分,并且可只对消息敏感部分(如CardId)加密,相对于SSL方案的非对称加密,性能有了提高。
<processingStep description="Processed message">
<soap:Envelope xmlns:soap=…….>
<soap:Header>
<wsse:Security soap:mustUnderstand="1">…
<xenc:EncryptedKey ……>
<xenc:EncryptionMethod
Algorithm="…#rsa-oaep-mgf1p"> //rsa算法
…
</xenc:EncryptionMethod>
<KeyInfo xmlns="…">
<wsse:SecurityTokenReference>
<wsse:KeyIdentifier ValueType="…#ThumbprintSHA1" EncodingType="…#Base64Binary">f6qxBnUNJkWtAqKzuIG
vOlmEAaw=</wsse:KeyIdentifier>
</wsse:SecurityTokenReference>
<xenc:CipherData>
<xenc:CipherValue>SBpTN…….XB5U+VChM0=</xenc:CipherValue></xenc:CipherData>
<xenc:ReferenceList> //加密URI引用
<xenc:DataReference
URI="#Enc-bf76abf3-f8b1-42fb-89d1-de35f9491b01" />
<xenc:DataReference
URI="#Enc-8400edc4-6288-494c-93b3-e72597a190e3" />
</xenc:ReferenceList>
</xenc:EncryptedKey>
<wsse:BinarySecurityToken …wsu:Id="SecurityToken-c27a7a0e-e85b-4cf5-8960-579444d28ee3">
<xenc:EncryptedData
Id="Enc--8400edc4-6288-494c-93b3-e72597a190e3" …/>
…….
</xenc:EncryptedData>
</wsse:BinarySecurityToken>
<Signature xmlns="…/xmldsig#">….. </Signature>
</wsse:Security> </soap:Header>
<soap:Body wsu:Id="#BodyId "> ….<NewDataSet xmlns="">…
<xh>2002070151</xh>
<xm>杨家艳</xm>
<class_Name>02级计算机科技</class_Name>
<wbbjh>B080680201</wbbjh>
<Acount>2103267901200911734</Acount>
<CardId wsu:Id="…..">
<xenc:EncryptedData
Id="Enc-bf76abf3-f8b1-42fb-89d1-de35f9491b01" Type="…..#Content" >
<xenc:EncryptionMethod
Algorithm="…./xmlenc#aes256-cbc" /> //对称加密算法
<xenc:CipherData>
<xenc:CipherValue>SL7k2Klk+lyVJtby……quCbA1</xenc:CipherValue>
</xenc:CipherData>
</xenc:EncryptedData>
</CardId></Table></NewDataSet>…
</soap:Body>
</soap:Envelope>
4 总结与展望
本文针对WEB服务存在的主要安全问题及其研究现状进行了分析与总结,深入研究了WS-Security、WS-SecureConversation和WS-Trust等相关安全规范,设计了基于.NET平台的安全服务模型,并实现了该模型。但是,由于WEB服务的安全性涉及到各阶段(发布阶段,请求阶段和绑定阶段),本文的主要研究还局限于SOAP消息通讯的安全,对于WEB服务的发布,其安全性需要进一步的研究;此外,本文模型的实现,客户端和服务端都是基于.NET平台的,后续研究的另一个重点是异构平台下WEB服务的安全性。
本文作者的创新点:设计了基于WS-Security的校园数据集成的安全模型,并在.NET平台上借助WSE3.0实现了该模型,对于数字化校园及企业信息集成的安全解决方案有参考价值。
摘要：Web服务被广泛应用于校园数据集成当中,其安全问题也日益受到重视。在分析现有的安全解决方案SSL/TLS存在的缺陷的基础上,以教务管理信息系统和财务管理信息系统的数据共享服务为背景,研究了WS-Security及以其为基础的WS-Secure-Conversation、WS-Trust等规范。结合SSL/TLS优势,设计了基于WS-*的Web服务安全模型,并在.NET平台上使用WSE3.0实现了该模型,对于数字化校园及企业信息集成的安全解决方案有参考价值。
关键词：WS-Security,WS-SecureConversation,WS-Policy,WSE3.0,数据集成
参考文献
[1]李培峰,朱巧明.基于web服务的校园信息化平台的设计与实现[J].计算机工程与设计,2006(10).
[2]何勇,陈世平.基于的校园数据共享的设计与实现[J].计算机应用与软件,2005(10):64-661.
[3]张学旺,汪林林,马中峰.数字化校园综合应用软件平台的关键技术[J].计算机工程,2007,33(23):267-269,272.
[4]汤卫东,周永权.Web服务消息级安全模型的设计及评价[J].计算机工程与设计,2006,27(10):1873-1875.
[5]WS-SecureConversation[EB/OL].http://www.microsoft.com/china/ms-dn/liberary/webservices/WebServicesSecureConversationLanguage.mspx.
[6]WS-Trust1.3[S].http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html.
数据集成模型 篇7
关键词：异构数据,数据集成,对象树模型,XML
一、引言
随着计算机网络和分布式系统的发展, 异构数据源的数量不断增多, 并且随着经济的飞速发展和资源共享的迫切需求使得异构数据库成为现今数据库应用技术的研究热点。我们解决问题的思路是利用XML技术, 把它作为不同数据源的中间数据格式, 将来自不同数据源的数据统一到虚拟XML文件这个框架下, 进行转化和加工, 以实现大规模的异构、分布数据的共享和利用。
XML (Extensible Markup Language) 它是由W3C组织于1998年2月制定的一种通用语言规范, 是SGML的简化子集, 专门为W e b应用程序而设计。X M L作为一种可扩展性标记语言, 其自描述性使其非常适用于不同应用间的数据交换, 而且这种交换是不以预先规定一组数据结构定义为前提。X M L最大的优点是它对数据描述和数据传送能力, 因此具备很强的开放性。应用X M L对数据进行集成是现在应用最广的一种数据集成方法, 这与网络的迅速发展有关。但现在利用X M L对异构数据进行集成主要的应用也是集中在数据库或结构化数据源上, 也有少量应用在半结构化数据源上的例子, 不过总是偏重于解决同一结构化的数据源的集成。
二、在“数据树”的基础上建立对象树模型
数据树 (Data Tree) 模型不同于一般的数据模型, 它的出发点是提供异构数据源集成的统一数据抽象, 特别是要便于集成那些没有预知模式的数据。现实世界的对象往往具有某些共性, 我们将具有共性的一类对象归并成数据树。正如用关系代数描述关系运算一样, 数据树代数用对数据树的运算表达查询。我们对数据树定义八种运算, 它们分别为数据树并、数据树差、数据树交、数据树选择、数据树投影、数据树反投影、数据树连接和数据树除运算。数据树代数满足封闭特性, 即数据树运算的结果仍是一棵数据树。
对象树模型 (OTM:Object Tree Model) 的建立是用于异构数据的统一模型, 不仅适用于结构化数据和半结构化数据, 同时尝试把非结构化数据加入到模型中。这使采集到的数据信息的输出方式都使用这种数据模型, 以屏蔽数据结构模型上的异构性。O T M是建立在数据树的基础之上, 但对数据树进行改进, 并有一定区别, 使其更适用于异构数据集成的应用, 同时对象的概念是O T M的核心, 这对数据映射有着重要的影响。
三、对象树与XML DOM
对象树和X M L文档对象模型在数据结构上都是树, 而且都是由对象嵌套所形成的树, 树作为一种常用的数据结构模型, 使得我们很容易对它们进行理解和使用。因为具有相同的数据结构模型, 它们拥有树所固有的特性, 如进行递规, 进行数据浏览等。对象树由于是从“数据树”的基础上建立起来的, 它具有数据树的代数运算, 如果我们对X M L D O M树同样就行扩展, 这些代数运算也能得到适用。
对于异构数据, 集成的数据信息统一以OTM数据模型格式的XML Scheme文档进行存储。这样无论是结构化数据、半结构化数据, 还是非结构化数据, 在数据管理平台上的表现形式都是一致的, 同时我们可以通过XML DOM树实现对象树中的数据操作。
映射关系规则:
1) 对象树OT (#oid, s) , 则oid是XML Scheme中的根元素<root>;
2) OT1 (oid1, s1) 是OT的子树, 则oid1是<root>的子元素<node1>;
3) OT2 (oid11, s11) 是OT1的子树, 则oid11是<node1>的子元素<node11>;
4) 如此不断反复递规, 直到将对象树OT的所有节点都转换成XML Scheme的元素, 则映射完成。
在映射关系规则的定义中, 我们可以看出对象树到XML Scheme的映射是一个遍历树的递规过程。我们首先把对象树的根映射成XML Scheme的根元素, 再将其第一棵子树的根映射成为根元素的子元素。如此反复, 若当前子树O T′的s′集合为空时, 即当前节点为叶子节点时, 执行映射后将进行对象树的下一棵子树的遍历;若此时对象树的所有子树都已经遍历完成, 则停止。映射结束时, 就生成了一个完整的XML Scheme文档。下面, 我们举例来说明对映射规则。
假设学生信息管理网站中的一个XML文档中含有下面的信息:
则我们可以得到一棵数据树T-info为:
再将数据树中的结点对象化, 便可得到对应的对象树, 如图2所示。
Pic.jpg是一个图像文件, 它具有以下属性:
Name:Pic.jpg, Type:JP Gimage, Size:168KB, Created:2005-10-1, Location:E:Picture, Read_write:Read-only。
则我们可以通过对象树的定义, 得到一棵与之对应的对象树。如图3所示。
对于结构化数据, 我们将其除了值以外的对象树节点对象的属性转换成元素节点的属性;同时由于元素名不能包括空格, 需要把包含有空格的节点对象名去掉之后才能作为元素名, 这一规定适合所有异构数据。通过映射关系, 结构化数据、半结构化数据和非结构化数据具有统一的表现和存储形式, 这是本文的关键所在。
四、结论
本文在引入“数据树”理论的基础上, 设计了对象树模型, 实现对异构数据统一建模并进行数据映射, 其优点在于使采集到的异构数据以统一形式的X M L Scheme表现出来, 同时以的XML文件对数据信息进行存储, 使对异构数据的管理和查询更为容易实现, 也更易于系统间的交换和共享。随着计算机技术发展, 我们有理由相信, XML同数据库的相结合将随着X M L技术的发展, 会实现更强大的功能。
参考文献
[1] 高明, 宋瀚涛.异构数据源集成应用模型及其查询处理方法.计算机工程.2003;24 (9) :91-93
[2] 李冠宇, 刘军, 张俊.分布式异构数据集成系统的研究与实现.计算机应用研究.2004;3:96-98
[3] 董玉萍, 邹承明, 钟珞.基于XML的异构数据源共享技术的研究.武汉理工大学学报.2002;24 (9) :90-92
数据集成模型 篇8
机械制造业由于物料品种规格多,生产制造过程复杂,势必造成管理也是最复杂的,面对竞争激烈的机械制造业市场,利用信息化技术的和数据仓库技术进行复杂的数据分析和决策,可使企业更快的响应市场需求,做出迅速、准确的决策分析,提高企业竞争能力。本文以典型的机械制造企业为例,对企业信息集成、数据仓库的结构和数据模型进行研究。
1 机械制造业管理的特点
我国机械制造业是发展较早的企业,大、中、小规模并存,且遍及各地,在生产过程中已经积累了大量的成功技术和经验,其管理的特点主要是生产、供销、资产、人事、财务等各部门组成一个有机的整体,企业运行时各部门之间存在大量信息交换。如果这些信息交换用传统的人工方法管理,则可能出现下列情况:1)基础数据不完善,信息分散、不及时、不准确、不共享等情况,这会大大影响管理决策的科学性。2)缺乏标准化、规范化、制度化、程式化的管理,管理的优劣因人而异。3)管理工具落后,没有实现信息的共享和资源的优化配置。
随着世界经济一体化的形成,市场竞争越来越激烈,要求企业产品更新换代快、产品质量高、价格低、交货及时、服务好,这就要借助于信息现代化技术改善企业管理的模式、管理方法、管理手段、组织结构、业务流程等,增强决策和竞争能力。
2 机械制造企业信息集成过程
2.1 机械制造企业信息集成过程分析
机械制造企业信息系统包含IT资源和业务应用两部分,IT资源主要由各种业务信息及其相应的基础IT构架组成。基础IT构架包含网络、服务器、个人计算机及存储、输入、输出、安全备份等设备,用来完成业务信息的获取、加工和使用主要由业务应用系统来完成以实现相应的业务处理、分析和决策功能和过程。
一个机械制造企业中有战略管理、人力资源管理、产品开发、产品制造、采购、销售和客户管理及决策服务等过程。业务过程的组织与协调运行水平决定了企业的工作效率,也就决定了企业的竞争力。由组织结构、人员、业务过程及相应的资源共同组成机械制造企业系统如图1所示,业务活动和业务过程的执行需要业务应用系统的支持,而IT资源负责业务信息的存储、转换和传递工作。
2.2 从机械制造企业模型到信息系统的实施过程
以机械制造企业模型为基础,以企业战略、信息系统战略和信息系统的实施及运行维护之间的正确信息影射和同步互动作为企业业务体系到信息系统实施过程的核心,强调信息的一致性、系统的柔性和可配置性。通过实施一体化的企业信息系统来实现企业的集成,企业模型为企业信息和业务信息提供了模型化的表示方式,它为企业决策层、IT部门以及系统提供商等不同参与者提供对企业和信息系统共同理解的平台和交流媒介。其信息转换过程如图2所示。
2.2.1 业务策略及业务体系规划
首先根据机械制造企业现状建立面向产品全生命周期的需求层企业模型,其核心内容是机械制造企业宏观的业务模型,它以企业业务过程为核心,并集成企业组织结构的相关内容,目的是通过该模型对企业业务现状进行分析和诊断,来发现企业存在的问题,对相应的业务过程进行优化。
企业核心业务过程的确定为实施信息化的方式、时间、风险等因素的决策和分析提供了依据。
2.2.2 信息系统规划
信息系统规划包括系统战略规划和信息资源规划,需要完成的是实现机械制造企业业务系统框架到信息系统框架的转化。信息系统框架包含的内容主要有企业整体信息的功能结构、数据结构、集成框架以及信息系统实施策略、实施方法、实施计划。
根据优化后的业务核心模型的功能需求,从中抽取得到信息系统需要实现的业务功能单元和功能结构,并且将过程中涉及到的活动、活动之间的逻辑关系和活动之间的数据流影射为这些功能单元所需要执行的功能操作、功能单元之间的交互关系以及不同功能单元之间的数据流。然后将所得到的功能单元配置成的信息系统中的子系统或者系统组件,再将所有功能单元使用和传递的各种可以结构化的数据抽取整理成为信息模型,最后再根据业务核心模型中描述的业务过程所关联的产品信息、组织信息和资源信息,确定未来数据库的系统分布结构、信息系统的网络结构,并在此基础上建立信息系统的集成框架。
2.2.3 信息系统实施
在一般情况下,基础结构和集成框架在设计和实施上都采用基于组件的方式,那么在企业业务功能和组件之间建立影射关系,实现信息系统模型到组件之间的一对一的影射,由此可以建立功能参考模型和系统摸板之间的影射信息系统的实施。
将宏观业务过程细化到由若干具体的功能操作组成的业务操作过程模型,可以用伪码的形式表达,以方便地实现与程序代码的转换,然后转换为UML模型,由CASE或ROSE来完成组件代码的自动生成,并将其存储到组件库中,并与功能单元建立影射关系。
2.2.4 信息系统运行与维护
基于工作流模型的信息系统运行管理和控制系统可以自动完成信息系统的运行和管理功能,通过工作流管理系统提供的运行维护功能建立有效的系统日志和数据仓库,利用数据分析技术可以对日志数据进行挖掘分析,来评价信息系统的运行性能,及时发现新鲜系统存在的错误和潜在的问题,及时完成系统的维护工作。
3 机械制造业信息系统数据仓库的数据模型设计
机械制造业的数据仓库采用“自底向上”的模式建立。数据仓库的实施步骤为:分析企业的信息结构,建立各个部门和分系统的数据集市,在数据集市的基础上建立数据仓库。
机械制造业信息系统的层次结构分为战略决策层、管理控制层和作业处理层。战略决策层对应厂级管理层,这一层的信息来源和输出数据库是企业级的数据仓库和部分数据集市。管理控制层对应各职能科室管理业务,各职能部门用相应的子系统对产品设计、生产制造、产品质量和产品销售进行全面计划与控制。信息来源与输出是部门级分数据集市和操作性数据库。作业处理层对应车间、仓库等发生大量作业数据,信息来源与输出是操作性数据库。
3.1 数据集市的开发
机械制造业的信息包括销售信息、产品信息、技术信息、工艺信息以及生产状态信息等几类,将这些信息分类映射到信息系统不同的分系统中,这种映射是多维的。
对于机械制造业的信息系统需要建立的数据集市有对应生产经营、工程设计、生产线管理与自动化和质量管理四个分系统。建立面向信息访问和决策分析的部门级数据集市,将少量部门的数据集市综合成真正分系统级的数据集市。
3.2 建立企业级的数据仓库
在各个分系统的数据集市和企业的业务数据库基础上,建立全企业范围的数据仓库。对于面向主题的数据仓库设计,可以用信息包图设计、星形图或雪花模型图设计和物理数据模型设计。
4 结束语
采用数据仓库的数据模型设计,可解决企业经营管理中存在的一些问题,提高了企业的信息共享度和集成度,提高企业生产效率和经济效益。
利用先进的企业集成技术和数据仓库技术对机械制造企业进行企业集成、数据分析和决策,可使机械制造企业提高生产效率和经济效益,更快的响应市场需求,做出迅速、准确的决策,提高竞争能力。
参考文献
[1]蒋明炜.机械制造业信息化探讨[J].洞察,2008,(3):60-62.
数据集成模型 篇9
关键词：数据集成,异构数据库
一、引言
目前很多高校在信息化建设过程中的现状是:一方面由于学校早期的信息化管理缺乏统一的规划和信息标准, 各部门管理信息系统在很大程度上是在独立运行, 也就是大家通常说的“信息孤岛”, 而且在缺乏总体规划的情况下, 应用系统建设的越多, “信息孤岛”现象就越严重。另一方面, 随着学校信息化建设步伐的加快, 部门间信息流通的需要会越来越强烈, 信息标准化和信息资源的共享及流通问题越来越突出。
具体表现在:第一, 学校信息化建设的应用领域不断延伸, 已覆盖了全校办公、教学、科研、财务、图书等学校的各项事务。第二, 部门信息系统之间的差别, 如各部门根据自己的业务需要, 建立了各种信息系统。它们之间存在的开发工具不同, 操作系统不同等情况;第三, 学校的信息资源由于缺乏统一标准和规范而无法实现共享, 影响着学校教育信息基本数据的收集、交换和应用。第四, 全部重新改造学校各部门管理信息系统和相关工作人员培训的成本太高, 周期太长。
综上所述, 在学校各部门信息系统已经存在的情况下, 在全校范围内需要建立一个统一的信息集成平台对分散在各应用系统中的异构数据进行整合, 使校园内的各个信息管理系统达到无缝连接。
本文提出了一种基于ODI的异构数据集成方案, 与其他异构数据集成方案相比, 它的特点是可以方便灵活得将新的业务系统集成进来, 具有很好的扩展性。而且具有不同于传统工具的独特核心特性—异构E-LT、声明设计和知识模块等, 符合高性能、灵活性、高生产率、模块化的集成平台的需求。
二、异构数据集成
1、异构数据集成的模式
(1) 集成模式 (联邦数据库)
集成模式对应的就是联邦数据库的模式, 即从集成的应用角度, 在异构数据的情况下, 提供统一的访问视图来满足应用对数据的集成需求。
(2) 复制模式 (数据仓库方法)
复制模式对应的就是数据仓库的建设方法, 也就是通常所说的ETL过程, 目的是把数据进行复制, 然后加以利用的过程。
2、异构数据集成的难点
(1) 异构 (体系异构、模式异构)
数据集成的异构, 一方面是体系上的异构, 主要是指各类差异化较大的数据源类型, 异构体现在对数据的描述的差异, 例如Oracle的Char类型, 对应Excel中的Varchar, 对应JMSQueue中的Fix String。这种映射关系体现了不同体系数据源的异构性。
另一方面, 即使对于同一种体系下的数据源, 例如同样是关系型数据库, Oracle与DB2 也存在模式上的异构。具体体现为Oracle的Long Row类型, 对应为DB2UDB中的BLOB类型, 对应于DB2/400 的Varchar () forbitdata。这种类型的异构就是模式上的异构体现。
(2) 语义转换 (语义识别、语义冲突)
数据集成的过程中, 最大的障碍就是找到源和目标的映射关系, 这也是数据处理的最为复杂、最难以处理的过程。映射关系就是要找到两者在语义定义上是完全一致的, 在此基础上进行关联。
对于数据映射过程, 一方面需要找到数据的语义定义, 即数据的数据说明, 包含数据的名称、类型、长度、范围、取值规则以及范例, 另一方面要针对语义进行辨别, 找到两者的对应关系和匹配法则, 这样才能进行映射关联, 并在映射过程中进行等值语义的处理。
另一方面, 在语义处理上, 还需要特别注意处理语义上的冲突问题。即源和目标在语义上存在的差异, 尤其是容易由程序辨识的部分, 更需要自动化的处理。常见如下的语义冲突:
①数据类型上的语义冲突, 例如Varchar类型到int类型的映射。
②数据长度的语义冲突, 例如源是varchar (40) , 目标是varchar (20) 。
③数据范围的语义冲突, 例如源是一张字典表, 目标是两外一张字典表。
(3) 性能 (交换性能、实施效率)
数据集成很重要的一个方面, 就是性能。这里性能指的是集成性能和集成实施的性能 (也可以说是实施效率)
一般比较常见的性能, 都指的是集成性能, 即数据从源到目标的数据集成或者数据集成的性能。这个性能又和集成的需求存在关联关系。一般对于全量数据同步, 都要求能够进行定时的集成, 那么性能主要体现在批量数据的处理能力上。
对于实施效率, 对于数据集成的实施环节, 面对可能多面的需求以及新增的集成内容, 也是客户关注的重要内容。集成实施过程要能够简单、模式化、流程化以及易用、易扩展, 这样无论是在项目的实施过程, 还是应对将来变化的情况, 都能做到高效实行。
(4) 完整性 (数据完整性、约束完整性)
数据集成的完整性, 体现在两个方面:数据的完整性和约束的完整性。
①数据的完整性, 主要体现在数据的事务处理方面。对于数据集成的过程, 要从源端把数据取出, 并加载到目标的这个过程, 必须要有完整的事务保证, 才能算是数据的完整。如果没有按照约定加载数据, 那么事务必须要进行回滚保证。例如增量的数据集成, 如果存在增量信息, 那么如果增量信息没有有效地写入目标, 那么必须要把增量数据进行回滚保存, 以便下次任务继续进行, 保证整个项目的事务完整。
还有就是数据操作过程的完整性, 如果存在异常的数据, 那么必须保证异常数据能够进行有效处理, 例如写入独立的错误记录表, 或者定义为完整事务来进行处理。
②数据约束的完整性, 一般都是在进行特别内容处理下体现出来的。例如父子表、外键关联的联动表以及带有字典字段的数据表。如果存在这种情况, 那么集成数据的时候, 必须考虑这些内容的一致和完整, 否则集成的数据就存在差异, 导致不可用或者数据无效。
3、异构数据集成的方法
对于数据集成, 就技术发展的过程来看, 分为以下几个方面:
ETL (包含E-LT) 方法:就是传统的数据仓库建设基础, 主要是基于SQL的操作。
EAI方法:这里主要指的是在应用集成角度, 对数据集成进行解决的方法。
SOA方法:新一代的集成方式, 主要是在架构和策略上, 体现总线的方式、概念以及松散耦合的策略。
(1) ETL (含EL-T技术)
ETL中三个字母分别代表的是Extract、Transform、Load, 即抽取、转换、加载。
传统的ETL工具的运行方式是, 首先从多种数据源抽取数据, 然后在一个专有的、中间层的ETL引擎转换数据, 最后装载转换后的数据到数据仓库或集成服务器中。
E-LT体系结构结合了手工编码和ETL方法的最佳特性于一个解决方案中。E-LT方法改变了数据转换发生在哪里和怎样处理, 事实上, E-LT方法重新部署数据转换步骤在目标数据库系统, 改变了操作顺序为:从数据源表抽取数据, 装载表到目标服务器, 然后使用数据库管理系统特有的SQL (native SQL) 操作在数据库系统上转换数据。
E-LT体系结构不需要额外的服务器、技术和技能来完成操作, 提供最优的性能和可伸缩性, 并且容易管理整个集成系统的基础架构。
(2) EAI
EAI则能提供基于应用级的数据集成。首先EAI是应用集成, 数据集成只是EAI的一部分, 它是在应用集成的基础上进行的数据集成, 也就是在不同的应用程序之间交换数据。所以它最擅长的是少量数据的频繁交换, 在数据迁移能力方面明显不如ETL。它的优势在于可以进行实时操作, 其核心部分是面向工作流的, 主要工作在传送层。
EAI技术因为是应用集成角度, 因而在数据集成的处理上, 沿用了应用集成的策略和机制, 所以都是通过事件或者消息的机制和中介来进行处理的, 那么在处理过程中, 这种转换必然会损失一定的性能, 在效率上要比ETL方法相差很多。
(3) SOA
SOA方法主要体现在数据接口和数据架构上。一方面, 对于传统的数据接口, 无论是ETL还是EAI, 都是数据库接口, 或者是基于数据库的适配器做为数据接口。而SOA方法则是对数据进行封装, 暴露Web Service接口进行数据集成。这是SOA的一大特点。另一方面在数据架构上, SOA方式先天就带有松耦合和总线策略, 松耦合使得系统的接入与退出更加容易和方便, 便于日后的集成扩展和调整。对于总线型架构, 也使得数据能够一处获取, 多处使用。
三、高校异构数据集成
1、高校异构数据集成的需求
(1) 信息孤岛 (没有交换)
各业务系统独立建设, 数据难以共享。现有的系统无法提供相互数据集成的功能, 当某些数据需要跨部门使用时, 还依赖于手工的传递或通过电子邮件等方式半手工的传递。这种低效率的信息共享方式无法满足各部门及时获取所需其他部门信息的需求。
(2) 数据标准与规范 (各部门都不统一)
无校级统一数据标准, 无法形成有效数据积累, 给领导辅助决策分析造成障碍。各个系统提供的统计数据不完全准确, 由于重复录入、录入时缺少差错审计和统计标准不统一, 无法通过现有的系统获取学校真实的教学、科研等重要的统计数据。
2、高校异构数据集成的特点
(1) 数据源多样;
(2) 数据质量差;
(3) 标准不统一;
(4) 异常产生频繁;
(5) 非严格同步。
四、高校异构数据集成平台的设计
1、平台的设计方案
整合整个高校的数据和应用, 并将它们在一个统一的视图中进行展现是一个复杂的任务。大量的不一致性不仅仅体现在技术、数据结构和应用功能上, 而且在整体的体系结构上也存在着基本的差距。有一些集成需求是面向数据的, 尤其是那些对大数据量的需求。还有一些其它的集成项目是基于事件驱动的体系架构 (EDA) 或者面向服务的体系架构 (SOA) , 如异步或同步的集成。许多组织针对这些多样化需求采用了广阔的工具和技术, 结果就会造成杂乱的集成项目而无法将它们进行综合利用和统一起来。这些工具不符合整体的性能、灵活性和模块化的需求。
新一代的数据集成工具Oracle Data Integrator提供了一个集成平台包括的所有数据集成的功能:基于数据的、基于事件的和基于服务的。通过高效地转换大数据量的能力、用先进的变化数据捕获 (CDC) 在实时环境中处理事件。它还提供了强大的数据完整性控制能力, 确保数据的一致性和正确性。采用不同于传统工具的独特核心特性—异构E-LT、声明设计和知识模块等。
Oracle Data Integrator符合高性能、灵活性、高生产率、模块化的集成平台的需求。根据高校异构数据的特点, 本文提出基于ODI的高校异构数据集成平台的设计方案。
2、关键技术
(1) EL-T
E-LT体系结构结合了手工编码和ETL方法的最佳特性于一个解决方案中。
(2) 轻量级增量日志
对少量的实时性要求高的数据 (比如学生基本表的学籍状态) 进行高效捕获, 而不对整张表的所有数据进行捕获的一种方法。
(3) 差异比对
差异比对指的是对于源和目标, 需要进行差异化的区分, 以便决定是否进行更新。这种情况是在无法通过其他手段获取数据差异的情况下产生的, 而又需要进行快速的数据集成处理, 因为最基本的全量数据集成也可以达到集成的效果。
(4) 集成中心库设计
对于集成中心库的设计, 也是数据集成平台较为核心的一块内容。
鉴于高校大多选择复制模式, 那么对于高校这种相对松散的数据管理模式, 数据源的多变和不确定性, 就需要数据能够通过临时存储解决一定的问题。
另外, 对于数据的使用上, 各个系统的数据要求又是不一致的, 例如对于学生信息的删除操作, 会存在订阅者不同的处理和消费方式。因而需要设置临时的数据存储来解决这种差异使用, 因而需要集成中心来存储这些内容以便进行处理。
数据集成中心库的模式设计, 需要考虑以下几个方面的内容:
首先, 需要参考高校的信息化标准模型, 因为集成的对象基本上覆盖了高校核心的数据内容, 另外, 数据也需要在集成中心库进行统一的格式化处理, 保证数据的统一, 一方面是元数据的统一, 另一方面是数据标准的统一。
其次, 数据模型要留有扩展性的考虑, 那么表现在模式设计上采用“松散设计”、“面向对象设计”的原则。“松散设计”保证对象与对象之间尽可能进行拆分, 这样对于新增的对象可以很容易通过新增的方法进行扩展, 而不必调整原有内容。“面向对象设计”使得设计不按照当前业务处理的规则, 这样对于以后可能存在的管理模式或者业务变化, 都可以保证原有的设计内容不做调整, 增强可适应性。
最后, 对于数据集成的考虑, 需要在传统的数据模式上扩展用于集成的字段, 用于数据集成过程的特别应用。
3、需求分析
在高校数据集成实施之前, 首先要做的就是对集成需求的搜集和分析。对需求进行详细地分析是进行数据集成十分重要的一点, 能极大提高实施中的效率。高校数据集成的需求主要包括以下几点:
(1) 集成中心库、各业务子系统数据库的环境信息。包括这些数据库所在主机操作系统、数据库的类型及版本、数据库用户名/ 密码、数据库用户的访问权限、数据库访问端口。
(2) 各业务系统与集成中心库的集成总体需求信息。对每个需要集成的业务系统的数据库, 都需要形成这样一份需求文档。这份文档里描述了业务系统提供哪些数据给集成中心库 (数据上行) , 以及业务系统需要从集成中心库中获取哪些数据 (数据下行) , 并且要描述数据在集成到其他系统后的应用场景。
(3) 需要集成的数据详细信息。对需要数据集成每一个子系统的数据库, 都要形成一份需求文档, 这份文档里详细记录了集成中源表和目标表的表结构、字段映射关系、字段详细信息 (包括字段名、说明、类型、长度、是否主键) 、源与目标字段的转换关系 (字段类型转换、代码转换) 、集成方式、数据集成周期等。
4、确立集成总体架构
对高校数据集成架构采用集线型的架构, 即引入集成中心数据库, 各业务系统与集成中心数据库做数据交互。不同的业务系统之间进行数据集成, 并非直接两两系统直接互连做集成, 而是其中一个系统首先将数据集成到集成中心数据库, 再通过集成中心库下行到另一个系统。这样做的优点主要有:降低各业务系统的耦合度、增加项目的可扩展性、保证了数据质量、并且能够有效地控制对各业务系统的访问权限控制。再者, 有了集成中心库, 对更好地实现全局信息集成和上层应用。
在这样的集成架构下, 例如系统A需要系统B的数据, 首先将系统B的数据上行至集成中心库, 再由集成中心库下行到系统A, 通过这样的方式实现系统B到系统A的集成。图中, 各业务系统与集成中心库之间通过集成工具互连, 在集成工具的作用下, 实现业务库与中心库的数据集成。
5、数据集成平台的安装
完成需求分析和总体架构设计后, 现在可以安装数据集成平台来完成数据集成的项目设计了。数据集成平台的开发环境要求是Windows 2000 (2003) Server系统。
集成平台的安装步骤是:
(1) 首先安装JDK1.5, 这是为了满足集成工具ODI的安装需求。
(2) 接着安装Oracle10g数据库, ODI运行时需要有两个存储库———主存储库和工作存储库, 所以需要安装Oracle数据库来创建这两个存储库。
(3) 安装ODI集成工具。
6、集成开发
安装了数据集成平台并正确的配置后, 就可以进行数据集成项目的开发了。
五、结束语
本文提出基于ODI的校园异构数据库数据集成的解决方案, 并对异构数据集成平台进行了设计, 提供了一种数字化校园异构数据源数据集成的有效方法, 该方法能够有效解决校园数共享和交换的问题, 实现校园数据的互联互通。
参考文献
[1]谢雄程;刘之家;异构数据集成技术中的“本体”建模方法研究[J].广西师范学院学报 (自然科学版) ;2010年01期.
项目集成风险管理模型研究 篇10
集成, 是以系统化的思想创造性把两个或者两个以上的要素集合在一起, 成为一个有机整体。要注意的是, 集成并不是要素的简单叠加, 而是无缝的结合。
集成风险管理的内涵: (1) 项目集成风险管理是对风险全面、动态化管理
项目面临的风险是多方位的, 包括来自外部的风险、技术上的风险、管理上的风险、人员上的风险等等。我们对于风险的管理, 不能只关注其中一个方面, 任何一方面风险因素的遗漏都有可能造成项目的失败。应关注方方面面风险, 采取全面化的管理方式。风险在项目生命周期中是不断变化的, 新的风险不断涌现, 旧的风险可能消失, 主要风险和次要风险也在不断转换。所以, 不能以一成不变的方式对风险进行管理, 应随时关注风险的变化, 采取动态化的管理方式[1,2]。 (2) 项目集成风险管理以实现项目目标为驱动项目风险管理的目标是将影响项目目标的不利因素降到最低, 帮助实现项目目标。可知, 项目风险管理的目标和项目管理的最终目标是一致的。项目各个阶段有不同的风险管理目标, 将这些阶段性的目标集合成为一个有机的目标系统, 驱动项目目标的实现。 (3) 项目集成风险管理贯穿项目全生命周期项目全生命周期是指项目从立项开始到最后丢弃的整个过程, 项目生命周期较长, 整个生命周期都充刺着不同的风险, 且项目生命周期各个阶段出现的风险, 并不是相互孤立的。项目风险管理, 并不能只针对项目生命周期中某一个或某几个阶段进行, 而是应该站在全局的角度, 贯穿生命周期的始终。 (4) 项目集成风险是风险管理过程的不断重复风险管理的过程是从风险的识别到, 评估, 到相应管理与监控的过程。风险管理的过程, 不应是一次性的, 而是应该不断的轮回, 在项目的全生命周期中不断重复。 (5) 项目集成风险管理是项目干系人全员参与, 共同管理风险项目可能会设立专门的风险管理部门, 但风险的管理落实到实处还是要依靠各项目干系人的努力:一、风险识别过程需要各干系人参与, 识别出尽量可能多的风险。二、项目干系人需要在各自的责任范围内管理好各自的风险, 这是风险管理最为基础的部分。三、各干系人有自己的利益驱动, 干系人能否站在全局的角度, 以项目目标完成为首要, 是风险管理相当重要, 也是最为困难的部分。
2 项目集成风险管理构建
本文根据项目集成风险管理的内涵建立的模型, 该模型以项目生命周期为主线, 从左至右。风险管理过程 (识别、评估、计划、控制环) 在生命周期中不断循环前进;它的活动以项目目标为中心驱动;风险管理方法库不断为风险管理各过程提供方法参考与选择;风险管理过程在开发项目全生命周期中不断与风险信息库进行信息交换。该模型由四个主要的集成部分组成, 为了更好的研究集成模型, 我们重点对这四个部分进行剖析: (1) 项目全生命周期与风险的集成。项目各生命周期的风险不是相互独立的, 而是相互影响。前阶段的风险后果会在后阶段逐级放大。比如项目立项阶段产生的风险会和整个生命周期所有的风险相关;需求阶段产生的风险会影响后续的范围、进度、成本等。因此, 对于项目生命周期的风险管理不应该是分割式的、独立的, 而是应该站在全局的、系统的角度来进行[3,4]。 (2) 项目风险管理目标的集成。项目风险管理是将影响项目目标的不利因素降到最低, 帮助各干系人达成对项目的目标要求, 从这个层面上来说, 项目风险管理的目标和项目管理的目标是一致的。项目目标总的来说分为三大类。质量、成本、时间。质量越好越好, 成本越低越好, 耗时越短越好, 如果这三个最好实现, 则是最“优”状态, 各干系人将得到最大的满足。实际情况是三者并不都是正相关的关系, 其中任意一个目标发生变化必然会引起其他目标的变化。质量一定时, 耗时短, 成本高;成本低, 耗时长;时间一定是, 质量好, 成本高;成本低, 质量差;成本一定时, 质量好, 耗时长;耗时短, 质量差。可知, 三者不可能同时达到最优。所以项目管理要追寻的最优不是单个目标的最优, 而是整体的最优。项目多目标集成管理旨在寻求项目目标之间的平衡。
本文借助质量管理的戴明环。将风险管理过程划分为四个阶段: (1) 风险识别; (2) 风险评估; (3) 风险计划; (4) 风险监控, 组成了风险管理环 (IEHM) 。 (3) 风险管理过程与方法的集成。风险管理过程中每个阶段所用到的方法都不一样。根据具体的项目, 在不同的风险管理过程中配套选用最为合适的方法是项目风险管理取得成功的保障。随着风险管理理论的发展, 人们已经研究出一系列定性和定量的方法。比如风险识别的头脑风暴、德尔菲技术、敏感性分析法;风险评估的层次分析法、概率分析法;风险计划风险回避、风险缓解、风险转移、风险接受等;风险监控的资料检查法、风险数据库、挣值分析法、关键路线法 (CPM) 、计划评审技术等。 (4) 风险管理信息的集成。项目中存在着大量数据与信息, 如何从中挖掘与处理有利于我们进行风险管理的信息, 是风险管理取得成功的保障。经典风险管理模Boehm模型建立了管理项目风险特征库, CMMI模型也以数据库为核心, 他强调实现每个活动要更新风险库, MSF强调经验学习的重要性。这些都表明, 数据信息库在风险管理中起着重要的作用。哪些信息应该被风险信息库存储并重点关注: (1) 项目自身的风险; (2) 风险相关的知识; (3) 风险的处理; (4) 风险的历史记录; (5) 外部的信息支持。
3 结束语
集成化风险管理模型应用于大型开发项目, 带来的直接好处是: (1) 风险管理不再无章可依, 能够做到有步骤、有依据的进行; (2) 风险管理能够朝着实现目标的方向前进, 目的性更强, 效率提高; (3) 为风险管理提供方法支持, 风险管理各过程有方法可依; (4) 风险的管理更为全面, 信息的收集更为及时、全面; (5) 提高了风险管理效率, 降低了项目失败的概率。
摘要：随着经济的多元化发展, 经营生活中出现的风险越来越多, 但是传统的风险管理处于一种分割式的状态, 没有站在整体的角度进行。本文就集成化的思路对项目风险管理模型进行研究, 旨在打造一个系统的、全面的、持续性的风险管理模式。
关键词：风险管理,集成管理,风险管理模型
参考文献
[1]《软件和信息技术服务业“十二五”发展规划》
[2]岳松涛, 黎志成.高科技项目风险预测[J].电子科技大学学报 (社科版) , 2007, (2) :39-43
[3]Lister T.Interviewwith Tim Lister[J].IEEESoftware, 1997, 14 (3) :18-19
【数据集成模型】相关文章：
共享数据集成05-07
数据集成技术06-01
信息系统集成与数据集成策略09-12
数据平台系统集成方案05-06
基于SOA的数据集成05-26
eip数据集成解决方案05-04
空间数据集成与交互的方法研究09-12
多数据库集成化管理策略论文04-28
基于XML模式的异构数据集成研究及应用09-11