关于SAP系统的调整

1、.：.；12 : 47 代理键的思索 代理键surrogate key这个概念是球派提出来的，在这个链接中可以找到kimball对它的描画，这篇文章还是1998年写的，比较早了。我们在2000年设计QiDSS时，采用的是informix公司的方案，基于redbrick、metacube，可以说这个方案充溢着球派的痕迹，毕竟kimball就是redbrick的开创人。在这种情况下，我们不接纳他的洗脑都难。运用代理键便是其中之一，kimball说了很多益处，我们也没法去验证，更来不及去疑心，反正不断都用着。不过时间长了，就有人提出疑问，happypu在dwway论坛上提出了这个问题，何谓代理建，a

2、tiger给出了答案，比较常规的回答，代理键一个主要的功能是反映变化。可以换一个角度来了解，从面向对象思想出发，一个维其实是一个class，而维成员是他的实例，object，在业务数据库的代码表中，主要记录的是当前形状，所以业务代码表记录的的是最近时辰一切维成员对象，对象ID就是码表主键。而对于数据仓库中的维表，他要表示历史信息，要记录的内容是历史上一切的维成员对象，而原有的业务主键一定不能作为对象ID，由于他不是独一的了，而用业务主键结合变卦时间作为主键大家都不会赞同吧。因此，代理键就出现了，它就是“历史上一切的维成员对象的对象ID。当然，kimball还又很多其他的理由运用代理键，这里也不

3、鼓吹了，毕竟有些益处我也没有对比过。但是就运用代理键，在目前工程中遇到的一些问题却是不得不说一下。首先，代理键的维护问题。代理键是一种自动添加的整型字段，如oracle的sequence，sql server的identy字段，对于那种慢速变化维SCD，这同样是球派提出的，请看kimball对slowly changing dimensions的描画。，要保证在数据仓库建立生命周期内，业务代码和代理键的对应关系是稳定的。例如有个工程，在实施过程中，一旦维表构造有稍许修正，就删掉一切维表数据重新初始化，而此时很能够打乱原有的对应关系。原来的A对应2，重新初始化以后就对应到3上去了。呵斥的后果可以

4、想象，原来相关的现实表数据需求重新装载，甚至假设有援用了这个值的报表SQL，存储过程都需求修正。所以在代理键的维护过程中，一定要保证对应关系的稳定性和每次维护前的备份。再者，代理键被客户接纳的程度。在onteldatastage讨论组中曾经讨论过着个问题。目前阶段，报表还是关键的运用，在报表SQL中援用代理键总不如援用业务键值那样顺，例如客户对于业务类型代码、城市代码都很熟习，普通看到代码就知道是那个业务或城市，而运用代理键值，让客户很迷糊。所以这不利于系统的推行。对此，暂时没有想到什么好的方法，只能暂时先在维表中放上业务代码字段。但是仍有个问题，代理键和业务代码不一定是一对一关系的，例如多个

5、数据源系统的不同代码映射到同一个代理键。这种情况，嘿嘿，只能看从哪个数据源出报表需求多了。08 : 59 再探数据形状 我们以前工程中经常想对度量进展分类，由于有些度量在计算汇总时要区别对待。为了区分，我们分成时点值和时期值，对于时点值，是不可累加的，例如在网用户数、历史欠费总金额、帐户余额等。这些度量反响的时特定时间点的一个形状值，不能在时间上累加，所以我们描画这个目的的时候，普通也都需求带上一个时间点定语，例如截至4月1日的在网用户数、到9月30日的历史欠费金额等。而对时期值，反响的是某个时间周期类的发生的值，例如通话费用、通话时长、新增用户数等度量，都可以在时间上累加。表述这些度量普通带

6、上一个时间区间的定语，例如8月份的通话费用、9月新增用户数等等。普通OLAP工具对这两种度量都是支持的，例如Cognos在度量选项中可以指定是求和还是求期末值或是期初值，可以求和的就是时期值，对于求期末、期初的度量，普通是时点值要运用此特性，必需明确指明一个时间维，可见这两种值和时间是严密联络的。昨天写的数据仓库中的数据形状中，提到ODS有两种形状数据，一种是事件型，一种为快照型。快照型数据记录当前时间点的形状值，事件型数据记录特定事件发生。这两种不同形状对于抽取增量有很大协助 。但是其他的分类方法，这是kimball在他的文章中提出来的，请看Fundamental Grain。此文中提出三种

7、现实表的数据形状分类，我觉得比我的分类更合理一些。由于事件型和快照型这两种分类主要是从增量抽取角度思索的，例如原来思索月帐单这种表应该属于哪一类时，有点模糊，便将至归结于事件型数据中，以为每个用户开帐是一种事件，不免有些牵强。因此，重新思索数据形状在时间上的分类，可以分成三种。事件型(Transaction Grain)、周期快照型(Piriodic Snapshot Grain)和累积快照型(Accumulating Snapshot Grain)。其中，事件型和我提到的事件型是差不多的意思，它记录的每一次事件的发生，包括发生的环境维度和发生的值度量，例如通话详单表，日志表等。而我的快照型表

8、还需求细分成周期快照和累积快照，而原来我将周期快照归于事件型。由于周期快照反响的是一段时间周期内发生值，例如月底出帐，月帐单记录每个用户的消费金额，就是上月通话费用的汇总。由于这种数据带有明显的周期性，例如每月，假设将它和事件型数据混为一谈有些说不过去。但是从运用周期快照型数据来说，他的特点和事件型数据有非常类似，例如都记录的是发生值，再如它们提交后普通都不会再做update操作。而累积快照型和我的快照型相对应，它记录是一个时间点上实体的形状，这种数据从实体的生命周期一开场不断更新到生命终了，例如用户表中，从用户创建开场，用户开机、停机、形状改动都会直接更新这些数据，最后，用户销户了，更新他的有效标志，从此这条记录根本不会再修正了。再结合一开场提到的时点值、时期值，前者记录某一时辰形状，普通都在累积快照型表中，当然也有能够在周期快照型表中，表示是期末那一刻的形状值，例如充值余额可以记录在用户表中同时也能够会在月帐单表中出现。而时点值普通在事件型数据中是不会出现的。时期值普通存在于事