数据仓库设计的21条原则.docx

PAGE 1 PAGE 1 数据仓库设计的21条原则  如何高效有序的设计数据仓库，本文给了你一个正确的答案。  高效实现数据仓库的七个步骤  数据仓库和我们常见的RDBMS系统有些亲缘关系，但它又有所不同。假如你没有实施过数据仓库，那么从设定目标到给出设计，从创建数据结构到编写数据分析程序，再到面对挑剔的用户的评估，整个过程都会带给你一种与以往的项目完全不同的体验。一句话，假如你试图以旧有的方式创建数据仓库，那你所面对的不是预算超支就是所建立的数据仓库无法良好运作。  在处理一个数据仓库项目时需要留意的问题许多，但同时也有许多有建设性的参考可以帮助你更顺当的完成任务。开放思维，不断尝试新的途径，对于找到一种可行的数据仓库实现方法来说也是必需的。  1.配备一个全职的项目经理或你自己全面负责项目管理  在通常状况下，项目经理都会同时负责多个项目的实施。这么做完全是出于资金和IT资源方面的考虑。但是对于数据仓库项目的管理，肯定不能出现一人身兼数个项目的状况。由于你所处的领域是你和你的团队之前没有进入过的领域，有关数据仓库的一切－数据分析、设计、编程、测试、修改、维护－全都是崭新的，因此你或者你指派的项目经理假如能全心投入，对于项目的成功会有很大帮助。  2.将项目管理职责推给别的项目经理  由于数据仓库实现过程实在是太困难了，为了避免自虐，你可以在当前阶段的项目完成后就将项目管理职责推给别的项目经理。当然，这个新的项目经理一定要复合第一条所说的具有全职性。为什么要这么做呢？首先，从项目经理的角度看，数据仓库实施过程的任何一个阶段都足以让人身心疲乏。从物理存储设备的开发到Extract-Transform-Load的实现，从设计开发模型到OLAP，全部阶段都明显的比以前接触的项目更加困难。每个阶段不但需要新的处理方法、新的管理方法，还需要创新性的观点。所以将管理职责推给别的项目经理不但不会对项目有损害，还可以起到帮助作用。  3.与用户进行沟通  这里所讲的内容远比一篇文章本身要重要的多。你必需明白，在数据仓库的设计阶段，那些潜在用户自己也不清晰他们究竟需要数据仓库为他们做什么。他们在不断的探索和发觉自己的需求，而你的开发团队也在和客户的接触中做着同样的事情。更加频繁的与客户接触，多做记录，并让你的团队更关注于项目需求争论的结果而不是争论的过程本身。  既然你和客户的交流是为了了解存储的数据是何种类型以及如何有效存储数据，你或许需要（和你的用户一起）采用一种新的方法观看数据，而不是直接处理数据。你可以尝试从中找出隐蔽的信息，比如在一段时期内的数字涨落等。不要试图追寻项目需求的答案，而是要让答案找上门来。  4.以技术/信息库作为领导  由于数据仓库实施的各个阶段都有很大不同，因此你需要有人能起到维持整个项目的连续进行的作用，不过这个职责并不需要那种全职性。项目实施有三个重要方面：架构、技术和业务。将架构作为重点可以保证在整个项目中，数据仓库的架构从物理层往上，都会受到良好的维护。而我们应当将技术作为重点，因为开发团队和关键用户都在使用他们以前从未用过的工具，必需有人监督开发过程以及工具使用的全都性。  最终，在数据仓库的应用过程中出现出来的业务需求必需被具体分析和记录，以促机开发过程持续下去。假如用户不能很好的开发人员以及其它用户沟通，那么数据分析和度量方面的开发进程就会延期，所以必需有人关注业务方面的开发，推动开发进入更高级别。  5.跳出反复修改程序的陷阱  第一次实现的数据仓库确定不会是最终交付的版本。为什么呢？实际上在真正见到产品前，你无法确定的知道自己的目标是什么。或者说，最终用户只有在使用数据仓库产品一段时间后，才能明确告知你这个产品是不是他所期望的。与你以往处理的项目不同，业务智能还处于发展的初期，每个公司对业务智能都有不同的解释，因此你的项目决不会一次成功。  为了以正确的格式获得数据，你需要在不断变化的状况中摸索前进。BI具有很强的个性，不同的环境、不同的市场以及不同的企业都有不同的BI。这又代表什么呢？这表示你需要把数据库管理员放在一个消息相对封闭的环境中，不要让他知道数据仓库的数据结构以及ETL程序在不断的转变。对此没有别的方法。这样可以减轻你和DBA所承受的压力。  6.对大量的前端资源进行数据源分析  在数据仓库实现过程中，你不得不在旧有的数据中困难跋涉，这些数据来自老的数据库、老的磁带机以及远程的数据。它们中的大部分都凌乱不堪，并且难以获取。你要对这些数据进行大量处理，并且还要设计ETL程序来查找其中的有用信息。假如你期望整个项目做起来比较