安徽地税数据集中方案.docx
《安徽地税数据集中方案.docx》由会员分享，可在线阅读，更多相关《安徽地税数据集中方案.docx（25页珍藏版）》请在冰豆网上搜索。
安徽地税数据集中方案
一、概述
1.1背景
XX省地税在2006年全省上线运行了XX征收管理系统ahtax2005，全省的信息化工作已经全面展开。
但是系统是在各地市独立运行的，对于省地税来说，无法及时准确地了解全省的税收情况。
另外，税务数据的省级集中也是一个大的趋势。
为了执行国家税务总局要求税务数据全省集中，以及实际的需要，必须建设统一的数据中心，集合全省的数据。
目前，XX省全省共有17个地市，加上省属直接单位，共有18个业务数据库在运行，各地数据都在本地服务器存放，虽然全省已经实现17个地市的2M带宽的连接，但是要对全省的数据进行查询分析还是比较麻烦的。
而且，由于各地税的数据是相对独立的，虽然应用的是同一套系统，但是由于各地的情况比较复杂，数据存在不一致的风险。
因此，必须建立统一的数据模型，通过建立数据仓库整合数据，支撑全省查询分析的需要。
1.2系统建设目标
XX地税数据中心的建设目标是：
1、通过统一的数据存储平台，对数据进行标准化处理和规X化管理，实现数据透明和共享。
目前各地市应用系统在线数据保存在不同的数据库中，各数据结构大致相同，但数据的一致性、统一性和规X性较差，数据共享十分困难。
因此，通过数据中心构建XX地税统一的数据服务平台，实现企业数据的统一规划、集中采集、集中处理和统一管理，形成地税数据的统一视图，实现数据透明和共享，充分发挥地税数据资源的价值。
2、有效支撑统计分析及查询应用等功能。
通过数据中心的建设，整合各地市、各业务系统等多种数据源，形成统一的业务数据视图，并采用统计分析、查询等方式满足各级专业和管理部门人员的不同要求。
3、在完成前两步目标的基础上，进一步建设全省的数据仓库，支撑更多的业务查询、统计分析、数据挖掘功能，提升管理和整体决策能力。
1.3系统建设原则
系统建设遵循以下原则：
Ø整体规划，分步实施，循序渐进，步步见效；
Ø有效控制项目风险；
Ø保护投资的长期有效性，资源能得到有效利用；
Ø为数据和应用大集中做好准备。
二、技术方案
数据仓库体系结构如下图所示：
整个数据仓库系统是一个包含四个层次的体系结构：
数据源：
是数据仓库系统的基础，是整个系统的数据源泉。
通常包括内部信息和外部信息。
内部信息包括存放于关系数据库中的各种业务处理数据和各类文档数据，外部信息包括各类法律法规、经济统计信息等等。
数据存储与管理：
是整个数据仓库系统的核心。
数据仓库的真正关键是数据的存储和管理。
数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。
要决定采用什么产品和技术来建立数据仓库的核心，则需要从数据仓库的技术特点着手分析。
针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。
其中，数据的存储与管理在数据仓库中通常按照三个层面进行存储和管理：
操作数据存储区（ODS）、数据仓库（DW）、数据集市（DM）。
在线分析服务器（OLAP）：
对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。
其具体实现可以分为：
关系型在线分析（ROLAP）、多维在线分析（MOLAP）和混合在线分析（HOLAP）。
ROLAP基本数据和聚合数据均存放在关系数据库之中；MOLAP基本数据和聚合数据均存放于多维数据库中；HOLAP基本数据存放于RDBMS之中，聚合数据存放于多维数据库中。
前端工具：
主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以及各种基于数据仓库或数据集市的应用开发工具。
其中数据分析工具主要针对OLAP服务器，报表工具、数据挖掘工具主要针对数据仓库。
2.1操作数据存储区（ODS）
2.1.1ODS的定位
操作数据存储（ODS）是应用数据库与数据仓库之间的桥梁，在ODS中系统地进行数据整合使数据仓库系统的时效性不足得以弥补，提供统一完整的企业视图和准确的运营数据信息；通过集中简化的信息提取过程，提高业务运行效率；更有效地统计分析税务信息，为实现XX地税内部自动化的信息和业务流程提供便利条件。
ODS的建立实现对税务数据的清理整合，构筑一个统一的、完整的数据平台，确定数据所有者，建立数据同步机制，统一数据编码定义，建立数据访问机制，实现业务系统数据共享，完成应用与数据分离，实现数据从地市到省级的提升。
ODS在XX地税数据集中方案中可以发挥以下几个方面的作用：
⏹作为数据仓库的主要数据源
ODS数据库对应用系统的数据进行了清洗、转换和整合，存储了较为详细和全面的业务运行数据，ODS数据库中的数据不仅具有较高的数据质量，而且比应用系统更有利于数据仓库对数据进行获取和进一步转换，是数据仓库的主要数据来源。
⏹提供报表和查询统计功能
ODS从不同的应用系统中采集数据，整合各个应用系统的共享数据，形成企业级数据的整体视图，实现综合统计和报表查询功能。
⏹进一步引导需求
通过ODS的建设及建立在其上的应用，进一步启发新的业务需求，为数据仓库的建设打下基础。
2.1.2数据抽取、转换与加载（ETL）
2.1.2.1数据源
XX省地税数据中心需要采集的业务基本数据包括：
⏹税务登记
⏹核定管理
⏹申报征收
⏹发票管理
⏹票证管理
⏹行政执法
⏹税费检查
⏹会统管理
这些数据主要从以下一些生产作业系统获得：
⏹XX地税征收管理系统ahtax2005
2.1.2.1.1税务登记
1、目标：
获取纳税人信息等。
纳税人基本登记信息，应缴税种信息，纳税人当前状况，证照信息等。
2、信息交换方式：
直接访问数据库。
3、通信呼叫方式：
纳税人新信息每日定时上传（访问）一次，若当日没有数据则不需要上传。
4、数据文件名称与内容：
1）税务登记信息：
纳税人名称，经营地址，行业信息，开业时间，纳税人状态，所属税务机关，科室代码，注册类型代码，主营X围，兼营X围，经营方式，注册资本，工商登记等。
2）纳税人缴税信息
税种代码、税目代码、缴税频率（按月、季、半年、年等），限缴期限。
3）纳税人状态信息
停复业登记，注销登记、非正常户确认，纳税人迁移。
4）证照信息
证件打印，封存、缴销、作废、遗失。
2.1.2.1.2核定管理
1、目标：
获取定期定额纳税人的税收信息。
核定税款信息，核定社保费信息。
2、信息交换方式：
FTP访问数据库。
3、通信呼叫方式：
本地核定操作后，每月定时往数据中心系统ETL服务器传送本地网的所有核定信息；或通过各本地网接口服务器直接访问。
4、数据文件名称与内容：
1）核定税款信息
核定时期，核定所属期，申报年月，核定的税种、税目，核定税额。
2）社保费核定信息
核定时期，核定所属期，申报年月，核定的税种、税目，核定费额。
2.1.2.1.3申报征收
1、目标：
各地市的申报征收开票信息。
2、信息交换方式：
FTP访问、直接访问数据库。
由于涉及较大的数据量，考虑到服务器的压力，建议通过FTP的方式间接访问数据局库。
3、通信呼叫方式：
每月定时传送（访问）二次。
征收期过后一次，月末一次。
4、数据文件名称与内容：
1）申报信息
企业编码，申报日期，申报税种、申报税目，申报日期，限期申报日期，申报所属期，申报类型，预算级次，预算科目，记税金额，申报税款，减免税款，是否零申报，金库编码
2）开票信息
企业编码，开票日期，入库日期，欠税属性编码，限缴日期，开票税金，减免税金，计征税金，税率、金库编码，预算级次，款项类别，税票，开户银行，银行账号
3）减免税信息
企业编码，减免税种、税目，减免类型，减免期限，减免比率或减免金额
4）延期申报信息
企业编码，延期税种、税目、税款所属期、延期缴纳时间、延期理由
5）欠税信息
企业编码，税种编码、税目编码、税款所属期，欠税金额，欠税属性编码
2.1.2.1.4发票管理
1、目标：
各地市发票计划、印制、库存等信息
2、信息交换方式：
直接访问数据库。
3、通信呼叫方式：
每日定时上传（访问）一次。
4、数据文件名称与内容：
1）发票计划信息
发票名称，计划领购数量
2）发票印制信息
承印单位，发票代码，印制数量、印制价格。
3）发票操作信息
发票发出数量，发票入库数量，发票核销等。
4）发票账务信息
发票记账信息、结账信息。
2.1.2.1.5票证管理
1、目标：
各地税票信息
2、信息交换方式：
直接访问数据库。
3、通信呼叫方式：
每月定时上传（访问）一次。
4、数据文件名称与内容：
1）票证领单
票证编码，发出机关，领入机关，字轨，票号，数量。
2）票证领据
票证编码，发出机关，用票人编码，领用数量，字轨，票证X围，数量。
3）票证结报
票证编码，用票人，结报类型，结报数量，字轨，票证X围。
4）票证上缴
票证编码、用票人，上缴单位，数量、字轨，票证X围。
2.1.2.1.6行政执法
1、目标：
各地行政处罚数据
2、信息交换方式：
FTP访问。
3、通信呼叫方式：
每日定时上传（访问）一次。
4、数据文件名称与内容：
1）处罚案件登记
案件名称，纳税人编码，处罚原因，案件来源，处罚类型，处罚方式，违章原因。
2）处罚案件情况表
案件编码，处罚依据，处罚金额，处罚时间，处罚类型。
2.1.2.1.7税费检查
1、目标：
各地稽查和税费检查情况数据：
2、信息交换方式：
直接访问数据库。
3、通信呼叫方式：
每日定时上传（访问）一次。
4、数据文件名称与内容：
1）案件情况表
案件编号，企业编码，企业名称，行业编码，检（稽）查所属期，检（稽）查时间，案件检（稽）查单位，案件状态，结案时间，立卷时间，是否立案，是否大要案，检查人员，审理人员，执行人员。
2）案件检查情况
案件编号，查处税种，查处税目，查处期间，查处金额，税款类型，预算级次，款项类型，所属金库编码，处罚机关，征收机关编码。
2.1.2.2数据源分析
数据源可以做如下分类：
（1）按照数据类型：
流水型数据
记录增量产生，原记录不能修改的数据，该类数据通常按照一定的周期，根据时间戳传送特定的纪录。
例如：
系统的字典表和关键的辅助表：
BM_SZ，BM_SM等。
混合型数据
记录既可以增量产生，原记录又可以修改的数据，该类数据通常按照一定的周期，对数据进行整表传送。
税收数据大部分都是这种类型的数据。
税收的大部分数据都是这种类型：
比如登记信息表，征收表等。
（2）按照数据量：
大数据量
数据量达到每天百万条记录以上。
从全省的角度来讲，申报表和开票表接近这个数据量。
中等数据量
数据量为每天一万条记录以上。
其他业务数据。
小数据量
数据量低于每天万条条记录。
基本上比较少，如部分文书表等。
（3）按照数据周期：
实时、日周期、月周期、年周期、不定周期。
2.1.2.3数据抽取、转换、加载
ETL即数据抽取、转换和加载，是数据中心实现过程中，将数据由数据源系统向数据中心加载的主要过程。
从功能上看，整个ETL包括三个部分：
1.数据抽取：
从数据源系统抽取数据中心系统需要的数据；
2.数据转换：
将从数据源获取的数据转换成数据中心要求的形式，对数据进行转换；
3.数据加载：
将数据装入数据中心。
ETL实现过程的流程图如下图所示：
在ETL的整个过程中，还必须充分考虑异常情况的处理。
2.1.2.3.1数据抽取
2.1.2.3.1.1数据抽取接口
1、直接访问接口
直接访问方式是在对方数据库上建立接口表（或视图），本系统通过数据直接获取对方数据，然后进行处理的数据通信方法。
该方法适用于双方数据库在同一台服务器上或在同一个局域网内。
2、FTP方式
在省中心配置ETL服务器，在ETL服务器上安装并启动FTP服务，外部系统需要发送给本系统的数据由相关外部系统定期或按需将需要传送的数据按要求组织成文本格式文件，通过FTP上传到本系统的ETL服务器。
⏹FTP文件存放位置
在省级ETL服务器中，统一建立针对外围不同系统存放文件的总目录，并以本地网为单位设置相应子目录，子目录名称为各本地网名称的全拼拼音字母，用来存放各本地网上传的文件；
⏹FTP文件命名规则
用文件扩展名区分数据文件类型，结构类型不同的数据文件其扩展名将不同。
文件扩展名长两位，每位取值X围从‘0’-‘9’、‘A’-‘Z’；文件名前半部分分两种情况：
◆对于每天生成的数据文件，取文件内数据发生的日期，具体文件格式：
‘yyyy（年）mm（月）dd（日）.?
?
’。
◆对于每月生成的数据文件，则取文件内数据所属的帐务月（或统计月），具体文件格式：
‘yyyy（年）mm（月）.?
?
’。
⏹FTP文件格式
可以按照各系统和实际情况，灵活设置FTP文件的格式，如：
文本文件的分隔符采用逗号方式，记录结束标识为换行/回车；或采用字段定长，记录定长的方式。
⏹FTP文件传送完成确认方法
由于数据文件可能很大，FTP传送可能是个漫长的过程，本系统接口处理程序不知道数据文件什么时候传送完毕。
因此，在此要求每个数据文件传送完成之后，再传送一个数据文件传输完成的确认文件，该确认文件以要确认传送完毕的数据文件扩展名后加字符’A’，文件类容仅仅包含要确认传送完毕的数据文件名。
一批传送多个数据文件时，每一个数据文件对应一个确认文件。
例如：
要上传一个20021024.A1的数据文件，确认文件名为20021024.A1A,确认文件内容为：
20021024.A1。
2.1.2.3.1.2数据抽取策略
数据的抽取必须能够充分满足数据中心的需要，又能保证不影响业务系统的性能，所以进行数据抽取时应制定相应的策略，包括抽取方式、抽取时机、抽取周期等内容。
●抽取方式：
增量抽取、完全抽取等。
●抽取时机：
尽可能避开业务系统的高峰时段，可选择在夜间业务系统比较闲时进行。
●抽取周期：
对不同类型的数据源，应综合考虑业务需求和系统代价，制定合理的抽取周期。
在制定抽取策略时，需要对以上各项因素综合考虑。
通常情况下，流水型增长且数据量大的数据适合采用增量抽取的方式；变化更新的数据适合采用完全抽取的方式；对于两者结合的数据，如果能提取增量信息，则进行增量抽取，否则采用完全抽取的方式进行。
此外，对于抽取周期要考虑实际业务的需求和抽取进行的系统代价，在可能的情况下，尽量缩短抽取周期。
2.1.2.3.2数据转换
数据转换是指对从业务系统中抽取的源数据根据数据中心模型的要求，进行数据的转换、清洗、拆分、汇总等处理，保证来自不同系统、不同格式的数据的一致性和完整性，并按要求装入数据中心。
2.1.2.3.2.1数据转换的主要功能
数据转换主要完成由于以下原因造成的数据不一致性问题：
1．源数据系统同数据中心系统在模型上的差异性；
2．源数据系统平台不一致：
数据中心系统的数据源可能包括基于不同平台的数据库的数据，可能会存在大量的转码工作。
；
3．源数据结构的不一致：
有些数据源由于历史的原因，导致同一个表在不同的时期数据结构不一致；
4．源数据定义不规X导致错误数据；
5．对数据的约束不严格，导致无意义数据；
6．存在重复记录。
2.1.2.3.2.2数据转换技术和策略
根据实际情况，数据转换工作一般会在以下几个环节中具体实现：
1．在抽取过程中进行数据处理；
2．使用异步数据加载，以文件的方式处理；
3．在数据加载过程中进行数据处理；
4．进入数据中心以后再进行数据处理。
采用在数据抽取过程中进行数据转换时，必须考虑抽取的性能以及对业务系统性能的影响；采用异步数据加载需要以文件方式处理时，必须充分考虑中间磁盘的存储量以及ETL整个流程的协调性工作，以及大量的非SQL语句的编程；采用在数据加载过程中进行数据转换时，必须考虑加载性能；采用先将数据装载到数据中心后再处理时，必须考虑数据中心引擎的海量数据处理能力。
2.1.2.3.3数据加载
2.1.2.3.3.1数据加载主要功能
数据加载就是将从数据源系统中抽取、转换后的数据加载到操作数据存储区或数据仓库系统中。
要求数据加载工具必须具有高效的加载性能。
2.1.2.3.3.2数据加载技术及策略
主要加载技术：
1.使用数据仓库引擎厂商提供的数据加载工具进行数据加载；
2.通过数据仓库引擎厂商提供的API编程进行数据加载。
数据加载策略要考虑加载周期及数据追加策略两方面的内容。
根据XX地税业务数据的实际情况，加载周期要综合考虑业务分析需求和系统加载的代价，对不同业务系统的数据采用不同的加载周期，但必须保持同一时间业务数据的完整性。
数据的追加策略根据数据的抽取策略以及业务规则确定，一般有以下三种类型：
直接追加、全部覆盖、更新追加。
●直接追加：
是指每次加载时直接将数据追加到目的表中。
对于典型的流水数据，一般采用此方法；
●全部覆盖：
对于抽取数据本身已包括了数据的当前和所有历史状况，对目标表采用全部覆盖方式。
●更新追加：
对于需要连续记录业务的状态变化，用当前的最新状态同历史状态数据进行对比的情况采用更新追加的方式。
具体采取何种方式，要综合考虑效率、业务实现等因素。
2.1.2.4数据审计
每个数据加载周期中，如何保证数据中心中数据同业务系统中数据在业务意义上的一致性及数据的准确性极其重要。
因此，必须引进数据审计功能。
数据正确性的审计工作是在数据加载工作完成以后,一方面要从设计到实施的整个过程中确保算法的正确性，另一方面要通过事后的检验来检查ETL的正确性。
理想的情况是，审计工作必须在数据抽取、转换、加载等所有的阶段都要进行，比如，如果采用异步数据抽取和加载，则在数据抽取传输完毕后，要从记录数、文件大小等角度检验抽取和传输的正确性。
数据加载完毕后，一方面通过加载日志检验加载过程的正确性，另一方面要通过业务规则来校验数据的正确性。
2.2数据仓库（DW）
数据仓库（DataWarehouse）是一个面向主题的（SubjectOriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（TimeVariant）的数据集合，用于支持管理决策。
对于数据仓库的概念我们可以从两个层次予以理解，首先，数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库；其次，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。
根据数据仓库概念的含义，数据仓库拥有以下四个特点：
1.面向主题。
操作型数据库的数据组织面向事务处理任务，各个业务系统之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织。
主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。
2.集成的。
面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。
而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
3.相对稳定的。
操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。
数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。
4.反映历史变化。
操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点（如开始应用数据仓库的时点）到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。
企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。
数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。
而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。
因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程。
2.2.1主题数据库
数据仓库里的数据都是按照业务主题进行组织的。
主题数据库的基本特征如下：
1．面向业务主题（不是面向单个报表）。
主题数据库是面向业务主题的数据组织存储，例如，对于XX地税来讲，需要建立的典型的主题数据库包括：
税务、申报、发票、票证、行政执法、税费等数据库的结构，是对有关税务、发票、税费的数据项进行分析整理而设计的，不是按税务、发票、税费的原样建立的。
这些主题数据库与税务管理中要解决的主要问题相关联，而不是与通常的计算机应用项目相关联。
2．信息共享（不是信息私有或部门所有）。
主题数据库是对各个应用系统“自建自用”的数据库的彻底否定，强调建立各个应用系统“共建共用”的共享数据库。
不同的应用系统的计算机程序调用这些主题数据库。
3．一次一处输入系统（不是多次多处输入系统）。
主题数据库要求调研分析各业务层次上的数据源，强调数据的就地采集、就地处理、使用和存储，以及必要的传输、汇总和集中存储。
同一数据必须一次、一处进入系统，保证其准确性、及时性和完整性，经由网络-计算机-数据库系统，可以多次、多处使用。
4．由基本表组成。
一个主题数据库的科学的数据结构，是由多个达到“基本表” （Base Table）规X的数据实体构成的，这些基本表具有如下的特性：
原子性――基本表中的数据项是数据元素（即最小的、不能再分解的信息单元）；
演绎性――可由基本表中的数据生成全部输出数据（即这些基本表是精练的，经过计算处理可以产生全部企业管理所需要的数据）；
规X性――基本表中数据满足三X式（3-NF）要求，这是科学的、能满足演绎性要求、并能保证快捷存取的数据结构。
在设计的同时，关键是要做好数据字典的维护工作，以使你对自己的数据库了如指掌。
2.2.2数据存储
数据仓库为XX地税各级管理部门、分析人员的分析、决策操作提供统一、集成的基础数据，包括XX地税各个业务部门当前及其历史的细节性业务数据，以及为了进行分析决策操作而生成的分析型数据，是一个统一、集成、稳定、基于历史数据的庞大数据集合，需要借助成熟的数据库技术对其进行存储管理，即利用改造过的关系数据库系统来组织和管理面向主题的数据仓库中的数据。
2.2.2.1整合业务数据的基础数据层
数据仓库系统的基础数据是按照主题来组织的。
基础数据层只考虑数据本身的来源与属性，按照业务本身的数据之间的相互关系来组织数据，而不考虑数据的应用，即“整合数据”，其目的在于减少数据的冗余，提高系统的灵活性，能快速的实现新增主题和功能。
2.2.2.2面向决策支持的分析数据层
应用数据层与具体的应用需求紧密结合，按照应用的要求来组织基础数据层的数据。
面向应用，其目的就是针对面向主题，面向具体的应用，提高访问、执行、查询的效率，即“面向决策支持”。
2.2.2.3数据仓库信息模型
数据仓库信息主题，主要包括：
税务登记、核定管理、申报征收、发票管理、票证管理、行政执法、税费检查、会统管理等，按照XX地税信息的组成进行前瞻性的结构设计。
2.2.3数据展现
数据仓库系统应提供灵活多样的展现方式。
目前常用的展现方式有：
固定（预定义）报表、图表、即席查询（Ad-Hoc）、多维动态分析等。
各主题分析的展现方式除了可以通过以上方式进行展现，对于异常的分析结果还可以通过短消息、或其他告警方式进行预警。
表格和图表可以转换为Excel等格式，分析人员可以根据需要排序、分组数据并改变图表的类型（直方图、饼形图、折线图、堆积图等），可在任何维度上通过“钻取”和“切片”生成报表及图形。
复合报表要“所见即所得”。
2.2.4数据挖掘
数据挖掘（DataMi
升级会员 