对重要的主数据，采用正确的方法以满足对历史数据分析的不同需求数据仓库是面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。反映历史变化、满足对历史数据分析的不同需求是数据仓库建模需要认真考虑的一个问题。SAPBI把数据分为主数据和交易数据，交易数据反映的是业务交易发生时的真实情景，较少涉及企业架构、产品分类等变动带来的影响。企业架构、产品分类等数据的变动产生的影响通常是通过主数据的变化来体现的。(1)示例业务场景介绍以下面的一个业务场景为例，具体认识SAPBI是如何以不同的建模方法来满足不同的分析需求的。这是一个组织结构变动的例子，如表1和表2所示。子公司母公司AAAXBBBXCCCY从2008年8月1日起，集团的组织结构作了变动，新增了DDD子公司，并把原来从属于X母公司的BBB子公司划到Y母公司旗下。子公司母公司AAAXBBBYCCCYDDDY由于组织架构的变动，集团的管理层对业务数据的分析可能存在不同的需求。不同的用户出于不同的业务需求也往往对如何分析历史数据存在不同的想法，在这一部分我们将深入探究4种不同的业务需求场景。得益于SAPBI主数据和信息立方体相分离的建模方法，这些不同的业务需求可以通过同一个信息立方体同时予以满足，所不同的只是主数据的设置方式而已。2008年7-8月某集团的业务收入子公司时间收入AAA200807100BBB200807100CCC200807100AAA200808100BBB200808100CCC200808100DDD200808100业务场景一、“老架构、老数据”。业务需求。用户希望以实际业务发生时的组织架构为依据，统计母公司的业务收入。也就是说，将7月份AAA和BBB子公司的收入记到X母公司账上，ccc子公司的收入记到时Y母公司账上。在8月份AAA子公司的收入记到X母公司账上，BBB、ccc、DDD子公司的收入记到时Y母公司账上。业务需求场景一2008年7-8月某集团的业务收入母公司时间收入X200807200X200808100Y200807100Y200808300这种需求注重的是历史的真实性，汇总后的数据真实反映了集团在组织架构变动前后母公司的收入总数的变化。但是这一方式忽略了各个母公司所包含的子公司组成的变化，不同历史时期的数据统计口径不统一，不同时期数据的可比性差。建模方法：针对这一需求，一种可行的建模方法是将母公司作为组织架构维度当中的一个特性直接保存在信息立方体中的维度中。如果数据在从源系统上传到BI系统时，业务数据只包含子公司，而没有包含母公司的信息，就需要在信息立方体的转换中定义母公司信息的更新方式。具体实现步骤如下。第一步:定义主数据(信息对象)一个行之有效的方式就是将母公司定义成子公司这个信息对象的一个属性。在信息对象的编辑窗口中定义，激活信息对象后，就可以往信息对象中加载子公司的主数据。第二步:维护或者加载主数据在2008年7月之前，主数据的信息如图5-27所示，通过信息对象的右键菜单中的"维护主数据"可以看到。第三步、建立一个infoCube来测试。我创建了一个infoCube：IC_RENO12,TimeDimension我加入了0CALMONTH，UnitDimension是因为KeyFigures加入IK_RREV自动加入的。子公司dimension加了SUB_COMP1,母公司Dimension加了PAR_COMP1.KEYFigure加了IK_RREV.这个infoCube很简单。但这里注意一点，有可能在加PAR_COMP1时有个错误提示，无法加入，那是因为你在创建PAR_COMP1时系统默认勾选AttributeOnly，这时你要unCheck这个选项，如下图：第四步：为IC_RENO12创建数据源。此数据源是用来读取CSV文件，文件就是交易数据，主要是子公司，交易月份，交易金额，交易币别（注意这里没有母公司）。第五步：创建Transformation，其中PAR_COMP1的规则是ReadMasterData.第六步：激活transformation，接着创建它的infoPackage和DTP。第七步：加载交易数据。第八步：创建一个Query,显示交易数据。如下图：第九步：在2008年8月之后，随着主数据的信息的更新，及时维护BI系统中的数据。根据业务需要修改SUB_COMP1的主数据：把BBB的母公司改为Y，并增加DDD公司。第十步：加载2008年8月之后的交易数据，如下图：第十一步：用第八步创建的Query,显示交易数据。如下图：总结：这种方法是用业务发生时的标准来统计数据，实现的方法就是...