BI通用流程

 

aspnetx

 

此图是根据个人经验总结出的一个BI通用流程,适用于报表方案,多维分析方案,但不适用于数据挖掘的方案。

BI项目关键资源:业务专家,BI开发人员,业务开发人员。

业务专家的参与有助于提高需求的准确性,BI开发人员主要负责BI过程相关资源的组织和管理,业务开发人员配合BI开发人员确认数据及业务的相关工作。

下面对这个开发流程做一个解释:

首先,从报表下手可以很容易的掌握用户所关注的东西,结合业务系统以及数据结构可以有助于对主题有个大体的印象,同事对一些用户比较关注的维度和度量才能有个概念。

但是理解业务是个需要经验和理解能力的过程,不同行业都会有不同的特点,所以这里需求人员和业务专家的参与就比较重要。另外同样也不可忽视掉包括项目相关的文档的重要性。

前四个步骤要求一定是有BI经验人参与的。这样看过报表以及系统后,对主题,度量维度等才能有个大体的规划。试想如果连主题,度量维度都不清楚为何物,那么此处根本无法进行,包括后续的维度建模。

闲话:相对国内的BI来说,报表是很容易获得的,因为大多数项目都是上BI之前,先把用户手头上的报表给解决了------即使你不想要用户也会塞给你,是啊,一大堆报表看上去挺头疼的,管它呢,还是看看能发觉出什么先吧。

模型验证,根据已建立的维度模型验证是否能满足所有的报表需求。同上,此步骤必须要有BI经验的人做。如果模型满足不了统计的要求则重新建模。这里是需要一个反复迭代的过程,每次迭代的结果都要沉淀下来并且形成文档。

反向确认数据仓库结构,手动或者系统自动均可,自动生成来说SQLServer从2005就已经支持了,不过为了命名规范,还是手动来生成数据仓库比较有必要。

分析数据来源及SSIS开发。最好是由相关模块的开发人员参与,因为开发人员是对数据结构比较了解的,并且有SQL功底,而且还掌握业务。这一步的目的是填充数据仓库。可能需要适当SSIS培训。不过,这一步公认是最耗时的。同时,不是所有的统计项就是能从业务那边解释的了的,比如某些统计概念,可能在业务系统从来就没出现过,但是通过基本数据组合都可以计算出来。所以类似概念,确认计算公式等就需要BI人员承担起需求的工作去确认。

同时,BI人员需要与业务开发人员协同制作开发数据增量的方案,以配合SSIS的开发。还有一种比较好的方法就是开发人员写SQL然后BI人员用BI的方法将其整合到方案中,总之方法很灵活,关键的就是跟开发人员的沟通。

SSAS开发,生成多维数据集,确认分区,增量等操作,建议这里一定要符合SSAS的规范,命名约定等,这样会给后续工作减少很多麻烦。

SSRS等其它开发。这一步需要参与的人员可以灵活来定,因为是需要一定的MDX经验,而且有可能需要对团队进行报表开发培训。需要指出的一点是,即使到目前的SQLServer版本,用Cube作为SSRS的数据源开发报表还不是很舒服,相关问题有时间会详细阐述,同时也希望有些问题能在下一个版本的SQLServer中解决。

数据验证,等同于测试的过程,观察统计出的数据是否有异常,比如通过单个SQL查询的方式对报表数据进行验证。如果出险问题,根据问题的实际情况再去确认是哪个环节出的问题。

最后生产环境的部署,没什么好说的了,注意管理好SSRS的报表资源就OK了,比如为了避免相互覆盖,我们可以要求报表开发人员不使用共享数据源等。

此方案还可扩展为SSAS支持的多维分析项目,相信之前通过对报表等的分析各大主题已经成型了,所以完全可以直接把Cube拿过来用。相信多维分析的方式会吸引住客户的眼球。前台分析工具很多,再次不一一做介绍。

至于是否可以继续在此基础上扩展数据挖掘的经验,aspnetx认为,这里会有资源可以继承,但是能否满足数据挖掘的需求不好说,所以还得根据具体需要解决的问题来出发。

此外,BI项目中四大“最”:

最关键的部分:维度建模,这里准确与否将决定整个项目的成败,这里也最需要经验。

最有难度的部分:主题确认。对于业务复杂的系统来说,这是一个需要时间的过程,而且需要反复迭代。

最累人的部分:SSIS开发。SQL脚本工作比较多,很累人,而且也需要耐心。

最需要的支持:客户最高领导,记住一定要是说话好使的,遇到问题能当机立断的,否则会死得很惨。

这个方案可能在不同人想法里不太一样,最常见的是认为应该先对报表进行分析,完后再针对报表内容直接分析数据来源,然后根据数据来源结果决定如何建模。个人不建议这样的方法,这样的分析工作会变得很繁琐而且重复劳动多,当然可以先对需要统计的东西汇总然后再一项一项的分析,但是你不认为按照维度建模的方式去分析是一个更好的汇总吗。

总之,仁者见仁,智者见智。还请各位高人提出更好的实施意见。

(此文章为转载)

 

你可能感兴趣的:(数据结构,数据挖掘)