2.3 主数据设计难点

BW 的主数据设计在一些特殊应用场景下是件令人头疼的事，本节将介绍几个典型的主数据设计应用案例，帮助读者理解数据仓库中传统的主数据设计方法，以及BW是如何实现主数据设计的。

2.3.1 主数据还是业务数据

在企业数据仓库建设过程中常常会出现下面这种情况：某个主题的数据信息有多个来源，而且随着业务的发展，数据会产生变化，如商品的描述、分类、产地等。在分析型系统中，为了更灵活地为前端的分析应用提供便利的数据支撑，往往需要将主数据分离出来，如图2-20所示。

虽然将主数据属性存储在业务数据表中会让数据分析变得简单，但从长远来看，这种建模方式存在很多弊端。

（1）数据冗余。如果同一产品出现在同一业务数据表或不同表的多条记录中，就会导致相同关系的冗余存储，大大占用HANA存储空间。

（2）数据固化。主数据更新的时候只能保存最新值，不能保存不同语言的文本，也不能保存主数据层次结构的不同版本。

（3）数据不一致。当主数据存储在不同的表中或一个表的不同数据条目之间存在延迟时，数据同步的难度很大。

（4）业务混乱。当原始的主数据值中有错误时，由于它们被存储在大量的业务数据表中，因此很难找到所有的错误，也很难改正错误。

（5）更新困难。如果主数据属性关系改变，则必须在业务数据表的每条记录中更改主数据值，这将导致ETL加载时间很长。

分离主数据后，不仅可以减少数据存储容量，主数据的更新和校验也变得更容易。除此之外，还可以针对不同语言的文本及层次对象进行管理，如图2-21所示。

将主数据独立建模的优点是便于检查引用的完整性。SAP认为，在数据仓库中，主数据应该只接收有效的值，这样可以消除主数据表中无效条目的记录。

如果在SAP BW/4HANA中进行数据流处理，那么那些没有在主数据表中列出的数据将被识别为错误。根据缺少条目的原因，有两个方法来修复它：一是将缺少的实体加载到主数据表中；二是纠正业务数据源中的条目。但是，在修复之后还需要重新加载这些数据。

如果使用SAP HANA视图，可以使用内连接来消除值与主数据表中的条目不匹配的记录。

SAP建议将主数据和业务数据分开存储。这样做有以下好处。

（1）节省存储空间。模型将单独存储每个独立的主数据。

（2）多语言支持。文本常常依赖于语言，这样更容易实现国际化。

（3）简化数据流。主数据更新的条目通常比业务数据少。如果主数据关系发生变化，则不需要重新加载业务数据。

（4）数据容易保持一致。不同模型引用了同一个主数据（如供应商），当主数据更新后，所有数据域的模型均会同时获取最新纪录。

（5）实现灵活的分析支持。更容易实现标签类应用，如每个类别有多少产品、产品类别更改的频率等。

然而，并不是所有的场景都适合将主数据与业务数据分离，下面将介绍需要将主数据与业务数据合并在一起的情况。

2.3.2 时间相关的主数据

通常，企业使用的主数据都是最新的信息，如产品分类、供应商所在地区等。但数据仓库不仅要对业务数据进行历史分析，也要对主数据进行历史分析。例如，在SAP HR人事主数据中，一个人的职业级别会发生变化，今天是初级，明天经过企业内部评定后就可能变为中级。那么，在不同日期统计出的各级别数据就应该体现出差异（初级减少1人，中级增加1人）。为了能正确反映这种随时间变化的数据，SAP BW提供了一些建模机制，统称时间相关性处理。

信息对象中的时间相关属性被勾选后，在主数据表中就会增加开始时间和结束时间两个字段，并且结束时间字段是主键，这样在主数据中就能按照时间区分同一个属性。例如，员工甲在2022年2月5日前在生产部，2月5日调岗到营销部，那么在主数据表中就存有两条数据记录，如表2-6所示。

在信息对象中用导航属性加时间相关的方法，可以区别不同时间的不同状态。但是，这一方法有一个缺陷：在生成数据报表的时候，只能把员工甲按新的架构统计到营销部，或者按以前的架构统计到生产部，无法在一张报表中用两种状态对他进行统计，以正确反映员工甲的历史情况。也就是说，无法正确生成如表 2-7 所示的报表（这种需求在人事部门很常见）。

要解决这个问题，一个比较好的方法是把组织单位这个与时间相关的维度看作模型里的一个特征（而不仅仅是主数据导航属性），在 ETL 过程中把历史数据保留在业务数据模型中，如表2-8所示。

一个属性是比较容易处理的，但是如果有多个时间相关属性，如教育信息、组织信息、奖惩信息等，那么传统的建模方式就不能准确表达员工的真实情况。

例如，员工甲在组织单位表中有如表2-9所示的数据。

员工甲在人事范围属性表中有如表2-10所示的数据。

如果要把这些变化记录到员工甲的统一属性表中，必须按照每一次变化的时间点把数据分割成多条，这样才能在每个时间段找到员工甲对应的所有正确属性，这种方法就是时间分割。从员工甲的个人数据中可以看出，其组织单位有一次变动，人事范围也有一次变动，如果用图形来表示，可以很直观地看出，员工甲的属性在时间轴上被分割成三段，如图2-22所示。

分割后将数据存入一个属性表，如表2-11所示。

可以看到，经过时间分割，前两个表中的数据在属性表中各有两条记录。在属性表中，在每个时间段都能找到员工甲对应的正确属性信息。

这时，将每个时间段的主数据属性关联到业务数据中便容易多了。

时间相关建模还有一个较棘手的问题：如果一个信息类型（一种属性）在一个时间段内重复出现怎么办？以奖惩信息为例，员工甲在2022年1月1日到1月31日期间得了两个奖，一个是道德风尚奖，另一个是劳动模范奖。企业需要一个如表2-12所示的统计表。

如表2-12所示，根据实际需求，可以从模型中获取每个月女性得奖人数和罗湖工厂得奖人数。但是，得奖情况无法直接从模型中获取。因为在该模型中，每个月每位员工只有一条记录（数据源只有一条记录），每位员工只能对应道德风尚奖或者劳动模范奖，无法统计一个月内获得两个奖的人数。

在SAP ERP中，子信息类型也会导致时间重复。子信息类型是指当仅按信息类型无法精确区分某个人员属性时，通过加上附属信息类型来进一步区分。以教育信息类型为例，它需要分为初中、高中、大学等子信息类型才能精确定位和维护具体信息。

因为存在子信息类型，所以可能会导致同一时间段内同一个信息类型中的字段重复出现（例如，家庭住址和办公地址可能是同一个地址，而且可能在同一时间段内出现，因此虽然两个地址的字段相同，但是表示的含义不同，需要做特殊处理）。

子信息类型是导致时间重复的一种特例，必须有一套额外的建模机制来对其进行合理的处理。

2.3.3 带有时间趋势的层级主数据

趋势分析可为企业经营管理提供参考。在分析数据的过程中，如果层级主数据也是时间相关的，那么建模设计会更加困难。

企业的组织架构通常会随时间发生变化，如果企业在某一年需要从组织架构维度分析12个月的销售额，或者分析物料类别的采购额，那么一般有两种分析方式。

方式一：以当前最新的组织架构分析销售额及采购额。

方式二：以业务发生时的组织架构分析销售额及采购额。

这两种方式在实践中均有应用，也各有优劣，如表2-13所示。

例如，某公司的营销部有A和B两个事业部，两个事业部各有两个销售大区，四个大区在2012年12月30日、2012年12月31日、2013年1月1日都有销售额，如表2-14所示。在2013年之前，A1和A2属于A事业部，B1和B2属于B事业部。到了2013年，公司调整了组织架构，两个事业部下面的大区调换了位置。

正常情况下，分析报表会基于一个关键日期（Key Date）来确定主数据对应的时间段，这个日期决定了用哪个组织架构来显示数据。简单来说，报表要么以2012年的组织架构显示数据，要么以2013年的组织架构显示数据，如图2-23所示。

以某个具体时间点来看，以上报表是没有问题的。但是站在业务的角度来看，以上报表中信息的缺失是比较严重的，无法直观反映组织架构的变化，也无法准确表达各事业部的销售额。因为在2013年之前，A事业部应当计算A1和A2大区的销售额，从2013年开始应当统计B1和B2大区的销售额。B事业部反之。

那么，如何正确反映组织架构的历史变化呢？以下是两种具体的解决方式。

第一种方式非常常见，即将主数据合并到业务数据中。如果有层级主数据，则将各个层级通过代码重新组织成平面结构。例如，某企业的组织层级有7个，那么创建7个特征：层级1、层级2、……、层级7。在ETL过程中根据组织特征读取层级表，把每个层级的节点读取到7个特征中。这样会使每条数据记录对于相应特征都有 n 个字段（ n =层级数）记录每个实际层级节点，且任何时候的各层级节点都是实际节点，而不存在Key Date。这样做的好处是报表的灵活度和性能都比较好，缺点是无法在报表中通过层级进一步展开维度。

第二种方式是借助BW信息对象的“使用时间层次结构连接”功能，如图2-24所示。

接下来，需要在创建关键日期派生类型，如图2-25所示。

和货币转换类似，可以选择参考时间特征为0CALDAY、0CALMONTH等。不同的是这里有个派生类型的概念（注意，这个字段只能在创建的时候修改）。

派生类型有三种：

（1）期间内的第一天；

（2）期间内的最后一天；

（3）延迟天数（在Delay by days字段中指定）。

关键日期是从时间段的第一天加上指定的天数减1开始计算的。如果关键日期不在该时间段内，则使用该时间段内的最后一天。

最终可以看到，在Query结果中，多了一个有效性字段，将各大区归属事业部的时间显示出来，并且销售额能正确对应到各自的维度上，如图2-26所示。

以上两种方式的对比如表2-15所示。