谈谈数据的用途和分类

作者：Jerome 20070110

看"BI 2006十大亮点"的帖子，又链接到了Qing的一个老帖子，写的就是数据的用途的分类。那个帖子写的比较久了，大家也该忘记了，我把它翻出来给大家加深一下印象，望Qing兄-不要见怪。

目前对数据的分类和定义非常多，那些老外吃饱了撑的没事干，专门造名词。他们用英文定义的词就不太统一，翻译过来更是比较乱。

我试着在Qing兄的基础上整理一下，希望大家能提出宝贵意见给指正。

先说http://www.dmreview.com/article_sub.cfm?articleId=1033570文章中提到的五个数据分类。

1.Meta data - 元数据
这个以前说起来还挺神秘的一个词，现在可能是最统一的一个关于数据的词了。它的含义、用途和分类大家应该都比较清楚了，这里也就不多说了。

2.Systems/applicaion data - 系统/应用数据
从那篇文章看，这个数据应该是指的是诸如那些在以前编写程序中写到.ini、注册表或者.properties中的描述参数的数据。在数据仓库系统中，这种数据-不怎么使用。

3.Transactional data - 事务数据
事务数据指的是应用程序中记录的企业的各种交易信息数据。

4.Reference data - 参照数据
参照数据是用来描述事务数据的数据，也就是用来描述Transactional data的数据。
这样来解释3和4有点迷糊，说的更明白一点，Transactional data指的是如销售单、出库单之类的数据，Reference data指的是客户的信息、仓库的信息之类的数据。从维度建模的角度，可以理解Transactional data是迁移入数据仓库后成为事实数据的数据，Reference data是迁移入数据仓库后成为维度数据的数据。这样来理解的话，Reference data其实英文名子起的不太好，很让人引起混淆。不过也难怪，3NF建模的数据库中，还没有一个好的名称用来描述诸如维度数据这类的数据，叫Referenc-e data也无不可。

5.Master data - 主数据
主数据应该是现在说的比较多的数据，它应该和前四个数据的分类方式就不同，所以放到一起也是容易混淆。
要说明主数据含义，举个例子来说明可能简单一点。假设一个企业有三个系统，每个系统都维护的客户信息表。对于同一个客户"客户甲"，在第一个系统中名称为"客户-甲"，在第二个系统中名称为"甲客户"，第三个系统中为"真的客户甲"。那么三个系统很难进行数据交互，为了解决这个问题，可以在另一个地方建立一个客户表，给-这个客户起个名字叫"终极客户甲"，并做好和其他几个系统的关联。这个在另一个地方建立的客户表描述了企业统一的客户信息，也就是我们说的主数据。
主数据应该是需要不断维护的，随着企业内各个系统内数据的变化而变化。
主数据应该描述的是Reference data部分的。而Transactional data没必要建立主数据。
我们回过头来考虑一下主数据和数据仓库的关系。他们的目的和要求都非常的相似。没有数据仓库，可以建立主数据表，有了数据仓库，主数据其实可以建立在数据仓库中-。对于bus architecture来说，我觉得主数据就是conformed dimension，在staging area中保存并维护conformed dimension，同时分发都各个数据集市。

再补充几个：
6.System of record - 系统记录

这又是一个容易混淆的名词。
Kimball的书中称system of record是起始数据来源，即最早产生数据的地方。企业中的数据会冗余的保存在很多地方，而最早生成数据的地方就是system of record。例如，信用评级系统评出客户的信用等级为AAA，信贷系统也需要这个信用等级，所以把信用等级迁移过去。但是信用等级肯定是信用评级系统产生的，-所以对于信用等级信息来说，信用评级系统的数据是system of record，而信贷系统的信用等级不能算。将来做数据迁移时需要从这些确定为system of record的地方进行数据抽取。
Inmon的书中称system of record是指数据仓库能得到的数据质量最好的源系统的数据，数据质量包括准确、最新、完整。

个人感觉，和master data相对，system of record主要是针对transactional data而言，即业务操作产生的记录数据。这样的transactional data一般的情况下，最早产生的地方也就是最准确、最新和最完整的地方。所以kimball和inmon对system of record的定义的差别并不算大。总归我们可以明白system of record是做源系统数据分析后，找到的最准确，并准备从这里进行数据抽取的地方。

7.Application data - 应用数据
8.Enterprise data - 企业数据
名词7和8是一对相对的概念，和前面的分类标准也不相同。应用数据指各个独立的业务系统记录的数据，这些数据是未经过整合的数据。
一般情况下，应用数据是transactional data和reference data的合集。
而企业数据刚好与应用数据相对应，是从应用数据迁移过来并整合好的一致的数据。
假设企业一开始没有任何信息系统，直接上了一套ERP系统，各个系统之间的数据本身就是整合好的，那么也就直接建立了企业数据。
所以应用数据和企业数据的本质区别在于是否是整合好的一致的数据。

9.Data linage - 数据世系
数据世系是描述数据在迁移的过程中的变化的数据。它描述的是从源系统抽取数据开始，经过数据转换到最终的数据加载的整个过程中各种信息。属于元数据的一部分。

还有诸如维度数据、事实数据、快照数据等大家常见的分类名词这里就不罗嗦了，欢迎大家补充一些易混淆的数据分类名词，或者指正前面的不妥之处。

作者：Qing 20070111

对于这些数据的分类，始终是让人觉得头大，虽然在dmreview中的文章中对每种每类作出解释，但也不敢确定所有人都是认同这种解释的。

比如现在对于主数据，有此处理解为描述对应关系的，或是描述实体的。这种分类应该是从数据的描述的对象来区分的吧，抛开那些名词，应该有如下几种：

1、描述实体的。此处的实体跟关系数据库理论里面的实体有些区别，是类似"客户"、"产品"这样的东西，是在问题域中被抽象出来的某种概念。我想成为"东西"可-能更容易明白些，这个"东西"，有诞生、有过程、有结束。这里特意加了一个限定词——"问题域"，意思是说，描述的对象是业务需求领域范围的"东西"。如果，我-将"数据"看作东西的话，不算，那算元数据。

2、描述在实体身上发生的事件的。谁，在什么地方，什么时间发生了一件什么事情，并且这个事件也是属于业务问题域的。称这为一个"事件"，或者称之为"交易"。-比如通话详单、ATM取款交易都算这种，取款记录描述了哪个客户，在哪台ATM，何时取了多少钱。

3、描述数据的数据。以上描述实体的，描述事件的数据，如果将它们也当作"东西"，同样需要记录。当然，要值得区分的是，"数据"这个东西并非在业务问题域里面-，而是在系统管理、架构的层面。比如，一条取款记录包括哪些信息，什么时间产生，什么时间被同步到另一个库里面去。同样，"数据"这个东西同样也有实体和事件之-分。数据的诞生、消亡是在实体层面的描述，而数据的迁移，便是事件。

4、描述数据对应关系的数据。这是当存在不一致数据的情况下，需要一个标准。那就描述这个标准跟其他非标准数据的对应关系，强调的是对应关系。

这四种倒是能够跟dmreview文中的五种分类对应四种。至于那种叫做系统/应用数据的，文中注明为系统配置信息，我想这些数据描述的对象无非还是"实体"，-比如有些系统设计里面会将所有可配置信息放在一个"包"里面，这不也是可以看成是业务领域的一个实体吗。而上面提到的第四种数据，描述对应关系的数据，跟前三个-也不是同一层面，他只是在有数据不一致的情况下才有。难道不可以认为"数据之间的对应关系"是一种数据吗？那样，其实他是一种描述数据的数据，也即元数据了？

胡思乱想一番，有些头晕。

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

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