开题报告.docx
- 文档编号:5436213
- 上传时间:2022-12-16
- 格式:DOCX
- 页数:19
- 大小:296.96KB
开题报告.docx
《开题报告.docx》由会员分享,可在线阅读,更多相关《开题报告.docx(19页珍藏版)》请在冰豆网上搜索。
开题报告
哈尔滨工业大学软件学院
软件工程硕士学位论文开题报告
研究生
学号
入学时间2011年08月
实习单位
校内导师教授
实习单位导师高级工程师
论文题目基于商务智能的燃气企业运营采购数据分析系统
开题报告日期2013年3月
目录
1论文选题的目的和意义1
1.1课题来源,项目名称1
1.1.1课题来源1
1.1.2项目名称1
1.2与本课题有关的国内外研究状况1
1.2.1国外研究现状2
1.2.2国内应用现状4
1.3本课题研究的主要内容5
2研究方案6
2.1需求分析6
2.1.1功能性需求7
2.1.2非功能性需求10
2.2技术方案10
2.2.1技术路线10
2.2.2技术措施12
2.3方案实施所需的条件14
2.3.1技术条件14
2.3.2试验条件14
2.4存在的主要问题和技术关键15
2.4.1存在的主要问题15
2.4.2技术关键15
2.5预期达到的目标16
2.5.1功能性目标16
2.5.2非功能性目标16
3研究计划进度表和经费预算及经费落实17
3.1研究计划进度表17
3.2经费预算及经费落实17
主要参考文献18
校内外导师意见19
1论文选题的目的和意义
1.1课题来源,项目名称
1.1.1课题来源
天然气运营企业往往是资本密集型的企业,与运营相关的采购业务在公司起着重要的作用,也是ERP建设的重点部分。
对采购数据的分析使得用户能对采购价值链、供应商、资金流动、供应计划等有全面的认识,从而提高效率,增强业务管控,改进流程。
一般来说采购业务包括需求计划、采购计划、采购申请、采购寻源、供应商管理、合同订单管理、收发货、发票、支付等环节。
而当前公司的采购业务相关数据分散于不同的业务系统中,使得对数据的分析变得非常困难。
同时,在业务系统中的报表通常仅限于常用的固定格式报表,如果需要对这些报表进行修改,往往需要专业的IT工程师进行代码调整。
而用户对数据分析的需求往往是多变的,如果能快速响应这些需求,甚至能让用户快捷地制作自己的报表,进行数据分析,将大大地提高数据分析的速度和质量。
因此,本课程的重点在于通过结合关系数据库与多维数据库技术,将各业务系统中的数据进行抽取和整理后,设计成不同的分析模型,使得用户可以在这些分析模型的基础上进行自定义的数据分析和报表制作。
同时,将此数据分析系统的设计模式进行归纳总结后,可应用于企业的不同业务,例如财务、销售等,为公司管理提供更及时、准确的数据。
1.1.2项目名称
本项目的名称为《基于商务智能的燃气企业运营采购数据分析系统》。
项目主要是为了设计与实现一套应用于天然气运营企业的采购数据分析系统,使用户可以在分析模型的基础上创建自定义的报表和查询。
在实现功能性需求的同时,提高数据查询的速度,确保数据质量。
1.2与本课题有关的国内外研究状况
经调查研究,国内外对于商业智能和数据挖掘的研究由来已久,出现了各种分析模型和算法。
商业智能在发达国家和地区,已经成为企业信息化的主要项目之一。
例如ING安泰人寿,自1998年起,就开始逐步导入IBM的商业智能解决方案,对顾客分类、消费行为、成本和效率等方面进行信息分析。
可口可乐公司也以SAP的BI平台为基础,整合财务信息,提高财务规划的能力[]。
以下将分别针对项目中需要使用到的ETL技术、数据仓库技术、数据分析模型等几方面对国内外研究情况进行介绍。
1.2.1国外研究现状
(1)ETL技术研究
数据仓库的处理可追溯到计算机与信息系统发展的早期。
60年代初,计算的主要工作是运行于主文件上的某个单个应用。
大约在60年代中期,主文件和磁带的使用迅速上升,出现了大量冗余数据,到了70年代出现了磁盘存储器,使得在线事务处理可以快速进行。
到了80年代,大型事务处理系统开始使用后,出现了一种用于“抽取”的程序[]。
对于ETL工具,随着商业智能的广泛应用,很多厂商推出了ETL产品套件,当前国外的主要ETL商业工具包括微软的SSIS、Informatica公司的Informatica、IBM的DataStage等。
Informatica是一种企业级的数据集成平台,包括管理元数据、管理设计数据仓库及映像过程、管理提取-转换-加载作业等几个组成部分。
Informatica采用图形化的界面,类似于数据结构设计图表,可用于与多种源数据进行连接。
微软在SQLServer2005中将DTS工具扩大为整合服务,即SQLServerIntegrationServices,使之成为一个可以提供数据仓库的抽取、转换及加载(ETL)相关操作的平台,该平台还包括了建立和侦错封闭的图形及向导,提供数据适配器、容器和转换等工具,让整合的能力变得更强大[]。
SSISDesigner主要包含了控制流、数据流及控件等三种基本组件。
数据流又可能包含三种形式的组件,即来源、转换和目的地。
控制流程为整合流程的组件,在控制流中可以执行不同的工作。
控件主要是指控制流和数据流中可以使用到的应用组件。
SSIS由于其出色的性价比,成为许多中小企业商业智能分析工具的选择。
对于ETL建模的研究,主要集中在逻辑建模和概念建模以及转换和优化模型方面[]。
典型的概念建模过程就是将数据源一端的属性映射到数据仓库的表字段中。
逻辑建模过程指从数据源流向数据仓库的数据流。
SimitsisA.等人对从概念建模向逻辑建模如何进行转换进行了研究,提出半自动的转化方法,为ETL设计人员提供了一套用于逻辑设计的通用步骤[]。
对于ETL过程,在数据抽取、转换、清洗和装载四个过程中都有深入的研究。
在数据抽取过程中,面临的主要困难是异构数据源的抽取。
在数据清洗过程中,补充缺失的值、去除重复值以及提高清洗的自动化程度等都是人们研究的重点。
对于数据仓库而言,数据的正确性非常重要,因此ETL过程中对错误的处理、清洗和转换以及加载过程都要求ETL工具有错误恢复的能力,以及对日志的记录,这一领域也得到了研究者的关注。
综上所述,对ETL的研究集中在工具、建模、过程等几个方面,并且得到了研究者的广泛关注。
(2)数据仓库技术研究
数据仓库是结构化环境的核心,也是决策支持系统的基础。
数据仓库是一种面向主题的、非易失的、集成的、随时间变化的数据集合,用于支持管理人员的决策。
数据仓库中包含的企业数据通常是有很多的目的性,为了将来的需求做准备的[]。
在产品方面,主流的软件厂商Oracle、IBM、Sybase、CA、NCR、Informix、Microsoft、SAS等公司都有自己的数据仓库产品。
通常数据仓库有几个特点,包括面向主题的、管理大量信息、跨越数据库模式的多个版本、信息概括和聚集、多数据来源等。
在国外,数据仓库在零售行业有着广泛的应用,包括NCR联合太平洋铁路公司的数据仓库系统、比利时国家电信经纪人使用数据仓库建立的顾客信息系统,其中数据仓库拥有超过1万亿字节的数据。
此外,英国电信、福特汽车、通用等都在高端信息系统中应用到数据仓库技术。
(3)OLAP技术研究
在数据仓库中存储了大量的数据,需要有工具能让用户能查询和使用这些数据。
1993年,E.F.Codd提出了联机分析处理的概念,简而言之就是让用户能快速地从多角度对数据进行交互访问[]。
从OLAP技术的发展来看,可以分为ROLAP、MOLAP和HOLAP几种,区别关键在于数据存储在何处。
在ROLAP中,数据是存储在关系数据库中的,多维数据分析模型中只构建出数据关系,本项目中使用的SAPBusinessOjbect是属于ROLAP技术的一种。
MOLAP技术则将数据存储在多维数据库中,在速度上比ROLAP有优势。
HOLAP技术则是结合ROLAP与MOLAP的一种新技术。
OLAM是OLAP技术的一种新形式,简称为联机分析挖掘,是联机分析处理技术和数据挖掘技术的结合。
OLAM以多维数据分析模型为基础,结合OLAP,并具有计算回溯功能[]。
OLAP系统的架构可以分为C/S和B/S两种,其中C/S架构维护成本较高,而B/S架构将WEB技术与OLAP技术相结合,减少了维护工作量,并且更易于用户访问。
如图1-1所示为基于B/S的OLAP系统架构,分为存储层、应用层和表现层三个层次。
其中,对系统的易用性和性能来说,表现层和应用层最为关键。
应用层一般可以执行MDX语句,从存储层中读取数据,实现从关系数据库到多维分析模型的映射。
表现层为WEB浏览器,通过表格或图形等形式实现对应用层多维数据集的访问。
图1-1基于B/S架构的OLAP系统架构
(4)数据分析模型研究
数据仓库的OLAP工具都是基于多维数据模型的。
模型将数据看作是一个一个的数据立方体,从多维对数据建模和观察。
现在流行的模型包括星形模型、雪花形模型或事实星座形模型。
星形模型包括一个大的并且不含冗余的中心表(事实表),以及一组小的附属表(维表),维表围绕中心事实表显示在射线上。
雪花形模型是星形的变种,其中某些维表是规范化的,从而把数据进一步分解到维表中,类似于雪花的形状。
复杂的应用可能需要多个事实表共享维表,可以看作星形模型的汇集,即事实星座形模型[]。
1.2.2国内应用现状
根据对文献的统计,国内的商业智能应用可以分为两个阶段,从1996年至2001年为初始阶段,这一段时间多数是关于一些商业智能软件以及在国外的研究情况。
在2002年至2005年为增长阶段,研究文章大量增长,但是大多数还是对功能的介绍以及简讯等[]。
商业智能的研究是以数据的积累为基础的,因此与国内的信息化程度密切相关。
我们可以看出,随着国内的信息化建设的发展,商业智能得到越来越多的应用。
商业智能的典型应用行业包括银行、电信、保险、医疗、零售等。
总的来说,商业智能的应用在国内还处于起步阶段,多数还是应用于以上几个信息化程度较高的行业中,这与商业智能对数据积累的要求以及人们对商业智能的认知程度有关,而数据的积累以及数据仓库的建设都是一个长期的过程。
在采购相关的数据仓库和商业智能建设方面,出现了对采购决策支持原型系统的研究,分析了采购活动中决策者关心的维度和主题,将逻辑模型设计分为了三个方面,即粒度层次划分、数据分割策略制定和关系模式定义,采用时间属性和物料属性来分割数据,并提供了一个参考的采购关系模式定义[]。
数据仓库技术包括SAPBW等在电力行业供应链管理中也得到了应用,对指标库设计、模型设计、数据源分析、报表展现等方面进行了研究[]。
但是,商业智能在燃气行业对于运营相关采购数据分析的应用还有待研究和发展。
总的来看,商业智能的发展趋势是要结合行业、领域的知识,对应用领域进行扩张,加强可视化和交互性,在更广泛的行业进行应用。
1.3本课题研究的主要内容
本课题主要研究如何设计和实现基于商务智能的燃气企业运营采购数据分析系统。
针对系统的预期规划,主要研究内容如下:
(1)对源业务系统数据进行抽取、转换和加载;
(2)根据业务逻辑建立数据仓库;
(3)通过SAPBusinessObject(以下简称BO)建立数据分析模型。
通过对本课题以上内容的研究,设计并实现一套合同采办数据分析系统,实现系统的功能性和非功能性需求,最后通过测试,为用户提供一套稳定可靠的数据分析系统。
2研究方案
2.1需求分析
采购数据分析系统的主要目的在于为用户提供数据分析模型和基础分析报表,满足用户灵活多变的数据分析和报表需求。
为实现此需求,需要将各相关业务系统数据进行抽取,并建立数据仓库,然后通过BO工具建立数据分析模型。
合同采办业务从需求计划开始,经过采购申请、采购寻源、合同审批和签订、收发货、发票登记和匹配、支付等一系列过程。
用户经常会需要从一笔支付信息对应到采购申请、合同订单和相关的收货信息进行查看。
反之也会从采购申请开始查看与之对应的合同执行情况、收货和付款的情况等。
因此,需要针对不同的分析主题建立分析模型,并将各种分析模型进行关联,例如采购申请与合同订单进行关联,合同订单与发票和付款进行关联,合同订单与收货进行关联,从而将实际业务系统中没有直接关系的业务数据进行关联,贯通整个业务链条。
报表用户用例图如图2-1所示。
图2-1报表用户用例图
2.1.1功能性需求
系统的主要功能性需求为数据查询和分析。
根据对用户需求的调研,可以将其需求分成以下几种分析主题,分别按照分析目的、数据来源、维度和需求等进行介绍。
(1)采购申请情况分析
分析目的:
按照需求部门、采购人员或采购时间等不同角度统计采购申请的明细情况。
数据来源:
Maximo
分析维度:
时间:
年-月-日
状态:
申请单状态
采办人:
采购人员
需求部门:
提出采购申请的部门
采购申请类型:
紧急采办、普通采办
数据分析需求:
从以上维度对采购申请各项内容进行明细查询,包括采购申请编号、采购单描述、采购行描述、需求部门、申请人、采购类型、状态、状态日期、采购员、申请日期、需要日期、合同采办接收日期等。
从以上维度对采购申请进行总体情况分析,包括按照采购申请部门、采购人员、采购时间、采购单状态等不同角度统计采购申请单的完成情况、有问题情况、所占比率。
(2)合同订单情况分析
分析目的:
按照需求部门、采购人员或采购时间等不同角度统计合同订单的明细情况。
数据来源:
Maximo
分析维度:
时间:
年-月-日
状态:
合同订单状态
采办人:
采购人员
需求部门:
提出采购申请的部门
合同订单类型:
小额、重复、招标、询价等
币种:
RMB、USD、JPY
数据分析需求:
从以上维度对合同订单各项内容进行明细查询,包括合同性质、合同编号、合同名称、文件编号、合同类型、采办类型、签约方、负责人、币种、合同签订日期、合同描述、合同行描述、金额等。
从以上维度对合同订单各项进行总体分析,按照采购申请部门、采购负责人、采购时间等不同角度统计和分析采购合同的单价合同数、总价合同数、服务合同数、货物合同数、合同金额、交接合同数、未交接合同数等情况。
(3)交货付款分析
分析目的:
按照需求部门、合同状态或合同时间等不同角度交货和付款的情况。
数据来源:
Maximo、SAP、工作流审批系统
分析维度:
时间:
年-月-日
状态:
合同订单状态
采办人:
采购人员
需求部门:
提出采购申请的部门
合同订单类型:
小额、重复、招标、询价等
币种:
RMB、USD、JPY
数据分析需求:
从以上维度对合同订单各项内容进行查询分析,包括合同号、采办处理人、合同名称、金额、币种、签约方、合同签订日期、合同交货日期、合同交货地点、合同交货后的运输方式、仓库验收时间、接收状态、付款申请审批日期、发票登记支付日期等。
(4)流程情况分析
分析目的:
将各系统中与审批相关的数据进行收集整理,以便对审批时效进行统计分析。
包括各审批节点所花费的时间、各业务流程总体花费时间、各类型审批花费时间。
分析维度:
时间:
年-月-日
流程类型:
不同流程的名称,例如采购申请审批、供应商名单审批、评标报告审批、合同审批、付款申请审批等
采办人:
采购人员
发起人:
提交流程的人员
需求部门:
提出采购申请的部门
节点名称:
各审批节点名称
审批结果:
同意、不同意、退回
数据分析需求:
从以上维度对审批流程明细和汇总情况进行统计分析,包括名称、文件编号、发起人、开始时间、结束时间、审批时长等。
(5)资金预测分析
分析目的:
依据现有的资金情况预测后面可能需要交付的资金额。
分析维度:
时间:
年-月-日
供应商:
供应商名称
需求部门:
提出采购申请的部门
数据分析需求:
根据付款申请和发票登记数据预测后续时间需要支付给供应商的款项。
综合以上分析主题中的维度和量度可以分为以下几种。
(1)时间维度:
时间是最常用的分析维度,按层次分为年、季度、月、日。
在此维度上,需要实现按层次的上钻和下钻功能。
例如从日上钻到月,同时将量度值进行汇总。
同理,也可以从年下钻到季度,并将数据进行明细拆分。
(2)部门:
按不同的部门对数据进行统计分析。
(3)采办类型:
按不同的采办类型对采购申请和合同进行统计分析,例如招标、询价、小额采办、重复性采办等。
(4)供应商类型:
按不同的供应商类型对供应商数据进行统计分析。
(5)发票状态:
根据不同的发票状态对发票流转进行统计分析。
(6)状态:
包括采购申请的状态和合同订单的状态,例如正在审批、已取消、审批完成、正在处理等。
(7)流程类型:
审批流程的类型,包括采购申请审批、供应商名单审批、评标组织和方法审批、评标报告审批和合同审批等不同类型。
(8)项目类型:
各项目名称和编号。
(9)币种。
从量度来看,主要分为以下几种:
(1)对各类业务数量的统计。
包括各类供应商的数量、采购申请和合同订单的数据、发票的数量、各种单据在不同状态的数量等。
(2)对时间的统计。
包括各类业务审批以及在各种状态的时间统计。
综合以上量度和维度需求,用户可以在客户端报表工具中自己选择所需的分析维度和量度,从而制作自定义报表或进行查询。
从数据来源看,主要包括:
(1)从K2工作流系统抽取合同采办相关流程的审批信息。
(2)从Maximo合同采办系统抽取采购申请及审批信息,抽取供应商、合同、库存、收货、发票等信息。
(3)从SAP财务系统抽取支付信息。
(4)从预算管理系统抽取预算数据。
2.1.2非功能性需求
(1)性能要求
对于大数据量的系统,ETL的速度关系到整个系统的运行速度。
因此,完成一次ETL过程的时间要求控制在10分钟内。
同时,数据分析的速度主要取决于数据分析模型设计的优劣。
因此,需要对不同结构的数据分析模型进行分析,设计出最优的数据分析模型,使客户端报表查询的时间控制在5秒内。
(2)错误日志与跟踪
要求可以对ETL过程进行跟踪并记录错误日志。
(3)易用性
用户要求可以直接通过拖拽等方式生成自定义报表,因此对维度和量度值的命名要求具有可读性并贴近实际业务。
将数据库表中的生硬的字段名以友好的命名方式提供给用户使用。
2.2技术方案
2.2.1技术路线
整个系统计划使用SQLServerIntegrationService进行数据抽取,以SQLServer构建数据仓库,其中数据仓库使用三层结构,分为STG、ODS和DW三层,分别为源数据层、整理中间层、数据仓库层。
在数据仓库的基础上,使用SAPBusinessObjectUniverse建立分析模型。
在分析模型基础上通过SAPBOWebIntelligence设计制作前端报表。
系统的设计模型如图2-2所示,总体来说分为数据源抽取、数据仓库、分析模型、前端使用平台等几部分。
图2-2系统设计模型
ETL过程使用SQLServerIntegrationService实现,设计思路如图2-3所示。
过程分为三层,分别是源数据处理层(STG)、历史数据处理层(ODS)、数据仓库层(DW)。
源数据处理层负责将数据从源业务系统抽取到SQLServer数据库中。
历史数据处理层负责存储和处理历史数据,以及来自不同源业务系统的共性数据。
数据仓库层负责将历史数据层的数据根据维度和量度原则建立成不同的量度表和维度表。
图2-3ETL处理过程
对于数据分析模型的建立,将使用SAPBOUniverse来进行设计。
将DW层的维度表和量度表进行关联,建立成不同的分析模型。
基于以上思路,数据库表也分为三层,分别是STG层、ODS层和DW层,分别用于存储源数据、经过清理的数据和历史数据、组成成为维度表和量度表的数据。
综上所述,数据分析系统的整体功能模块如图2-4所示。
图2-4系统功能模块图
2.2.2技术措施
为了支持上述技术路线的实施,需要考虑如下技术措施进行实现。
2.2.2.1ETL部分的实现
ETL部分主要通过SSIS技术和存储过程技术来实现。
ETL是一个复杂的过程,ETL过程的开发往往可以占到整个数据仓库开发时间的80%。
ETL过程主要分为抽取、转换清洗和加载三个阶段,ETL过程和数据仓库之间的关系如图2-5所示[]。
图2-5ETL过程
(1)抽取过程
抽取过程面向多种异构的数据源,包括Oracle数据库、SQLServer数据库、SAP、IBMCognosTM1等。
这些源数据以数据库表、适配器、WebService、文件等方式提供源数据供抽取。
对应于这些异构的数据源,将分别使用SSIS中的SQLTask、BiztalkAdapter等技术来进行抽取。
抽取过程将把所需要使用到的源数据全部抽取到数据库的STG层表。
这一过程实现时要注意如何应对数据源的改变,使得数据源的改变不影响过程的执行,否则将导致取数过程失败。
为了达到此目的,取数使用SQLTask时,需要增加对字段名和字段长度的检查,并定义好失败时的处理措施。
(2)转换过程
转换过程主要包括对冲突数据的处理、对重复数据的处理、对历史数据的处理、对脏数据的处理。
在对冲突数据处理方面,主要是针对维度相关的数据,例如单位、时间、格式、命名等。
因此,需要定义规范,统一各类数据。
另外,在冲突处理过程中,需要对冲突数据加以区分,找出重复的原因。
例如,与合同相关的采购申请编号,在合同行上和合同主体上都有关联,但在对源系统进行调研后发现,这两种关联意义不同,虽然是重复的,但是都是后面的报表中可能要用到的,因此都是需要的。
经过冲突处理后的数据,加载到同一个关系表中时,可能会出现重复的记录,需要在对这些重复的数据进行标记,在建立数据分析模型时,根据需要进行选择。
因为源业务系统数据库多数都是存储实时数据,而对于数据分析系统来说,历史数据也需要保留,因此,在进行转换过程中,需要将有必要保存的历史数据进行存储。
在对脏数据的处理方面,在用户使用过程中,会发现有一部分源业务系统中数据不正确的记录,但是由于各种原因,无法修改源业务系统,而希望在数据分析系统中将这部分数据进行纠正。
(3)加载过程
加载过程主要负责将清过转换的源数据加载到维度表和量度表中。
量度表也称为事实表,主要用于存储用于分析的数据值,例如采购申请数据表、合同订单数据表、审批流程数据表等。
维度表主要用于存储分析维度值,例如部门表、时间表、状态表等。
加载过程主要通过存储过程实现。
2.2.2.2多维分析模型部分的实现
多维分析模型部分的实现借助于SAPBOUniverseDesigner工具。
在此工具中将DW层定义好的维度表和事实表进行关联。
建立模型时可以直接使用DW层的事实表和维表,也可以在其基础上进行处理后产生衍生表,作为建立分析模型的基础。
在数据分析模型这一层并不实际存储数据,所以从前端传来的请求都将经过数据模型后直接从DW层读取。
DW层、Universe对象和前端展现层的关系如图2-6所示。
图2-6多维分析模型与DW和前端展现的关系图
2.2.2.3非功能性需求部分的实现
对于性能要求,主要通过对ETL和数据分析模型的优化来实现。
ETL过程的优化关键在于对生成事实表的存储过程进行优化,而事实表的处理往往涉及多个源表,因此对查询设计的优化是关键问题。
对于日志和跟踪的要求,需要在存储过程中增加对运行过程的记录,并将日志记录在日志表中。
对于易用性需求,需要在Universe即分析模型的设计过程中,注意将DW层表中的字段名称对应到Universe中的实际业务名称,以便用户在使用时不用直接面对生疏的技术名称,而是通过熟悉的业务名称进行查询和报表制作。
2.3方案实施所需的条
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 开题 报告