indicate的挖掘对数据仓库项目的重要性

innovate
20060301

我今天看到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，你可以深入挖掘维表中对该行业有价值的指标，更可以不用分析客户数据中潜在的指标，而是等待客户给你答案。至于经验和教训，就不用多说了，那现在还需要优秀的设计作项目前提么？

刘庆
20060301

什么叫做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字段理解为实体型事实表中的度量字段，不知这样理解是否正确？

Innovate
20060301

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

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

刘庆
20060301

哦，是我将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集合，然后和全用户表进行关联到数据集市中，如此，则灵活一些，可以动态地增加用户分类。当然，缺点也是显而易见，因为增加了一个关联操作，性能上有些影响。

Innovate
20060302

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

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

变幻莫测

刘庆

20060302

吃饭的时候，对面两个哥们儿在抱怨。"又要修改？需求变了多少次了？"

不是第一次听到这样的抱怨，我也抱怨。不过今天听到以后，第一个反应不是同情，也不是想应该建立需求变更的流程，竟然是幸灾乐祸。"嘿嘿，谁叫你们需求分析没做好来着。"

需求变更的原因当然又很多，作为集成商这边，一般都是埋怨客户没脑子，想一出是一出。后来算是认了，客户得罪不起，他们想怎样就怎样吧，但要留下痕迹，有变更书，到时候好跟他们谈判，看，没有功劳也有苦劳啊。要不就力争将需求规格定义地尽量清楚，不许抵赖。可这都无法阻挡需求变更，企业要将运营放在第一位，IT的支撑只能迎合它，不可能因为纸面文字的约束而削足适履。

好像根本问题是在源头，IT建设的初期就并不明白要解决什么，企业真正的需求是什么。缺乏合适的需求分析人员，只能用某些人来代替了，例如架构师，甚至是程序员。自己就曾经作需求分析，未来还要作。可惭愧的很，将客户心中所想的东西分析出来、表达出来很困难。在时间限制下，通常的结果只能是选择一个模板，照葫芦画瓢地形成一份需求文档，上面列出种种功能、种种分析，却未必是真实的。客户看完，觉得是一份文档，内容大多也不会细看，主要的考虑在于是否准备在上面签字。

如此的需求分析，真是有些让人灰心啊。昨晚，朋友打了一通电话，和人谈联通经营分析的建设，听起来他们公司对这块业务要求严了。成本、盈利、需求、阶段都得有规矩，这可让他犯愁。挂了电话，感叹，"联通经营分析怎么才能做的好呢？"。赶紧安慰他，"能作好的，慢慢来"，可怎么慢慢来呢？如果从项目不能盈利，一段时间后，要不公司歇菜，要不部门取消，或是退出这个业务。

Liu annie

已经不作数据仓库好久了。不过既然提到了需求分析，我在这个方面多少有些见解，就多说两句了。

数据仓库项目因为需求分析做得不好，需求变更的事情我实在见的多，也曾经干过力挽狂澜的事情，把一个近乎失败的项目成功完成，靠的，也只是我的需求分析能力，也就比别人多懂了那么一点点的业务知识。

先说，需求分析为什么变更频繁，那自然是在需求分析阶段，需求分析人员没有完整准确地整理出客户对系统的真实需求。如果一个数据仓库项目简单地说，客户说怎么实现，需要怎么去实现，我们帮他们去实现好了，需求分析人员只是简单记录下客户的要求，那就请准备好，客户说怎么修改，就怎么修改吧。这种情况下，客户水平决定了项目水平，实施人员只能被人牵着鼻子走，客户反过来觉得，你们怎么这么差，我虽然说一，但是我的意思其实包含了二，你们自己不理解，还怪我变更频繁，我如何相信你们做出来的东西！

相反，如果需求分析人员非常了解相关的业务知识，跟客户调研需求的时候，既能全面理解客户的意图，又能对其中所包含的问题非常清楚，那么需求分析阶段，其实是良性引导客户需求的阶段，需求分析结束，整个项目的边界、实现功能等方面，都非常清楚，客户既不会期望过高，又不会频繁变更需求，后续的设计、开发就不会这么被动了。
  
说句大白话，不是被客户牵着鼻子走，就是牵着客户的鼻子走，之后后者，才是成功之道。可惜啊，我现在是甲方了，作此类项目，想牵着我的鼻子走，各位再继续努力了啊。

Dumpedjoe

Business analyst的位置在国内一般都是由architect或者PM担任，PM大多也是技术优而PM，由于看问题的角度较多是从技术出发，而且业务领域的知识很少能达到(超过?)客户水平，所以大都是像刘庆所说，找几个业务人员聊聊，填填需求规格说明书模版，争取让客户签字确认就是成功，后续能够对需求变更进行记录和跟踪就算是不错的了。

造成这样的状况是一般都是由两方面决定的，第一是实施人员缺乏成熟方法论的指导和必须的技能，成熟的咨询公司都有经过无数项目验证的方法论的指引（例如ERP实施SAP有GLOBALASAP和VALUESAP，ORACLE有AIM，这些都不是概念炒作而是实际的过程指导）并且有专职的、在某些行业有丰富业务知识的business analyst，相信实施过相关项目的人有深切的体会（ERP实施成功的没几个？往下看），而DW实施同样如此，尤其对于面向高管人员提供决策支持的BI系统，不是像Annie Liu所说的那样要么牵客户的鼻子，要么被牵，指望公司的business analyst都能达到一个行业浸淫数十年的CXO的高度是不现实的，重点是记录并理解CXO的想法，将客户的思考和意愿转化为商业问题，然后通过和architect、PM的沟通，在TQC的三角中做出恰当的选择，能做的肯定不推，不行的坚决不搞。在这个基础上，需求变更是正常的，那是咱们挣钱的机会啊，客户不给？往下看。

其次不成熟的客户也是造成该现象的一个因素，不成熟体现在以下几个方面：一是我有想法，但是没空聊，找小弟聊吧，二是我没想法，我不聊，以后想起来再说，三是我有想法，聊聊吧，都得听我的，乙方都是孙子，咱是爷啊，项目成本会超？你还做不做了？！应对的方法就是在商言商，清晰界定责任和义务，出了问题是谁的责任？！别看广告，看文件啊！公司没实力就算了，能中标就不错了，加强一下“沟通管理”吧，狂勾兑，否则就只能惹不起躲得起，等天亮吧。

刘庆
20060303

看来作需求也得找个大款傍一傍啊，昨天看到一个大款项目的组织结构，列出一些人的角色，有个女的，名头为"项目管理员"。但后面的职责描述却令我羡慕不已，说到"主要工作为提醒项目经理一些重要的约见，包括其与项目资金负责人和核心团体的会见，另外还包括为项目经理安排每阶段一次的为期一周的休假。"
 
啊，牛，我也想要一个。
 
这气势，到客户那里肯定能够震的住。带着小蜜王小姐，找客户的老大，说，"今天我们来谈一谈BI的需求，小王，给我泡杯茶，给刘总对个火。"如此，刘总还不得亲自接待啊，岂敢怠慢。
 
人多势众，这话不加，要是以为人家牌子响就可以省着点人力成本，那人家就不叫大款那。小集成商，身份卑微，作个项目七凑八凑，四五个人七八条枪，上阵啥事都得干，需求你作、设计你作、代码测试还是你作，连现场的卫生都要你作。如此，都显得捉襟见肘，要是多个项目一起来，还得允一两个到其他项目里面去。那些大款可就不同，一路气势下来，从开始技术交流，就十几个"专家"扑上去，轮番轰炸。"这是我们叉叉专家，来为您介绍叉叉知识。"等开始作项目了，也不落气势，住的是当地最好的酒店，二流的不住。还是十几二十人，当然一半是领导，大部分时间在开会讨论项目怎么干。
 
看到现场热热闹闹的气氛，会议室里唇枪舌战的斗争，客户领导不仅捋捋山羊胡子，曰："项目啊，就得这么干。"
 
人大多如此，你要是牛气，人家就笑脸相迎，你要是客气，你家就不鸟你。这也怪不得很多人要摆谱罗，其实他们也不一定喜欢摆，但要是不摆，又让人看不起，做人真难啊。
 
你要是背靠个大款，例如十八摸那样的，出去谈事情也硬气。记得有一次，一位十八摸兄弟写了一封信给客户项目经理，谈项目应该如何如何建设。颇有道理，但结果是此为项目经理将此文拿出来与大众共享，并像小学老师展示先进作文一样，将其中精彩句子拿出来解构，几奉为项目纲领。我倒，寻思着，要是小弟弟写的，再有道理也是放屁之言。
 
一个愿打，一个愿捱，这是正常。也有原来在客户面前总是软不拉及，傍了大款以后，硬起来不鸟客户的。比如朗新傍了二目刀客寺以后，以往不签合同就进场干项目的面目变了，摇身，"不签合同？不合我们规矩，不干！"。看，这样的事情，国内一般的集成商哪里敢呢。不过这可是好事，也算为行业风气作出贡献。

BI4Fun

如果需求不变化,那就不是需求。正因为跟需求分析人员的接触，与你的交流，用户不断地将自己的思维内容和想法展现给需求分析人员，而往往这个时候需求定义的时间已经过去了大半，所以项目进度啊，系统设计啊都受到影响，何况有些就直接影响项目的整个开发难度和周期，所以一个好的需求不是需求分析人员完全可以控制好的，需要PM,SM的配合。

BI系统的建设就是一个不断建设的过程，是个递进式的，更何况中国用户的信息化建设脚步大，业务不规整。，如果期望几个月搞完诸如联通这样的分析主题，基本是不太可能。

Dumpedjoe

看这样子不但要傍大款，还得是“市面”最流行的，现在NB客户太多，18摸等天天走马灯式的拜访，花哨PPT见过无数，新名词听得耳朵出茧，18摸，M$？，不行（也许应该说no way），现在流行boston，google，bearingpoint？考虑考虑约个时间，McKinsey我们可以见见，难道是个说鸟语的公司我们都见，岂不累死大爷。

于是乎弟兄们眼热心跳，心潮澎湃，看某牛拒绝需求斩钉截铁，看某牛的专家一来气势如虹，看以前差不多的兄弟一朝升天，昨天还在点头哈腰今日便NB哄哄，于是生出许多幽怨，可怜咱们不光委屈，偶尔还要被客户问候，于是卧薪尝胆混成甲方，于是自我挖潜进入鸟公司，说鸟语、变鸟人，于是澳洲、英国MBA的简历漫天飞舞，再不济拼拼小身体混完两年回家休息，不是现在客户太坏就是市场被人做坏，爱尔兰、印度、以色列这帮穷酸就是给欧美打工，follow什么CMM5，方法论都是扯淡，他们搞的能叫东西？牛人都该致力于技术，联想研究院？拜托换人，哥哥我虽说现在不行，但有理想追求，现在流行的是开复李，要不咱就open source，嘴里念念RMS就是他的传人，gnome的管理方法论？兄弟你不是玩真的吧？中国IT逐渐的“成熟”，我们随之也茁壮的成长，好一派热闹繁荣的景象。

数据仓库总体架构

丁西宁
20060304

Conformed dimension 和 conformed facts 都是Kimball建立数据仓库总线架构中的概念，数据仓库总线架构的核心元素是data marts and dimensional models。

建立数据仓库总线架构的原因有几个：
 企业数据仓库的建设是从建立一个企业级的数据仓库开始还是根据各个部门的需求，建立解决部分业务问题的数据集市？

 如果企业已经存在了不同的数据集市，在这些数据集市之间，即使对于同一个业务也可能存在不同的维度定义，不同的指标含义，不同粒度的度量。如何屏蔽这些不统一的因素，充分的利用这些已经有的资源？

 对于不同的数据集市，如何在报表中对进行drill-through？即使两个集市的指标粒度是不同的？例如：货物在运输过程中的计量单位是吨，而在零售店里面的计量单位是听。
 对于不同的数据集市来说，有的可能是OLAP方式，有的可能是ROLAP方式，那又如何能在它们之间进行drill-through 或者 drill-cross 呢？

 客户的需求不停的变化，新的维度、新的事实表如何加入到已有的数据仓库系统中？
Kimball提出的数据仓库总线架构就是为了解决这些问题。

Conformed dimension的作用就像电脑的总线接口一样，是一个标准，所有以总线接口为标准的外设都可以直接在电脑中使用。用在数据仓库上，所有根据Conformed dimension设计的数据集市，即使使用技术不同，指标的粒度不同，都可以通过Conformed dimension来统一进行解释。不同数据集市之间通过Conformed dimension来进行交互。至于Conformed facts，我的理解是不同事实表的一个统一的视图。Innovate511说可以用它来进行汇总，来解决不同的业务需求。可能的话，还请Innovate511再讲讲吧。（单独讲也行，也许大家都明白了）

Innovate
太具体的方法可能不便讲，不过可以提高到理论角度说一下。

看过Kimball的life cyle的都知道，Kimball的data model设计思想的中心还是Bus Architecture Matrix。不知道大家看到书上的矩阵图有何感想？其实这就是data model方面的架构思想，作为建模者，就应该通过这种矩阵图，把握建模的全局。上面也说了，那是个样板图，如果业务比较复杂的话，不能一个矩阵图就包含了所有信息，那样就不容易分析，但是可以一个业务层一个图。像楼主所说，增加维表、增加事实表这种情况，非常常见的，但是如何和我们的系统融合，那就请放到矩阵图里，先理清楚逻辑关系，再详细设计。

至于统一标准的问题，不是每个情况，你都需要统一标准，而且有的情况客户需要的就是要不同的标准。这个时候需要一个参考维表，比如一个国际大公司收入各种货币都有，但是你把所有都转换为美金不现实的，因为地方分公司要看当地的货币更直观，而同样的业务指标，老总要看的是美金，而货币换算每天都在更新，所以得有个维表来存储这些信息。

最后说一个问题，建立怎样的数据仓库。我DW是个工程，没有定势，Inmon的也好，Kimball的也好，只是些理论的指导，具体的项目唯一的目的就是帮助客户更好地实现BI，所以我觉得没有必要争论哪个更好。不是我是中间派，而是项目实际上需要你灵活设计。就业务层来说，对于你解决了各个部门的独立的需求的情况下，老总的业务汇总如何设计？就数据层面来说，如何平衡各个部门对于业务不同的认识、每个部门对应数据量和业务复杂程度不同，是否需要分开设计数据逻辑架构？这些都要考虑到。所以我之前提出了，移动公司争论的业务驱动还是数据驱动都是片面的，应该同时驱动，整体架构Matrix（业务和数据），建模用Kimball的Matrix，数据流请也Matrix（不同业务层分开流，最后汇总，维表在不同数据层并不是一成不变的）。呵呵，不是我自己乱创造、模仿概念，而实际国外成功的复杂的项目，就是一个矩阵架构，只是我们自己设计的时候，不要把自己给绕进取了就好。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友