数据仓库工作总结(转自CSDN的转载)

1.   概述

本文作为我这些年实施数据仓库的总结，如有错误，请各位同仁指正。

文档条理不是很清楚，而且也有很多口水话，我不想搞成一个真正的官方文档，所以很随意，符合我的性格。很多问题我只是提出来了，解决方案没有想好，也不知道怎么落到文字，就先提出来备注吧。

文档原本想讨论的元数据管理、数据质量和监控工具的内容，由于时间关系，没有添加，以后有空补上吧。

1.1.阅读方法

本文阅读方式:

1、 如果你认为本节没有意义，请将第二节作为第一节。

2、 如果你觉得第二节没有意义，请将第三节作为第一节。

3、 归纳：如果你觉得第X节没有意义，请将X+1节作为第一节。

4、 如果你觉得整个文档都没有意义，恭喜你，你打开了一个无用的文档。

1.2.感谢

(这段应该好好写)

谢谢党和国家给我这么一个大环境，让我可以安居，让我可以娶妻生子，更重要的是让我可以在三个代表的光辉下茁壮成长。

感谢那些给我无穷压力也被我无数次暗骂的客户们：贵州联通、广西联通、云南联通、重庆移动、江西移动、浙江移动、吉林移动、天津电信、河北移动、山东移动。没有他们的刻薄，我也无法作出这个东西。

感谢我的妻子，忍受我长期的出差，更重要的是对我职业选择的包容和理解。

2.   定义

2.1.定义的混淆

和客户交流的时候开始的第一个麻烦可能就是数据仓库的概念问题，怎么看怎么觉得“数据仓库”应该是一个实体概念，但是实际数据仓库只是一个过程，而不是一个产品。过程就是计划如何工作的单元，而不是实际工作的单元。

数据仓库是这么定义的：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。

这个定义中有一个定义比较容易含混，那就是“面向主题”。面向主题是指数据仓库围绕一些主题,排除对于决策无用的数据,提供特定主体的简明视图。近年提出的“面向专题”的分析和这个概念混淆的厉害，只能用用户熟悉的业务才能作出解释。

以下列出几个概念，备查：

BI：商业智能（Business Intelligence）,指数据仓库相关技术与应用的通称。指利用各种智能技术，来提升企业的商业竞争力。

BPR:业务流程重整（Business Process Reengineering）,指利用数据仓库技术，发现并纠正企业业务流程中的弊端的一项工作。数据仓库的重要作用之一。

OLAP

定义1 ：OLAP(联机分析处理)是针对特定问题的联机数据访问和分析。通过对信息(维数据)的多种可能的观察形式进行快速、稳定一致和交互性的存取，允许管理决策人员对数据进行深入观察。

定义2 ：OLAP(联机分析处理) 是使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术。(OLAP委员会的定义)

OLAP的目标是满足决策支持或多维环境特定的查询和报表需求，它的技术核心是“维”这个概念，因此OLAP也可以说是多维数据分析工具的集合。

ROLAP:基于关系型数据库的OLAP称为Relational OLAP，简称ROLAP。代表产品有Informix Metacube、Microsoft SQL Server

MOLAP(MuiltDimension OLAP):严格遵照Codd的定义，自行建立多维数据库，来存放联机分析系统数据,简称MOLAP，代表产品有Hyperion Essbase等。

HOLAP:混合OLAP。

Server OLAP:数据在服务器端处理

Client OLAP:部分数据下载到本地，为用户提供本地的多维分析。代表产品有Brio Designer, Business Object.

2.2.数据仓库能给客户带来什么？

客户的第二个问题就是，数据仓库能够给客户带来什么？或者说为什么使用数据仓库。还是一个比较难以回答的问题。

一般数据仓库的入门指导的开篇都会有这么一个论调，这个论调基本集中在数据存储的周期、数据存储容量、数据响应性能以及对在线事务系统(OLTP)的压力的问题。

但是单纯这一点就足以说服客户么？(插一句，我不管商务怎么去谈的单子，我只说怎么面对客户的刁难。)以上提出的论调肯定客户也了解的。原因很简单，有一点用心的客户都会事先进行相关资料的查阅。

我对于“实用”这个词比较敏感，我想在介绍数据仓库的时候更多的关切到用户的实际需求去谈可能效果会更好。有一家公司的仁兄去讲他的PPT的时候，前面有好十好几张都是数据仓库的理论知识，这个家伙上台打开PPT就说“我们主要讲业务，前面的都是理论，我一张张念完就行了，大家如果有兴趣自己回去翻阅”。有点门道吧？客户面对的厂商不见得比我们面对的客户少，老听这些，客户自己都能讲出个123来——虽然还不知道怎么去玩转这个东西。

换个角度来看，客户被灌输的这方面理论已经不少，数据仓库难讲就在于没有一个直观的东西（整个快速原型？如果公司有那么多资源或者以前实施过倒也问题不大。），很多东西都隐藏在实施中，留给客户的就是一堆文字描述，客户被搞得头昏，自己也说得嘴巴乏味。

一个假设，如果客户有一台超级强悍的主机，已经有一个非常稳定的在线系统，而且更要命的是客户已经在这台主机上实现了一个快速响应的报表系统。你如何说服客户使用数据仓库？使用这种技术意味着客户会为移动数据、数据准确性甚至为多了的主机操心。我只是想提醒一下，不是任何时候都需要建立一个数据仓库的。如果在这个环境中，更多的工作可能是集中在数据仓库的实用价值之上。

所幸的是，托硬件厂商的福。我们现在还没有拥有这样的主机。所以现实情况中的种种不如意还是值得说道说道。

2.3.就是一个复杂的报表系统

回到刚才的问题，数据仓库是什么？

有次我们做经营分析系统的操作培训完后，酒席上一位地市分公司的负责人说了一句“你们经营分析系统搞了这么久，不就是一个复杂的报表系统么?”。

的确，他说的是实话，一个复杂的报表系统的确是数据仓库应用的表征。

如果要试着向客户解释那么一套什么持久啊时间啊存储时限啊企业级啊之类的概念，那么这个问题你还是会输掉。一个复杂的报表系统（大型客户所使用的报表系统基本都是）底层基本也是按照数据仓库的这几个流程走的，只是规模较小、流程不规范而已。

如果这时客户再问，“我现在的报表系统为什么不能称为数据仓库应用？”，这下应该苦笑了。

数据仓库对于非技术人员，本身就是一个复杂的报表系统，所有后台的操作最终目的都是为了呈现结果给客户，所以这么说一点也没错。认同这一点有点不容易，甚至有些令人泄气。但是事实就是如此，数据仓库除了报表