过去我们一直使用的OLTP技术也许隐藏着许多严重的缺陷数据仓库的实现并不是一个简单的任务你会发现以前积累下来的丰富经验并不适合处理每个数据仓库的独特需求
下面列出的条款是你在实现数据仓库过程中一定会面对的问题其中一些看起来并没有想象中那么严重但是你还是应该尽量避免出现类似问题数据仓库并不是一个事务处理系统它没有一定的标准也不会实现某个特定的应用但它本质上是非常有组织性的总之每个公司所建立的数据仓库都是唯一的并且每一次数据仓库的实现方法都不是一成不变的在实现数据仓库时需要注意的不单是应该如何作更要注意不该如何做下面就是我们总结的七点不该如何作
不要编写自己无法快速修改的代码
你所要编写的程序主要用于数据分析而不是处理事务而你的用户也并不真正知道他们自己真正想要一个什么样的程序因此你不得不反复修改代码好几次才会明白用户到底需要一个什么样的程序如果你编写的程序具有良好的结构和灵活性就算需要修改也不会太浪费力气反之你会被自己累死
不要使用无法修改的数据库访问API
在过去你的数据库可以为大量的客户提供稳定的数据查询服务而如今你的程序必须能够应付更多的数据查询这使得重新改写程序以使得每个查询请求能得到最大的数据量成为势在必行的工作而一般来说这种代码修改都不会一次成功所以只有选择合适的可以修改的API才能使程序尽快适应新的需求
不要设计任何无法扩展的东西
在联机处理过程（OLTP）应用中数据分析并不是一个真正的应用程序实际上数据分析的关键是获取大量旧的数据从中提取数据模型并以此模型推断出新的信息而你所编写的访问潜在信息的代码应该具有可扩展性可以附加新的数据千万别在支持数据分析的代码中假定数据都是固定格式的 不要附加不必要的功能
一个仓库要做的是恰到好处的服务用户走进仓库从货架上取得自己所需得信息仅此而已由于业务智能分析以及规律性的问题都有各自的处理程序因此你的客户唯一的需要就是获取信息他们需要一种应用环境可以让他们快速的从数据仓库中取得分析过程所需的数据而不论这个数据是什么样子的也许你想帮助他们精炼一下获得的数据但最好不要这么做一定要记住不要给客户的数据分析程序添加任何会影响数据访问性能的功能
不要简化数据清除和数据源分析的步骤
在实现数据仓库过程中最应该注意的地方就是为ExtractTransformLoad机制分析数据源以及为优化负载而清除数据安全的做法是假设项目经理在这个阶段会需要整个项目资源的一半以上相反如果你在这方面进行了简化稍后肯定会后悔所以就算系统工作缓慢也不要简化清理旧的数据的过程
不要避免颗粒度和分区问题
在数据仓库设计过程中有两个最大的数据存储问题第一是如何给转换数据定位一个恰当的颗粒度等级第二是如何将数据绝对的分区为什么这两点问题如此重要呢？因为整个数据仓库的响应能力受颗粒度影响并且数据访问的效率直接与数据分区性能有关因此这是具有关键性的工作不要试图避免面对这些问题
不要在没考虑业务问题前就使用OLAP
用户在亲眼见到程序前通常都不知道自己到底想要个什么样的程序因此他们的观点有不少错误比如他们希望分析结果会忠实反应性能度量或者希望程序会使他们部门或公司的业务工作有所不同而你必须跳出自己的职责范围从IT管理者的角度考虑用户部门直至整个企业的运行方式才能在开发过程中避免这类问题在通常的OLTP开发中你可以比较方便的理解业务流程而在联机分析处理（OLAP）领域任何事情都需要亲自考察而在你周围工作的人也许并不会发现你对业务方面存在的误解因此不要自以为已经了解了足够的信息不断的询问才能使你真正了解业务智能中的业务到底是什么样子的
