1. 前言

在事務處理系統中的資料，主要用於記錄和查詢業務情況。隨著資料倉庫（DW）技術的不斷成熟，企業的資料逐漸變成了決策的主要依據。資料倉庫中的資料是從許多業務處理系統中抽取、轉換而來，對於這樣一個複雜的企業資料環境，如何以安全、高效的方式來對它們進行管理和訪問就變得尤為重要。解決這一問題的關鍵是對元資料進行科學有效的管理。

2. 元資料

按照傳統的定義，元資料（Metadata）是關於資料的資料。在資料倉庫系統中，元資料可以幫助資料倉庫管理員和資料倉庫的開發人員非常方便地找到他們所關心的資料；元資料是描述資料倉庫內資料的結構和建立方法的資料，可將其按用途的不同分為兩類：技術元資料（Technical Metadata）和業務元資料（Business Metadata）。

技術元資料是儲存關於資料倉庫系統技術細節的資料，是用於開發和管理資料倉庫使用的資料，它主要包括以下資訊：

• 資料倉庫結構的描述，包括倉庫模式、檢視、維、層次結構和匯出資料的定義，以及資料集市的位置和內容；
• 業務系統、資料倉庫和資料集市的體系結構和模式
• 彙總用的演算法，包括度量和維定義演算法，資料粒度、主題領域、聚集、彙總、預定義的查詢與報告；
• 由操作環境到資料倉庫環境的對映，包括源資料和它們的內容、資料分割、資料提取、清理、轉換規則和資料重新整理規則、安全（使用者授權和存取控制）。 
  業務元資料從業務角度描述了資料倉庫中的資料，它提供了介於使用者和實際系統之間的語義層，使得不懂計算機技術的業務人員也能夠“讀懂”資料倉庫中的資料。業務元資料主要包括以下資訊：使用者的業務術語所表達的資料模型、物件名和屬性名；訪問資料的原則和資料的來源；系統所提供的分析方法以及公式和報表的資訊；具體包括以下資訊：
• 企業概念模型：這是業務元資料所應提供的重要的資訊，它表示企業資料模型的高層資訊、整個企業的業務概念和相互關係。以這個企業模型為基礎，不懂資料庫技術和SQL語句的業務人員對資料倉庫中的資料也能做到心中有數。
• 多維資料模型：這是企業概念模型的重要組成部分，它告訴業務分析人員在資料集市當中有哪些維、維的類別、資料立方體以及資料集市中的聚合規則。這裡的資料立方體表示某主題領域業務事實表和維表的多維組織形式。

業務概念模型和物理資料之間的依賴：以上提到的業務元資料只是表示出了資料的業務檢視，這些業務檢視與實際的資料倉庫或資料庫、多維資料庫中的表、欄位、維、層次等之間的對應關係也應該在元資料知識庫中有所體現。

3. 元資料的作用

(1) 元資料是進行資料整合所必需的

資料倉庫最大的特點就是它的整合性。這一特點不僅體現在它所包含的資料上，還體現在實施資料倉庫專案的過程當中。一方面，從各個資料來源中抽取的資料要按照一定的模式存入資料倉庫中，這些資料來源與資料倉庫中資料的對應關係及轉換規則都要儲存在元資料知識庫中；另一方面，在資料倉庫專案實施過程中，直接建立資料倉庫往往費時、費力，因此在實踐當中，人們可能會按照統一的資料模型，首先建設資料集市，然後在各個資料集市的基礎上再建設資料倉庫。不過，當資料集市數量增多時很容易形成“蜘蛛網”現象，而元資料管理是解決“蜘蛛網”的關鍵。如果在建立資料集市的過程中，注意了元資料管理，在整合到資料倉庫中時就會比較順利；相反，如果在建設資料集市的過程中忽視了元資料管理，那麼最後的整合過程就會很困難，甚至不可能實現。

(2) 元資料定義的語義層可以幫助終端使用者理解資料倉庫中的資料

終端使用者不可能象資料倉庫系統管理員或開發人員那樣熟悉資料庫技術，因此迫切需要有一個“翻譯”，能夠使他們清晰地理解資料倉庫中資料的含意。元資料可以實現業務模型與資料模型之間的對映，因而可以把資料以使用者需要的方式“翻譯”出來，從而幫助終端使用者理解和使用資料。

(3) 元資料是保證資料質量的關鍵

資料倉庫或資料集市建立好以後，使用者在使用的時候，常常會產生對資料的懷疑。這些懷疑往往是由於底層的資料對於使用者來說是不“透明”的，使用者很自然地對結果產生懷疑。而藉助元資料管理系統，最終的使用者對各個資料的來龍去脈以及資料抽取和轉換的規則都會很方便地得到，這樣他們自然會對資料具有信心；當然也可便捷地發現數據所存在的質量問題。甚至國外有學者還在元資料模型的基礎上引入質量維[6]，從更高的角度上來解決這一問題。

(4) 元資料可以支援需求變化

隨著資訊科技的發展和企業職能的變化，企業的需求也在不斷地改變。如何構造一個隨著需求改變而平滑變化的軟體系統，是軟體工程領域中的一個重要問題。傳統的資訊系統往往是通過文件來適應需求變化，但是僅僅依靠文件還是遠遠不夠的。成功的元資料管理系統可以把整個業務的工作流、資料流和資訊流有效地管理起來，使得系統不依賴特定的開發人員，從而提高系統的可擴充套件性。

4. 元資料的標準化

關於元資料的一般標準，從內容上，大致可分為兩類。一是元資料建模，是對將來元資料的組織進行規範定義，使得在元資料建模的標準制定之後產生的元資料都以一致的方式組織，從而保證元資料管理的一致性和簡單性。二是元資料互動，是對已有的元資料組織方式以及相互間互動格式加以規範定義，從而實現不同系統元資料的互動。目前，主要有以下組織定義了元資料相關的規範。

(1) 物件管理組織OMG

OMG在1995年採用了MOF（Meta Object Facility），並不斷完善之。1997年採用了UML，2000年，OMG又採用了CWM。這三個標準：UML、MOF和CWM形成了OMG建模和元資料管理、交換結構的基礎，推動了元資料標準化的快速發展。

(2) 元資料聯合會MDC

MDC建於1995年，目的是提供標準化的元資料互動。MDC於1996年開發了MDIS（Meta Data Interchange Specification）並完成了MDC－OIM的技術評審，MDC－OIM基於微軟的開放資訊模型OIM，是一個獨立於技術的、以廠商為核心的資訊模型。OIM是微軟的元資料管理產品Microsoft Repository的一部分。由微軟和其它20多家公司共同開發的，作為微軟開放過程的一部分，經過了300多個公司的評審。

為了推動元資料標準化的發展，MDC和OMG在元資料標準的制定上協同工作。1999年4月，MDC成為OMG的成員，而OMG也同時成為MDC的成員。MDC中使用了OMG的UML，而MDC－OIM中的資料倉庫部分被用來作為OMG的公共倉庫元資料互動（CWMI：Common Warehouse Metadata Interchange）的設計參考。在兩個組織的技術力量的合作努力下，元資料標準將逐步一致化。公共倉庫元模型(CWM)是為資料倉庫和業務分析環境之間方便地交換元資料而制定的一個標準，已經成為模型驅動體系結構(MDA)新策略方向中的核心組成部分。下面我們講重點講述CWMI機器在資料倉庫中的應用。

5. CWM提出的背景

• 從資料倉庫開發者的角度：單一工具很少能完全滿足使用者不斷變化的需求，但同時又很難對各種產品進行整合；
• 從資料倉庫使用者的角度：面對的資訊量太大，無法輕易找到自己真正需要的，而且把這些資訊完整正確地表示出來也是個挑戰；
• 從資料倉庫供應商的角度：目前資訊的共享還沒有標準格式，元資料整合的代價太大；

現在有很多資料倉庫產品，它們對元資料都有自己的定義和格式，因此建立、管理和共享元資料很耗時而且容易出錯。要解決上面這些問題，必須用標準的語言描述資料倉庫元資料的結構和語義，並提供標準的元資料交換機制。CWM就是滿足這些條件的一個規範。OMG在2000年釋出了CWM規範，旨在推動資料倉庫、智慧商務和知識管理方面元資料的共享和交換。和OMG合作提出CWM規範的公司有：IBM，Unisys，NCR，Hyperion Solutions，Oracle，UBS AG，Genesis Development，Dimension EDI。還有一些公司明確表示支援CWM，包括：Deere & Company，Sun，HP，Data Access Technologies，InLine Software，Aonix，Hitachi, Ltd。

6. OMG組織的CWM模型

CWM完整地描述了資料倉庫元資料交換的語法和語義以及用於異質平臺之間的元資料交換機制，OMG元資料知識庫體系結構如圖1所示。

圖1 OMG的元資料倉儲體系結構

CWM為資料倉庫和商業智慧（BI）工具之間共享元資料，制定了一整套關於語法和語義的規範。它主要包含以下四個方面的規範：

(1) CWM元模型（Metamodel）：描述資料倉庫系統的模型；

(2) CWM XML：CWM元模型的XML表示；

(3) CWM DTD：DW/BI共享元資料的交換格式

(4) CWM IDL：DW/BI共享元資料的應用程式訪問介面（API）

下面重點討論CWM元模型的組成，它與OIM規範一樣，也是由很多包組成的。組成CWM元模型的包結構如圖2所示。

圖2 CWM元模型的包結構

如圖中所示，CWM元模型主要包括四層：基礎包Foundation，資源包Resource，分析包Analysis和管理包Management。

基礎包主要定義了為CWM其它包所共享的一些基本概念和結構，它包含的子包有：

• Business Information：定義了面向業務的通用資訊，比如負責人資訊等；
• Data Types：定義了其它包用以建立自己所需的資料型別的元模型元件；
• Expressions：定義了CWM其它包定義表示式樹所需的元模型元件；
• Keys and Indexes：定義了描述關鍵字和索引的共享元模型；
• Software Deployment：描述一個軟體在資料倉庫中如何被使用的元模型；
• Type Mapping：支援不同系統之間資料型別的對映的元模型；

資源包主要定義了一些描述常用的資料來源/目標的元模型，它包含的子包有：

• Relational：描述通過關係型介面訪問的資料庫的資料模型和元模型，比如RDBMS，ODBC，JDBC等；
• Record：描述記錄的基本概念和結構的元模型，這裡記錄的概念很廣泛，它可以描述任何結構化的資訊，比如資料庫的一條記錄、文件等；
• Multidimensional：描述多維型資料庫的元模型；
• XML：描述用XML表示的資料來源和資料目標；

分析包主要定義了一些描述資料倉庫工具的元模型，它包含的子包有：

• Transformation：定義資料倉庫中抽取轉換規則的元模型，它包含對各種型別資料來源之間的轉換規則的描述；
• OLAP：對OLAP工具和應用進行描述，並定義了它到實際系統的對映；
• Data Mining：對資料探勘工具和應用進行描述；
• Information Visualization：定義了問題領域中有關資訊釋出或者資訊視覺化的元模型；
• Business Nomenclature：對業務資料進行描述，比如業務術語及其適用範圍等；

管理包主要定義了一些描述資料倉庫執行和排程資訊的元模型，它包含的子包有：

• Warehouse Process：描述資料倉庫中抽取轉換規則的執行過程，也就是各個轉換規則的觸發條件；
• Warehouse Operation：描述資料倉庫日常執行情況的元模型；

7. CWM的特點

通過對CWM組成結構的介紹，可以看出CWM具有以下特點：

• 對所有的資料倉庫功能元資料定義了詳細的元模型和交換方式，包括技術元資料（比如Software Deployment，Transformation，Warehouse Process等）和業務元資料（比如OLAP，Business Information等）；
• 定義了一個通用且強大的Transformation包，可以表示任何資料來源和資料目標之間的轉換規則。此外，還為多種常用的資料來源/目標（比如Relational，Record，Multidimensional，XML等）和工具相關的資料來源（比如IMS，DMSII，COBOL Data，Essbase和Express等）定義了元模型和交換方式；
• 對所有的資料倉庫執行元素定義了元模型和交換方式，包括排程、狀態報告和歷史記錄等；
• 對所有的分析型資料以及主要的分析型資料模型定義了元模型和交換方式，比如多維型；
• 對操作型資料以及主要的操作型資料模型定義了元模型，比如關係型和麵向物件型；

8. CWM的應用

CWM主要面向以下幾類使用者：

• 資料倉庫平臺和工具提供商：CWM為他們提供了一個元件可插卸的通用系統框架。因為這是一種全球通用的元資料交換協議，所以他們可以很方便地在各種異質平臺上釋出自己的產品；
• 資料倉庫服務提供者：可重用、可編輯、可擴充套件的CWM元資料大大提高了他們的工作效率。因為CWM與產品無關，所以可以避免大量的重複設計工作；
• 資料倉庫管理員：資料倉庫管理員有時需要對現有工具進行整合，而CWM XML無疑為他們提供了一種最方便的整合方式。另外，管理員經常需要對資源進行增減、分割槽或者重新分配，CWM提供了這方面的元資料以幫助他們完成這些工作，並對改變造成的影響作出評估；
• 終端使用者：CWM為查詢和展示工具定義了元模型，以便更方便快捷地為終端使用者展示他們所需的資訊；
• 資訊科技管理者：CWM為系統管理和報表工具定義了元模型，使得使用者能夠更輕鬆地對系統和資訊進行管理；

例如，在企業資料倉庫體系結構中，ETL元件是構建資料倉庫一個非常重要的部分，它將資料從外部系統提取出來，排除噪聲，去掉冗餘，並進行轉換、聚集、重構，以利於使用者使用和理解的方式儲存到資料倉庫中，其主要目的有兩個：改進資料倉庫中資料的質量和提高資料的可用性。ETL過程的工作量比較大，可以佔到資料倉庫開發工作的80%左右，其過程設計和執行情況直接影響到資料倉庫中資料的質量和使用者的使用，所以應該予以足夠的重視。ETL過程主要包括以下一些步驟：

• 讀取資料：資料倉庫系統通常都需要從多種不同的資料來源中讀取資料，如果資料來源結構清晰、定義規範且說明文件比較全，這一步會相對簡單些，但很多情況下，遺留系統中總會有些欄位的含義不明確並且各個資料來源的資料語義不能完全保持一致，這時需要抽取含義明確的資料並在抽取過程中對同一語義的資料進行重新定義；
• 清潔資料：清潔包括範圍檢驗和複雜的重新格式化以去除源資料中不規範的部分，也就是髒資料。清潔不僅檢查欄位或欄位組的儲存格式，而且檢查欄位中資料的有效值。簡單情況下，可以用一些預先定義的規則或演算法對資料進行過濾，當這種做法不能滿足需求時，可能需要利用人工智慧技術以獲取所需的輸出資料；
• 轉換資料：在初步獲取所需的乾淨的源資料後，需要對它們進行一系列的變換，包括：資料型別轉換、日期/時間格式轉換、重構（比如變換儲存格式）、綜合（首先對不同資料來源的資料進行整合，然後再聚合到不同的粒度，同時為每條記錄生成關鍵字）等。在轉換過程中，不可避免地需要對資料以及資料之間的關係進行重新定義，但無論如何變化，它們都必須遵循統一的模型和語義，以保持整個企業資料都一致性；
• 裝載資料：在所需資料處理完畢後，就可以把它們裝載到資料倉庫中，這個過程相對簡單一些，但由於源系統和目標系統通常採用不同的工具實現並且可能位於不同型別的作業系統中，所以要求ETL過程能夠支援多種型別的系統，並注意格式的轉換；

ETL的實現可以有兩種方法，一是使用專用的資料轉換工具，二是通過手工編制程式完成。考慮到時間的許可範圍、預算、系統規模以及技術可行性等方面的因素，對於規模小、實際寬裕、程式設計技巧高的專案可以採用手工轉換的方式。而對於規模大、時間緊、技術成熟的專案可以考慮使用專用的抽取轉換工具完成，或者採用二者結合的方式。

ETL元件的CWM元模型主要定義了以下三組類：黑盒變換、白盒變換和變換的執行順序。黑盒變換元模型在比較粗的粒度上（也就是資料來源的級別）描述變換，包括以下一些類和介面：

• Transformation：描述一個變換步驟。其主要介面有：建立變換；查詢和設定屬性（比如是否主變換等）；查詢和修改變換使用的函式；查詢、修改、增加變換的資料來源和資料目標；查詢、修改和新增變換使用的模型（可以為空）；
• DataObjectSet：即資料集，描述變換用到的資料來源和資料目標。其主要介面有：建立資料集；查詢、新增、修改和刪除資料集包含的資料元素；查詢、新增、修改和刪除以該資料集為資料來源或目標的變換；
• TransformationUse：用於連線一個變換和實現該變換的物件（比如程式、查詢、規則等）的模型。其主要介面有：建立TransformationUse；查詢和設定實現物件的型別；查詢、新增、修改和刪除TransformationUse連線的變換和實現物件；

白盒變換在比較細的粒度上描述變換（也就是資料來源的屬性的級別），主要包括以下一些類和介面：

• FeatureMap：描述Feature之間的變換。主要介面建立FeatureMap；有查詢、新增、刪除和修改該變換用到的函式及其源/目標Feature；查詢和修改包含該FeatureMap的ClassifierMap；
• ClassifierMap：描述Classifier之間的變換。主要介面有建立ClassifierMap；查詢、新增、刪除和修改該變換用到的函式及其源/目標Feature；查詢和修改包含該ClassifierMap的TransformationMap以及該ClassifierMap包含的FeatureMap和ClassifierFeatureMap；
• ClassifierFeatureMap：描述Classifier和Feature之間的變換。主要介面有建立ClassifierFeatureMap；查詢和修改該變換的型別；查詢、新增、刪除和修改該變換用到的函式及其源/目標Feature和Classifier；查詢和修改包含該ClassifierFeatureMap的ClassifierMap；
• TransformationMap：由ClassifierMap組成，描述資料集之間的變換；主要介面有建立TransformationMap；查詢、新增、刪除和修改該TransformationMap包含的ClassifierMap；

變換的執行順序控制主要包括以下一些類和介面：

• TransformationTask：即變換任務，它描述一組必須作為一個邏輯單元同時執行的變換。一個變換任務可以有一個功能相反的逆向變換任務與之對應，稱為inverse task。TransformationTask的主要介面有建立變換任務；查詢、新增、刪除和修改該變換任務包含的變換、第一個執行的變換及其對應的逆向變換任務；
• TransformationStep：即變換步驟，它和變換任務是一一對應的，用於描述一個變換任務在變換活動（TransformationActivity）中的執行順序。TransformationStep的主要介面有建立變換步驟；查詢和設定它對應的變換任務以及包含它的變換活動；查詢、新增、刪除和修改在該變換步驟之前和之後執行的步驟，以及施加於該步驟之上的限制條件；
• TransformationActivity：即變換活動，用於描述一個變換系統。其主要介面有建立變換活動；查詢和設定活動的建立日期；查詢、新增、刪除和修改該變換活動包含的變換步驟；
• PrecedenceConstraint和StepPrecedence：用於控制變換步驟執行的順序。其主要介面有建立PrecedenceConstraint和StepPrecedence；查詢、新增、刪除和修改在該步驟之前和之後執行的變換；

9. 元資料管理系統的設計原則

資料倉庫環境下的元資料管理系統的建設是十分困難的。但是在實際專案的實施過程中，這個環節又是非常重要的。當前情況下，我們認為OMG組織的CWM標準將會成為資料倉庫元資料領域事實上的標準，在元資料管理系統的建立過程中應儘量參考這個標準，這樣使系統的可擴充套件性增強。可是在與之相關的工具成熟之前，我們完全可以採用OIM中的元模型（因CWM對OIM是相容的）以及支援它的元資料管理工具進行元資料管理系統的建設，而且元資料所包含的範圍很廣。我們在建立元資料管理系統的時候，絕對不能盲目追求大而全，要堅持目標驅動的原則，在實施的時候要採取增量式、漸進式的建設原則。具體的建設步驟如下：

（1）如果是在建設資料倉庫系統的初期，那麼首先要確定系統的邊界範圍，系統範圍確定的原則是首先保障重點，不求大，只求精。

（2）系統邊界確定以後，把現有系統的元資料整理出來，加入語義層的對應。然後存到一個數據庫中，這個資料庫可以採用專用的元資料知識庫，也可以採用一般的關係型資料庫。

（3）確定元資料管理的範圍。比如，我們只想通過元資料來管理資料倉庫中資料的轉換過程，以及有關資料的抽取路線（參見第8點中的例子），以使資料倉庫開發和使用人員明白倉庫中資料的整個歷史過程。

（4）確定元資料管理的工具，採用一定的工具可以完成相應的工作。當前相關工具有微軟的Repositry，它帶有相應的程式設計介面，可以藉助於它來完成元模型出入庫的功能；與之相似的還有Platinum的OEE；另外還有Sybase的Wcc，它可以通過MDC以前的一個老標準――MDIS來整合抽取工具與轉換工具，在一個視窗中就可以表示資料抽取與轉換，並且可以把語義層以MDIS的格式匯出到一個前端工具當中（比如Cognos的Improptu）

總之，建立元資料管理系統一定要堅持關注標準，又不被標準所束縛的原則，建立符合自身目標的元資料管理系統。