数据建模分析

1.建立模型前应该想到的问题。

1.1数据仓库的数据组织是面向主题的，而不是报表。

   操作型数据库的数据组织结构面向事物处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题进行组织的。主题是一个抽象的概念，是指用户使用的数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。

   这和软件编程中的面向对象的概念类似，在项目中要面向一个功能模块的实现，不是面向一个方法的实现。在我们建模中，也是面向一个分析点的方面。

   可以参照以下主题，来判断如何划分主题：

      ！顾客的购买行为

      ！产品销售情况

      ！企业生产事物

      ！原料采购

      ！合作伙伴关系

      ！会计科目余额

   但是现在的数据仓库实施中，很多数据仓库需求都是来自业务部门的出具的报表的需求，这样数据仓库的数据模型结构往往来源于报表的数据需求。基于报表的需求要比没有明确的需求要好，所以现在大多数业务部门更多的是采用报表的需求方式来进行开发的，这样需求方和实施方都会拥有一个比较明确的界限和口径。

但是面向报表的开发不是最好的，而且有很多缺点。所以我们正确的做法是，要对现有的报表需求进行细致的分类，分析和调整，不能为了实现单个报表而进行大量的建模工作。要根据分析的不同内容和主题对报表进行分类，明确报表中每个数据的定义，统计口径及不同数据之间的关系，建立在整个数据仓库内统一的数据指标定义，将数据指标按分析主题及分析维度进行归集，从而形成面向主题的数据类型。

       例如：我们的利润表报表，当业务部门发我们一个利润表的报表，作为需求时，我们应该进行细致的分析，最终我们确定我们面向的主题不是利润表，而是比利润表更大的一个层次的所有科目业务量的主题，这样我们在做别的报表，例如资产负债表，现金流量表等报表时，就不用重复建模的工作了，做到了软件工程中的可重用规则。

   1.2数据仓库要实现对数据的集成与数据的同构性。

      面向事物处理的操作型数据库通常与某些特定的应用相关，数据库之间相互并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取，清理的基础上经过系统加工，汇总和整理得到的，必须消除源数据的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

      例如：在总公司和分公司之间，某个部门id或公司id名字不一样，不是同构的，比如一个人家人叫他张三别人叫他小张，这种情况在数据库中一定会被认为是两个人，所以我们要建立统一的数据字典，来统一数据。

      要实现数据的同构性，是一件复杂的工作，涉及到大量的数据转换工作和调研工作。在数据的获取阶段，要确保所有的数据来源是一致的，或者经过一定的处理后是一致的。如果数据来源不一样的，那么我们就有必要把数据来源信息也包含在数据仓库中，以便在后续的数据转换中对不同来源数据进行分析。

      综上所述，我们在项目开始之前，要对现有数据建立统一的数据字典，交付品应该有一个《XXX数据字典》的文件。

   1.3明确数据库历史数据和即时数据

      操作型数据库主要关心当前某一个时间段的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一点到目前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势作出定量分析和预测。

      但是数据仓库中还包括即时的数据分析需求，所以我们要安排好历史数据和即时数据以及明细数据之间的不同存储方式，采用不同的处理方法。根据业务分析需要进行数据存储划分，对不同的分析要求提供不同明细级别的数据基础。此外，还要对数据或信息的生命周期有良好的管理，安排好旧的归档工作。

2.sap bi项目流程和分析方法

2.1收集客户需求

用户的需求工作是一个非常关键的环节，因为用户的需求可能详细可能不明确，也可能会经常变动，所以建模之前要收集足够的信息，要对客户的需求进行深度挖掘。

2.1.1组织架构

       这一方面不仅仅是报表本身需要的数据，还涉及到系统权限和报表发布等工作的需求。要了解各个部门的基本业务，业务流程，考核指标，担负职责。了解各个业务部门对内或对外的主要产品和服务。了解客户的以业务流程，明确bi应该展示的分析内容是正确建立模型的需要。一般情况下，客户都不能用技术术语去表达他们的需求，所以有时候需要在技术应用方面的帮组下把他们的需求转化成技术语言。

    2.1.2 客户最需要分析的数据指标

       对于客户所要分析的数据的整理一般先从数据指标入手，清理指标之间的关系，再结合分析的维度与报表分析需求进一步细化对指标的界定。数据指标主要指客户要分析的数据，如金额，数量等，在系统中反映为前面提到的关键值及多个关键值之间的一系列计算。

       在这一步分析时，我们会用到两个模板文件。

                        收集模板1

       如果客户需要其他部门的指标以完成数据分析，或者客户不能给出具体的计算公式，也应该让客户给出清单和简要描述，这些指标稍后会和其他部门的需求结果做合并。

                       收集模板2

    2.1.3数据指标的数据来源

       除了给出分析数据指标的列条和计算公式之外，还要收集每一个指标的数据来源，简单地对可用字段的一个列表显示是不足以建立模型的，有必要知道每一个数据指标取自哪个数据源。在确定信息需求能否实现时，确定数据源的问题是关键的。

      有些指标虽然有同样的描述，但是数据来源不同，可以看成是两个不同指标，如收入就分为很多种收入。

      在此我们要收集r3数据源的名称，如果文件数据源我们要收集外部文件。

    2.1.4 对数据指标的分析对象

        这是对以上指标更细一层的考虑，一方面要明确分析的周期，是每天分析一次呢，还是一个月生成一个报表。另一方面要知道是哪些部门的需求，和业务分析的对象，也就是维度。

                     模板文件

      但是如果应用相关的KPI进行分析时，比如每个部门或权限看到的数据是不一样的，那么在计算指标，如利润，金额等指标都要求能在事业部级别能够进行分离，从而实现各自的计算。

    2.1.5数据指标优先级

        任何一个项目的范围都是有限的，不可能在一个项目中完成用户所有的或所有用户的分析需求。因此有必要对客户分析指标的优先级进行排序。一般可以从指标的重要程度，紧急程度，和影响程度3方面进行评估。从项目实施的角度看，重要成度好，需求紧急，影响范围大的KPI可以纳入项目实施范围，其他分析指标可以在项目上线后视需要而逐步扩展。

    2.1.6 权限问题

        对于数据仓库项目而言，权限问题是一个重要的问题，应该及早考虑。SAP BI可以支持从信息范围到信息对象的多级别的灵活的权限设置。在信息收集时可以请客户描述他们需要对什么业务分析角度进行授权，如报表需要对部门，区域进行授权等。

    2.2 如何收集客户需求

      2.2.1 面谈

         面谈的对象多是业务人员，所以在收集信息的时候，要使用业务语言与面谈人沟通。不论是一般的数据仓库还是SAP BI，都有大量的特有术语，比如维度，特征，关键值等，直接使用这些术语，问客户使用那些关键值是行不通的。讲业务语言而不是技术语言，是与业务人员进行沟通的基本条件。其次，要保证对每一个角色至少两次面谈，因为对同一问题对于不同的人会有不同的理解，就是同一问题对同一个人不同时期也有不同的回答，所以要多次面谈准确获取需求。可以采取小型会议的方式。

     2.2.2报表样例分析法

      报表样例分析是通过收集分析客户目前使用的报表，现在大多企业都是采用这种分析方法。

      如何收集：

（1）更正报表名字

报表-XXXXXXX

（2）基本信息：[填写报表的基本信息]，模板：

（3）查询条件

（4）基本格式

     画出你的报表基本格式

（5）数据指标说明

描述指标

        （6） 业务分析角度

               业务分析角度:

（7）权限要求

报表需对部门，区域进行授权。

（8）其他要求说明

2.2.3分析客户需求，形成分析模型（逻辑建模）

     数据仓库的建模需要经过一个由粗到细的过程，即从高层次的逻辑到低层次的物理数据结构建模不断细化的过程。在sap bi系统中，一方面自动集成了对数据库的管理，每一类数据对象都会自动生成相应的数据库表并由系统自动管理，另一方面由于引入了信息对象，每一个信息对象都是一个实体，每个实体所具有的属性是在定义信息对象的时候考虑的。这样就简化了建立分析模型时的工作量，使建模的重心集中在对实体之间关系的建立上，这正是高层建模的所要完成的工作。

（1）实体-关系模型

              高层建模一个有力工具就是实体-关系模型，这是设计的第一步，但是实体-关系模型并不等同于分析模型（逻辑模型），这只是建立分析模型的

           第一步。

画出实体之间的关系图，可以确定哪些实体属于模型范围，哪些不属于模型范围，也就是确定了所谓的“集成范围”。

               集成范围定义了数据模型的边界，而且集成范围需要在建模之前进行定义。这个范围由系统的建模者，管理人员，和最终用户共同决定。如果范围没有事先确定，建模过程就会一直持续下去。

         实体-关系模型与数据仓库分析模型还有很大的差距，无法直接转化成数据仓库的分析模型。

（2） KPI与分析维度

a.对KPI进行分析和分解

信息收集的过程会要确定客户需要衡量的指标，如数量，订单记录和成本等。但是客户最终查看的指标大多数是经过计算的，具有综合性数据才称的上KPI。一般做法是先从分析KPI入手，首先要从面谈中获得相关的KPI，再是要对KPI进行还原，明确KPI的计算方法及其基础数据的来源。这个过程中，才可以确定数据模型里需要的关键值。

比如，利润同比指标值是一个常用的指标，但是在模型里，一般是不会存储这个数值的。利润同比是是计算公式“本期利润/上期利润”，在做模型时，我们会把本期利润和上期利润作为关键值保存在模型中。实现这样的分析一方面有利于实现数据的重用，因为其他KPI计算也会用到这些数据。另一方面，只有基本数据才能实现度的灵活分析。比如我们保存了本期利润和上期利润就可以在年底时，计算出总的利润，当然本期利润和上期利润也是计算得出来的。

b.构建业务主题

第二步分析业务主题相关的属性，业务主题往往就是那些勇于描述KPI的特征。也就是说，KPI经常是包含业务主体的，如“某产品组的收入”就是一个KPI。收入作为一个具体的有特定含义的数值，是由特定的产品组来界定和说明的，产品组就是一个业务主题的一个体现，这样的特征很多，如客户，产品，销售城市等。

其次就是要对这些主题对象进行分析，分清报告领域的主要业务主题和他们的属性，找出那些是主题那些又是属性。

比如：地址和客户，如果我们的报告领域中，不需要从地区的角度来分析，但是又希望在看到客户时，能看到客户所在的地区，那么地址就要作为客户的属性来设计，反之则作为业务主题。

一般情况下主题和属性之间的关系是一对多的关系，通过诸多属性的描述，可以得到客户等对象的最详细的信息。但是有些情况下，也有存在多对多的情况，如一个产品有多个颜色等，这种情况下，我们设计时，要把他们作为的两个特征同时出现在维度表中，也是视实际的关系采用组合属性，时间相关的属性等方法。如例子中的一个人在不同的时期属于不同的地区，这就是多对多的关系，所以采用了时间相关的属性。

               c. 分配关键值与业务主题的关系

上两步我们根据实体关系模型，分析出了关键指标和业务主题（特征和关键值）。下一步骤就是理清业务主题和关键值的关系。正如前面提到的，关键值与业务主题的关系式密切相关的，所有的KPI都是在一定的业务主题的界定下才具有的含义。有些主题或分析对象对应着数量众多的交易记录，即事实表的记录，比如客户，账户等。也有些主题或分析对象和事实存在着明细记录上的联系，比如凭证号。后者往往涉及到对交易数据非常明晰级别的分析，同时维度表也会有大量的数据。还有一对多的关系等这样可以分析成各自的分析对象。

c.归集关键值，形成分析结构

根据以上的分析，形成一个具有多个关键值，公用一系列的业务分析主题的分析结构，这是构建立方体的一个基础。

2.2.4将逻辑模型变成物理模型

     在逻辑模型建好后，下一步就是将逻辑模型转化成物理模型，物理模型是有一系列的数据库表构成。在逻辑模型中，可以很容易的确认出事实和纬度。逻辑模型中心的关键值结构就是事实表中的数据，而周围的业务主题就是分析模型的维度，特征及其属性。

     这一步骤包括建立业务蓝图文档和在系统中建立模型。

2.2.5利用业务内容（bi content）加快建模进程。

     我们都知道使用bi content可以加快建模进程，如何找到适合我们的bi content组件呢？

（1）基于关键值的方法

a.充分理解逻辑数据模型。理解模型背后的业务是非常关键的，只是基于技术杀死那个的描述进行查找永远不可能得到100%效果。

b.将KPI指标分解为基本关键值。

c.使用业务内容资源库浏览器。

d.比较逻辑数据模型与业务内容中的信息立方体，查询，和工作簿的业务场景。注重从业务长江来比较不同的技术配置。

e.检查业务内容查询里的业绩指标的定义，是否和你业务分析需要相匹配。调查数据流向，最终确定最终的报表中使用到的关键值。

（2）基于数据源的方法。

a.主要关注是项目的源系统的业务流程。

b.根据业务需要检查源系统的数据源。在r3源系统中，业务都以明显的目录分配数据源。根据自己的业务查找相应字段，可能会需要增强。

c.从数据源向上查检逻辑模型中的维度里的特征。查找数据转换规则，信息立方体和查询。确定维度的数据源。

                （3）两种方法灵活使用。