元数据内容模型

再来说说元数据，从开始对元数据模糊的概念，渐渐地清晰了一些。原来总觉得"描述数据的数据"这个定义有些故弄玄虚，但似乎这么解释确实是比较精练的，只是这种表述让人不易理解。

有必要将这两个数据区分开来。出现的第一个"数据"，是指存在于企业IT环境中的有形的数据，是企业日积月累沉积下来的资产，就像日积月累沉积下来的客户资源一样，都是有价值的，因此需要让他们可以被管理。对客户，有客户管理、客户关系管理等系统，是用数据模型来描述这些实体，例如客户姓名＝"张三"，这也就形成一批数据。那么对于这些数据资源，当然也有必要管理起来，因此传统的数据库系统都会记录"客户这种数据，有哪些属性"，这就是元数据了，在数据库环境中，通常也叫数据字典。

不过元数据并非仅仅描述实体的属性、属性的属性之类的，这是数据包含什么。还有其他一些信息需要描述，知道了数据包含"什么"，还要知道"谁"使用这些数据，"如何"使用这些数据，数据质量"如何"，数据的位置在"哪儿"，"何时"采集的这些数据，"何时"被使用，"为何"存在等。

因此，第二个数据虽然在形式上也是一种数据，和描述客户的数据没什么两样（也是用表、关系、属性来表现的），但其内容才是区别之处。它描述的对象都是那些IT环境中的数据、关系、文档、代码等物，相对于第一个"数据"，后者描述的对象多是存在企业环境中，实实在在参与的对象，例如客户、员工、供应商、设备等。

关于这点，曾经在BI领域细分之数据管理中提到了一些。

可以继续深入一些，元数据究竟该有哪些内容呢？从上面的描述中，可以看到一些单词，"什么"、"谁"、"如何"等…，这是从数据的使用角度考虑的，而从数据的生命周期考虑，我想可以整成下图这个矩阵，姑且称之为"元数据内容模型"吧。

这当然还需要细化。

长期以来，元数据管理实在是让人摸不清头脑的，因为其目的性不强。确实，如果企业对自己的数据就像对待客户、设备一样看待，认为有需要管理起来并优化他们的必要。那时，元数据才能发挥更大的作用。

没有这个数据管理的需求，那么即便是那些大型的系统，诸如boss、erp，其中数据也未必有上面那些信息。这是明智的，加了这些信息，当然会占用更多的存储，需要消耗更多的执行时间，对于大数据量，很多事务的情况下，能省就省吧。可这种状况必定是要改变的，将数据看作是一种"东西"并管理之是个趋势。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友