CWM元模型研究及其在广发银行数据仓库中的应用

1、CWM元模型研究及其在广发银行数据仓库中的应用李珊珊一数据仓库的描述需求数据仓库是企业级信息管理的一项新兴技术。它的目的是为了将企业的大量历史数据按主题集成在一起，并以一种统一的模式供分析和知识挖掘使用。数据仓库中技术种类繁多，不象数据库系统那样单一，典型的数据仓库技术包括数据抽取技术、OLAP技术、数据挖掘技术等。构建一个数据仓库需要考虑到它的创建、管理、使用和维护等诸多方面，如创建过程中要考虑旧数据库系统的数据模型、数据集成的ETL (Extract, Tansfomation and Load) 规则、仓库中新数据模型的建立等，使用过程要考虑数据的物理模型和展现方式、对数据进行操作的各种

2、统计分析算法、数据挖掘规则等。对于这些应用需求，数据仓库建模应该具备描述它们的能力，无论是底层的数据源信息，还是高层的各种操作信息，方方面面都应尽量涉及到。经过分析研究，发现OMG组织的CWM具备了这种能力，它提供了描述数据源、数据目标、转换、分析、处理、操作等与建设和管理数据仓库相关的元数据基础框架（构成规则集）1，使不同厂商产品的元数据通信和共享有了一个切实可行的标准。在深入理解CWM的基础上，1.2节总结了CWM的内容框架和各个组成部分的依赖关系。二、 CWM的内容框架参考数据仓库的描述需求，课题中对CWM的内容体系进行了总体研究，深入分析了它的组成及结构23。CWM基本描述了数据仓库的

3、各个方面，包括基本类型信息、数据资源信息、数据分析信息、仓库管理信息等。当然，它不可能囊括数据仓库中的所有信息，随着数据仓库技术的不断进步，需要描述的新信息也越来越多，这些信息只能被包含进CWM的后续扩展规范中。OMG的CWM工作小组也在时刻关注数据仓库的最新发展动向。目前的CWM版本所包含的信息基本涉及了数据仓库领域的各个方面，虽然不是完全的但至少是描述仓库操作所需的最少信息。另外，对于其所描述的元数据，语义都是精确的、无歧义的。图1-1是CWM的内容结构图1，从图中可以看出，CWM的内容按包组织，每个包尽量涉及一个独立的领域，这样极大地方便了开发者的建模工作，因为在建模时只取所需的包即可。

4、并且，包的数目没有太大，结构更易于扩展，CWM目前的版本中包含了18个包和一个ObjectModel，CWM的这种特性也使得它易于理解。每个包都由一系列UML表示的类图组成。虽然这些包描述的领域不尽相同，但它们组织结构并不完全独立，事实上，它们之间有着紧密的依赖关系。在CWM的内容框架中，所有包按功能和抽象层次组织成四层，同层的包的功能角色类似，如第二层中的包描述的都是数据仓库的数据资源。每一层中的包都为同层或上层的包提供服务，如第三层包描述的操作都是基于第二层包描述的数据资源，层次越高描述的内容越抽象。在包的结构方面，或者上层包中的类和关联继承下层包中的类和关联，或者在上层的包直接使用下层包

5、中定义的类或关联，这样做既使整个元模型组织更精练，又使CWM在功能结构上十分清晰。图1-1 CWM的内容结构图如图1-1所示，最底层的是ObjectModel，分析CWM的继承图，会发现它是整个CWM的基础。ObjectModel实际是UML的一个子集， CWM最大程度地重用了UML中与描述数据仓库领域相关的一些模型元素1,7。CWM所有包的类与关联都是直接或间接地继承ObjectModel中的类与关联，这样，CWM可以看作是从ObjectModel生长出来的一棵大树，树的根部就是ObjectModel。ObjectModel以上的四个层次依次为：Foundation层、 Resource层、

6、 Analysis层、Management层。每个层次中的包都为高层（或同层）的包提供服务。Foundation层的元模型主要是代表上层CWM包共享的概念与结构，如表达式、索引、数据类型、软件配置信息等，虽然这些都是很基本的信息，但它们与ObjectModel中的元素又有所不同，因为这些模型元素专有于CWM领域，而ObjectModel中的元素则更具一般性和通用性。Foundation层中的包以字母顺序给出；Resource层中包含了OLTP系统与数据仓库所使用的各种数据资源,有关系的、层次的、多维的等等，这些数据源都要用到Foundation层的通用信息，如关系包中描述索引和关键字的类都是从

7、Foundation层的Keys and Indexs包中继承而来。此外，ObjectModel恰好是面向对象的数据源，因此，ObjectModel在整个CWM承担着两种角色，一方面作为整个CWM的基础，另一个方面又代表了面向对象数据源；Analysis层提供了数据仓库各种操作的元模型，包括OLAP、数据挖掘、转换等，它们会被映射到由Resource层的包所定义的数据存储中去。例如，Transformation元模型描述了数据仓库中的数据源到数据目标的转换，OLAP元模型允许存储在关系或多维数据引擎中的数据仓库以多维视图显示。Management层定义了操作任务及其调度信息（Warehouse

8、 Process包）并记录了数据仓库活动以及相关的统计信息（Warehouse Operation Package）。CWM的所有包中的类与关联都尽量利用了UML中的继承机制，复用已有的元素。并且，所有的基类都只出现在Object Model、Foundation 和Resource层中，在更高的层中（Aanlysis层和Management层），已经没有基类出现。这样做的主要目的是为了简化高层包中的类图，因为更高层中的类一般都要比低层多。这种组织方式也使得类图更易于理解，因为类的总数减少了。图1-2是分析得出的包依赖关系图，箭头指向代表依赖方向，即箭头始发处的包中的类和关联继承箭头指向的包中

9、的类和关联。ManagementAnalysisResourceFoundationObjectModel图1-2 CWM各包依赖关系图CWM中的每个包都由一组类图和相应的约束组成，约束使用OCL来描述。所有的类都只包含静态属性，没有包含任何操作属性，CWM把操作信息留给工具自定义，从而为CWM开发商保留更大的灵活性。另外，类之间的关联使用引用方式表达。考虑到工作量的问题，在1.1节将以一个独立完整的数据仓库过程为主线详细分析部分包的内容。三、CWM各层内容剖析考虑到工作量的问题，本文将不对CWM中的所有包进行分析，而是依据实际数据仓库开发的经验只在四个层次中选一部分进行研究和实现，它们是描述

10、一个独立完整的数据仓库过程所需要的最少建模元素。分别挑选了Management层的Warehouse Process包和Warehouse Operation包、Analysis层的Transformation包和OLAP包、Resource层的Relation包和Multidimensional包以及Foundation层中的所有包。在分析这些包之前，先深入剖析ObjectModel。ObjectModel是整个CWM的基础，它为创建和描述CWM的其它包提供了基本构架。分析过程需要对照CWM规范中的类图，由于CWM中的图繁多，因此在正文中只附Core包的图辅助讲解。另外，分析由下往上按层次展

11、开。3.1.1 Object ModelObjectModel是UML的一个子集，它只含有UML中与描述数据仓库有关的部分。ObjectModel又包括四个包：Core包 、Behavioral包、Relationship包和Instance包。Core包是核心，其余三个包都依赖且只依赖于Core包。除此之外，ObjectModel中再没有其他依赖关系。 Core包Core 中总共有三个图，分别见图1-3,1-4,1-5。图1-3 Core包类图1从图中可以看出，Element类位于最顶层，事实上，它也是CWM中所有类的祖先，如果把CWM想成一个树状的类继承结构，那么Element就是这棵树的

12、根。Element中没有任何属性，只是一个抽象元类，包含表达语义信息的模型元素和用于表示的表达元素。ModelElement是Element的子类，前者只描述模型元素。模型元素与表达元素不同，表达元素是以表现模型为目的的图形元素，它们不含有语义信息，而在CWM中，绝大多数类都是带有语义信息的模型元素。ModeElement包含了一个最基本且最重要的属性Name。除了少数几个类，如Multiplicity，几乎所有CWM类都是直接或间接地继承ModelElement。并且ModelElement还作为这些类相互关联的连接点，绝大多数提供通用服务的类，如Dependency，Constraint等

13、都直接关联到ModelElement表示可以为所有的模型元素提供这种服务。 Core包中提供通用服务的类主要有以下这些：n Constraint：一种扩展机制，用于描述对模型元素的行为约束。n Dependency：定义了模型元素之间的依赖关系，与Dependency相关联的两个模型元素中，一个作为依赖方（client），另一个作为被依赖方（supplier）。n TaggedValue：一种名字值对的形式，表示与具体应用相关的属性，TaggedValue是一种扩展机制。任何模型元素或表达元素都可以带有零或多个名字值对24。n Stereotype：该类也为CWM提供了一种扩展机制。在实际建模

14、过程中，开发人员可能想要传递某种语义差别，但是供使用的可能只有一种建模元素，为了表示这种差别，更精确地反映该模型元素所表达的语义，就可以用Stereotype24。比如说类可以分为实体类，边界类和控制类，而在用UML建模时就只能用Class统一表示，为了在必要的时候加以区分，就可以使用Stereotype。再从ModelElement沿着继承链往下看，Namespace的含义就象通常所说的容器，它的目的是为了按某种逻辑意义将元素分组。组包含一系列的ModelElement，且它与ModelElement的关系是强聚合关联。除了顶级Namespace，几乎所有的ModelElement都会属于且

15、只能属于一个Namespace。同一Namespace中ModelElement的命名是唯一的，命名规则一般为“Namespace名：ModelElement名”。因此，使用Namespace还可以避免在整个模型范围内的命名冲突。Classifier和Package都是Namespace的子类，可以这样理解这两个子类的意义：Classifier的作用类似于C+中的.h文件，而Package的作用类似于C+中的.cpp文件，一个描述静态结构，而另一个则描述具体实现。Classifier有多种具体的形式，包括Class，DataType等，Classifier常用作类型（Type）。作为一个Nam

16、espace，一个Classifier还可以嵌套定义其它的Classifier。Classifier也可能包含一系列Feature，比如说Attribute，Operation等。Class是一种最常见的Classifier，其实Classifier的每种子类都可按Class的概念理解，只是分别在内容和使用上有了某些特殊限制。DataType既包含原始的数据类型（如整型，字符串等），又包含可定义的枚举类型。一般来说，DataType常被用来作为属性或参数的类型。Package也提供了一个分组机制，虽然父类Namespace已经定义了“包含“的语义，但 Package还可以表示组织这些元素的依据

17、和目的。一个包可以通过“导入（import）”访问其它包中的模型元素。当包导入了其他模型元素后，包的范围就被扩充了，加入了被导入的模型元素。Subsystem的直接父类（即多重继承）有两个：分别是Package和Classifier。Subsystem主要表示物理系统中的行为单元，描述一组模型元素的具体行为特征。Subsystem可以向外提供接口，这些接口描述了它与系统其他部分的关系以及使用环境。Model是从不同视图的角度对系统进行的完整抽象。说它是完整的，是因为它从给定视图全面地描述了系统和实体。一个物理系统可以定义多个Model，如分析模型，设计模型，实现模型。Feature也是Mode

18、lElement的子类，它表示一个具体特性，既可以是静态特性（StructureFeature）也可以是动态特性（BehavioralFeature），静态特性的一个例子就是属性（Attribute），动态特性的一个例子是操作（Operation），它们被封装在一个Classifier中。有关动态特性的模型元素在Behavior包中描述，Core中只描述了与静态特性有关的模型元素。StructureFeature的类型由Classifier确定，既可以是一种简单的数据类型，也可以是一个复杂类型，如Class等等。图1-4 Core包类图2在图1-4中，列出了一些CWM中的支持类，分别是Expr

19、ession，Multiplicity和MultiplicityRange。Expression即通常所说的表达式，它有两种子类型：BooleanExpression和ProcedureExpression。BooleanExpression描述布尔表达式的求值，而ProcedureExpression描述一个过程表达式的计算，其计算结果可能会影响当前系统的运行状态。Multiplicity表示允许的候选值范围，也就是通常在关联端的使用的取值个数约束。由于取值空间可能不连续，所以一个Multiplicity又可能包含多个MultiplicityRange，一个MultiplicityRange

20、定义一个整数范围，下限必须是非负数，上限没有限制，可以是无穷大。图1-5 Core包类图1图1-5描述了CWM的扩展机制，共有包含三个元素：TaggledValue，Stereotype，和Constraint。上面已经提到过，TaggledValue允许信息以名字值对的形式附加到任何模型元素，具体的含义已经超出了CWM的范畴，在交换元数据时，交换双方必须要有对名字值对的统一理解才能交换这些名字值对。Constraint和Stereotype上面已给出，这里不在赘述。Behavioral包Behavioral包中主要描述了Classifier的行为特性，如附录中图A-4所示。在该包中，最为重要

21、的一个类就是BehavioralFeature， BehavioralFeature描述模型元素的动态特性。从日常的观点来看，BehavioralFeature代表程序逻辑中的可执行单元，因此，它包含一系列的输入输出参数以及返回值。BehavioralFeature的参数用Parameter类来表示。Method和Operation都是BehavioralFeature的子类，Operation描述某种转换或查询，它有自己的名称和参数列表，是程序逻辑的可直接调用的单元，而Method则表示Operation的实现，它指定了完成Operation的算法规则和过程描述，一个Operation可以有

22、多个Method实现，每个实现可能使用不同的程序语言，不同的算法。CallAction描述对一个Operation的具体调用，它还指定此次调用的实参，实参用Argument类表示，它与Parameter不同，Parameter主要是指形参。Interface是Classifier的子类，它是一系列Operation的集合，定义了能给外界提供的服务，只包含服务名而不包含实现。Event类描述一次值得注意的事件，它也包含多个Parameter，如鼠标点击事件中的参数包含点击处的坐标等等。但是，在CWM中并没有描述当事件发生以后将会采取什么行动，这个将留给具体的应用去处理。Relationship包

23、Relationship包比较简单,主要描述对象（即元数据）之间如何关联，关联有两类：Generalization和Association，如附录中的A-5所示。Generalization描述较为通用的classifier和较为特殊的Classifier之间的关联，就如同UML里的继承，这种关联把类组织成一种层次的结构。很明显，与Generalization相关联的两个Classifier所充当的角色一个叫child，代表较为特殊的一方，另一个是parent，代表较为通用的一方。在CWM中，允许出现多重继承的形式，即一个child可以对应多个parent，说明作为child的Classifi

24、er同时含有多个作为Parent的Classifier的特性。Association即常说的关联。一个Association可以有多个AssociationEnd（至少两个）两个的话被称为binary，大于两个的被称为n-ary，Association与AssociationEnd之间是通过ClassifierFeature关联起来的。有三种类型的Association：ordinary association（普通关联）, composite aggregate（组合式聚合关联）和shareable aggregate（共享式聚合关联）。ordinary association是通常意义上的

25、关联，任何有联系的模型元素之间都可以由这种关联建立联系。composite aggregate和shareable aggregate只有在二元的Association下才有意义。在composite aggregate中，被包含的模型元素最多只能被一个组合端所拥有，组合与被组合端的生命期是一致的，即如果组合端被破坏，被组合端的模型元素也会随之破坏，从实现的意义上来看，组合端为它所包含的模型元素分配内存并负责回收。对于shareable aggregate，顾名思义，一个模型元素可以被多个组合端共享拥有，当聚合端被删除时，有可能它包含的部分依然存在。Instance包在元数据进行交换时，有时候

26、也需要附带一些实例数据（即M0层的数据）。Instance包就是用来描述实例数据的构成规则，如附录中图A-6所示。在CWM中，每个Instance类对应一个具体的Classifier，用来定义该Instance的静态和动态特性。Instance有两种类型：要么是简单数据值（如一整数值或字符串值等），要么是对象。对象中拥有一些Slot（槽），每个slot对应一个静态特性，如果某个静态特性本身的类型又是一个Classifier，则该对象包含另一个Classifier的对象，后者本身又拥有自己的Slot。如此递归下去，直到所有Slot值都是简单的数据类型为止。3.1.2 Foundation层Fou

27、ndation层元模型描述其它CWM包所共享的概念与结构。Foundation层中主要有六个包：BusinessInformation, Expression, KeyandIndexs, Typemapping, DataType, SoftwareDeployment。BusinessInformation包BusinessInformation包描述了一些面向商业的信息，包括数据仓库系统的责任方，责任方的联系信息以及系统描述文档等。这些商业信息虽然不可能是有关商业环境的完整表示，但包含了CWM设计组认为是为了完成数据仓库元数据交换所必须携带的商业信息，如附录中图A-7所示。Busines

28、sInformation包只依赖OjbectModel中的Core包。该包主要定义了三个概念：ResponsibleParty， Document和 Description,它们都是Namespace的子类。Description表示通用的描述信息，这些信息与CWM元数据存放在一起。一般而言，Description描述了对相关元数据的帮助、指南信息或注释，Description甚至还可以描述其它的Description。Document与Description非常类似，它们之间主要的区别在于Document不与元数据一起存放，而仅在元数据中指明Document的位置。存在这两种方式的原因是为了

29、避免元数据交换被大且结构复杂的文件所累，因为Document可能很大很复杂。Document可以以层次方式组织，即其中包含章，节，副标题等。ResponsibleParty主要描述对元数据负责的人或部门，由于是Namespace的子类，所以它也可以形成层次树的结构，ResponsibleParty可以表示一个完整的组织机构图，允许每一个组织单元都直接和信息系统中一个特定方面绑定。ResponsibleParty与多个Contact相关联。每个Contact信息代表该责任方的联系信息，如Telephone，E-mail，Location，ResourceLocator，它们都是ModelElem

30、ent的子类，意义很直观，此处不解释。DataTypes包DataTypes包为建模者提供了自定义所需特殊数据类型的一些模型元素。该包只依赖于Core包。Core包中的DataType类描述了简单原始的数据类型，而这个包中主要提供定义较复杂数据类型的功能，如：Struct，Union和Enumration，如附录中图A-8所示。Struct类型比较简单，就是Classifier的一个子类，图中没有直接给出。Struct类型中的每个域对应Classifier的一个StructureFeature。Enumration类型即枚举类型，代表一些常量值的命名集合，由于这些值的数据类型一致，即整个Enu

31、meration的类型是单一的，所以可以把Enumration作为Datatype的子类，它包含的每个常量用EnumerationLiteral来表示，注意，常量还可以是某个固定的范围，如47。TypeAlias也是DataType的子类，它主要是为Classifier提供重命名的能力。Union是较为复杂的数据类型，它可以被认为由一系列简单、可选的结构类型Union Member组成，但在同一时间只允许一种Union Member代表Union被使用。Union有两种类型，分别是：Discriminated Union和Undiscriminated Union。Discriminated

32、Union带有一个Discriminator的属性，它可以用来指明当前使用的是哪一种Union Member，可以通过UnionDiscriminator关联找到这个Discriminator。而Undiscriminated Union则没有Discriminator属性，所以当Union表示为Undiscriminated Union时，UnionDiscriminator关联的Discriminator端的多样性为零。图中并没有画出所有Union和它所包含的Union Member之间的关联，直接通过继承父类之间的ClassifierFeature关联来表示这些意义。另外，QueryEx

33、pression（查询表达式）是PorcedureExpression的子类，描述要做的查询操作，但不包括具体怎么做，其实例中所包含的查询声明与具体语言无关，把QureyExpression放在此包的目的是因为表达式的返回值也可能是一种复杂的数据类型。Expression包Expression包描述了表达式的树型产生规则，实际应用可以据此追踪数值的来源。Expression包也只依赖于Core包。从附录图A-9中可以看到，一棵表达式树的所有节点都从ExpressionNode派生，表达式可以看成是一些ExpressionNode的子类的实例按层次的方式组织在一起的集合。ExpressionNo

34、de派生自Element，它有三种子类型，分别是：ElementNode, ConstantNode, 和 FeatureNode。FeatureNode描述了常规特性，如属性或操作，当是操作的情况下，FeatureNode通过与ExpressionNode之间的OperationArgument关联描述操作的参数，参数可能是常量，用ConstantNode表示，也可能又是某种FeatureNode，如此递归下去，如果FeatureNode的参数为空，则表明这个FeatureNode是一个属性或一个无参操作。参数还有可能是ElementNode，ElementNode表示那些不能用Featur

35、eNode表示的模型元素。ExpressionNode与Classifier之间的关联表明这个ExpressionNode的具体类型，意义同core中描述，该这个关联是可选的，只有在需要返回值的ExpressionNode节点（如等号操作的FeatureNode）时才需要。ExpressionNode中的Expression属性给出表达式的文字表述。这个包中所描述的表达式与Core中的Expression类有所不同，ExpressionNode是一种白盒表达式，它不但给出了表达式的文本内容，还定义了表达式的语义，Expression类是一种“黑盒”表达式，它只包含了表达式的文本内容以及交换和记

36、录这种表达式所用的语言，而对这种表达式的理解，则留给开发商去考虑。KeysandIndexes包由于在许多的数据源中都存在关键字和索引的概念，所以将这个包放置在Foundation层中。该包中的许多内容放到关系数据库中将会更好理解，见附录中图A-10，这个包只依赖于core包。围绕Keys有两个重要的类，分别是UniqueKey和KeyRelation。UniqueKey能唯一标识实例的身份，如同关系数据中的主关键字。KeyRelation的概念就象关系数据中的外键一样，它包含在一个实例中，但是可以标识与该实例相关的别的实例的身份。UniqueKey和KeyRelation都与Structur

37、eFeature相关联，标明哪些静态特性与它们相关。注意这里UniqueKey和KeyRelation都是ModelElement的子类，而不是Classifier的子类，原因是UniqueKey和KeyRelation可以被认为是相关StructureFeature所担当的角色，不需要用Classifier来描述UniqueKey和KeyRelation的内部结构。而且，在Core中已经规定，一个Feature最多只属于一个Classifier。如果将UniqueKey和KeyRelation都建模为Classifier，StructureFeature就会同时属于它的Class又属于它所参

38、与的关键字。Index对应通常意义的索引，指存放着元素实际位置的一个列表，它的序列并不代表元素的物理顺序，当查询与索引的结构相匹配时，索引能加快检索的速度。Index与被加索引的class之间的关系是span,而不是拥有的关系，这样允许用一个并不属于这个Class的Index来span它。当然在实际情况中，被span的Class一般也是这个index的拥有者。IndexedFeature用来将Index连接到具体组成这个Index的StructureFeature上，另外，一个StructureFeature可以参与多个Index。SoftwareDeployment包SoftwareDepl

39、oyment包描述了软硬件在数据仓库的配置状况。该包依赖于三个包：Core包，BusinessInformation包，TypeMapping包。先看附录中图A-11,SoftwareSystem是Subsystem的子类，代表软件的一个可安装单元。一个SoftwareSystem可能会引用一个或多个的TypeSystem，TypeSystem定义了SoftwareSystem支持的数据类型，具体在TypeMappings包中描述。一个SoftwareSystem由多个Component（Component描述的软件系统中的静态单位）组成，并且还可以导入其它SoftwareSystem的Com

40、ponent。DeployedSoftwareSystem类表示在一个机器上实际安装的软件包。类似地， DeployedComponent表示安装了的Component。一个SoftwareSystem可以有多个配置方案，组成SoftwareSystem的每个Component也可能有多个配置方案。每个DeployedComponent与配置了它的Machine相关联，而Machine又放置在具体的Site中，Site代表了一个地理位置，它是Location（在Business Information包中描述）的子类，可以以任何粒度记录，如一个国家，一座建筑物，或是建筑物里的一间房间。很自然，

41、一个Site很可能属于别的Site也可能包括别的Site。再看图A-12,DataManager代表访问数据库的软件组件，如数据库管理系统或文件系统等，它可能与一个或多个表模式、关系目录、文件或其它数据容器的数据包相关联。实际上，Resource层中描述的每种数据源都会包含一个Package的子类，它们也继承了Pachage与DataManager之间的关联，DataProvider描述访问DataManager所管理的数据库的客户端。例如：ODBC或JDBC客户端。一个DataProvider可能含有多个ProviderConnection，指明多个相同或不同r的数据库连接。DataProv

42、ider还可以使用别名来访问数据库，如果别名与DataManager管理的数据库的实际名字不同，可以使用PackageUsage来记录这个别名。PackageUsage是Dependency的子类，表示一个ProviderConnection所使用的别名依赖于具体的数据库。Typemapping包Typemapping包定义了类型系统的概念,类型系统包含一系列数据类型的集合以及不同类型系统之间的数据类型映射，定义这个包的主要目的是为了在元数据交换时双方的数据类型能够兼容，该包只依赖于Core包。如附录图中A-13所示，该包主要有两个类：TypeSystem和TypeMapping。TypeSy

43、stem描述一个类型系统中包含的数据类型，TypeMapping描述了类型映射，即一个TypeSystem的数据类型（源类型）如何映射到其它TypeSystem中的数据类型（目标类型）。每个类型系统都包含自己的数据类型和类型映射，所以TypeMapping和Classifier以及TypeMapping和TypeSystem之间的关联都是ElementOwnership。TypeMapping所属的TypeSypstem是映射源类型所属的TypeSystem。尽管在不同环境中数据的传输和映射由Transformation包来完成，但是可以用TypeMapping指明某种映射是否合法或是最佳的，

44、如果两个数据类型间的映射不合法，则只能由Transformation包来处理。TypeMapping类中的isBestMatch属性指出当存在多种映射方式时这种映射是否是最佳的。3.3.3 Resource层这一层的包主要描述了基于CWM的元数据交换中的各种数据资源。有面向对象数据源，关系数据源，层次数据源，多维数据源和XML数据源，在这里只叙述Relation包和MultiDimension包。Relation包Relation包描述了访问关系数据所涉及的方方面面；第一部分描述关系数据库的总体结构。第二部分描述表、列和数据类型。第三部分描述了结构类型与扩展，第四部分描述关键字，第五部分描述索

45、引，第六部分描述触发器，第七部分描述存储过程，第八部分描述了实例。以下分别来解释各个部分。Relaiton包依赖于Behavioral包，Core包，Instance包，DataType包和KeysIndexes包。附录中图A-14中描述了关系数据库的总体结构，DataManager代表可以访问数据的软件组件，在此表示DBMS。Catalog（目录）表示DataManger管理下的数据库，一个Catalog下可以包含多个Schema（表模式），Schema又可以包含多个Trigger（触发器），NamedColumnSet（命名了的列集合，如表或视图），Procedure（存储过程），SQLI

46、ndex（关系数据表中的索引），它们与Schema的关联都是ElementOwnership，这个关联是从Namespace和ModelElement之间的关联继承下来的。由于对关系数据模式大家都比较熟悉，这里就不再详述图中的每个类与关联。图A-15描述了表、列和数据类型。Column类表示关系中的列，多个Column组成一个ColumnSet，ColumnSet有两个子类：QueryColumnSet和NamedColumnSet。QueryColumnSet表示查询的结果集合。NamedColumnSet有两个子类：Table和View，Table中的isTemporary属性表明表是全局

47、表还是局部表，View中的isReadOnly属性表明如果视图更新，相应的表是否需要更新。与Column关联的还有CheckConstraint，它将约束列的取值范围，很明显，CheckConstraint是Constraint的子类，其中的deferrability属性表明当有多用户更新时约束施加的时机。每个Column都有使用的数据类型，这通过抽象类SQLDataType表示，SQLSimpleType和SQLDistinctType是SQLDataType的两个子类，前者表示列所使用的简单数据类型，如integer，varchar等，后者表示某些DBMS使用的一些额外数据类型，它们从简单

48、数据类型中定义得来。图A-16描述了结构类型与扩展。为了方便理解，CWM Specfication在解释该图时举了大量的例子。图中只有一个新的类型：SQLStructuredType，它是Class和DataType的子类，另外两个类是在图A-15中已经定义了的Column，NameColumnSet。SQLStructuredType就象C语言中定义的Struct一样，里面有多个域，只是这些域在这里都是Column，所以它与Column的关联中有一条是ClassifierFerture关联，表示该类型中包含的列。另外一条关联是ColumnRefStructuredType，表示列又是某种复杂

49、类型SQLStructureType，这两个关联都可以在它们的父类中找到。另外，SQLStructuredType还与NameColumnSet相对应，表示NameColumnSet的结构可以从SQLStructuredType导出。图A-17中描述了关键字，前面在Foundation层中的KeyandIndex包中已定义了UniqueKey和KeyRelationship类，该图进一步将这两个类扩展为关系数据库中的PrimaryKey（主码）和ForeignKey（外键）。UniqueConstraint是UniqueKey的子类，它定义了表中每一行唯一的条件，即可认为是侯选关键字，其中的一

50、个将被作为主键，所以PrimaryKey是UniqueConstraint的子类。其它的类和关联在前面的内容中已有描述，这里不赘述。图A-18描述了索引，同关键字一样，其中的一些类和关联已在KeyandIndex包中定义，这里只描述与关系数据相关的内容。在关系数据源中，Index为SQLIndex，该index所span的类是Table。这里，与SQLIndex相关联的IndexedFeature是SQLIndexColumn，参与SQLIndexColumn的StructureFeature是Column。图A-19描述触发器（Trigger），触发器和表之间有两重关系：其一表示表发生变化时

51、激活触发器，即触发器监控表，其二为触发器对表进行操作，另外要注意的是，触发器所属的模式不一定是它所监控的表所属的模式。有关触发器的内容比较简单，这里也不详述。图A-20描述了存储过程（Procedure），Procedure扩展了Behavioral包的Method类并从属于一个Schema，该Procedure所使用的参数是SQLParameter。图A-21描述了关系实例的构成规则。该包中的类和关联主要继承Instance包定义的类和关联。关系中的每个Row（元组）包含了关系的所有列在该Row中的相应取值。ColumnValue是DataValue的子类，Row是Object的子类，各种关

52、联关系同Instance包。RowSet是Extent的子类，它表示元组的集合，一个元组集合包含多个元组。Multidimensional包Multidimensional包描述多维数据库，其主要用于OLAP（联机分析处理）工具分析数据。在多维数据库中，OLAP的关键结构如维度、层次等由多维数据库内部的数据结构表示。与关系数据库管理系统不同，多维数据库在物理存储上一般是私有的，相互之间没有共同的标准，可以以多维数组的形式存放，也可以别的方式。但是，多维数据库的逻辑表示有统一的标准，这个在OLAP包中会讲到。多维数据库为OLAP系统带来的主要好处在于：n 它能提供快速的聚合时间和公式计算时间，以

53、及一致的查询响应时间，而不管查询有多复杂。这主要归功于有效的方格存储技术和高度优化的索引路径。n 由于多维数据库服务器直接支持和表示多维结构，构建多维数据库对多维模式以及查询的说明与使用也将相对简单直观。该包主要依赖于Core包和Instance包。如附录中图A-22所示，Schema是组成多维数据模型的所有元素的容器，意义与其在关系数据包中的Schema类似。Dimension表示多维数据库中的一个物理维度，而OLAP包中定义的Dimension只是概念上的维度，它具体的物理实现可以是多维数据库中的Dimension，也可以是关系表等。维度可以包含其它维度形成层次结构。Dimensioned

54、Object表示Dimension的属性，例如，按维度上卷的聚合函数，维度成员别名等。DimensionedObject也属于Schema并被Dimension使用。MemberSet代表一个维度取值的子集，如地区维度中城市属于美国的维度成员，它是Extent的子类，Member指维度的一个具体取值，MemberValue指维度取值中各个域的值（此处的域同关系表中的列），MemberSet，Member，MemberValue的含义与图A-21部分描述的RowSet，Row，ColumnValue类似。3.3.4 Analysis层Analysis层提供了支持逻辑服务的元模型，这些服务将会被映

55、射到由Resource层的包所定义的数据存储中去，服务包括支持ETL（抽取，转换，加载）和数据跟踪操作的Transformation包，以维度和立方体观察数据仓库的OLAP包，支持数据挖掘的元模型包，信息可视化的Information Visualization包和定义商业术语的的Nomenclature包。为简单起见，这里只讨论Transformation包和OLAP包。Transformation包将数据从操作数据源中提取、加载、转换到仓库或集市中是数据仓库非常重要的一个环节。提取、转换、加载都可以都看成是转换(Transformation)的一部分。转换包主要是用来描述与转换活动相关的元

56、数据，具体支持：1）将转换与它的数据源和数据目标联系起来。2）“黑盒”与“白盒”转换。在黑盒转换中，只知道数据源与数据目标通过转换相关联，但是并不知道如何将一个特定种类的数据源联系到另一种特定种类的数据目标。而在白盒转换中，却可以清楚地知道一种特定类型的数据源是如何通过某种特定的转换与另一种类型的数据目标相关联。3）允许将转换分成若干个逻辑部分。 转换允许不同类型和粒度的数据作为它的数据源与数据目标。例如，一个转换中的源数据类型可以是XML schema，而目标类型是关系表中的列；更典型的情况是，转换的源类型可以是类和属性而目标类型可以是关系表和列，反之亦然。另外，可以使用现有的程序，查询，或

57、规则执行转换过程。在元模型中，将使用transformation use将它们与具体的转换过程相关联，Operation是依赖的提供端，Transformation是依赖的客户端。转换包依赖于以下几个包：Behavioral，Core，Expressions，SoftwareDeployment。转换包描述了以下功能：1. 转换与数据跟踪。这些类与关联处理转换以及它们的数据源、目标、约束和操作。2. 转换分组与执行。这些类与关联处理将转换分组成逻辑单元并定义它们的执行顺序。3. 特殊转换。这些类与关联用来定义数据仓库中广泛使用的“白盒”转换。下面分别看看每个元模型图。先看附录中图A-23, 转

58、换可以被划分为多个逻辑单元。在功能层上，它们被分组为transformation task，每个transformation task又包含一系列必须一起执行和完成的transformation。在执行层，使用模型元素Transformation step来协调transformation task的执行，即每一个Transformation step代表单个transformation task的具体执行。并且多个transformation step还组成transformation activity。在每个transformation activity中，transformation s

59、tep的执行顺序或者通过step precedence 或precedence constraint明确定义，或者通过data dependency隐含表示。每个transformation task 还可能对应有其反向的Task，即原来的转换源变成转换目标，原来的转换目标现在变成转换源。DataObjectSet代表了一系列能被作为转换数据源和数据目标的数据对象。StepPrecedence是Dependency的子类，用来明确定义transformation step的执行顺序，它既可以独立使用也可以与PrecedenceConstraint（constraint的子类）联合使用。图A-24主要描述了TransformationMap的组成，它是