详解数据仓库的数据维——上下文

「数仓宝贝库」，带你学数据！

过去，典型的操作型信息系统将注意力集中在企业的当前数据上。在操作型世界中，强调的重点是此刻账目的余额是多少，此刻的存货有多少，或此刻货物的运送情况如何。当然，任何一个企业都有必要知道当前的信息。但对过去一段时间的信息进行考察也有真正的价值，并且，在有了数据仓库技术以后，这个要求变得可能了。例如，对历史信息进行观察就可以明显地看到相应的发展趋势，而仅仅查看当前信息是看不到这一点的。数据仓库定义中的一个最重要特征就是能够对一段时间内的数据进行存储、管理和访问。

伴随着作为数据仓库一部分的足够长的时间谱，出现了一个新的数据维—上下文。为了阐明上下文信息的重要性，下面给出了一个例子。

例子

假定一个管理者想从数据仓库中要一份1995年的报表。报表生成后，管理者很满意。事实上，由于管理者很满意，所以想要一份1990年的报表。由于数据仓库载有历史信息，这样的要求并不难实现。1990年的报表生成了。现在，管理者手上有两份报表—1990年和1995年各一份，并宣布这些报表是一场灾难。

数据仓库体系结构设计者检查了报表，发现1995年的财政报告显示收入为50 000 000美元，而1990年的报告对同一种类显示为10 000美元。管理者宣称任何账户或分类都不可能在5年时间内就增长这么多。

就在要放弃之前，数据仓库体系结构设计者向管理者指出，还有一些相关的因素没有在报表中体现出来。1990年和1995年的数据是从不同来源得到的；1990年的产品定义不同于1995年的；1990年和1995年有不同的市场范围；1990年和1995年有不同的计算方法，如针对贬值问题。另外，还有许多不同的外部因素需要考虑，如在通货膨胀、税款、经济预测等方面的差别。一旦把报表的上下文向管理者解释之后，内容就在相当程度上显得可接受。

在这个简单而又常见的例子中，如果随着时间变化数据的内容没有任何附加信息，那么内容本身就是非常难于解释和难以令人相信的。然而，随着时间的变化同时，把上下文加入到数据的内容上，内容和上下文都变得非常明了。

为了解释和理解一段时间内的信息，需要一个全新的上下文维。虽然信息的内容仍十分重要，但是，一段时间内信息的比较和理解使得上下文和内容具有同等的重要性。而在过去的几年中，上下文一直是信息的一个未被发现、未被探索的维。

上下文信息的三种类型

需要管理三种级别的上下文信息：

1.简单上下文信息。

2.复杂上下文信息。

3.外部上下文信息。

简单上下文信息

简单上下文信息与数据本身的基本结构有关，包括如下一些内容：

■ 数据的结构。

■ 数据的编码。

■ 数据的命名习惯。

■ 描述数据的度量，如：

• 数据量有多少。

• 数据增长速度。

• 数据的哪一部分在增长。

• 数据是如何被使用的。

以往，简单上下文信息用字典、目录、系统监视器等进行管理。复杂上下文信息描述的数据和简单上下文信息描述的相同，但是从不同的角度进行描述。复杂上下文信息如下说明数据：

• 产品定义。

• 市场范围。

• 定价。

• 包装。

• 组织结构。

• 配送。

复杂上下文信息

复杂上下文信息是一些非常有用，同时又是非常难以捉摸的信息。难以捉摸是因为它被人们想当然，并存在于背景环境中。它非常基本，以致于没有人会想到要定义它是什么，或怎样随时间变化。然而，长期下去，复杂上下文信息在理解和解释一段时间内的信息方面有着非常重要的作用。

外部上下文信息是处于企业之外的、在理解随时间变化的信息方面起重要作用的信息。外部上下文信息的实例包括：

■ 经济预测：

• 通货膨胀。

• 金融。

• 税务。

• 经济增长。

■ 政治信息。

■ 竞争信息。

■ 技术进展。

■ 用户人数的统计变动。

外部上下文信息

外部上下文信息并没有直接指出关于一个企业的任何事情，但指出了企业运转和竞争中所处的大环境。考虑到外部上下文信息的立即显现和随时间变化的特性，外部上下文信息是很令人感兴趣的。同复杂上下文信息一样，很少会有企业尝试去采集和量度这些信息。外部上下文信息非常之多，也很显然，以致被人们想当然，因此，它会很快被遗忘，而在需要时却又很难重建。

捕获和管理上下文信息

复杂上下文信息和外部上下文信息难以捕获和确定，是因为这些信息都是非结构化的。与简单上下文信息相比较，外部上下文信息和复杂上下文信息显得非常杂乱无章。另外的一个较轻的因素是上下文信息变化很快。这一刻相关的信息，在下一时刻就消失了。正是因为外部和复杂上下文信息的这些不断变化和没有固定状态的特点，使得这种类型的信息难于系统化。

回顾上下文信息管理历史

有人可能会争辩说，信息系统行业在过去已经有了上下文信息。字典、知识库、目录和库都是用来管理简单上下文信息的尝试。尽管有这些好的想法，但存在的一些明显的局限性大大地降低了它们的有效性。下面给出以往管理简单上下文信息的方法存在的一些缺点：

• 信息的管理是针对信息系统的开发者，而不是最终用户。这样，对于最终用户有很少的可视性。结果，最终用户对并不明显的事情没有什么热情，或者不支持这样的事情。

• 这些上下文信息管理的尝试都是被动的。开发者可以选择用或不用这些上下文信息管理工具，很多人倾向于回避这些工具。

• 这些上下文信息管理的计划在很多情况下都会被从开发计划中删除。在许多的实例中，应用是在1965年开发的，而数据字典是1985年做的，而到了1985年，就再也没有更多的开发经费了。甚至，那些对组织和定义简单上下文信息最有帮助的人早已改行或到了其他公司了。

• 这些上下文信息管理的尝试仅局限于简单上下文信息，并没有尝试去捕获或管理外部和复杂上下文信息。

作者简介：

William H.Inmon，世界公认的“数据仓库之父”，企业信息工厂创造者之一。