探索分析问题的方法之 去芜存菁

  作者:姜玲
2007/3/28 16:33:29
本文关键字: ttnn 2005年11期

分析是一个分类细化的过程。这是昨天提到的观点,继续对以往的分析行为总结,发现它还有别的一些特征。

并且,上次有些概念表述不清晰,将角度、类别、因素都混为一谈。其实角度和因素是更加相似概念,例如说"过程移植的工作量由所依赖表的结构变化因素和语法元素因素影响的",也可以表述为"从依赖表的结构变化角度和语法元素角度判断移植的工作量"。
 
而所谓类别,是指每个观察角度和因素包含的内容,它们的确定,这才是分类。
 
继续拿存储过程移植的例子来说。例如工作量,分成"巨大、中等、少量"三类,表结构变化包括"不变、字段名称变化、表名变化、字段代码变化、数据含义变化"等。当然,如果要便于分析,那些一对多的因素,可以摊开成若干角度。例如上面的表结构变化因素,显然一个表可能会字段名称变化,也可能是表名变化等多种情况。因此,转变为"是否不变、是否字段名称变化、是否…"等,然后基于这些因素,合成一个表结构变化属性,这个属性包含了"大变、小变、微变"三类。
 
可以看到,分析时采用"后组式"分类方法区分类别的好处。这个词是从yushan那里学来的,是指那种类似label、tag的分类方法。当你发现被分析事物有某种特征,想区别出来,就可以给它打个标签。例如上面分析表的变动,发现表中如果有某个特定字段,将可能引起大的移植工作量,就可以新加入一个因素"是否有xx字段"。
 
分析的目的在于针对问题作出决策。在移植的例子中,最后要用分析结果去安排计划、分配资源。
 
然而,虽然分析者发现了分析主体之间很多的不同之处,也发现若干相同之处,前者用新标签(类别)予之区别,具有相同之处的,合入同一类别之下。这些发现并非总是目的明确,例如发现两个过程的名称结构有些区别,有的叫做proc_xxx,有的叫做xxx_proc,是否这会给移植带来影响?没关系,在这个问题没有得到解答之前,尽可使用一个"名称风格"来作个标识。
 
如此,最后可能会考虑了很多因素,从很多角度去看待这个分析主体。然而并非所有的因素是对目标(如工作量、优先级)有重要影响的,太多的因素也只能是让人目不暇接,如云坠雾。
 
因此,在得出很多类别之后,将有一步重要的工作是"去芜存菁"。这个步骤是从若干待选因素中挑选出对目标问题影响最大的因素,考虑因素之间的关联,考虑优先等级。
 
结合数据挖掘的常用算法,可以发现其中主成分分析、关联规则。这才发现,其实挖掘的算法,很多都是代替人脑去作复杂的,基于大数据量的判断,而分析的思路都是相通的。在一般的分析活动中,常常可以借助分析者的经验,这些经验就像挖掘依赖的数据一样,帮他一步步走进目标。
 
我在想,是否可以将这种分析思路形成一种固定的套路呢?以前曾经浏览过Martin Folwer的《分析模式》,可惜没有细看下去。但从名称上看,似乎作者正有此打算。
 
结合身边的情况,假设对一个新手,缺乏有效工作方法,教他如何在工作中分析问题。却发现,问题不光光是在方法上,而且还是在那些因素的提取上。在一个新手看来,待分析的主体几乎完全不一样,看不到什么相同的部分,无法区分他们,因为每个主体就是单独的类别。
 
针对这种情况,还得有针对特定问题域的分析体系。例如在分析企业业务模型的时候,可以从参与方、产品、资源、事件等主体着手,一级级分类,将参与方分成客户、供应商、合作伙伴、员工等等。在分析一个OLTP系统作为数据仓库数据源的时候,可以从数据源表、关系等主体着手,将表分为代码表、数据表,按数据形态分成累积快照表、周期快照以及事件型等。这样类似"分析模板"的东西应该更加具体些吧。

 

责编:姜玲
vsharing微信扫一扫实时了解行业动态
portalart微信扫一扫分享本文给好友

著作权声明:kaiyun体育官方人口 文章著作权分属kaiyun体育官方人口 、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。
畅享
首页
返回
顶部
×
    信息化规划
    IT总包
    供应商选型
    IT监理
    开发维护外包
    评估维权
客服电话
400-698-9918
Baidu
map