元数据（Metadata）是描述数据的数据。元数据按用途不同分为技术元数据、业务元数据和管理元数据。
技术元数据（Technical Metadata）：描述数据系统中技术领域相关概念、关系和规则的数据；包括数据平台内对象和数据结构的定义、源数据到目的数据的映射、数据转换的描述等；
业务元数据（Business Metadata）：描述数据系统中业务领域相关概念、关系和规则的数据；包括业务术语、信息分类、指标、统计口径等；
管理元数据（Management Metadata）：描述数据系统中管理领域相关概念、关系、规则的数据，主要包括人员角色、岗位职责、管理流程等信息。
元数据管理（Meta Data Management） ）是数据资产管理的重要基础，是为获得高质量的、整合的元数据而进行的规划、实施与控制行为。元数据管理的内容可以从以下六个角度进行概括，即“向前看”：“我”是谁加工出来的；“向后看”：“我”又支持了谁的加工；“看历史”：过去的“我”长什么样子；“看本体”：“我”的定义和格式是什么；“向上看”：“我”的父节点是谁；“向下看”：“我”的子节点是谁。
元数据管理内容描述了数据在使用流程中的信息，通过血缘分析可以实现关键信息的追踪和记录，影响分析帮助了解分析对象的下游数据信息，快速掌握元数据变更可能造成的影响，有效评估变化该元数据带来的风险，逐渐成为数据资产管理发展的关键驱动力。
以上均引用《数据资产管理实践白皮书4.0》 的原文，这也是传统意义上理解的元数据相关的概念。
在DAMA数据管理知识体系指南中文版还做了形象的比喻，将元数据和图书馆的目录卡片做类比，目录卡片记录了书籍的书名、作者、主题标签、ISBN号、出版社、出版日期，这其实属于技术元数据范畴，因为这是书籍的原始标准信息的客观描述；如果把书籍的分类、书籍介绍或其他拓展信息放到目录卡片里即为业务元数据，因为这是图书的业务领域描述；如果把书籍的管理员、采购员、审计人员、采购时间放到目录卡片中，即为管理元数据；对于古籍书籍而言，普通用户一般是无法借阅的，如果把书籍的借阅等级和用户等级要求也放到卡片里就是安全元数据；再如果把书籍的折旧期限，保存期限放到卡片里，就是生命周期元数据了。当然作为目录卡片而言，一般不会把所有相关内容释放出来，但出于安全、管理要求又是切切实实在后台存在着的。
数据资产管理实践白皮书和DAMA数据管理知识体系指南中文版中都定义了元数据管理、主数据管理、数据质量管理、数据安全管理；个人认为DAMA数据管理知识体系指南中文版对元数据管理的理解更胜一筹，而且对各种元数据的描述上也更为精确和全面；不过为了表述方便，两者都有意的把各种数据管理做了割裂。
目前绝大多数元数据管理系统都是按照技术元数据、业务元数据、管理元数据来开发和设计的，尤其强调了血缘关系；强调血缘关系确实是对的，尤其是在数据仓库系统中，数据仓库是天然的靠血缘关系支撑的系统，但业务系统的血缘关系并非那么明显；即使在数据仓库中，血缘关系并非想象的那样唾手可得，绝大多数元数据管理工具的血缘关系大多来自于表的主外键依赖关系和对存储过程的解析，对于ETL工具而言则来自于ETL开发过程；简而言之，我们看到的和处理后的血缘关系只是冰山一角，大量的有用的信息还沉在冰山之下。
为什么这么说呢，现在绝大多数OLTP和OLAP系统都很少使用主外键，绝大多数OLTP系统都比较少使用存储过程，出于开发和迁移的便捷考虑，大多数都采用ORM映射方式或SQL语句，这导致在我们的系统中无法发现表和表之间的关系，字段和字段级的关系；解决方案是什么呢？其实在DAMA数据管理知识体系指南已经给了我们答案了，技术元数据包括物理数据库表名和字段名、字段属性、其他数据库对象的属性和数据存储特性。数据库管理员需要了解用户的访问频率和报表和查询的执行时间。通常可以通过DBMS内的程序或其他软件以获取技术元数据。
1、数据表的访问频率，可以从另一面发现表的价值，可以发现孤立表和热表
2、数据表的更新频率和变化，可以帮我们评估表的有效程度
3、数据表索引的多少和使用与否，可以发现表的设计是否合理
4、和数据表相关的SQL的查询执行时间，可以发现表的设计是否合理
5、系统数据字典中各SQL中相关表的运行频次和运行效率，可以发现表的设计是否合理，以及表的利用效率
6、系统数据字典中各SQL相关的表的连接属性和次数，可以发现表与表的关系和连接属性，以及表的设计是否合理，通过知识图谱表达后，可更进一步可以实现业务场景的聚合，反向帮我们生成全局E-R关系结构。
7、通过基于表结构的相似度比较，可以帮我们评估系统设计是否合理，是否重复建设
8、通过跨域表结构的相似度比较，可以帮我们发现各业务系统中高度相同或相似的表，并建立起全业务域的企业E-R关系模型和数据地图。
关于业务元数据，更多的是实现对业务术语、信息分类、指标、统计口径的定义，这个需要通过管理手段来强制要求和提供，同样需要业务部门的参与，确保业务元数据的有效性和价值。
关于管理元数据，看起来比较容易，但难在执行环节，数据质量可根据技术元数据提供的规则或业务规则，有效的发现数据的准确性、一致性、完整性，也可以生成相关质量报告，但数据的整改往往很难执行下去，主要问题就出在管理元数据上。很多企业的基础数据是靠主数据进行流转分发的，而不同业务系统为了自身的便宜往往在原有的主数据基础上进行修改、删除或新增，导致基础数据在不同系统之间出现不一致情况越来越严重，企业会花大量的时间和成本开展账实核查，运动式的账实核查也解决不了根本问题。因此明确数据的录入责任、使用责任、管理责任至关重要，需要构建数据治理团队或数据运营团队帮助梳理各数据表各数据项的相关责任分工，并固化到管理元数据中，结合数据质量管理，生成绩效报告，开展数据认责，这是另外一方面的问题了，在此不做详述。
关于安全元数据和数据生命周期管理，甚至数据标准，也可以扩充到元数据管理范畴。
元数据管理能否用好，重要的一点在于强制性，元数据变更管控是个不错的切入点，要求在系统变更时，各级审核人员基于元数据的血缘关系和相关价值，对数据变更的范围和影响要做出准确的评价；其次是审核结构变更能否满足数据标准要求；再次确认变更前后的元数据是否一致；没有强制，元数据就没有太大存在价值。
还有一点元数据管理的价值在于能否有效支撑其他系统，比如通过标准API或提供标准界面实现和其他系统的融合，帮助业务人员有效理解相关业务。
再有一点，很多人认为可以靠元数据可视化工具即可实现业务人员对数据的开发，这一点是极其可笑的，元数据在大多数情况下还是给有一定技术背景的人去使用的，想简化数据开发或者让业务人员去实现简单的开发，这点需要建立在数据模型的基础上，并通过数据资产管理来实现。
最后想表达的是，单纯的元数据管理存在的价值还是极其有限的，必须把元数据管理和数据标准、数据质量、数据资产、数据安全、数据认责等管理结合在一起，并通过各种服务向外提供给业务系统，才能真正发挥元数据的价值。
