数据仓库的粗略发展历程及相关概念1.1 概述数据仓库的概念可能比一般人想像的都要早一些，中间也经历比较曲折的过程。
其最初的目标是为了实现全企业的集成（Enterprise Integration），但是在发展过程中却退而求其次：建立战术性的数据集市（Data Marts）。
到目前为止，还有很多分歧、论争，很多概念模棱两可甚至是彻底的让人迷惑。
本文试图从数据仓库的发展历史中看到一些发展的脉络，了解数据仓库应该是怎么样的，并展望一下未来的数据仓库发展方向。
同时，由于新应用的不断出现，出现了很多新的概念和新的应用，这些新的应用如何统一现成完整的企业BI应用方案还存在很多争论。
本文试图对这些概念做一些简要的阐述，让大家对此有初步的了解。
1.2 粗略发展过程1.2.1 开始阶段（1978-1988）数据仓库最早的概念可以追溯到20世纪70年代MIT的一项研究，该研究致力于开发一种优化的技术架构并提出这些架构的指导性意见。
第一次，MIT的研究员将业务系统和分析系统分开，将业务处理和分析处理分成不同的层次，并采用单独的数据存储和完全不同的设计准则。
同时，MIT的研究成果与80年代提出的信息中心（Information Center）相吻合：即把那些新出现的、不可以预测的、但是大量存在的分析型的负载从业务处理系统中剥离出来。
但是限于当时的信息处理和数据存储能力，该研究只是确立了一个论点：这两种信息处理的方式差别如此之大，以至于它们只能采用完全不同的架构和设计方法。
之后，在80年代中后期，作为当时技术最先进的公司，DEC已经开始采用分布式网络架构来支持其业务应用，并且DEC公司首先将业务系统移植到其自身的RDBMS产品：RdB。
并且，DEC公司从工程部、销售部、财务部以及信息技术部抽调了不同的人员组建了新的小组，不仅研究新的分析系统架构，并要求将其应用到其全球的财务系统中。
该小组结合MIT的研究结论，建立了TA2（T echnical Architecture 2）规范，该规范定义了分析系统的四个组成部分：♦数据获取♦数据访问♦目录♦用户服务其中的数据获取和数据访问目前大家都很清楚，而目录服务是用于帮助用户在网络中找到他们想要的信息，类似于业务元数据管理；用户服务用以支持对数据的直接交互，包含了其他服务的所有人机交互界面，这是系统架构的一个非常大的转变，第一次将交互界面作为单独的组件提出来。
1.2.2 全企业集成（Enterprise Intergration，1988）同时，IBM也在处理信息管理不同方面的问题，其最烦人的问题是不断增加的信息孤岛，IBM 的很多客户要面对很多分立系统的数据集成问题，而这些系统有不同的编码方式和数据格式。
1988年，为解决全企业集成问题，IBM爱尔兰公司的Barry Devlin 和Paul Murphy第一次提出了“信息仓库（Information Warehouse）”的概念，将其定义为：“一个结构化的环境，能支持最终用户管理其全部的业务，并支持信息技术部门保证数据质量”，并在1991年在DEC TA 2的基础上把信息仓库的概念包含进去，并称之为VITAL规范（virtually integrated technical architecture life cycle），将PC、图形化界面、面向对象的组件以及局域网都包含在VITAL 里，并定义了85种信息仓库的组件，包括数据抽取、转换、有效性验证、加载、Cube开发和图形化查询工具等。
但是IBM只是将这种领先的概念用于市场宣传，而没有付诸实际的架构设计。
这是IBM有一个领域上创新后停止不前导致丧失其领先地位。
因此，在90年代初期，数据仓库的基本原理、框架架构，以及分析系统的主要原则都已经确定，主要的技术，包括关系型数据存取、网络、C/S架构和图形化界面均已具备，只欠东风了。
同时，在1988年－1991年，一些前沿的公司已经开始建立数据仓库。
1.2.3 企业级数据仓库（EDW，1991）1991年，Bill Inmon出版了其有关数据仓库的第一本书，这本书不仅仅说明为什么要建数据仓库、数据仓库能给你带来什么，更重要的是，Inmon第一次提供了如何建设数据仓库的指导性意见，该书定义了数据仓库非常具体的原则，包括：♦数据仓库是面向主题的（Subject-Oriented）、♦集成的（Integrated）、♦包含历史的（Time-variant）、♦不可更新的（Nonvolatile）、♦面向决策支持的（Decision Support）♦面向全企业的（Enterprise Scope）♦最明细的数据存储（Atomic Detail）♦数据快照式的数据获取（Snap Shot Capture）这些原则到现在仍然是指导数据仓库建设的最基本原则，虽然中间的一些原则引发一些争论，并导致一些分歧和数据仓库变体的产生。
但是，Bill Inmon凭借其这本书奠定了其在数据仓库建设的位置，被称之为“数据仓库之父”。
1.2.4 数据集市（1994－1996）数据仓库发展的第一明显分歧是数据集市概念的产生。
由于企业级数据仓库的设计、实施很困难，使得最早吃数据仓库螃蟹的公司遭到大面积的失败，因此数据仓库的建设者和分析师开始考虑只建设企业级数据仓库的一部分，然后再逐步添加，但是这有背于Bill Inmon的原则：各个实施部分的数据抽取、清洗、转换和加载是独立，导致了数据的混乱与不一致性。
而且部分实施的项目也有很多失败，除了常见的业务需求定义不清、项目执行不力之外，很重要的原因是因为其数据模型设计，在企业级数据仓库中，Inmon推荐采用3范式进行数据建模，但是不排除其他的方法，但是Inmon的追随者固守OLTP系统的3范式设计，从而无法支持DSS系统的性能和数据易访问性的要求。
这时，Ralph Kimball出现了，他的第一本书“The DataWarehouse T oolkit”掀起了数据集市的狂潮，这本书提供了如何为分析进行数据模型优化详细指导意见，从Dimensional Modeling 大行其道，也为传统的关系型数据模型和多维OLAP之间建立了很好的桥梁。
从此，数据集市在很多地方冒了出来，并获得很大成功，而企业级数据仓库已逐渐被人所淡忘。
1.2.5 争吵与混乱（1996-1997）企业级数据仓库还是部门级数据集市？关系型还是多维？Bill Inmon 和Ralph Kimball一开始就争论不休，其各自的追随者也唇舌相向，形成相对立的两派：Inmon派和Kimball派（有点象少林和武当，呵呵）。
在初期，数据集市的快速实施和较高的成功率让Kimball派占了上风，但是很快，他们也发现自己陷入了某种困境：企业中存在6－7个不同的数据集市，分别有不同的ETL，相互之间的数据也不完全一致。
同时，各个项目实施中也任意侵犯了Inmon开始定下的准则：把数据集市当成众多OLTP系统之后的有一个系统，而不是一个基础性的集成性的东西，为保证数据的准确性和实时性，有的甚至可以由OLTP系统直接修改数据集市里面的数据，为了保证系统的性能，有的数据集市删除了历史数据。
等等，不一而足。
当然，这导致了一些新的应用的出现，例如ODS，但是人们对DataWarehouse、DataMart、ODS的概念非常的模糊，经常混为一谈。
有人说OLAP就是数据仓库，也有人说我要ODS和DataMart，不要Datawarehouse，也有人说，我DataMart建多了，自然就有DataWarehouse了。
但是Bill Inmon一直很旗帜鲜明：“你可以打到几万吨的小鱼小虾，但是这些小鱼小虾加起来不是大鲸鱼”1.2.6 合并（1998－2001）经过多翻争吵，证明one-size-fits-all是不可能的，你需要不同的BI架构来满足不同的业务需求。
Bill Inmon也推出了新的BI架构CIF（Corporation information factory），把Kimball 的数据集市也包容进来了，第一次，Kimball承认了Inmon，但是仍然还有很多人在争论是自顶向下，还是自底向上。
CIF的核心思想是把整个架构分成不同的层次以满足不同的需求，把DW、DM、ODS进行详细的描述。
现在CIF已经成为建设数据仓库的框架指南。
1.2.7 未来？？但是数据仓库未来会怎么发展呢，有人说是RealTime DW（by Michael Haisten）。
但是从其历史发展过程来看，几个趋势是比较明显的：♦从战略决策到战术决策的发展：这对DW的实时性和可获得性（availability）有更高的要求，甚至要求7×24×365♦需求更加多样化，要求有不同的架构和应用层次以适应不同的需求♦数据量膨胀，对数据建模、数据组织和层次划分提出更高的要求。
从EDW到DM，又有ODS、RTDW、Exploration DataWarehouse等等，同时新的应用层出不穷，看来DW/BI的未来是热热闹闹的。
1.3 战术决策支持系统数据仓库从一开始是定位在面向高层管理者、进行战略决策支持的，而随着应用的发展，要求中层管理者甚至底层的一线操作者也能分享数据仓库的功能。
例如客服人员在接听客户电话的同时能查看到该客户的完整历史信息、该客户的偏好信息、根据其客户情况目前能提供的促销信息等等。
即运营系统与决策支持系统将不再是完全隔离的两个系统，而是要求二者之间能相互共享有用的信息。
1.3.1 战术决策支持系统的交互方式运营系统和DW/DSS系统的交互方式可以有两种：直接交互和间接交互。
直接交互直接交互虽然在表面上很直观，但是有很多限制的地方：1. 数据仓库的查询反应速度是比较长的，很难满足运营系统的时间要求，特别是对那些比较随机的查询，其反应时间超过好几分钟，甚至上小时。
2. 得到的数据量可能是比较大的，增加了网络的负担3. 从数据仓库得到的数据格式、数据含义等与运营系统有差距，需要某种数据置换和加载过程（与数据仓库建设的ETL区分，可以称之为反向ETL）这些问题使得由运营系统直接访问数据仓库系统变动不切实际，在现实世界中也很少有这样的系统建设。
间接交互间接交互中，通过分析系统计算出该客户能得到的折扣是最重要的组成部分，他需要综合当前的运营数据（运营系统）和历史消费信息（数据仓库）。
通常来说，这部分计算要求的数据量和计算时间超过了运营系统能承受的范围，一般是在机器空闲的时候在夜间先行计算的。
这种间接交互的分析型应用可以存在很多行业的众多应用，例如银行信贷系统的动态评级、电话销售时的客户细分和促销、航空定票的动态定价、生产系统的动态生产计划制定与调整等等。