元数据管理
一、简介
元数据的定义是“关于数据的数据”,但是其确切含义是什么?元数据与数据的关系就像数据与自然界的关系。数据反映了真实世界的交易、事件、对象和关系,而元数据则反映了数据的交易、事件、对象和关系等。
元数据管理是关于元数据的创建、存储、整合与控制等一整套流程的集合,从而支持基于元数据的相关应用。
为了理解元数据在数据管理中的重要作业,可以用图书馆中的目录卡片做类比。通过目录卡片可以查询图书馆中保存了哪些书、在图书馆的什么位置。读者可以根据主题领域、作者或书名来查询书籍。此外,目录卡片还说明每一本书的作者、主题标签、出版日期和修订历史。目录卡片提供的信息有助于帮助读者确定哪些是他们需要的图书。如果没用目录卡片,在图书馆中查找书籍就像大海捞针一样困难,并耗费大量时间,最终让人沮丧,读者可能要找错很多次,才可能找到他想要的书。
与其他数据管理职能一样,元数据管理也可以用一幅关联图来表示。如图所示:
元数据管理的关联图对本章所介绍的职能进行了概要展示。元数据管理活动位于中间,周围是相关的环境因素。而该领域的关键概念位于图上方。
在组织中应用元数据管理能带来以下收益:
(1)通过数据的上下文关联信息,提升战略信息的价值,从而帮助分析人员作出更有效的决策。
(2)通过对数据上下文背景、历史和起源进行完整的记录并文档化,减少培训成本,降低员工流失的影响。
(3)帮助业务分析人员快速找到正确的信息,减少针对数据的研究时间。
(4)弥合业务用户和IT人员之间的分歧,方便团队间共享工作成果,提升用户对IT系统数据的信心。
(5)减少系统开发的生命周期,提升系统开发与投入运行的速度。
(6)在变更管理过程中的不同层面上进行更好的影响分析,降低项目失败风险。
(7)识别并减少冗余数据和流程,减少重复工作和对冗余、过期、不正确数据的使用。
二、概念和活动
元数据是一个受控的数据环境中的目录卡。抽象的说,在一个受控的数据环境中,元数据是描述数据的标签或数据的上下文背景。元数据为业务用户和技术用户展示了在哪里可以找到信息,还提供了有关数据从哪里来、如何到大此处、相关数据转换规则和数据质量的要求等详细信息,有助于理解数据的真实含义和对数据进行解释说明。
2.1 元数据定义
元数据是有关一个企业所使用的物理数据、技术和业务流程、数据规则和约束以及数据的物理与逻辑结构的信息。元数据是描述性标签,描述了数据(如数据库、数据元素、数据模型)、概念(如业务流程、应用系统、软件代码、技术架构)以及它们之间的联系/关系。
元数据是一个包含了许多潜在主题领域的广义术语,这些主题领域包括:
(1)业务分析:数据定义、报表、用户、使用方法和绩效。
(2)业务架构:角色和组织、目的和目标。
(3)业务定义:有关组织中的一个特定的概念、事实或其他事务的业务术语和解释。
(4)业务规则:标椎计算公式和衍生方法。
(5)数据治理:政策、标椎、程序、项目、角色、组织和管理职责安排。
(6)数据整合:数据源、数据目标、数据转换规则、数据血缘关系、ETL工作流、EAL、EII、迁移和变换。
(7)数据质量:缺陷、度量和评级。
(8)文档内容管理:非结构化数据、文档、术语分类、本体、命名集合、法律发现、搜索引擎索引。
(9)信息技术架构:平台、网络、配置和许可证。
(10)逻辑数据模型:实体、属性、关系和规则、业务名称和定义。
(11)物理数据模型:文件、表、列、视图、业务定义、索引使用、性能、变更管理。
(12)流程模型:职能、活动、角色、输入/输出、工作流、业务规则、定时、存储。
(13)系统群和IT治理:数据库、应用程序、项目和计划、整合路线图、变更管理。
(14)面向服务架构(SOA)信息:组件、服务、消息、主数据。
(15)系统设计和开发:需求、设计、测试计划、影响。
(16)系统管理:数据安全、许可证、配置、可靠性、服务水平。
2.1.1 元数据类型
总体上,元数据可分为4类:业务元数据、技术和操作元数据、流程元数据和数据管理制度元数据。
业务元数据包括了主题和概念领域、实体及属性的业务名称和业务定义,属性的数据类型和其他特性,范围描述,计算公式,算法和业务规则,以及有效值域及其定义。业务元数据把业务目标与元数据用户紧密关联起来了,业务元数据示例包括:
• 业务数据定义,包括计算公式。
• 业务规则和算法,包括层级。
• 数据血缘和影响分析。
• 数据模型——企业级概念模型和逻辑模型。
• 数据质量描述,如置信度和完整性指标。
• 数据管理制度信息和所属组织。
• 数据更新周期。
• 历史数据可用性。
• 历史的或替代的业务定义。
• 监管或合同约束。
• 报表和数据内容。
• 数据元素的记录系统。
• 有效值约束(取样或列表)。
技术和操作元数据为开发人员和技术用户提供了系统信息。技术元数据包括物理数据库表名和字段名、字段属性、其他数据库对象的属性和数据存储特性。数据库管理员需要了解用户的访问模式、访问频率和报表和查询的执行时间。通常可以通过DBMS内的程序或其他软件以获取技术元数据。
操作元数据主要用于满足IT运维用户的需求,它包括了数据迁移信息、数据源和目标系统信息,批处理程序、任务频率、调度异常处理、备份与恢复信息,归档规则和使用等信息。以下是技术和操作元数据的示例:
• 审计控制和损益信息。
• 数据的归档规则和保留规则。
• 编码转换/参照表变换规则。
• 抽取的历史和结果。
• 数据源系统字段标识。
• 从记录系统到目标数据存储系统(OLTP、OLAP)的映射、转换规则和统计信息。
• 物理数据模型,包括表名、键和索引。
• 程序任务依赖和调度信息。
• 程序名称和描述信息。
• 清洗规则。
• 备份与恢复规则。
• 数据模型和数据仓库/集市之间的映射关系。
• 填充目标数据存储(OLTP、 OLAP、SOA)的记录系统.
• 用户报表和查询访问模式、频率和执行时间。
• 版本维护。
流程元数据是定义和描述系统的其他元素(流程、业务规则,程序、任务、工具等)的特性的数据。流程元数据示例包括:
• 数据存储和所含数据。·管理/监管机构。
• 组织拥有人和利益相关者。
• 流程依赖和分解。
• 流程反馈文档。
• 流程名称。
• 流程顺序和计时。
• 由于输人差异或计时产生的流程变动信息。
• 角色和职责。
• 价值链活动。
数据管理制度元数据是关于数据管理专员、监管制度流程和责任分配的数据。数据管理专员确保数据和元数据在企业范围内是正确的并且是高质量的,他们建立数据的共享方式,并对其进行监控。数据管理制度元数据包括:
• 业务驱动力/目标。
• 数据 CRUD(增/删/改/查)规则。
• 数据定义——--业务定义和技术定义。数据拥有人。
• 数据共享规则和协议/合同。数据管理专员、角色和职责。
• 相关的数据存储和系统。数据主题域。
• 数据用户。
• 管理/监管机构。
• 治理组织架构和职责。
2.1.2 非结构化数据的元数据
在某种意义上,所有的数据都是结构化的,所以“非结构化元数据”的说法有些牵强。一种更合适的说法是:非结构化数据的元数据。尽管存取的实现方法不同,非结构化数据其实是高度结构化的。总体而言,不在数据库或数据文件中的数据都可以被认为是非结构化数据,包括文档或其他媒体数据。有关此内容请参见第10章。元数据描述了结构化数据和非结构化数据。根据不同的需求,非结构化数据的元数据有多种格式。描述非结构化信息的元数据存储库包括内容管理应用,大学网站、公司内部网站、数据档案、电子期刊和社区资源列表。对非结构化数据源的元数据进行分类的一种常用方法是将其描述为“描述性元数据、结构元数据或管理性元数据”。
描述性元数据示例包括:
• 目录信息。
• 同义关键词术语。
结构元数据示例包括:
• 都柏林核心元数据
• 字段结构。
• 特定的格式(音频/视图/手册)。
• 同义关键词标签。
• XML模式。
管理性元数据示例包括:
• 来源。
• 数据源整合/更新调度信息。
• 访问权限。
• 页面关系(如网站的导航设计)。
书目元数据、记录保留元数据和保存元数据都是应用于文档的元数据模式,但它们的侧重点有所不同。书目元数据是文档的图书馆目录卡。记录保留元数据关注有效性和保留期。保存元数据与存储、归档条件和材料保存有关。
2.1.3 元数据来源
可以说,在每一项数据管理活动中都含有元数据。任何数据的标识信息都是元数据,因为会有一些用户对其感兴趣。毋庸置疑,元数据是所有信息系统和应用必需的组成部分。使用这些元数据来源用于满足技术元数据需求。元数据的来源包括:
(1) 人们可以通过用户交互、定义和数据分析定义业务元数据。
(2) 通过某些维护支持活动可以将有关数据的质量描述和其他发现添加到元数据存储库中,或者从IT系统中获取元数据。
(3)可以在汇总层面(如主题领域、系统特性)或细节层面(如数据库列的特性和编码值)识别元数据。
(4) 对相关元数据的适当管理和在元数据之间导航是重要的使用需求。
元数据有许多主要来源,事实上,一个组织内部的任何可命名的事物都是一个元数据的主要来源。元数据的次要来源是指通过桥接软件来访问其他元数据存储库。许多数据管理工具创建并使用其自有的存储库,这些软件的供应商同时提供额外软件来把其他工具和元数据存储库连接起来,这些附属软件通常称为桥接应用。然而,此功能的主要意义是实现存储库之间的元数据复制,而不是真正意义上的连接。
2.2 元数据的历史(1990--2008)
到20.世纪90年代,一些业务管理人员最终意识到元数据存储库的价值,他们把业务元数据纳人到了新的软件工具中,从而扩大了其所处理的元数据的范围。在这个时期,业界意识到业务元数据带来的潜在价值包括:
• 在信息系统及其业务用户之间提供语义层,而这些系统包括操作型系统和商务智能系统。
• 减少培训成本。
• 通过辅助分析并做出更有利的决策,提升数据仓库、CRM,SCM 等战略性信息的价值。
• 创建对业务执行有参考价值的信息。
• 限制不正确的决策。
20世纪90年代中后期,一些公司受困于如何理解其信息资源,也意识到了元数据与公司信息系统间的相关性。这主要有以下几点原因:千年虫问题的到来、新兴的数据仓库技术和对于互联网与日俱增的关注。业界开始尝试进行元数据的标准化工作,包括元数据定义的标准化和企业内部应用之间的元数据交换的标准化。这些标准化工作包括:由电子行业联盟(EIA)于1995年开发的CASE定义交换设施(CDIF);由都柏林核心元数据倡议计划(DCMI)在俄亥俄州的都柏林开发的都柏林核心元数据元素;在1994年至1999年期间陆续发布的ISO11179的前期部分内容,用于对数据元素定义进行规范化和标准化。1998年,对象管理组织(OMG)开发了公共仓储元数据模型(CWM),与之相竞争的是,微软支持元数据联盟(MDC)在1995年发布的开放信息模型(OIM)。到 2000年,这两套标准已逐渐融合为CWM,众多元数据存储库开始承诺遵循CWM 标准。
21世纪早期,业界对已有的元数据存储库进行了升级,以便支持在互联网环境中的部署,这些产品同时也对CWM提供一定程度的支持。在这时期,许多数据整合工具厂商开始将元数据功能作为一种附加产品进行销售。然而,相对厂商而言,只有很少的企业实际采购或者开发了元数据存储库,因此实现CWM所定义的那种理想状态——企业范围内的有效管理的元数据环境——就成了奢望。这主要由于以下几点原因:
• 缺乏具有实际技能的人员。
• 工作量方面的困难。
• 一些公司的早期努力未获取明显的回报。
• 20世纪90年代后期元数据工具市场爆发性增长后,该市场一直处于停滞状态。
• 对于元数据业务价值的理解不够普遍。
• 业界过于强调遗留应用和技术元数据。
如今,企业开始更加关注对元数据的需求和元数据的重要性。关注范围也从传统的结构化数据的元数据扩展到非结构化数据源的元数据。对于元数据管理的重新关注主要由于以下一些原因:
• 一些大的软件供应商最近进人此市场。
• --些公司面临法律监管方面的问题,如萨班斯-奥克斯利法案,以及对简单工具的隐私保护要求。
·一些涉及整个企业范围的工作开始兴起,如信息治理、法规遵从、企业架构和自动化软件复用。
• 已有元数据标准的不断完善,如:OMG 发布了新的信息管理元模型(IMM,即CWM2.0)征求意见稿,此标准将替代 CWM标准。
• 一些领先公司和组织的高层开始意识到——信息是一种资产(特别是对某些公司而言,是最关键的资产),应该对信息进行主动且有效的管理。
元数据管理工具和产品的发展历史似乎暗示了企业和组织普遍都缺乏对企业信息管理的方法论支持。大部分元数据管理方案是私有的、缺少标准,这造成大量企业忽视了对元数据的关注,同时限制了企业开发一种真正意义上的企业信息管理环境的能力。企业越来越关注信息,关注信息对企业运营和决策的重要性,这将推动元数据管理产品和方案进一步标准化,也会提升信息管理方法论和元数据管理方法论的重要性的认可程度。
2.3 元数据战略
元数据战略是关于企业元数据管理目标的说明,同时也作为开发团队的参照框架。因每一类用户对于元数据应用都有一些特定的需求,所以遵循元数据需求开发流程可以清晰地理解用户对于元数据应用的预期及其需求产生的原因。
元数据战略是基于一系列定义好的组成部分建立起来的,其主要关注点是理解企业的关键业务驱动力,问题和信息需求并达成共识,从而开展企业元数据管理项目。目标在于理解当前环境是否能满足企业现在与未来的需求。
元数据战略的目标定义了企业未来的元数据架构,同时会建议一系列分阶段演进的实施步骤,以帮助企业实现未来愿景。它定义了满足业务目标所需的技术和流程。通过制定元数据战略的过程,企业会获得一份实施阶段清单,这份清单中的实施阶段是由业务目标驱动的并且对结果中的阶段排定了优先级:按照结果清单中各实施阶段对组织产生的业务价值大小,以及所需的资源投入多少进行综合排序。实施阶段包括:
(1)元数据战略启动和规划——确定元数据战略团队和相关参与人,从而为推动流程和提升效果做好准备工作,工作内容包括概述元数据战略的项目章程和元数据战略的工作组织,其中需要包括与数据治理工作如何协同,同时需要将工作目标与各相关方进行沟通。应该与来自业务和IT的相关者共同制定元数据战略,确定元数据战略的范围,沟通潜在的业务价值和目标。
(2)对主要的利益相关者进行访谈——访谈为元数据战略提供知识基础,通常对业务相关者和技术相关者都要进行访谈。
(3)评估现有元数据来源和信息架构----本阶段将对关键IT人员进行详细访谈,并评审系统架构,数据模型的相关文档。需要对访谈和评审结果中发现的元数据与系统的问题进行评估,确定解决这些问题的难度。
(4)开发未来的元数据架构——在此阶段会细化并最终确认未来愿景,为受控的元数据环境开发出长期的适用架构。本阶段将涉及元数据战略的全部组成部分,包括组织架构、有关如何与数据治理和监管制度保持协同的建议,受控的元数据架构,元数据交付架构,技术架构、安全架构等。
(5)开发分阶段的MME(受控的元数据环境)实施战略和计划-——对访谈和数据分析的结果进行评审,验证、整合、排定优先级并最终达成一致意见。开发元数据战略,包括分阶段的实施方法,此方法帮助组织从当前环境逐步实现未来的受控的元数据环境。
2.4 元数据管理活动
有效的元数据管理依赖于数据治理(参见第3章),需要业务数据管理专员来设定元数据管理优先级,指导项目投资,并从政府和行业监管的大背景下对实施工作进行监督。
2.4.1 理解元数据需求
元数据管理战略必须反映对企业元数据需求的理解,收集需求的目的包括:确认企业需要元数据管理环境,设定范围和优先级,教育和沟通,指导工具评估和实施,指导元数据建模,指导建立元数据内部标准,指导提供基于元数据的服务,以及预估和验证人员需求。元数据需求是通过与组织中的业务用户和技术用户进行沟通而获得的,并且对组织中特定人员的岗位角色,职责、挑战等进行分析可提炼出需求,而不是简单地询问用户的元数据需求。
1)业务用户需求
业务用户对来自于操作型系统和分析系统的信息需要加深理解,来自企业数据仓库、分析应用和操作型系统需要产生让业务用户可以高度信任的信息。他们还需要根据角色定制的信息提供方法,如报表、查询、推送(定期)、随机获取,OLAP,仪表盘等,同时还要附带高质量的文档和信息的上下文背景。
例如,业务术语“使用费”是由供应商制定的,计入零售商的付费金额中,并最终由消费者支付。这些数值在操作型系统和分析系统中存储为数据元素,他们会出现在关键的财务报表,OLAP立方体和数据挖掘模型中。在使用“使用费”数据时,就需要获得相关定义,使用方法和算法的信息。需要保密的或被认为与竞争对手有关“使用费”的任何信息,都需要采用用户组权限认证后才能使用。
业务用户需要理解元数据管理的意图和目的,为了给用户提供有意义的业务需求,需要让他们学习数据与元数据的区别。但是,如何让业务用户的关注点限定在元数据需求而非其他的数据需求则是一个挑战。与有相似岗位(如财务部门)的业务用户一起召开推动会(如访谈或JAD议程)是一种非常有效的确定元数据管理需求的方式,这种方式也有助于将用户的关注点聚焦于元数据需求和上下文背景需求中。
另外一个对元数据管理的成功至关重要的因素是建立数据治理组织。数据治理组织的职责是设定方向和目标,从而帮助企业对产品、供应商、技术架构和总体战略等方面制定更有效的决策。通常,数据治理委员会是企业数据和元数据管理的方向和需求的治理主体。
2)技术用户需求
宏观的技术需求主题包括:
• 每日数据处理流量——大小和处理时间。
• 现有元数据。
• 已知和未知数据源。
• 目标。
• 转换。
• 物理与逻辑架构流程。
• 非标准元数据需求。
技术用户包括数据库管理员(DBA),元数据专家、架构师、IT支持人员和开发人员。通常,这些人员是企业信息资产的监管人,他们必须完整地理解数据的技术实现,包括原子级的细节,数据整合点,接口和映射关系。此外,他们必须对数据的业务上下文背景有足够程度的理解,以便为业务用户所提出的需求提供必要的支持,包括实现计算过程或衍生的数据规则,以及实现数据整合程序。
2.4.2 定义元数据架构
从概念上来说,所有的元数据管理方案或元数据管理环境都包含如下架构层次:元数据创建/获取、元数据整合、一个或多个元数据存储库,元数据交付,元数据应用和元数据管理/控制。
元数据管理系统必须具备从多种元数据来源抽取元数据的能力,所设计的元数据架构需要能扫描各种元数据来源并定期更新元数据存储库。并且系统必须支持多用户组进行元数据手工更新、请求、搜索和查询。
一个受控的元数据环境应该为最终用户屏蔽元数据的位置、类型的差异,其架构应该为用户提供一个统一的元数据存储库访问人口。该入口需要透明地向用户提供所有相关元数据的资源。透明意味着用户可以访问元数据而不必关注各种元数据来源所处的不同环境。
设计以上所述的元数据架构取决于组织的特定需求。与设计数据仓库相似,建立公共元数据存储库通常有3种技术架构方法:集中式、分布式和混合式。这些方法都考虑了存储库的实施和更新机制如何运行。企业应根据需求选择最合适的架构。
1)集中式元数据架构
集中式架构包括一个单独的元数据存储库,在这里保存了来自各个元数据来源的最新元数据的副本。如果企业的IT资源有限,或者希望实现最大程度的自动化管理,可能需要考虑避免采用这种架构。为支持这些新的流程,需要对流程进行监控,并且设立一系列新的IT角色。如果企业高度重视元数据存储库的统一性和一致性,那么集中式架构将是个不错的选择。
集中式存储库的优势包括:
• 高可用性,因为其独立于元数据的来源系统。
• 快速查询元数据,因为存储库和查询整合于一体。
• 数据库结构经过解析,不受第三方系统或商业产品的私有性影响。
• 抽取过来的元数据可以进一步转换或附加其他元数据,生成来源系统中没有的元数据,从面提升质量。
集中式架构的一些局限包括:
• 需要复杂的流程来确保将元数据来源的变更快速复制到存储库中。
• 对集中式存储库的维护是至关重要的。
• 元数据抽取可能需要定制化的模块或中间件。
• 定制化开发代码的验证和维护会增加对内部IT人员和软件供应商的需求。
2)分布式元数据架构
一个完整的分布式架构只维护-一个单一访问点,元数据获取引擎响应用户的需求,从元数据来源系统实时获取元数据,而不存在永久的元数据存储库。在此架构中,元数据管理环境维护了所需的元数据来源系统目录和查询信息,从而有效地处理用户的查询和搜索请求。对元数据来源系统的访问是通过一个公共对象请求桥接器或类似的中间件协议实现的。
分布式元数据架构的优势包括:
• 元数据始终是最新且有效的。
• 分布式请求,可提升响应和处理时间。
• 来自局部系统的元数据请求只受限于查询处理,而不需要对私有数据结构的深入理解,所以降低了实施和维护所需的投入。
• 开发自动化元数据查询处理可能更简单,需要极少的人工参与。
• 减少了批量处理,不需要做元数据复制或同步。
分布式架构存在以下局限;
• 系统之间没有必要的元数据改进或标准化。
• 查询能力直接受制于相关元数据来源系统的可用性。
• 不能支持用户定义的或手工输入的元数据条目,因为没有可以用来存储这些内容的存储库。
3)混合元数据架构
一种折中的方案是混合架构。此架构中,元数据依然从元数据来源系统进人存储库。但存储库的设计只考虑用户增加的元数据、高度标准化的元数据以及手工获取的元数据。
该架构的好处是可以实现准时地获取元数据,以及提供更完善的元数据信息更好地满足元数据用户的需求。混合架构减少了IT 人工参与和访问私有系统所需的定制化开发功能。并能满足使用的及时性和有效性要求。但混合架构不能提升系统的可用性。
因为后端系统处理查询请求时是分布式的,所以元数据来源系统的可用性是一个限制。在把最终查询结果展现给用户之前,需要在中央存储库中将初始的查询结果与元数据参数相关联,这会带来额外的开销。
混合架构适用于有快速变更的元数据、需要元数据的统一和一致、并且元数据量和元数据来源数量都显著增长的组织。如果组织中更多是静态元数据和较小的元数据量增长,那么混合式架构对这样的组织可能不会有太大帮助。
另一种先进的架构是“双向元数据架构”,它允许元数据在架构中的任何部分(如元数据来源、ETL,用户接口等)发生变化,然后通过存储库反馈到初始的元数据来源,存储库充当了变更的桥接器。包含此类功能的商用套装软件正在开发中,同时,相关标准仍在制定之中。
此方案中的各种挑战是显而易见的。架构的设计要求元数据存储库包含元数据来源的最新版本,并且能够管理元数据来源的变更。必须对变更进行系统的捕获和解析,还要开发和维护一系列程序和流程接口,从而将存储库与元数据来源相连接。
2.4.3 开发和维护元数据标椎
元数据标准有两种主要类型:行业或共识标准,以及国际标准。总体而言,国际标准是制定和执行行业标准的基础框架。在DAMA国际的网站(www. dama.org)上,有一套元数据的动态标准:Ashcomp. com。图11.2的宏观框架图说明多套标准是如何关联的,在上下文背景或应用之中标准之间如何互相依赖。此图还展示了元数据标准的复杂度,可以将其作为元数据标准学习和探索的入门。
1)行业/共识元数据标准
理解行业元数据标准对于希望实施元数据管理、引进和使用适用的元数据方案的企业是至关重要的。元数据标准在与运营交易伙伴进行数据交换的领域非常关键,如:电子数据交换(EDI)格式是EDI工具中的早期元数据标准。许多公司意识到了与客户,供应商、合作伙伴和监管机构进行数据共享的价值,而信息共享需要公共元数据共享的支撑,因此这类需求产生了大量的领域元数据标准。
供应商们在其数据管理产品中支持XML以支持数据交换,并使用相同的策略将其工具与一系列解决方案相整合。包括数据整合,关系型和多维数据库﹑需求管理﹑商务智能报表、数据建模和业务规则在内的各种技术都提供了基于XML的元数据和数据的导人导出能力。对XML 的支持是重要的,但是由于缺少XML Schema标准,所以进行跨产品的元数据整合就变成了巨大的挑战。供应商维护其私有的XML Schema和文档类型定义(DTD),这些信息需要通过私有接口才能访问,所以将各种工具整合到元数据管理环境仍然需要定制化开发。
值得关注的行业元数据标准包括:
(1)OMG规范。OMG是一家由计算机领域的领先机构组成的非营利组织,致力于定义,推广,维护行业标准,以促进企业应用间的互操作。ORACLE、IBM、Unisys,NCR和其他很多公司都支持OMG,同时,OMG是CORBA 中间件标准的创造者,并定义了其他相关元数据标准,包括:
• 公共仓储元模型(CWM)—对数据仓库,商务智能、知识管理和门户技术等领域的元数据交换进行规范。CWM 基于UML实现,表现面向对象的数据结构。如图11.3所示,CWM包括多个组成部分。
• 信息管理元模型(IMM)——--IMM是CWM的下一代演迸模型,由OMG指导开发并于2009年发布。其目标是弥补面向对象﹑数据和XML之间的差距并包含cWM,提供从需求到类图的可追溯性(类图包括逻辑模型、物理模型),数据定义语言DDL和XMLSchema。
• MDC开放信息模型(OIM)—-一个中立的采用独立技术的元数据规范,覆盖操作型系统、数据仓库和知识管理环境的核心元数据类型。
• 可扩展标签语言(XML)-—基于MDC OIM模型进行元数据交换的标准格式。
• 统一建模语言(UML)-—-OIM的正式规范语言。
• 结构化查询语言(SQL)———OIM的查询语言。
• 扩展标签接口(XMI)—-简化了工具和存储库之间的元数据交换。XMI规范包括生成XML文件的规则,XML文件中包含实际的元数据和XML的数据类型定义(DTD)。
• 本体定义元模型(ODM)一—一定义了业务语义的正规表达、管理、互操作性和应用,用于支持OMG期望中的模型驱动的架构(MDA)。
(2)万维网协会(W3C)规范。W3C建立了资源描述框架(RDF),用于描述元数据和基于XML进行元数据交换。RDF主要关注获取互联网资源以及与URL相关联的其他资源。
(3)都柏林核心规范。都柏林核心元数据计划(DCMD)是一个非营利的论坛,目的是为各类业务和组织开发共同的可交互的在线元数据标准。其主要关注在线和网络资源元数据的标准化,同时也可用于从数据仓库和操作型系统中获取元数据。都柏林核心规范基于资源描述框架(RDF)。
(4)分布式管理任务组(DMTF):基于网络的企业管理(WBEM)是一组管理技术和互联网标准技术,目的是统一分布式计算环境的管理。它帮助企业获得交付易于整合的、基于标准的管理工具的能力,促进分散技术和系统之间的数据交换。组成WBEM的标准之一是公共信息模型(CIM)标准——WBEM的数据模型。CIM对系统,网络,应用和服务提供管理信息的公共定义,同时支持供应商扩展。
(5)非结构化数据的元数据标准包括:
• ISO 5964——Guidelines for the establishment and development of multilingual thesauri(多语种叙词表编辑和修订指南)。
• ISO 2788————Guidelines for the establishment and development of monolingual thesauri(单语种叙词表编辑和修订指南)。
• ANSI/NISO Z39.1——American Standard Reference Data and Arrangement ofPeriodicals(美国标准参照数据和期刊编排)。
• ISO 704——Terminology work—-principles and methods(术语工作原则与方法)。
(6)空间地理标准:起源于美国联邦地理图像数据委员会(FGDC)维护的全球空间数据基础架构。数字地理空间元数据的内容标准(CSDGM)是由FGDC管理的一项美国国家级计划,FGDC对如下内容进行严格要求,包括:数据票据清算所、空间数据标准,国家数字地理空间数据框架和数据获取合作关系。
(7)澳大利亚新西兰土地信息委员会(ANZLIC)为“ISO19115:2003地理信息:元数据”和“ISO 19139:2003地理信息:元数据实施规范”提供了重要的信息。
(8)在欧洲,地理元数据标准主要依靠INSPIRE(欧洲空间信息基础架构)委员会的工作。
(9)根据各行业和领域的需求和具体问题,提出了面向领域元数据标准。下面提供了两个领域标准的示例:
• 汽车行业。现代车辆识别号码系统基于两个相关标准——ISO 3779和ISO 3780,定义了17位唯一编号。17位号码的每一位都有特定的含义和有效值域范围。同时,还存在一个变体的欧洲版本。
• 电力事业行业。事业公共信息模型(CIM)是一套数据交换结构标准,用于电力信息共享,包括一个消息总线,和北美公共事业之间的数据访问公共规范。电力研究委员会支持事业公共信息模型。
基于OMG的标准,模型驱动架构(MDA)将业务和应用逻辑从平台技术中分离。可以使用UML 和MOF(元对象设施)技术标准在几乎任何平台上实现应用或系统的业务功能和行为的模型,此模型与平台是独立的。在此架构方法下,各应用供应商需要遵循统一框架,此框架保障应用实施的灵活性,因此产品也能满足各类市场需求。MDA对组织实施特定软件包的应用直接影响较小。
进行元数据方案实施规划的组织应该在规划前期采用已被业界认可,面向行业特定需要的元数据标准。使用已采纳的标准用于评估,并作为选择所有元数据管理新技术的原则。许多领先的供应商的产品都支持多种元数据标准,有一些可以帮助制定行业基础或领域相关的标准。
2)国际元数据标准
一-项主要的国际元数据标准是国际标准组织(ISO)发布的ISO/IEC 11179,主要描述了数据元素的标准化和注册,从而提高数据的可理解性与可共享性。
ISO/IEC 11179的目的是为分散的数据元素描述和语义内容(元数据)的规格化和维护提供指引,从而以标准和统一的方式对数据元素进行定义。
对于行业工具开发商来说,此标准有重要的指导作用,然而对于那些希望使用商业工具的企业,他们却不是十分在意,因为工具本身必然要满足此标准。尽管如此,因为ISO/IEC11179标准对所覆盖的每个主题都提供了十分详细内容,所以对于希望建立内部数据标准的企业来说,此标准应该有所帮助。
ISO/IEC 11179标准包括如下相关内容。
• 第1部分——数据元素的规范和标准化。
• 第2部分——数据元素的分类。
• 第3部分——数据元素的基础属性。
• 第4部分——数据定义的表达规则和指引。
·第5部分—数据元素的命名和标识原则。
• 第6部分——数据元素的注册。
2.4.4 标椎化元数据的评估指标
为控制环境中所实施的元数据的有效性,应对量化评估用户的理解,组织的投入以及内容的覆盖度和质量。评估指标主要应采取定量指标而非定性指标。
元数据环境中建议采用的评估标准包括:
• 元数据存储库的完整性——将理想状态下企业元数据的覆盖度(范围内的全部交付物和实例)与实际覆盖度进行比较。可参考战略部分的范围定义。
• 元数据文档的质量——通过自动化方法和人工方法评估元数据文档的质量。自动化方法包括对某两个元数据来源执行冲突检测,判断其匹配程度和随时间变化的趋势。另一个评估指标是度量具有定义的属性的百分比及其随时间变化的趋势。人工方法是指依据企业对于质量的定义而采用随机或完整的调查。质量度量指示了存储库中的元数据的完整性,可靠性,及时性等质量特性。
• 主数据服务数据合规性—说明SOA方案中数据的复用程度。数据服务的元数据辅助开发人员决定何时可以采用已有服务来完成新的开发。
• 管理职责/范围——对元数据管理的组织承诺评估手段是通过任命数据管理专员,建立企业范围内的管理制度,并对相关岗位的角色职责文档化。
• 元数据的使用/引用——用户对元数据存储库的使用情况,可以通过简单的统计访问量测量出来。用户在实际业务工作中对元数据的引用情况﹐相对难以跟踪度量。为评估此方面的情况,可以采用定性的访谈调查收集相关场景。
• 元数据管理成熟度——用于评估企业元数据成熟度的一系列指标,基于能力成熟度模型(CMM)的方法进行成熟度评估。
• 元数据存储库可用性——在线时间、处理时间(包括批处理和查询)。
2.4.5 实现受控的元数据环境
为减小风险并提高被接受的程度,一般通过分步推进的方式实现一个受控的元数据环境。
通常,首先会实施一个试验项目来理解受管理的元数据环境并进行概念验证。一个试验项目应具有一定的复杂度,包括需求评估、战略制定、技术评估选型和初始实施周期,这些都是后续项目中没有的工作内容。后续项目中包含路线图规划、人员培训,组织变革和一个后续发布计划,其中根据需要进行评估和再评估的工作。此外,有必要将元数据项目与信息系统/信息技术开发方法论相整合。
元数据管理的沟通和规划工作主要内容是对战略、规划、实施方案的讨论和决策,包括:
• 企业信息管理。
• 数据治理。
• 主数据管理。
• 数据质量管理。
• 数据架构。
• 内容管理。
• 商务智能/数据仓库。
• 企业数据建模。
• 元数据访问和分发。
2.4.6 创建和维护元数据
使用元数据管理的套装软件意味着不需要开发存储库的数据模型,但可能需要根据企业需求进行调整。如果需要开发一套定制化方案,那么制定完元数据战略、完全理解了业务需求之后,应该进行存储库的数据模型设计。
添加元数据等操作可以由授权用户和程序以手工方式完成,也可以通过元数据创建和更新的工具定期扫描和更新存储库。最后需要采用审计流程以验证各项操作活动并报告异常。
企业将元数据视为数据的索引,因此元数据的质量是至关重要的。如果企业数据源存在不规则的数据并且可以通过元数据体现这些不规则性,那么元数据就可以辅助用户更好地理解这些复杂的数据。而对于元数据质量的质疑可能会导致对整个元数据方案的否定,并影响后续与元数据相关的工作。因此,在元数据的迁移和整合之外,管理好元数据的质量也是非常重要的。由于质量是主观性的,需要让业务人员参与,以他们的视角共同定义质量的组成。
低质量元数据会导致:
• 重复的数据字典/存储库/元数据存储。
• 不一致的元数据。
• 元数据的来源和版本有冲突——意味着不一致的“真相”。
• 对元数据系统可靠性的质疑。
高质量的元数据会带来:
• 在企业层面的信心。
• 对于数据资源的价值的一致理解。
• 企业范围内的元数据———即知识。
2.4.7 整合元数据
元数据整合过程是在企业范围内采集并存储元数据的过程,也包括企业外部数据的元数据。把元数据来源库中抽取到的元数据,与相关的业务元数据和技术元数据进行整合,最终存储到元数据存储库中。元数据的抽取有多种方式:可以使用适配程序、扫描程序、桥接程序或者直接访问数据存储中的元数据。许多第三方软件工具和元数据整合工具都提供适配程序。有些情况下,需要通过工具的 API来开发适配程序。
元数据整合过程中可能存在一些挑战,也可能需要诉诸于数据治理流程进行协调解决,例如:在对内部数据集、外部数据(如道琼斯数据或政府统计数据)、非电子形式数据(如白皮书、杂志文章或报表)进行整合时,可能会出现大量的质量和与语义方面的问题。
对元数据存储库的扫描有如下两种不同的方式。
(1)私有接口:采用单步方式,扫描程序从来源系统中扫描和装载,以采集元数据,并直接调用与元数据格式相关的装载程序,将元数据装载到元数据存储中。在此过程中,不需要输出任何中间元数据文件,元数据的采集和装裁也是一步完成的。
(2)半私有接口:采用两步方式,扫描程序从来源系统中采集元数据,并且输出到特定格式的数据文件中。扫描程序只产生目标存储库能够正确读取和装载的数据文件。可以通过多种方式读取生成的数据文件,所以这种接口的架构更加开放。在此过程中,扫描程序产生和使用多种类型文件:
• 控制文件——包含了数据模型的数据源结构信息。
• 重用文件一-包含了管理装载流程的重用规则信息。
• 日志文件——在流程的每一阶段、每次扫描或抽取操作生成的日志。
• 临时和备份文件——在流程中使用或做追溯流程所使用的文件。
可以使用一个非持久的元数据暂存区(Staging Area)进行临时和备份文件的存储。暂存区应支持回滚和恢复流程,并且提供中间审计跟踪信息,这样有助于存储库管理员追踪元数据来源或质量问题。暂存区可以采用文件目录的方式或数据库。在新的元数据源使用缓冲表之前,应对已有暂存区数据表进行截断﹐或者对相同的存储格式打时间差标明版本。通常可以使用数据仓库和商务智能工具的数据提取、转换与加载工具进行有效的元数据整合。
2.4.8 管理元数据存储库
为了管理元数据环境,需要采取一些控制措施。对存储库的控制意味着对元数据技术人员执行的元数据迁移和存储库更新活动进行控制。这些措施的本质是管理性的,包括监视、响应报告、告警、任务日志和解决存储库环境中的各类问题。数据操作和接口维护需要以控制措施为标准。
这些控制手段包括:
• 备份、恢复、归档、清洗。
• 变更配置。
• 对用户和数据管理专员的培训。
• 任务调度/监视。
• 装载统计分析。
• 生成管理指标和分析。
• 性能调优。
• 质量保障、质量控制。
·查询统计分析。
• 生成查询/报告。
• 存储库管理。
• 安全管理。
• 源映射/迁移。
• 提供控制措施及查询/报告的培训。
• 用户界面管理。
• 版本记录。
1)元数据存储库
元数据存储库是指存储元数据的物理数据库表,通常采用开放标准的关系型数据库平台实现元数据存储库,因此即便在开发元数据存储库的项目初期没有考虑到,也可以后续开发出各种控制和接口程序。
存储库的内容在设计上应该是通用的,而不是仅仅反映来源系统的数据库设计,并需要综合考虑企业主题域专家的意见,同时基于一个易于理解的元数据模型。应当尽可能实现元数据的整合一这是存储库最有直接价值的工作。存储库应当存储当前的、计划中的和历史版本的元数据。
例如,“客户”的业务元数据定义可能是一任何通过店面或目录购买了我公司产品的人员。一年之后,公司增加了新的分销渠道,建立了网站,客户可以订购商品。此时,“客户”的业务元数据的定义应该变为—--任何通过我公司的店面、邮寄目录或网站购买了我公司产品的人员。
2)目录,术语表和其他元数据存储
目录是一类元数据存储,它将元数据限制在特定位置或数据来源。可以为来源系统打标签标记为记录系统(如使用“gold”符号作为标记可能更有用)或其他质量水平。应在目录中指明多个来源。元数据目录对于开发人员、数据超级用户(如数据监管团队)和数据分析师尤其有用。
术语表通常提供术语使用的指引,同义词可以指导用户完成包括3类关系的结构化选择,关系类型包括相等、层级和关联。可以为“术语表内”和“术语表间”的两个术语之间指定这些关系类型。这些术语还可以和存储在元数据存储库的其他类型的元数据建立关系,从而一起提升可用性。一个多来源的术语表可以:
• 存储来自多个来源的业务术语和定义。
• 展示一个单一数据来源内的多个术语之间的关系。
• 建立一个足够灵活的架构,支持存储多个数据源中的输入并将新术语和已有术语建立关系。
• 连接到元数据存储库中所记录的全部的元数据属性集合。
其他元数据存储包括专用列表如来源列表或接口,代码集、专业词汇、空间和时间模式、空间参照、数字地理数据集、存储库和业务规则等。
2.4.9 分发和交付元数据
元数据交付层负责将元数据从存储库分发到最终用户和其他需要使用元数据的应用或工具。
一些常用的交付机制包括:
• 元数据内网,提供浏览、查询、搜索、报告和分析功能。·报告、术语表、其他文档及网站。
• 数据仓库、数据集市和商务智能工具。
• 建模和软件开发工具。
• 消息传输交换。
• 应用程序。
• 外部组织接口方案(如供应链方案)。
元数据方案通常与商务智能方案相连接,所以元数据方案中涵盖的元数据内容以及元数据的时效性会与商务智能内容同步。可以通过元数据与商务智能之间的连接作为将元数据整合到商务智能的交付方案,并提供给最终用户使用。与此相似,一些CRM或ERP方案可能也需要在应用交付层整合元数据信息。有时可能需要通过文件方式将元数据与外部组织进行交互,比较常见的是使用XML作为传输格式,在私有方案之间进行元数据交互。
2.4.10 查询、报告和分析元数据
元数据指导我们如何使用数据资产:我们在商务智能(报表和分析)、商业决策(操作型,运营型和战略型)以及业务语义(业务所述内容及其含义)方面使用元数据。
元数据指导我们如何管理数据资产:在数据治理流程中使用元数据进行控制和治理;信息系统实现和传送过程中会使用元数据来增加、变更、删除和访问数据;数据整合(操作型系统,数据仓库/商务智能系统)通过数据的标签或元数据实现数据整合。元数据控制并审计数据,流程和系统整合:正如系统和数据安全管理一样,数据库管理也是通过数据的标签或元数据层进行数据控制和维护的;一些质量提升活动通常是从对元数据及元数据与数据的关系进行检查而开始的。
元数据存储库应该具有前端应用程序,并支持查询和获取功能,从而满足以上各类数据资产管理的需要。提供给业务用户的应用界面和功能与提供给技术用户和开发人员的界面和功能有所不同,后者可能会包括有助于新功能开发的变更影响分析,或有助于解决数据仓库和商务智能项目中数据定义问题的血缘关系分析报告。
三、综述
在组织中实施元数据管理的指导原则、每一个元数据管理活动相关角色的总结表,以及在元数据管理中可能出现的组织和文化问题,总结如下。
3.1 指导原则
建立元数据管理职能的指导原则如下所示。
(1)建立和保持一套元数据战略和相关政策,特别是有关元数据管理和使用方面的清晰目标和目的。
(2)需要来自于高层管理者的对企业元数据管理的持续可靠承诺、资金支持和宣传方面的支持。
(3)从企业全局着眼规划,确保可扩展性;同时采取迭代和渐进交付的实现方案。
(4)在评估、采购和安装元数据产品之前,制定元数据战略。
(5)建立或采用元数据标准,确保在企业范围内元数据的互操作性。
(6)确保对内部和外部元数据的有效获取。
(7)最大化的用户访问,因为没有使用或使用率较低的方案无法体现业务价值。
(8)理解和沟通元数据的必要性和每一类元数据的目的;传播元数据的价值,促进业务使用。
(9)评估元数据内容和使用情况。
(10)采用XML、消息和Web服务等技术手段。
(11)建立数据监管制度,并保持业务人员对该制度的参与,赋予元数据管理责任。
(12) 定义操作程序和流程并进行监控,确保政策执行的正确性。
(13) 关注角色、人员、标准、操作程序、培训和评估指标。
(14)为项目和后续管理提供专职的元数据专家。
(15)认证元数据的质量。
3.2 过程总结
元数据管理职能的过程总结如表11.1所示,表中列举了元数据管理每一项活动的交付物、负责角色.批准角色和贡献角色。此表也在附录A.9中体现。
3.3 组织和文化问题
元数据管理工作中存在许多组织和文化问题,组织的准备与完善程度是一项关键考虑因素,同样也要考虑治理和控制的方法。
Q1:元数据管理在许多组织中优先级较低。能够体现元数据管理核心价值的工作是什么?
有一部分元数据特别需要在组织中协调一致。这些元数据可以是员工身份数据、保险号码、车牌号码或产品规格等,如果这些数据产生变更,将对企业内的许多系统产生极大影响。在某些领域进行管控可以立即获得数据质量方面的收益,这些领域就是体现元数据管理价值的最好的实例。需要在与业务相关的具体实例中体现元数据的价值。
Q2:元数据管理与数据治理是如何相关联的?可以通过元数据的规则治理元数据吗?
是的。元数据和其他数据--样,可以通过原则、政策和积极有效的监管制度进行治理。
文末说明:参考书籍来自《DAMA数据管理知识体系指南》