再次，项目开发阶段
    “由客户方提出源系统数据详细清单，通过与客户方的沟通定义目标区数据模型，定制出源到目标的MAPPING清单, 然后ETL人员根据此清单进行数据抽取，报表开发人员通过数据模型进行语义层设计、报表展现” ，仿佛一个开发过程十分的清晰简单，但现在中，困难可谓是无所不在，源系统数据理解、模型的定义、ETL的程序设计等各方面都可能出现潜在的、必然的、意 想不到的困难。

以下简单列出些常见的问题
    1），对源系统的数据理解，在项目中，可能存在客户方很难给出源系统的详细清单，特别是对于业务繁多的大系统而言，可能源系统表有几百个之多，而且关系复杂，这将给mapping制定带来巨大的困难。
    2），数据抽取困难

    一般情况下，数据的抽取都有时间的限制，当数据量过大且模块加工繁杂时，必然存在很大的难度。除此之外，以下因素也是经常存在。
     (1),表记录变化无相应的系统时间戳，此问题在系统中一般都存在。（Oracle解决办法，物化视图、CDC等）
     (2),数据来源复杂，存在多个业务系统及外部数据的集中。
     (3),抽取工具不成熟及自己使用的不熟练（主观及客观因素）。 
     (4)，业务系统的不断变更增大数据仓库抽取的难度，etl抽取程序可能要有N个版本。

3）， 怎样说服客户数据仓库的正确性--对于一大型数据仓库的实施运行的检查，如果证明数据仓库的准确性在某些模块是个十分困难的事情，主要原因有以下几点：
    （1），在其它业务系统中没有相应的指标进行对比。
    （2），原始数据中垃圾数据的存在且难于判定。
    数据仓库中存在最多的是各维度对比及各方面分析，对于一些数据存在维度错误及关系错误而难于确定修复策略，当然此时数据仓库的建立也能发现源业务系统的不足及促进源系统的不断完善。
    （3），业务规则与原始数据业务系统难于对应。

    例如 A业务及B业务是有联系的，但可能在原业务系统中没有此类需求，因此AB找不到对应的关系，而在数据仓库中AB的联系自然就无法体现了。，
    特别对于税务数据仓库来说，主题多，业务广，涉及面广，因此对于成千上万的业务关系中，怎样抽取有效的、核心的、有决策意义、多数人所关心的需求成为一个很大的难点。