元数据管理是整个数据仓库架构中很重要的一块（关于数据仓库的架构，请参考这篇文章——数据仓库的基本架构），但发其实现很多书里面都没有对元数据下一个详细的定义，或者没有系统地介绍到底数据仓库的元数据应该包括哪些。下面是我个人整理的一些对元数据管理的看法，主要来自Inmon的《数据仓库》的两本书、Oracle的文档及个人在数据仓库的应用中认为应该记录的一些元数据。

元数据的定义

　　元数据（Meta Data），从字面来看好像无法看出所以然，我当初看到的时候也是，但其实看看对应的英文，含义还是挺明确的，Meta一般是指“对……的解释或描述”，类似的还有Meta Tag。所以元数据其实就是对数据的解释和描述，这种解释可以以多种形式存在，数据库的数据字典、外部文档，工具的资料档案库（Repository）等。

元数据包括哪些

　　这里主要将数据仓库的元数据分为3类：数据库管理系统的数据字典、ETL处理流程产生的日志、BI建模和分析中工具或文档中记录的信息。

DBMS数据字典

　　数据库管理系统（DBMS）中的元数据一般在所有的数据仓库都会包含，因为数据仓库一般都是基于数据库搭建的，而数据库本身的管理系统就会自动维护一套数据字典供用户查询。这些信息一般包括：

• 数据库的关系模型，包含的对象及对象的描述；
• 数据库的表结构、字段信息及描述；
• 表和字段中的主外键、索引、约束等信息；
• 各对象的存储位置和操作权限等。

ETL处理日志

　　ETL是数据仓库管理和维护的基础，就像是数据仓库的血液维系着整个数据的新陈代谢。我们需要时刻关注血液的循环是否正常，它是保证数据完整性、一致性、准确性和及时性的重要参考依据，所以我们需要记录ETL任务的处理日志，我一般会记录以下几类信息：

• 任务信息、调用的程序或脚本、前置任务；
• 数据来源、加载目标、转化规则或计算公式；
• 数据的刷新类型、刷新频率，任务调度信息；
• 每次运行的起始时间、结束时间、操作记录数、任务状态及出错信息。

　　记录ETL信息的方式有很多，一般我会将上面罗列的信息分两类进行记录，一类是ETL基本信息与调度信息，另一类是ETL的每次运行日志。其实ETL的任务信息和任务调度一般比较简单且更新频率不高，可以以文档或建数据库表的形式记录，当有新的ETL任务配置进去时进行手动更新；而ETL的运行日志一般是当任务运行一次就会记录一条，反映该次运行的状态，所以一般每个程序或脚本每天甚至每小时就会产生一条，建议如果ETL环境在数据库里面的话，建立ETL日志表记录相对会比较方便，当每次ETL运行时自动地去维护这张表，INSERT一条任务运行的记录。

BI分析模型

　　这里的BI分析模型主要有两类，一类是数据仓库常见的多维模型，另一类是根据具体业务构建的商业分析模型。无论是哪类模型，其实都已经在分析的层面上，所以都有必要记录以下几类信息：

• 分析模型的设计和结构；
• 模型的分析应用和商业价值；
• 模型中指标的定义、计算方法；
• 模型的展现和效果。

　　模型一般由分析师设计和构建，所以这类信息一般会以文档的形式记录下面，或者制作成相应的PPT进行展示。这里必须注意的是分析模型在构建之初就必须明确应用的环境、体现的价值或可能实现的预期，明确这些是为了更好地应用到实践中，如果只是单纯为了实现这样的模型或者基于相应算法的实现，那么很有可能最终模型会变成一种摆设；再有一点就是模型的展现，模型需要优化其在可视化层面的效果，也就是要让其他人能够更好地理解模型的使用和价值，一切底层的算法和数据的处理只是为了让模型在最终的展现上更加有效。

　　上面只是对于所有的分析模型而言，对于多维模型，其在数据仓库的应用已经形成了一定的规范，所以我们可以获取到更多的信息：

• 多维模型的结构（星形、雪花等）；
• 多维模型的维（层次、级别、属性）和立方（度量、计算度量）；
• 多维模型的数据组织和加载；
• 可以实现的OLAP应用与展现。

　　其实如果你用工具来构建多维模型，那么这些多维模型的元数据信息可能很多直接就会保存在工具相应的资料档案库（Repository）里面，当然你也可以自己整理出相应的文档，供不时的查询和分享的需要。

　　好了，数据仓库的元数据管理方面的总结就是这些。非常感谢近几天一些网友在博客中的评论和留言，让我学到了很多，也让我可以去改善一些东西，希望大家能够继续在博客中提出宝贵的建议。近段时间可能会比较忙，留言的回复和文章的更新可能会相对慢一些，希望大家谅解。