謝培基,余金山
(華僑大學 計算機科學與技術(shù)學院,福建 泉州 362021)
數(shù)據(jù)倉庫技術(shù)是在數(shù)據(jù)庫基礎(chǔ)上發(fā)展而來的新一代信息管理技術(shù),主要用于支持企業(yè)信息集成、數(shù)據(jù)挖掘、企業(yè)決策支持等的應用。在數(shù)據(jù)倉庫建設(shè)過程中,由于各工具廠商采用不同的元數(shù)據(jù)標準和不同的元數(shù)據(jù)管理策略,使得依靠這些工具進行數(shù)據(jù)集成、數(shù)據(jù)共享顯得十分困難。為了統(tǒng)一數(shù)據(jù)倉庫開發(fā)商元數(shù)據(jù)管理策略,實現(xiàn)元數(shù)據(jù)的交流和數(shù)據(jù)的集成,2001年OMG組織在其已制定的規(guī)范 UML、MOF、XMI的基礎(chǔ)上提出公共倉庫元模型(CWM)。CWM是OMG制定的一個互操作標準,為數(shù)據(jù)倉庫和業(yè)務分析領(lǐng)域中使用的元數(shù)據(jù)定義了一種通用語言和交換機制[1]。CWM不僅提供了極受歡迎的描述數(shù)據(jù)倉庫與業(yè)務分析元數(shù)據(jù)的公共元模型,而且還提供了基于XML的交換工具。CWM本質(zhì)上是一種交換技術(shù),其目的是促進多個廠商的不同軟件工具間的元數(shù)據(jù)交換活動。
本文基于CWM的元數(shù)據(jù)管理策略,介紹了元數(shù)據(jù)管理的三種主要策略,并對此三種策略進行比較,分析各策略的功能與復雜度,總結(jié)基于CWM的元數(shù)據(jù)管理策略的優(yōu)勢,進而給出基于CWM元數(shù)據(jù)管理策略改進的元數(shù)據(jù)管理體系結(jié)構(gòu),最后討論了元倉庫的設(shè)計。
元數(shù)據(jù)管理策略為元數(shù)據(jù)集成、共享和重用制定目標和需求。成功進行元數(shù)據(jù)集成的關(guān)鍵之一是建立一個有效的元數(shù)據(jù)管理策略。從元數(shù)據(jù)的發(fā)展歷史[2]來看,元數(shù)據(jù)管理策略包括三種:搭建元數(shù)據(jù)橋、搭建元數(shù)據(jù)中央存儲庫、構(gòu)建元數(shù)據(jù)倉庫。
(1)搭建元數(shù)據(jù)橋[3]:是一種能夠?qū)⒁粋€產(chǎn)品的元數(shù)據(jù)轉(zhuǎn)換成另一個產(chǎn)品所要求的格式的軟件。使用元數(shù)據(jù)橋?qū)崿F(xiàn)不同工具間的元數(shù)據(jù)集成是一種點到點的元數(shù)據(jù)體系結(jié)構(gòu)。在這種結(jié)構(gòu)中,每一對被集成的工具之間都需要一個獨立、雙向的橋,對于n個產(chǎn)品要實現(xiàn)元數(shù)據(jù)交換必須建立n×(n-I)個元數(shù)據(jù)橋。這種方式集成元數(shù)據(jù)大幅增加了開發(fā)和維護費用,而且通常將一種格式的元數(shù)據(jù)轉(zhuǎn)換為另一種格式時,都會有一定的信息損失。
(2)搭建元數(shù)據(jù)中央存儲庫[4]:是具有特定目的的數(shù)據(jù)庫,它存儲、控制并能操作環(huán)境中其他所有相關(guān)軟件產(chǎn)品的元數(shù)據(jù)。軟件產(chǎn)品從中央存儲庫中檢索、使用元數(shù)據(jù),每個產(chǎn)品必須實現(xiàn)它自己的存儲庫訪問層(另一種形式的橋)。通過使用元數(shù)據(jù)中央存儲庫可以在一定程度上解決定義全局可用且被廣泛理解的元數(shù)據(jù)的需要但并沒有完全消除問題,它仍然需要使用到元數(shù)據(jù)橋,使得成本無法降低很多,也沒有消除受制于特定的廠商的問題。
由于點到點的體系結(jié)構(gòu)和中央存儲庫的集成體系結(jié)構(gòu)并沒有形成一個統(tǒng)一的元數(shù)據(jù)標準,所以其方案成本都相對昂貴。
(3)構(gòu)建元數(shù)據(jù)倉庫:即是基于CWM的元數(shù)據(jù)管理策略。元數(shù)據(jù)倉庫的功能包括對元數(shù)據(jù)源的ETL、元數(shù)據(jù)的Warehouse以及終端用戶的各種分析、挖掘、報告工具。通過構(gòu)建基于CWM的元數(shù)據(jù)倉庫,使得各軟件產(chǎn)品元數(shù)據(jù)有一個一致的標準(CWM標準),各軟件工具之間只需要建立一個與元數(shù)據(jù)倉庫連接的 “橋”(即CWM適配器)就能實現(xiàn)元數(shù)據(jù)的交換或共享。元數(shù)據(jù)倉庫與元數(shù)據(jù)存儲庫都要求建立通用的元數(shù)據(jù)標準,但二者相比有所不同:①元數(shù)據(jù)存儲庫的刷新周期相對于元數(shù)據(jù)倉庫來說要慢,元數(shù)據(jù)倉庫的元數(shù)據(jù)是準實時的,而元數(shù)據(jù)存儲庫的元數(shù)據(jù)通常的刷新周期在1天以上;②元數(shù)據(jù)倉庫所集成的元數(shù)據(jù)不斷變化,其保存元數(shù)據(jù)的更新情況。而元數(shù)據(jù)存儲庫則是將所有不同時期的元數(shù)據(jù)都存儲下來。
通過對上述三種元數(shù)據(jù)管理策略的分析,得出如圖1所示的三種策略的對比圖。
圖1 元數(shù)據(jù)管理策略對比
基于CWM的元數(shù)據(jù)管理策略使得元數(shù)據(jù)的交換有了一個統(tǒng)一的具體通用標準,解決了用元數(shù)據(jù)橋式的元數(shù)據(jù)交換帶來的元數(shù)據(jù)的雜亂無章、不可理解性,以及為了讀懂接收的元數(shù)據(jù),對交換的元數(shù)據(jù)進行從一種格式到另一種格式的轉(zhuǎn)換所帶來的一定數(shù)量的元數(shù)據(jù)的丟失,破壞了元數(shù)據(jù)的完整性、準確性。
比較三種元數(shù)據(jù)的功能復雜度,CWM元數(shù)據(jù)管理策略中使用的CWM元倉庫既滿足了性能的要求,又能夠提供很廉價的存放元數(shù)據(jù)的場所;而對于元數(shù)據(jù)中央存儲庫,雖然性能上偏優(yōu),但元數(shù)據(jù)在獲得庫所提供的復雜性能的同時也會受到它的限制,例如庫本身的復雜性和資源需求,導致人員培訓費用的增加等。
通過對三種元數(shù)據(jù)管理策略的分析比較可以發(fā)現(xiàn),搭建基于CWM的元數(shù)據(jù)倉庫的管理策略存在較多的優(yōu)點,它能夠以較少的代價提供豐富的數(shù)據(jù)管理功能,即持續(xù)存儲、允許并發(fā)、對數(shù)據(jù)倉庫環(huán)境中復雜元數(shù)據(jù)提供事物訪問,而相對于一個完善的基于元數(shù)據(jù)中央存儲庫的元數(shù)據(jù)管理系統(tǒng)來說,基于CWM的元數(shù)據(jù)管理系統(tǒng)在功能上還存在一些不足,如版本化、生命周期的管理等。針對基于CWM的元數(shù)據(jù)管理策略不足,本文給出了一種如圖2所示改進的元數(shù)據(jù)管理體系結(jié)構(gòu)。
該系統(tǒng)結(jié)構(gòu)主要由元倉庫、可操作的數(shù)據(jù)存儲器、建模工具、元數(shù)據(jù)管理工具及其他一些數(shù)據(jù)庫應用工具或軟件產(chǎn)品等模塊組成。
(1)元倉庫:是整個架構(gòu)的核心,是一個全局共享元數(shù)據(jù)的以CWM編碼的關(guān)系型數(shù)據(jù)庫,主要用于存儲管理各以CWM為元數(shù)據(jù)標準的工具產(chǎn)生的元數(shù)據(jù)和以CWM規(guī)范建模和操作過程中所產(chǎn)生的元數(shù)據(jù)以及從各類型數(shù)據(jù)庫提取的元數(shù)據(jù)。
(2)建模工具:可供用戶對可操作的數(shù)據(jù)存儲器中的某一主題建立元模型實例,直接收集元數(shù)據(jù),然后存入到元倉庫中,作為其他工具所需要元數(shù)據(jù)的數(shù)據(jù)源。
(3)元數(shù)據(jù)管理工具:可供對元倉庫中的元數(shù)據(jù)進行增刪改查操作,方便用戶對元倉庫的更新和維護。但元倉庫中的元數(shù)據(jù)一般的用戶很難讀懂,很難將一堆雜亂的元數(shù)據(jù)聯(lián)系起來理解其實際意義,應當將其與建模工具相結(jié)合,用圖形化的形式顯示這些元數(shù)據(jù)的元數(shù)據(jù)模型。
(4)與元倉庫連接的各軟件工具、應用程序都支持CWM標準,它們都實現(xiàn)了相同的用于元數(shù)據(jù)交換的公共接口,這也意味著任何支持CWM的軟件組件都能夠很容易地理解其他支持CWM的組件的元數(shù)據(jù)實例,并且能通過標準的CWM元數(shù)據(jù)接口集來訪問元數(shù)據(jù)。在這些支持CWM的工具與元倉庫的元數(shù)據(jù)交流中,同樣需要一個元數(shù)據(jù)“橋”,這個橋可以用一個CWM適配器的輕量級的橋代替。
(5)CWM適配器是一個軟件,它可以理解CWM元模型以及擁有該適配器的軟件產(chǎn)品內(nèi)部的元模型和專有的元數(shù)據(jù)接口。適配器的公共端實現(xiàn)CWM的標準接口,另一端則連接到產(chǎn)品的特定接口。針對某一軟件產(chǎn)品或工具寫適應它的適配器只需要編寫一次,所以它相對于其他的元數(shù)據(jù)橋節(jié)省了很多開銷。
在元數(shù)據(jù)管理體系結(jié)構(gòu)中,CWM編碼的元倉庫是整個架構(gòu)的核心。因為CWM本身是一個面向?qū)ο蟮脑P?,而各軟件產(chǎn)品或工具的元數(shù)據(jù)大部分是建立在關(guān)系數(shù)據(jù)庫之上,且目前面向?qū)ο蟮臄?shù)據(jù)庫管理系統(tǒng)不普及[5],因而無法使用面向?qū)ο蟮腄BMS來創(chuàng)建一個元倉庫,因此,需要將CWM的面向?qū)ο笤P陀成涞揭粋€關(guān)系數(shù)據(jù)庫中,建立基于關(guān)系數(shù)據(jù)庫的元倉庫。在將CWM面向?qū)ο蟮母拍钣成涞疥P(guān)系表上同時又要保持元數(shù)據(jù)本身的邏輯結(jié)構(gòu)不變,需要解決CWM中數(shù)據(jù)類型、類、繼承和關(guān)聯(lián)等在關(guān)系數(shù)據(jù)庫中的映射問題。在CWM中大量使用了UML的繼承特性,CWM的21個元模型包[6]中就存在著大量的泛化層次結(jié)構(gòu),因此,選擇如何實現(xiàn)泛化層次在元倉庫的開發(fā)是最關(guān)鍵的。為此,下面首先分析了繼承模式的幾種映射策略,選擇了一種實現(xiàn)方便、節(jié)約存儲空間的方法來實現(xiàn)元倉庫的建立,然后討論對象關(guān)系映射中數(shù)據(jù)類型、關(guān)聯(lián)的映射問題。
從類到表的映射并不是簡單的一一對應關(guān)系,因為一個子類可以繼承父類的一些特性和操作,而繼承是UML和面向?qū)ο笙到y(tǒng)的一個主要特征,它把類組織成逆向的樹形結(jié)構(gòu) (即泛化層次),因此必須考慮泛化層次的對象的映射問題。以圖3所示的CWM關(guān)系型包中的Relational::Trigger的泛化層次為例,給出幾種對象關(guān)系映射策略。
圖3 Relational::Trigger的泛化層次
(1)整個泛化層次結(jié)構(gòu)映射成一張表
將一個完整的泛化層次結(jié)構(gòu)映射成一張表,層次結(jié)構(gòu)中所有類的屬性都存放在這個表中,每個實例對應表中的一行。為了表明一個對象實例是屬于哪個類的,必須添加一個屬性“對象類別”O(jiān)ID,這種映射對應的表如表1所示。這種映射策略的優(yōu)點是結(jié)構(gòu)相對簡單,只有一個單一的表,其缺點是存儲空間浪費大、利用率低、類層次間的耦合非常高,當泛化層次結(jié)構(gòu)中的某一個類要增加屬性時,必須將一個新屬性增加到表中,這將影響到泛化層次中的所有類。
表1 整個泛化層次映射成一張表
(2)每個類映射成一張包含該類繼承屬性的表
使用這種映射策略,是將每個類映射成一張表,在表中既包含該類的屬性又包括其父類的屬性,如表2所示。這種映射策略的優(yōu)點是對單個類的查詢操作比較簡單,但是同樣會造成存儲空間的浪費,且類層次間的耦合性較高,當父類的結(jié)構(gòu)改變時,子類的結(jié)構(gòu)也要跟著改變。此外在實現(xiàn)上不方便,因為ModelElement有兩個子類 (Trigger類和 A類),Trigger有一個 ID,A也有一個ID,它們都是ModelElement的子類。如果這兩個表的主鍵相同,父類是無法識別這兩個子類的,所以這兩個ID一定不能相同,因此也就不能使用ID自動生成策略。
表2 每個類映射成一張表(包含該類的屬性又包括其父類的屬性)
(3)每個類映射成一張只包含該類特有屬性的表對各個表進行連接
使用這種策略子類對應的表ID應該參考父類對應的表的ID,即進行主鍵連接,對應的表結(jié)構(gòu)如表3所示。這種策略的優(yōu)點是存儲空間比較小,類間的耦合性比較低,查詢的時候不用找很多的表,缺點是要進行表連接,每當增加一個子類還應添加一個表。
表3 每個類映射成一張表進行連接
由上分析可以得出:(1)第一種策略是將整個泛化層次映射成一個表結(jié)構(gòu)。由于CWM元模型包中的泛化層次樹形結(jié)構(gòu)很深,所以會使得元組很龐大,浪費大量的存儲空間,且每次讀取時需要讀入很多不必要的屬性,因此不適合用這種策略建立元倉庫;(2)第二種策略同樣也會造成存儲空間的浪費,在實現(xiàn)上也不方便,亦不適合采用;(3)第三種策略是將每個類映射成一個表,每個表只包含該類含有的屬性,這種方法可節(jié)省存儲空間,雖然查詢操作涉及多個表的連接操作,連接操作將多個連接的表組成一個表較耗時,但在計算機速度不斷提高且不要求實時性的情況下適宜選用這種策略。所以本文使用第三種策略來實現(xiàn)CWM元模型包中各泛化層次結(jié)構(gòu)的映射問題,建立元倉庫。
每個CWM屬性可以是以下三類中的一種:簡單數(shù)據(jù)類型、枚舉數(shù)據(jù)類型和基于類的數(shù)據(jù)類型。這些CWM的數(shù)據(jù)類型集必須映射到相應的T-SQL語言支持的數(shù)據(jù)類型上,如果沒有直接對應的T-SQL數(shù)據(jù)類型,元倉庫必須創(chuàng)建數(shù)據(jù)結(jié)構(gòu)使其能模仿所要求的類型。如簡單的數(shù)據(jù)類型映射規(guī)則是:只要將CWM簡單數(shù)據(jù)類型映射到CORBA IDL類型碼,而后映射到T-SQL數(shù)據(jù)類型即可。
枚舉數(shù)據(jù)類型映射規(guī)則是將每個CWM枚舉數(shù)據(jù)類型用一個創(chuàng)建的表表示。枚舉數(shù)據(jù)類型表中的行只有一列,名為_EnumLiteral,它包含枚舉文字值。當基于枚舉數(shù)據(jù)類型的列值變化時,新的取值按照該表確定以保持列數(shù)據(jù)的完整性。
基于類的數(shù)據(jù)類型映射規(guī)則,則需要創(chuàng)建一個基于類的類型的實例,然后將該實例的鍵存放在一個向表示擁有該類屬性的類的表增加的基礎(chǔ)列中。
關(guān)聯(lián)是UML中表示類的實例間的關(guān)系的一種方法,有一對一、一對多、多對多三種關(guān)聯(lián)。
對于一對一關(guān)聯(lián)映射規(guī)則,只要在如圖4所示的兩個關(guān)聯(lián)類各對應的表中增加一列。
圖4 1:1關(guān)聯(lián)映射
一對多的關(guān)聯(lián)映射規(guī)則,僅僅需要改變關(guān)聯(lián)的多端的固定表,在該固定表中增加一列,以存放一端的一個實例的標識值。如果關(guān)聯(lián)的多端是有序的,則需要在多端的固定表中增加一列,以存儲記錄多端實例次序的順序值,如圖5所示。
圖5 1:N關(guān)聯(lián)映射
多對多關(guān)聯(lián)映射規(guī)則需要將關(guān)聯(lián)單獨映射成一張關(guān)系表,如圖6所示。
本文分析了三種典型的元數(shù)據(jù)管理策略,并進行了詳細的比較,提出了基于CWM管理策略的元數(shù)據(jù)管理體系結(jié)構(gòu),解決了多個廠商的產(chǎn)品之間的元數(shù)據(jù)交換使用繁瑣而復雜的軟件工具來實現(xiàn)交換的問題。CWM為數(shù)據(jù)倉庫和商業(yè)智能環(huán)境下的元數(shù)據(jù)交換制定了一個標準,元倉庫是對其的映射實現(xiàn),用元倉庫來存放管理元數(shù)據(jù),做到元數(shù)據(jù)存儲、管理和交換的協(xié)調(diào)統(tǒng)一。
[1]吳曉淵,寧洪.基于CWM的企業(yè)數(shù)據(jù)集成研究[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中基于元模式的數(shù)據(jù)集成研究與實現(xiàn)[J].現(xiàn)代計算機,2008(8).
[4]聶茹,張虹.數(shù)據(jù)倉庫元數(shù)據(jù)管理模式的分析與比較[J].計算機應用研究,2005,22(2).
[5]馬思紅.淺談面向?qū)ο髷?shù)據(jù)庫的技術(shù)和發(fā)展[J].安徽農(nóng)業(yè)科學,2007,35(24).
[6]INMON W H.Buildingthedatawarehouse[M].John Wiley&Sons Inc.2005.