基础理论：数据仓库DW的辩识

基础理论：数据仓库DW的辩识

数据仓库的认识误区

提起数据仓库，现在对很多人来说并不陌生，但大多数人并未系统地读过数据仓库的经典论著，更没有经历过成熟的数据仓库项目，因此无论他们仅仅限于探讨有关数据仓库的话题，还是尝试数据仓库的项目，往往不解数据仓库的真谛，尝试的项目很可能是无疾而终，甚至连数据仓库的基本概念都没有真正理解。

数据仓库是现在越来越热的话题，但大多数人，无论是客户还是开发商，往往在不明确、不成熟的数据仓库需求与不清晰、不深刻的数据仓库知识间徘徊。一方面，很多客户积累了大量的业务数据，总想从中得到些什么，甚至有了一些具体的想法，另一方面，一些软件开发商在潮流的推动下，找来一些有关数据仓库的书，也学用一些有关数据仓库的软件工具，在数据仓库项目上跃跃欲试。学费总是要花的，数据仓库的项目也是这样。但与一些IT技术项目不同的是，这次学费是花了，但怎么不见迅速长进？近些年,我们在国内遇到不少这样的事，客户与开发商开始是热情高涨，双方不仅投入了不菲的金钱和人力，但结果与期望相差甚远。因此，有些人甚至开始怀疑数据仓库的技术的可行性及有效性了。确实，从朴素意义上讲，做好哪一件也不容易，往往需要对真理的不断追求与对实践的不断尝试，做好数据仓库是在啃一块硬骨头。我们的体会是，首先以源头开始，扎扎实实地走每一步。急功近利的做法，跨越式地发展，尤其在数据仓库方面是终究要跌跟头的，因为这些想法与做法不符合客观事物发展的规律！科学的数据仓库技术发展的步骤是，首先学习数据仓库的经典知识，然后尽可能地学习数据仓库项目的成熟的技术和经验，甚至不惜到其发源地和技术领先的国家去求经验，然后不断地自我实践，不断地总结与提高。

我们首先来看看大家在数据仓库概念上有哪些误区吧。

1. 数据仓库是个非常大的数据库。

很多人望文生义，数据既然到了仓库的量级，那肯定是非常大的数据。不错，数据仓库往往是个海量的数据集，但它不是必要条件。在数据仓库经典定义中，也没有数据仓库是大数据的概念。实际上，很多好的数据仓库项目，从当今的社会信息规模来看，并不是数据量很大，但它们确实给业务分析带来了很好的效益。因此评价一个数据仓库，从来没有用大小来衡量的。

2. 数据仓库是将所有的业务数据存在一起的。

数据仓库的一个目标是将分散的业务整合在一起的，但它往往是有目的地按分析需去实施的，并不是将全部的业务数据统统都集成在一起，更不是像有些人完全地将所有的业务数据集中地存储在一起的，在这里既没有有效地数据整合，也没有按分析需要去集成数据，只是一个集中式的庞大数据堆。

3. 数据仓库是一次性的工程

我们曾经见过这样一个单位，他们骄傲地告诉我，他们做一个大的数据仓库，这项工程已经完成了，他们会在需要的时候，到仓库中分析一些数据。开始我们产生了一个疑问，这些需求不是日常的和周期性的吗？后来我们才知道，他们只是将历史的数据截止到每一个时间，弄到了一个专用的数据库中了，而且数据流就到此结束了，不再有增量数据规律或不规律地流进数据仓库中了。我们说这不是真正的数据仓库。

其次我们再从数据仓库项目上看看有哪些误解。

1. 数据模型为什么这么简单

由于许多经历过IT项目的人，往往是技术不错的人，对交互型的数据操作系统的概念太深，往往用OLTP的思维方式去看待数据仓库。我们曾经为一个单位设计数据仓库数据模型，他们的IT主管看了很吃惊，“我们这么复杂的业务，分析起来当然也很复杂，你们设计的数据模型怎么这么简单？”我们不得不解释原因，给他们讲，数据仓库的目的是什么，什么叫数据仓库的Star Sehema，Snow falake Sehema。他们还是似懂非懂。其实，相对于复杂的面向业务和流程的交互型系统来说，数据仓库则主要面向分析，将复杂数据模型转变简单结构的多维数据模型。

2. 为什么占用这么多的资源存储，太浪费存储空间了。

我们遇到这样一个故事，一位爱找错的IT组长报告他的上司，发现了我们将看似相同的数据存储在多个不同的表中，从而浪费了他们的很多宝贵的存储空间，一时间他们的经理反问我们，为什么犯这样低级的错误。我们只得解释，数据仓库是面向分析，通常是以存储空间为代价来换取查询上的性能，而是这些数据虽然存在不同的表中，但它们是不同的，它们是以不同的数据模型形式和不同的数据颗粒度存在的，这样查询不同量级的数据，节省了大量的计算时间，可以获得很好的查询性能。于是他们无语，面部露出惊奇的表情。

经典的数据仓库

好了，现在我们开始追溯经典，看看经典的数据仓库是什么样子的。

按照经典定义，数据仓库是一个基于历史数据的，逻辑数据整合的，不断增长的，满足特定目标的数据集合。什么是成熟的数据仓库和数据仓库项目？成熟表现在哪些方面？我们说，首先数据仓库项目开发商要成熟，其次数据仓库项目的客户要成熟，最后是开发数据仓库项目的时机要成熟。

1. 数据仓库项目开发商成熟

1.1数据仓库项目开发商对数据仓库的核心知识和理论认识要成熟。

这时开展数据仓库项目最基本的要求了。如果开发商对数据仓库的经典概念搞不透彻，那将是太可怕了。首先大家要从数据仓库的论著开始读起，如美国的Kimballl的数据仓库，Innon的数据仓库等等。读了还不行，还要写作业，有条件的到美国或加拿大来一趟，多看看成功的数据仓库项目，找找资深人士取取经。同时也不断博览群书，看看不同的书的区别是什么，哪些人讲的有道理。总而言之，要像唐僧那样去追求真理。

1.2数据仓库项目开发商运用的数据仓库的技术手段要成熟

这是比较难了。初学者就是要从数据仓库论著的第一节开始实践了。这里谈的主要是技术层面。开发数据仓库项目有很多专用工具，但我们不能拘泥于某些工具。我们认为工具不是最重要的，人才才是最重要的。哪怕有再多的不同的专用工具，只要我们合理安排数据仓库所需的软硬件，只需精通某一个或少数的专用工具，都可以做好数据仓库项目，因此大家不要过多的把精力投入到不同的工具和技术的学习中，而且将经典的理论与实际情况结合起来，将理论转化到可行的实践技术中。

1.3数据仓库项目开发商需要有成熟的数据仓库项目经验

这里谈得主要是如何成功地将数据仓库技术应用于大量不同的实际项目中，这一方面需要开发商要对有关行业的业务和相关专业的概念有深刻的理解，还要运用适当的技术进行设计、开发。拿来主义是个不错的方案，不妨到有成熟数据仓库项目经验的国内、外单位去学习，或将这些专家请来做顾问。

1.4数据仓库项目开发商对客户的培训与教育要有成熟的方法

对于大多数客户来说，数据仓库项目是个新鲜事。对刚要吃螃蟹的人要做心理辅导和知识辅导。数据仓库开发商要给客户作必要的数据仓库知识培训，当然是讲者自己首先要将数据仓库知识搞通。我们曾经看过这样一个项目，开发商与客户对他们的项目还均较满意，但我们发现那其实不是一个真正定义上的数据仓库项目。

2. 数据仓库项目的客户要成熟

2.1数据仓库项目的客户对数据仓库的认识与知识要成熟

首先客户对数据仓库的基本概念和知识要有一定了解，最好客户派出精干的信息人员和专业人员搞一个数据仓库短期学习，再到有成功案例的单位重点地参观考察一下，然后将有关流程向领导讲明白，因为领导认识的层次与水平将对今后的项目有很大的影响。

2.2数据仓库项目的客户对自己的需求要成熟

进一步讲，客户要下来好好分析，既然数据仓库能做这些事，我们究竟需要什么，我们最急需的是什么，我们的分期规划是什么，我们哪些需求是可操作性比较强的，哪些是有困难的，哪些是异想天开的。
2.3数据仓库项目的客户对项目投入、产出、风险的认识要成熟

数据仓库项目往往是看起来容易做起来难。看似不太复杂的数据，整起来还真不容易。因此科学设计与规划决定着项目的成败。数据仓库项目的初学客户与初学开发商由于经验不足，对数据仓库理解不透，对困难准备不足，常常规划了不合理的人力和开发应用周期，结果导致了种种问题，最终的结果就是表现各异地达不到预期结果与目标。需要的没做到，因此对于初学们来说，首先将目标放低一些，多规划一些分期投入，在以后的项目中再逐渐改进，良性循环。

3. 数据仓库项目开发时机要成熟

3.1分析需求是否足够的健全

正如之前的例子，如果是想分析时就要全部分析一下，这不算成熟的需求。我们说健全的需求应是指业务需求，通常是定期需要的，基本是业务依赖的。

3.2业务系统的数据能涵盖分析需求吗？

对于通常的数据仓库项目进行需求分析，首先看看我们的业务系统的数据全不全，这事做起来不难，但我们需要细化和量化，确实做到量力（数据）而行，不要等到开发时，才看清现在的数据并不满足需求。

3.3业务系统足够健壮么？

数据仓库所有的数据技术源于业务系统，而且数据是短暂地由业务系统流向数据仓库。尽管，通常数据仓库的ETL操作对业务系统影响较小，有的并不从生产库中取数据，但还是对业务系统的稳定性和可靠性有一定要求的。

3.4软硬件是否具备

中国有句俗语，叫既来之则安之。如果前面的条件都成熟了，那最后就需要有相应的软硬件配套。这里说的软件是指客户的人力资源，即业务分析人员、IT支持人员，数据分析应用人员等，硬件是指数据仓库项目所需的服务器，网络设备，终端设备，以及系统软件、数据库软件、应用软件等。如果确保这些软硬件都能满足，那就可以开始实施了。

数据仓库需要考虑的几个方面

1. 首先整个项目的设计与目标要基本符合经典的数据仓库概念和理论。不要做一个四不像的东西，数据仓库是一个基于历史数据的，逻辑数据整合的，不断增长的，满足特定目标的数据集合。
2. 项目的结果应该达到了预期的目标。
   评价项目的建设目标是否达到了预期的目标，不是项目建成验收的结果，而是交付使用一段时间以后，通常是半年以上，对应用结果的评价。
3. 项目具有可靠的稳定性。数据仓库系统可靠地与业务系统相衔接，数据仓库项目评价是考验它对数据的驾驭能力，可以以驾驭数据流程的能力为标准。数据仓库的实质是数据计算技术。数据源源不断地从业务系统流向数据仓库中，历史数据能否始终健康成长？即保证它的完整、准确、不重复、不缺失，随着数据量不断地增长，系统的性能依然良好可用。
4. 项目是可维护的。
   我们曾经见过这样的数据仓库项目，它的数据模型设计得很巧妙，但忽视了数据仓库在增长到一定数据量时的的性能，结果系统运行第一年效果不错，第二年就性能大大降低了，而且随着数据不断地增长，系统越来越慢，除了对数据模型推翻重组别外几乎是没有有效的办法了。还有其他方面设计和开发不当的，数据越来越不准确，导致结果最后不可用。

数据仓库与数据挖掘的关系

最后,我们再简单提一下数据仓库与数据挖掘的关系。什么是数据挖掘呢?数据挖掘就是采用一定技术和方法发现隐藏在数据中的规律和知识的工作。数据挖掘需要应用一定的数学和计算技术对较大数据集做深层次的分析，它通常需要与项目的业务流程和专业知识深入相结合，工作流程须基本符合数据挖掘业界标准-CRISP。

数据仓库与数据挖掘的关系就像是一对战略合作伙伴，彼此合作是共赢的，但双方又是独立自主的，并不以对方为前提条件。数据挖掘并不是依赖于数据仓库，实际上的商业应用项目当中数据挖掘往往是相对独立的，数据挖掘要的数据是有它特殊的需求，数据可以来源于数据仓库，也可以直接从数据源里来取，并不是说是数据仓库与数据挖掘有必然的关系，也不是先有数据仓库后有数据挖掘，所有的数据挖掘一定基于数据仓库，不是这个概念。

那么，没有数据挖掘应用的数据仓库的应用是什么？没有数据仓库的数据挖掘是怎样工作的？数据仓库与数据挖掘是怎样结合的？好处是什么？我们以后再讲。