DAMA数据管理知识体系指南》12—第12章 元数据管理 知识点记录

第12章 元数据管理

12.1 引言

1.元数据最常见的定义是“关于数据的数据”。这个定义非常简单，但也容易引起误解。可以归类为元数据的信息范围很广，不仅包括技术和业务流程、数据规则和约束，还包括逻辑数据结构与物理数据结构等。它描述了数据本身（如数据库、数据元素、数据模型），数据表示的概念（如业务流程、应用系统、软件代码、技术基础设施），数据与概念之间的联系（关系）。元数据可以帮助组织理解其自身的数据、系统和流程，同时帮助用户评估数据质量，对数据库与其他应用程序的管理来说是不可或缺的。它有助于处理、维护、集成、保护和治理其他数据。
为了理解元数据在数据管理中的重要作用，试想一个大型图书馆中有成千上万的书籍和杂志，但是没有目录卡片。没有目录卡片，读者将不知道如何寻找一本特定的书籍甚至一个特定的主题。目录卡片不仅提供了必要的信息（图书馆拥有哪些书籍和资料以及它们被存放在哪里），还帮助读者可以使用不同的方式（主题领域、作者或者书名）来查找资料。如果没有目录，寻找一本特定的书将是一件十分困难的事情。一个组织没有元数据，就如同一个图书馆没有目录卡片。
元数据对于数据管理和数据使用来说都是必不可少的（参阅DAMA-DMBOK中对元数据的多处引用）。所有大型组织都会产生和使用大量的数据，在整个组织中，不同的人拥有不同层面的数据知识，但没有人知道关于数据的一切。因此，必须将这些信息记录下来，否则组织可能会丢失关于自身的宝贵知识。元数据管理提供了获取和管理组织数据的主要方法。
然而，元数据管理不仅是知识管理面临的一个挑战，还是风险管理的一个必要条件。元数据可以确保组织识别私有的或敏感的数据，能够管理数据的生命周期，以实现自身利益，满足合规要求，并减少风险敞口。
如果没有可靠的元数据，组织就不知道它拥有什么数据、数据表示什么、数据来自何处、它如何在系统中流转，谁有权访问它，或者对于数据保持高质量的意义。如果没有元数据，组织就不能将其数据作为资产进行管理。实际上，如果没有元数据，组织可能根本无法管理其数据。
随着技术的发展，数据产生的速度也在加快，技术元数据已经成为数据迁移和集成方法中不可或缺的一部分。ISO的元数据注册标准ISO/IEC 11179旨在基于精确数据定义，在异构环境中实现以元数据为驱动的数据交换。使用数据时，元数据需要以XML或其他格式呈现，其他类型的元数据要求在基于保留所有权、安全要求等属性的基础上进行数据交换（参见第8章）。
与其他数据一样，元数据需要管理。随着组织收集和存储数据能力的提升，元数据在数据管理中的作用变得越来越重要。要实现数据驱动，组织必须先实现元数据驱动。
2.元数据语境关系图如图12-1所示。

图12-1 语境关系图：元数据
12.1.1 业务驱动因素
3.数据管理需要元数据，元数据本身也需要管理，可靠且良好管理元数据有助于：
1）通过提供上下文语境和执行数据质量检查提高数据的可信度。
2）通过扩展用途增加战略信息（如主数据）的价值。
3）通过识别冗余数据和流程提高运营效率。
4）防止使用过时或不正确的数据。
5）减少数据的研究时间。
6）改善数据使用者和IT专业人员之间的沟通。
7）创建准确的影响分析，从而降低项目失败的风险。
8）通过缩短系统开发生命周期时间缩短产品上市时间。
9）通过全面记录数据背景、历史和来源降低培训成本和员工流动的影响。
10）满足监管合规。
元数据有助于采用一致的方式表示信息、简化工作流程以及保护敏感信息，尤其是在已有监管合规要求的情况下。
如果组织的数据质量很高，那么组织可以从数据资产中获得更多价值。高质量的数据和数据治理工作密切相关，因为元数据解释了使组织能够运行的数据和流程，所以元数据对于数据治理至关重要。如果说元数据是组织中数据管理的指南，那么必须妥善管理元数据。
4.元数据管理不善容易导致以下问题：
1）冗余的数据和数据管理流程。
2）重复和冗余的字典、存储库和其他元数据存储。
3）不一致的数据元素定义和与数据滥用的相关风险。
4）元数据的不同版本相互矛盾且有冲突，降低了数据使用者的信心。
5）怀疑元数据和数据的可靠性。
良好的元数据管理工作，可以确保对数据资源的一致理解和更加高效的跨组织开发使用。

12.1.2 目标和原则

5.元数据管理的目标包括：
1）记录和管理与数据相关的业务术语的知识体系，以确保人们理解和使用数据内容的一致性。
2）收集和整合来自不同来源的元数据，以确保人们了解来自组织不同部门的数据之间的相似与差异。
3）确保元数据的质量、一致性、及时性和安全。
4）提供标准途径，使元数据使用者（人员、系统和流程）可以访问元数据。
5）推广或强制使用技术元数据标准，以实现数据交换。

6.成功实施元数据解决方案应遵循以下指导原则：
1）组织承诺。确保组织对元数据管理的承诺（高级管理层的支持和资金），将元数据管理作为企业整体战略的一部分，将数据作为企业资产进行管理。
2）战略。制定元数据战略，考虑如何创建、维护、集成和访问元数据。战略能推动需求，这些需求应在评估、购买和安装元数据管理产品之前定义。元数据战略必须与业务优先级保持一致。
3）企业视角。从企业视角确保未来的可扩展性，但是要通过迭代和增量交付来实现，以带来价值。
4）潜移默化。宣导元数据的必要性和每种元数据的用途；潜移默化其价值将鼓励业务使用元数据，同时也为业务提供知识辅助。
5）访问。确保员工了解如何访问和使用元数据。
6）质量。认识到元数据通常是通过现有流程（数据建模、SDLC、业务流程定义）生成的，所以流程所有者应对元数据的质量负责。
7）审计。制定、实施和审核元数据标准，以简化元数据的集成和使用。
8）改进。创建反馈机制，以便数据使用者可以将错误的或过时的元数据反馈给元数据管理团队。

12.1.3 基本概念

1.元数据与数据

如在简介中所述，元数据也是一种数据，应该用数据管理的方式进行管理。一些组织面临的一个问题是，如何在元数据和非元数据之间划分界限。从概念上讲，这条边界与数据所代表的抽象级别有关。例如，在报告美国国家安全局对美国人使用电话的监控情况时，电话号码和通话时间通常被称为“元数据”，这意味着“真实”数据只包括电话交谈的内容，常识是电话号码和通话时间也只是普通数据。
从经验来说，一个人的元数据，可能是另一个人的数据。即使是看似元数据的东西（如一列字段名称），也可能是普通数据。例如，该数据可以作为输入，满足多个不同组织理解数据和分析数据的需求。
为了管理元数据，组织不应该担心理论上的区别，相反他们应该定义元数据需求，重点关注元数据能用来做什么（创建新数据、了解现有数据、实现系统之间的流转、访问数据、共享数据）和满足这些需求的源数据。

2.元数据的类型

7.元数据通常分为三种类型：业务元数据、技术元数据和操作元数据。这些类别使人们能够理解属于元数据总体框架下的信息范围，以及元数据的产生过程。也就是说，这些类别也可能导致混淆，特别是当人们对一组元数据属于哪个类别或应该由谁使用这个类别产生疑问时。最好是根据数据的来源而不是使用方式来考虑这些类别。就使用而言，元数据不同类型之间的区别并不严格，技术和操作人员既可以使用“业务”元数据，也可以使用其他类型元数据。
8.在信息技术之外的领域，如在图书馆或信息科学中，元数据被描述为不同的类别：
1）描述元数据（Descriptive Metadata）。描述资源并支持识别和检索，如标题、作者和主题等。
2）结构元数据（Structural Metadata）。描述资源及其组成组件之间的关系，如页数、章节等。
3）管理元数据（Administrative Metadata）。用于描述管理生命周期的元数据，如版本号、存档日期等。
这些类别有助于了解定义元数据需求的过程。

（1）业务元数据

9.业务元数据（Business Metadata）主要关注数据的内容和条件，另包括与数据治理相关的详细信息。
10.业务元数据包括主题域、概念、实体、属性的非技术名称和定义、属性的数据类型和其他特征，如范围描述、计算公式、算法和业务规则、有效的域值及其定义。
11.业务元数据的示例包括：
1）数据集、表和字段的定义和描述。
2）业务规则、转换规则、计算公式和推导公式。
3）数据模型。
4）数据质量规则和检核结果。
5）数据的更新计划。
6）数据溯源和数据血缘。
7）数据标准。
8）特定的数据元素记录系统。
9）有效值约束。
10）利益相关方联系信息（如数据所有者、数据管理专员）。
11）数据的安全/隐私级别。
12）已知的数据问题。
13）数据使用说明。

（2）技术元数据

10.技术元数据（Technical Metadata）提供有关数据的技术细节、存储数据的系统以及在系统内和系统之间数据流转过程的信息。
11.技术元数据示例包括：
1）物理数据库表名和字段名。
2）字段属性。
3）数据库对象的属性。
4）访问权限。
5）数据CRUD（增、删、改、查）规则。
6）物理数据模型，包括数据表名、键和索引。
7）记录数据模型与实物资产之间的关系。
8）ETL作业详细信息。
9）文件格式模式定义。
10）源到目标的映射文档。
11）数据血缘文档，包括上游和下游变更影响的信息。
12）程序和应用的名称和描述。
13）周期作业（内容更新）的调度计划和依赖。
14）恢复和备份规则。
15）数据访问的权限、组、角色。

（3）操作元数据

12.操作元数据（Operational Metadata）描述了处理和访问数据的细节，例如：
1）批处理程序的作业执行日志。
2）抽取历史和结果。
3）调度异常处理。
4）审计、平衡、控制度量的结果。
5）错误日志。
6）报表和查询的访问模式、频率和执行时间。
7）补丁和版本的维护计划和执行情况，以及当前的补丁级别。
8）备份、保留、创建日期、灾备恢复预案。
9）服务水平协议（SLA）要求和规定。
10）容量和使用模式。
11）数据归档、保留规则和相关归档文件。
12）清洗标准。
13）数据共享规则和协议。
14）技术人员的角色、职责和联系信息。

3.ISO/IEC 11179元数据注册标准

13.ISO的元数据注册标准ISO/IEC 11179中提供了用于定义元数据注册的框架，旨在基于数据的精确定义，从数据元素开始，实现元数据驱动的数据交换。
14.该标准由以下几部分组成：
第1部分：数据元素生成和标准化框架。
第2部分：数据元数据分类。
第3部分：数据元素的基本属性。
第4部分：数据定义的形成规则和指南。
第5部分：数据元素的命名和识别原则。
第6部分：数据元素的注册。

4.非结构化数据的元数据

15.从本质上来说，所有数据都是有一定结构的，但并非所有数据都是以行、列的形式在我们熟悉的关系型数据库中进行记录的。任何不在数据库或数据文件中的数据（包括文档或其他介质）都被认为是非结构化数据（参见第9章和第14章）。
相比结构化数据的管理，元数据对非结构化数据的管理来说可能更为重要。上文提到的图书馆中的书籍和杂志就是很好的非结构化数据的例子，目录卡片中元数据的主要用途是找到所需材料，而不用在意其格式。
非结构化数据的元数据包括：描述元数据，如目录信息和同义关键字；
结构元数据，如标签、字段结构、特定格式；

管理元数据，如来源、更新计划、访问权限和导航信息；
书目元数据，如图书馆目录条目；
记录元数据，如保留策略；
保存元数据，如存储、归档条件和保存规则（参见第9章）。
大多数人断言非结构数据的元数据管理与传统的内容管理问题相关，但是围绕着数据湖中的非结构化数据管理出现了新的实践。希望利用数据湖、使用Hadoop等大数据平台的组织发现，他们必须对采集的数据进行编目，以便以后访问。在多数情况下，收集元数据作为数据采集流程的一部分，需要收集关于在数据湖中采集的每个对象的最小元数据属性集（如名称、格式、来源、版本、接收日期等），这将生成数据湖内容的目录。

5.元数据来源

从元数据的类型应该能够清楚地看出，元数据的来源各异。此外，如果来自应用和数据库中的元数据管理得当，则可以较为容易地收集和整合它们。但是，大多数组织都没有在应用层面很好地管理元数据，因为元数据通常是作为应用程序处理的副产品而不是最终产品创建的（它不是为消费而创造的）。与其他形式的数据一样，在元数据集成之前，还需要做大量的准备工作。
16. 大多数操作元数据是在处理数据时生成的。使用这类元数据的关键是以一种可用的形式进行收集，并确保负责解释它的人拥有他们需要的工具。要想理解错误日志中的信息，需要理解描述日志文件中内容的元数据。同样，可以从数据库对象中收集大部分技术元数据。
可以对现有系统中的数据进行逆向工程，并从现有数据字典、模型和流程文档中收集业务元数据（Loshin，2001；Aiken，1995），但这样做是有风险的，最大的风险在于一开始不知道在开发和细化这些定义时需要花费多少精力。如果定义不完善或含糊不清，那么企业就不能向数据使用者提供他们用于理解正在使用的数据的信息。
最好是有意识地重新定义而不是简单地接受现有定义。定义的确定需要时间和正确的技能（如写作和辅导技能），这就是业务元数据的开发需要专职岗位的原因（参见第3章）。
管理数据库所需的大部分技术元数据和使用数据所需的业务元数据，可以作为项目工作的一部分进行收集和开发。例如，数据建模过程需要讨论数据元素的含义以及它们之间的关系。应记录和整理讨论过程中共享的知识，以便在数据字典、业务术语表和其他存储库中使用。数据模型本身包含数据物理特征的重要细节，应在这些工作上分配足够的时间，以确保项目产出物包含符合企业标准的高质量元数据。
定义良好的业务元数据可以在不同的项目中重复使用，并促进在不同数据集的业务概念得到一致理解。组织还可以有意规划元数据的集成作为开发元数据的一部分，以便元数据可以重复使用。例如，可以整理一个系统清单，所有与特定系统相关的元数据都可以使用相同的系统标识符进行标记。
为元数据本身而创建元数据很少能行得通，大多数组织都不会为此类工作提供资金支持，即使他们这样做，也不太可能实施维护流程。在这方面，元数据与其他数据一样：它应该作为有明确定义流程的产品而创建，使用可以保障整体质量的工具，管理员和其他数据管理专业人员应确保有适当的流程来维护与这些流程相关的元数据。例如，如果组织从其数据模型中收集关键元数据，应该确保有一个合适的变更管理过程保持模型的最新状态。
17.为了使组织对元数据有更深入的感受，此处概述一系列来源，按英文字母顺序排列。

（1）应用程序中元数据存储库

元数据存储库指存储元数据的物理表，这些表通常内置在建模工具、BI工具和其他应用程序中。随着组织元数据管理成熟度的提升，希望将不同应用程序中的元数据集成，以便数据使用者可以查看到各种信息。

（2）业务术语表

业务术语表（Business Glossary）的作用是记录和存储组织的业务概念、术语、定义以及这些术语之间的关系。
在许多组织中，业务术语表仅仅是一个电子表格。但是，随着组织的日渐成熟，他们会经常购买或构建术语表，这些术语表包含健壮的信息以及跟随时间变化的管理能力。与所有面向数据的系统一样，设计业务术语表应考虑具有不同角色和职责的硬件、软件、数据库、流程和人力资源。

18.业务词汇表应用程序的构建需满足三个核心用户的功能需求：
1）业务用户（Business users）。数据分析师、研究分析师、管理人员和使用业务术语表来理解术语和数据的其他人员。
2）数据管理专员（Data Stewards）。数据管理专员使用业务术语表管理和定义术语的生命周期，并通过将数据资产与术语表相关联增强企业知识，如将术语与业务指标、报告、数据质量分析或技术组件相关联。数据管理员收集术语和使用中的问题，以帮助解决整个组织的认识差异。
3）技术用户（Technical users）。技术用户使用业务术语表设计架构、设计系统和开发决策，并进行影响分析。
19.业务术语表应包含业务术语属性，例如：
1）术语名称、定义、缩写或简称，以及任何同义词。
2）负责管理与术语相关的数据的业务部门和/或应用程序。
3）维护术语的人员姓名和更新日期。
4）术语的分类或分类间的关联关系（业务功能关联）。
5）需要解决的冲突定义、问题的性质、行动时间表。
6）常见的误解。
7）支持定义的算法。
8）血缘。
9）支持该术语的官方或权威数据来源。
每个业务术语表的实施都应该有一组支持治理过程的基本报告。建议组织不要“打印术语表”，因为术语表的内容不是静态的。数据管理专员通常负责词汇表的开发、使用、操作和报告。报告包括：跟踪尚未审核的新术语和定义、处于挂起状态的术语和缺少定义或其他属性的术语（见12.6.4节）。
易用性和功能性会背道而驰，业务术语表的搜索便捷性越高，越容易推广使用。但是，术语表最重要的特征是它包含足够完整和高质量的信息。

（3）商务智能工具

商务智能工具生成与商务智能设计相关的各类元数据，包括概述信息、类、对象、衍生信息和计算的项、过滤器、报表、报表字段、报表展现、报表用户、报表发布频率和报表发布渠道。

（4）配置管理工具

配置管理工具或数据库（CMDB）提供了管理和维护与IT资产、它们之间的关系以及资产的合同细节相关的元数据的功能。CMDB数据库中的每个资产都被称为配置项（CI）。为每个CI类型收集和管理标准元数据。许多组织将CMDB与变更管理流程集成，以识别受特定资产变更影响的相关资产或应用程序。存储库提供了将元数据存储库中的资产链接到CMDB中的实际物理实现细节的机制，以提供数据和平台的完整视图。

（5）数据字典

数据字典定义数据集的结构和内容，通常用于单个数据库、应用程序或数据仓库。数据字典可用于管理数据模型中每个元素的名称、描述、结构、特征、存储要求、默认值、关系、唯一性和其他属性。它还应包含表或文件定义。数据字典嵌入在数据库工具中，用于创建、操作和处理其中包含的数据。数据使用者如需使用这类元数据，则必须从数据库或建模工具中进行提取。数据字典还可以描述那些对社区有用的、在安全限制下可用的、在业务流程中应用的数据元素。通过直接利用逻辑数据模型中的内容，在定义、发布和维护用于报告和分析的语义层时可以节省时间。但是，如前所述，应谨慎使用现有定义，尤其是在元数据管理成熟度较低的组织中。
在数据模型的开发过程中，会解释许多关键业务流程、关系和术语。当将物理结构部署到生产环境中时，通常会丢失在逻辑数据模型中捕获的部分信息。数据字典可以帮助组织确保此信息不会完全丢失，以及在生产部署之后逻辑模型与物理模型保持一致。

（6）数据集成工具

许多数据集成工具用于可执行文件将数据从一个系统移动到另一个系统，或在同一系统中的不同模块之间移动。许多工具生成临时文件，其中可能包含数据的副本或派生副本。这些工具能够从各种源加载数据，通过分组、修正、重新格式化、连接、筛选或其他操作对加载的数据进行操作，然后生成输出数据。这些数据将被分发到目标位置，它们记录在系统之间移动数据的沿袭关系。任何成功的元数据解决方案都应该能够通过集成工具移动时使用沿袭元数据，并将其作为从实际源到最终目的地的整体血统进行公开。
数据集成工具提供了应用程序接口（API），允许外部元数据存储库提取血缘关系信息和临时文件元数据。一旦元数据存储库收集了信息，元数据管理工具就可以为任何数据元素生成全局数据地图。数据集成工具还提供有关各种数据集成作业执行的元数据，包括上次成功运行、持续时间和作业状态。某些元数据存储库可以提取数据集成运行时的统计信息和元数据，并将其与数据元素一起公开（参见第6章和第8章）。

（7）数据库管理和系统目录

数据库目录是元数据的重要来源，它们描述了数据库的内容、信息大小、软件版本、部署状态、网络正常运行时间、基础架构正常运行时间、可用性，以及许多其他操作元数据属性。最常见的数据库形式是关系型的，关系型数据库将数据作为一组表和列进行管理，其中表包含一个或多个列、索引、约束、视图和存储过程。元数据解决方案应该能够连接到各种数据库和数据集，并读取数据库公开的所有元数据。一些元数据存储库工具可以集成系统管理工具中公开的元数据，以提供描述物理资产的更全面的图像。

（8）数据映射管理工具

映射管理工具用于项目的分析和设计阶段，它将需求转换为映射规范，然后由数据集成工具直接使用或由开发人员用来生成数据集成代码。映射文档通常也存储在整个企业的Excel文档中。一些厂商现在正在考虑为映射规范提供集中存储库，这些存储库具有版本控制和变更分析的功能。此外，许多映射工具与数据集成工具集成后，便可以自动生成数据集成程序，并且大多数映射工具还可以与其他元数据和参考数据存储库进行数据交换（参见第8章）。

（9）数据质量工具

数据质量工具通过验证规则来评估数据质量，其中的大多数工具提供了与其他元数据存储库交换质量分数和质量概况的功能，使元数据存储库能够将质量分数附加到相关的物理资产上。

（10）字典和目录

数据字典和术语表包含有关术语、表和字段的详细信息，但是字典或目录包含有关组织内数据的系统、源和位置的信息。元数据目录对于开发人员和数据超级用户（如数据管理团队和数据分析师）来说特别有用，可以了解企业中的数据范围，无论是研究问题还是查找有关寻找新应用程序的信息。

（11）事件消息工具

事件消息工具在不同系统之间移动数据，需要大量的元数据，并生成描述此移动的元数据。这些工具包括图形接口，可以管理数据移动的逻辑，并将接口实现细节、移动逻辑和处理统计信息导出到其他元数据存储库。

（12）建模工具和存储库

数据建模工具用于构建各种类型的数据模型：概念模型、逻辑模型和物理模型。这些工具生成与应用程序或系统模型设计相关的元数据，如主题域、逻辑实体、逻辑属性、实体和属性关系、父类型和子类型、表、字段、索引、主键和外键、完整性约束以及模型中其他类型的属性。元数据存储库可以提取由这些工具创建的模型，并将导入的元数据整合到存储库中。建模工具通常是数据字典内容的来源。

（13）参考数据库

参考数据记录各种类型的枚举数据（值域）的业务价值和描述，在系统中的上下文中使用。用于管理参考数据的工具，还能够管理相同或不同业务领域内不同编码值之间的关系。这些工具套件通常提供将收集的参考数据发送到元数据存储库的功能，元数据存储库则提供将参考数据与业务词汇表以及物理实现该数据的位置（如列或字段）相关联的机制。

（14）服务注册

服务注册是从面向服务的架构（SOA）角度管理和存储有关服务和服务终端的技术信息，如定义、接口、操作、输入和输出参数、制度、版本和示例使用场景。一些与服务相关的最重要的元数据包括服务版本、服务位置、数据中心、可用性、部署日期、服务端口、IP地址、统计端口、连接超时和连接重试超时。服务注册中心应满足各种需求，如显示所有可用服务的列表、具有特定版本的服务、过时服务或关于特定服务的细节，还可以审查服务评估是否可以复用。这些存储库中包含的信息提供了有关哪些数据存在以及它们如何在各种系统或应用程序之间移动的事实依据。可以提取服务存储库中的元数据，并将其与从其他工具收集的元数据合并，以提供数据如何在各种系统之间移动的完整画面。

（15）其他元数据存储

其他元数据的种类繁多，大多是指特定格式的清单，如事件注册表、源列表或接口、代码集、词典、时空模式、空间参考、数字地理数据集的分发、存储库的存储库和业务规则。

6.元数据架构的类型

20.与其他形式的数据一样，元数据也有生命周期。从概念上讲，所有元数据管理解决方案都包含与元数据生命周期相对应的架构层次：
1）元数据创建和采集。
2）元数据在一个或多个存储库中存储。
3）元数据集成。
4）元数据交付。
5）元数据使用。
6）元数据控制和管理。
可以采用不同的架构方法获取、存储、集成和维护元数据，供数据消费者访问元数据。

（1）集中式元数据架构

20.集中式元数据架构由单一的元数据存储库组成，包含来自各种不同源的元数据副本。IT资源有限的组织或者那些追求尽可能实现自动化的组织，可能会选择避免使用此架构选项。在公共元数据存储库中寻求高度一致性的组织，可以从集中式元数据架构中受益。
集中式存储库的优点有：
1）高可用性，因为它独立于源系统。
2）快速的元数据检索，因为存储库和查询功能在一起。
3）解决了数据库结构问题，使其不受第三方或商业系统特有属性的影响。
4）抽取元数据时可进行转换、自定义或使用其他源系统中的元数据进行补充，提高了元数据的质量。
集中式存储库的缺点有：
1）必须使用复杂的流程确保元数据源头中的更改能够快速同步到存储库中。
2）维护集中式存储库的成本可能很高。
3）元数据的抽取可能需要自定义模块或中间件。
4）验证和维护自定义代码会增加对内部IT人员和软件供应商的要求。
图12-2显示集中式存储库在各自具有内部元数据存储库的工具中收集元数据的方式。集中式存储库通过各种工具将元数据定时导入（箭头）来填充。反过来，集中式存储库公开了一个门户，供最终用户提交查询。元数据门户将请求传递到集中式元数据存储库，集中式存储库将以收集的元数据满足请求。在这种架构中，不支持将请求从用户直接传递给各种工具的功能。由于在集中式存储库中收集了各种元数据，因此可以对从各种工具收集的元数据进行全局搜索。

图12-2 集中式元数据架构

（2）分布式元数据架构

22.**一个完全分布式的架构中维护了一个单一的接入点。元数据检索引擎通过实时从源系统检索数据来响应用户请求；分布式元数据架构没有持久化的存储库。**在这种架构中，元数据管理环境维护必要的源系统目录和查找信息，以有效处理用户查询和搜索。可通过公共对象请求代理或类似的中间件协议访问这些源系统。
分布式元数据架构的优点包括：
1）元数据总是尽可能保持最新且有效，因为它是从其数据源中直接检索的。
2）查询是分布式的，可能会提高响应和处理的效率。
3）来自专有系统的元数据请求仅限于查询处理，而不需要详细了解专有数据结构，因此最大限度地减少了实施和维护所需的工作量。
4）自动化元数据查询处理的开发可能更简单，只需要很少的人工干预。
5）减少了批处理，没有元数据复制或同步过程。
分布式元数据架构的缺点包括：
1）无法支持用户定义或手动插入的元数据项，因为没有存储库可以放置这些添加项。
2）需要通过统一的、标准化的展示方式呈现来自不同系统的元数据。
3）查询功能受源系统可用性的影响。
4）元数据的质量完全取决于源系统。
图12-3说明了分布式元数据架构。没有集中式元数据存储库，门户会将用户的请求传递给相应的工具来执行。由于没有从各种工具收集元数据进行集中存储，必须将每个请求委托给源系统，因此不具有跨各种元数据源进行全局搜索的功能。

图12-3 分布式元数据架构

（3）混合式元数据架构

23.混合架构结合了集中式和分布式架构的特性，元数据仍然直接从源系统移动到集中式存储库，但存储库设计仅考虑用户添加的元数据、重要的标准化元数据以及来通过自手工来源添加的元数据。
该架构得益于从源头近乎实时地检索元数据和扩充元数据，可在需要时最有效地满足用户需求。混合方法降低了对专有系统进行手动干预和自定义编码访问功能的工作量。基于用户的优先级和要求，元数据在使用时尽可能是最新且有效的。混合架构不会提高系统可用性。
但是，源系统的可用性是一个限制，因为后端系统的分布式特性处理查询。在将结果集呈现给最终用户之前，需要用额外的系统开销将这些初始结果与中央存储库中的元数据扩展连接起来。
许多组织都可以从混合架构中受益，包括那些具有快速变化的操作元数据的组织，需要一致、统一的元数据组织，以及在元数据和元数据源正在大幅增长的组织。对于大多静态元数据或元数据量较小元数据增量的组织来说，可能无法发挥这种架构替代方案的最大潜力。

（4）双向元数据架构

24.另一种高级架构方法是双向元数据架构，它允许元数据在架构的任何部分（源、数据集成、用户界面）中进行更改，然后将变更从存储库（代理）同步到其原始源以实现反馈。
这种方法显然存在各种挑战。该设计强制元数据存储库包含最新版本的元数据源，并强制对源的更改管理，必须系统地捕获变更，然后加以解决；必须构建和维护附加的一系列处理接口，以将存储库的内容回写至元数据源。
图12-4说明了如何在集中式元数据存储中收集来自不同来源的公共元数据。用户将他们的查询请求提交到元数据门户，元数据门户将请求传递到一个集中式存储库，集中式存储库将尝试用最初从各种源收集的公共元数据满足用户请求。请求变得更具体或用户需要更详细的元数据时，集中式存储库将委托特定的源处理具体细节。由于在集中式存储库中收集了公共元数据，因此可以跨各种工具进行全局搜索。

12.2 活动

12.2.1 定义元数据战略

25.元数据战略描述组织应如何管理其自身元数据，以及元数据从当前状态到未来状态的实施线路。元数据战略应该为开发团队提供一个框架，以提升元数据管理能力。开发元数据需求，可以帮助阐明元数据战略的驱动力，识别潜在障碍并克服它。
26.元数据战略包括定义组织元数据架构蓝图和与战略目标匹配的实施步骤。步骤包括：
1）启动元数据战略计划。启动和计划的目的是保证元数据战略团队可以定义出短期和长期目标。计划包括起草与整体治理措施一致的章程、范围和具体目标，然后展开沟通计划以落实治理措施。关键利益相关方应参与计划制订。
2）组织关键利益相关方的访谈。通过对业务人员和技术人员的访谈，可以得到元数据战略的基础知识。
3）评估现有的元数据资源和信息架构。评估确定解决元数据和系统问题的难度，在访谈和文档复查中识别这些问题。在此阶段，对关键IT员工做进一步访谈，审查系统架构、数据模型等文档。
4）开发未来的元数据架构。优化和确认未来愿景，开发可以满足管理现阶段元数据环境长期目标的元数据架构。这个阶段必须考虑战略组成部分，如组织架构、与数据治理所需的管理人员一致、受控的元数据架构、元数据交付架构、技术架构和安全架构。
5）制订分阶段的实施计划。从访谈和数据分析中验证、整合、确定结果的优先级，发布元数据战略，并定义分阶段的、可以从当前状态迈向未来受控的元数据环境的实施方法。
为了使元数据需求、体系架构和元数据生命周期被更好地理解，它们将随着时间的推移而发生变化，元数据战略也将随之改变。

12.2.2 理解元数据需求

27.元数据需求的具体内容是：需要哪些元数据和哪种详细级别。例如，需要采集表和字段的物理名称和逻辑名称。元数据的内容广泛，业务和技术数据使用者都可以提出元数据需求（参见12.1.3（2）节）。
28.元数据综合解决方案由以下功能需求点组成：
1）更新频次。元数据属性和属性集更新的频率。
2）同步情况。数据源头变化后的更新时间。
3）历史信息。是否需要保留元数据的历史版本。
4）访问权限。通过特定的用户界面功能，谁可以访问元数据，如何访问。
5）存储结构。元数据如何通过建模来存储。
6）集成要求。元数据从不同数据源的整合程度，整合的规则。
7）运维要求。更新元数据的处理过程和规则（记录日志和提交申请）。
8）管理要求。管理元数据的角色和职责。
9）质量要求。元数据质量需求。
10）安全要求。一些元数据不应公开，因为会泄露某些高度保密数据的信息。

12.2.3 定义元数据架构

29.元数据管理系统必须具有从不同数据源采集元数据的能力，设计架构时应确保可以扫描不同元数据源和定期地更新元数据存储库，系统必须支持手工更新元数据、请求元数据、查询元数据和被不同用户组查询。
有相关元数据资源，这意味着用户可以在不关注数据源的差异的情况下访问元数据。在数据分析和大数据解决方案中，接口可能包含大量用户自定义函数（UDF）以利用多个数据集，此时对这些定制元数据向最终用户公开元数据是不透明的方式。方案中减少对UDF的依赖，最终用户将更加直接地收集、检查和使用数据集，此时许多支持的元数据通常可以更好地公开。
组织根据具体的需求设计元数据架构。与设计数据仓库相似，建立公共元数据存储库通常有三种技术架构方法：集中式、分布式和混合式（参见12.1.3节）。这些方法都考虑了存储库的实现以及更新机制的操作方式。

1.创建元模型

30.创建一个元数据存储库的数据模型，也叫元模型，是定义元数据战略和理解业务需求后的第一个设计步骤。可以根据需求开发不同级别的元模型；高级别的概念模型描述了系统之间的关系，低级别的元模型细化了各个属性，描述了模型组成元素和处理过程。作为一种规划工具和表达需求的方案，元模型本身也是一个有价值的元数据源。
图12-5显示了一个元数据存储库元模型的例子，图中方框表示包含数据的高级别主要实体。

图12-5 元数据存储库元模型示例

2.应用元数据标准

32.元数据解决方案应遵循在元数据战略中已定义的对内和对外的标准，数据治理活动应监督元数据的标准遵从情况。组织对内元数据标准包括命名规范、自定义属性、安全、可见性和处理过程文档，组织对外元数据标准包括数据交换格式和应程序接口设计。

3.管理元数据存储

33.实施控制活动以管理元数据环境。存储库的控制活动是由元数据专家执行的元数据迁移和存储库更新的控制。这些活动本质是可管理的、可监控的、可报告的、可预警的、有作业日志的，同时可以解决各种已实施的元数据存储库环境的各种问题。许多控制活动是数据操作和接口维护的标准，控制活动应受到数据治理过程的监督。
34.控制活动包括：
1）作业调度和监控。
2）加载统计分析。
3）备份、恢复、归档、消除。
4）配置修改。
5）性能调优。
6）查询统计分析。
7）查询和报表生成。
8）安全管理。
35.质量控制活动包括：
1）质量保证，质量控制。
2）数据更新频率——与时间表匹配。
3）缺失元数据报告。
4）未更新的元数据报告。
36.元数据管理活动包括：
1）加载、探测、导入和标记数据资产。
2）记录与源的映射和迁移关系。
3）记录版本。
4）用户界面管理。
5）连接数据集的元数据维护——为NOSQL提供支持。
6）数据与对内数据采集建立连接——自定义连接和作业元数据。
7）外部数据源和订阅源的许可。
8）数据增强元数据，如关联GIS。
37.培训活动包括：
1）教育和培训用户和数据专员。
2）生成和分析管理指标。
3）对控制活动、查询、报告进行培训。

12.2.4 创建和维护元数据

如12.1.3节所述，元数据是通过一系列过程创建的，并存储在组织中的不同地方。为保证高质量的元数据，应把元数据当作产品来进行管理。好的元数据不是偶然产生的，而是认真计划的结果（参见第13章）。
38.元数据管理的几个一般原则描述了管理元数据质量的方法：
1）责任（Accountability）。认识到元数据通常通过现有流程产生（数据建模，SDLC，业务流程定义），因此流程的执行者对元数据的质量负责。
2）标准（Standards）。制定、执行和审计元数据标准，简化集成过程，并且适用。
3）改进（Improvement）。建立反馈机制保障用户可以将不准确或已过时的元数据通知元数据管理团队。
如其他类型数据一样，可以对元数据进行剖析和质量的检查。作为项目工作的可审计部分，元数据维护工作应按计划进行或完成。

1.整合元数据

集成过程中从整个企业范围内收集和整合元数据，包括从企业外部获取的数据中的元数据。元数据存储库应将提取的技术元数据与相关的业务、流程和管理元数据集成在一起，可以使用适配器、扫描仪、网桥应用程序或直接访问源数据存储中的方式来提取元数据。第三方厂商的软件工具和元数据整合工具都提供采集适配器程序。在某些情况下，需要通过API来开发适配器。
元数据整合过程中可能存在一些挑战，也可能需要诉诸数据治理流程进行协调解决，例如，在对内部数据集、外部数据（如政府统计数据）、非电子形式数据（如白皮书、杂志文章或报表）进行整合时，可能会出现大量的质量和语义方面的问题。
39.对元数据存储库的扫描有两种不同的方式：
1）专用接口。采用单步方式，扫描程序从来源系统中采集元数据，直接调用特定格式的装载程序，将元数据加载到元数据存储中。在此过程中，不需要输出任何中间元数据文件，元数据的采集和装载也是一步完成的。
2）半专用接口。采用两步方式，扫描程序从来源系统中采集元数据，并输出到特定格式的数据文件中。扫描程序只产生目标存储库能够正确读取和加载的数据文件。数据文件可以被多种方式读取，所以这种接口的架构更加开放。
40.在此过程中，扫描程序产生和使用多种类型文件：
1）控制文件。包含数据模型的数据源结构信息。
2）重用文件。包含管理装载流程的重用规则信息。
3）日志文件。在流程的每一阶段、每次扫描或抽取操作生成的日志。
4）临时和备份文件。在流程中使用或做追溯流程所使用的文件。
可以使用一个非持久的元数据暂存区进行临时和备份文件的存储，暂存区应支持回滚和恢复处理，并提供临时审计跟踪信息，这样有助于存储库管理员追踪元数据来源或质量问题。暂存区可以采用文件目录或数据库的形式。
数据仓库和商务智能所使用的数据整合工具通常也适用于元数据整合（参见第8章）。

2.分发和传递元数据

41.元数据可传递给数据消费者和需要处理元数据的应用或工具。传递机制包括：
1）元数据内部网站，提供浏览、搜索、查询、报告和分析功能。
2）报告、术语表和其他文档。
3）数据仓库、数据集市和BI（商务智能）工具。
4）建模和软件开发工具。
5）消息传送和事务。
6）Web服务和应用程序接口（API）。
7）外部组织接口方案（如供应链解决方案）。
元数据方案通常与商务智能方案有联系，所以元数据方案的范围和流转与商务智能内容同步。正因为有这样的联系，元数据需要整合到商务智能的交付物中，并提供给最终用户使用。同样，一些CRM（客户关系管理）或ERP（企业资源规划）方案可能也需要在应用交付时整合元数据信息。
有时，可能需要通过文件（文本、XML或JSON格式）或Web服务方式将元数据与外部组织进行交互。

12.2.5 查询、报告和分析元数据

42.元数据指导如何使用数据资产：在商务智能（报表和分析）、商业决策（操作型、运营型和战略型）以及业务语义（业务所述内容及其含义）方面使用元数据。元数据存储库应具有前端应用程序，并支持查询和获取功能，从而满足以上各类数据资产管理的需要。提供给业务用户的应用界面和功能与提供给技术用户和开发人员的界面和功能有所不同，后者可能会包括有助于新功能开发（如变更影响分析）或有助于解决数据仓库和商务智能项目中数据定义问题（如数据血缘关系报告）的功能。

12.3 工具

43.管理元数据的主要工具是元数据存储库。元数据存储库包括整合层和手工更新的接口。处理和使用元数据的工具集成到元数据存储库中作为元数据来源。
44.元数据管理工具提供了在集中位置（存储库）管理元数据的功能。元数据可以手动输入，也可以通过专门的连接器从其他各种源中提取。元数据存储库还提供与其他系统交换元数据的功能。
45.元数据管理工具和存储库本身也是一种元数据的数据源，特别是在混合型元数据架构模型或大型企业架构中。
46.元数据管理工具允许已采集的元数据与其他元数据存储库进行交换，支持采集多种多样的、不同来源的元数据到中央仓库中，支持有差异的元数据在两个存储库迁移时进行提炼和标准化。

12.4 方法

12.4.1 数据血缘和影响分析

47.发现和记录数据资产的元数据的一个重要意义在于提供了数据如何在系统间转移的信息。许多元数据工具中存储着某个环境中数据现况的信息，并提供查看跨系统或应用程序接口的血缘功能。
48.基于程序编码的当前版本的血缘称为“实现态血缘（As Implemented Lineage）”。相反，映射规范文档中描述的血缘称为“设计态血缘（As Designed Lineage）”
数据血缘创建的局限性在于元数据管理系统的覆盖范围。特定功能的元数据存储库或数据可视化工具在其管理范围内提供数据血缘的信息，超出管理范围时将无法提供相关信息。
49.元数据管理系统通过可以提供数据血缘详情的工具导入“实现态血缘”，并从无法自动抽取的“设计态血缘”文件中获取实施细节加以补充。
50。将数据血缘的各个部分连接起来的过程称为“拼接”，“拼接”结果是一个表示数据从原始位置（数据源或记录系统）转移到最终位置的全景视图。
图12-6是一个数据元的血缘关系示例，业务数据元“所有延期订单金额”物理实现下的字段“zz total”依赖其他三个数据元:“单位成本（分）”的字段“yy unit cost”、“税金”的字段“yy tax”、“延期订单数联”的字段“yy qty”。
如图12-6所示，血缘图描述特定数据元的血缘，但不是所有业务人员都能理解。更高阶的血缘关系（如系统血缘）概况描述系统级或应用级的数据迁移。许多可视化工具提供了缩小/放大功能，可以查看系统血缘内部的数据元血缘关系。图12-7为一个系统血缘关系的示例，一眼就能看到系统或应用级的数据迁移情况。

图12-6 数据元血缘关系流向图示例

图12-7 系统血缘关系流向图
51.随着系统中数据元的大量增加，数据血缘关系的发现变得复杂且难以管理。为了成功实现业务目标，需要计划和设计一个策略来发现和采集元数据到元数据存储库。
52.要想成功发现数据血缘关系，需要兼顾业务焦点和技术焦点。
1）业务焦点。根据业务优先级寻找数据元的血缘关系。从目标位置回溯到具体数据起源的源系统。通过扫描那些发生迁移、传送或更新的数据元，确保业务数据使用者理解特定数据元在系统间迁移时发生了什么。例如，将血缘关系应用在数据质量测量中，血缘关系用来定位影响数据质量的系统设计缺陷。
2）技术焦点。从源系统开始识别直接相关的数据使用者，依次识别间接的数据使用者，直到识别出所有系统为止。技术人员可以从这个系统的识别策略中获益，有助于回答各种各样的数据问题。这一方法可以确保技术人员和业务人员回答关于发现全企业数据元的问题，如“哪里存有社保编号”，或者生成影响分析报告，如“修改指定字段的长度哪些系统会受影响”。然而，这种策略可以管理但很复杂。

许多数据整合工具提供数据血缘分析功能，该功能不仅包括开发大量代码，也设计了数据模型和物理数据库。某些整合工具支持业务人员使用网页来监控和更新元数据，看起来类似业务术语管理。
记录血缘关系有助于业务和技术人员使用数据，如缺失数据血缘，用户将需花费大量时间来检查异常现象、潜在的变更影响和其他未知结果。希望实现一个集成的影响和血缘工具，以理解加载过程中涉及的所有移动部分以及最终用户报告和分析。影响报告概述了哪些组件受到潜在变更的影响，加速和简化评估和维护任务。

12.4.2 应用于大数据采集的元数据

53.大部分数据管理专业人员更熟悉和适应结构化数据存储，结构化数据的每个数据项都有清晰的定义和标记。然而，如今越来越多的数据以非结构化格式存储，这些非结构化数据源来自组织的内外部。无论是内部，还是外部，都不再需要移动数据到物理环境下同一位置。通过新技术，程序将围绕数据，而不是把数据移动到程序里，这样可以减少大量的数据移动，并提高程序执行速度。尽管如此，数据湖中的成功数据管理依然依赖于管好元数据。
54.元数据标签应在采集时应用于数据，然后元数据可以用来识别可访问的数据湖中的数据内容。大部分采集引擎采集数据后进行数据剖析，数据剖析可以识别出数据域、数据关系和数据质量问题，并打上标签。采集数据时，识别到敏感或隐私（如个人身份信息，PPI）数据时应添加元数据标签。例如，数据科学家会添加关于置信度、文本标识符和表示集群行为的代码（参见第14章）。

12.5 实施指南

使用渐进的步骤建设实施受控的元数据管理环境，可减少组织的风险，并便于用户接受。使用开源的关系型数据库平台来实施元数据存储，可以应对实施存储库项目开始时可能无法预料的各种控制和接口问题。
存储库的内容在设计上应该是通用的，而不只是反映源系统的数据库设计。应基于易理解的元数据模型与企业领域专家共同进行设计。规划设计时应考虑集成元数据，以确保数据使用者无须关注数据源的差异，这个功能将是元数据存储库最有价值的功能之一。元数据存储库包含当前的、计划的和历史版本的元数据。
通常来说，第一个实施的是验证概念并学习管理元数据环境的试点项目。把元数据相关项目与IT开发方法论进行整合是必要的，因为IT的架构和存储类型不同，这些项目也将随之变化。
12.5.1 就绪评估/风险评估
55.拥有坚定的元数据战略，有助于所有人进行更高效率的决策。首要的是，所有人应意识到不管理元数据的风险。评估缺失高质量元数据可能带来的影响如下：
1）因不正确、不完整和不合理的假设或缺乏数据内容的知识导致错误判断。
2）暴露敏感数据，使客户或员工面临风险，影响商业信誉和导致法律纠纷。
3）如果了解数据的那些领域专家们离开了，那么他们了解的知识也随之被带走了。
56.当组织采用坚定的元数据战略时可以减少风险。组织准备情况的评估解决方法为：对元数据相关活动现状进行正式的成熟度评估，评估内容应包括重要的业务数据元、可用的元数据术语表、数据血缘、数据剖析和数据质量管理过程、主数据管理成熟度和其他方面。评估的结果与业务优先级一致，将为改进元数据管理实践的战略方法提供基础。正式的评估结果也为业务案例、赞助和筹集资金提供基础。
57.元数据战略是整体数据治理战略的一部分，是实现有效数据治理的第一步。元数据评估应该通过对现有元数据的客观检查来进行，包括对关键利益相关方的访谈。风险评估的交付成果包括元数据战略和实施线路。

12.5.2 组织和文化变革

与其他数据管理工作一样，元数据计划经常遇到文化阻力。元数据从非托管环境转移到托管环境需要工作和规范，而即使大多数人已认识到可靠元数据的价值，也不容易做到这一点。因此，组织准备程度是一个主要关注点，治理和控制的方法也是如此。
58.元数据管理在许多组织中是一项低优先级的工作。一组基本的元数据需要组织中各团队的协调和承诺，它们可能是员工身份数据、保险单编号、车辆识别号或产品规格的结构。如果要更改这些结构，需要对许多企业系统进行重大检修。需要寻找一个合适的案例试点，在这个案例中，控制元数据将为公司的数据带来显而易见的质量效益，从具体的业务相关案例中构建论点。
企业数据治理战略的实现需要高级管理层的支持和参与，要求业务人员和技术人员能够以跨职能的方式紧密合作。

12.6 元数据治理

59.组织应确定他们管理元数据生命周期的具体需求，并开展元数据治理工作以满足这些需求。建立正式的角色和职责并分配专用资源，特别是在大型或业务关键领域中。元数据治理过程本身依赖于可靠的元数据，因此负责管理元数据的团队可以在创建和使用元数据的过程中对管理原则进行验证测试。

12.6.1 过程控制

数据管理团队应负责定义标准和管理元数据的状态变化（通常使用工作流或协作软件），同时可以负责组织内的质量提升活动、培训计划或实际培训活动。
60.更成熟的元数据治理需要通过多个不同阶段和状态的决策来确定业务术语和定义，如一个候选术语从申请审批到发布再到更新或者删除的全生命周期的各节点。治理团队还可以管理与业务术语关联的其他术语，以及术语的分类和分组。
需要将元数据战略集成到软件开发的生命周期中，确保变更过的元数据及时得到收集，以确保元数据保持最新。

12.6.2 元数据解决方案的文档

62.元数据的主目录包括当前作用域中的源和目标。元数据资源面向技术及业务用户，可发布到用户社区，并可作为“元数据在哪里”的指引，告知用户能够满足他们的以下需求：
1）元数据管理实施状态。
2）源和目标元数据存储。
3）元数据更新的调度计划信息。
4）留存和保持的版本。
5）内容。
6）质量声明或警告（如缺失的值）。
7）记录系统和其他数据源状态（如数据内容历史加载、删除或更新标志）。
8）相关的工具、架构和人员。
8）敏感信息和数据源的移除或脱敏策略。
在文件和内容管理中，数据地图展示了类似的信息。整个元数据整合系统的全景视图也作为元数据文档的一部分进行维护（参见第9章）。

12.6.3 元数据标准和指南

在与业务贸易伙伴交换数据时，元数据标准是必不可少的。公司已意识到与客户、供应商、合作伙伴和监管机构共享信息的价值。为了支持共享信息的最佳使用，需要共享公共元数据，这催生了许多专业领域的标准。
63.在计划周期的早期采用基于行业的、行业特有的元数据标准，并使用这些标准评估元数据管理技术。许多领先的厂商支持多种标准，其中一些可以帮助定制基于行业的、行业特有的标准。
工具厂商提供XML、JSON或REST技术支持其数据管理产品的数据交换，他们使用相同的策略将工具绑定到解决方案套件中，包括数据整合、关系和多维数据库、需求管理、BI报告、数据建模和业务规则在内的技术使用XML提供了数据和元数据导入和导出功能。厂商维护他们专有的XML模式、文档类型定义（DTD），或者更常见的XML模式定义（XSD）。这些内容是要通过专有接口访问的，需要自定义开发集成工具到元数据管理环境中。
指导方针包括模板、相关示例、有关预期输入和更新的培训，以及“不使用术语定义术语”等规则和完整性声明。针对不同类型的元数据开发不同的模板，部分由所选的元数据解决方案驱动。持续监测指导方针的有效性和必要更新是治理责任。
元数据的ISO标准为工具开发人员提供了指导，但不太可能成为使用商业工具的组织所关注的问题，因为工具应该满足这些标准。无论如何，对这些标准及其影响有一个很好的理解都是很有帮助的。

12.6.4 度量指标

64.要想测量元数据的影响，就需要验证缺少元数据导致的影响。作为风险评估的一部分，将数据使用者搜索信息所花费的时间作为评估指标，以便在实施元数据解决方案后体现改进程度。元数据管理实施的有效性可以根据元数据本身的完整性、与其关联的日常管理操作以及元数据的使用情况来度量。元数据管理环境的建议指标包括：
1）元数据存储库完整性。将企业元数据（范围内的所有产品和实例）的理想覆盖率与实际覆盖率进行比较。参照元数据管理范围定义的策略。
2）元数据管理成熟度。根据能力成熟度模型（CMM-DMM）的成熟度评估方法，开发用于判断企业元数据成熟度的指标（参见第15章）。
**3）专职人员配备。**通过专职人员的任命情况、整个企业的专职人员覆盖范围，以及职位描述中的角色定义说明，来评估的组织对元数据的承诺。
4）元数据使用情况。可以通过存储库的访问次数衡量用户对元数据存储库的使用情况和接受程度。在业务实践中，用户引用元数据是一个很难跟踪的指标，可能需要定性的调研措施获取评估结果。
5）业务术语活动。使用、更新、定义解析、覆盖范围。
6）主数据服务数据遵从性。显示SOA解决方案中数据的重用情况。主数据服务上的元数据帮助开发人员决定新的开发任务可以使用哪些现有服务。
7）元数据文档质量。一个质量指标是通过自动和手动两种方式评估元数据文档的质量。自动评估方式包括对两个源执行冲突逻辑的比对、测量二者匹配的程度以及随时间推移的变化趋势。另一个度量指标是度量具有定义的属性的百分比，以及随着时间的推移而发生变化的趋势。手动评估方式包括基于企业质量定义进行随机或完整的调查。质量度量表明存储库中元数据的完整性、可靠性、通用性等。
8）元数据存储库可用性。正常运行时间、处理时间（批处理和查询）。