浅谈基于数据仓库技术的税收数据应用系统建设

摘要:基于数据仓库技术,设计了税务数据应用系统的宏观架构,并对其中的数据加工平台、数据存储平台、应用服务平台-OLAP引擎、数据展现平台以及元数据管理平台等各组成部件进行了研究,最后提出了下一步研究方向。

关键词:数据仓库;税务系统;数据应用;OLAP

中图分类号:TP274文献标识码:A文章编号:1007-9599 (2010) 03-0072-03

The Construction of Revenue Data Application System Based on

Datawarehouse Technology

Yin Songtao1,Zhao Weiwei2

(1.Jiangsu Local Taxation Bureau,Nanjing 210024,China;

2.Jiangsu Entry-Exit Inspectin and Qunarantine Bureau,Nanjing 210001,China)

Abstract: Based on the data warehouse technology, this article has designed the macrostructure of revenue data application system,and has researched its components ,including data processing platform, data storage platform, application services platform-OLAP engine, data presentation platform and metadata management platform, finally proposed the next step research direction.

Keywords: Datawarehouse;Revenue System;Data Application;OLAP

一、引言

随着全国税务行业信息化建设的不断深化发展,各级税务机关通过开发各类税收业务系统,已基本完成各类税收业务数据的电子化采集工作,但这些系统很多是不同时期和不同渠道建设的,普遍缺少对这些宝贵数据系统、科学、灵活、有效的分析利用,无法将其从“数据”转化成为“信息”,从而真正体现信息化技术对税收管理工作的核心支撑和驱动作用,因此研究税务系统的数据应用系统建设,具有重要的理论意义和现实价值。

本文主要阐述如何借助业界成熟的数据仓库技术来构建一整套面向各级税务机关的税收数据应用系统。通过对各类现有数据进行归并整合,使之成为一个可扩展的综合数据应用平台,从而提高税收数据资源利用率,实现信息技术手段对税收日常管理工作的辅助决策支持作用。文章主要分析了“数据仓库”的基本概念和分层架构等,同时基于数据仓库技术,提出了税务数据应用系统的宏观架构,并对其中的数据加工平台、数据存储平台、应用服务平台-OLAP引擎、数据展现平台以及元数据管理平台等各组成平台进行了研究分析。

二、数据仓库概述

数据仓库概念始于20世纪80年代中期,首次出现在被称为“数据仓库之父”WiiliamH.Inmon编写的《建立数据仓库》一书中:“数据仓库是在企业管理和决策中面向主题的、集成的、不可更新的,随时间不断变化的数据集合”。换言之,数据仓库是数据积累、信息需求增长的产物,其目标是达到有效的决策支持,但它不是数据的简单堆积,而是从大量的事务型数据库中抽取数据,并将其按照管理目标的不同进行分类清理、转换、整合成为新的特殊存储格式,随着此过程的不断发展和完善,这种支持决策的、特殊的数据存储即被称为数据仓库。

数据仓库的最终目标是尽可能让决策者能够方便、有效和准确地使用数据仓库,但这仅靠数据仓库本身是难以实现的,必须再加上数据仓库前道的数据加工和后道的分析展现才能真正实现这一目的,而这一套完整的动态体系架构我们就称之为“数据仓库系统”。在Jiawei Han和Micheline Kmaber编著的《数据挖掘概念与技术》一书中,对于数据仓库系统划分了四个层次,具体由图1表示。

图1数据仓库系统体系结构

三、税收数据应用系统设计

宏观架构设计。鉴于税收数据应用系统的特殊性,与现有传统数据采集型生

产系统在体系架构、建模方式、应用重点等方面都有较大差异,可以看作是基于数据仓库技术的数据仓库系统的一类具体行业性应用,也应按照上述四层体系结构来建设,因此我们提出采用数据仓库的思想和体系架构来建设税收数据应用系统。根据税收数据应用系统建设的要求,税收数据应用系统的宏观架构见图2。

图2税收数据应用系统宏观架构

税收数据应用系统由从下自上的五大分层平台共同构成:

(一)数据加工平台:实现不同数据之间的传递和加工,由一系列数据加工处理服务组成,包括数据交换/采集服务、数据审计(产生推送数据和预警数据,完成数据质量检查和校验)、ETL(实现不同数据模型之间的抽取、清洗、加工、转换、装载)、数据挖掘等。

(二)数据存储平台:保存税收数据应用系统中涉及的各种数据,并进行分类设计和存放。按照数据库存储数据的类型和作用分为:业务数据库、采集/交换数据库、ODS操作数据存储(主要是各类实时性比较高的明细型数据,例如一户式、一员式数据等,同时其中还包括数据审计产生的面向各级用户的各类预警/推送数据)、数据仓库/数据集市、元数据控制数据等数据库。通过这些不同类型的数据库划分,既满足不同类型应用程序的差异,又便于日常的管理维护。

(三)应用服务平台:以相对平台化的服务提供应用开发的基础平台和运行部署平台。具体包括业务处理、数据服务、采集交换、预警推送、实体查询、查询分析、报表加工、门户控制和元数据等主要功能。

(四)数据展现平台:将通过应用服务平台加工处理后的数据以丰富多样的形式展现给最终用户,就目前税务系统常见的展现需求而言,主要包括以下几种形式:明细查询、实体查询、多维分析、趋势分析、对比分析、排名分析、固定报表、MDX分析、图形展现等。

(五)元数据管理平台:提供应用开发人员和系统维护人员对各类元数据进行开发、维护和管理监控的平台。

在上述五项分层平台的基础上,即可搭建我们的各项应用系统,就税务行业而言,目前根据应用模式基本可以初步划分为:面向业务处理的征管信息系统、面向纳税人服务的电子申报系统和面向决策分析的税收数据应用系统,这三者通过门户手段整合到一个门户系统中。税收数据应用系统是比较全面的应用系统建设,由于篇幅所限,我们这里重点阐述整体系统架构中的数据加工平台、数据存储平台、应用服务平台中与OLAP相关的部分、数据展现平台以及元数据管理平台。

1.数据加工平台。

数据加工平台由数据加工服务器、管理监控平台、数据加工规则三部分组成,实现从源数据(一个或多个)到目标数据(一个或多个)的数据加工,系统的结构见图3。

图3数据加工平台总体结构

2.数据存储平台。

税收数据应用系统的核心在于数据的科学、合理的存储和管理,从数据类型划分、数据分布、数据用途、数据时效性等角度进行分类和设计,税收数据应用系统中包括以下类型的数据:

(1)业务明细数据:由业务处理系统产生和管理,数据的组织以业务处理

(OLTP)为主,数据时效性要求比较高,通常只保存近期(二至三年内且处于活动状态)的数据,业务明细以满足业务处理的性能作为中心进行结构设计,通常基于ER模型(实体-关系模型)进行设计和存储。

(2)操作型数据存储(ODS):通过数据抽取从业务系统数据库获得的数据,或通过数据采集/交换系统直接录入的各种业务数据,可以直接提供各种明细数据的查询服务,数据的时效性为接近实时,数据结构组织上贴近于业务处理系统。

(3)历史明细数据:由业务处理系统和ODS数据库中迁移出来,通过一定的数据清洗和转换后形成的历史明细数据;历史明细数据通常为处于稳定(不再发生变化)的数据,对历史明细数据访问的时效性要求通常不高,历史明细数据即数据仓库中的细节数据,历史明细数据满足对业务历史数据的访问要求。

(4)主题分析数据:从历史明细数据基础上通过数据的加工和聚合产生的业务分析数据,业务分析数据通过以业务主题为中心,主题分析数据的数据时效性要求不高。

通过这种不同粒度和不同层次的标准划分,来满足各类用户的数据应用需求,结合税务系统而言:对于一线税管员而言,他关心的是所管辖的每户纳税人的当月申报明细数据,以便确认该纳税人是否按期、按项、足额纳税;对于中层科所长而言,他关心的是本单位的各类轻度汇总的统计报表,以便及时调整近期的管理重点和管理方式;对于局领导而言,他关心的则是所辖各单位的高度综合数据,以便确保宏观整体工作进度,例如省局局领导所关心的是各省辖市局的最新税收入库数和计划完成数,相反他不会去关心某个纳税人当月的纳税项目和纳税金额。

3.应用服务平台-OLAP。

目前市面上有很多OLAP引擎的第三方产品,虽然种类众多,但使用基本一致。例如:Mondrian是一个使用Java开发的开放源代码的ROLAP服务器[3]。它实现了XMLA(Xml For Analysis)和JOLAP(Java Online Analytical Processing)规范,而且自定义了一种使用MDX语言的客户端接口。在功能上,Mondrian支持共享维和成员计算,支持星型模型和雪花模型的功能。

4.数据展现平台。

数据仓库的数据以及分析结果需要用一种灵活的方式展现出来,其中包括报表、查询、多维分析等多种方式提供给最终用户使用。通过对税收管理决策业务的分析,我们认为数据展现平台重点不在于其实现了多少功能,而在于其是否支持灵活扩展性,我们需要的是对于大部分查询、统计、报表、分析而言都能够由操作人员根据实际需要动态配置后即可使用,而不能是固化在程序中无法修改调整,即大部分的应用功能应基于应用开发平台配置生成,无需编码。因此我们考虑数据展现平台应至少由以下三部分组成:

(1)数据展现器:提供最终用户使用的数据展现器,实现数据的展现功能。其应能实现门户管理、通用查询、通用报表和通用分析等功能。

(2)数据展现设计器:提供开发人员使用的设计工具,完成数据展现功能的设计和开发。

(3)资料库和控制库:资料库和控制库中保存数据展现相关的各种元数据,包括用户、组、角色、功能定义、权限、数据源等,可以以XML文件形式进行保存。

5.元数据管理平台。

元数据管理是数据仓库系统中提出的概念,“元数据”即描述数据的数据,用来对数据的定义和内涵进行描述,便于使用人员(包括技术人员和业务人员)理解数据库和数据仓库保存的、及应用功能中展现的各种数据,包括数据的格式、含义、加工过程、业务算法等,形成对数据全方面的理解,并在此基础上形成对数据的分析和应用。根据上述对元数据的定义,元数据管理平台将元数据划分为以下几种:

(1)业务元数据:即数据标准定义,主要实现税收数据应用系统中的涉及的税务术语的统一定义和管理。

(2)模型元数据:对保存在数据库、数据仓库、数据集市中的数据项的结构和含义进行描述。

(3)ETL元数据:对数据加工处理过程中的指标数据的加工过程和业务算法进行描述。

(4)应用元数据:对数据分析利用阶段的业务功能的内容、指标的口径和算法进行描述。

四、总结和展望

本文设计了税务数据仓库的宏观体系架构,并对其中的数据加工、数据存储、OLAP引擎、数据展现平台以及元数据管理等设计工作进行了研究。但还有如下几方面内容需要进一步考虑:

(一)税务系统的数据仓库建成之后规模一般都很大,从建立之初就要保证它的可管理性,需要进一步解决如何使数据可用性和系统稳定性达到最大,并优化性能;在数据仓库的应用中迅速反映变化的业务环境;管理数据仓库应用程序的生命周期等。

(二)现有数据应用系统主要是针对关系型结构化数据的分析应用,随着税收信息化应用的不断深化,电子照片方式的档案资料将会更为增多,这些资料在提高数据的准确性方面和降低税务人员的录入工作量方面具有非常重要的现实意义,如何加强此类非结构化数据的应用将是下一步的一项重要工作内容。

(三)随着近几年DW2.0概念的提出,我们将结合DW2.0的思路,对现有的中心数据仓库进一步划分为:交互区、整合区、近线区和归档区[4],以进一步区分不同的数据类型,同时对VODS(虚拟操作数据存储)等新技术进行分析。

参考文献:

[1]W.H.Inmon.Building the Data Warehouse[M].JohnWiley&Sons Inc,1993

[2]Jiawei Han,Micheline Kmaber.数据挖掘概念与技术[M].范明等.北京:机械工业出版社,2001:61-67

[3]Mondrian[EB/OL].Sourceforge网站Mondrian专题,2007,1,26

[4]W.H.Inmon.DW2.0 WHITE PAPER[EB/OL].Inmoncif网站DW2.0专题,2006

作者简介

殷松涛(1979-),男,软件工程硕士,研究方向:数据仓库、数据审计、数据库管理等;

赵伟伟(1980-),女,硕士在读,研究方向:软件工程和计算机应用。