“数仓宝库”，带你学习数据！
传统上，典型的操作型信息系统关注的是企业当前的数据。 在操作型的世界里，现在的账面余额是多少，现在的库存是多少，或者现在货物的运输状况如何都是被强调的。 当然，任何企业都需要知道当前的信息。 但是考察过去一段时间的信息也有真正的价值，在有了数据仓库技术之后，这个要求就成为了可能。 例如，观察历史信息的话，可以明显看到与之相对应的趋势，但只看现在的信息是看不到的。数据仓库定义中的一个最重要特征就是能够对一段时间内的数据进行存储、管理和访问。
随着作为数据仓库一部分的足够长的时间谱，出现了新的数据维— 上下文。 为了明确上下文信息的重要性，以下是一个例子。
例子
假设一个管理员想要来自数据仓库的1995年的报告。 报告生成后，管理员感到满意。 其实，管理员很满意，所以我想要1990年的报告。 由于数据仓库中包含历史信息，因此这些请求不容易实现。 生成了1990年的报告。 目前，管理员手中有两个报告，1990年和1995年，这些报告被宣布为灾难。
数据仓库体系结构的设计者检查了报告后发现，根据1995年的财政报告，收入为50，000，000美元，而1990年的报告对于同一种类为10，000美元。 管理者声称任何账户或分类都不可能在五年内增长这么多。
就在放弃之前，数据仓库体系结构的设计者向管理者指出了一些报告中没有出现的要素。 1990年和1995年的数据来自不同的来源1990年的产品定义与1995年的不同1990年和1995年有不同的市场范围1990年和1995年有不同的计算方法，例如对贬值问题。 另外，还需要考虑通货膨胀、税收、经济预测等各种外部因素。 如果向管理员说明报告的上下文，则内容相当可以接受。
在这个简单而一般的例子中，随着时间的经过，如果数据的内容中没有追加信息，则内容本身非常难以解释，难以置信。 但是，随着时间的推移，把上下文加入到数据的内容上，内容和上下文都变得非常明了
为了说明和理解一段时间内的信息，新的上下文维信息的内容仍然很重要，但是信息的比较和理解在一段时间内，上下文和内容变得具有同等的重要性。 这几年，上下文是信息的未发现、未探索的维度。
上下文信息的三种类型
需要管理以下三个级别的上下文信息：
1 .简要上下文信息。
2 .复杂的上下文信息。
3 .外部上下文信息。
简单上下文信息
简单上下文信息涉及数据本身的基本结构，包含以下内容。
数据结构。
数据编码。
数据命名习惯。
描述以下数据的度量
数据量是多少？
数据增长速度。
数据的哪些部分在增加？
数据是如何被使用的？
以往，简单的上下文信息通过词典、目录、系统监视器等进行管理。 复杂语境信息描述的数据与简单语境信息描述相同，但从不同的角度进行描述。 复杂的上下文信息说明数据，如下所示。
产品的定义。
市场范围。
决定价格。
包装。
组织的结构。
配送。
复杂上下文信息
复杂的上下文信息在非常有用的同时，也是非常难以掌握的信息。 之所以难以捉摸，当然是因为它与背景环境共存。 因为它是非常基本的，所以没有人能想到它是什么，以及它如何随时间变化。 但从长期来看，复杂的上下文信息在理解和解释一定时期内的信息中起着非常重要的作用。
外部上下文信息是在理解企业外部的、随时间变化的信息中起着重要作用的信息。 外部上下文信息的示例如下：
经济预测：
通货膨胀。
金融业。
税务。
经济增长。
政治信息。
竞争情报。
技术进展。
用户数的统计变动。
外部上下文信息
外部上下文信息没有直接指出一个企业，但指出了企业运营和竞争中的大环境。 考虑到外部上下文信息的即时性和时变特性，外部上下文信息非常有趣。 与复杂的上下文信息一样，很少有企业试图收集和测量这些信息。 外部的上下文信息非常多，很明显，被人们认为是理所当然的事情，所以很快就会被忘记，在必要时很难重构。
捕获和管理上下文信息
复杂的上下文信息和外部上下文信息是非结构化的，因此很难捕获和识别。 与简单的上下文信息相比，外部
部上下文信息和复杂上下文信息显得非常杂乱无章。另外的一个较轻的因素是上下文信息变化很快。这一刻相关的信息，在下一时刻就消失了。正是因为外部和复杂上下文信息的这些不断变化和没有固定状态的特点，使得这种类型的信息难于系统化。回顾上下文信息管理历史
有人可能会争辩说，信息系统行业在过去已经有了上下文信息。字典、知识库、目录和库都是用来管理简单上下文信息的尝试。尽管有这些好的想法，但存在的一些明显的局限性大大地降低了它们的有效性。下面给出以往管理简单上下文信息的方法存在的一些缺点：
信息的管理是针对信息系统的开发者，而不是最终用户。这样，对于最终用户有很少的可视性。结果，最终用户对并不明显的事情没有什么热情，或者不支持这样的事情。
这些上下文信息管理的尝试都是被动的。开发者可以选择用或不用这些上下文信息管理工具，很多人倾向于回避这些工具。
这些上下文信息管理的计划在很多情况下都会被从开发计划中删除。在许多的实例中，应用是在1965年开发的，而数据字典是1985年做的，而到了1985年，就再也没有更多的开发经费了。甚至，那些对组织和定义简单上下文信息最有帮助的人早已改行或到了其他公司了。
这些上下文信息管理的尝试仅局限于简单上下文信息，并没有尝试去捕获或管理外部和复杂上下文信息。
作者简介：
William H.Inmon，世界公认的“数据仓库之父”，企业信息工厂创造者之一。