第二部分：元数据集成体系结构

在本系列的第一篇文章中，我们主要介绍了大数据治理的基本概念和统一流程参考模型，并阐述了该模型的第一步“明确元数据管理策略”和第二步“元数据集成体系结构” 的六种示例等内容。大数据治理统一流程参考模型的第二步是“元数据集成体系结构”，具体包括元模型、元-元模型、公共仓库元模型（CWM）、CWM 发展史、OMG 的模型驱动体系结构（Model Driven Architecture，MDA）本文将对元数据集成体系结构包含的各种模型展开叙述。

模型（Model）是用来描述特定的系统、过程、事物或概念的准确而抽象的表示。例如软件架构师可以用概要设计的形式建立一个应用系统的模型。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该描述准确地描述了数据。元模型（Metamodel）也就是模型的模型（或者元-元数据），是用来描述元数据的模型。

下面基于关系型表实体-关系（ER）模型举例说明什么是元模型。如图 1 所示，一个简单的关系型表元模型描述了如何定义一个关系型表，规定了每个表必须有一个名字（字符串），一个表可以有 1 到多个列，每个列必须有一个名字（字符串）和数据类型（字符串）：

如果要创建一个关系型表模型，基于该表元模型创建一个实例即可，比如创建一个常见的雇员表 Employees 表模型，具体如图 2 所示，Employees 表包含 6 个列，分别是编号、姓、名字、部门编号、经理编号和职位编号。

比如在 DB2 中创建 employees 表，可以很容易的从 employees 表模型中得到相应的 DDL 语句，执行 DDL 语句时 DB2 会生成描述 employees 表的内部元数据并存储在目录（DB2 内部的元数据存储库）中。

同样基于图 1 简单关系型表元模型创建另一个实例 department 表模型。department 表包含 2 个列，分别是编号和部门名称，具体如图 3 所示。由于 department 表模型和 employees 表模型都是基于相同的公共元模型，其它工具和应用程序软件（了解关系型表的公共元模型）可以很容易理解 department 表和 employees 表，因为它们都是同一个元模型的实例。其它工具或应用程序通过调用导入映射（import mapping）将该 department 表模型或 employees 表模型翻译成自己内部的元数据实例。同样，也可以将该软件内部元数据翻译成一个与平台无关的形式化模型，也就是导出映射（export mapping），以便其他软件使用其专有的元数据。这种基于公共元模型的集成方法就是模型驱动的元数据集成体系结构 [1]。

回页首

元-元模型就是元模型的模型，有时也被称为本体（ontology），是模型驱动的元数据集成体系结构的基础，其定义了描述元模型的语言，规定元模型必须依照一定的形式化规则来建立，以便所有的软件工具都能够对其进行理解。

元-元模型比元模型具有更高的抽象级别，一个元模型是一个元-元模型的实例，元模型比元-元模型更加精细，而元-元模型比元模型更加抽象。元数据（模型）则是一个元模型的实例，遵守元模型的规定和约束。用户对象（或用户数据）则是元数据（或者称为模型）的实例。元数据层次结构具体如表 1 所示，共分为 4 层，最高层 L3 是元-元模型，之下是 L2 元模型和 L1 模型/元数据，最底层是 L0 用户对象/用户数据：

回页首

公共仓库元模型（Common Warehouse MetaModel，CWM）是被对象管理组织 OMG（Object Management Group）采纳的数据仓库和业务分析领域元数据交换开放式行业标准，在数据仓库和业务分析领域为元数据定义公共的元模型和基于 XML 的元数据交换（XMI）。CWM 作为一个标准的接口，可以帮助分布式、异构环境中的数据仓库工具，数据仓库平台和数据仓库元数据存储库之间轻松实现数据仓库和业务分析元数据交换。CWM 提供一个框架为数据源、数据目标、转换、分析、流程和操作等创建和管理元数据，并提供元数据使用的世系信息 [2]。

CWM 是一个基于模型驱动方法的完整地描述数据仓库和业务分析领域的元模型，提供构建元数据所需的语法和语义，由若干个不相同又紧密相关的子元模型组成。CWM 模型的目的是最大限度的重用对象模型（Object Model，UML 的一个子集），并在可能的地方共享通用模型结构。如图 4 所示，CWM 元模型使用包（package）和层次来简化管理的复杂度并便于理解，共包含 21 个单独的包，这些包被分为 5 个层次。对象模型层包含定义基本元模型的概念、关系和约束的包，其它 CWM 包都需要用到这些定义，对象模型层的包构成了其它 CWM 包所需要的基本元模型服务的全部集合。对象模型层主要包括核心包（Core package）、行为包（Behavioral package）、关系包（Relationships package）和实例包（Instance package）。

CWM 1.1 是在 2003 年 3 月发布的，与之相关的 OMG 组织规范还有MOF、UML和XMI。CWM 使用统一建模语言（UML）定义公共元数据的模型（CWM 元模型），使用可扩展标记语言（XML）生成 CWM 元数据交换规范（也就是 XML 元数据交换，XMI），使用 CORBA 接口定义语言（IDL）为访问 CWM 元数据生成编程语言 API 的规范（依赖 MOF 到 IDL 的映射）。

UML 是一种规范化、可视化、描述明确、结构化和文档化的定义分布式对象系统的图形化语言。1996 年，业内三种最杰出的面向对象建模语言：Grady Booch 的 Booch 方法、Ivar Jacobson 的面向对象软件工程（OOSE）和 Jim Rumbaugh 的对象建模技术（OMT）被统一起来发布，也就是 UML 0.9。2011 年，UML 2.4.1 发布。CWM 依赖于 UML 规范的前三个部分，即 UML 语义、UML 符号向导和对象约束语言规范。UML 语义定义 UML 元模型的语义，UML 元模型是层次结构并以包为单位进行组织，每个包按照抽象语言（使用类图）、结构良好规则（采用 OCL）和语义（采用英语）来定义。UML 符号指定表达 UML 元模型语义的图形语法（例如类图）。对象约束语言规范定义对象约束语言（OCL）的句法、语义和语法，OCL 是一种表述约束的形式化语言 [3]。

UML 在 CWM 中主要作为三种角色出现 [4]：

元对象框架（Meta Object Framework，MOF，本文以 2.4.1 版本为例）是一个以独立于平台的方式定义、操作、集成元数据和数据的、可扩展、模型驱动的分布式对象集成框架。此框架支持各种类型的元数据，还可以根据需求添加新类型的元数据。MOF 包括 MOF 模型（定义建立元模型的建模元素和使用规则）、MOF 反射接口（允许程序在不使用元模型指定接口时对元数据进行各种操作）和 MOF 到 IDL 的映射（定义 MOF 模型定义的元模型到 CORBA IDL 之间的标准映射）。MOF 模型是以 UML 的概念和结构为基础，尤其是以 UML 的静态结构模型和模型管理为基础。MOF 模型没有定义自己的图形符号和约束语言，而是采用 UML 的图形符号和 OCL 来实现。MOF 模型也是层次结构，并以包为单位进行组织。

MOF 支持各种类型的元数据，采用四层元数据体系结构（也就是 OMG 元数据体系结构）[5]，具体如表 2 所示，该体系架构将元数据（M1）视同为数据（M0），并对之进行形式化建模（即元模型，M2）。元模型（M2）使用元-元模型（M3）所提供的元建模结构来表示。表 2 表明 MOF 模型（元-元模型）、UML 元模型、用户模型和用户对象/数据之间的关系。

XML 元数据交换（XMI）是在工具软件、应用程序之间进行元数据交换的 XML 语言，整合了 UML、MOF 和 XML 三种技术，允许 MOF 元数据（即遵从 MOF 或基于 MOF 的元模型的元数据）以流或文件的形式按照 XML 的标准格式进行交换。XMI 是 OMG 在元数据交换方面的标准之一，同时也是 W3C 认可的标准。本质上，XMI 是 W3C 的 XML 和 MOF 之间，以及 XML 文档和 MOF 元数据之间的一对平行映射。2011 年 8 月，XML 发布了 2.4.1。

回页首

其实早在上世纪 80 年代末 90 年代初，很多企业就尝试使用一种元模型实现元数据集成以整合分布于各个业务竖井中的元数据，但最终失败了，因为很多的利益相关者各自拥有不同的观点，且需要不同的模型结构。1997 年，OMG 将 UML 采纳为标准，为 CWM 标准制定打下了第一个基础。同样在 1997 年，MOF 被 OMG 采纳为标准，为 CWM 的产生打下了第二个基础。1999 年初，OMG 采纳 XMI 作为标准，为 CWM 的出现打下了第三个基础。1998 年 5 月，IBM、ORACLE 和 Unisys 向 OMG 提交了公共仓库元数据交换（Common Warehouse Metadata Interchange，CWMI） 征求意见稿（RFP），同年 9 月 OMG 发布了该征求意见稿，经过 8 个公司（IBM、Unisys、Oracle、Hyperion、UBS、NCR、Genesis 和 Dimension EDI）2 年半的努力和协作，OMG 于 2001 年 4 月正式采纳 CWM 为标准。

在 CWM 发展的同时，其他一些元数据标准的制定也在进行中。最早在 1993 年，电子信息组织就发布了计算机辅助工程数据交换格式（CASE Data Interchange Format，CDIF）并得到了一定的认可。1995 年 10 月，元数据联盟（Meta Data Coalition，MDC）成立，并与 1996 年 4 月发布了元数据交换规范 1.0（Meta Data Interchange Specification，MDIS），与 CWM 相比，MDIS 涉及的范畴少很多，且其规范和交换语言都是自身独有的。此时微软也在和其他一些合作者一起开发开放信息模型（Open Information Model，OIM），该模型于 1996 年 10 月成形，采用 UML 作为其规范语言。1998 年 11 月，微软加入 MDC 并提交 OIM 标准，1999 年 7 月 MDC 发布了 OIM v1.0 版本，由此业内面临着两种元数据集成规范的竞争局面，之后考虑到业内对 CWM 的认可，MDC 于 2000 年 9 月决定终止其 OIM 后续工作，将其元数据标准归入到 OMG 中，从此 CWM 影响力和范围持续扩大并得到了业内的统一认可。

回页首

OMG 组织成立不久制定了对象管理体系结构（Object Management Architecture，OMA）参考模型，描述了 OMG 规范所遵循的概念化的基础结构。OMA 是由对象请求代理（Object Request Broker ，ORB）、对象服务、公共设施、域接口和应用接口等几个部分组成，其核心是对象请求代理（ORB）。对象请求代理（ORB）是公共对象请求代理体系结构（Common Object Request Broker Architecture，CORBA）的核心组件，提供了识别和定位对象、处理连接管理、传送数据和请求通信所需的框架结构。OMA 和 CORBA 被定位为软件框架，用来指导基于 OMG 规范的技术开发。

从 1995 年开始，OMG 开始非正式的采用针对特定行业（“领域”，Domain）的技术规范，为了保持扩张重点，OMG 在 2001 年正式采用第二个框架，模型驱动体系架构（Model Driven Architecture，MDA）。与 OMA 和 CORBA 不一样，MDA 不是部署分布式系统的框架，而是在软件开发中基于模型驱动的方法。为了实现 MDA，OMG 随后制定了一系列标准如 UML、MOF、XMI 和 CWM 等，解决了 MDA 的模型建立、扩展、交换等几个方面的问题。模型驱动体系结构源自众所周知的和长期建立的思想：“将系统操作规范从系统利用底层平台能力的细节中分离出来”。MDA 提供了一种方法（基于相关工具）来规范化一个平台独立的系统，为系统选择一个特定的实现平台，并把系统规范转换到特定的实现平台。MDA 的首要三个目标是：可移植性、互操作性和可重用性。MDA 三个视角（viewpoint）[6] 分别是：

OMG 模型驱动体系结构如图 5 所示：

CWM 元模型、规范以及生成的产品同 MDA 非常契合，从技术平台角度来说，所有的平台相关模型（CWM XML、CWM IDL 和 CWM Java 等）都是自动地从平台无关模型（CWM 元模型和规范）中产生的；从产品平台角度来说，平台相关模型（比如 DB2、ORACLE、SQL SERVER 等）都是人工从平台无关模型（CWM 元模型和规范）中构造出来的。

回页首

本文详细介绍了大数据治理统一流程参考模型第二步“元数据集成体系结构”的后续内容，主要包括元模型、元-元模型、公共仓库元模型（CWM）、CWM 发展史、对象管理组织 OMG 的模型驱动体系结构（Model Driven Architecture，MDA）。在本系列文章的下一部分将重点介绍大数据治理统一流程参考模型的第三步：“实施元数据管理”，讲述在大数据时代如何实施元数据管理，如何使用元数据管理成熟度模型，以及 IBM 在元数据管理方面的产品：业务元数据管理工具 IBM InfoSphere Business Glossary、业务词汇表小工具 InfoSphere Business Glossary Anywhere 和技术元数据管理工具 InfoSphere Metadata Workbench。

回页首