CWM元模型研究及其在廣發(fā)銀行數(shù)據(jù)倉庫中的應(yīng)用

1、CWM元模型研究及其在廣發(fā)銀行數(shù)據(jù)倉庫中的應(yīng)用李珊珊一數(shù)據(jù)倉庫的描述需求數(shù)據(jù)倉庫是企業(yè)級信息管理的一項新興技術(shù)。它的目的是為了將企業(yè)的大量歷史數(shù)據(jù)按主題集成在一起，并以一種統(tǒng)一的模式供分析和知識挖掘使用。數(shù)據(jù)倉庫中技術(shù)種類繁多，不象數(shù)據(jù)庫系統(tǒng)那樣單一，典型的數(shù)據(jù)倉庫技術(shù)包括數(shù)據(jù)抽取技術(shù)、OLAP技術(shù)、數(shù)據(jù)挖掘技術(shù)等。構(gòu)建一個數(shù)據(jù)倉庫需要考慮到它的創(chuàng)建、管理、使用和維護等諸多方面，如創(chuàng)建過程中要考慮舊數(shù)據(jù)庫系統(tǒng)的數(shù)據(jù)模型、數(shù)據(jù)集成的ETL (Extract, Tansfomation and Load) 規(guī)則、倉庫中新數(shù)據(jù)模型的建立等，使用過程要考慮數(shù)據(jù)的物理模型和展現(xiàn)方式、對數(shù)據(jù)進行操作的各種

2、統(tǒng)計分析算法、數(shù)據(jù)挖掘規(guī)則等。對于這些應(yīng)用需求，數(shù)據(jù)倉庫建模應(yīng)該具備描述它們的能力，無論是底層的數(shù)據(jù)源信息，還是高層的各種操作信息，方方面面都應(yīng)盡量涉及到。經(jīng)過分析研究，發(fā)現(xiàn)OMG組織的CWM具備了這種能力，它提供了描述數(shù)據(jù)源、數(shù)據(jù)目標(biāo)、轉(zhuǎn)換、分析、處理、操作等與建設(shè)和管理數(shù)據(jù)倉庫相關(guān)的元數(shù)據(jù)基礎(chǔ)框架（構(gòu)成規(guī)則集）1，使不同廠商產(chǎn)品的元數(shù)據(jù)通信和共享有了一個切實可行的標(biāo)準(zhǔn)。在深入理解CWM的基礎(chǔ)上，1.2節(jié)總結(jié)了CWM的內(nèi)容框架和各個組成部分的依賴關(guān)系。二、 CWM的內(nèi)容框架參考數(shù)據(jù)倉庫的描述需求，課題中對CWM的內(nèi)容體系進行了總體研究，深入分析了它的組成及結(jié)構(gòu)23。CWM基本描述了數(shù)據(jù)倉庫的

3、各個方面，包括基本類型信息、數(shù)據(jù)資源信息、數(shù)據(jù)分析信息、倉庫管理信息等。當(dāng)然，它不可能囊括數(shù)據(jù)倉庫中的所有信息，隨著數(shù)據(jù)倉庫技術(shù)的不斷進步，需要描述的新信息也越來越多，這些信息只能被包含進CWM的后續(xù)擴展規(guī)范中。OMG的CWM工作小組也在時刻關(guān)注數(shù)據(jù)倉庫的最新發(fā)展動向。目前的CWM版本所包含的信息基本涉及了數(shù)據(jù)倉庫領(lǐng)域的各個方面，雖然不是完全的但至少是描述倉庫操作所需的最少信息。另外，對于其所描述的元數(shù)據(jù)，語義都是精確的、無歧義的。圖1-1是CWM的內(nèi)容結(jié)構(gòu)圖1，從圖中可以看出，CWM的內(nèi)容按包組織，每個包盡量涉及一個獨立的領(lǐng)域，這樣極大地方便了開發(fā)者的建模工作，因為在建模時只取所需的包即可。

4、并且，包的數(shù)目沒有太大，結(jié)構(gòu)更易于擴展，CWM目前的版本中包含了18個包和一個ObjectModel，CWM的這種特性也使得它易于理解。每個包都由一系列UML表示的類圖組成。雖然這些包描述的領(lǐng)域不盡相同，但它們組織結(jié)構(gòu)并不完全獨立，事實上，它們之間有著緊密的依賴關(guān)系。在CWM的內(nèi)容框架中，所有包按功能和抽象層次組織成四層，同層的包的功能角色類似，如第二層中的包描述的都是數(shù)據(jù)倉庫的數(shù)據(jù)資源。每一層中的包都為同層或上層的包提供服務(wù)，如第三層包描述的操作都是基于第二層包描述的數(shù)據(jù)資源，層次越高描述的內(nèi)容越抽象。在包的結(jié)構(gòu)方面，或者上層包中的類和關(guān)聯(lián)繼承下層包中的類和關(guān)聯(lián)，或者在上層的包直接使用下層包

5、中定義的類或關(guān)聯(lián)，這樣做既使整個元模型組織更精練，又使CWM在功能結(jié)構(gòu)上十分清晰。圖1-1 CWM的內(nèi)容結(jié)構(gòu)圖如圖1-1所示，最底層的是ObjectModel，分析CWM的繼承圖，會發(fā)現(xiàn)它是整個CWM的基礎(chǔ)。ObjectModel實際是UML的一個子集， CWM最大程度地重用了UML中與描述數(shù)據(jù)倉庫領(lǐng)域相關(guān)的一些模型元素1,7。CWM所有包的類與關(guān)聯(lián)都是直接或間接地繼承ObjectModel中的類與關(guān)聯(lián)，這樣，CWM可以看作是從ObjectModel生長出來的一棵大樹，樹的根部就是ObjectModel。ObjectModel以上的四個層次依次為：Foundation層、 Resource層、

6、 Analysis層、Management層。每個層次中的包都為高層（或同層）的包提供服務(wù)。Foundation層的元模型主要是代表上層CWM包共享的概念與結(jié)構(gòu)，如表達式、索引、數(shù)據(jù)類型、軟件配置信息等，雖然這些都是很基本的信息，但它們與ObjectModel中的元素又有所不同，因為這些模型元素專有于CWM領(lǐng)域，而ObjectModel中的元素則更具一般性和通用性。Foundation層中的包以字母順序給出；Resource層中包含了OLTP系統(tǒng)與數(shù)據(jù)倉庫所使用的各種數(shù)據(jù)資源,有關(guān)系的、層次的、多維的等等，這些數(shù)據(jù)源都要用到Foundation層的通用信息，如關(guān)系包中描述索引和關(guān)鍵字的類都是從

7、Foundation層的Keys and Indexs包中繼承而來。此外，ObjectModel恰好是面向?qū)ο蟮臄?shù)據(jù)源，因此，ObjectModel在整個CWM承擔(dān)著兩種角色，一方面作為整個CWM的基礎(chǔ)，另一個方面又代表了面向?qū)ο髷?shù)據(jù)源；Analysis層提供了數(shù)據(jù)倉庫各種操作的元模型，包括OLAP、數(shù)據(jù)挖掘、轉(zhuǎn)換等，它們會被映射到由Resource層的包所定義的數(shù)據(jù)存儲中去。例如，Transformation元模型描述了數(shù)據(jù)倉庫中的數(shù)據(jù)源到數(shù)據(jù)目標(biāo)的轉(zhuǎn)換，OLAP元模型允許存儲在關(guān)系或多維數(shù)據(jù)引擎中的數(shù)據(jù)倉庫以多維視圖顯示。Management層定義了操作任務(wù)及其調(diào)度信息（Warehouse

8、 Process包）并記錄了數(shù)據(jù)倉庫活動以及相關(guān)的統(tǒng)計信息（Warehouse Operation Package）。CWM的所有包中的類與關(guān)聯(lián)都盡量利用了UML中的繼承機制，復(fù)用已有的元素。并且，所有的基類都只出現(xiàn)在Object Model、Foundation 和Resource層中，在更高的層中（Aanlysis層和Management層），已經(jīng)沒有基類出現(xiàn)。這樣做的主要目的是為了簡化高層包中的類圖，因為更高層中的類一般都要比低層多。這種組織方式也使得類圖更易于理解，因為類的總數(shù)減少了。圖1-2是分析得出的包依賴關(guān)系圖，箭頭指向代表依賴方向，即箭頭始發(fā)處的包中的類和關(guān)聯(lián)繼承箭頭指向的包中

9、的類和關(guān)聯(lián)。ManagementAnalysisResourceFoundationObjectModel圖1-2 CWM各包依賴關(guān)系圖CWM中的每個包都由一組類圖和相應(yīng)的約束組成，約束使用OCL來描述。所有的類都只包含靜態(tài)屬性，沒有包含任何操作屬性，CWM把操作信息留給工具自定義，從而為CWM開發(fā)商保留更大的靈活性。另外，類之間的關(guān)聯(lián)使用引用方式表達?？紤]到工作量的問題，在1.1節(jié)將以一個獨立完整的數(shù)據(jù)倉庫過程為主線詳細分析部分包的內(nèi)容。三、CWM各層內(nèi)容剖析考慮到工作量的問題，本文將不對CWM中的所有包進行分析，而是依據(jù)實際數(shù)據(jù)倉庫開發(fā)的經(jīng)驗只在四個層次中選一部分進行研究和實現(xiàn)，它們是描述

10、一個獨立完整的數(shù)據(jù)倉庫過程所需要的最少建模元素。分別挑選了Management層的Warehouse Process包和Warehouse Operation包、Analysis層的Transformation包和OLAP包、Resource層的Relation包和Multidimensional包以及Foundation層中的所有包。在分析這些包之前，先深入剖析ObjectModel。ObjectModel是整個CWM的基礎(chǔ)，它為創(chuàng)建和描述CWM的其它包提供了基本構(gòu)架。分析過程需要對照CWM規(guī)范中的類圖，由于CWM中的圖繁多，因此在正文中只附Core包的圖輔助講解。另外，分析由下往上按層次展

11、開。3.1.1 Object ModelObjectModel是UML的一個子集，它只含有UML中與描述數(shù)據(jù)倉庫有關(guān)的部分。ObjectModel又包括四個包：Core包 、Behavioral包、Relationship包和Instance包。Core包是核心，其余三個包都依賴且只依賴于Core包。除此之外，ObjectModel中再沒有其他依賴關(guān)系。 Core包Core 中總共有三個圖，分別見圖1-3,1-4,1-5。圖1-3 Core包類圖1從圖中可以看出，Element類位于最頂層，事實上，它也是CWM中所有類的祖先，如果把CWM想成一個樹狀的類繼承結(jié)構(gòu)，那么Element就是這棵樹的

12、根。Element中沒有任何屬性，只是一個抽象元類，包含表達語義信息的模型元素和用于表示的表達元素。ModelElement是Element的子類，前者只描述模型元素。模型元素與表達元素不同，表達元素是以表現(xiàn)模型為目的的圖形元素，它們不含有語義信息，而在CWM中，絕大多數(shù)類都是帶有語義信息的模型元素。ModeElement包含了一個最基本且最重要的屬性Name。除了少數(shù)幾個類，如Multiplicity，幾乎所有CWM類都是直接或間接地繼承ModelElement。并且ModelElement還作為這些類相互關(guān)聯(lián)的連接點，絕大多數(shù)提供通用服務(wù)的類，如Dependency，Constraint等

13、都直接關(guān)聯(lián)到ModelElement表示可以為所有的模型元素提供這種服務(wù)。 Core包中提供通用服務(wù)的類主要有以下這些：n Constraint：一種擴展機制，用于描述對模型元素的行為約束。n Dependency：定義了模型元素之間的依賴關(guān)系，與Dependency相關(guān)聯(lián)的兩個模型元素中，一個作為依賴方（client），另一個作為被依賴方（supplier）。n TaggedValue：一種名字值對的形式，表示與具體應(yīng)用相關(guān)的屬性，TaggedValue是一種擴展機制。任何模型元素或表達元素都可以帶有零或多個名字值對24。n Stereotype：該類也為CWM提供了一種擴展機制。在實際建模

14、過程中，開發(fā)人員可能想要傳遞某種語義差別，但是供使用的可能只有一種建模元素，為了表示這種差別，更精確地反映該模型元素所表達的語義，就可以用Stereotype24。比如說類可以分為實體類，邊界類和控制類，而在用UML建模時就只能用Class統(tǒng)一表示，為了在必要的時候加以區(qū)分，就可以使用Stereotype。再從ModelElement沿著繼承鏈往下看，Namespace的含義就象通常所說的容器，它的目的是為了按某種邏輯意義將元素分組。組包含一系列的ModelElement，且它與ModelElement的關(guān)系是強聚合關(guān)聯(lián)。除了頂級Namespace，幾乎所有的ModelElement都會屬于且

15、只能屬于一個Namespace。同一Namespace中ModelElement的命名是唯一的，命名規(guī)則一般為“Namespace名：ModelElement名”。因此，使用Namespace還可以避免在整個模型范圍內(nèi)的命名沖突。Classifier和Package都是Namespace的子類，可以這樣理解這兩個子類的意義：Classifier的作用類似于C+中的.h文件，而Package的作用類似于C+中的.cpp文件，一個描述靜態(tài)結(jié)構(gòu)，而另一個則描述具體實現(xiàn)。Classifier有多種具體的形式，包括Class，DataType等，Classifier常用作類型（Type）。作為一個Nam

16、espace，一個Classifier還可以嵌套定義其它的Classifier。Classifier也可能包含一系列Feature，比如說Attribute，Operation等。Class是一種最常見的Classifier，其實Classifier的每種子類都可按Class的概念理解，只是分別在內(nèi)容和使用上有了某些特殊限制。DataType既包含原始的數(shù)據(jù)類型（如整型，字符串等），又包含可定義的枚舉類型。一般來說，DataType常被用來作為屬性或參數(shù)的類型。Package也提供了一個分組機制，雖然父類Namespace已經(jīng)定義了“包含“的語義，但 Package還可以表示組織這些元素的依據(jù)

17、和目的。一個包可以通過“導(dǎo)入（import）”訪問其它包中的模型元素。當(dāng)包導(dǎo)入了其他模型元素后，包的范圍就被擴充了，加入了被導(dǎo)入的模型元素。Subsystem的直接父類（即多重繼承）有兩個：分別是Package和Classifier。Subsystem主要表示物理系統(tǒng)中的行為單元，描述一組模型元素的具體行為特征。Subsystem可以向外提供接口，這些接口描述了它與系統(tǒng)其他部分的關(guān)系以及使用環(huán)境。Model是從不同視圖的角度對系統(tǒng)進行的完整抽象。說它是完整的，是因為它從給定視圖全面地描述了系統(tǒng)和實體。一個物理系統(tǒng)可以定義多個Model，如分析模型，設(shè)計模型，實現(xiàn)模型。Feature也是Mode

18、lElement的子類，它表示一個具體特性，既可以是靜態(tài)特性（StructureFeature）也可以是動態(tài)特性（BehavioralFeature），靜態(tài)特性的一個例子就是屬性（Attribute），動態(tài)特性的一個例子是操作（Operation），它們被封裝在一個Classifier中。有關(guān)動態(tài)特性的模型元素在Behavior包中描述，Core中只描述了與靜態(tài)特性有關(guān)的模型元素。StructureFeature的類型由Classifier確定，既可以是一種簡單的數(shù)據(jù)類型，也可以是一個復(fù)雜類型，如Class等等。圖1-4 Core包類圖2在圖1-4中，列出了一些CWM中的支持類，分別是Expr

19、ession，Multiplicity和MultiplicityRange。Expression即通常所說的表達式，它有兩種子類型：BooleanExpression和ProcedureExpression。BooleanExpression描述布爾表達式的求值，而ProcedureExpression描述一個過程表達式的計算，其計算結(jié)果可能會影響當(dāng)前系統(tǒng)的運行狀態(tài)。Multiplicity表示允許的候選值范圍，也就是通常在關(guān)聯(lián)端的使用的取值個數(shù)約束。由于取值空間可能不連續(xù)，所以一個Multiplicity又可能包含多個MultiplicityRange，一個MultiplicityRange

20、定義一個整數(shù)范圍，下限必須是非負數(shù)，上限沒有限制，可以是無窮大。圖1-5 Core包類圖1圖1-5描述了CWM的擴展機制，共有包含三個元素：TaggledValue，Stereotype，和Constraint。上面已經(jīng)提到過，TaggledValue允許信息以名字值對的形式附加到任何模型元素，具體的含義已經(jīng)超出了CWM的范疇，在交換元數(shù)據(jù)時，交換雙方必須要有對名字值對的統(tǒng)一理解才能交換這些名字值對。Constraint和Stereotype上面已給出，這里不在贅述。Behavioral包Behavioral包中主要描述了Classifier的行為特性，如附錄中圖A-4所示。在該包中，最為重要

21、的一個類就是BehavioralFeature， BehavioralFeature描述模型元素的動態(tài)特性。從日常的觀點來看，BehavioralFeature代表程序邏輯中的可執(zhí)行單元，因此，它包含一系列的輸入輸出參數(shù)以及返回值。BehavioralFeature的參數(shù)用Parameter類來表示。Method和Operation都是BehavioralFeature的子類，Operation描述某種轉(zhuǎn)換或查詢，它有自己的名稱和參數(shù)列表，是程序邏輯的可直接調(diào)用的單元，而Method則表示Operation的實現(xiàn)，它指定了完成Operation的算法規(guī)則和過程描述，一個Operation可以有

22、多個Method實現(xiàn)，每個實現(xiàn)可能使用不同的程序語言，不同的算法。CallAction描述對一個Operation的具體調(diào)用，它還指定此次調(diào)用的實參，實參用Argument類表示，它與Parameter不同，Parameter主要是指形參。Interface是Classifier的子類，它是一系列Operation的集合，定義了能給外界提供的服務(wù)，只包含服務(wù)名而不包含實現(xiàn)。Event類描述一次值得注意的事件，它也包含多個Parameter，如鼠標(biāo)點擊事件中的參數(shù)包含點擊處的坐標(biāo)等等。但是，在CWM中并沒有描述當(dāng)事件發(fā)生以后將會采取什么行動，這個將留給具體的應(yīng)用去處理。Relationship包

23、Relationship包比較簡單,主要描述對象（即元數(shù)據(jù)）之間如何關(guān)聯(lián)，關(guān)聯(lián)有兩類：Generalization和Association，如附錄中的A-5所示。Generalization描述較為通用的classifier和較為特殊的Classifier之間的關(guān)聯(lián)，就如同UML里的繼承，這種關(guān)聯(lián)把類組織成一種層次的結(jié)構(gòu)。很明顯，與Generalization相關(guān)聯(lián)的兩個Classifier所充當(dāng)?shù)慕巧粋€叫child，代表較為特殊的一方，另一個是parent，代表較為通用的一方。在CWM中，允許出現(xiàn)多重繼承的形式，即一個child可以對應(yīng)多個parent，說明作為child的Classifi

24、er同時含有多個作為Parent的Classifier的特性。Association即常說的關(guān)聯(lián)。一個Association可以有多個AssociationEnd（至少兩個）兩個的話被稱為binary，大于兩個的被稱為n-ary，Association與AssociationEnd之間是通過ClassifierFeature關(guān)聯(lián)起來的。有三種類型的Association：ordinary association（普通關(guān)聯(lián)）, composite aggregate（組合式聚合關(guān)聯(lián)）和shareable aggregate（共享式聚合關(guān)聯(lián)）。ordinary association是通常意義上的

25、關(guān)聯(lián)，任何有聯(lián)系的模型元素之間都可以由這種關(guān)聯(lián)建立聯(lián)系。composite aggregate和shareable aggregate只有在二元的Association下才有意義。在composite aggregate中，被包含的模型元素最多只能被一個組合端所擁有，組合與被組合端的生命期是一致的，即如果組合端被破壞，被組合端的模型元素也會隨之破壞，從實現(xiàn)的意義上來看，組合端為它所包含的模型元素分配內(nèi)存并負責(zé)回收。對于shareable aggregate，顧名思義，一個模型元素可以被多個組合端共享擁有，當(dāng)聚合端被刪除時，有可能它包含的部分依然存在。Instance包在元數(shù)據(jù)進行交換時，有時候

26、也需要附帶一些實例數(shù)據(jù)（即M0層的數(shù)據(jù)）。Instance包就是用來描述實例數(shù)據(jù)的構(gòu)成規(guī)則，如附錄中圖A-6所示。在CWM中，每個Instance類對應(yīng)一個具體的Classifier，用來定義該Instance的靜態(tài)和動態(tài)特性。Instance有兩種類型：要么是簡單數(shù)據(jù)值（如一整數(shù)值或字符串值等），要么是對象。對象中擁有一些Slot（槽），每個slot對應(yīng)一個靜態(tài)特性，如果某個靜態(tài)特性本身的類型又是一個Classifier，則該對象包含另一個Classifier的對象，后者本身又擁有自己的Slot。如此遞歸下去，直到所有Slot值都是簡單的數(shù)據(jù)類型為止。3.1.2 Foundation層Fou

27、ndation層元模型描述其它CWM包所共享的概念與結(jié)構(gòu)。Foundation層中主要有六個包：BusinessInformation, Expression, KeyandIndexs, Typemapping, DataType, SoftwareDeployment。BusinessInformation包BusinessInformation包描述了一些面向商業(yè)的信息，包括數(shù)據(jù)倉庫系統(tǒng)的責(zé)任方，責(zé)任方的聯(lián)系信息以及系統(tǒng)描述文檔等。這些商業(yè)信息雖然不可能是有關(guān)商業(yè)環(huán)境的完整表示，但包含了CWM設(shè)計組認為是為了完成數(shù)據(jù)倉庫元數(shù)據(jù)交換所必須攜帶的商業(yè)信息，如附錄中圖A-7所示。Busines

28、sInformation包只依賴OjbectModel中的Core包。該包主要定義了三個概念：ResponsibleParty， Document和 Description,它們都是Namespace的子類。Description表示通用的描述信息，這些信息與CWM元數(shù)據(jù)存放在一起。一般而言，Description描述了對相關(guān)元數(shù)據(jù)的幫助、指南信息或注釋，Description甚至還可以描述其它的Description。Document與Description非常類似，它們之間主要的區(qū)別在于Document不與元數(shù)據(jù)一起存放，而僅在元數(shù)據(jù)中指明Document的位置。存在這兩種方式的原因是為了

29、避免元數(shù)據(jù)交換被大且結(jié)構(gòu)復(fù)雜的文件所累，因為Document可能很大很復(fù)雜。Document可以以層次方式組織，即其中包含章，節(jié)，副標(biāo)題等。ResponsibleParty主要描述對元數(shù)據(jù)負責(zé)的人或部門，由于是Namespace的子類，所以它也可以形成層次樹的結(jié)構(gòu)，ResponsibleParty可以表示一個完整的組織機構(gòu)圖，允許每一個組織單元都直接和信息系統(tǒng)中一個特定方面綁定。ResponsibleParty與多個Contact相關(guān)聯(lián)。每個Contact信息代表該責(zé)任方的聯(lián)系信息，如Telephone，E-mail，Location，ResourceLocator，它們都是ModelElem

30、ent的子類，意義很直觀，此處不解釋。DataTypes包DataTypes包為建模者提供了自定義所需特殊數(shù)據(jù)類型的一些模型元素。該包只依賴于Core包。Core包中的DataType類描述了簡單原始的數(shù)據(jù)類型，而這個包中主要提供定義較復(fù)雜數(shù)據(jù)類型的功能，如：Struct，Union和Enumration，如附錄中圖A-8所示。Struct類型比較簡單，就是Classifier的一個子類，圖中沒有直接給出。Struct類型中的每個域?qū)?yīng)Classifier的一個StructureFeature。Enumration類型即枚舉類型，代表一些常量值的命名集合，由于這些值的數(shù)據(jù)類型一致，即整個Enu

31、meration的類型是單一的，所以可以把Enumration作為Datatype的子類，它包含的每個常量用EnumerationLiteral來表示，注意，常量還可以是某個固定的范圍，如47。TypeAlias也是DataType的子類，它主要是為Classifier提供重命名的能力。Union是較為復(fù)雜的數(shù)據(jù)類型，它可以被認為由一系列簡單、可選的結(jié)構(gòu)類型Union Member組成，但在同一時間只允許一種Union Member代表Union被使用。Union有兩種類型，分別是：Discriminated Union和Undiscriminated Union。Discriminated

32、Union帶有一個Discriminator的屬性，它可以用來指明當(dāng)前使用的是哪一種Union Member，可以通過UnionDiscriminator關(guān)聯(lián)找到這個Discriminator。而Undiscriminated Union則沒有Discriminator屬性，所以當(dāng)Union表示為Undiscriminated Union時，UnionDiscriminator關(guān)聯(lián)的Discriminator端的多樣性為零。圖中并沒有畫出所有Union和它所包含的Union Member之間的關(guān)聯(lián)，直接通過繼承父類之間的ClassifierFeature關(guān)聯(lián)來表示這些意義。另外，QueryEx

33、pression（查詢表達式）是PorcedureExpression的子類，描述要做的查詢操作，但不包括具體怎么做，其實例中所包含的查詢聲明與具體語言無關(guān)，把QureyExpression放在此包的目的是因為表達式的返回值也可能是一種復(fù)雜的數(shù)據(jù)類型。Expression包Expression包描述了表達式的樹型產(chǎn)生規(guī)則，實際應(yīng)用可以據(jù)此追蹤數(shù)值的來源。Expression包也只依賴于Core包。從附錄圖A-9中可以看到，一棵表達式樹的所有節(jié)點都從ExpressionNode派生，表達式可以看成是一些ExpressionNode的子類的實例按層次的方式組織在一起的集合。ExpressionNo

34、de派生自Element，它有三種子類型，分別是：ElementNode, ConstantNode, 和 FeatureNode。FeatureNode描述了常規(guī)特性，如屬性或操作，當(dāng)是操作的情況下，F(xiàn)eatureNode通過與ExpressionNode之間的OperationArgument關(guān)聯(lián)描述操作的參數(shù)，參數(shù)可能是常量，用ConstantNode表示，也可能又是某種FeatureNode，如此遞歸下去，如果FeatureNode的參數(shù)為空，則表明這個FeatureNode是一個屬性或一個無參操作。參數(shù)還有可能是ElementNode，ElementNode表示那些不能用Featur

35、eNode表示的模型元素。ExpressionNode與Classifier之間的關(guān)聯(lián)表明這個ExpressionNode的具體類型，意義同core中描述，該這個關(guān)聯(lián)是可選的，只有在需要返回值的ExpressionNode節(jié)點（如等號操作的FeatureNode）時才需要。ExpressionNode中的Expression屬性給出表達式的文字表述。這個包中所描述的表達式與Core中的Expression類有所不同，ExpressionNode是一種白盒表達式，它不但給出了表達式的文本內(nèi)容，還定義了表達式的語義，Expression類是一種“黑盒”表達式，它只包含了表達式的文本內(nèi)容以及交換和記

36、錄這種表達式所用的語言，而對這種表達式的理解，則留給開發(fā)商去考慮。KeysandIndexes包由于在許多的數(shù)據(jù)源中都存在關(guān)鍵字和索引的概念，所以將這個包放置在Foundation層中。該包中的許多內(nèi)容放到關(guān)系數(shù)據(jù)庫中將會更好理解，見附錄中圖A-10，這個包只依賴于core包。圍繞Keys有兩個重要的類，分別是UniqueKey和KeyRelation。UniqueKey能唯一標(biāo)識實例的身份，如同關(guān)系數(shù)據(jù)中的主關(guān)鍵字。KeyRelation的概念就象關(guān)系數(shù)據(jù)中的外鍵一樣，它包含在一個實例中，但是可以標(biāo)識與該實例相關(guān)的別的實例的身份。UniqueKey和KeyRelation都與Structur

37、eFeature相關(guān)聯(lián)，標(biāo)明哪些靜態(tài)特性與它們相關(guān)。注意這里UniqueKey和KeyRelation都是ModelElement的子類，而不是Classifier的子類，原因是UniqueKey和KeyRelation可以被認為是相關(guān)StructureFeature所擔(dān)當(dāng)?shù)慕巧?，不需要用Classifier來描述UniqueKey和KeyRelation的內(nèi)部結(jié)構(gòu)。而且，在Core中已經(jīng)規(guī)定，一個Feature最多只屬于一個Classifier。如果將UniqueKey和KeyRelation都建模為Classifier，StructureFeature就會同時屬于它的Class又屬于它所參

38、與的關(guān)鍵字。Index對應(yīng)通常意義的索引，指存放著元素實際位置的一個列表，它的序列并不代表元素的物理順序，當(dāng)查詢與索引的結(jié)構(gòu)相匹配時，索引能加快檢索的速度。Index與被加索引的class之間的關(guān)系是span,而不是擁有的關(guān)系，這樣允許用一個并不屬于這個Class的Index來span它。當(dāng)然在實際情況中，被span的Class一般也是這個index的擁有者。IndexedFeature用來將Index連接到具體組成這個Index的StructureFeature上，另外，一個StructureFeature可以參與多個Index。SoftwareDeployment包SoftwareDepl

39、oyment包描述了軟硬件在數(shù)據(jù)倉庫的配置狀況。該包依賴于三個包：Core包，BusinessInformation包，TypeMapping包。先看附錄中圖A-11,SoftwareSystem是Subsystem的子類，代表軟件的一個可安裝單元。一個SoftwareSystem可能會引用一個或多個的TypeSystem，TypeSystem定義了SoftwareSystem支持的數(shù)據(jù)類型，具體在TypeMappings包中描述。一個SoftwareSystem由多個Component（Component描述的軟件系統(tǒng)中的靜態(tài)單位）組成，并且還可以導(dǎo)入其它SoftwareSystem的Com

40、ponent。DeployedSoftwareSystem類表示在一個機器上實際安裝的軟件包。類似地， DeployedComponent表示安裝了的Component。一個SoftwareSystem可以有多個配置方案，組成SoftwareSystem的每個Component也可能有多個配置方案。每個DeployedComponent與配置了它的Machine相關(guān)聯(lián)，而Machine又放置在具體的Site中，Site代表了一個地理位置，它是Location（在Business Information包中描述）的子類，可以以任何粒度記錄，如一個國家，一座建筑物，或是建筑物里的一間房間。很自然，

41、一個Site很可能屬于別的Site也可能包括別的Site。再看圖A-12,DataManager代表訪問數(shù)據(jù)庫的軟件組件，如數(shù)據(jù)庫管理系統(tǒng)或文件系統(tǒng)等，它可能與一個或多個表模式、關(guān)系目錄、文件或其它數(shù)據(jù)容器的數(shù)據(jù)包相關(guān)聯(lián)。實際上，Resource層中描述的每種數(shù)據(jù)源都會包含一個Package的子類，它們也繼承了Pachage與DataManager之間的關(guān)聯(lián)，DataProvider描述訪問DataManager所管理的數(shù)據(jù)庫的客戶端。例如：ODBC或JDBC客戶端。一個DataProvider可能含有多個ProviderConnection，指明多個相同或不同r的數(shù)據(jù)庫連接。DataProv

42、ider還可以使用別名來訪問數(shù)據(jù)庫，如果別名與DataManager管理的數(shù)據(jù)庫的實際名字不同，可以使用PackageUsage來記錄這個別名。PackageUsage是Dependency的子類，表示一個ProviderConnection所使用的別名依賴于具體的數(shù)據(jù)庫。Typemapping包Typemapping包定義了類型系統(tǒng)的概念,類型系統(tǒng)包含一系列數(shù)據(jù)類型的集合以及不同類型系統(tǒng)之間的數(shù)據(jù)類型映射，定義這個包的主要目的是為了在元數(shù)據(jù)交換時雙方的數(shù)據(jù)類型能夠兼容，該包只依賴于Core包。如附錄圖中A-13所示，該包主要有兩個類：TypeSystem和TypeMapping。TypeSy

43、stem描述一個類型系統(tǒng)中包含的數(shù)據(jù)類型，TypeMapping描述了類型映射，即一個TypeSystem的數(shù)據(jù)類型（源類型）如何映射到其它TypeSystem中的數(shù)據(jù)類型（目標(biāo)類型）。每個類型系統(tǒng)都包含自己的數(shù)據(jù)類型和類型映射，所以TypeMapping和Classifier以及TypeMapping和TypeSystem之間的關(guān)聯(lián)都是ElementOwnership。TypeMapping所屬的TypeSypstem是映射源類型所屬的TypeSystem。盡管在不同環(huán)境中數(shù)據(jù)的傳輸和映射由Transformation包來完成，但是可以用TypeMapping指明某種映射是否合法或是最佳的，

44、如果兩個數(shù)據(jù)類型間的映射不合法，則只能由Transformation包來處理。TypeMapping類中的isBestMatch屬性指出當(dāng)存在多種映射方式時這種映射是否是最佳的。3.3.3 Resource層這一層的包主要描述了基于CWM的元數(shù)據(jù)交換中的各種數(shù)據(jù)資源。有面向?qū)ο髷?shù)據(jù)源，關(guān)系數(shù)據(jù)源，層次數(shù)據(jù)源，多維數(shù)據(jù)源和XML數(shù)據(jù)源，在這里只敘述Relation包和MultiDimension包。Relation包Relation包描述了訪問關(guān)系數(shù)據(jù)所涉及的方方面面；第一部分描述關(guān)系數(shù)據(jù)庫的總體結(jié)構(gòu)。第二部分描述表、列和數(shù)據(jù)類型。第三部分描述了結(jié)構(gòu)類型與擴展，第四部分描述關(guān)鍵字，第五部分描述索

45、引，第六部分描述觸發(fā)器，第七部分描述存儲過程，第八部分描述了實例。以下分別來解釋各個部分。Relaiton包依賴于Behavioral包，Core包，Instance包，DataType包和KeysIndexes包。附錄中圖A-14中描述了關(guān)系數(shù)據(jù)庫的總體結(jié)構(gòu)，DataManager代表可以訪問數(shù)據(jù)的軟件組件，在此表示DBMS。Catalog（目錄）表示DataManger管理下的數(shù)據(jù)庫，一個Catalog下可以包含多個Schema（表模式），Schema又可以包含多個Trigger（觸發(fā)器），NamedColumnSet（命名了的列集合，如表或視圖），Procedure（存儲過程），SQLI

46、ndex（關(guān)系數(shù)據(jù)表中的索引），它們與Schema的關(guān)聯(lián)都是ElementOwnership，這個關(guān)聯(lián)是從Namespace和ModelElement之間的關(guān)聯(lián)繼承下來的。由于對關(guān)系數(shù)據(jù)模式大家都比較熟悉，這里就不再詳述圖中的每個類與關(guān)聯(lián)。圖A-15描述了表、列和數(shù)據(jù)類型。Column類表示關(guān)系中的列，多個Column組成一個ColumnSet，ColumnSet有兩個子類：QueryColumnSet和NamedColumnSet。QueryColumnSet表示查詢的結(jié)果集合。NamedColumnSet有兩個子類：Table和View，Table中的isTemporary屬性表明表是全局

47、表還是局部表，View中的isReadOnly屬性表明如果視圖更新，相應(yīng)的表是否需要更新。與Column關(guān)聯(lián)的還有CheckConstraint，它將約束列的取值范圍，很明顯，CheckConstraint是Constraint的子類，其中的deferrability屬性表明當(dāng)有多用戶更新時約束施加的時機。每個Column都有使用的數(shù)據(jù)類型，這通過抽象類SQLDataType表示，SQLSimpleType和SQLDistinctType是SQLDataType的兩個子類，前者表示列所使用的簡單數(shù)據(jù)類型，如integer，varchar等，后者表示某些DBMS使用的一些額外數(shù)據(jù)類型，它們從簡單

48、數(shù)據(jù)類型中定義得來。圖A-16描述了結(jié)構(gòu)類型與擴展。為了方便理解，CWM Specfication在解釋該圖時舉了大量的例子。圖中只有一個新的類型：SQLStructuredType，它是Class和DataType的子類，另外兩個類是在圖A-15中已經(jīng)定義了的Column，NameColumnSet。SQLStructuredType就象C語言中定義的Struct一樣，里面有多個域，只是這些域在這里都是Column，所以它與Column的關(guān)聯(lián)中有一條是ClassifierFerture關(guān)聯(lián)，表示該類型中包含的列。另外一條關(guān)聯(lián)是ColumnRefStructuredType，表示列又是某種復(fù)雜

49、類型SQLStructureType，這兩個關(guān)聯(lián)都可以在它們的父類中找到。另外，SQLStructuredType還與NameColumnSet相對應(yīng)，表示NameColumnSet的結(jié)構(gòu)可以從SQLStructuredType導(dǎo)出。圖A-17中描述了關(guān)鍵字，前面在Foundation層中的KeyandIndex包中已定義了UniqueKey和KeyRelationship類，該圖進一步將這兩個類擴展為關(guān)系數(shù)據(jù)庫中的PrimaryKey（主碼）和ForeignKey（外鍵）。UniqueConstraint是UniqueKey的子類，它定義了表中每一行唯一的條件，即可認為是侯選關(guān)鍵字，其中的一

50、個將被作為主鍵，所以PrimaryKey是UniqueConstraint的子類。其它的類和關(guān)聯(lián)在前面的內(nèi)容中已有描述，這里不贅述。圖A-18描述了索引，同關(guān)鍵字一樣，其中的一些類和關(guān)聯(lián)已在KeyandIndex包中定義，這里只描述與關(guān)系數(shù)據(jù)相關(guān)的內(nèi)容。在關(guān)系數(shù)據(jù)源中，Index為SQLIndex，該index所span的類是Table。這里，與SQLIndex相關(guān)聯(lián)的IndexedFeature是SQLIndexColumn，參與SQLIndexColumn的StructureFeature是Column。圖A-19描述觸發(fā)器（Trigger），觸發(fā)器和表之間有兩重關(guān)系：其一表示表發(fā)生變化時

51、激活觸發(fā)器，即觸發(fā)器監(jiān)控表，其二為觸發(fā)器對表進行操作，另外要注意的是，觸發(fā)器所屬的模式不一定是它所監(jiān)控的表所屬的模式。有關(guān)觸發(fā)器的內(nèi)容比較簡單，這里也不詳述。圖A-20描述了存儲過程（Procedure），Procedure擴展了Behavioral包的Method類并從屬于一個Schema，該Procedure所使用的參數(shù)是SQLParameter。圖A-21描述了關(guān)系實例的構(gòu)成規(guī)則。該包中的類和關(guān)聯(lián)主要繼承Instance包定義的類和關(guān)聯(lián)。關(guān)系中的每個Row（元組）包含了關(guān)系的所有列在該Row中的相應(yīng)取值。ColumnValue是DataValue的子類，Row是Object的子類，各種關(guān)

52、聯(lián)關(guān)系同Instance包。RowSet是Extent的子類，它表示元組的集合，一個元組集合包含多個元組。Multidimensional包Multidimensional包描述多維數(shù)據(jù)庫，其主要用于OLAP（聯(lián)機分析處理）工具分析數(shù)據(jù)。在多維數(shù)據(jù)庫中，OLAP的關(guān)鍵結(jié)構(gòu)如維度、層次等由多維數(shù)據(jù)庫內(nèi)部的數(shù)據(jù)結(jié)構(gòu)表示。與關(guān)系數(shù)據(jù)庫管理系統(tǒng)不同，多維數(shù)據(jù)庫在物理存儲上一般是私有的，相互之間沒有共同的標(biāo)準(zhǔn)，可以以多維數(shù)組的形式存放，也可以別的方式。但是，多維數(shù)據(jù)庫的邏輯表示有統(tǒng)一的標(biāo)準(zhǔn)，這個在OLAP包中會講到。多維數(shù)據(jù)庫為OLAP系統(tǒng)帶來的主要好處在于：n 它能提供快速的聚合時間和公式計算時間，以

53、及一致的查詢響應(yīng)時間，而不管查詢有多復(fù)雜。這主要歸功于有效的方格存儲技術(shù)和高度優(yōu)化的索引路徑。n 由于多維數(shù)據(jù)庫服務(wù)器直接支持和表示多維結(jié)構(gòu)，構(gòu)建多維數(shù)據(jù)庫對多維模式以及查詢的說明與使用也將相對簡單直觀。該包主要依賴于Core包和Instance包。如附錄中圖A-22所示，Schema是組成多維數(shù)據(jù)模型的所有元素的容器，意義與其在關(guān)系數(shù)據(jù)包中的Schema類似。Dimension表示多維數(shù)據(jù)庫中的一個物理維度，而OLAP包中定義的Dimension只是概念上的維度，它具體的物理實現(xiàn)可以是多維數(shù)據(jù)庫中的Dimension，也可以是關(guān)系表等。維度可以包含其它維度形成層次結(jié)構(gòu)。Dimensioned

54、Object表示Dimension的屬性，例如，按維度上卷的聚合函數(shù)，維度成員別名等。DimensionedObject也屬于Schema并被Dimension使用。MemberSet代表一個維度取值的子集，如地區(qū)維度中城市屬于美國的維度成員，它是Extent的子類，Member指維度的一個具體取值，MemberValue指維度取值中各個域的值（此處的域同關(guān)系表中的列），MemberSet，Member，MemberValue的含義與圖A-21部分描述的RowSet，Row，ColumnValue類似。3.3.4 Analysis層Analysis層提供了支持邏輯服務(wù)的元模型，這些服務(wù)將會被映

55、射到由Resource層的包所定義的數(shù)據(jù)存儲中去，服務(wù)包括支持ETL（抽取，轉(zhuǎn)換，加載）和數(shù)據(jù)跟蹤操作的Transformation包，以維度和立方體觀察數(shù)據(jù)倉庫的OLAP包，支持?jǐn)?shù)據(jù)挖掘的元模型包，信息可視化的Information Visualization包和定義商業(yè)術(shù)語的的Nomenclature包。為簡單起見，這里只討論Transformation包和OLAP包。Transformation包將數(shù)據(jù)從操作數(shù)據(jù)源中提取、加載、轉(zhuǎn)換到倉庫或集市中是數(shù)據(jù)倉庫非常重要的一個環(huán)節(jié)。提取、轉(zhuǎn)換、加載都可以都看成是轉(zhuǎn)換(Transformation)的一部分。轉(zhuǎn)換包主要是用來描述與轉(zhuǎn)換活動相關(guān)的元

56、數(shù)據(jù)，具體支持：1）將轉(zhuǎn)換與它的數(shù)據(jù)源和數(shù)據(jù)目標(biāo)聯(lián)系起來。2）“黑盒”與“白盒”轉(zhuǎn)換。在黑盒轉(zhuǎn)換中，只知道數(shù)據(jù)源與數(shù)據(jù)目標(biāo)通過轉(zhuǎn)換相關(guān)聯(lián)，但是并不知道如何將一個特定種類的數(shù)據(jù)源聯(lián)系到另一種特定種類的數(shù)據(jù)目標(biāo)。而在白盒轉(zhuǎn)換中，卻可以清楚地知道一種特定類型的數(shù)據(jù)源是如何通過某種特定的轉(zhuǎn)換與另一種類型的數(shù)據(jù)目標(biāo)相關(guān)聯(lián)。3）允許將轉(zhuǎn)換分成若干個邏輯部分。 轉(zhuǎn)換允許不同類型和粒度的數(shù)據(jù)作為它的數(shù)據(jù)源與數(shù)據(jù)目標(biāo)。例如，一個轉(zhuǎn)換中的源數(shù)據(jù)類型可以是XML schema，而目標(biāo)類型是關(guān)系表中的列；更典型的情況是，轉(zhuǎn)換的源類型可以是類和屬性而目標(biāo)類型可以是關(guān)系表和列，反之亦然。另外，可以使用現(xiàn)有的程序，查詢，或

57、規(guī)則執(zhí)行轉(zhuǎn)換過程。在元模型中，將使用transformation use將它們與具體的轉(zhuǎn)換過程相關(guān)聯(lián)，Operation是依賴的提供端，Transformation是依賴的客戶端。轉(zhuǎn)換包依賴于以下幾個包：Behavioral，Core，Expressions，SoftwareDeployment。轉(zhuǎn)換包描述了以下功能：1. 轉(zhuǎn)換與數(shù)據(jù)跟蹤。這些類與關(guān)聯(lián)處理轉(zhuǎn)換以及它們的數(shù)據(jù)源、目標(biāo)、約束和操作。2. 轉(zhuǎn)換分組與執(zhí)行。這些類與關(guān)聯(lián)處理將轉(zhuǎn)換分組成邏輯單元并定義它們的執(zhí)行順序。3. 特殊轉(zhuǎn)換。這些類與關(guān)聯(lián)用來定義數(shù)據(jù)倉庫中廣泛使用的“白盒”轉(zhuǎn)換。下面分別看看每個元模型圖。先看附錄中圖A-23, 轉(zhuǎn)

58、換可以被劃分為多個邏輯單元。在功能層上，它們被分組為transformation task，每個transformation task又包含一系列必須一起執(zhí)行和完成的transformation。在執(zhí)行層，使用模型元素Transformation step來協(xié)調(diào)transformation task的執(zhí)行，即每一個Transformation step代表單個transformation task的具體執(zhí)行。并且多個transformation step還組成transformation activity。在每個transformation activity中，transformation s

59、tep的執(zhí)行順序或者通過step precedence 或precedence constraint明確定義，或者通過data dependency隱含表示。每個transformation task 還可能對應(yīng)有其反向的Task，即原來的轉(zhuǎn)換源變成轉(zhuǎn)換目標(biāo)，原來的轉(zhuǎn)換目標(biāo)現(xiàn)在變成轉(zhuǎn)換源。DataObjectSet代表了一系列能被作為轉(zhuǎn)換數(shù)據(jù)源和數(shù)據(jù)目標(biāo)的數(shù)據(jù)對象。StepPrecedence是Dependency的子類，用來明確定義transformation step的執(zhí)行順序，它既可以獨立使用也可以與PrecedenceConstraint（constraint的子類）聯(lián)合使用。圖A-24主要描述了TransformationMap的組成，它是