BW顾问必需要清楚的：时间相关数据建模场景需求分析

 

场景需求分析
A场景实现
B场景实现
C场景实现
D场景实现

 

场景需求分析

 

对于某些与时间相关的数据（主数据有变化的数据）进行分析时，根据用户不同的需求，数据可归为4种不同的场景中，这4种场景是我们BW顾问建模之前一定要弄清楚的，要根据业务用户的需求才能确定采用那种场景，选定场景后我们才能开始建模。下面我会是针对这四种不同的场景，有不同的实现，其统计分析结果是不一样的

需求分析：BBB物料在2000.01月份所属物料组为Food，而到了2000.02月份时变为了Chemicals了，并且在2000.02月份新增了EEE物料主数据，在2000.01月份与2000.02月份BBB都产生了交易数据（但EEE物料只在2000.02月份产生了交易数据）。这样在统计时，BBB物料是归到Food组还是Chemicals组？由于归到哪组参照的标准不同，这就产生了下面不同的4种场景。

• 场景A：能够还原业务数据的真实情况，这种是遵循历史的。此场景下，BBB物料在2000.01月份产生的业务数据会被归到Food组；在2000.02月份产生的业务数据会被归到Chemicals组
• 场景B：只注重于当前，不遵循历史，根据出具报表时间来判断物料所属组。也就是说不管以前BBB物料曾经属于过哪些物料组，只看现在它属于哪个组。比如查看报表的日期为2月份，则BBB物料在1月分产生的业务即使属于Food，但还是归到当前最新所属物料组Chemicals
• 场景C：与场景B相似，不同的是，场景B只的依据是查看报表的当前时间，这个标准是定死的，即当前时间，另一个不同的地方是在建模方面，物料组属性在场景B是与时间无关的，但在C场景中是相关的。场景C在B的基础上更灵活，你可以设定这个标准为过去的某个时间点，也可以是当前时间，这种可变标准是通过报表里的变量Key Date来实现的。此场景下（假设当前已经到了2000.03月份了），如果Key Date设定为2000.01月份，则BBB物料在2000.02月份产生的业务数据虽然在历史上来看属于Chemicals，但还是会被归到Food组；如果Key Date设定为2000.02月份，则BBB物料在2000.01月份产生的业务数据虽然在历史上来看属于Food，但还是会被归到Chemicals组
• 场景D：具有可比性，即只统计一段时间内主数据未发生过变化的数据。该场景也是在C场景的基础上（物料组属性也是与时间相关的），物料主数据属性附加了两个有效期字段，这两字段实质上与系统产生的有效期字段是完全一样的，另外也有Key Date，因为如果没有Key Date，而查询时间相关的属性时，会以当前时间为Key Date，所以为了像场景C那样数据的真实性，所以还是加上了Key Date变量。在D场景下，如果当前日期已到了3月份，则在查看1996.1到9999.12之间从未发生过变化的数据时，BBB与EEE就不会出现

 

场景A实现

场景A另一实现示例请参考另一篇文章：HR数据抽取

 

场景A：数据在不同时期所属有变化，但变化后在统计时也要区分开来，即原来与现在是属于哪类还是属于哪类，要符合历史实际情况，一就是一，二就是二。这种需要将主数据特征与其变化的属性一起作为CUBE的维度，同时出现在Cube中（即变化的属性特征也会现在交易数据里）。下面针对该场景进行实现：

    

从上面的主数据源文件来看，物料组要设计成为物料一个属性，为了遵循数据历史的客观性场景，需要将物料组的数据还需要存储到CUBE的物料组维度字段中，让物料组信息成为交易数据的一部分，这样才能记录下每条业务发生时，该业务数据到底属性哪个物料组。要将物料组信息也直接存储到CUBE中，能不只是简单的将物料组设置成为物料特征的导航属性就可以实现的，而是将物料组设置为非仅属性（非Attribute  Only，表示该物料组属性不仅是某物料的属性，而且还有相应的底表），设置为非仅属性后，就可以将物料组这个有主数据的特征直接引入到CUBE的维度中，作为维度表中的物料字段而存在，而非导航属性。这种设置，完全是为了实现场景A来设置。

由于Cube维度中直接出现了物料组这列，这样Cube就要求交易数据中要有物料组这列，但从下面提供的实际交易数据来看是没有的物料组数据的，这就要求在Transformateion转换规则里对物料组这列进行填充，具体请参考后面过程。

 

下面开始建模：

创建物料主数据的数据源，并加载一月分的数据到ZMTR00中。结果数据会是这样：

物料组特征需直接在Cube的维度中使用，所以需要去掉此勾 ：

 

否则在Cube中引用物料组特征属性ZMTRGP00时会提示它只是个属性，不进使用：

 

创建CUBE，并且将物料特征ZMTR00的物料组属性特征ZMTRGP00引用进来，也作为一个维度：

除了将物料组ZMTRGP00设置 为物料ZMTR00的属性外，还需要将物料组属性特征ZMTRGP00设置为CUBE的维度，这样物料ZMTR00与其属性ZMTRGR00都会出现在维度表中，处于平等地位。但是，交易数据中并没有此列的值，所以物料组属性特征ZMTRGP00的值只能从物料特征ZMTR00主数据中的物料组属性里读取，并在Transformateion里进行赋值处理。

 

规则 Read Master Data：表示目标字段的值从指定的InfoObject特征主数据表里读取相应属性来填充，这就要求源字段是由InfoObject特征字段组成成，并且这个InfoObject带有主数据。由于这里的源是一个DataSource，组成DataSource的字段不会是InfoObject，而是普通的数据库表字段定义，所以上而会提示出错。满足这种要求的源（字段由InfoObject组成，而非普通表字段），只能是DSO、CUBE等。下面我们只能使用DSO过渡一下：

创建DTP抽数，这样就将交易数据存储到了上面这个过渡DSO中了。

再为Cube创建Transformateion，源为上面创建过渡型DSO：

此时源为DSO，而非DataSource了，并且组成DSO的原字段中有ZMTR00这个InfoObject，且这个InfoObject具有主数据表，并含有ZMTRGP00属性，所以这个DSO可以用为 Read Master Data 规则的源：

再为Cube创建Transformateion：

并且为了模拟交易数据的过程（交易数据本应该分两次抽的，一月与二月分开抽），所以要为DTP加上过滤条件，分两次抽取，这次只抽一月份的数据：

运行这个DTP，一月份4条交易数据已被抽到CUBE中去了：

 

到目前为止，一月份的主数据与交易数据都已加载完成。下面进行二月份数据加载

加载二月份主数据：

再查看P表：

 

发现P表里有M版本的，所以在更新主数据后，要激活一下主数据后更新的数据才生效：

 

加载二月份交易数据，为CUBE新创建（原因是由于DSO中的数据已被上面CUBE的Delta DTP抽过了，再使用那个Delta DTP是抽不上数据的，所以重新新的DTP）一个Full全量的DTP（也可创建一个Delta DTP，因 为此时两个Delta DTP条件不重叠也是可以的），并将DTP过滤条件设置为二月份的：

此时CUBE中的数据如下，且满足场景A的需求了：

  

 

下面进行报表设计：

由于报表查看器（Business Query）Excle有问题，所以临时使用ECC自带的查看器 RSRT 来查看：

  

 

结论：这种正是因为将物料组属性也放在了维度表里，记录了物料属性哪个物料组的全过程，所以BBB在2000.1月与2000.2属于不同物料组时，也记录下来了。并且在出报表时，也是基于此维度表来查询某个物料属于哪个物料组的，所以场景A的统计结果不会随着查询时间变化而变化：

 

场景B实现

 

场景B：根据查看报表时间的不同，查询的结果会有所不同，其结果是以最新的数据状态来展现，不管过去是啥，只注重于今天。这种只需要将变化的属性作为与时间无关的导航属性即可，这是我们通常的做法。下面针对该场景进行实现：

 

下面直接在场景A实现上继续。

这里我们并没有将A场景中的CUBE的物料组ZMTRGP00维度给删除。现将ZMTR00的属性ZMTRGP00修改成导航属性（非时间相关），并在CUBE中打上勾：

这样在Query Designer里就会看到物料维度下有三个维度字段：

 

结论：由于直接使用的物料组属性是存放在主数据表里的，并且该属性与时间无关，所以物料主数据表里的物料组属性值只能存储最新的值，比如这里在2000.1月时BBB属于Food，但到了2000.2月后却变成了Chemical了，最后使用最新的Chemical覆盖了以前的Food，并且这个变化过程并未记录下来，所以报表在2000.2月之前某个时间点查看与在2000.2月之后某个时间点查看的结果是不同的（在2000.2月查时，会将以前为Food的销售额也看作成了Chemical了）。所以场景B的统计结果会随着查询时间点的变化可能会发生变化，原因是主数据属性随着时间发生了变化

 

场景B的第二种实现：

场景C实现

 

场景C：根据查看报表指定的Key Date不同，查询的结果会有所不同，一笔业务数据到底属于哪个范畴，则根据指定的Key Date来划分，这样，一笔数据在昨天看来或在今天看来是不一样的。这种与场景B有点相似，只不过B只能根据查询报表当前来定业务数据到底该划分到哪个组，而场景B除了根据当前外，还可以基于历史的任一天来灵活查看。下面针对该场景进行实现：

 

由于该物料的物料组属性设置的与时间相关，所以会出现0DATETO与0DATEFROM两个字段，按理需要物料主数据文件里有这两列，为了省事，就在Transformation里设置对应固定值，这里抽的是2000.1月份的主数据，所以有效期设置为 2000.01.01 到 2000.01.31：

物料主数据表数据如下（系统会自动为每个物料加上两个有效期：一个是在输入的有效期之前的期间，另一个是在输入的有效期之后的期间）：

从上面数据来看，系统会自动为每个物料多生成两个期间，一个是在我们指定的有效期之间的期间，另一个是在我们指定的有效期之后的期间

下面再次抽取2月份的物料主数据，先修改转换规则的有效时间为2000.02.01 到 2000.02.29：

 

 

创建CUBE：

创建转换规则时金额字段报错：

编辑规则，由于金额字段的单位固定为RMB，所以这里不需要对金额进行转换：

 

下面创建报表测试：

    

由于Key Date输入的为 2000-01-15 ，在这一时间点上，EEE 还没有对应的物料组属性（即那个时候还没有产生业务数据），所以是 # 表示。其他物料都是按 2000-01-15 这一天所属物料组来统计的，如 BBB物料，虽然在2000.2月份变成了Chemical组了，但输入的Key Date为2000-01-15，则按2000-01-15这天的标准来判断BBB物料到底属性哪个物料组，经到数据主数据表里查找这一时间点（2000-01-15）所对应的组还是Food，而不管业务什么发生的，而是按查询时指定的Key Date为依据进行判断，所以BBB物料在2000.2月份的销售金额原本属于Chemical的，却还是归到了Food组了：

 

 

 

再将报表的Key Date设置为2000.02.15：

 

原本BBB有一笔在2000.01月份业务发生时，是属于Food物料组的，但由于Key Date输入的为 2000-02-15，即物料属于哪个物料组要按着这个指定的Key Date为判断依据，所以这笔发生的业务要算到Chemical物料组里而不是Food组

 

结论：主数据的属性随着时间的变化而变化时，数据统计的标准可以是过去的某天，也可也是今天。同一笔业务数据根据不同的Key Date分类统计时会划分到不同的分组里，这样以不同的时间点来看报表时，统计结果会有所不同

 

场景C第二种实现：

场景D实现

 

 

注：由于同一InfoObject属性里不能多次添加同一属性，所以通过Reference的方式创建Valid From与Valid TO：

    

 

从场景C中物料特征复制，加上两个日期字段 Valid From与Valid To，并且做为时间相关的导航属性：

 

创建好Transformation后，加载主数据：

 

Cube从场景C中复制并修改如下：

加载交易数据：

 

报表设计：