[为方便本人阅读所以收集整理此处，www.DMResearch.net]

 

数据仓库设计的21条准绳

--7个步骤，7个禁忌和7种思路



高效实现数据仓库的七个步骤

数据仓库和我们常见的RDBMS系统有些亲缘关系，但它又有所不同。如果你没有实施过数据仓库，那么从设定目标到给出设计，从创建数据结构到编写数据分析程序，再到面对挑剔的用户的评估，整个过程都会带给你一种与以往的项目完全不同的体验。一句话，如果你试图以旧有的方式创建数据仓库，那你所面对的不是预算超支就是所建立的数据仓库无法良好运作。

在处理一个数据仓库项目时需求留意的问题很多，但同时也有很多有建设性的参考可以协助你更顺利的完成任务。开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实现方法来说也是必需的。

1. 配备一个全职的项目经理或你本人全面担任项目管理
在通常情况下，项目经理都会同时担任多个项目的实施。这么做完全是出于资金和IT资源方面的考虑。但是对于数据仓库项目的管理，绝对不能出现一人身兼数个项目的情况。由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修正、维护－全都是簇新的，因此你或者你指派的项目经理如果能全心投入，对于项目的成功会有很大协助。

2. 将项目管理职责推给别的项目经理
由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。当然，这个新的项目经理一定要复合第一条所说的具有全职性。为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲惫。从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，所有阶段都明显的比以前接触的项目愈加困难。每个阶段不但需求新的处理方法、新的管理方法，还需求创新性的观点。所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到协助作用。

3.与用户进行沟通
这里所讲的内容远比一篇文章本身要重要的多。你必须明白，在数据仓库的设计阶段，那些潜在用户本人也不清楚他们到底需求数据仓库为他们做什么。他们在不断的探索和发现本人的需求，而你的开发团队也在和客户的接触中做着同样的事情。愈加频繁的与客户接触，多做记录，并让你的团队更关注于项目需求讨论的结果而不是讨论的过程本身。

既然你和客户的交流是为了了解存储的数据是何品种型以及如何无效存储数据，你也许需求（和你的用户一同）采用一种新的方法观察数据，而不是直接处理数据。你可以尝试从中找出隐藏的信息，比如在一段时期内的数字涨落等。不要试图跟随项目需求的答案，而是要让答案找上门来。

4. 以技术/信息库作为领导
由于数据仓库实施的各个阶段都有很大不同，因此你需求有人能起到维持整个项目的连续进行的作用，不过这个职责并不需求那种全职性。项目实施有三个重要方面：架构、技术和业务。将架构作为重点可以保证在整个项目中，数据仓库的架构从物理层往上，都会遭到良好的维护。而我们应该将技术作为重点，由于开发团队和关键用户都在使用他们以前从未用过的工具，必须有人监督开发过程以及工具使用的分歧性。

最后，在数据仓库的使用过程中浮现出来的业务需求必须被详细分析和记录，以促机开发过程持续下去。如果用户不能很好的开发人员以及其它用户沟通，那么数据分析和度量方面的开发进程就会延期，所以必须有人关注业务方面的开发，推动开发进入更高级别。

5. 跳出反复修正程序的圈套
第一次实现的数据仓库肯定不会是最终交付的版本。为什么呢？实际上在真正见到产品前，你无法确定的知道本人的目标是什么。或者说，最终用户只要在使用数据仓库产品一段时间后，才能明确通知你这个产品是不是他所希望的。与你以往处理的项目不同，业务智能还处于发展的初期，每个公司对业务智能都有不同的解释，因此你的项目决不会一次成功。

为了以正确的格式获得数据，你需求在不断变化的情况中摸索前进。BI具有很强的特性，不同的环境、不同的市场以及不同的企业都有不同的BI。这又代表什么呢？这表示你需求把数据库管理员放在一个音讯绝对封闭的环境中，不要让他知道数据仓库的数据结构以及ETL程序在不断的改变。对此没有别的办法。这样可以减轻你和DBA所承受的压力。

6. 对大量的前端资源进行数据源分析
在数据仓库实现过程中，你不得不在旧有的数据中艰难跋涉，这些数据来自老的数据库、老的磁带机以及近程的数据。它们中的大部分都凌乱不堪，并且难以获取。你要对这些数据进行大量处理，并且还要设计ETL程序来寻觅其中的有用信息。如果你希望整个项目做起来比较顺利，并且找到一种方法能够一次成功，那就需求你的开发人员必须花费足够的时间来充分研讨这些旧无数据，将凌乱的数据规则化，并尽力设计和实现强壮的数据采集和转换过程。数据仓库的ETL部分会占用整个项目资源的百分之八十，所以一定要确定你的资源都用在刀刃上了。

7. 将人际关系处理放在首位
在数据仓库实现过程中真正的地狱不是来自技术或者开发方面，而是来自你四周的人。你也许会遇到一个对项目并不乐观而又没时间听你陈述的领导。你也许会遇到一些开发人员将进度拖延太长时间还抱怨为什么不能用老方法实施。你也许还会遇到一些抱有不切实际的幻想的用户，他们希望轻点鼠标就能实现想象中的功用，但却不愿在他们那边多做些智力投资，更好的培训他们本人的员工。而你也曾经疲惫不堪，鼓励投资，以及在开发团队和用户（甚至老板）中推广新的开发技巧。

总之你要保持浅笑。当一切搞定，你的烦恼也就一扫而空了，笑到最后才笑得最轻松。



数据仓库开发过程中的七个禁忌

过去我们不断使用的OLTP技术也许隐藏着许多严重的缺陷。数据仓库的实现并不是一个简单的任务，你会发现以前积累下来的丰富经验，并不适合处理每个数据仓库的独特需求。

下面列出的条款是你在实现数据仓库过程中一定会面对的问题，其中一些看起来并没有想象中那么严重，但是你还是应该尽量避免出现类似问题。数据仓库并不是一个事务处理系统，它没有一定的标准也不会实现某个特定的使用，但它本质上是非常有组织性的。总之，每个公司所建立的数据仓库都是独一的，并且每一次数据仓库的实现方法都不是原封不动的。在实现数据仓库时需求留意的不单是"应该如何作"，更要留意"不该如何做"。下面就是我们总结的七点"不该如何作"。

1.不要编写本人无法快速修正的代码
你所要编写的程序次要用于数据分析，而不是处理事务。而你的用户也并不真正知道他们本人真正想要一个什么样的程序。因此你不得不反复修正代码好几次，才会明白用户到底需求一个什么样的程序。如果你编写的程序具有良好的结构和灵活性，就算需求修正也不会太浪费力气。反之，你会被本人累死。

2. 不要使用无法修正的数据库访问API
在过去，你的数据库可以为大量的客户提供稳定的数据查询服务。而如今，你的程序必须能够应付更多的数据查询。这使得重新改写程序以使得每个查询请求能得到最大的数据量成为势在必行的任务，而普通来说这种代码修正都不会一次成功，所以只要选择合适的可以修正的API，才能使程序尽快顺应新的需求。

3. 不要设计任何无法扩展的东西
在联机处理过程（OLTP）使用中，数据分析并不是一个真正的使用程序。实际上，数据分析的关键是获取大量旧的数据，从中提取数据模型，并以此模型推断出新的信息。而你所编写的访问潜在信息的代码应该具有可扩展性，可以附加新的数据。千万别在支持数据分析的代码中假定数据都是固定格式的。

4. 不要附加不必要的功用
一个仓库要做的是恰到好处的服务，用户走进仓库，从货架上取得本人所需得信息，仅此而已。由于业务智能、分析以及规律性的问题都有各自的处理程序，因此你的客户独一的需求就是获取信息。他们需求一种使用环境，可以让他们快速的从数据仓库中取得分析过程所需的数据，而不论这个数据是什么样子的。也许你想协助他们精炼一下获得的数据，但最好不要这么做。一定要记住，不要给客户的数据分析程序添加任何会影响数据访问功用的功用。

5. 不要简化数据清除和数据源分析的步骤
在实现数据仓库过程中最应该留意的地方就是为Extract-Transform-Load机制分析数据源，以及为优化负载而清除数据。安全的做法是假设项目经理在这个阶段会需求整个项目资源的一半以上。相反，如果你在这方面进行了简化，稍后肯定会后悔。所以就算系统任务缓慢，也不要简化清理旧的数据的过程。

6. 不要避免颗粒度和分区问题
在数据仓库设计过程中有两个最大的数据存储问题，第一是如何给转换数据定位一个恰当的颗粒度等级，第二是如何将数据绝对的分区。为什么这两点问题如此重要呢？由于整个数据仓库的呼应能力受颗粒度影响，并且数据访问的效率直接与数据分区功用有关。因此这是具有关键性的任务，不要试图避免面对这些问题。

7. 不要在没考虑业