Inmon vs Kimball：DW 2.0

随着拉尔夫·金博尔（Ralph Kimball）博士出版了他的第一本书“The DataWarehouse Toolkit”（《数据仓库工具箱》），数据仓库行业就开始喧哗起来，恩门的“Building the Data Warehouse”主张建立数据仓库时采用自上而下（DWDM）方式，以第3范式进行数据仓库模型设计，而他生活上的好朋友Ralph Kimball在“The DataWarehouse T oolkit”则是主张自下而上（DMDW）的方式，力推数据集市建设，以致他们的FANS吵闹得差点打了起来，直至恩门推出新的BI架构CIF（Corporation information factory），把Kimball的数据集市包括了进来才算平息。

Ralph Kimball和Bill Inmon一直是商业智能领域中的革新者，开发并测试了新的技术和体系结构。

他们都撰写了关于数据仓库的多本书籍，这些书也经常被参考。

Kimball 和Inmon 都同意组织需要一个与遗留系统和联机事务处理（OLTP）系统分开的数据仓库，以捕获组织的有关信息并且使之可用。

他们也同意数据仓库中的数据应该是净化的、一致的，并且不受到其来源的遗留系统和OLTP 系统设计的牵制。

在开始第一个数据集市之前他们还同意用针对整个体系结构的思想重复构建数据仓库。

到这里，他们的意见就发生了分歧。

Bill Inmon将数据仓库定义为“一个面向主题的、集成的、随时间变化的、非易变的用于支持管理的决策过程的数据集合”（Building the data warehouse，第2 版，第33 页）。

Inmon通过“面向主题”表示应该围绕主题来组织数据仓库中的数据，例如客户、供应商、产品等等。

每个主题区域仅仅包含该主题相关的信息。

数据仓库应该一次增加一个主题，并且当需要容易地访问多个主题时，应该创建以数据仓库为来源的数据集市。

换言之，某个特定数据集市中的所有数据都应该来自于面向主题的数据存储。

Inmon 的方法包含了更多上述工作而减少了对于信息的初始访问。

但他认为这个集中式的体系结构持续下去将提供更强的一致性和灵活性，并且从长远来看将真正节省资源和工作。

Ralph Kimball说“数据仓库仅仅是构成它的数据集市的联合”（Figure 2，The Data Warehouse Lifecycle Toolkit，第27 页）。

他认为“可以通过一系列维数相同的数据集市递增地构建数据仓库”。

每个数据集市将联合多个数据源来满足特定的业务需求。

通过使用“一致的”维，能够共同看到不同数据集市中的信息，这表示它们拥有公共定义的元素。

Kimball的方法将提供集成的数据来回答组织迫切的业务问题并且要快于Inmon的方法。

Inmon的方法是只有在构建几个单主题区域之后，集中式的数据仓库才创建数据集市。

而Kimball认为该方法缺乏灵活性并且在现在的商业环境中所花时间太长。

从Inmon被人尊称为数据仓库之父，就可以看出，inmon对于数据仓库领域的技术发展作起的作用的巨大的，无数数据仓库爱好者甚至把《建设数据仓库》看作是数据仓库的“圣经”。

inmon自己创建的网站上的文章被广为传颂，每当有inmon公开演讲的时候，很多用户和技术人员都把能够聆听inmon的最新成果为荣。

在企业信息工厂的设计蓝图中，inmon 清除地描述了如何从各种业务系统当中捕获需要的数据，并在随后的流程中，为适应不同的需求，而逐渐演变为各种不同的形态，所有的这一切都围绕着一个最重要的部件来运转，这就是企业数据仓库。

在国内数据仓库领域，inmon和kimball的理论也一度争论不休，但是随着数据仓库建设的逐步深化，把企业数据仓库作为企业数据整合平台的思路深得人心，越来越多的企业开始强调在企业内部建立一个企业级别的数据仓库来支持整个企业的发展和运作。

数据仓库的分层可以算是数据仓库架构的子话题。

在前段时间参与的一次讨论中，笔者发现其中争论的焦点集中在每一层的作用、特点、是否有必要存在等问题。

其中，大家虽然一致提到某些相关概念，但各方的理解却并非完全一致。

例如对于ODS是什么、维度建模是什么等问题的解读，都是如此。

不妨想想看：数据从分散而异构的数据源中长途跋涉，到最终的报表、仪表盘、OLAP 应用等等，让用户看到一致的结果，这是一个过程。

记得以前有个矿泉水广告，说要经过N 层的过滤才得到了那种水。

而数据仓库也一样，从原来乱七八糟的数据到交付到用户手中的“纯净”数据，也需要这样一个过滤过程，需要各种不同的过滤装置。

这个过滤过程，我们可以称之为ETL；而那些过滤装置，就可以看作数据仓库的分层。

从目前来看，还没有非常统一的分层方法，其中，Inmon和Kimball是最具代表性的两种分层方法。

Inmon与Kimball在Inmon提出的CIF（Corporate Information Factory，企业信息工厂)中，他将ODS （Operational Data Store，操作型存储）、EDW（Enterprise Data Warehouse，企业数据仓库）、DM（DataMart，数据集市）区别开来，共分三层。

相对于此，Kimball的总线架构强调多个数据集市合成了数据仓库，只是他们基于统一的维度而已。

因此，总线架构的分层中，从数据源接口就直接到了DM了。

根据这两种思路，又可以衍生一些不同的方法。

例如IBM就提出一种CDW的概念，叫做企业数据仓库层，这一层介于EDW和DM之间，起过渡作用（因为EDW和DM两层的建模理念是不同的）。

除了这些分层，大家都还认同一个Staging Area（集结地）的地方。

这是用于ETL过程中数据的临时存储，可究竟这个区域是位于接口到ODS之间，还是ODS到DW之间，或是CDW到DM之间，并没有达成一致的意见。

在笔者看来，既然它是用于ETL中间数据缓存的，那么，在以上每一层都会需要，它是一个每层共用的存储区域。

ODS层与DW层对于ODS层，一般大家都能够认同它是一种操作型比较强的、未保留历史或者保留近期历史的数据。

所谓操作型，是相对分析型而言的。

后者多是汇总的、便于分析统计的结构。

操作型的另一个特点就是经常会被更新，而分析型数据很少如此。

然而，对于ODS的认识，也有不同。

常见的争议包括：ODS是否应该被最终用户访问？ODS存在的目的是仅仅供DW层获取经过清洗的数据，还是能够让用户从中得到统计报表？关于前一个问题，在笔者以前做经营分析的时候，就曾遇到这样的争议；关于后一个问题，如果让它仅仅具备前一项功能，倒是结构清晰、易于管理，是一种好的设计风格，但恐怕不能满足用户灵活的需求。

而如果可以让用户查询统计，可能造成它统计的数据和DW统计的数据不一致。

对于DW层，一般大家都会认同，这是保留历史数据的地方。

但它是按照第三范式还是维度建模呢？当然，最大的不同就是：是需要一个中心DW，还是一个由若干数据集市组成的“虚拟”的DW。

至于DM层，对此基本有一致的认同，这是面向最终用户分析统计的，采用维度建模再好不过。

可因为对DW层建模方法的不同观点，因此也就出来了所谓CDW的提法。

想想，如果DW是按照第三范式建模，而DM是按照维度建模的话，那么它们之间该如何过渡？看上去，CDW确实也有存在的必要，在这个区域，需要形成满足总线架构所需的一致性维度（Confirmed Dimension）和一致性事实（Confirmed Fact）。

但问题是，第三范式和维度建模难道就真得水火不相容？笔者更相信一个道理—架构中没有绝对的设计原则。

所谓第三范式，只是指出一种理想的ER（实体-关系模型）设计模式，但实际做设计时，设计师大多会去做一些平衡，他们也许会说，“为了性能、应用方便，会考虑适当的冗余。

”可这适当冗余不也就破坏了第三范式吗？而且这个“适当”谁也说不准是多少。

因此，可以理解EDW并不是绝对的第三范式，而所谓维度建模又能够和第三范式有多少冲突呢？在其本身概念里面，星型模式是一种不太符合第三范式的ER结构，但只是不“太”，如果改成雪花模式，是不是也就是第三范式了呢？名词与真义具体要采用哪种分层方法还得视项目大小而言。

对于大项目，或是大的集成商来实施，恐怕多会采用复杂的分层方法。

其实分层越细，每层的功能也就越单一，它们之间的耦合程度也就越单一。

当然这也是需要衡量的，因为分层多了，ETL过程自然也就复杂，那对于数据质量的控制也就变得麻烦——在多个层里面可能都存在同样意义的数据，需要保证它们是一致的。

像IBM、NCR这样的厂商，他们大多走的Inmon路线。

经过多年的经验总结，都已有自己的企业概念模型，这也非常适合走分层明确、具有中心数据仓库的路线。

在Inmon的体系中，EDW是按照第三范式建模的。

之所以要强调这种思想，是因为第三范式能够让数据模型变得简洁、高度一致性。

对数据仓库的一个目的——统一口径（Single Version of Truth），是非常有帮助的。

另一方面，Kimball的维度建模理论，即按照事实表、维表来构建数据仓库、数据集市，也已经在很多实践中被证明是非常有效的方法。

可这种建模方法和第三范式多少有点冲突。

例如在维表中，不同粒度的数据放在一种表里面，即存在大量的数据冗余。

但这种方法对数据仓库四大特点之一的“面向主题”，又是有利的。

如此看来，大家提到的方法似乎都是从不同角度去看，没有绝对的对错，只是在为维护自己的观点而争论。

具体采用何种分层，还得看项目投资大小、数据量多少以及业务逻辑复杂程度而定吧。

说句题外话，或许当概念太多的时候，我们最应该做的就是要抛开那些容易混淆视听的名词，去探察其真正的意义所在。

Bill Inmon和Ralph Kimball，在上学的时候接触到的两个名字，对于大多数人来说，这两个美国人显得有些陌生，但是在数据库领域，他们可是响当当的人物。

Bill Inmon，被称为“数据仓库之父”，现在可以在网上看到他大把大把的学术性论文和文章，Wikipedia上对他的介绍应该是非常全面的：在上世纪80年代，Inmon的《建立数据仓库》一书中定义了数据仓库的概念，随后又给出了更为精确的定义：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。

与其他数据库应用不同的是，数据仓库更像一种过程，对分布在企业内部各处的业务数据的整合、加工和分析的过程。

而不是一种可以购买的产品。

Ralph Kimball同Bill Inmon相类似，甚至提出数据仓库的概念更早，只不过当初他只是提出了一种自下而上的架构，Inmon则将一系列的理论进行了总结。

Inmon和Kimball两种DW架构支撑了数据仓库以及商业智能近二十年的发展，其中Inmon主张自上而下的架构，不同的OLTP数据集中到面向主题、集成的、不易失的和时间变化的结构中，用于以后的分析;且数据可以通过下钻到最细层，或者上卷到汇总层;数据集市应该是数据仓库的子集;每个数据集市是针对独立部门特殊设计的。