最近一直在SONY参与一个DW项目（Sony China Tri-One Project），主要负责将用户的生产及供分析数据从SAP中ETL到搭建在ORACLE中的POOL里，并为其它系统提供相应数据接口。并且这个POOL也是由我们负责根据用户的需求来设计并构建。客观地说，我们的工作部分是整个DW项目中这个分支项目的基础与关键核心。当然，了解和熟悉DW项目的人也都会赞同我的观点。毋庸置疑，整个项目规模是很庞大，参与此项目的也都是几个大公司，如IBM、HP、FUJITSU等，我公司的名气显然没前面几个大，因此在整个项目中也只是分了一小杯羹。前面的几个公司参与此项目的大多二、三十号人马，显得浩浩荡荡，而我们项目组连PM才总共3人。不过做的事情却是这个分支项目中最累最繁杂的部分。目前我们的工作部分已进入到提供相应数据接口的阶段，应该说已经接近尾声。现在将前段时间工作中的心得与积累下来的一些零碎东西整理成文。
先总体来看这个项目，应该说，我们负责的部分有4个核心阶段：
一、需求数据从SAP系统迁移到ORACLE系统阶段
二、POOL的需求分析、设计和构建阶段
三、数据从ODS中ETL到POOL的阶段
四、向其它系统提供数据接口阶段
接下来，就每个阶段的工作过程及要点做一个大致的总结和回顾。
一、需求数据从SAP系统迁移到ORACLE系统阶段
通常的DW项目实施中，在这一阶段，为了避免复杂的业务或者转换逻辑直接与生产系统加载而往往提供ODS层。出于技术层面上的考虑及用户的认可，我们也设计并提供这一数据层，以保证数据在不同的系统间迁移时的平滑过渡。因为SAP系统不像别的ERP系统一样，它对自身的管理以及安全性方面有着更高和更严谨的要求，我们也只能借助一个用户提供的应用层有限地来了解SAP的DB结构。因此，我们必须借助ETL工具（对于这个项目客户选用的是INFORMATICA）来将构建DW用到的SAP中很多系统表抽取到ORACLE系统中，以便研究和搞清其结构和关系。用户对整个项目过程中任何设计、开发和测试的要求都很严格，想尽量避免频繁地无谓地与SAP进行数据交互。最重要的是，用户现场有3个SAP环境，分别是开发、测试与生产环境，因此通过INFORMATICA设计产生的ABAP程序都将在这3个环境下注册并移植，所以，用户是不希望看到未经严格测试而通过的ABAP程序在3个环境中反复注册移植的现象（因为移植的工作是由用户来做的^_^）。总体看，这个阶段的工作是比较简单，但比较费时繁琐的。
二、POOL的需求分析、设计和构建阶段
通过前一阶段的工作，我们从用户的大致需求出发，已经将项目中涉及到的SAP系统表抽到了ORACLE平台上。这样对我们深入分析表结构与表间的关系及了解掌握其业务逻辑带来了极大的便利，同时也尽可能减少了与SAP系统的交互。这一阶段的工作中，我们首先熟悉了系统中的表结构及数据关系，一定程度上理解了数据关系中所包含和体现的业务逻辑，然后就又回头对照用户EXCEL式的需求条目细致地去分析如何将需求完全、合适地加载整合到要设计出的业务模型里面。当然了，这个阶段中与用户的沟通是十分关键和必要的，因为只有与用户进行全方位的交流和明确的确认，才能真正体会到用户的实际需求，不至于出现对业务逻辑产生理解偏差的现象。所以，这个阶段中大小会议成了主旋律。在清晰地理解了用户需求、数据关系和业务逻辑后，我们就借助POWERDESIGNER来着手设计业务模型了。我们大致是按照业务模块来分工做模型设计的，在做模型设计的过程中，当问题积累到一定程度后就又同用户进行交流以澄清、确认或加以说明。反反复复就是为了明明白白。POOL的业务模型最终成型了，紧接着就是根据将其生成物理模型，并最终创建到ORACLE里。应该说，这一阶段是这个项目中最艰苦、最熬人，同时也是最为关键的一个阶段。不过，一旦将这一阶段做好、做扎实了，那后面的工作就会变的得心应手、一马平川了。
（待续…）
