企业信息数据更新分析范文

本站小编为你精心准备了企业信息数据更新分析参考范文，愿这些范文能点燃您思维的火花，激发您的写作灵感。欢迎深入阅读并收藏。

1介绍

制造企业的信息系统已经在上世纪经历了一场集成化的革命，为了在竞争中取胜，企业纷纷将自己的信息系统通过各种方式进行集成，因此，目前市面上存在若干种企业信息集成系统．然而，制造企业中的信息大多数仍然存在不同的数据管理系统中，这些旧的数据包括关系数据库系统，面向对象的数据库系统，XML文件，分割文件，HTML文件，Excel文件等等．将不同的数据源中的数据抽取出来进行协同工作具有很大的应用价值¨0J．企业数据集成系统的目标就是为多个数据源提供一个统一的接口．它使得用户可以集中关注自己需要什么，而不是关注如何去获得数据．结果就是，企业数据集成系统使得用户从繁琐的与每一个独立的数据源交互的工作中解放出来，他们不再需要跟每一个数据源用其特定的接口进行交互，并且将从每一个数据源中返回的数据进行联合．XML是作为互联网中信息交换的主要标准出现的，XQuery则是一个强大而又方便的语言，用于查询XML．目前出现了很多基于XML的数据集成系统，也被称为Web上的数据服务提供平台(简称Web数据服务平台，下同)．在一个数据服务平台中，每一个Wrapper都导出一个XML的模式(XMLSchema)，用以将所对应的数据源的内容描述成XML．查询处理器从客户端接收XQuery查询，并进行解析和分解，将查询计划下压给Wrapper．Wrapper将会把这个查询翻译成本地语言，当子查询在本地执行完之后，Wrapper负责将查询结果转换成XML并返回给查询处理器，典型的数据服务平台包括BEA公司的AquaLogicDataServicePlatformpl和XCaliaIntermediationCore[41．目前的企业信息集成系统中，信息的框架变得越来越复杂，有越来越多的异构系统之间建立了互相依赖的融合关系和依赖关系，这就使得整个系统框架变得难以管理．已有系统中会建立新的依赖关系，新的系统又不断加入，总的来说，在企业信息管理系统中，难以建立一个对所有系统进行中间管理的机制．一些小的本地的数据变化，有可能因为系统之间的依赖关系，而对整个企业范围内的数据产生极其重大的影响，为了使整个企业的信息系统得以正常运转，必须建立一种机制，对这种数据变化可能产生的影响进行防范性的分析(de-fensiveanalysis)或反应性分析(reactiveanalysis)，从而在数据产生变化的时候进行适当的调整，而不必对整个系统框架进行调整和改变．在做这样的防范性分析时发现，系统的异构性以及元数据的不完整性，使得对数据更新进行影响分析十分困难，同时，数据的更新常常没有在全局得到计划，这样的境况使得这个问题变得更加困难．所以，不可预计的问题总是会在一个更新完成后发生，这就使得一个防范性或反应性的数据更新影响分析变得十分必要．本文提出一种解决方案MDUAM(Metal)amupdateAnalysisandManagement)，该解决方案能够使得数据更新影响分析即使在不利的条件下也能够工作．本文的数据更新指的是元数据的更新，元数据不仅包括数据模式(dataschema)，也包括应用编程接口(APIs)，配置文件，关于数据质量的断言，执行效率等等，简短的说，就是其余系统可能会依赖的一切．

目前已经有很多这方面的研究工作．有些方案和本文是完全互补的，有些和本文在某些方面是类似的．MDUAM最重要的和别的系统不同之处在于它没有对工作的环境做任何假设，因此可以在任何需要进行变化影响分析的场景下进行工作．[5]提出一种和MDUAM非常类似的方案，然而，他们需要一个中心的文档库(或者是元数据库)和一个严格的处理策略．这就限制了方案的灵活性，因为中心的文档库常常会成为处理的瓶颈，这种方案还强制整个系统必须严格根据定义的进程进行运转，而这常常是不可能的和不能接受的．[6]则提出一种形式化的方法，用以表达元数据之间的依赖关系，以及在元数据发生更新时，通过依赖关系计算出该更新所发生的影响．该方法主要建立在UML建模的基础上，未对以XML为数据模型的企业信息集成系统加以分析．[7]提出了另一种解决方案，来进行变化影响分析．他们使用一个多图，和变化传播规则来进行分析，这和MDUIA很接近．该方案重点在于防范性的变化影响分析，因此缺乏一种框架来支持反应性的更新影响分析．同样，该方案没有考虑到元数据的不完全性问题．他们的元模型和规则都是专门的，很难对其进行扩展来支持其他的数据模型和变化类型．软件工程方面也有很多解决这个问题的方案哺】，有些是限制了支持的数据模型或范围，有些则加以限制，必须进行准确的分析．软件系统中的变化影响分析和本文所使用的很类似，然而，他们的模型和分析过程着重在于那些在软件中可见的元素：如方法，签名，类，属性，等．再者，软件系统中的更新影响分析通常是防范性的．像异构性，元数据的不完全性和分布性，这些问题在软件系统中都不会得到考虑，因为这些问题只是和信息系统息息相关．模式进化，模式匹配或者模型管理中的研究工作和本文的工作是互补的[9．101，特别是数据模型管理中的方案用来计划和实现集成，通常是在两个或者一组系统中进行集成，还有将系统适应成变化的需求．[11，12]则对基于XML的数据集成系统中利用反应性和防范性规则对数据的更新进行分析和管理，然而，该工作未对元数据的更新进行分析和管理．MDUAM不是为一个集成项目的初期进行设计的，而是将一个集成项目的结果作为输入，就是系统之间的依赖关系已经存在了．两这些依赖关系是基于模式匹配或者模式映射的定义的，并且监视他们的变化情况．MDUAM将会分析变化产生的影响，并且将可能有关的人员通知到．如果出现问题，MDUAM的输出将作为信息集成工具的输入，来修复这个受到影响的系统．MDUAM着重在于监视参与整个信息集成框架的系统中元数据的变化，并且探测到变化可能产生的全局影响．因此可以说，MDUAM解决了一个异构集成环境下的全局管理的重要问题．本文面临的问题就是一个元数据更新的管理，首先将所面临的问题分为3个部分：

1．异构性．企业信息集成系统中，互操作的系统常常有不同的数据模型，例如，XML数据模型，或者是关系数据模型；也具有不同的接口，例如，通过查询语言还是函数调用等等．

2．元数据的不完全性．一般来说，不可能为一个准确的数据变化影响分析获得所有的元数据．而且在有些情况下，查询一个系统的元数据不是一件容易的事．同时，文档数据可能是过时的，或者是不存在的，系统之间的依赖关系有可能隐藏在过程代码中，在最坏的情况下，有可能必须反编译一些代码才能获得所需要的信息．这仅仅在理论上是可能的，但是在实际上，这样做的代价太高从而是不可行的．

3．系统自制性和缺乏全局管理．在实际情况中，许多系统都是一个黑盒子，不能从外部得到控制，这在一个集成环境中尤其如此，因为一般来说企业信息集成系统覆盖了很多个部门或者甚至覆盖了很多个公司．数据更新常常没有得到全局分析，也没有通知到可能影响到的系统就已经得到实施．这时候，很多问题就出现了，而且很难发现导致问题的原因．

2元数据表示

Ⅺ咀(XML—basedMetadataInterchange)是基于XML的元数据交换¨“．它通过标准化的XML文档格式和DTDs(DocumentTypeDefinitions)为UML元模型(元模型是一类特殊的模型)和其他模型定义了一种基于XML的数据交换格式．它同时也定义了一个从UML到XML的映射．XMI的主要目的就是让各种分布式的异构环境中的建模工具和元数据存储(metadatarepositorie)仓库之间能方便地进行数据交换．XMI代表了一种元数据传输的新途径．由于XMI是一种数据交换格式而不是CORBA的接口，所以不需要使用用于完成ORB连通的ORB来影响转化过程．事实上，任何一个有传输ASCII能力的机制都能胜任这种转化工作．这样，XMI提供了一个进行数据交换的新途径．鉴于OMG的UML已经在当今的企业信息集成系统建模中得到了最广泛的使用，MOF(元对象工具，MetaObjectFacility)作为OMG的元模型建模(metamodeling)和元数据存储已成为新的工业界标准，本文的工作是建立在企业信息集成系统采用MOF进行建模，并将元数据按照XMI标准转换和存储．这样做的好处就是各个异构系统之间的元数据交换遵循工业界标准，从而使互操作成为可能．

3元数据更新影晌分析模型

对元数据的更新影响分析，本方案使用ECA(Event-Con—dition．Action)规则也叫activerules来实现，理由是ECA规则已经在以数据为中心的应用中有十分广泛和坚实的应用基础¨3．1“．ECA规则可以在相关的更新发生并在满足一定的条件的情况下自动调用行动部分．其中，防范性分析用BEFORE表示，反应性分析用AFTER表示．利用ECA对元数据更新的依赖关系进行建模．下图定义了元数据更新分析规则．1：DECLAREDATASOURCEDATASOURCENAME2：CREATEECARULERULENAME3：BEFOREIAFTER4：ONUPDATEOFMETADATA5：IFCONDITIONTHEMETADATAMUSTSATISFY6：DOSENDMESSAGETO(ADMINISTRATOR)lANALYSISPROCEDURE第一行用来定义该分析规则是针对哪一个数据源的，在这之前必须对所有的数据源进行识别，并赋予唯一的标识符。第二行用来定义规则的名字，第三行定义该规则是防御性的还是反应性的，如果是一个防御性的规则，则对元数据的更新将会定制，等待相关的动作完成后(例如，获得了相关的管理员的审批等)，再进行元数据的更新，如果是一个反应性的规则，则对元数据的更新将会如期举行，但是在更新之后将会根据规则中定义的行动进行分析和补救．第四行定义了所需要监测的元数据名字，第五行定义了满足什么条件，第六行则定义了如果条件满足，则需要采取什么行动．值得注意的是，第6行中的行动部分，有可能有一组操作．例如在更新完A数据源中的某个元数据名字或类型后，有必要更新B、C、D数据源中的相应的元数据的名字和类型，以保持这4个数据源中的同步．在这里，我们使用了一个抽象的概念模型，因此在实现中，首先需要将该规则模型中的元数据和以XMI标准存储的元数据一一对应．将其抽象的好处是，便于规则的制定，规则的可读性好，容易维护．同时，这些更新分析管理规则都存成XML形式，目的是可以与元数据共用一个存储库．下面举一个例子，用来解释如何使用该ECA规则定义元数据更新影响分析规则：DECLAREDATASOURCEcustomerDBCREATEECARULECustomerlDChangeBEFOREONUPDATEOFCustomerDB．Customerlnfo．CustomerlDDOSENDMESSAGETO(ADMINISTRATOR)该例子说明了，如果要改变CustomerDB中的Customer-Info表中的CustomerlD必须通知管理员．同时，这是一个防范性的规则，在得到管理员批准之前，该元数据不得更新．下一个例子说明了，两个数据源之间如何通过元数据更新影响分析规则进行同步：DECLARED峨KSOURCEcustomerDBDECLAItEDATASOURCEcustomerXMLCREATEECARULECustomcrIDChangeAFrERONREPLACEOFCustomerDB．CustomcrInfo．C_IDW删CustomcrDB．CustomerIafo．CustomerlDDOREPLACECustomerXML．Customerlrffor．C—IDWrrHCustomer-XML．Customcrlnfor．CustomerID在这个例子中，如果对CustomerDB中的Customerlnfo表中的CustomerlD进行更新，则必须同时更新CustomerXML中的Customerlnfo文件中的CustomerlD．值得注意的是，这是一个反应性的规则，CustomerDB中的元数据如期更新，同时也要更新CustomerXML中的元数据．

4MDUAM解决方案

本文提出一种框架结构MDUAM(MetaDataUpdateIm-pactAnalysis)，允许在集成系统中间对元数据变化影响进行分布式的分析．图1是MDUAM的框架结构．假定一个企业有客户关系都，生产都，和销售部．元数据更新影响分析方案分为3个层次，最底层是底层信息系统数据源，中间层是监视层，有一个元数据监视器在对底层的数据源进行监视，监视到的元数据变化可以报告给上层，也就是管理服务层中的更新影响分析器．更新影响分析器允许进行防范性的更新影响分析或者进行有反应的更新影响分析．同时提出一种元数据触发器模型，使得本文可以处理和同化异构的元数据，根据该模型可以决定对于哪些元数据更新需要做相应的分析．

4．1更薪影响分析器在更新影响分析器(下页图2)中，存在一个元数据库(MetaDataRepository，MDR)和更新管理器(UpdateManag•er，UM)，MDR是一个被动的组件，它负责存储不同的信息系统中的元数据，并且用一种通用的表现方式进行存储．同时还为查询和更新所存储的元数据提供了一个接口．所有的元数据都是有版本号码的，这样做的目的是可以跟踪到过去所发生的所有的变化．更新管理器则是一个主动的反应性的的组件，它可以分析通过用户界面提出的变化建议，也可以在一个被观察到的系统中发生的变化进行反应性分析．值得注意的是，在本解决方案中，元数据之间的依赖关系以及在更新时需要进行的监控实际上是分层次解决的．首先把企业信息集成系统中的各个子系统分为若干个”群”，”群”可以是一个部门的若干个子系统，也可能是几个职能类似的部门所有子系统的合集．这样做的目的是在企业中进行元数据的分层管理，群内的元数据更新可以在群内管理，如果群内的元数据更新涉及到群外的元数据，则通过更新管理器与别的群的更新管理器进行交互完成．本解决方案的好处在于，没有一个中心文档库，从而没有系统瓶颈，很好的满足了企业信息集成系统中松散耦合的特性．

4．2元数据监视器元数据监视器是该解决方案中重要的组件．每一个参与变化影响分析的系统都被一个元数据监视器进行监测，元数据监视器负责在变化管理器、被观察的信息系统，以及负责的人之间进行协商，一个元数据包含了好几个子部件．1．元数据抽取器．用于在最初的阶段抽取底层系统中的所有元数据，并在后来的工作中提取变化2．转换器．负责将抽取到的元数据转换成MDUAM可以识别的形式．3．观察器．观察在信息系统中的所有的变化．4．存储器．出于缓存的(caching)目的，有一个存储的组件．元数据和变化管理器进行异步通信，异步的目的是为了不阻塞任何一个组件．MDUAM为数据管理器和元数据提供了一些图形用户界面(GUI)．再者，图形用户界面给出全局和本地的对元数据及其依赖关系的视图，并为防范性的变化影响分析提供界面．元数据监视器图形用户界面被限制为一个本地的分析，例如，用来分析在一个基表被修改时，其视图是如何变化的．MDUAM也可以分布式的进行使用．几个更新管理器，每一个都对整个系统中的一部分进行负责，它们之间可以进行通信．并且传输它们各自的分析结果．这就使得MDUAM的使用在集中解决方案得不到实施时同样进行．

4．3元数据抽取所有类似的解决方案一样，本解决方案的最大问题就是面临着如何去监测系统的变化，以及如何用一种自动化的方式来提取元数据．所有的关系型数据库管理系统都有一个信息模式，这就使得提取模式信息和其余的元数据时非常容易．监听系统数据变化是比较困难的，因为在系统表格上创立触发器通常是不被允许的．在这里有～个解决方案就是定期定时的Poll和使用一个diff算法来判断数据的变化，或者通过检查日志文件．在这种和类似的情况下，监测元数据和元数据抽取工作，不会带来任何问题．但是有一些其他的情况，例如，有些系统只允许函数调用来查询元数据，有些系统则有访问权限机制，用以阻止元数据被查询．在这种情况下，没有一个通用的解决方案，必须针对不同的机制开发出不同的探测方法．

4．4防范性分析和反应性分析在理想情况下，在每一个数据更新实施之前，都应该进行变化的分析，本文将这种情况称为防范性分析，根据分析的结果，可以做出一些相关的调整，以尽可能的降低影响或者通过调整受到影响的系统来降低影响．MDUAM可以在变化发生之前做一些防范性的变化影响分析．实际上，相关系统的自治性决定了这样的理想情况是不可能的．集成系统的数目越多，就越有可能变化在没有经过预先的分析和协同就发生了．反应性的数据变化影响分析则是自动启动的，受到影响的系统的管理员就会收到通知．分析的过程对于两种情况其实是一样的，但是不同之处在于输入数据的类型不嗣，(可能的变化VS已经发生的变化)．并且，在分析之后采取的措施也是不同的．对于防范性的数据影响分析，结果不会对运行的系统产生任何影响，而反应性数据影响分析来说，收到影响的系统可能会停止运行，或者采取其他的补救措施，来防止数据损坏．

5实现和评估

我们在合作方上海侯氏物流集团有限公司成功实施了本项目．上海侯氏物流集团有限公司下设多个加盟子公司，每个公司均有自己的信息管理系统和数据存储形式，这些系统和数据存储彼此独立异构，而且由于集团公司处于上升阶段，公司业务变化快，元数据经常更新，因此很有必要对元数据进行更新变化的管理，从而保证公司业务正确运行．利用BEAWebLogi应用服务器平台全面开发、部署和集成企业管理软件，利用AquaLogicDataServicePlatform¨’作为企业信息集成系统．每一个更新管理器都安装了～个开源的XML数据库eXistDB【l钊用以存放本群中的元数据和元数据更新管理规则，eXistDB提供了一个纯XML数据库所需的所有功能，它完全不需要安装，下载后即可使用．附带的工具非常简单，提供的服务容易被使用，而且其开源性也为企业节约了成本．利用我们的元数据更新管理器对物流企业的销售部、人事部、管理办公室、客户关系部以及各个加盟子公司进行元数据更新管理，实践证明，该解决方案采用X／VII存储元数据，利用ECA规则管理元数据的更新，元数据的管理采用分层的原则，避免了中央瓶颈．ECA元数据更新管理规则可读性和可维护性好，图形用户界面友好，便于使用．同时做到了既可以进行防范性分析又可以定义反应性分析，满足了企业中元数据更新的多样化管理需求．在物流公司中的成功实施使我们有理由相信，本解决方案同样适用于加盟子公司多、信息管理系统和数据异构的现代虚拟企业．6结论我们在一个企业信息集成系统中实现了MDUAM，根据ECA模型定义了企业信息集成系统中元数据更新必须进行影响分析的规则，我们建立了整个系统框架，提出了如何对元数据进行抽取、存储和分析，同时对元数据更新进行管理．在MDUAM框架下，企业信息集成系统中的重要的元数据得到了严格的监控，其更新以及影响得到了合理和必须的管理，从而保证了整个企业信息集成系统中的元数据和数据是一致的，各个子系统之间的元数据也能够得到充分的一致性保证．