读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. 必须构建和维护附加的一系列处置惩罚接口，以将存储库的内容回写至元数据源
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。