基于CWM的元數據管理策略

謝培基，余金山

(華僑大學 計算機科學與技術學院，福建 泉州 362021)

數據倉庫技術是在數據庫基礎上發展而來的新一代信息管理技術，主要用于支持企業信息集成、數據挖掘、企業決策支持等的應用。在數據倉庫建設過程中，由于各工具廠商采用不同的元數據標準和不同的元數據管理策略，使得依靠這些工具進行數據集成、數據共享顯得十分困難。為了統一數據倉庫開發商元數據管理策略，實現元數據的交流和數據的集成，2001年OMG組織在其已制定的規范 UML、MOF、XMI的基礎上提出公共倉庫元模型(CWM)。CWM是OMG制定的一個互操作標準，為數據倉庫和業務分析領域中使用的元數據定義了一種通用語言和交換機制[1]。CWM不僅提供了極受歡迎的描述數據倉庫與業務分析元數據的公共元模型，而且還提供了基于XML的交換工具。CWM本質上是一種交換技術，其目的是促進多個廠商的不同軟件工具間的元數據交換活動。

本文基于CWM的元數據管理策略，介紹了元數據管理的三種主要策略，并對此三種策略進行比較，分析各策略的功能與復雜度，總結基于CWM的元數據管理策略的優勢，進而給出基于CWM元數據管理策略改進的元數據管理體系結構，最后討論了元倉庫的設計。

1 元數據的不同管理策略及其比較

元數據管理策略為元數據集成、共享和重用制定目標和需求。成功進行元數據集成的關鍵之一是建立一個有效的元數據管理策略。從元數據的發展歷史[2]來看，元數據管理策略包括三種：搭建元數據橋、搭建元數據中央存儲庫、構建元數據倉庫。

(1)搭建元數據橋[3]：是一種能夠將一個產品的元數據轉換成另一個產品所要求的格式的軟件。使用元數據橋實現不同工具間的元數據集成是一種點到點的元數據體系結構。在這種結構中，每一對被集成的工具之間都需要一個獨立、雙向的橋，對于n個產品要實現元數據交換必須建立n×(n-I)個元數據橋。這種方式集成元數據大幅增加了開發和維護費用，而且通常將一種格式的元數據轉換為另一種格式時，都會有一定的信息損失。

(2)搭建元數據中央存儲庫[4]：是具有特定目的的數據庫，它存儲、控制并能操作環境中其他所有相關軟件產品的元數據。軟件產品從中央存儲庫中檢索、使用元數據，每個產品必須實現它自己的存儲庫訪問層(另一種形式的橋)。通過使用元數據中央存儲庫可以在一定程度上解決定義全局可用且被廣泛理解的元數據的需要但并沒有完全消除問題，它仍然需要使用到元數據橋，使得成本無法降低很多，也沒有消除受制于特定的廠商的問題。

由于點到點的體系結構和中央存儲庫的集成體系結構并沒有形成一個統一的元數據標準，所以其方案成本都相對昂貴。

(3)構建元數據倉庫：即是基于CWM的元數據管理策略。元數據倉庫的功能包括對元數據源的ETL、元數據的Warehouse以及終端用戶的各種分析、挖掘、報告工具。通過構建基于CWM的元數據倉庫，使得各軟件產品元數據有一個一致的標準(CWM標準)，各軟件工具之間只需要建立一個與元數據倉庫連接的 “橋”(即CWM適配器)就能實現元數據的交換或共享。元數據倉庫與元數據存儲庫都要求建立通用的元數據標準，但二者相比有所不同：①元數據存儲庫的刷新周期相對于元數據倉庫來說要慢，元數據倉庫的元數據是準實時的，而元數據存儲庫的元數據通常的刷新周期在1天以上；②元數據倉庫所集成的元數據不斷變化，其保存元數據的更新情況。而元數據存儲庫則是將所有不同時期的元數據都存儲下來。

通過對上述三種元數據管理策略的分析，得出如圖1所示的三種策略的對比圖。

圖1 元數據管理策略對比

基于CWM的元數據管理策略使得元數據的交換有了一個統一的具體通用標準，解決了用元數據橋式的元數據交換帶來的元數據的雜亂無章、不可理解性，以及為了讀懂接收的元數據，對交換的元數據進行從一種格式到另一種格式的轉換所帶來的一定數量的元數據的丟失，破壞了元數據的完整性、準確性。

比較三種元數據的功能復雜度，CWM元數據管理策略中使用的CWM元倉庫既滿足了性能的要求，又能夠提供很廉價的存放元數據的場所；而對于元數據中央存儲庫，雖然性能上偏優，但元數據在獲得庫所提供的復雜性能的同時也會受到它的限制，例如庫本身的復雜性和資源需求，導致人員培訓費用的增加等。

2 基于CWM的元數據管理體系結構

通過對三種元數據管理策略的分析比較可以發現，搭建基于CWM的元數據倉庫的管理策略存在較多的優點，它能夠以較少的代價提供豐富的數據管理功能，即持續存儲、允許并發、對數據倉庫環境中復雜元數據提供事物訪問，而相對于一個完善的基于元數據中央存儲庫的元數據管理系統來說，基于CWM的元數據管理系統在功能上還存在一些不足，如版本化、生命周期的管理等。針對基于CWM的元數據管理策略不足，本文給出了一種如圖2所示改進的元數據管理體系結構。

該系統結構主要由元倉庫、可操作的數據存儲器、建模工具、元數據管理工具及其他一些數據庫應用工具或軟件產品等模塊組成。

(1)元倉庫：是整個架構的核心，是一個全局共享元數據的以CWM編碼的關系型數據庫，主要用于存儲管理各以CWM為元數據標準的工具產生的元數據和以CWM規范建模和操作過程中所產生的元數據以及從各類型數據庫提取的元數據。

(2)建模工具：可供用戶對可操作的數據存儲器中的某一主題建立元模型實例，直接收集元數據，然后存入到元倉庫中，作為其他工具所需要元數據的數據源。

(3)元數據管理工具：可供對元倉庫中的元數據進行增刪改查操作，方便用戶對元倉庫的更新和維護。但元倉庫中的元數據一般的用戶很難讀懂，很難將一堆雜亂的元數據聯系起來理解其實際意義，應當將其與建模工具相結合，用圖形化的形式顯示這些元數據的元數據模型。

(4)與元倉庫連接的各軟件工具、應用程序都支持CWM標準，它們都實現了相同的用于元數據交換的公共接口，這也意味著任何支持CWM的軟件組件都能夠很容易地理解其他支持CWM的組件的元數據實例，并且能通過標準的CWM元數據接口集來訪問元數據。在這些支持CWM的工具與元倉庫的元數據交流中，同樣需要一個元數據“橋”，這個橋可以用一個CWM適配器的輕量級的橋代替。

(5)CWM適配器是一個軟件，它可以理解CWM元模型以及擁有該適配器的軟件產品內部的元模型和專有的元數據接口。適配器的公共端實現CWM的標準接口，另一端則連接到產品的特定接口。針對某一軟件產品或工具寫適應它的適配器只需要編寫一次，所以它相對于其他的元數據橋節省了很多開銷。

3 元倉庫的設計

在元數據管理體系結構中，CWM編碼的元倉庫是整個架構的核心。因為CWM本身是一個面向對象的元模型，而各軟件產品或工具的元數據大部分是建立在關系數據庫之上，且目前面向對象的數據庫管理系統不普及[5]，因而無法使用面向對象的DBMS來創建一個元倉庫，因此，需要將CWM的面向對象元模型映射到一個關系數據庫中，建立基于關系數據庫的元倉庫。在將CWM面向對象的概念映射到關系表上同時又要保持元數據本身的邏輯結構不變，需要解決CWM中數據類型、類、繼承和關聯等在關系數據庫中的映射問題。在CWM中大量使用了UML的繼承特性，CWM的21個元模型包[6]中就存在著大量的泛化層次結構，因此，選擇如何實現泛化層次在元倉庫的開發是最關鍵的。為此，下面首先分析了繼承模式的幾種映射策略，選擇了一種實現方便、節約存儲空間的方法來實現元倉庫的建立，然后討論對象關系映射中數據類型、關聯的映射問題。

3.1 繼承映射

從類到表的映射并不是簡單的一一對應關系，因為一個子類可以繼承父類的一些特性和操作，而繼承是UML和面向對象系統的一個主要特征，它把類組織成逆向的樹形結構 (即泛化層次)，因此必須考慮泛化層次的對象的映射問題。以圖3所示的CWM關系型包中的Relational：：Trigger的泛化層次為例，給出幾種對象關系映射策略。

圖3 Relational：：Trigger的泛化層次

(1)整個泛化層次結構映射成一張表

將一個完整的泛化層次結構映射成一張表，層次結構中所有類的屬性都存放在這個表中，每個實例對應表中的一行。為了表明一個對象實例是屬于哪個類的，必須添加一個屬性“對象類別”OID，這種映射對應的表如表1所示。這種映射策略的優點是結構相對簡單，只有一個單一的表，其缺點是存儲空間浪費大、利用率低、類層次間的耦合非常高，當泛化層次結構中的某一個類要增加屬性時，必須將一個新屬性增加到表中，這將影響到泛化層次中的所有類。

表1 整個泛化層次映射成一張表

(2)每個類映射成一張包含該類繼承屬性的表

使用這種映射策略，是將每個類映射成一張表，在表中既包含該類的屬性又包括其父類的屬性，如表2所示。這種映射策略的優點是對單個類的查詢操作比較簡單，但是同樣會造成存儲空間的浪費，且類層次間的耦合性較高，當父類的結構改變時，子類的結構也要跟著改變。此外在實現上不方便，因為ModelElement有兩個子類 (Trigger類和 A類)，Trigger有一個 ID，A也有一個ID，它們都是ModelElement的子類。如果這兩個表的主鍵相同，父類是無法識別這兩個子類的，所以這兩個ID一定不能相同，因此也就不能使用ID自動生成策略。

表2 每個類映射成一張表(包含該類的屬性又包括其父類的屬性)

(3)每個類映射成一張只包含該類特有屬性的表對各個表進行連接

使用這種策略子類對應的表ID應該參考父類對應的表的ID，即進行主鍵連接，對應的表結構如表3所示。這種策略的優點是存儲空間比較小，類間的耦合性比較低，查詢的時候不用找很多的表，缺點是要進行表連接，每當增加一個子類還應添加一個表。

表3 每個類映射成一張表進行連接

由上分析可以得出：(1)第一種策略是將整個泛化層次映射成一個表結構。由于CWM元模型包中的泛化層次樹形結構很深，所以會使得元組很龐大，浪費大量的存儲空間，且每次讀取時需要讀入很多不必要的屬性，因此不適合用這種策略建立元倉庫；(2)第二種策略同樣也會造成存儲空間的浪費，在實現上也不方便，亦不適合采用；(3)第三種策略是將每個類映射成一個表，每個表只包含該類含有的屬性，這種方法可節省存儲空間，雖然查詢操作涉及多個表的連接操作，連接操作將多個連接的表組成一個表較耗時，但在計算機速度不斷提高且不要求實時性的情況下適宜選用這種策略。所以本文使用第三種策略來實現CWM元模型包中各泛化層次結構的映射問題，建立元倉庫。

3.2 數據類型映射

每個CWM屬性可以是以下三類中的一種：簡單數據類型、枚舉數據類型和基于類的數據類型。這些CWM的數據類型集必須映射到相應的T-SQL語言支持的數據類型上，如果沒有直接對應的T-SQL數據類型，元倉庫必須創建數據結構使其能模仿所要求的類型。如簡單的數據類型映射規則是：只要將CWM簡單數據類型映射到CORBA IDL類型碼，而后映射到T-SQL數據類型即可。

枚舉數據類型映射規則是將每個CWM枚舉數據類型用一個創建的表表示。枚舉數據類型表中的行只有一列，名為_EnumLiteral，它包含枚舉文字值。當基于枚舉數據類型的列值變化時，新的取值按照該表確定以保持列數據的完整性。

基于類的數據類型映射規則，則需要創建一個基于類的類型的實例，然后將該實例的鍵存放在一個向表示擁有該類屬性的類的表增加的基礎列中。

3.3 關聯映射模式

關聯是UML中表示類的實例間的關系的一種方法，有一對一、一對多、多對多三種關聯。

對于一對一關聯映射規則，只要在如圖4所示的兩個關聯類各對應的表中增加一列。

圖4 1：1關聯映射

一對多的關聯映射規則，僅僅需要改變關聯的多端的固定表，在該固定表中增加一列，以存放一端的一個實例的標識值。如果關聯的多端是有序的，則需要在多端的固定表中增加一列，以存儲記錄多端實例次序的順序值，如圖5所示。

圖5 1：N關聯映射

多對多關聯映射規則需要將關聯單獨映射成一張關系表，如圖6所示。

本文分析了三種典型的元數據管理策略，并進行了詳細的比較，提出了基于CWM管理策略的元數據管理體系結構，解決了多個廠商的產品之間的元數據交換使用繁瑣而復雜的軟件工具來實現交換的問題。CWM為數據倉庫和商業智能環境下的元數據交換制定了一個標準，元倉庫是對其的映射實現，用元倉庫來存放管理元數據，做到元數據存儲、管理和交換的協調統一。

[1]吳曉淵，寧洪.基于CWM的企業數據集成研究[C].中國計算機大會，2005.

[2]VADUVA A，DITTRICH K R.Metadata management for data warehousing： between vision and reality[C].2001 Int′1 Database Engineering&Amp； Application Symp，2001.

[3]楊華甫，鄧守城，高張.CWM中基于元模式的數據集成研究與實現[J].現代計算機，2008(8).

[4]聶茹，張虹.數據倉庫元數據管理模式的分析與比較[J].計算機應用研究，2005，22(2).

[5]馬思紅.淺談面向對象數據庫的技術和發展[J].安徽農業科學，2007，35(24).

[6]INMON W H.Buildingthedatawarehouse[M].John Wiley&Sons Inc.2005.