深入探讨数据仓库设计的步骤禁忌和思路

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

数据仓库与我们常见的RDBMS系统有关，但又有所不同。如果你还没有实施过数据仓库，那么从设定目标到设计、创建数据结构到编写数据分析程序，再到评估关键用户的整个过程，都会给你带来与之前项目完全不同的体验。总之，如果你试图用老方法创建数据仓库，你要么面临预算超支，要么你已经建立的数据仓库不能很好地工作。

在处理一个数据仓库项目时，需要注意的问题有很多，但也有很多建设性的参考，可以帮助您更顺利地完成任务。虚心，不断尝试新的方法，也是找到可行的数据仓库实现方法的必要条件。

1.让一个专职项目经理或你自己全面负责项目管理。

通常情况下，项目经理同时负责多个项目的实施。这样做是为了资金和IT资源。但是对于数据仓库项目的管理，绝对不可能一个人有几个项目。因为你的领域是你和你的团队从未进入过的领域，所以关于数据仓库的一切——数据分析、设计、编程、测试、修改和维护——都是全新的，所以如果你或你指派的项目经理能够全心投入，对项目的成功会有很大的帮助。

2.把项目管理责任推给其他项目经理。

因为数据仓库实现过程太难，为了避免自虐，可以在当前项目完成后，将项目管理责任推给其他项目经理。当然，新的项目经理必须是第一条所说的专职。为什么要这么做？首先，从项目经理的角度来看，数据仓库实施过程的任何一个阶段都足以让人身心俱疲。从物理存储设备的开发到提取-转换-加载的实现，从设计开发模型到OLAP，各个阶段都明显比之前的项目更加困难。每个阶段不仅需要新的治疗方法和新的管理方法，还需要创新的理念。因此，将管理责任推给其他项目经理，不仅不会伤害项目，还会帮助项目。

3.与用户交流

这里说的远比一篇文章本身重要。你必须明白，在数据仓库的设计阶段，那些潜在用户自己并不确切知道他们需要数据仓库为他们做什么。他们在不断探索和发现自己的需求，你的开发团队在接触客户的时候也是这样。多接触客户，多做笔记，让你的团队更关注项目需求讨论的结果，而不是过程本身。

既然你和客户的沟通是为了了解存储数据的类型以及如何有效存储，你可能需要采用一种新的方法(和你的用户一起)去观察数据，而不是直接处理数据。你可以试着找出隐藏的信息，比如一段时间内数字的波动。不要试图去寻找项目需求的答案，而是让答案来找你。

4.以技术/信息基础为主导。

由于数据仓库实现的阶段差异很大，您需要一个能够保持整个项目持续进展的人，但是这个职责不需要那种全职工作。项目实施有三个重要方面:架构、技术和业务。关注架构可以确保数据仓库的架构在整个项目中从物理层向上得到很好的维护。但是我们应该把重点放在技术上，因为开发团队和关键用户正在使用他们从未使用过的工具，必须有人监督开发过程和工具使用的一致性。

最后，必须对数据仓库应用中出现的业务需求进行详细的分析和记录，以促进计算机开发过程的延续。如果用户不能与开发者和其他用户很好地沟通，数据分析和测量的开发进程就会被延迟，所以必须有人关注业务的发展，将开发推向更高的层次。

5.跳出反复修改程序的陷阱

第一次实现的数据仓库肯定不会是最终交付的版本。为什么？事实上，在你真正看到产品之前，你无法确定你的目标是什么。换句话说，最终用户只有在使用数据仓库产品一段时间后，才能清楚地告诉你这个产品是不是他想要的。与你之前的项目不同，商业智能还处于早期发展阶段。每个公司对商业智能的解释都不一样，所以你的项目永远不会一下子成功。

为了得到正确格式的数据，你需要在不断变化的情况下摸索进步。毕个性很强。不同的环境，不同的市场，不同的企业有不同的BI。这是什么意思？这意味着你需要把数据库管理员放在一个相对封闭的环境中，不要让他知道数据仓库的数据结构和ETL程序是不断变化的。没有其他方法可以做到这一点。这样可以减轻你和DBA的压力。

6.大量前端资源的数据源分析。

在数据仓库的实施过程中，你不得不在来自旧数据库、旧磁带机和远程数据的旧数据中跋涉。大部分都是乱七八糟的，很难得到。你必须对这些数据进行大量的处理，你必须设计ETL程序来找到有用的信息。如果你想让整个项目顺利进行，并找到一个立刻成功的方法，你的开发人员必须花足够的时间来充分研究旧数据，将杂乱的数据正则化，并尽力设计和实现一个健壮的数据获取和转换过程。数据仓库的ETL部分会占用整个项目80%的资源，所以一定要确保你的资源用在刀刃上。

7.优先考虑人际关系。

在数据仓库实施的过程中，真正的地狱不是来自技术或者开发，而是来自你身边的人。你可能会遇到一个对项目不看好，没有时间听你陈述的领导。你可能会遇到一些开发人员拖延进度太久，抱怨为什么不能用老办法实现。你也可能会遇到一些抱有不切实际幻想的用户。他们希望通过点击鼠标来实现他们想象中的功能，但他们不愿意在他们的智力上投入更多，更好地培训自己的员工。而你已经筋疲力尽，鼓励投资，在开发团队和用户(甚至老板)中推广新的开发技能。

无论如何，你应该保持微笑。当一切都做完了，你的烦恼也就一扫而光空，笑到最后才是最轻松的。
数据仓库开发中的七大禁忌

我们过去一直使用的OLTP技术可能隐藏了许多严重的缺陷。数据仓库的实现不是一个简单的任务。你会发现之前积累的丰富经验并不适合应对各个数据仓库的独特需求。

以下条款是你在实施数据仓库的过程中肯定会面临的问题。有些看起来没有你想的那么严重，但是你要尽量避免类似的问题。数据仓库不是一个事务处理系统，它没有一定的标准，也不会实现特定的应用，但它本质上是非常有组织的。总之，每个公司建立的数据仓库都是正确的，数据仓库的实现方法也不是每次都一成不变的。在实施数据仓库时，不仅要注意“怎么做”，还要注意“怎么不做”。下面是我们总结的七点:“不要做什么”。

1.不要写不能快速修改的代码。

你要写的程序主要用于数据分析，不是事务处理。你的用户并不知道他们真正想要什么样的程序。所以你要多次修改代码，才能了解用户需要什么样的程序。如果你的程序有很好的结构和灵活性，即使需要修改，也不会浪费太多精力。反之，你会被自己搞得精疲力尽。

2.不要使用无法修改的数据库访问API。

在过去，您的数据库可以为大量客户提供稳定的数据查询服务。现在，你的程序必须能够处理更多的数据查询。这使得重写程序变得势在必行，以便每个查询请求都可以获得大量的数据。一般来说，这种代码修改不会一次成功，所以只有选择一个合适的可以修改的API，程序才能尽快适应新的需求。

3.不要设计任何不能扩展的东西

在联机处理过程(OLTP)的应用中，数据分析并不是真正的应用。事实上，数据分析的关键是获取大量的旧数据，从中提取数据模型，并从这个模型中推断出新的信息。您编写的用于访问潜在信息的代码应该是可扩展的，并且可以附加新数据。在支持数据分析的代码中，永远不要假设数据是固定格式的。

4.不要附加不必要的功能。

仓库要做的就是恰到好处的服务。用户走进仓库，从货架上获取所需信息。因为商业智能、分析和常规问题都有自己的处理流程，你的客户需要的是获取信息。他们需要一个应用程序环境，允许他们从数据仓库中快速获得分析过程所需的数据，无论数据看起来是什么样的。也许你想帮他们提炼数据，但不要这么做。请记住，不要在客户的数据分析程序中添加任何会影响数据访问性能的功能。

5.不要简化数据清理和数据源分析的步骤。

在实现数据仓库的过程中，最需要注意的是为提取-转换-加载机制分析数据源，为优化加载清除数据。可以有把握地假设，在这个阶段，项目经理将需要整个项目资源的一半以上。相反，如果你把这方面简单化了，你以后肯定会后悔的。所以即使系统运行缓慢，也不要简化清理旧数据的过程。

6.不要回避粒度和分区问题

在数据仓库的设计过程中，有两个数据存储问题。第一个是如何为转换后的数据找到合适的粒度级别，第二个是如何对数据进行绝对分区。为什么这两个问题如此重要？因为整个数据仓库的响应能力受到粒度的影响，而数据访问的效率直接关系到数据划分的性能。因此，这是一项非常重要的任务。不要试图逃避面对这些问题。

7.不要在没有考虑商业问题的情况下使用OLAP。

用户在亲眼看到之前，通常不知道自己想要什么样的程序。所以他们的观点有很多错误。例如，他们希望分析结果忠实地反映绩效测量，或者希望该程序会使他们部门或公司的业务工作有所不同。而你必须跳出自己的职责，站在IT管理者的角度考虑用户部门和整个企业的运营模式，才能避免开发过程中出现这样的问题。在通常的OLTP开发中，你可以很容易地理解业务流程。在联机分析处理(OLAP)领域，一切都需要亲自考察，在你身边工作的人可能发现不了你对业务的误解。因此，不要认为你有足够的信息。只有不断提问，才能真正理解“商业智能”中的“业务”是什么样的
顺利开发数据仓库的七个思路。

对于大多数IT顾问来说，实现一个数据仓库比以前的任何项目都要困难。考虑到不同的数据结构、用途和应用开发方法，积累的经验和技能大部分都是无用的。但是，只要你一路上做一些修正，你会发现实现一个数据仓库并不难，哪怕是你第一次实现一个数据仓库。

下面是数据仓库实现过程中要考虑的步骤列表。有些你可能从来没有意识到，有些你可能在执行过程中用过，但也许重新思考后你会有更多的感悟。虚心，不断尝试新的方法，找到可行的数据仓库实现方法。

1.对应用程序的实现方法要三思。

数据仓库不涉及事务处理，只占报表的一小部分。数据仓库应用的本质是分析，特别是对于商业智能。BI不是通常的数据:它是根据旧数据建模的新数据。那么如何才能从旧数据中挖掘出这些新数据呢？其实这个工作不是让你来完成，而是让你的客户来完成。从项目主管的角度来看，一个有经验的电子表格设计师应该和你一起决定如何整合各种程序。主要的挑战将是如何以一种新的方式观察数据，这是你的客户正在尝试使用的。

2.创建一个抽象的、部署良好的数据库访问组件。

你过去接触过的数据库项目和现在的数据仓库有一个绝对的区别，就是在联机事务处理(OLTP)环境下，用户数量非常多，但是使用的数据相对较少；然而，在联机分析处理(OLAP)环境中，情况正好相反，少数用户使用大量数据。而你的工作就是写一个应用来优化这种差异。这里有一个线索:在你所有的分析程序中，你应该能够抓取连续的数据项，这样就可以将与原始数据的物理结构相似的数据存储在后面将要建立和访问的数据结构中。具体怎么实现？先不要归一化数据。第二，将它放在一个数组中，以最小化读取请求的数量。按照这个方法，DBA会很乐意和你合作的。

保持放松

现在回头看第一步，你就能明白，定义一个分析程序并不是一件简单的事情，一般来说，很难在第一时间实现最终符合要求的产品。这种问题也存在于你要分析的数据结构中。总之，在实现过程中会有很多变数，需要你不断改变你的程序。通常我们希望尽量减少变化的次数。在一个数据仓库的实现中，本质是分析过程不出错，这也需要DBA的参与。不要执着于你的编程、代码、框图或者你已经建立的任何东西，而是要根据这种变化不断调整。

4.把管理放在首位。

你在分析数据来源方面做得怎么样？你觉得清理垃圾数据很难吗？你不是唯一这样想的人。做过类似工作的人都有这个观点。在一般规模的组织中，作为数据仓库实现过程的一部分，必须一致地处理大量旧数据。所以，分析数据源，写几个小时的转换程序，把旧数据导入数据仓库，是整个数据仓库实现过程中最难的部分。而这也是整个项目中最重要的环节，可以占到整个项目周期和预算的四分之三。所以要小心。

5.从字里行间寻找问题

和用户沟通是一件很麻烦的事情。为什么这么说？因为很多用户在看到最终产品之前，并不知道自己想要什么样的产品。定义数据仓库应用程序是一个探索性的过程，这个过程必须重复。记住所谓的“商业智能”是用户自己定义的，他们按照自己的理解来处理业务流程。因此，这些用户是数据和业务流程之间的桥梁。他们要的不是数据本身，而是数据背后的情报。你可以让他们讨论，思考，提出建设性的意见。但是不要让他们去解决或者让他们随意去想象和表达那些“可能”的意见。最后，时刻关注用户得出的结论。

保持

数据仓库似乎不像传统的OLTP模型那样根深蒂固，但它确实如此。虽然很多人都参与了数据仓库的开发，但是数据仓库的实现在一开始看起来相当混乱，因为它的框架与以前的系统有很大的不同。但是坚持下去很重要。它有两个重要的功能。

第一，技术的本质。它可以在项目的任何阶段跟踪软件工具的部署和正确使用，以及开发过程。如果这符合你的背景，你可以多加注意。

第二，架构的性质。它使得数据仓库及其支持的系统的物理和逻辑架构是持久的，并且在项目的每个阶段转换时不会改变。这是你能提供的。

发出警告

最后，你要记住，你不是那个登陆新世界的人。你身边的每个人都会有以下一个或多个问题:不切实际的期望，对技术的误解，旧的或坏的习惯，竞争行为，或者对项目缺乏信任。虽然沟通等工作应该是项目经理的责任，但实际上你也要承担同样的责任。那么作为技术总监应该怎么做呢？首先当然要真诚对待身边的人，但是一定要竖立威信，发出适当的警示。当你发现项目进展缓慢，资源流失，或者员工失去目标的时候，你要说出来。在大多数情况下，给出明确的警告是明智的。一个仓促启动的数据仓库项目可能会脱轨，但不要让一个失败的项目拖累你。