企业信息数据更新分析.docx

企业信息数据更新分析.docx

《企业信息数据更新分析.docx》由会员分享，可在线阅读，更多相关《企业信息数据更新分析.docx（5页珍藏版）》请在冰豆网上搜索。

企业信息数据更新分析

企业信息数据更新分析

　　1介绍

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

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

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

　　对元数据的更新影响分析，本方案使用ECA规则也叫activerules来实现，理由是ECA规则已经在以数据为中心的应用中有十分广泛和坚实的应用基础¨3．1“．ECA规则可以在相关的更新发生并在满足一定的条件的情况下自动调用行动部分．其中，防范性分析用BEFORE表示，反应性分析用AFTER表示．利用ECA对元数据更新的依赖关系进行建模．下图定义了元数据更新分析规则．1：

DECLAREDATASOURCEDATASOURCENAME2：

CREATEECARULERULENAME3：

BEFOREIAFTER4：

ONUPDATEOFMETADATA5：

IFCONDITIONTHEMETADATAMUSTSATISFY6：

DOSENDMESSAGETOlANALYSISPROCEDURE第一行用来定义该分析规则是针对哪一个数据源的，在这之前必须对所有的数据源进行识别，并赋予唯一的标识符。

第二行用来定义规则的名字，第三行定义该规则是防御性的还是反应性的，如果是一个防御性的规则，则对元数据的更新将会定制，等待相关的动作完成后，再进行元数据的更新，如果是一个反应性的规则，则对元数据的更新将会如期举行，但是在更新之后将会根据规则中定义的行动进行分析和补救．第四行定义了所需要监测的元数据名字，第五行定义了满足什么条件，第六行则定义了如果条件满足，则需要采取什么行动．值得注意的是，第6行中的行动部分，有可能有一组操作．例如在更新完A数据源中的某个元数据名字或类型后，有必要更新B、C、D数据源中的相应的元数据的名字和类型，以保持这4个数据源中的同步．在这里，我们使用了一个抽象的概念模型，因此在实现中，首先需要将该规则模型中的元数据和以XMI标准存储的元数据一一对应．将其抽象的好处是，便于规则的制定，规则的可读性好，容易维护．同时，这些更新分析管理规则都存成XML形式，目的是可以与元数据共用一个存储库．下面举一个例子，用来解释如何使用该ECA规则定义元数据更新影响分析规则：

DECLAREDATASOURCEcustomerDBCREATEECARULECustomerlDChangeBEFOREONUPDATEOFCustomerDB．Customerlnfo．CustomerlDDOSENDMESSAGETO该例子说明了，如果要改变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，允许在集成系统中间对元数据变化影响进行分布式的分析．图1是MDUAM的框架结构．假定一个企业有客户关系都，生产都，和销售部．元数据更新影响分析方案分为3个层次，最底层是底层信息系统数据源，中间层是监视层，有一个元数据监视器在对底层的数据源进行监视，监视到的元数据变化可以报告给上层，也就是管理服务层中的更新影响分析器．更新影响分析器允许