关于“元数据”的理解
一直都对元数据一知半解，当然理论我都知道，但是主要是没有实际应用过，所以对这方面的知识还是比较好奇，想多了解一下。最近又看到一篇关于“元数据”的文章，发现写得不错，摘录下来留存。
元数据
元数据(Metadata)：就是数据的数据，用于建立、管理、维护和使用数据仓库。元数据管理是企业级数据仓库中的关键组件，贯穿于建立数据仓库的整个过程。
元数据使得用户可以掌握数据的历史情况，如数据从哪里来？流通时间有多长？更新频率是多大？数据元素的含义是什么？对它已经进行了哪些计算、转换和筛选等等。在需求不确定情况下，在瞬间万变的商业环境下，元数据可以更好的支持需求的变化，降低项目风险。
元数据贯彻于建立数据仓库的整个过程，不只是ETL过程需要元数据的支持。
元数据分类
通常把元数据分为技术元数据(Technical Metadata)和业务元数据(Business Metadata)。
技术元数据
是描述关于数据仓库技术细节的数据，这些元数据应用于开发、管理和维护数据仓库，它主要包含以下信息。
1、数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；
2、业务系统、数据仓库和数据集市的体系结构和模式；
3、汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚合、汇总和预定义的查询与报告；
4、由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则及安全（用户授权和存取控制）。
业务元数据
从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法及公式和报表的信息。
在信息打包过程中，需要用包图表示维度和类别还有它们之间的传递和映射关系，实际上这个操作就是在原业务系统的基础上创建了元数据。其中的维度、类别还有层次关系是属于典型的技术型元数据，而业务系统中与之对应的术语则属于业务元数据。比如日期、区域、产品、客户年龄和客户状况等维度，实际销售、计划销售、预测销售、计划偏差和预测偏差等指标皆属于元数据。这些数据在分析中起到了极为重要的作用。
元数据的作用
从元数据的类型和作用来看，元数据实际上是要解决何人在何时、何地为了什么原因及怎样使用数据仓库的问题。再具体化一点，元数据在数据仓库管理员的眼中是数据仓库中的包含了所有内容和过程的完整知识库和文档，而在最终用户（即数据分析人员）眼中，元数据则是数据仓库的信息地图。
数据分析员为了能有效地使用数据仓库环境，往往需要元数据的帮助。尤其是在数据分析员进行信息分析处理时，他们首先需要去查看元数据。元数据还涉及到数据从操作型环境到数据仓库环境中的映射。当数据从操作型环境进入数据仓库环境时，数据要经历一系列重大的转变，包含了数据的转化、过滤、汇总和结构改变等过程。数据仓库的元数据要能够及时跟踪这些转变，当数据分析员需要就数据的变化从数据仓库环境追溯到操作型环境中时，就要利用元数据来追踪这种转变。另外，由于数据仓库中的数据会存在很长一段时间，其间数据仓库往往可能会改变数据的结构。随着时间的流逝来跟踪数据结构的变化，是元数据另一个常见的使用功能。
元数据描述了数据的结构、内容、链和索引等项内容。在传统的数据库中，元数据是对数据库中各个对象的描述，数据库中的数据字典就是一种元数据。在关系数据库中，这种描述就是对数据库、表、列、观点和其他对象的定义；但在数据仓库中，元数据定义了数据仓库中的许多对象——表、列、查询、商业规则及数据仓库内部的数据转移。元数据是数据仓库的重要构件，是数据仓库的指示图。元数据在数据源抽取、数据仓库开发、商务分析、数据仓库服务和数据求精与重构工程等过程都有重要的作用，元数据在整个数据仓库开发和应用过程中的巨大影响。因此，设计一个描述能力强并且内容完善的元数据，对数据仓库进行有效地开发和管理具有决定性意义。
*******************************************************
在数据仓库中，元数据的概念被强化了，在每个数据仓库项目的总体架构图中，几乎都有”元数据治理”模块来横贯其他模块。显然，这表示它是一种基础模块，可以服务于诸如OLAP、ETL等其他模块。但实际上，却很少见一个完成了的数据仓库项目中有独立的元数据部分。大多项目，元数据都是分散在各种BI工具中。
这些分散的元数据是不一致的，例如对一张表的结构定义，可能出现在ER设计工具中，当然也会在数据库的数据字典中，还有可能在ETL工具的源、目标定义中。如此多的重复定义，当然会发生数据不一致现象，却也正好为元数据治理工具留下广阔空间，它们的作用就是集中治理这些分散的元数据，就像数据仓库一样，从不同的源采集数据，有ETL，也有清洗，甚至重新建模。
元数据(metadata)这个词现在到处泛滥。其实我对元数据充其量只能说有自己的理解而已，并不能确信这个理解是正确的。
我认为，数据结构分为三个层次(UML可是四层哦)：
实例层：直接描述特异化的数据场景；
元数据层：描述实例的结构的一组数据；
元数据的元数据层：描述元数据的结构的一组数据。
元数据就是用来描述实例或者描述元数据的一种结构。
元数据的特征有这样几个：第一是元数据一定不依赖业务反而被业务所依赖，相当业务的多变性，元数据是相对稳定的；第二是元数据具有广泛的可复用性，而业务的可复用性极差；第三是元数据注重结构，而业务注重行为。
在Xml中，元数据就是模式(Schema)，在数据库中，元数据就是数据库对象定义，包括表、视图、关系约束、存贮过程、触发器、函数、数据库用户、数据库角色等等定义。在对象空间，元数据就是类型、接口、方法、方法参数、属性的定义。在结构化程序空间，元数据就是函数及函数的参数。
我之所以反复强调参数，是因为我们在定义一个接口或者方法的参数时总是非常随便，但定义一个Xml文档模式或者数据库对象时总是小心翼翼的，很受束缚。这显然有一定的不合理之处。仔细推敲，我的结论就是：第一，我们设计每个方法的参数时，特别是设计每个虚拟方法的参数时一定要小心一点，尽量不要滥用参数重构。第二，我们在设计一个Xml文档结构或者数据库结构的时候可别那么畏首畏尾的，就象平时写程序时设计一个方法的参数那样。这样就平衡了。
总结以往多年的数据库设计，我归纳为两个原则和两个方法：
降冗优先原则(降冗是数据库设计时的首要要素)；
平行引用原则(所有的关系都必须是单向的并且不能交叉)；
依职责拆分方法(同一基数不同职责或者不同的维护方法或者不同的维护期必须拆分)；
依基数合并方法(同一基数且职责相同必须合并)。
忽然发现，其实这些原则和方法在整个元数据层都适用，不仅仅只针对数据库设计。
*******************************************************