indicate的挖掘对数据仓库项目的重要性（原创）

[innovate511]

我今天看到itpub.net的帖子“浅谈数据仓库”http://www.itpub.net/496965.html
突然想起忘说一个主题：indicate

就我看到2003年普遍上的移动经营分析项目，要得到客户需要的查询、报表或者其他需求时，往往是用事实表一点一点地算出客户要得指标，然后sum,count后放进前端客户需要看的汇总聚合表。这样做的错误很多书上已经说了，至于为啥有问题，显然客户前端的需求是多变的，他们报表或者其他应用所要的指标是经常被使用的，如果每次都做一个这样的sum,count，系统的资源是被浪费的，而且维护量很大，每次指标调整，每一个汇总程序、相关汇总表们全部要改。

这就是今天突然想到要提一下indicate字段的原因。一般优秀的DW项目，处理客户需要的指标的时候，是在某个维表里加indicate字段，一些复杂的算法，只要有人知道其计算方法，就能加在一个维表一个对应的indicate，所以不要怕维表是动态维，也不要怕业务需要时增加一个新的复杂维表。试想你在DM那边改动那么大，而且每次重新计算是面向事实表的汇总，哪个效率高，哪个可靠性高，哪个扩展性强呢？

这就说到前面提到的conform
table了，如何解释conform，就是多个分表聚合到一个事实表，适应各种应用。到DM层后，对于报表和查询的应用需求，就可以通过conform
table和相应的维表关联形成一个summurry
table，这个时候的维表对应的解释信息都在这个表里，当然indicate的解释信息也在里面，客户要查询具体信息，那不是很爽了么，也许光这点就比花哨的OLAP还有用。当然作为分析，还是要靠报表和OLAP，以及DM，至于这么丰富的信息如何挖掘知识，那是后话，不在此讨论中。

如果诸位从这些分析里在项目实施中得到启发，请给我们回复。
再说一下设计，不仅仅是了解业务后，分了几块数据库，有ODS,有DW，有DM，再data
model，然后该怎样选用工具实施，而是从宏观架构设计到细致建模。业务了解清楚后，你可以选择最后汇总来计算各个指标，你也可以选择在仓库的前面的维表里去解决这些问题，你可以很粗鲁地直接将一大块事实表ETL放到DM，然后找数据库优化、code优化等去优化ETL，你可以深入挖掘维表中对该行业有价值的指标，更可以不用分析客户数据中潜在的指标，而是等待客户给你答案。至于经验和教训，就不用多说了，那现在还需要优秀的设计作项目前提么？

[刘庆]

什么叫做Indicate字段啊？我有个提议，对于此类从国外来的名词，是否能够对应一个中文名词。同样，什么叫Confirm table，最好也能够为之中文命名。不管咱们是否权威，但既然现在国内没有一个统一的叫法，就创造一个呗。

 

从Innovate的描述中，依稀对这个Indicate字段有些感觉。是否和KPI（Key Performance Indicator）中的Indicator是相似的意思呢？或者它就是一种度量，但文中又提到，这种字段是在维表里面，却又让我疑惑了。哦，也有可能是我们对"维表"的理解又不一样，例如一个"客户表"是事实表还是维表？似乎都可以啊。

 

一般来说，我还是愿意将"客户表"看作一个事实表，或者可以称之为"实体型事实表"。

 

举个例子，一个客户信息表：

(月份ID, 客户ID, 所属地区ID,客户类型ID, 客户级别ID, 通话费, 通话时长, 通话次数, 欠费金额, 投诉次数)
 

这种事实表和汇总型的事实表有一些区别。首先他们作为事实表，可以说都是又维度字段和度量字段组成。而实体型事实表之所以冠以"实体型"，是因为它的每条记录标识了一个实体(或者是某个周期的)，因此这个实体的ID（有可能需要加上周期ID）就是事实表的主键。上面的例子中，月份ID和客户ID就是该表的主键，而诸如所属地区、客户类型和客户级别维度字段都是依赖客户ID的。

 

而汇总型事实表有个特征，他们的维度字段相互之间（除去周期ID）并不完全存在依赖关系，可能有依赖，但必定存在不依赖，例如一个用户收入汇总表：

(月份ID，用户ID，所属地区ID，费用类型ID，收入，优惠)

 

此处，所属地区还是依赖用户ID，而费用类型跟用户ID、地区ID没有依赖关系，因此他的主键其实是月份ID、用户ID和费用类型ID。可以称之为汇总性的事实表。我的理解，应该就是innovate所称的summary table。

 

区分出这两种事实表，就将indicate字段理解为实体型事实表中的度量字段，不知这样理解是否正确？
 

On 3/1/06, innovate511 <innov...@gmail.com> wrote:

我今天看到itpub.net的帖子"浅谈数据仓库"http://www.itpub.net/496965.html
突然想起忘说一个主题：indicate

....

[innovate511]

传统的KPI大家都知道了，我这里强调的indicator是对一些业务上的解释性标示。在Kimball的life
cycle second edition里有一些例子，比如说vacation
indicator，就是通过日期date字段，判断某条记录是否是vacation，如果是，那该字段就是Y，不是，就是N。这些，就是我说的业务上的深度挖掘，供客户方便地查询和一些分析使用。

当然，现实中可能是更复杂的indicator，比如客户想要一种客户类型，这种客户必须是集团客户，必须是头衔为经理，而且信用度大于100的，大客户经理也许想对这些集团客户进行特殊照顾，于是想在系统中查寻。那么你可以有个大客户维表，至少含有以上信息，那么根据以上条件，开一个indicator字段，进行判断。之所以我说尽量在维表中定义，我觉得这样更符合中国国情，客户对一些特殊需求的定义往往可能改变的，不同部门的定义也不同，如果你放在事实表进行indicator字段的转换的话，那么对ETL性能是一个挑战。

[刘庆]

哦，是我将indicator字段理解错了。

 

举个例子就知道是怎么回事了。其实我们以前确实存在这种需求，例如在电信里面，假期，特别是黄金周的时候通话行为会有明显变化，于是在日期维中加入"黄金周假期描述"，包括春节、五一、十一。可以根据这个字段来过滤或是汇总来作分析，咱们再来深入说说。

 

在ROLAP中，这种indicator也称为"属性"（attribute）。

 

一个维度，有若干个级别（level），上下级别之间构成钻取体系（Hierarchy），而每个级别可以有一个级别ID标识，并拥有不同的描述属性（Attribute）。

 

例如在日期维中，其结构可以如下：

（日ID、日描述、节假日描述、月ID、月描述、年中月描述、季度ID、季度描述、年中季描述、年ID、年描述）
 

这个维有4个级别，日、月、季、年，可以构成几个钻取体系，例如日->月->年，或是日->月->季->年，而对于每个级别，可以有一到多个属性，日级别，就有两个属性，日描述如"2006年3月1日"，节假日描述为"非节假日"。季度级别也有两个属性，季度描述可以为"2006年第一季度"，年中季描述为"第一季度"。

 

可以看到，同一级别的属性的作用也是有所不同，在季度级别里的两个属性，仅仅是为了展现的时候，看到的描述信息不一样。例如要分析最近三年每季度收入同比，可以用季度描述，其中包含年份。如果是分析某年季度收入的环比，就可以省去年份，用年中季描述。这都是在分析展现上的事情。

 

而"是否节假日"这个属性，就不仅仅为了展现方便，而是要对他所属级别进行区分，是一种分类，通常会用它作为过滤条件。将它称为Indicator，其实挺符合的，有"指示"、"描述"、"类别"的含义。

 

对这类字段，曾经考虑过用另一种方法实现，但没有付诸实施，故此只在此纸上谈兵。

 

例如对于用户，在分析的时候通常要对某一群体进行分析，例如集团客户、离网用户、欠费用户、零次通话用户、使用xx业务的用户、发生若干次呼转的用户...。对于这些，一种方法就是在用户表中增加上面提到的描述性字段，"是否集团客户"、"是否欠费用户"等等。但显然，这样的"是否"会不断继续下去，也就意味着要不断增加字段。

 

而这些"是否"字段通常的用户就是过滤，例如将集团客户挑出来作分析，或将非零次通话用户拿出来分析。

 

因此，是否可以考虑现在web2.0流行的tag分类方法，就像gmail中的label呢？

 

设计一个"用户标志"表，主要包括两个字段，一是用户ID，二是用户标志。如果一个用户，他同时是欠费用户、零次通话用户，那么在这张表中就有两条记录。当分析主题需要对某个群体的用户分析时，可以用这个表的用户标志字段进行过滤，得到一个用户ID集合，然后和全用户表进行关联到数据集市中，如此，则灵活一些，可以动态地增加用户分类。当然，缺点也是显而易见，因为增加了一个关联操作，性能上有些影响。

 

不知道是否有如此设计的真实案例。

 

On 3/1/06, innovate511 <innov...@gmail.com> wrote:

传统的KPI大家都知道了，我这里强调的indicator是对一些业务上的解释性标示。在Kimball的life
cycle second edition里有一些例子，比如说vacation

.....之所以我说尽量在维表中定义，我觉得这样更符合中国国情，客户对一些特殊需求的定义往往可能改变的，不同部门的定义也不同，如果你放在事实表进行indicator字段的转换的话，那么对ETL性能是一个挑战。

[innovate511]

我觉得有的时候不能做重复工作，比如集团用户、欠费用户如果在生产系统已经有一个标志，或者说某个字段已经有描述了，那就不用专门做一个这样的标志了。但是如果生产系统没有，需要DW系统自己转换产生的，可以增加一个标志。

[innovate511]

对了，稍微补充一下，我的意思不是你有多个条件组合的就必须有个indicator,没有必要，组合的情况太多了，而且在前端需求也很容易实现，多一个where条件，并不会影响性能。什么情况才需要indicator字段呢？只有需要用程序转换的情况，才能体现其设计优势。就如vacation，或者上中下旬，这些日常定义，但是在生产系统没有的东西，都需要程序判断才能得出的东西，就需要用indicator字段来处理。