企業信息數據更新分析范文

本站小編為你精心準備了企業信息數據更新分析參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

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框架下，企業信息集成系統中的重要的元數據得到了嚴格的監控，其更新以及影響得到了合理和必須的管理，從而保證了整個企業信息集成系統中的元數據和數據是一致的，各個子系統之間的元數據也能夠得到充分的一致性保證．