最近在整理档案时，我发现了一篇1976年发表的关于数据字典/目录系统的文章，作者是L. Delport。如今我们已不再使用“数据字典/目录系统”这一术语，而是用“数据目录”或简称“元数据系统”。但在当时，这正是用来指代存储、描述和管理元数据的系统的流行术语。
元数据管理这些年来有改善吗？
我决定阅读这篇文章，因为我想知道这些年来元数据的管理状况有何改善。不过归根结底，这篇文章其实是在抱怨各组织在元数据管理方面存在诸多问题。让我印象深刻的是，作者提出的几乎所有批评意见至今仍适用于许多组织。因此，读完这篇文章后我得出的结论是：半个世纪以来 ，元数据管理并没有太大变化。（顺便说一下，我还有一个大胆的计划，那就是把那篇文章中的部分术语替换成现代用语，然后重新发表。我敢打赌，如果我真的这么做了，大多数读者根本不会注意到这篇文章其实写在半个世纪以前 。）
为什么元数据管理至今仍未发生变化呢？很少有人会认为元数据不重要。事实上，大多数人都持相反观点。那么，我们为何不更好地管理元数据，更明智地为组织提供相关支持呢？换言之，为什么元数据仍然在IT领域被忽视呢？这对我来说仍然是个谜。
我的一般建议是，设计元数据架构时应与设计数据架构的方式相同。这需要了解需要访问元数据的用户和应用程序的需求。让我举几个例子来说明。
分析需求
过去，元数据主要供IT专家使用。他们需要详细了解各种文件、表格和列的含义。这种需求依然存在，但现在有更多新用户对元数据感兴趣。如今，业务用户——尤其是那些负责开发自定义仪表盘和数据科学模型的人——也需要访问元数据。他们需要查看文件的描述、分类信息、来源等细节，以便清楚地了解自己所处理的数据。他们必须能够搜索元数据，以找到适合制作报告或数据科学模型的正确数据。此外，元数据还有助于他们理解数据的含义。因此，我们需要详细分析业务用户需要哪些类型的元数据。
了解用户如何获取元数据也很重要。例如，对于需要处理大量财务数据的商务用户来说，应能轻松获取各项数值的说明。当用户将鼠标悬停在某个具体数值上两秒钟时，可能希望自动显示该元数据的详细信息。他们不想为了获取这些说明而启动单独的系统，因为那样既不方便又浪费时间。因此，了解用户使用元数据的方式非常重要。
元数据也可以成为操作系统的一部分。例如，如果为不同的数据对象分配了不同的安全级别，那么相关的数据隐私和安全规则就可以参照这些级别来执行。没有适当权限的用户组将无法查看具有高安全级别的列内容。
如今，出于数据隐私、安全、可审计性和可管理性考虑，必须妥善管理元数据，而这可能需要采用强大的版本控制机制。
企业用户可能希望以注释的形式自行添加元数据描述。同样，为了设计合理的元数据架构，这也是一个重要的需求。
此外，还必须从其他系统中输入和提取元数据。在提取元数据时，可能需要采用类似ETL的解决方案，定期从源系统中提取元数据，因为元数据可能会发生变化。需要注意的是，元数据的ETL处理并不只是从结构化数据源中提取元数据，还可能包括从ETL程序、数据库存储过程以及报告工具的语义层中提取元数据描述。元数据ETL的来源并不总是数据库，有时也可能是代码和规范文件。
在未来的架构中，元数据不可或缺
所有这些要求并非凭空出现，必须经过分析、设计及开发才能实现。因此，建筑师们应充分了解这些要求。要实现这一点，需要使用合适的工具，同时必须对元数据进行有效管理，以确保其能被正确访问。
在未来的数据架构中，无论是数据网状结构、数据织物结构、数据仓库还是数据湖屋架构，元数据都不可或缺。尤其是对于那些需要自行开发仪表盘和报告的现代商业用户而言，他们需要能够无缝访问元数据。
我知道这一切听起来像是在做显而易见的事，但那么为什么在半个世纪后 ，元数据仍然被视作IT领域被忽视的环节呢？其实不该如此。
