数据建模分析

数据建模分析

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 权限问题

对于数据仓库项目而言，权限问题是一个重要的问题，应该及早考虑。