在当今互联网发达的信息社会，处处充满商机，有商机的地方就有大量数据。就数据本身而言，并不是越多越好，也并不是存在就有价值。只有把数据跟它所在的需求背景相关联，并转化为价值，这时的数据才具有存在的意义。商业智能(BI)是一种企业辅助工具，利用BI将数据进行处理，来支持并产生企业决策。

　　企业经营分析的目的是通过分析的结果资料，提供具体可行的改善方案，给经营决策层进行参考，已达到合理化管理和提高经营绩效的目的。具体来说必须借助企业内生产、物料、成本、财务、HR等全部资料进行分析才能产生分析结果资料。

　　任何需求来源于业务，业务决定了需求，需求分析的正确与否关系到BI项目能否成功。因此数据模型在数据仓库中的作用尤为重要。在现实项目中，有很多比较死板的数据模型，面对更多报表与业务分析时，只能依靠BI工具去努力实现新的业务逻辑。比如工具不能支持，或没人能挖掘出这个功能，那么就会耽误整个项目的进程。

　　BI项目的经典办法是确定业务系统范围，根据分析要求构建数据仓库，开发ETL过程获取数据，分析建模并根据分析模型进行分析应用(展现)实施，最后完成交付。这样的过程有很多成功的案例自激励着我们，但有更多不如意和无奈的项目在提醒我们。原因有很多究其本源，一方面是经营分析范围或者说是内容方面，一方面是经营分析方法层面的问题。客户往往希望在具体的项目中一次解决两各方面的问题。

　　这样我们的BI团队面临以下挑战：

　　第一，要了解面向业务级应用，针对不同业务部门的具体需求，如何在统一业务语义模型的基础上，而又满足不同部门不同阶段的业务分析需求;

　　第二，如何在具体的逻辑建模上去满足客户业务需求，包括从粒度、周期、字段描述等角度结合。如何基于成熟行业模型产品去扩展表、视图、字段，并根据需求去合并、汇总来满足客户业务分析、挖掘和查询需求和需求变化;

　　第三，对分析维度的重定义。分析维度往往来源与ERP等业务系统的档案数据，但是进行业务分析时这些档案所产生的维度远远不够，比如进行成本分析时扩展维表以满足客户个性化的维度描述的需求，包括以扩展字段的方式，也包括表、视图的扩展;

　　第四，对事实表的扩展。扩展事实表，以及满足客户对分析的需求。包括结合度量和新的维度描述，生成新的字段，也包括维度事实表的建设;

　　第五，用数据模型支撑ETL。在ETL阶段，往往会因为数据量太大，而导致不能在客户要求周期内完成ETL，造成BI整体失败。

　　如果不谈BI产品从数据模型层面谈，我们需要把数据模型更灵活更高效的建设起来。如果在项目中，只是根据业务需求做临时的数据模型，这样对整体业务起不到很好的支持作用，并且一旦业务需求发生变化，原有的数据模型需要做重大修改。

　　这就需要在DW中构建两种不同的数据层面，一层是大家都比较熟悉的业务主题数据模型，根据系统中抽取的业务数据创建业务主题分析数据模型，根据业务主题进行数据分析这方面在已经有很多案例，也有成熟的方法论。但这样做是工程性的工作，通过业务数据创建的分析模型对业务数据本身有极大的依赖性，不同的项目可以进行复用的是方法，而非分析模型本身，而且跨主题的分析对模型而言是极大的挑战。

　　如果基于业务主题数据模型再构建一层——分析主题数据模型，通过分析数据模型用户可以定义出ERP系统或其他业务系统中不存在的分析维度(而这些维度是分析所必要的)，如分析利润用户需要定义利润组成项目，典型案例如会计报表中的损益表(虽然损益表的格式是基本固定的但企业中的分析不仅仅限于这些固定报表)。分析主题数据模型需要提供相应的构建功能，完全可以由用户自行创建分析项目，并根据创建的分析项目从业务数据中填充数据，完成数据获取。

　　根据分析要求定制的分析主题数据模型，无需考虑系统中业务数据是否满足，基于公式表达式的数据处理，可以为分析数据提供更加灵活的数据获取方式。定制的分析主题数据模型能够从业务主题数据模型中填充数据，也可以从外部数据导入填充数据。一方面：实施人员可以基于分析模型进行分析展现的实施，通过导入数据与最终用户进行沟通确认。另一方面：实施人员和最终用户都可以基于分析模型的要求完成业务数据处理的设置，如果业务主题模型中的数据不满足根据实际情况扩展业务主题模型，或者通过分析数据模型提供的导入模板完成数据导入。

　　分析主题数据模型由于其在结构方面脱离业务语义可以在不同的项目中复用，维护分析数据模型的经验可以得到有效的复制和传播，基于分析主题数据模型完成的分析应用也可以在不同的项目中进行复用。对实施伙伴和用户而言，对分析数据模型使用时间越长，积累越多，能够获得更多的效率提升和专业提升。对BI团队而言能够资产化的可能性越高，可以将资产化的分析主题数据模型和分析应用再作为最佳实践进行传播，最大化的固化和沉淀每个项目成果提升团队的交付效率和业务分析的专业性。