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

CWM元模型研究及其在广发银行数据仓库中的应用李珊珊一．数据仓库的描述需求数据仓库是企业级信息管理的一项新兴技术。它的目的是为了将企业的大量历史数据按主题集成在一起，并以一种统一的模式供分析和知识挖掘使用。数据仓库中技术种类繁多，不象数据库系统那样单一，典型的数据仓库技术包括数据抽取技术、OLAP技术、数据挖掘技术等。构建一个数据仓库需要考虑到它的创建、管理、使用和维护等诸多方面，如创建过程中要考虑旧数据库系统的数据模型、数据集成的ETL(Extract,TansfomationandLoad)规则、仓库中新数据模型的建立等，使用过程要考虑数据的物理模型和展现方式、对数据进行操作的各种统计分析算法、数据挖掘规则等。对于这些应用需求，数据仓库建模应该具备描述它们的能力，无论是底层的数据源信息，还是高层的各种操作信息，方方面面都应尽量涉及到。经过分析研究，发现OMG组织的CWM具备了这种能力，它提供了描述数据源、数据目标、转换、分析、处理、操作等与建设和管理数据仓库相关的元数据基础框架（构成规则集）[1]，使不同厂商产品的元数据通信和共享有了一个切实可行的标准。在深入理解CWM的基础上，1.2节总结了CWM的内容框架和各个组成部分的依赖关系。二、CWM的内容框架参考数据仓库的描述需求，课题中对CWM的内容体系进行了总体研究，深入分析了它的组成及结构[23]。CWM基本描述了数据仓库的各个方面，包括基本类型信息、数据资源信息、数据分析信息、仓库管理信息等。当然，它不可能囊括数据仓库中的所有信息，随着数据仓库技术的不断进步，需要描述的新信息也越来越多，这些信息只能被包含进CWM的后续扩展规范中。OMG的CWM工作小组也在时刻关注数据仓库的最新发展动向。目前的CWM版本所包含的信息基本涉及了数据仓库领域的各个方面，虽然不是完全的但至少是描述仓库操作所需的最少信息。另外，对于其所描述的元数据，语义都是精确的、无歧义的。图1-1是CWM的内容结构图[1]，从图中可以看出，CWM的内容按包组织，每个包尽量涉及一个独立的领域，这样极大地方便了开发者的建模工作，因为在建模时只取所需的包即可。并且，包的数目没有太大，结构更易于扩展，CWM目前的版本中包含了18个包和一个ObjectModel，CWM的这种特性也使得它易于理解。每个包都由一系列UML表示的类图组成。虽然这些包描述的领域不尽相同，但它们组织结构并不完全独立，事实上，它们之间有着紧密的依赖关系。在CWM的内容框架中，所有包按功能和抽象层次组织成四层，同层的包的功能角色类似，如第二层中的包描述的都是数据仓库的数据资源。每一层中的包都为同层或上层的包提供服务，如第三层包描述的操作都是基于第二层包描述的数据资源，层次越高描述的内容越抽象。在包的结构方面，或者上层包中的类和关联继承下层包中的类和关联，或者在上层的包直接使用下层包中定义的类或关联，这样做既使整个元模型组织更精练，又使CWM在功能结构上十分清晰。图1-1CWM的内容结构图如图1-1所示，最底层的是ObjectModel，分析CWM的继承图，会发现它是整个CWM的基础。ObjectModel实际是UML的一个子集，CWM最大程度地重用了UML中与描述数据仓库领域相关的一些模型元素[1,7]。CWM所有包的类与关联都是直接或间接地继承ObjectModel中的类与关联，这样，CWM可以看作是从ObjectModel生长出来的一棵大树，树的根部就是ObjectModel。ObjectModel以上的四个层次依次为：Foundation层、Resource层、Analysis层、Management层。每个层次中的包都为高层（或同层）的包提供服务。Foundation层的元模型主要是代表上层CWM包共享的概念与结构，如表达式、索引、数据类型、软件配置信息等，虽然这些都是很基本的信息，但它们与ObjectModel中的元素又有所不同，因为这些模型元素专有于CWM领域，而ObjectModel中的元素则更具一般性和通用性。Foundation层中的包以字母顺序给出；Resource层中包含了OLTP系统与数据仓库所使用的各种数据资源,有关系的、层次的、多维的等等，这些数据源都要用到Foundation层的通用信息，如关系包中描述索引和关键字的类都是从Foundation层的KeysandIndexs包中继承而来。此外，ObjectModel恰好是面向对象的数据源，因此，ObjectModel在整个CWM承担着两种角色，一方面作为整个CWM的基础，另一个方面又代表了面向对象数据源；Analysis层提供了数据仓库各种操作的元模型，包括OLAP、数据挖掘、转换等，它们会被映射到由Resource层的包所定义的数据存储中去。例如，Transformation元模型描述了数据仓库中的数据源到数据目标的转换，OLAP元模型允许存储在关系或多维数据引擎中的数据仓库以多维视图显示。Management层定义了操作任务及其调度信息（WarehouseProcess包）并记录了数据仓库活动以及相关的统计信息（WarehouseOperationPackage）。CWM的所有包中的类与关联都尽量利用了UML中的继承机制，复用已有的元素。并且，所有的基类都只出现在ObjectModel、Foundation和Resource层中，在更高的层中（Aanlysis层和Management层），已经没有基类出现。这样做的主要目的是为了简化高层包中的类图，因为更高层中的类一般都要比低层多。这种组织方式也使得类图更易于理解，因为类的总数减少了。图1-2是分析得出的包依赖关系图，箭头指向代表依赖方向，即箭头始发处的包中的类和关联继承箭头指向的包中的类和关联。WarehouseProcessWarehouseOperationTransformationBusinessNomenclatureInformationVisualizationDataMiningOLAPXMLMultidimensionalRecordRelationalObjectModelDatatypesBusinessInformationExpressionKeysandIndexesSoftwareDeploymeTypeMappingCoreBehaviorRelationshipInstance图1-2CWM各包依赖关系图CWM中的每个包都由一组类图和相应的约束组成，约束使用OCL来描述。所有的类都只包含静态属性，没有包含任何操作属性，CWM把操作信息留给工具自定义，从而为CWM开发商保留更大的灵活性。另外，类之间的关联使用引用方式表达。考虑到工作量的问题，在1.1节将以一个独立完整的数据仓库过程为主线详细分析部分包的内容。三、CWM各层内容剖析考虑到工作量的问题，本文将不对CWM中的所有包进行分析，而是依据实际数据仓库开发的经验只在四个层次中选一部分进行研究和实现，它们是描述一个独立完整的数据仓库过程所需要的最少建模元素。分别挑选了Management层的WarehouseProcess包和WarehouseOperation包、Analysis层的Transformation包和OLAP包、Resource层的Relation包和Multidimensional包以及Foundation层中的所有包。在分析这些包之前，先深入剖析ObjectModel。ObjectModel是整个CWM的基础，它为创建和描述CWM的其它包提供了基本构架。分析过程需要对照CWM规范中的类图，由于CWM中的图繁多，因此在正文中只附Core包的图辅助讲解。另外，分析由下往上按层次展开。3.1.1ObjectModelObjectModel是UML的一个子集，它只含有UML中与描述数据仓库有关的部分。ObjectModel又包括四个包：Core包、Behavioral包、Relationship包和Instance包。Core包是核心，其余三个包都依赖且只依赖于Core包。除此之外，ObjectModel中再没有其他依赖关系。Core包Core中总共有三个图，分别见图1-3,1-4,1-5。ManagementAnalysisResourceFoundationObjectModel图1-3Core包类图1从图中可以看出，Element类位于最顶层，事实上，它也是CWM中所有类的祖先，如果把CWM想成一个树状的类继承结构，那么Element就是这棵树的根。Element中没有任何属性，只是一个抽象元类，包含表达语义信息的模型元素和用于表示的表达元素。ModelElement是Element的子类，前者只描述模型元素。模型元素与表达元素不同，表达元素是以表现模型为目的的图形元素，它们不含有语义信息，而在CWM中，绝大多数类都是带有语义信息的模型元素。ModeElement包含了一个最基本且最重要的属性——Name。除了少数几个类，如Multiplicity，几乎所有CWM类都是直接或间接地继承ModelElement。并且ModelElement还作为这些类相互关联的连接点，绝大多数提供通用服务的类，如Dependency，Constraint等都直接关联到ModelElement表示可以为所有的模型元素提供这种服务。Core包中提供通用服务的类主要有以下这些：Constraint：一种扩展机制，用于描述对模型元素的行为约束。Dependency：定义了模型元素之间的依赖关系，与Dependency相关联的两个模型元素中，一个作为依赖方（client），另一个作为被依赖方（supplier）。TaggedValue：一种名字值对的形式，表示与具体应用相关的属性，TaggedValue是一种扩展机制。任何模型元素或表达元素都可以带有零或多个名字值对[24]。Stereotype：该类也为CWM提供了一种扩展机制。在实际建模过程中，开发人员可能想要传递某种语义差别，但是供使用的可能只有一种建模元素，为了表示这种差别，更精确地反映该模型元素所表达的语义，就可以用Stereotype[24]。比如说类可以分为实体类，边界类和控制类，而在用UML建模时就只能用Class统一表示，为了在必要的时候加以区分，就可以使用Stereotype。再从ModelElement沿着继承链往下看，Namespace的含义就象通常所说的容器，它的目的是为了按某种逻辑意义将元素分组。组包含一系列的ModelElement，且它与ModelElement的关系是强聚合关联。除了顶级Namespace，几乎所有的ModelElement都会属于且只能属于一个Namespace。同一Namespace中ModelElement的命名是唯一的，命名规则一般为“Namespace名：：ModelElement名”。因此，使用Namespace还可以避免在整个模型范围内的命名冲突。Classifier和Package都是Namespace的子类，可以这样理解这两个子类的意义：Classifier的作用类似于C++中的.h文件，而Package的作用类似于C++中的.cpp文件，一个描述静态结构，而另一个则描述具体实现。Classifier有多种具体的形式，包括Class，DataType等，Classifier常用作类型（Type）。作为一个Namespace，一个Classifier还可以嵌套定义其它的Classifier。Classifier也可能包含一系列Feature，比如说Attribute，Operation等。Class是一种最常见的Classifier，其实Classifier的每种子类都可按Class的概念理解，只是分别在内容和使用上有了某些特殊限制。DataType既包含原始的数据类型（如整型，字符串等），又包含可定义的枚举类型。一般来说，DataType常被用来作为属性或参数的类型。Package也提供了一个分组机制