大数据治理系列.doc

1、大数据治理 为业务提供持续的、可度量的价值目录大数据治理 为业务提供持续的、可度量的价值 1概述 1大数据治理系列 .1第一部分：大数据治理统一流程模型概述和明确元数据管理策略 .2第二部分：元数据集成体系结构 14第三部分：实施元数据管理 .24第四部分：大数据治理统一流程参考模型的第四步到第九步 .36第五部分：定义度量值和主数据监管 52第六部分：大数据监管和信息单一视图监管 .66第七部分：分析监管、安全与隐私管理和信息生命周期监管 .79概述面对我们身边每时每刻迅速增长的庞大数据，因为其数量大、速度快、种类多和准确性的特征，如何更好地利用大数据创造出有意义的价值，一直是我们探索的重要

2、话题。而在这之前，就需要用科学正确的方法策略对大数据进行治理。大数据治理是指制定与大数据有关的数据优化、隐私保护与数据变现的政策，是传统信息治理的延续和扩展，也是大数据分析的基础，还是连接大数据科学和应用的桥梁，因此大数据治理是大数据再创高峰的“必修课”。下面我们将与您分享新鲜出炉的大数据治理方案。大数据治理系列本系列共分为七个部分，围绕大数据治理统一流程参考模型，并结合实际业务问题和 IBM 相应的产品解决方案展开叙述。第一部分：大数据治理统一流程模型概述和明确元数据管理策略为了更好地帮助企业进行大数据治理，笔者在 IBM 数据治理统一流程模型基础上结合在电信、金融、政府等行业进行大数据治理

3、的经验，整理出了大数据治理统一流程参考模型。本文主要介绍了大数据治理的基本概念，以及结合图文并茂的方式讲解了大数据治理统一流程参考模型的前两步：“明确元数据管理策略”和“元数据集成体系结构 ”内容。大数据治理概述（狭义）大数据是指无法使用传统流程或工具在合理的时间和成本内处理或分析的信息，这些信息将用来帮助企业更智慧地经营和决策。而广义的大数据更是指企业需要处理的海量数据，包括传统数据以及狭义的大数据。 （广义）大数据可以分为五个类型：Web 和社交媒体数据、机器对机器（M2M ）数据、海量交易数据、生物计量学数据和人工生成的数据。 Web 和社交媒体数据：比如各种微博、博客、社交网站、购物网

4、站中的数据和内容。 M2M 数据：也就是机器对机器的数据，比如 RFID 数据、GPS 数据、智能仪表、监控记录数据以及其他各种传感器、监控器的数据。 海量交易数据：是各种海量的交易记录以及交易相关的半结构化和非结构化数据，比如电信行业的 CDR、3G 上网记录等，金融行业的网上交易记录、corebanking 记录、理财记录等，保险行业的各种理赔等。 生物计量学数据：是指和人体识别相关的生物识别信息，如指纹、DNA、虹膜、视网膜、人脸、声音模式、笔迹等。 人工生成的数据：比如各种调查问卷、电子邮件、纸质文件、扫描件、录音和电子病历等。在各行各业中，随处可见因数量、速度、种类和准确性结合带来的

5、大数据问题，为了更好地利用大数据，大数据治理逐渐提上日程。在传统系统中，数据需要先存储到关系型数据库/数据仓库后再进行各种查询和分析，这些数据我们称之为静态数据。而在大数据时代，除了静态数据以外，还有很多数据对实时性要求非常高，需要在采集数据时就进行相应的处理，处理结果存入到关系型数据库/ 数据仓库、 MPP 数据库、Hadoop 平台、各种 NoSQL 数据库等，这些数据我们称之为动态数据。比如高铁机车的关键零部件上装有成百上千的传感器，每时每刻都在生成设备状态信息，企业需要实时收集这些数据并进行分析，当发现设备可能出现问题时及时告警。再比如在电信行业，基于用户通信行为的精准营销、位置营销等

6、，都会实时的采集用户数据并根据业务模型进行相应的营销活动。大数据治理的核心是为业务提供持续的、可度量的价值。大数据治理人员需要定期与企业高层管理人员进行沟通，保证大数据治理计划可以持续获得支持和帮助。相信随着时间的推移，大数据将成为主流，企业可以从海量的数据中获得更多的价值，而大数据治理的范围和严格程度也将逐步上升。为了更好地帮助企业进行大数据治理，笔者在 IBM 数据治理统一流程模型基础上结合在电信、金融、政府等行业进行大数据治理的经验，整理了大数据治理统一流程参考模型，整个参考模型分为必选步骤和可选步骤两部分。大数据治理统一流程参考模型如图 1 所示，大数据治理统一流程参考模型必要步骤分为

7、两个方向：一条子线是在制定元数据管理策略和确立体系结构的基础上实施全面的元数据管理，另一条子线是在定义业务问题、执行成熟度评估的基础上定义数据治理路线图以及定义数值治理相关的度量值。在 11 个必要步骤的基础上，企业可以在 7 个可选步骤中选择一个或多个途径进行特定领域的数据治理，可选步骤为：主数据监管、 （狭义）大数据监管、信息单一视图监管、运营分析监管、预测分析监管、管理安全与隐私以及监管信息生命周期。企业需要定期对大数据治理统一流程进行度量并将结果发送给主管级发起人。图 1 大数据治理统一流程参考模型第一步：明确元数据管理策略在最开始的时候，元数据（MetaData）是指描述数据的数据，

8、通常由信息结构的描述组成，随着技术的发展元数据内涵有了非常大的扩展，比如 UML 模型、数据交易规则、用 Java，.NET，C+等编写的 APIs、业务流程和工作流模型、产品配置描述和调优参数以及各种业务规则、术语和定义等1。在大数据时代，元数据还应该包括对各种新数据类型的描述，如对位置、名字、用户点击次数、音频、视频、图片、各种无线感知设备数据和各种监控设备数据等的描述等。元数据通常分为业务元数据、技术元数据和操作元数据等。业务元数据主要包括业务规则、定义、术语、术语表、运算法则和系统使用业务语言等，主要使用者是业务用户。技术元数据主要用来定义信息供应链（Information Suppl

9、y Chain， ISC）各类组成部分元数据结构，具体包括各个系统表和字段结构、属性、出处、依赖性等，以及存储过程、函数、序列等各种对象。操作元数据是指应用程序运行信息，比如其频率、记录数以及各个组件的分析和其它统计信息等。从整个企业层面来说，各种工具软件和应用程序越来越复杂，相互依存度逐年增加，相应的追踪整个信息供应链各组件之间数据流动、了解数据元素含义和上下文的需求越来越强烈。在从应用议程往信息议程的转变过程中，元数据管理也逐渐从局部存储和管理转向共享。从总量上来看，整个企业的元数据越来越多，光现有的数据模型中就包含了成千上万的表，同时还有更多的模型等着上线，同时随着大数据时代的来临，企业

10、需要处理的数据类型越来越多。为了企业更高效地运转，企业需要明确元数据管理策略和元数据集成体系结构，依托成熟的方法论和工具实现元数据管理，并有步骤的提升其元数据管理成熟度。为了实现大数据治理，构建智慧的分析洞察，企业需要实现贯穿整个企业的元数据集成，建立完整且一致的元数据管理策略，该策略不仅仅针对某个数据仓库项目、业务分析项目、某个大数据项目或某个应用单独制定一个管理策略，而是针对整个企业构建完整的管理策略。元数据管理策略也不是技术标准或某个软件工具可以取代的，无论软件工具功能多强大都不能完全替代一个完整一致的元数据管理策略，反而在定义元数据集成体系结构以及选购元数据管理工具之前需要定义元数据管

11、理策略。元数据管理策略需要明确企业元数据管理的愿景、目标、需求、约束和策略等，依据企业自身当前以及未来的需要确定要实现的元数据管理成熟度以及实现目标成熟度的路线图，完成基础本体、领域本体、任务本体和应用本体的构建，确定元数据管理的安全策略、版本控制、元数据订阅推送等。企业需要对业务术语、技术术语中的敏感数据进行标记和分类，制定相应的数据隐私保护政策，确保企业在隐私保护方面符合当地隐私方面的法律法规，如果企业有跨国数据交换、元数据交换的需求，也要遵循涉及国家的法律法规要求。企业需要保证每个元数据元素在信息供应链中每个组件中语义上保持一致，也就是语义等效（semantic equivalence）

12、 。语义等效可以强也可以弱，在一个元数据集成方案中，语义等效（平均）越强则整个方案的效率越高。语义等效的强弱程度直接影响元数据的共享和重用。本体（人工智能和计算机科学）本体（Ontology ）源自哲学本体论，而哲学本体论则是源自哲学中“形而上学”分支。本体有时也被翻译成本体论，在人工智能和计算机科学领域本体最早源于上世纪 70 年代中期，随着人工智能的发展人们发现知识的获取是构建强大人工智能系统的关键，于是开始将新的本体创建为计算机模型从而实现特定类型的自动化推理。之后到了上世纪 80 年代，人工智能领域开始使用本体表示模型化时间的一种理论以及知识系统的一种组件，认为本体（人工智能）是一种应

13、用哲学。最早的本体（人工智能和计算机科学）定义是 Neches 等人在 1991 给出的：“一个本体定义了组成主题领域的词汇的基本术语和关系，以及用于组合术语和关系以及定义词汇外延的规则”。而第一次被业界广泛接受的本体定义出自 Tom Gruber，其在 1993 年提出： “本体是概念化的显式的表示（规格说明） ”。Borst 在 1997 年对 Tom Gruber 的本体定义做了进一步的扩展，认为： “本体是共享的、概念化的一个形式的规范说明”。在前人的基础上，Stude 在 1998 年进一步扩展了本体的定义，这也是今天被广泛接受的一个定义：“本体是共享概念模型的明确形式化规范说明”

14、。本体提供一个共享词汇表，可以用来对一个领域建模，具体包括那些存在的对象或概念的类型、以及他们的属性和关系2。一个简单的本体示例发票概念及其相互关系所构成的语义网络如图 2 所示：图 2 简单本体（发票）示例随着时间的推移和技术的发展，本体从最开始的人工智能领域逐渐扩展到图书馆学、情报学、软件工程、信息架构、生物医学和信息学等越来越多的学科。与哲学本体论类似，本体（人工智能和计算机科学）依赖某种类别体系来表达实体、概念、事件及其属性和关系。本体的核心是知识共享和重用，通过减少特定领域内概念或术语上的分歧，使不同的用户之间可以顺畅的沟通和交流并保持语义等效性，同时让不同的工具软件和应用系统之间实

15、现互操作。根据研究层次可以将本体的种类划分为“顶级本体”（top-level ontology） 、应用本体（application ontology） 、领域本体（domain ontology）和任务本体（task ontology） ，各个种类之间的层次关系如图 3 所示。图 3 本体层次关系 顶级本体，也被称为上层本体（upper ontology）或基础本体（foundation ontology） ，是指独立于具体的问题或领域，在所有领域都适用的共同对象或概念所构成的模型，主要用来描述高级别且通用的概念以及概念之间的关系。 领域本体是指对某个特定的领域建模，显式的实现对领域的定义，

16、确定该领域内共同认可的词汇、词汇业务含义和对应的信息资产等，提供对该领域知识的共同理解。领域本体所表达的是适合自己领域的术语的特定含义，缺乏兼容性，因而在其他领域往往不适用。在同一领域内，由于文化背景、语言差异、受教育程度或意识形态的差异，也可能会出现不同的本体。很多时候，随着依赖领域本体系统的扩展，需要将不同的领域本体合并为更通用的规范说明，对并非基于同一顶级本体所构建的本体进行合并是一项非常具有挑战的任务，很多时候需要靠手工来完成，相反，对那些基于同一顶级本体构建的领域本体可以实现自动化的合并。 任务本体是针对任务元素及其之间关系的规范说明或详细说明，用来解释任务存在的条件以及可以被用在哪

17、些领域或环境中。是一个通用术语的集合用来描述关于任务的定义和概念等。 应用本体：描述依赖于特定领域和任务的概念及概念之间的关系，是用于特定应用或用途的本体，其范畴可以通过可测试的用例来指定。从详细程度上来分，本体又可以分为参考本体（reference ontologies）和共享本体（share ontologies） ，参考本体的详细程度高，而共享本体的详细程度低。本体（哲学）哲学中的本体（ontology ）也被称为存在论，源自哲学中“形而上学”分支，主要探讨存在的本质，也就是存在的存在。英文 ontology 实际上就是来源于希腊文“”（存在）和“ ”（学科）的组合。本体是由早期希腊哲学

18、在公元前6 世纪到公元前 4 世纪提出的“始基”延伸出来的。始基（Principle，又称本原）最早由泰勒斯（米利都学派）最早提出来，认为万物由水而生，其学生阿那克西曼德认为万物由一种简单的原质组成，该原质不是水3。而毕达哥拉斯（学派）认为“万物都是数 ”，数不仅被看作万物的本原，而且被看作万物的原型、世界的本体。后来巴门尼德（爱利亚学派）提出了“存在”的概念，认为存在才是唯一真正存在的真理，其创造了一种形而上学论证方式，之后的哲学一直到近时期为止，都从巴门尼德处接受了其“实体的不可毁灭性”。苏格拉底继承了巴门尼德的存在概念，主张“真正的善” 并完善了巴门尼德弟子芝诺的辩证法，其学生柏拉图提出

19、了“ 理念论 ”，认为只要若干个个体拥有一个共同的名字，它们就有一个共同的理念或形式。亚里士多德（柏拉图学生）总结了先哲们的思想，完成了形而上学 ，并将本体总结为：对世界上客观存在事物的系统的描述，即存在论，也就是最形而上学的知识。形而上学不是指孤立、静止之类的意思，而是指超越具体形态的抽象意思，是关于物质世界最普遍的、最一般的、最不具体的规律的学问。第二步：元数据集成体系结构在明确了元数据管理策略后需要确定实现该管理策略所需的技术体系结构，即元数据集成体系结构。各个企业的元数据管理策略和元数据管理成熟度差别较大，因此元数据集成体系结构也多种多样。大体上元数据集成体系结构可以分为点对点的元数据

20、集成体系结构、中央辐射式元数据体系结构、基于CWM（Common Warehouse Meta Model，公共仓库元模型）模型驱动的点对点元数据集成体系结构、基于 CWM 模型驱动的中央存储库元数据集成体系结构、分布式（联邦式）元数据集成体系结构和层次/星型元数据集成体系结构等。针对信息供应链中不同的组件，为了实现跨组件的元数据交换和集成，最开始人们采用点对点的方式进行，也就是每一对组件之间通过一个独立的元数据桥（metadata bridge）进行元数据交换，桥一般是双向的能够理解两个方向的元数据映射4。点对点的元数据集成体系结构帮助用户实现了跨企业的元数据集成和元数据交换，对提升信息化水

21、平提供了巨大帮助。这种体系结构在应用过程中，也暴露了很多问题，比如元数据桥的构建工作量和耗时都非常大，对中间件厂商、应用厂商、集成商和用户来说都是一个巨大的挑战，而且构建元数据桥还必须具有所有者的元数据模型和接口的详细信息。构建完成的桥很多时候无法在构建其他元数据桥时进行重用，因此开发和维护费用大幅度增加，用户投资回报率（ROI）不高。以动态数据仓库为例，其点对点的元数据集成体系结构具体如图 4 所示，信息供应链各组件之间的空心箭头表示全部的数据流，实心箭头表示不同的元数据桥和与之关联的元数据流。图 4 点对点的元数据集成体系结构通过使用中央元数据存储库（central metadata re

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

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

24、体系结构如图 7 所示，在基于模型驱动（比如 CWM）的中央辐射式元数据体系结构中，中央存储库包含公共元模型和整个领域（domain）用到的该元模型的各个实例（模型） 、存储库自身元模型及其实例、理解元模型（公共元模型和自身元模型）的适配器层，当然存储库也可以直接实现公共元模型的某些内部表示。图 7 基于 CWM 模型驱动的中央存储库元数据集成体系结构如图 8 所示，这种体系架构是基于 CWM 模型驱动的中央存储库元数据集成体系结构的一个变种，两个中央辐射式的拓扑结构通过各自的元数据存储库连接起来，也被称为分布式（Distributed ）或联邦（ Federated）体系结构。两个元数据存储

25、库之间通过元数据桥连接，两个存储库使用相同的元模型和接口，也可以使用不同的元模型和接口。建立分布式元数据集成体系结构的原因有很多种，比如企业基于多个区域单独部署自己的应用，每个区域有自己的数据中心。图 8 分布式（联邦式）元数据集成体系结构如图 9 所示，这种体系结构是分布式体系结构的变体，根存储库实现了元模型的公共部分（横跨整个企业） ，叶子存储库实现了一个或多个特定的公共元模型子集，并只保存这些自己所对应的元数据实例。特定客户可以主要访问其感兴趣的元数据所在的叶子存储库，也可以访问其它叶子存储库和根存储库。这种体系结构被称为层次或星型拓扑结构。图 9 层次或星型元数据集成体系结构结束语本文

26、详细介绍了大数据治理的基本概念和统一流程参考模型，并阐述了该模型的第一步“ 明确元数据管理策略” 和第二步“元数据集成体系结构” 等内容。在第一步“明确元数据管理策略”中讲述了元数据的基本概念以及本体在人工智能/计算机科学和哲学中的含义。在第二步“ 元数据集成体系结构”讲述了元数据集成体系结构的六种示例，分别为：点对点的元数据集成体系结构、中央辐射式元数据体系结构、基于 CWM 模型驱动的点对点元数据集成体系结构、基于 CWM 模型驱动的中央存储库元数据集成体系结构、分布式（联邦式）元数据集成体系结构和层次/星型元数据集成体系结构。在本系列文章的下一部分将继续介绍大数据治理统一流程参考模型第二

27、步“元数据集成体系结构” ，具体包括元模型、元- 元模型、公共仓库元模型（ CWM） 、CWM 发展史、OMG 的模型驱动体系结构（ModelDrivenArchitecture，MDA） 。参考文献1 David Frankel Consulting,”Using Mode lDriven Architectureto Manage Metadata”,P3;2 Fredrik Arvidssonand Annika Flycht-Eriksson,2008,OntologiesI,”Anontology provide a share dvocabulary,which can be us

28、ed to modela domain,that is,the type of objects and/or concepts that exist,and their properties and relations”;3 更多内容请参考:专著 /(英)伯特兰. 罗素/ 著孙绍武/主编;4 John Poole,Dan Chang,Douglas Tolbertand David Mellor,2002,Common Warehouse Metamodel,p18-32,p180-202;5 本系列文章参考了 Sunil Soares 编写的The IBM Data Governance U

29、nified Process和 Big data Governance书中内容第二部分：元数据集成体系结构在明确了元数据管理策略后需要确定实现该管理策略所需的技术体系结构，即元数据集成体系结构。元数据集成体系结构涉及到多个概念，如元模型、元-元模型、公共仓库元模型（CWM）等，本部分将继续介绍大数据治理统一流程参考模型第二步“ 元数据集成体系结构” 的相关内容。在本系列的第一篇文章中，我们主要介绍了大数据治理的基本概念和统一流程参考模型，并阐述了该模型的第一步“明确元数据管理策略”和第二步“元数据集成体系结构” 的六种示例等内容。大数据治理统一流程参考模型的第二步是“元数据集成体系结构 ”，具

30、体包括元模型、元 -元模型、公共仓库元模型（CWM） 、CWM 发展史、OMG 的模型驱动体系结构（Model Driven Architecture，MDA）本文将对元数据集成体系结构包含的各种模型展开叙述。大数据治理统一流程参考模型，第二步：元数据集成体系结构元模型（Meta model）模型（Model ）是用来描述特定的系统、过程、事物或概念的准确而抽象的表示。例如软件架构师可以用概要设计的形式建立一个应用系统的模型。本质上来说，元数据是数据的形式化模型，是数据的抽象描述，该描述准确地描述了数据。元模型（Meta model）也就是模型的模型（或者元- 元数据） ，是用来描述元数据的模

31、型。下面基于关系型表实体-关系（ ER）模型举例说明什么是元模型。如图 1 所示，一个简单的关系型表元模型描述了如何定义一个关系型表，规定了每个表必须有一个名字（字符串） ，一个表可以有 1 到多个列，每个列必须有一个名字（字符串）和数据类型（字符串）：图 1 简单关系型表元模型如果要创建一个关系型表模型，基于该表元模型创建一个实例即可，比如创建一个常见的雇员表 Employees 表模型，具体如图 2 所示，Employees 表包含6 个列，分别是编号、姓、名字、部门编号、经理编号和职位编号。图 2Employees 表实例比如在 DB2 中创建 employees 表，可以很容易的从 e

32、mployees 表模型中得到相应的 DDL 语句，执行 DDL 语句时 DB2 会生成描述 employees 表的内部元数据并存储在目录（DB2 内部的元数据存储库）中。清单 1 在 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)同样基于图 1 简

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

34、型，也就是导出映射（export mapping） ，以便其他软件使用其专有的元数据。这种基于公共元模型的集成方法就是模型驱动的元数据集成体系结构1。图 3 department 表实例元-元模型（ Meta-meta model）元-元模型就是元模型的模型，有时也被称为本体（ontology ） ，是模型驱动的元数据集成体系结构的基础，其定义了描述元模型的语言，规定元模型必须依照一定的形式化规则来建立，以便所有的软件工具都能够对其进行理解。元-元模型比元模型具有更高的抽象级别，一个元模型是一个元- 元模型的实例，元模型比元-元模型更加精细，而元 -元模型比元模型更加抽象。元数据（模型）则是一

35、个元模型的实例，遵守元模型的规定和约束。用户对象（或用户数据）则是元数据（或者称为模型）的实例。元数据层次结构具体如表 1 所示，共分为 4 层，最高层 L3 是元-元模型，之下是 L2 元模型和 L1 模型/元数据，最底层是 L0 用户对象/用户数据：表 1 元数据层次结构元层次 名称 示例L3 元-元模型 元类、元属性、元操作L2 元模型 类、属性、操作、构件L1 模型 /元数据 实体-关系（ER）图L0 用户对 象/用户数据交易数据、ODS 数据、数据 仓库数据、数据集市数据、数据中心数据等公共仓库元模型（CWM）概述公共仓库元模型（Common Warehouse MetaModel，

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

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

38、package）和实例包（ Instance package） 。 数据源层（Data Resources）：主要描述 CWM 元数据交换中既可作为源又可以作为目标的数据源的结构，本层含有的元模型主要描述面向对象的数据库和应用、关系型数据库、面向记录的数据源（如文件、记录数据库管理系统等） 、多维数据库和 XML 数据源等。对于面向对象数据源， CWM 一般情况下重用基本的对象模型（位于对象模型层） ，如果该数据源具有对象模型层无法处理的一些特征和功能时，可以通过定义一个扩展包来解决。 数据分析层（Data Analysis）：本层含有的元模型主要描述数据转换、在线分析处理 OLAP、数据挖掘

39、、信息可视化和业务术语等。 仓库管理层（Warehouse Management）：本层含有的元模型主要描述数据仓库处理和数据仓库操作。图 4 CWM1.1 元模型CWM1.1 是在 2003 年 3 月发布的，与之相关的 OMG 组织规范还有MOF、 UML 和 XMI。CWM 使用统一建模语言（UML）定义公共元数据的模型（CWM 元模型） ，使用可扩展标记语言（XML）生成 CWM 元数据交换规范（也就是 XML 元数据交换， XMI） ，使用 CORBA 接口定义语言（IDL）为访问 CWM元数据生成编程语言 API 的规范（依赖 MOF 到 IDL 的映射） 。UML 是一种规范化、

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

41、（采用英语）来定义。UML 符号指定表达 UML 元模型语义的图形语法（例如类图） 。对象约束语言规范定义对象约束语言（OCL）的句法、语义和语法，OCL 是一种表述约束的形式化语言3 。 构造块和结构良好规则：UML 提供了组成构造块和结构良好规则的面向对象建模语言，基本的构造块包括模型元素（如类、对象、接口、组件、用例等） 、关系（如关联、泛化、依赖等）和图（如类图、对象图、用例图等）等。 UML 可以为一个系统进行不同方面的建模，比如结构建模（又包括使用类图和对象图的静态结构建模、使用组件图和部署图实现建模） 、用例建模和行为建模等。元数据建模只需要静态结构建模，静态结构的核心元素是类、

42、对象、属性和操作。 UML 用包来将模型元素组织成语义上相关联的分组，每个包拥有其自己的模型元素，每个模型元素不能同时被多个包拥有。UML 在 CWM 中主要作为三种角色出现4 ：1、UML 作为和 MOF 等价的元- 元模型。UML，或者部分对应 MOF 模型、UML 符号和 OCL 的 UML 分别被用作建模语言、图形符号和约束语言，用来定义和表示 CWM。2、UML 作为基础元模型。对象模型层（ObjectModel）与 UML 关系密切，是 UML 的一个子集。3、UML 用来作为面向对象元模型。元对象框架（Meta Object Framework，MOF ，本文以 2.4.1 版本

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

44、F 模型也是层次结构，并以包为单位进行组织。MOF 支持各种类型的元数据，采用四层元数据体系结构（也就是 OMG 元数据体系结构）5，具体如表 2 所示，该体系架构将元数据（M1 ）视同为数据（M0） ，并对之进行形式化建模（即元模型，M2 ） 。元模型（M2）使用元-元模型（M3）所提供的元建模结构来表示。表 2 表明 MOF 模型（元- 元模型） 、UML元模型、用户模型和用户对象/数据之间的关系。表 2 MOF 四层元数据体系结构描述 示例M3MOF,i.e. the set of constructs used to define metamodelsMOF Class,MOF Att

45、ribute,MOF Association,etc .M2Metamodels,consisting ofinstances of MOF constructs.UML Class,UMLAssociation,UML Attribute,UML State,UML Activity,etc.CWM Table,CWM Column,etc.M1Models,consisting of instancesof M2 metamodel constructs.Class“Customer”,Class“Account”Table “Employee”,Table“Vendor”,etc.M0O

46、bjects and data,i.e.instances of M1 modelconstructsCustomer Jane Smith,Customer Joe Jones,Account 2989,Account2344,Employee A3949,Vendor 78988,etc.XML 元数据交换（ XMI）是在工具软件、应用程序之间进行元数据交换的XML 语言，整合了 UML、MOF 和 XML 三种技术，允许 MOF 元数据（即遵从MOF 或基于 MOF 的元模型的元数据）以流或文件的形式按照 XML 的标准格式进行交换。XMI 是 OMG 在元数据交换方面的标准之一，同时也

47、是 W3C 认可的标准。本质上，XMI 是 W3C 的 XML 和 MOF 之间，以及 XML 文档和 MOF 元数据之间的一对平行映射。2011 年 8 月，XML 发布了 2.4.1。CWM 发展史其实早在上世纪 80 年代末 90 年代初，很多企业就尝试使用一种元模型实现元数据集成以整合分布于各个业务竖井中的元数据，但最终失败了，因为很多的利益相关者各自拥有不同的观点，且需要不同的模型结构。1997 年，OMG将 UML 采纳为标准，为 CWM 标准制定打下了第一个基础。同样在 1997 年，MOF 被 OMG 采纳为标准，为 CWM 的产生打下了第二个基础。1999 年初，OMG 采纳

48、 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 发展的同时，其他一些元数据标准的制定也在进行中。最早在199

49、3 年，电子信息组织就发布了计算机辅助工程数据交换格式（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 发布了 OIMv1.0 版本，由此业内面临着两种元数据集成规范的竞争局面，之后考虑到业内对 CWM 的认可，MDC 于 2000年 9 月决定终止其 OIM 后续工作，将其元数据标准归入到 OMG 中，从此 CWM影响力和范围持续扩大并得到了业内的统一认可。OMG 的模型驱动体系结构（Model Driven Architecture，MD