系统分析师论文范文-论新技术的引进

【#第一文档网# 导语】以下是®第一文档网的小编为您整理的《系统分析师论文范文-论新技术的引进》，欢迎阅读！

论新技术的引进

【摘要】

本文讨论了XX经营分析系统1.5项目的OLAP技术引进过程。该项目是在2010年1月启动的，主要是基于原有1.0版本进行开发而成，在2011年5月验收通过。该项目分为多个层次，在数据源层扩充了5个数据源，在数据仓库层中增加了100多个主题，在前端展现层增加了300多个CUBE，并展现了多个OLAP的分析主题。在本文中首先讨论了开发XX经营分析系统的背景和需求，接着论述了OLAP技术方法的引进目的，并且对引进的过程做了详细的描述，随后概要的介绍了与原有系统集成的过程，最后指出了该系统在开发工作中没有与元数据系统结合等不足之处，并提出了改进的方法。在本项目的开发过程中，我担任了前端展现的系统分析和设计工作。 【正文】

根据XX经营分析系统1.5规范的需求，我所在的BI研发部门组织了XX经营分析系统1.5的项目开发工作。该项目是在2008年1月启动，到2009年5月通过了用户的验收。该项目是基于原有的经营系统1.0开发而成的。该系统在原有的BOSS和计费的数据源的基础上再增加了DSMP，数据业务，集团业务，财务系统，CRM系统等5个数据源。按照数据源的不同在数据仓库层中分别组织了100多个业务主题的开发，其中包括的内容基本上有数据业务，集团业务，个人业务等等。在前端展现上，由于数据来源比较多，导致了需要2000多张报表页面的开发，通过引入了OLAP分析技术，我们通过开发CUBE，最终给用户展现了300多个OLAP型的主题报表，大大的减少了我们的开发工作量，并且增加了客户较为满意OLAP功能。在经营分析1.5项目的开发过程中，我担任了前端模块的系统分析和设计的工作，以下是我在该系统中的实践过程。 在经营分析1.5项目的系统中，我们做了大量的工作，其中包括了系统的需求分析，原有系统的分析，并且对OLAP工具的选取进行了大量的原型的试验性工作，在归纳和总结了需求报表的特性后，根据OLAP新技术的特点，把该技术引入的项目开发的过程中，并作为一种底层的技术集成到原有的经分1.0系统中，形成最终经营分析系统1.5的重要基础模块。 在需求分析和原有系统的分析过程中，我们归纳了三点： 1. 在行业的大背景下，行业需要有一个试验的地方实现XX经营分析系统的1.5规范，该规范包括了OLAP分析以及元数据管理系统的建立。 2. 在开发人员的需求下，由于


通过之前的需求收集以及数据仓库主题建立的资料，我们知道需要开发2000多张报表，需要在原有系统的基础上进行开发是可以花费半年的时间完成，但是不利于以后的扩展以及系统的维护，并且会造成服务器性能的下降，影响原有的系统，并且通过调查发现，在2000多张报表中，大致上每5张报表都是来源与同样一个表模型，并且在报表的查询字段上，基本上都必须要有时间和地市的维。 3. 在客户方面的需求，客户希望通过该系统不仅仅是获取数据的能力，并且希望通过该系统得到数据的分析能力，希望能过自己手动对数据进行旋转分析，从而摆脱导出到EXCEL再进行分析的痛苦过程。同时具有高级分析能力的客户能够通过汇总数据查询到更加细节的数据，对数据的钻取功能非常感兴趣。 在以上的需求分析过程中，我们参考了行业内一些工具的功能，根据自身的环境要求，我们选择的开源的Modra来作为引进OLAP技术的开发工具。在OLAP技术引进的时候，我们还对水晶报表+SQLServer，BO+数据库，BRIO+ESSBASE的组合方式进行了对比以及原型的测试。由于水晶报表+SQLServer在数据库选择上不符合数据仓库的要求，而且基本上该工具只能制作报表，与现有系统集成比较困难，在开发2000张报表的一开始，我们有曾经引入的想法，但是后来由于不能满足客户的需求，所以把该原型抛弃了。对于BO+DB2数据仓库的选择，由于对于BO的技术了解的人员不多，并且BO对数据分析的能力比较弱，在没有经过多少试验的基础上就把该组合给放弃了。在BRIO+ESSBASE的原型开发过程中，基本上能够符合用户的需求，而且开发报表也能够适应用户的需求，但是由于ESSBASE是MLOAP结构，对于大数据量的加载和计算的时间比较长，并且由于数据仓库中已经有了汇总的数据，对于这部分的数据再此建立CUBE会使得大量的空间浪费，最后在经济不允许的情况下，我们也放弃了该原型。最后，我们选择了开源的Morda工具来进行OLAP技术的开发，由于该工具基本上是基于XML，与原有系统有比较好的集成方法，并且开发组内多是JAVA高手，对于该工具的理解比较容易，所以最后选取了该工具进行OLAP技术引入的基础。 选取了具体的工具后，我们对原有的系统结构进行了分析，由于原有的系统是基于MVC的架构开发而成，后台的业务逻辑是使用IOC容器，并且该IOC容器是自身构建而成的。在这里为了能够集成Modra工具到原有的系统中，我们在后台业务逻辑方面对MDX查询语句进行了封装，形成IOC容易能够识别的Processor组件，然后容器通过该组件访问引入工具系统的Cube，并且形成正确的查询结果通过前端的控制器返回XML的Model到前端展现层中，由于数据量传送比较大，我们在前端的展现层开发了ActiveX控件，控制了数据的压缩和解压缩，并且对Model层的XML结果进行解析，形成能够展现的表格和图形。我们结合的XML和XSLT技术，在展现层实现了OLAP的基本功能，包括上卷，下钻，旋转，切片，切块等


基本的OLAP功能。 在整个开发的过程中，我们还注意了OLAP的上面的一些理论基础，并且对于建立Cube的方法进行了比较多的探讨，由于我们现有系统中已经有了数据仓库的支撑，对于Cube的建立还算比较简单，对于复杂的Cube的支持工作，作为以后升级开发时候的需求再次进行。同时我们还注意到了一些开发的风险意识，由于使用开源的工具作为引进，没有厂商的支持，如果不是有一班好的开发人员在这里进行钻研，估计该项目很可能会失败。 在整个项目开发完成后，我们得到了各方面的肯定，首先，我们得到了客户的肯定，在客户的理解和支持下，我们总算把该项目中用户需求的OLAP分析工具开发出来，并且引入到项目，并对需求的报表进行了大量的分析工作，最终把报表的数目减少到了400多张，形成了400多个Cube，大大的减少了开发人员的开发工作量，经过初步估算至少减少了60%的报表开发工作量，并且为以后增加的类似的报表提供了扩展性，增加了系统的灵活性和适应性。客户在OLAP技术引入到系统后，对数据分析能力大大的加强了，并且提出了很多在使用上的很多习惯的总结，得到了用户对我们的认可。但是系统还是有其不足之处，在性能上，虽然使用了压缩算法的传送数据，在进行大数据量分析的时候，有时候还是显得比较缓慢，现在我们基本上是通过Cube设计的算法改进的来该进这些缓慢的问题。从现在看来，我们的开发的经营分析系统1.5还有很多需要改进的地方，首先，我们忽视了经营分析1.5规范的另外一个系统——元数据系统。由于两套系统分别开发，所有我们对元数据系统了解不多，对于Cube的形成方面很多都是手工进行的，这些其实都是可以通过元数据系统，使用接口的形式传递到我们系统后，通过分析元数据中的关系，首先可以对中英文名称的模型对照减少了大量的工作，同时Cube的层次关系形成也可以通过元数据导入形成，通过与元数据系统的集成，可以更加简化了系统的开发。

本文来源：https://www.dy1993.cn/T8A.html