在最开始的时候，元数据（Meta Data）是指描述数据的数据，通常由信息结构的描述组成，随着技术的发展元数据内涵有了非常大的扩展，目前包括：UML模型、数据交易规则、用JAVA，NET，C++等编写的APIs、业务流程和工作流模型、产品配置描述和调优参数以及各种业务规则、术语和定义等[1]。元数据通常分为业务元数据、技术元数据和操作元数据等。业务元数据主要包括业务规则、定义、术语、术语表、运算法则和系统使用业务语言等，主要使用者是业务用户。技术元数据主要用来定义信息供应链（Information Supply Chain，ISC）各类组成部分元数据结构，具体包括各个系统表和字段结构、属性、出处、依赖性等以及存储过程，函数，序列等各种对象。操作元数据是指应用程序运行信息，比如其频率、记录数以及各个组件的分析和其它统计信息等。本章主要讲述元数据管理的方法和模型比如本体论（Ontology）、元模型、元-元模型、公共仓库元模型（CWM）、元数据管理成熟度模型以及元数据管理策略、元数据集成体系结构等。

1.概述

从整个企业层面来说，各种工具软件和应用程序越来越复杂，相互依存度逐年增加，相应的追踪整个信息供应链各组件之间数据流动、了解数据元素含义和上下文的需求越来越强烈。在从应用议程往信息议程的转变过程中，元数据管理也逐渐从局部存储和管理转向共享。从总量上来看，整个企业的元数据越来越多，光现有的数据模型中就包含了成千上万的表，同时还有更多的模型等着上线。为了企业更高效地运转，企业需要有步骤的提升其元数据管理成熟度，基于成熟的方法论进行构建。
信息供应链是由典型的数据仓库和业务分析环境引申出来的概念，后来逐渐外延到整个数据中心，是指信息从源头流出，经过一系列转换和处理，最终产生信息产品的过程。下图所示就是一个电信行业简单的ISC的示例：

2. 本体（人工智能和计算机科学）

本体（Ontology）源自哲学本体论，而哲学本体论则是源自哲学中“形而上学”分支。本体有时也被翻译成本体论，在人工智能和计算机科学领域本体最早源于上世纪70年代中期，随着人工智能的发展人们发现知识的获取是构建强大人工智能系统的关键，于是开始将新的本体创建为计算机模型从而实现特定类型的自动化推理。之后到了上世纪80年代，人工智能领域开始使用本体表示模型化时间的一种理论以及知识系统的一种组件，认为本体（人工智能）是一种应用哲学。
最早的本体（人工智能和计算机科学）定义是Neches等人在1991给出的：“一个本体定义了组成主题领域的词汇的基本术语和关系，以及用于组合术语和关系以及定义词汇外延的规则”。而第一次被业界广泛接受的本体定义出自Tom Gruber，其在1993年提出：“本体是概念化的显式的表示（规格说明）”。Borst在1997年对Tom Gruber的本体定义做了进一步的扩展，认为：“本体是共享的、概念化的一个形式的规范说明”。在前人的基础上，Studer在1998年进一步扩展了本体的定义，这也是今天被广泛接受的一个定义：“本体是共享概念模型的明确形式化规范说明”。本体提供一个共享词汇表，可以用来对一个领域建模，具体包括那些存在的对象或概念的类型、以及他们的属性和关系[2]。一个简单的本体示例发票概念及其相互关系所构成的语义网络如下图所示：

随着时间的推移和技术的发展，本体从最开始的人工智能领域逐渐扩展到图书馆学、情报学、软件工程、信息架构、生物医学和信息学等越来越多的学科。与哲学本体论类似，本体（人工智能和计算机科学）依赖某种类别体系来表达实体、概念、事件及其属性和关系。本体的核心是知识共享和重用，通过减少特定领域内概念或术语上的分歧，使不同的用户之间可以顺畅的沟通和交流并保持语义等效性，同时让不同的工具软件和应用系统之间实现互操作。
根据研究层次可以将本体的种类划分为“*本体”（top-level ontology）、应用本体（application ontology）、领域本体（domain ontology）和任务本体（task ontology），各个种类之间的层次关系如下图所示。

• *本体，也被称为上层本体（upper ontolog）或基础本体（ foundation ontology），是指独立于具体的问题或领域，在所有领域都适用的共同对象或概念所构成的模型，主要用来描述高级别且通用的概念以及概念之间的关系。
• 领域本体是指对某个特定的领域建模，显式的实现对领域的定义，确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领域知识的共同理解。领域本体所表达的是适合自己领域的术语的特定含义，缺乏兼容性，因而在其他领域往往不适用。在同一领域内，由于文化背景、语言差异、受教育程度或意识形态的差异，也可能会出现不同的本体。很多时候，随着依赖领域本体系统的扩展，需要将不同的领域本体合并为更通用的规范说明，对并非基于同一*本体所构建的本体进行合并是一项非常具有挑战的任务，很多时候需要靠手工来完成，相反，对那些基于同一*本体构建的领域本体可以实现自动化的合并。
• 任务本体是针对任务元素及其之间关系的规范说明或详细说明，用来解释任务存在的条件以及可以被用在哪些领域或环境中。是一个通用术语的集合用来描述关于任务的定义和概念等。
• 应用本体： 描述依赖于特定领域和任务的概念及概念之间的关系，是用于特定应用或用途的本体，其范畴可以通过可测试的用例来指定。

从详细程度上来分，本体又可以分为参考本体（reference ontologies）和共享本体（share ontologies），参考本体的详细程度高，而共享本体的详细程度低。

3. 元模型（Metamodel）

模型（Model）是用来描述特定的系统、过程、事物或概念的准确而抽象的表示。例如软件架构师可以用概要设计的形式建立一个应用系统的模型。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该描述准确地描述了数据。元模型（Metamodel）也就是模型的模型（或者元-元数据），是用来描述元数据的模型。
下面基于关系型表实体-关系（ER）模型举例说明什么是元模型。如下图所示，一个简单的关系型表元模型描述了如何定义一个关系型表，规定了每个表必须有一个名字（字符串），一个表可以有1到多个列，每个列必须有一个名字（字符串）和数据类型（字符串）：

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

Create table employees (
Id integer not null，
First_name String not null，
Last_name  String not null，
Depart_ID  Integer not null，
Manager_ID Integer not null，
Job_ID  Integer not null

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

# **4. 数据中台所使用的元-元模型（Meta-meta model）**
元-元模型就是元模型的模型，有时也被称为本体（ontology），是模型驱动的元数据集成体系结构的基础，其定义了描述元模型的语言，规定元模型必须依照一定的形式化规则来建立，以便所有的软件工具都能够对其进行理解。
元-元模型比元模型具有更高的抽象级别，一个元模型是一个元-元模型的实例，元模型比元-元模型更加精细，而元-元模型比元模型更加抽象。元数据（模型）则是一个元模型的实例，遵守元模型的规定和约束。用户对象（或用户数据）则是元数据（或者称为模型）的实例。元数据层次结构具体如下表所示，共分为4层，最高层L3是元-元模型，之下是L2元模型和L1模型/元数据，最底层是L0用户对象/用户数据：


# **5. 元数据集成体系结构**
元数据集成体系结构是在技术上实现元数据管理策略的系统体系结构。针对信息供应链中不同的组件，为了实现跨组件的元数据交换和集成，最开始人们采用点对点的方式进行，也就是每一对组件之间通过一个独立的元数据桥（metadata bridge）进行元数据交换，桥一般是双向的能够理解两个方向的元数据映射[5]。点对点的元数据集成体系结构帮助用户实现了跨企业的元数据集成和元数据交换，对提升信息化水平提供了巨大帮助。这种体系结构在应用过程中，也暴露了很多问题，比如元数据桥的构建工作量和耗时都非常大，对中间件厂商、应用厂商、集成商和用户来说都是一个巨大的挑战，而且构建元数据桥还必须具有所有者的元数据模型和接口的详细信息。构建完成的桥很多时候无法在构建其他元数据桥时进行重用，因此开发和维护费用大幅度增加，用户投资回报率（ROI）不高。点对点的元数据集成体系结构具体如下图所示，信息供应链各组件之间的空心箭头表示全部的数据流，实心箭头表示不同的元数据桥和与之关联的元数据流。

通过使用*元数据存储库（central metadata repository）取代各个工具软件和应用程序之间的点对点连接方式，改成*元数据存储库与各个工具软件和应用程序实现元数据交换的访问层（也是一种桥），可以有效降低总成本，减少建立点对点元数据桥的工作，提高投资回报率。信息供应链各组件可以从存储库访问元数据，不必与其他产品进行点对点交互。这种使用*元数据存储库方式进行元数据集成的方式就是*辐射式元数据体系结构（hub-and-spoke meta data architecture），具体如下图所示。由于特定的元数据存储库是围绕其自身的元模型、接口和交付服务建立的，所以仍需要建立元数据桥实现与ISC各组件的互相访问。

采用模型驱动的元数据集成方法（比如使用CWM）可以有效降低元数据集成的成本和复杂度，无论点对点元数据集成体系结构还是*辐射式元数据集成体系结构都可以因此受益。在点对点体系结构中，通过使用基于模型的方法可以不必在每一对需要集成的产品之间构建元数据桥，每个产品只需要提供一个适配器（adapter）即可实现各个产品之间的元数据交换，适配器既了解公共的元模型也了解本产品元模型的内部实现。如下图所示，基于CWM模型驱动点对点元数据集成体系结构使用通用元模型，不再需要在各个产品间建立元数据桥，在各个产品之间通过适配器实现了语义等价性。

如下图所示，在基于模型驱动（比如CWM）的*辐射式元数据体系结构中，*存储库包含公共元模型和整个领域（domain）用到的该元模型的各个实例（模型）、存储库自身元模型及其实例、理解元模型（公共元模型和自身元模型）的适配器层，当然存储库也可以直接实现公共元模型的某些内部表示。

如下图所示，这种体系架构是基于CWM模型驱动的*存储库元数据集成体系结构的一个变种，两个*辐射式的拓扑结构通过各自的元数据存储库连接起来，也被称为分布式（Distributed）或联邦（Federated）体系结构。两个元数据存储库之间通过元数据桥连接，两个存储库使用相同的元模型和接口，也可以使用不同的元模型和接口。建立分布式元数据集成体系结构的原因有很多种，比如企业基于多个区域单独部署自己的应用，每个区域有自己的数据中心。

如下图所示，这种体系结构是分布式体系结构的变体，根存储库实现了元模型的公共部分（横跨整个企业），叶子存储库实现了一个或多个特定的公共元模型子集，并只保存这些自己所对应的元数据实例。特定客户可以主要访问其感兴趣的元数据所在的叶子存储库，也可以访问其它叶子存储库和根存储库。这种体系结构被称为层次或星型拓扑结构。


# **6. 公共仓库元模型（CWM）概述**
公共仓库元模型（Common Warehouse MetaModel ，CWM）是被对象管理组织OMG（Object Management Group）采纳的数据仓库和业务分析领域元数据交换开放式行业标准，在数据仓库和业务分析领域为元数据定义公共的元模型和基于XML的元数据交换（XMI）。CWM作为一个标准的接口，可以帮助分布式、异构环境中的数据仓库工具，数据仓库平台和数据仓库元数据存储库之间轻松实现数据仓库和业务分析元数据交换。CWM提供一个框架为数据源、数据目标、转换、分析、流程和操作等创建和管理元数据，并提供元数据使用的世系信息[6]。CWM是一个基于模型驱动方法的完整地描述数据仓库和业务分析领域的元模型，提供构建元数据所需的语法和语义，由若干个不相同又紧密相关的子元模型组成。CWM模型的目的是最大限度的重用对象模型（Object Model，UML的一个子集），并在可能的地方共享通用模型结构。CWM元模型使用包（package）和层次来来简化管理的复杂度并便于理解，共包含21个单独的包，这些包被分为5个层次。对象模型层包含定义基本元模型的概念、关系和约束的包，其它CWM包都需要用到这些定义，对象模型层的包构成了其它CWM包所需要的基本元模型服务的全部集合。对象模型层主要包括核心包（Core package）、行为包（Behavioral package）、关系包（Relationships package）和实例包（Instance package）。
1.数据源层（Data Resources）：主要描述CWM元数据交换中即可作为源又可以作为目标的数据源的结构，本层含有的元模型主要描述面向对象的数据库和应用、关系型数据库、面向记录的数据源（如文件、记录数据库管理系统等）、多维数据库和XML数据源等。对于面向对象数据源，CWM一般情况下重用基本的对象模型（位于对象模型层），如果该数据源具有对象模型层无法处理的一些特征和功能时，可以通过定义一个扩展包来解决。
2.数据分析层（Data Analysis）：本层含有的元模型主要描述数据转换、在线分析处理OLAP、数据挖掘、信息可视化和业务术语等。
3.仓库管理层（Warehouse Management）：本层含有的元模型主要描述数据仓库处理和数据仓库操作。    

CWM截止到目前最新版本是1.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，最新版本是2.4.1，是在2011年发布的。CWM 依赖于UML规范的前三个部分，即UML语义、UML符号向导和对象约束语言规范。UML语义定义UML元模型的语义，UML元模型是层次结构并以包为单位进行组织，每个包按照抽象语言（使用类图）、结构良好规则（采用OCL）和语义（采用英语）来定义。UML符号指定表达UML元模型语义的图形语法（例如类图）。对象约束语言规范定义对象约束语言（OCL）的句法、语义和语法，OCL是一种表述约束的形式化语言[7]。
- 构造块和结构良好规则：UML提供了组成构造块和结构良好规则的面向对象建模语言，基本的构造块包括模型元素（如类、对象、接口、组件、用例等）、关系（如关联、泛化、依赖等）和图（如类图、对象图、用例图等）等。
- UML可以为一个系统进行不同方面的建模，比如结构建模（又包括使用类图和对象图的静态结构建模和使用组件图和部署图实现建模）、用例建模和行为建模等。元数据建模只需要静态结构建模，静态结构的核心元素是类、对象、属性和操作。
- UML用包来将模型元素组织成语义上相关联的分组，每个包拥有其自己的模型元素，每个模型元素不能同时被多个包拥有。
UML在CWM中主要作为三种角色出现[8]：
1.    UML作为和MOF等价的元-元模型。UML，或者部分对应MOF模型、UML符号和OCL 的UML分别被用作建模语言、图形符号和约束语言，用来定义和表示CWM。
2.    UML作为基础元模型。对象模型层（Object Model）与UML关系密切，是UML的一个子集。
3.    UML用来作为面向对象元模型。
元对象框架（Meta Object Framework，MOF，目前版本是2.4.1）是一个以独立于平台的方式定义、操作、集成元数据和数据的、可扩展、模型驱动的分布式对象集成框架。此框架支持各种类型的元数据，还可以根据需求添加新类型的元数据。MOF包括MOF模型（定义建立元模型的建模元素和使用规则）、MOF反射接口（允许程序在不使用元模型指定接口时对元数据进行各种操作）和MOF到IDL的映射（定义MOF模型定义的元模型到CORBA IDL之间的标准映射）。MOF模型是以UML的概念和结构为基础，尤其是以UML的静态结构模型和模型管理为基础。MOF模型没有定义自己的图形符号和约束语言，而是采用UML的图形符号和OCL来实现。MOF模型也是层次结构，并以包为单位进行组织。
MOF支持各种类型的元数据，采用四层元数据体系结构（也就是OMG元数据体系结构）[9]，具体如表05-02所示，该体系架构将元数据（M1）视同为数据（M0），并对之进行形式化建模（即元模型，M2）。元模型（M2）使用元-元模型（M3）所提供的元建模结构来表示。如下表所示，MOF模型（元-元模型）、UML元模型、用户模型和用户对象/数据之间的关系。

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

# **7. OMG的模型驱动体系结构（Model Driven Architecture，MDA）**
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）[10]分别是：
- 计算无关视角（Computation Independent Viewpoint）：侧重系统环境和系统需求；系统结构和流程细节被隐藏或尚未确定。其对应的是计算无关模型（Computation Independent Model ，CIM）。
- 平台无关视角（Platform Independent Viewpoint）：侧重系统的操作，同时隐藏用于特定平台的必要细节。其对应的是平台无关模型（Platform Independent Model ，PIM），PIM是抽出技术和具体工程细节之后的模型。
- 平台相关视角（Platform Specific Viewpoint）：结合平台无关系视角和系统所使用的特定平台细节。其对应的是平台相关模型（Platform Specific Viewpoint Model ，PSM），PSM是包含技术和具体工程细节的模型。
MG模型驱动体系结构如下图所示：

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

# **7. 参考文献**
1. David Frankel Consulting ，”Using Model Driven Architecture™ to Manage Metadata”，P3
2. Fredrik Arvidsson and Annika Flycht-Eriksson，2008，Ontologies I，” An ontology provide a shared vocabulary，which can be used to model a domain，thatis，the type of objects and/or concepts thatexist，and their properties and relations”
3. 更多内容请参考：  [专著] / （英）伯特兰.罗素/著 孙绍武/主编 <<西方哲学史 >> 
4. 更多信息请参考：OMG Model Driven Architecture ：http://www.omg.org/mda/
5. John Poole，Dan Chang，Douglas Tolbert and David Mellor，2002，Common Warehouse Metamodel ，p18-32，p180-202
6. OMG，Common Warehouse Metamodel（CWM） Specification v1.1，P44
7. John Poole，Dan Chang，Douglas Tolbert and David Mellor，2002，Common Warehouse Metamodel ，p48-53，p58-63
8. OMG，Common Warehouse Metamodel（CWM） Specification v1.1，P45
9. David Frankel Consulting ，”Using Model Driven Architecture™ to Manage Metadata”，P46
10. OMG，2003，MDA Guide Version 1.0.1，p11-12，P15-16