元数据在数据治理领域是被滥用的术语，但是您知道它的身世吗？现在我就带你简单了解一下元数据的过去、现在和将来。

韦伯斯特将“元”定义为一个更全面的术语，它需要“描述一个新的和相关的学科，以批判性地处理原始学科”。因此，元数据描述了一个促进数据研究的学科。

元数据的起源可以追溯到我们如何使用度量单位。单位的目的是描述一个对象的属性。例如，木棒（物体）的长度（物理性质）为5米（测量单位）。此例用于一个对象、一个数据项（数字5）和两个元数据项（长度和测量单位）。

在过去，元数据通常被视为“二等公民”。随着计算机的出现和对数据需求的不断增加，我们引入了将数据永久存储在辅助存储器中的技术。然后，应用程序可以检索和使用这些数据。文件管理器用于存储和检索辅助存储中的数据。为了完成他们的工作，文件管理器使用诸如字段名和文件名之类的元数据。元数据的这种使用，连同实际数据，现在已经广泛地根植于数据库管理技术中。

元数据概念的演变

20世纪60年代

人们早期将文件保存在磁带上，访问是连续的，成本与文件大小成正比，使用简单的索引来加速访问。然而，随着数据成指数倍的增长，变得难以管理。由于这个原因，在20世纪60年代初，应用树结构的想法成为了一种潜在的解决方案。在20世纪60年代后期，许多供应商创建的文件系统速度更快，而且不是连续的。对于所有文件系统，首先确定记录的格式，记录的字段名及其数据类型基本上就是文件中使用的元数据。

70年代

20世纪70年代可以称为元数据管理的元年。随着数据库管理系统（DBMS）的出现，元数据的使用急剧增加。例如，在关系DBMS中，元数据被广泛用于定义数据。这些元数据包括实体系名、属性名、主/外键和域值信息。1976年，随着实体关系（ER）数据模型的引入，以及后来其他语义数据模型的出现，更高层次的元数据被使用。由于语义数据模型（如ER）没有支持DBMS，因此部署了一种转换机制，将更高级别的元数据转换为关系元数据。

80年代

随着数据库管理系统成功地用于存储和检索业务数据，人们开始努力研究非业务数据类型。这些数据类型来自不同的应用领域，如计算机辅助设计/计算机辅助制造（CAD/CAM）、计算机辅助软件工程（CASE）、地理信息系统（GIS）。此时，数据的概念被一个称为资产的术语所取代。资产是一个有用的项目，它是应用程序开发过程的产品或副产品。资产可以是相对有形的，如凭证、和软件代码，或者更加无形，如知识和方法。有形资产可以采用框架或完整应用程序的形式；也可以是例程、类或封装组件。它可以包括模型和算法。无形资产的例子包括编程知识、编程计划、软件系统架构、项目计划、设计文档、用户文档和其他相关知识来源。

与数据一样，资产需要存储在磁盘上以便重用。然而，资产比简单的业务数据要复杂得多，而且很难存储和访问。在此基础上，提出了几种新的处理资产及其元数据语义的数据库范式。这包括复杂对象模型、嵌套关系数据模型和面向对象数据模型。

访问这些资产主要是通过对象查询完成的。资产存储为对象或对象集合。查询使用的元数据通常是类定义和类层次结构。类定义非常类似于表定义，但有一些例外。它们包括属性定义以及类的方法定义。构建类层次结构时使用的三种主要关系是聚合、部分-整体和泛化。聚合关系处理相关类之间的关系。例如，课程班与学生班和教师班有关。另一方面，部分-整体涉及构图。例如，车辆类由底盘类、发动机类等组成。泛化（也称为“IS-A”）关系用于显示类之间的分类。例如，机动车辆和飞机类是车辆类的子类。生成关系允许子类继承超类的属性。

随着数据库管理系统通过索引访问数据，访问资产的查询最终会从数据库中找到资产的所有部分，并将它们组合起来创建资产。但是，有时很难将资产存储为数据库中的对象集合。这是因为资产可能是无法分解为对象的包（如代码包或文档）。

90年代

在20世纪90年代，有三个独立的研究范式出现，它们负责推动元数据技术的发展。下面将逐一描述。

代码可重用性的元数据

软件开发中的代码可重用概念始于20世纪80年代，当时日本的软件工厂，在20世纪90年代变得非常重要。

为了提高代码的可重用性，软件开发环境的研究蓬勃发展。软件开发环境（SDE）是软件和硬件工具的集合，专门为支持特定应用领域中软件系统的生产而定制。SDE在其所有操作中都使用元数据。使用元数据的目的是支持选择SDE中使用的工具。这些环境分为三大类：编程环境（PE）、案例和软件工程环境。PE是一种主要用于支持编程、测试和调试过程的环境。案例是支持软件规范和设计的环境。它还可以与编程环境一起使用。SEE旨在支持大型、长寿命软件系统的研发，其维护成本通常超过开发成本，由团队而不是单个程序员研发。

资产存储库中的元数据

资产存储库（也称为存储库）是一个共享的数据库，其中包含有关项目文档的信息，如软件、文档、地图和其他东西。换句话说，存储库是一个元数据管理器。例如，支持软件开发和部署工具的存储库可以存储元数据，如数据库描述、表单定义、控件、文档、接口定义、源代码、帮助文本和其他。在存储库上下文中使用元数据的目的是强调选择和集成支持不同类型数据的各种工具。

数据仓库中的元数据

由于数据仓库概念的出现，元数据在20世纪90年代发挥了重要作用。数据仓库的元数据基本上分为两类：后台元数据和前台元数据。后台元数据与流程相关，并指导提取、清洗和加载流程。示例包括通常与源数据相关的规范，如源数据格式、源的所有权描述、数据清洗规则、维度和其它；数据转换日志；和DBMS系统表内容。前台元数据更具描述性，有助于查询工具和报表的顺利运行。示例包括连接规范、网络安全用户权限配置文件、使用和访问映射、网络安全使用统计信息和其他。

随着软件项目越来越多地集中于代码、类、组件、模式、框架和应用程序的集成和重用，资产存储库的需求在20世纪90年代末变得至关重要。在传统行业和互联网企业大量使用数据仓库技术来开发使用大量运营数据的决策支持，也推动了这种需求增长。

2000年以后

在2000年初，处理元数据的主要工作是认识到创建元数据标准的必要性。这个标准是由这样一个事实推动的：与软件开发不同，数据仓库项目需要异构的工具和数据环境。例如，在数据仓库世界中，数据质量工具、数据建模工具、ETL工具和最终用户工具由不同的供应商开发，具有完全不同的规格。使用元数据标准的集成允许它们彼此通信。数据仓库中的数据也可以是各种类型和格式。标准化工作也将有助于数据集成。

元数据管理的发展

元数据虽然最初是用来描述数据或资产的信息，但现在却在与它定义的资产或数据竞争以获得同等的关注。随着元数据在软件开发、数据库管理和数据仓库设计与实现中的显著应用，研究元数据管理技术显得尤为重要。

为了正确地描述元数据管理器的发展，我从一组使用元数据隐式管理数据的工具开始。从这个阶段，我将描述元数据管理是如何逐步从隐式管理转变为与资产和数据共同管理，然后再转变为与存储库管理器进行显式管理的。

第一阶段：隐式元数据管理

甚至在数据库管理系统出现之前，软件库管理器就已经开始尝试离散地使用元数据来重用代码。它旨在共同管理数据和元数据。大多数编程语言允许应用程序包含来自其软件库的代码。软件库是可以在构建大型程序模块时重用的程序集合。在这种编程环境中，语言编译器将程序转换为对象模块。然后，使用基础元数据的链接器组合组成程序的所有对象模块，包括从库中获取的对象模块。一些示例库是C++类库、标准C库和微软的MFC库。

尽管元数据和数据的联合管理并不复杂，但是像这样的库是相当静态的。一旦一个库被开发出来并发布到外部世界，它的结构和界面就不可能改变，而用户群也不会有很大的困难。使用库相当于使用编程语言。类库中的更改通常比编程语言中的更改更难处理。

第二阶段：元数据的共同管理

随着数据库管理系统的出现，对元数据的管理更加明确。这一思想被用来使库管理器更加动态化，用户需要一种机制来轻松地插入、删除、修改和检索库的内容。

为了创建对库的简单操作，我们将元数据与库一起使用。在这种技术中，需要捕获代码的元数据，并与实际的库一起使用。代码的元数据包含有关代码的数据。其思想是将元数据存储在数据库中。如果软件库得到更新，数据库中的相应条目将被更改。

第三阶段：明确的元数据管理

在这个阶段，元数据及其管理逐渐成熟。元数据现在不再是一个附带问题，而是被视为绑定许多企业资源（如MIS程序、ERP、和数据仓库）的粘合剂。元数据管理工具（也称为存储库）现在变得至关重要。

这方面的第一次尝试是引入数据字典。数据字典通常非常注重数据。它提供了一个关于数据的集中信息库，如含义、关系、来源、域、用法和格式。数据字典的目的是帮助DBA规划、控制和评估数据的收集、存储和使用。

为了保存其他非软件项，引入了第二种机制，称为存储库。存储库是一个共享的数据库，可以存储数据库描述、表单定义、控件、文档、接口定义、源代码、帮助文本等。

在20世纪80年代后期，IBM提出建立一个通用存储库，这个存储库可以存储各种case工具的输出，并使存储的元素对任何请求它们的工具都可用。不幸的是，由于软件行业从COBOL定位向C/C++方向的转变，以及从主框架到客户机-服务器，IBM的存储库从未被交付。然而，在20世纪90年代后期，这个想法又被其他已经开发了几个存储库的供应商所接受。这些供应商包括Microsoft（带Microsoft存储库）、Unisys（带通用存储库）、Computer Associate（带白金存储库）、Viasoft（带Rochade存储库）、SoftLab（带启用程序存储库）和Oracle（带Oracle存储库）。

为了理解存储库的组成，我简单描述一下存储库的重要特性。存储库的第一个特性是它管理的元数据类型。这些类型包括数据库元数据、数据模型元数据、数据传输元数据、业务规则元数据、应用程序组件元数据、数据访问元数据和与数据仓库相关的元数据。存储库的其他功能包括描述存储库核心元数据类型的信息模型；作为工具正式规范语言的规范语言；支持跨不同产品的工具互操作性的语言；查询元数据的标准查询语言等。

第四阶段：元数据集成管理

此阶段的重点是管理应用程序中不同元数据的集成。有两种集成：工具集成和数据集成。工具通常生成特定于工具的元数据。为了在多个工具之间建立通信，需要集成这些元数据。同样，数据可以是不同的格式，也可以来自不同的世界。这些数据还需要集成以帮助决策支持。最初为管理元数据而创建的存储库技术（第三阶段）可用于集成。

上面描述的存储库技术支持元数据集成，只要元数据遵循通用模型，比如微软的组件对象模型（COM）体系结构。在各种元数据集成的世界中，例如当前数据仓库域中使用的工具没有通用的模型。这是因为项目中引入了来自具有不同规格（或元数据）的不同供应商的不同工具。工具可以是“同类最佳”、“最兼容”或“最经济”。

20世纪90年代，元数据联盟（MDC）和对象管理小组（OMG）两个标准化小组开始研究元数据标准，他们将元数据标准称为元模型。20世纪90年代末，MDC集团与微软一起开发并采用了一种称为开放信息模型（OIM）的元数据标准。另一个组OMG在2000年初创建了一个名为Common Data Warehouse Meta Model（CWM）的模型。2000年6月，MDC成员决定加入OMG，支持元数据中的一个标准进行集成。

未来展望

元数据仓库的主要挑战是开发一种能够捕获分散在数据仓库项目中的元数据并将其放入元数据仓库的设计方法。目前尚不清楚如何做到这一点。设计方法会遵循任何数据仓库设计技术，还是会是一种新技术？

其次，需要对元数据仓库的ETL工具进行设计和开发。在元数据中使用当前的ETL工具有些不寻常。我认为元数据与常规数据非常不同，需要以不同的方式处理。

再次，需要为元数据仓库开发最终用户工具。元数据仓库的最终用户活动从版本控制（存储库活动）跨越到变更管理决策支持（仓库类型活动）。我们可能需要向下钻取或向上钻取最终用户的数据，就像在常规数据仓库中那样。

最后，元数据仓库与现有数据仓库的集成问题非常重要。由于元数据仓库是一种新事物，我们需要弄清楚如何将其与现有的数据仓库结合起来。元数据仓库将与数据仓库分开，还是与数据仓库集成？