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）

总之，建立元数据管理系统一定要坚持关注标准，又不被标准所束缚的原则，建立符合自身目标的元数据管理系统。