烟草企业数据综合分析应用系统设计开发可行性研究报告Word文档格式.docx
《烟草企业数据综合分析应用系统设计开发可行性研究报告Word文档格式.docx》由会员分享,可在线阅读,更多相关《烟草企业数据综合分析应用系统设计开发可行性研究报告Word文档格式.docx(22页珍藏版)》请在冰豆网上搜索。
本项目在系统设计、软硬件采购、应用开发、系统集成和服务过程中应采用已有的国家标准、行业标准和主流国际标准,遵循但不仅限于下列标准体系和要求:
《烟草行业信息化标准体系》及其有关标准
《烟草行业信息化建设统一技术平台要求》
《烟草行业数字证书应用接口规范》
《烟草行业信息系统安全等级保护定级指南》
国家《SOA标准体系》
除了遵循上述标准,在整个项目设计开发过程中,需要遵守下面的5项原则。
1.技术的先进性
Ø
系统应采用先进成熟的技术,以保证投资的有效性和延续性。
支持常用的操作系统平台、常用的数据库系统、常用的应用服务器平台和常用的开发工具,与XX烟草现有系统互联互通,以保证系统的兼容性。
2.系统的稳定性
保证系统能够正常运作,系统应能够7×
24小时连续稳定工作。
软件版本升级或改进应在不影响业务的情况下进行,保证系统可以稳定、平滑过渡。
3.系统可维护性
系统应能使系统管理员集中方便地配置、监视、控制、诊断整个系统,并且能够监视和控制用户情况、提高效率、消除隐患。
对于系统各功能模块的配置、控制、监视、诊断等工作能够通过专用的系统管理工具方便的进行,无须进行专门的编码工作。
数据中心系统将按照集中的模式进行部署,因此对系统处理并发任务的能力提出了很高的要求,投标方需要提供大规模并发流量的处理机制以及发生性能问题时的解决方案;
并提供实时交易量(并发交易量及其硬件配置)和并发用户量(并发用户数及硬件配置)的相关测试报告和案例说明;
4.系统安全性
系统应保证信息的安全性,即保证此系统中的信息能够安全存储,并有良好的数据备份和快速恢复方案;
采用分级的安全体系,保证数据在处理和传输全过程的安全性。
系统支持对关键的信息(如:
用户密码)进行加密保存,同时支持对一些比较重要的业务数据在传送和存储过程中进行加密保护;
保证系统中的信息不被非授权用户访问,按组织结构划分操作人员的操作权限,使用烟草办公自动化系统的用户身份认证系统,且各种使用权限所能调用的应用软件模块可按要求灵活配置;
系统在身份认证方面支持多种的认证手段,如:
口令认证、数字证书认证等;
系统支持基于角色和基于资源的授权方式,支持用户到角色的映射,并采用角色的身份来控制对特定操作的访问权,支持层次化,结构化和区域化的角色设定;
系统需要有对系统数据的关键操作(如授权操作、流程环节变更)进行追踪和回溯的能力;
4.2、设计思路
1、模块化的系统结构
系统结构采用三层(3-tier)或多层(N-tier)设计模型;
设计模式为B/S模式。
由合理分划、边界清晰的子系统和模块组成,形成组装式、插件式的体系结构,以利于系统的升级、扩充和发展。
支持业务流程的可调整性;
支持业务信息的可调整性和延续性。
2、面向服务的整体架构(SOA)
系统模块都是向系统内部和外部提供服务的逻辑单元;
采用标准的协议提供服务。
采用松耦合的机制与外部系统进行信息交换和系统之间的互操作。
3、无缝集成的应用
提供与其他相关信息系统的数据接口、支持开放的XML标准接口规范。
不同的异构系统之间可以无缝地实现数据集成,也可以无缝地实现业务流程的集成。
4.3、总体架构
系统基于SOA设计理念,架构信息采集、整合、展现信息系统,为增值服务管理奠定总体架构基础,并以“服务”方式,扩展将来主题业务数据分析、服务系统。
五、系统实现
5.1、整合内容
数据来源主要为营销系统、专卖系统、物流系统、财务系统、0A系统以及其他业务系统。
5.2、采集处理方式
5.2.1、数据采集
5.2.1.1、功能设计
通过整合完善数据采集系统,更加高效的接收和处理来自各系统的数据,实现数据采集工作的灵活设置和快速部署,使数据采集工作更专业化和规范化,减轻数据提供单位的负担,提高数据采集效率和质量。
支持基于事件发生时接收数据消息、支持数据库改变时数据同步、支持定时提取数据、支持外部文件导入、支持异地全局数据库。
并且支持基于消息的数据传输,在前置机感知数据改变后,通过WebService机制项服务器传递消息;
支持通过各类数据传输中间件进行消息的传递。
数据采集方式包括:
自动采集、定时采集。
自动采集是指通过系统接口,自动实时从数据源采集数据,适用于实时性要求较高的数据信息。
定时采集是指在设定好的时间点对数据源数据进行采集,适用于数据源有规范的数据传输技术架构。
数据审核:
在数据加载到数据库前对采集的数据的格式及数据内容进行校验和审核,保证数据采集平台采集的数据质量。
自动采集:
支持自动采集和定时采集方式,实现采集系统自动获取数据源数据的功能。
数据加工处理:
包括数据信息清洗、信息转换、信息加载等功能,将从数据源获取过来的数据进行规范化处理,实现多源数据组合、冲突数据处理、数据格式检查等功能。
并将其转换成数据仓库需要的格式。
数据加载功能是将经过规范化处理后的数据存放到数据仓库中。
需要定义数据的加载频率和加载方式。
数据的加载频率根据数据的产生频率和数据仓库对数据的分析粒度决定,可以根据需要来定义加载的间隔。
采集平台系统功能结构如下图:
5.2.1.2、技术实现
1、技术架构
通过各种采集方式把现有各部门、企业的诸多系统通过数据交换平台抓取进入数据中心,并可以通过业务报表填报的功能补充信息,支持暴扣文档、多媒体、XML、文件以及数据库等多种方式的数据采集。
2、数据接口
本系统采集通过建立数据口的方式与现有的营销系统、专卖系统、物流系统、财务系统、0A系统以及其他业务系统进行数据采集,并将采集数据进行审核与加工处理。
与此同时考虑到与新系统的整合,系统将预留数据交互模块并建立数据交换机制,为新业务系统的接入提供准备。
5.2.2、数据整合
利用完善的ETL工具,通过节点控制库、信息共享与管理库把采集来的数据按照业务内在关联形成能够表述完整业务链信息的整合信息,并为下一步的数据应用打定基础。
5.2.2.1、技术架构
1、ETL工具介绍
ETL负责将分散的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成,最后加载到数据仓库或数据集市中,成为联机分析处理、数据挖掘的基础。
ETL是数据仓库中的非常重要的一环。
它是承前启后的必要的一步。
相对于关系数据库,数据仓库技术没有严格的数学理论基础,它更面向实际项目应用。
所以从项目应用的角度来考虑,按着物理数据模型的要求加载数据并对数据进行一些系列处理,处理过程与经验直接相关,同时这部分的工作直接关系数据仓库中数据的质量,从而影响到联机分析处理和数据挖掘的结果的质量。
ETL的质量问题具体表现为正确性、完整性、一致性、完备性、有效性、时效性和可获取性等几个特性。
而影响质量问题的原因有很多,由系统集成和历史数据造成的原因主要包括:
业务系统不同时期系统之间数据模型不一致;
业务系统不同时期业务过程有变化;
旧系统模块在运营、人事、财务、办公系统等相关信息的不一致;
遗留系统和新业务、管理系统数据集成不完备带来的不一致性。
实现ETL,首先要实现ETL转换的过程。
它可以集中地体现为以下几个方面:
空值处理:
可捕获字段空值,进行加载或替换为其他含义数据,并可根据字段空值实现分流加载到不同目标库。
规范化数据格式可实现字段格式约束定义,对于数据源中时间、数值、字符等数据,可自定义加载格式。
拆分数据:
依据业务需求对字段可进行分解。
验证数据正确性:
可利用Lookup及拆分功能进行数据验证。
数据替换:
对于因业务因素,可实现无效数据、缺失数据的替换。
Lookup查获丢失数据Lookup实现子查询,并返回用其他手段获取的缺失字段,保证字段完整性。
建立ETL过程的主外键约束对无依赖性的非法数据,可替换或导出到错误数据文件中,保证主键唯一记录的加载。
2、整体结构
系统将各个业务系统中采集到的销售、财务、物流、仓储等基本业务数据进行整合,形成节点前置库,并进行数据加载,形成结构化的综合信息共享库与管理数据库,最后通过加工处理形成数据集市,并通过综合分析、统计报表、智能分析、决策支持等方式展现给用户。
如下图所示:
5.2.2.2、数据资源整合
主要功能是实现将分散、异构的数据和记录进行规范化整理并实现聚合处理,生成基本数据集所规范的、全面动态的企业业务综合数据信息(宏观或个案级别综合业务视图)共享库,该综合共享库支持动态、交互、智能的综合业务管理,可发布(提供)综合集成的“全景业务信息”以支持全局性同步信息共享。
主要功能模块包括数据规范化整理(数据校验、语法学清洗、语义学清洗等)和数据聚合处理(数据解析、整合存储/主数据管理、展现预处理等)。
流程如下图:
1、数据校验清洗
数据质量问题分类:
根据处理的是单数据源还是多数据源以及问题出在模式层还是实例层我们将数据质量问题分为4类:
单数据源模式层问题、单数据源实例层问题、多数据源模式层问题和多数据源实例层问题,具体的质量问题表现如下:
1)缺少完整性约束,糟糕的模式设计,2)数据记录的错误,3)异质的数据模型和模式设计,4)冗余、互相矛盾或者不一致的数据,5)唯一性约束,⑾引用约束,6)拼写错误,7)相似重复记录,8)互相矛盾的字段,9)命名冲突,10)结构冲突,11)不一致的汇总,12)不一致的时间选择。
问题数据处理:
单数据源情形中出现的问题在多数据源的情况下会变得更加严重.多数据源没有列出在单数据源情形中就已经出现的问题.模式层次上的问题也会体现在实例层次上.糟糕的模式设计、缺少完整性约束的定义以及多个数据源之间异质的数据模型、命名和结构冲突等,都属于该类问题.可以通过改进模式设计、模式转化和模式集成来解决模式层次上的问题.实例层次上的问题在模式层次上不可见,一些可能的情况有数据拼写错误、无效的数据值、重复记录等。
对于第1种情形,由于在数据输入时不知道电话字段的值,因此在数据库中以存放一个无效值来表示.如果针对电话字段定义一个规则存放在数据清洗库中,清洗工具就能够根据这条规则判断出哪些是无效值.对于第2种拼写错误的情形,需要在数据清洗库中建立一个存放所有城市名的查找表,通过与该查找表中的城市名相比较,就可以判断出数据库中存放的本来应该是哪个城市.对于第3种情况,一般也需要利用外部的查找表才能检测出来并加以改正.在数据清洗工具中,一些典型的查找表应该是内建的,此外也应该具备可扩展性