读DAMA数据管理知识体系指南37元数据管理概念（下）

1. 元数据来源

1.1. 元数据的来源各异

• 1.1.1. 大多数操作元数据是在处理数据时生成的

• 1.1.2. 最好是有意识地重新定义而不是简单地接受现有定义

1.2. 管理数据库所需的大部分技术元数据和使用数据所需的业务元数据，可以作为项目工作的一部分进行收集和开发

• 1.2.1. 应记录和整理讨论过程中共享的知识，以便在数据字典、业务术语表和其他存储库中使用

1.3. 定义良好的业务元数据可以在不同的项目中重复使用，并促进在不同数据集的业务概念得到一致理解

• 1.3.1. 组织还可以有意规划元数据的集成作为开发元数据的一部分，以便元数据可以重复使用

1.4. 应该作为有明确定义流程的产品而创建，使用可以保障整体质量的工具，管理员和其他数据管理专业人员应确保有适当的流程来维护与这些流程相关的元数据

1.5. 应用程序中元数据存储库

• 1.5.1. 元数据存储库指存储元数据的物理表，这些表通常内置在建模工具、BI工具和其他应用程序中

1.6. 业务术语表

• 1.6.1. 业务术语表(Business Glossary)的作用是记录和存储组织的业务概念、术语、定义以及这些术语之间的关系

• 1.6.2. 在许多组织中，业务术语表仅仅是一个电子表格

  • 1.6.2.1. 随着组织的日渐成熟，他们会经常购买或构建术语表

• 1.6.3. 业务用户(Business users)

  • 1.6.3.1. 数据分析师、研究分析师、管理人员和使用业务术语表来理解术语和数据的其他人员

• 1.6.4. 数据管理专员(Data Stewards)

  • 1.6.4.1. 数据管理专员使用业务术语表管理和定义术语的生命周期，并通过将数据资产与术语表相关联增强企业知识，如将术语与业务指标、报告、数据质量分析或技术组件相关联

  • 1.6.4.2. 数据管理专员通常负责词汇表的开发、使用、操作和报告

• 1.6.5. 技术用户(Technical users)

  • 1.6.5.1. 技术用户使用业务术语表设计架构、设计系统和开发决策，并进行影响分析

• 1.6.6. 业务术语表应包含业务术语属性

  • 1.6.6.1. 术语名称、定义、缩写或简称，以及任何同义词

  • 1.6.6.2. 负责管理与术语相关的数据的业务部门和/或应用程序

  • 1.6.6.3. 维护术语的人员姓名和更新日期

  • 1.6.6.4. 术语的分类或分类间的关联关系（业务功能关联）

  • 1.6.6.5. 需要解决的冲突定义、问题的性质、行动时间表

  • 1.6.6.6. 常见的误解

  • 1.6.6.7. 支持定义的算法

  • 1.6.6.8. 血缘

  • 1.6.6.9. 支持该术语的官方或权威数据来源

• 1.6.7. 每个业务术语表的实施都应该有一组支持治理过程的基本报告

  • 1.6.7.1. 建议组织不要“打印术语表”​，因为术语表的内容不是静态的

  • 1.6.7.2. 报告包括：跟踪尚未审核的新术语和定义、处于挂起状态的术语和缺少定义或其他属性的术语

• 1.6.8. 用性和功能性会背道而驰，业务术语表的搜索便捷性越高，越容易推广使用

• 1.6.9. 术语表最重要的特征是它包含足够完整和高质量的信息

1.7. 商务智能工具

• 1.7.1. 商务智能工具生成与商务智能设计相关的各类元数据

• 1.7.2. 包括概述信息、类、对象、衍生信息和计算的项、过滤器、报表、报表字段、报表展现、报表用户、报表发布频率和报表发布渠道

1.8. 配置管理工具

• 1.8.1. 配置管理工具或数据库(CMDB)提供了管理和维护与IT资产、它们之间的关系以及资产的合同细节相关的元数据的功能

• 1.8.2. CMDB数据库中的每个资产都被称为配置项(CI)

1.9. 数据字典

• 1.9.1. 数据字典定义数据集的结构和内容，通常用于单个数据库、应用程序或数据仓库

• 1.9.2. 数据使用者如需使用这类元数据，则必须从数据库或建模工具中进行提取

1.10. 数据集成工具

• 1.10.1. 用于可执行文件将数据从一个系统移动到另一个系统，或在同一系统中的不同模块之间移动

• 1.10.2. 任何成功的元数据解决方案都应该能够通过集成工具移动时使用沿袭元数据，并将其作为从实际源到最终目的地的整体血统进行公开

• 1.10.3. 数据集成工具提供了应用程序接口(API)，允许外部元数据存储库提取血缘关系信息和临时文件元数据

• 1.10.4. 数据集成工具还提供有关各种数据集成作业执行的元数据，包括上次成功运行、持续时间和作业状态

1.11. 数据库管理和系统目录

• 1.11.1. 数据库目录是元数据的重要来源，它们描述了数据库的内容、信息大小、软件版本、部署状态、网络正常运行时间、基础架构正常运行时间、可用性，以及许多其他操作元数据属性

• 1.11.2. 最常见的数据库形式是关系型的，关系型数据库将数据作为一组表和列进行管理，其中表包含一个或多个列、索引、约束、视图和存储过程

1.12. 数据映射管理工具

• 1.12.1. 映射管理工具用于项目的分析和设计阶段，它将需求转换为映射规范，然后由数据集成工具直接使用或由开发人员用来生成数据集成代码

1.13. 数据质量工具

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

1.14. 字典和目录

• 1.14.1. 数据字典和术语表包含有关术语、表和字段的详细信息

• 1.14.2. 字典或目录包含有关组织内数据的系统、源和位置的信息

1.15. 事件消息工具

• 1.15.1. 事件消息工具在不同系统之间移动数据，需要大量的元数据，并生成描述此移动的元数据

1.16. 建模工具和存储库

• 1.16.1. 数据建模工具用于构建各种类型的数据模型：概念模型、逻辑模型和物理模型

• 1.16.2. 元数据存储库可以提取由这些工具创建的模型，并将导入的元数据整合到存储库中

• 1.16.3. 建模工具通常是数据字典内容的来源

1.17. 参考数据库

• 1.17.1. 参考数据记录各种类型的枚举数据（值域）的业务价值和描述，在系统中的上下文中使用

1.18. 服务注册

• 1.18.1. 服务注册是从面向服务的架构(SOA)角度管理和存储有关服务和服务终端的技术信息，如定义、接口、操作、输入和输出参数、制度、版本和示例使用场景

1.19. 其他元数据存储

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

2. 元数据架构的类型

2.1. 架构层次

• 2.1.1. 元数据创建和采集

• 2.1.2. 元数据在一个或多个存储库中存储

• 2.1.3. 元数据集成

• 2.1.4. 元数据交付

• 2.1.5. 元数据使用

• 2.1.6. 元数据控制和管理

2.2. 集中式元数据架构

• 2.2.1. 集中式元数据架构由单一的元数据存储库组成，包含来自各种不同源的元数据副本

• 2.2.2. 在公共元数据存储库中寻求高度一致性的组织，可以从集中式元数据架构中受益

• 2.2.3. 优点

  • 2.2.3.1. 高可用性，因为它独立于源系统

  • 2.2.3.2. 快速的元数据检索，因为存储库和查询功能在一起

  • 2.2.3.3. 解决了数据库结构问题，使其不受第三方或商业系统特有属性的影响

  • 2.2.3.4. 抽取元数据时可进行转换、自定义或使用其他源系统中的元数据进行补充，提高了元数据的质量

• 2.2.4. 缺点

  • 2.2.4.1. 必须使用复杂的流程确保元数据源头中的更改能够快速同步到存储库中

  • 2.2.4.2. 维护集中式存储库的成本可能很高

  • 2.2.4.3. 元数据的抽取可能需要自定义模块或中间件

  • 2.2.4.4. 验证和维护自定义代码会增加对内部IT人员和软件供应商的要求

2.3. 分布式元数据架构

• 2.3.1. 一个完全分布式的架构中维护了一个单一的接入点

• 2.3.2. 元数据检索引擎通过实时从源系统检索数据来响应用户请求

• 2.3.3. 分布式元数据架构没有持久化的存储库

• 2.3.4. 元数据管理环境维护必要的源系统目录和查找信息，以有效处理用户查询和搜索

• 2.3.5. 优点

  • 2.3.5.1. 元数据总是尽可能保持最新且有效，因为它是从其数据源中直接检索的

  • 2.3.5.2. 查询是分布式的，可能会提高响应和处理的效率

  • 2.3.5.3. 来自专有系统的元数据请求仅限于查询处理，而不需要详细了解专有数据结构，因此最大限度地减少了实施和维护所需的工作量

  • 2.3.5.4. 自动化元数据查询处理的开发可能更简单，只需要很少的人工干预

  • 2.3.5.5. 减少了批处理，没有元数据复制或同步过程

• 2.3.6. 缺点

  • 2.3.6.1. 无法支持用户定义或手动插入的元数据项，因为没有存储库可以放置这些添加项

  • 2.3.6.2. 需要通过统一的、标准化的展示方式呈现来自不同系统的元数据

  • 2.3.6.3. 查询功能受源系统可用性的影响

  • 2.3.6.4. 元数据的质量完全取决于源系统

2.4. 混合式元数据架构

• 2.4.1. 混合架构结合了集中式和分布式架构的特性，元数据仍然直接从源系统移动到集中式存储库，但存储库设计仅考虑用户添加的元数据、重要的标准化元数据以及来通过自手工来源添加的元数据

• 2.4.2. 降低了对专有系统进行手动干预和自定义编码访问功能的工作量

• 2.4.3. 元数据在使用时尽可能是最新且有效的

• 2.4.4. 混合架构不会提高系统可用性

• 2.4.5. 源系统的可用性是一个限制，因为后端系统的分布式特性处理查询

2.5. 双向元数据架构

• 2.5.1. 允许元数据在架构的任何部分（源、数据集成、用户界面）中进行更改，然后将变更从存储库（代理）同步到其原始源以实现反馈

• 2.5.2. 存在各种挑战

  • 2.5.2.1. 该设计强制元数据存储库包含最新版本的元数据源，并强制对源的更改管理，必须系统地捕获变更，然后加以解决

  • 2.5.2.2. 必须构建和维护附加的一系列处理接口，以将存储库的内容回写至元数据源