电子税务局毕业论文

时间：2023-05-01 10:40:40 论文范文我要投稿

相关推荐

电子税务局毕业论文

学校编码：10384 分类号密级学号：X20113287123 UDC

电子税务局毕业论文

工程硕士学位论文

某市税收数据综合应用平台

数据质量监控系统的设计与实现

Design and Implementation of Data Quality Monitoring system for Integrated Tax Data Application Platform

李正东

指导教师：林凡副教授

专业名称：软件工程

论文提交日期： 2011年9月

论文答辩日期： 2011年9月

学位授予日期：年

指导教师：__________

答辩委员会主席：__________

2015年*月月

厦门大学学位论文原创性声明

本人呈交的学位论文是本人在导师指导下,独立完成的研究成果。本人在论文写作中参考其他个人或集体已经发表的研究成果，均在文中以适当方式明确标明，并符合法律规范和《厦门大学研究生学术活动规范（试行）》。

另外，该学位论文为（）课题（组）的研究成果，获得（）课题（组）经费或实验室的资助，在（）实验室完成。（请在以上括号内填写课题或课题组负责人或实验室名称，未有此项声明内容的，可以不作特别声明。）

声明人（签名）：

年月日

厦门大学学位论文著作权使用声明

本人同意厦门大学根据《中华人民共和国学位条例暂行实施办法》等规定保留和使用此学位论文，并向主管部门或其指定机构送交学位论文（包括纸质版和电子版），允许学位论文进入厦门大学图书馆及其数据库被查阅、借阅。本人同意厦门大学将学位论文加入全国博士、硕士学位论文共建单位数据库进行检索，将学位论文的标题和摘要汇编出版，采用影印、缩印或者其它方式合理复制学位论文。

本学位论文属于：

（）1.经厦门大学保密委员会审查核定的保密学位论文，于年月日解密，解密后适用上述授权。

（√）2.不保密，适用上述授权。

（请在以上相应括号内打“√”或填上相应内容。保密学位论文应是已经厦门大学保密委员会审定过的学位论文，未经厦门大学保密委员会审定的学位论文均为公开学位论文。此声明栏不填写的，默认为公开学位论文，均适用上述授权。）

声明人（签名）：

年月日

摘要

税收征管和纳税服务是税收工作的两大核心业务。强化核心业务，关键在于提高税源管理水平。税源管理水平的高低，很大程度上取决于是否有效地解决“两个不对称”问题，即征纳双方之间的信息不对称、税务系统内各部门之间的信息不对称问题。这就要求税务部门首先要打通税务系统内各部门之间的、税务系统和各经济主管单位之间的信息交互渠道，整合来至其他社会部门的涉税资源。并在此的基础上，从税收工作实际出发，强化税收情报综合分析能力，打破“两个不对称”的信息藩篱，从源头上提高税源管理效益。

我国税务系统经过多年的信息化建设，尤其是金税工程的不断推进，基本实现了税收征管工作的数字化，但对海量税收数据的监、管、用缺乏全生命周期的规划，这成为税务部门有效发挥其职能作用的瓶颈。利用现代信息处理技术，强化涉税数据管理与应用，已成为各国税务部门提升税源管理水平的突破口。

本文按照总局“信息管税”的总体要求，针对基层税务机关的开展税收征管和纳税服务工作实际需要，结合某市国家税务局税收数据综合应用平台的建设思路和要求，利用数据仓库、数据挖掘等信息处理手段，进行分析挖掘等技术手段，对多种来源的涉税数据进行全生命周期的质量监督和管理，全力确保涉税信息“采集数据、挖掘信息、发现规律、获取知识”的税收数据分析利用链条的质量，提升税收数据信息和价值发现的有效性、可靠性，进一步发挥信息化建设对推进税收事业发展的支撑作用，推进征管体系现代化，服务经济、社会发展的“新常态”。

关键词：税收数据综合应用平台；税源管理；信息不对称

Abstract

Tax revenue collection and management are two of the main businesses of taxation work。To strengthen the core business, the key is to raise the level of tax source management. And the level of tax source management depends on whether we can solve two kinds of the information asymmetric problem or not. In another words, we need to solve the information asymmetry problem between the taxpayers and collection department, and between different departments in tax system. Hence, this requires us to make ways for information exchange between different departments in tax system and between the tax system and various economic unites, to integrate the tax resources from other social sectors. Given on that, we should Starting from the reality of tax work, strengthening the comprehensive analysis ability in tax information, breaking the obstacles of two asymmetric, so as to improve the efficiency of tax source management from the beginning.

After years of information construction in our tax system, especially the continuing boosting of golden tax project, our county realizes the digitalization in tax collection work. But, for rapid development of social economic environment, it is

still lack of overall plan of tax data monitoring, management and using with the full data life-cycle, which becomes the bottleneck of effectively play functions in tax departments. So using modern information processing technology and strengthening the tax-related data management and application, has become the breach of the tax department to enhance the level of tax source management.

????? 缺33333

Keywords: Tax Data Integrated Application Platform；Tax Source Management； Tax Data Monitoring

摘要 ........................................................................................................... I Abstract .................................................................................................... II 目录 ........................................................................................................ IV

第1章

1.1

1.2

1.3

第2章

2.1

2.2

2.4.1

2.4.2

2.4.3

第3章

3.1

3.2

3.2.1

3.2.2

3.2.3

3.2.4

3.2.5

3.3

3.3.1

3.3.2

3.3.3

3.3.4

3.3.5

3.3.6

3.3.7 绪论........................................................................................... 1 项目开发的背景 ...................................................................................... 1 国内外研究现状综述 .............................................................................. 2 本文的研究方向及主要工作 .................................................................. 2 项目整体架构 ....................................... 错误！未定义书签。项目定位与目标 .................................................... 错误！未定义书签。项目设计原则 ........................................................ 错误！未定义书签。开放性与独立性统一原则 .................................... 错误！未定义书签。可持续发展原则 .................................................... 错误！未定义书签。先进性与成熟性结合原则 .................................... 错误！未定义书签。需求分析 .................................................................................. 4 项目需求综述 .......................................................................................... 4 业务需求 ..........................................http://www.unjs.com........................................................ 8 查询统计 ................................................................ 错误！未定义书签。报表管理 ................................................................ 错误！未定义书签。报告管理 ................................................................ 错误！未定义书签。 OLAP分析 ............................................................... 错误！未定义书签。数据挖掘应用 ........................................................ 错误！未定义书签。技术需求 ................................................................................................ 12 框架需求 ................................................................ 错误！未定义书签。性能需求 ................................................................................................ 23 可扩展性需求 ........................................................................................ 24 可操作性需求 ........................................................ 错误！未定义书签。可靠性需求 ............................................................ 错误！未定义书签。数据需求 ................................................................ 错误！未定义书签。数据应用对象需求 ................................................ 错误！未定义书签。

3.3.9

第4章

4.1

4.2

4.3

4.4

4.4.1

4.4.2

4.4.3

第5章

5.1

5.1.1

5.1.2

5.1.3

5.2

5.2.1

5.2.2

5.2.3

5.2.4

5.2.5

5.2.6

5.2.7

5.3

5.3.1

5.3.2

5.3.3

5.3.4

5.3.5

第6章

6.1

6.2

6.3 其他技术需求 ........................................................................................ 25 概要设计 ................................................................................ 26 总体框架设计 ........................................................ 错误！未定义书签。数据架构设计 ........................................................ 错误！未定义书签。应用架构设计 ........................................................ 错误！未定义书签。非功能设计 ............................................................ 错误！未定义书签。性能设计 ................................................................ 错误！未定义书签。可靠性设计 ............................................................ 错误！未定义书签。可维护性设计 ........................................................ 错误！未定义书签。数据支撑层的详细设计与实现 ........... 错误！未定义书签。数据支撑层架构规划 ............................................ 错误！未定义书签。生产系统数据层 .................................................... 错误！未定义书签。数据仓库层 ............................................................ 错误！未定义书签。分析应用系统层 .................................................... 错误！未定义书签。数据模型的设计与实现 ........................................ 错误！未定义书签。数据层次模型 ........................................................ 错误！未定义书签。历史区..................................................................... 错误！未定义书签。原子区..................................................................... 错误！未定义书签。汇总层..................................................................... 错误！未定义书签。主题数据概念模型 ................................................ 错误！未定义书签。逻辑模型实例 ........................................................ 错误！未定义书签。模型管理工具 ........................................................ 错误！未定义书签。数据的抽取、转换和加载 .................................... 错误！未定义书签。总体设计 ................................................................ 错误！未定义书签。数据同步 ................................................................ 错误！未定义书签。 OT-ETL ..................................................................... 错误！未定义书签。数据加工 ................................................................ 错误！未定义书签。数据反馈 ................................................................ 错误！未定义书签。应用支撑层的详细设计与实现 ............................................ 26 应用层总体架构 .................................................................................... 55 应用支撑功能模块定义 ........................................ 错误！未定义书签。应用支撑层的实现 ................................................ 错误！未定义书签。

6.3.2

6.3.3 分析引擎设计 ........................................................ 错误！未定义书签。通用分析工具设计 ................................................ 错误！未定义书签。

第7章

7.1

7.1.1

7.1.2

7.1.3

7.1.4

7.1.5

7.2

7.2.1

7.2.2 重点功能模块设计与实现 ................... 错误！未定义书签。一户式管理子系统 ................................................ 错误！未定义书签。一户式——整体设计 ............................................ 错误！未定义书签。逻辑结构 ................................................................ 错误！未定义书签。一户式——首页 .................................................... 错误！未定义书签。一户式——查询统计 ............................................ 错误！未定义书签。界面设计与实现 .................................................... 错误！未定义书签。收入分析 ................................................................ 错误！未定义书签。领导驾驶舱设计 .................................................... 错误！未定义书签。税源地图 ................................................................ 错误！未定义书签。

第8章

8.1

8.2

8.3

8.4

8.4.1

8.4.2

8.4.3

8.4.4

8.5 项目测试 ................................................................................ 56 测试目标 ................................................................................................ 56 测试规划及方案 .................................................................................... 56 测试准备 ................................................................................................ 57 测试内容与结果 .................................................................................... 57 数据和数据库完整性测试 .................................................................... 57 接口测试 ................................................................................................ 57 功能测试 ................................................................................................ 58 性能测试 ................................................................................................ 59 测试结果分析 ........................................................................................ 64

第9章

9.1

9.2 总结与展望 ............................................................................ 65 总结......................................................................................................... 65 展望......................................................................................................... 65

参考文献................................................................................................... 67

致谢 ....................................................................................................... 69

第1章绪论

1.1 项目开发的背景

经济决定税收，税收影响经济。近年来，经济的发展逐渐呈现出从要素驱动、投资驱动转向创新驱动的“新常态”[1]。作为和经济密切相关的税收工作，也必然会呈现出。在社会经济走向“新常态”的过程中，与之密切相关的税收工作将会面临更多的挑战。目前，我国的税制结构仍然以间接税为主，在由10%左右的高速经济增长向7%左右的中高速经济增长“新常态”转变的过程中[2]，税收增长率的减速幅度通常会大于经济增长率的减速幅度。同时，经济结构变化必然带来税源结构的深刻变化。一方面，经济实体的组织形式、经营方式不断增加，发展速度不断加快 [3]。税源呈现出复杂性、隐蔽性和流动性越来越突出、越来越普遍的特点[4]。另一方面，随着房地产税等涉及个人的直接税改革的推进，纳税人的范围将在现有企业、个体工商户的基础上增加自然人，纳税人数量将从“大量”变成“海量”；其高容量（Volume）、多样性（Variety）、速度（Velocity）及价值（Value）的4V特性[5]，直接导致了税务部门的数据来源更加广泛、数据类型多种多样。这使得各级税务机关如何更加有效的“监、管、用”税收信息，持续提高涉税数据质量的问题逐渐显现出来。

同时，在税收“新常态”下，我国税务系统不断“加强税收征收管理信息系统的现代化建设”[7]。“金税三期工程”的推广建设，一是在全国税务系统的范围内，包括国税系统和地方税务系统，规范了涉税数据的采集、处理和管理机制，为信息分析利用准备了数据基础；二是金税三期工程主体系统在国家税务总局、国税系统和地税系统的全面应用，实现了全国税收管理信息系统的统一，为大范围的涉税信息分析利用提供了技术条件；三是全国、省级数据大集中、涉税数据分类管和统一的税收征管工作要求，为信息分析利用整合了统一的管理体系[8]。

综上所述，现阶段，我国税务系统既存在强化税收数据质量监督、规范涉税数据使用的内在要求，也具备了深度分析利用涉税数据所需的物质基础、技术条件和管理体系。

1.2 研究现状和问题

西方国家，如美国、德国、日本、意大利、澳大利亚等国家，税收信息化建设起步早、发展快、历时长、技术沉淀和经验积累深厚，已经逐渐从简单的统计分析发展到有理论支撑、技术先进、管理配套的现代税收数据质量管控系统。例如，美国联邦税务局（IRS）通过两个全国性的总部计算机中心和10个区域性的大区服务中心实现了税收数据的高度管理，在进行业务管理、实现有效的税源管理、征收率高达80%以上的同时，税收直接成本下降到0.4%左右[6]。

我国税收信息化建设走过了以业务处理为主的、以“单机使用”、“税网/新税网”、“省级集中”为标志的信息化建设历程，进入了以“金税三期”为标志的“业务处理系统和决策支持并重”、“统一系统、统一流程、统一数据”、全国涉税数据总局/省局两级集中的新的发展阶段。全国各级税务部门在不断探索数据分析和税源管理工作的过程中，都对如何通过技术手段提高数据质量的问题进行了不断的研究和实践。例如，XX国税利用税收数据综合应用平台，整合了金税三期系统数据、防伪税控系统数据、车辆购置数据以及工商、海关、质检、能源、交通、公安等多个部门的涉税，通过多方比对的方式排除疑点，提高数据质量。但是，由于局限于当时现实条件，涉税数据质量的管理能力和效率都较为有限，无法满足“新常态”下经济社会发展对税收工作提出的时代要求。

1.3 本文的研究方向及主要工作

本文按照总局“以信息管税为依托,努力构建税源专业化管理新体系”[9]的总体思路，立足金税三期系统，借鉴其他行业对业务数据质量管控的实践经验，针对涉税数据质量管理“没人管”、“没法管”等问题，在某市国家税务局税收数据综合应用平台的整体框架下，从各种来源的涉税数据的采集、整理、保存、流转、使用等多个环节入手，【？？？？？？】利用、等现代信息处理技术，采用。。。。。。。的手段，不断丰富涉税数据质量的跟踪监控手段，预警数据使用风险，完善涉税信息“采集数据、挖掘信息、发现规律、获取知识”的分析利用链条，进一步发挥信息化建设对推进税收事业发展的支撑作用。本项目是XX市国

家税务局强化数据质量管控、深化数据分析利用，努力适应税收工作“新常态”的一次新的尝试和努力。

1.4 本文的组织结构

第1章是绪论。从内部原因和外部原因，既经济发展“新常态”和税收工作“新常态”，两个方面分析了税收数据质量管控的必要性和可行性，介绍了当前研究的概况以及主要的问题，明确了本文的研究方向，并对论文的组织结构进行了说明。

第2章是需求分析。从业务需求描述，采用流程图和用例图描绘了系统的功能需求，包括指标管理需求分析、计划管理需求分析、支付管理需求分析、银行管理需求分析、公务卡管理需求分析、工资统发需求分析、数据报表需求分析和系统管理需求分析等。

第3章是系统设计。详细的介绍了系统的总体框架设计、功能架构设计图，总体功能设计、数据库设计和安全设计等。

第4章是系统实现。详细介绍了系统的实现环境、主要界面设计以及关键功能模块的实现过程，给出了重要功能的实现代码。

第5章是系统测试。包括系统的测试环境，功能测试用例设计、功能测试结果分析以及性能测试场景设计和性能测试结果分析，并给出了具体的测试分析图。

第6章是总结与展望部分。总结了本文所开展的研究工作，给出了后期系统需要改进的地方。

第2章需求分析

2.1 项目需求综述

2.1.1 业务现状分析

随着税务信息化建设不断向深度和广度发展，征管数据的采集和覆盖范围日益扩大，就实际工作来看，在综合征管软件数据采集和处理过程中，出现了部分质量低下、无效、冗余、不合法、不一致的数据，税务生产系统数据质量现状不容乐观，而对于未来税务大数据的应用来说，数据质量又是一个分析系统的生命力之源。作为目前税务涉税信息的数据质量管控还未有信息化的支撑，往往在业务人员发现了数据质量事故发生或被发现之后，由信息化人员采取人工的方式去排错、去清理。目前这种基于事后，人工管控的数据质量治理手段基于以下流程展开：

目前基于上述流程的人工数据质量管控有以下不足：

1. 所有数据质量的问题发现只能靠事后，实际工作中业务人员被动的发现，

无法提前治理，导致质量事故的发生。

2. 数据质量问题即使分析到数据异常规则，由于无法获知数据异常的生产

来源，数据质量还会随着生产数据的产生而产生，无法从根本解决数据质量管控。

3. 整个质量管控的过程成果维护起来费时费力，存在大量的返工，成本加

高。

4. 基于人工的数据质量管控成果信息无法归集，也无法进行成果分析和宏

观的预警，无法为辅助决策提供

2.1.2 业务流程分析

面对目前人工执行数据质量管控的弊端，为解决目前税务局数据仓库的数据质量管控，依赖信息化系统建设，降低质量管控的难度，在降低成本的同时，增强数据分析的准确性。原则上，可以将数据质量按照业务约束和技术约束来区分，例如行业认定和经营范围不符合的异常数据，直接影响群体分析的准确性，所以对于这种限制于业务影响的，称之为业务约束导致的数据质量问题。对于重复记录、字符类型不符、长度不符的，编码规范不符的，直接受数据库技术约束，称之为技术约束数据质量问题。受技术约束的数据质量问题，一般有估计的解决规则，发现异常可以按照重复的规则处理。受业务约束的数据质量问题，一般需要人工的治理，系统需要能自动识别和任务推送即可。

将传统人工数据质量管控和信息化相结合的思路，就需要梳理出利用信息化分析的整个基于数据仓库的数据质量管控系统业务流程，目前结合传统业务，规划整个业务系统的流程如下：

如上图流程，同过引入信息化数据质量管控流程后，和现状业务相比，数据质量管控具有以下优点：

1. 实现了数据质量规则的维护，成果会有数据保留，利于成果复用和规则

完善。

2. 增加了周期性的自动化扫描分析，降低人工重复查找数据质量难度和时

间，节省了人力和成本。

3. 增加了自动清理环节，对于分析出来的数据质量问题，尤其针对生产数

据无法从源头解决的数据质量问题，一旦有确定的清理规则，可以结合周期扫描监控来及时自动化进行数据异常数据清理。

4. 系统考虑到有些由于业务操作引起数据质量问题，需要具体业务人员根

据实际具体治理的，则系统提供人工统筹流程，及时提醒提示治理。

5. 在系统流程实现数据质量管控的基础上，进行各个环节的成果进行分析，

含跟踪管理和效应分析。

6. 随着数据质量管控成果知识的积累，可以依赖成果数据进行宏观预警，

对高发的数据质量问题或高发的群体，自动化分析，提供预警信息。

2.1.3 系统角色分析

按照系统业务流程分析，系统流程可分为制定数据质量模型、管控方案、扫描分析、任务统筹、质量治理、成果分析、监测预警等主要环节。扫描监控为系统后台功能，在系统流程上可以和管控方案合并为分析监控环节。按照这样的分析可以将系统共分为：质量模型、分析监控、任务统筹、质量治理、成果分析、监测预警核心业务模块。考虑该系统需要单独部署需要单独的系统管理模块。所以按照系统业务模块，划分系统角色如下：

图2-1：图 2.2 业务需求

2.2.1 质量模型需求

质量模型是将数据质量从业务转化成技术实现的基础，是将平时业务人员能看懂的数据质量业务规则通过质量模型的维护，转化到具体数据表上的逻辑规则定义。质量模型业务上的规划可分为四层设计思路，分别为数据层、对接层、逻辑层、规则层，分别通过指标元、指标和模型来维护出数据质量模型。应实现数据质量规则管理，在标准的数据质量规范之上，通过数据质量审计和数据一致性

比对来对数据质量进行检查，发现数据出现差错的环节。质量模型就是将示意图如下：

2.2.2 分析监控需求

分析监控主要是将维护的质量模型通过设定分析方案、分析规则、扫描监控、数据质量信息、审核，确定通过定义周期实现执行风险模型自动扫描，最总成果为数据质量信息。分析方案可以维护自动治理规则或者选择人工质量，需要有自动的监听执行功能和高效能的分析引擎。分析监控的主要流程图如下：

2.2.3 任务统筹需求

任务统筹实现对审核通过的数据质量信息，进行任务统筹下发，主要存在多任务的合并和逐级下发功能。处理好任务统筹，就需要对市、区县、分局三级的用户人员功能进行操作，任务统筹可以分为主要以下环节：任务定义、任务下发、任务接收、任务合并、任务分配，通过分析可以树立出目前任务统筹的一个整体流程如下：

2.2.4 质量治理需求

质量治理是最后管控过程的最后一道环节，主要操作对象是科所级的用户操作。质量治理在方式上要提供给用户任务办理和处置的页面，同时要有对处置结果的检测功能，确保治理后的效果。同时考虑业务上的需求，该模块还需要具有审核流程和办结等处理。所以梳理的质量治理需求流程图如下：

2.2.5 成果分析需求

1. 过程跟踪

主要实现质量管控各个环节的成果进行统计跟踪，包括模型体系的指标元、指标、模型的建立数量；分析监控的方案、扫描分析、数据质量数据等；任务制发、流转、超限的过程跟踪；治理的进度和成果进行跟踪。

2. 效应分析

主要是对治理前的数据质量问题和治理后数据质量问题进行宏观比对，通过比对算法，对不同业务指标的计算准确性等从治理前到治理后对比，对治理前后

的数据质量问题遗漏情况进行比对效应分析。通过这些分析，验证业务系统完整性，不断对质量模型进行优化。

2.2.6 分析预警需求

数据质量管控系统处理结果的积累上，可将数据质量管控结果作为知识积累，一方面对大量的质量数据进行分析，找出问题突出的数据质量问题和来源，有方向有侧重点的在某些行业某些区域加大数据质量管控，进行宏观的辅助决策。其次，利用整个质量管控知识库，可以根据业务数据依赖规则、数理统计、二八原理、人工智能算法等进行潜在的数据质量问题预警，提高数据质量管控的持续深入发展。核心的业务可以从分析和预警两个方面考虑：

1. 数据质量管控结果分析的分时间、税务机关、分质量模型、分行业等维度进行宏观分析，找出问题突发区域，进行辅助决策。

2. 潜在数据质量问题的预警，依赖进行预警值测算和人工智能算法等方式进行分析，进行潜在关联的数据质量问题预警。

2.2.7 系统管理需求

系统管理主要是确保系统有独立的权限控制系统和运维监控功能，主要分为权限管理和日志管理两方面，对系统安全和优化提供监控数据。

1. 用户、岗位、角色管理，进行系统用户密码、身份的维护；

2. 日志管理，监控系统登录日志、菜单访问日志、系统报错日志、流量监控日志的查询监控。

2.3 功能需求

本章节采用UML建模中的用例建模来分析业务需求中的需要包含的系统功能需求分析。参照系统角色分析，系统中的用户可按照角色对应分别为：质量模型维护和分析监控管理工作交由各级信息中心技术人员操作；任务统筹环节，由各级机关设置专门的数据质量管控专员负责各级任务接收流转；质量治理主要有各业务处室的业务操作人员执行；成果分析用户和分析预警用户主要提供给各层级机关局领导使用，进行宏观辅助决策工作使用；设定单独的专人做系统管理员。所以该系统的所有用户为：技术人员、管控专员、业务操作人员、局领导和系统管理员。以下是对系统流程中核心功能模块的功能需求分析，如下图（系统整体

用例图）。

局领导

2.3.1 模型体系管理

质量模型体系在功能上是要将业务上的数据质量规则和要求，通过系统功能进行实现定义出来，分别建立功能点来实现对接层、逻辑层和规则层的功能，所以该模块在功能上可以分为指标元管理、指标管理、模型管理三个功能来实现。

技术人员

2.3.1.1 指标元维护

指标元维护在功能上主要将数据层到应用层的对接，是将来源数据表的字段定义成可视化的业务名词，是对底层数据库到业务层的名词对照关系维护，指标元维护的主要功能有：指标元新增、指标元修改、指标元移除、指标元导出、批量新增和指标元检测等主要用例，如下图所示：

技术人员

表2-1 指标元维护用例表

2.3.1.2 指标维护

指标维护功能对照业务需求质量模型的逻辑层维护功能，是将业务指标的加工规则公式和部分数据函数基于指标元定义出来。指标维护的主要功能有：指标维护、指标修改、指标移除、指标导出、批量维护和指标检测等主要用例，如下图所示：

表2-2 指标维护用例表

2.3.1.3 模型维护

模型维护功能对照业务需求质量模型的规则层维护功能，基于指标，定义出来数据质量业务判断过滤的逻辑规则。模型维护的主要功能有：模型维护、模型修改、模型移除、模型检查等主要用例，如下图所示：

表2-3 模型维护用例表

2.3.2 分析监控管理 2.3.2.1 管控方案管理

监控方案管理是设置出数据质量监控的数据范围和执行规则，包括所使用的质量模型、分析期间、是否周期扫描、行业、税务机关、清理规则等。主要功能用例如下：

表2-4 监控方案维护用例表

2.3.2.1 扫描监控管理

扫描监控主要是按照维护的质量模型规则和方案规则进行自动化的监控分析，包括触发开始时间、结束时间、异常信息、结果信息等。扫描监控功能上需要实现一个高能效的分析引擎来保障自动调度和智能算法解析扫描，具体功能如下：

表2-4 扫描监控维护用例表

2.3.3 任务统筹管理

任务统筹管理功能是实现了将数据质量问题清单通过任务流转方式，最终确定治理人员和质量方式，确保管控流程闭环。主要功能实现省、市、（县）区、科所人员间的任务流转，实现数据治理任务流转到具体的处置人员。主要的功能用例如下：

表2-4 任务统筹维护用例表

2.3.4 数据质量治理

数据质量治理主要是在确定人员和确定方式后，对数据质量问题进行清理，清理后进行下规则检测，确保数据清理的正确性。主要功能包括异常数据清理和规则检验、提交审核、办结处理。

异常数据清洗、清理、验证。

表2-4 数据质量治理用例表

2.3.5 管控成果分析

在系统实现数据质量管控的流程环节基础上，对各个环节的过程成果和过程情况进行分析和跟踪，含跟踪管理和效应分析，主要功能用例如下：

表2-4 管控成果分析用例表

2.3.6 分析预警

分析预警主要包括两部分功能，包括宏观分析和潜在数据质量问题预警，提供给管理者辅助决策信息。宏观分析包括分税务机关、分行业、分质量模型等多维度的成果查询统计分析。数据质量预警主要通过预警算法维护、预警值测算和监控预警。具体的分析预警用例如下：

分税种、分行业、分月份、分事项等；

表2-4 分析预警用例表

2.3.7 系统管理

系统管理主要功能为权限管理和日志管理两个模块内容，权限管理功能包括用户管理、角色管理、岗位管理，日志管理主要是用户登录情况日志监控、菜单访问日志、系统报错日志、流量监控日志的日志监控功能。具体用例如下：

表2-4 系统管理用例表

2.4 非功能需求

2.4.1

性能需求

数据质量管控系统用户对象为所有内部税务人员，全局税务人员6000名，其中主要的用户群体为信息中心负责数据运维人员使用，预计全局使用用户为1000名。按照目前的规模评估用户并峰值在100左右。系统登录性能要求为平均登录响应时长不能超过5s，最长不能超过10s。系统核心是对大数据的质量监控，核心的性能问题会集中在数据统计和模型分析引擎的执行性能，既包括分析引擎对服务器的资源占用，分析过程对数据库的资源占用。性能过程需对应用服务器和数据库服务均进行性能监控和优化，服务器的CPU占用不能高于60%，内存占用不超过70%。

其他具体系统模块的性能要求如下：查询类业务性能要求：

分析型业务性能要求：

2.4.2 安全性需求

系统接入安全：

1、渠道安全：应用系统对所有的接入渠道进行渠道安全校验，只有被许可的接入渠道才能接入应用系统。

2、身份认证：应用系统对所有的接入渠道需要通过口令认证方式进行身份认证，只有被许可的接入渠道及提供正确的口令才能使用应用系统提供的服务。

3、权限控制：应用系统对所有的接入交易请求根据渠道进行权限控制，只有被许可的渠道接入及被允许的交易请求才能正常使用应用系统提供的服务。

系统数据安全：

1、传输安全：关键数据在传输过程中，必须加密传输，以保证数据的传输安全性。

2、存储安全：根据国家税务局等级保护三级要求，应用系统必须保证数据的存储安全。因此，在税务局内部网络环境下，必须将与业务相关的数据保存在税务局内网区域（核心区域）。 2.4.3

可扩展性需求

系统应能适应税务数据应用需求复杂多变的要求，考虑未来 3-5 年的可扩展性，采用构件化设计思想，系统框架与业务逻辑分离，具备开放的可扩展体系

结构，支持在线升级和扩展，支持多用户和并行访问。系统的设计应确保在用户

系统保存已有和未来至少五年的（共十年以上）最明细的业务数据。进入数据仓库的数据应与生产系统中的数据保持一致。经过数据清洗、装载、查询、展现后为用户提供准确的数据。 2.4.4

其他技术需求

建立统一的数据模型标准。技术框架采用J2EE架构，JAVA语言为主要开发语言，基于B/S(Browser/Web Server)和关系型数据库方式实现。具体需求如下：系统后台采用WINDOWS SERVER、UNIX 等平台、WEBLOGIC等应用服务和 ORACLE大型数据库。

第3章系统设计

3.1 应用体系设计

根据总体设计，操作型业务与分析型业务需要进行分离设计。本系统的模块可划分如下：

3.1.1操作型业务

操作型业务设计以生命周期管理为核心，以工作流的驱动方式执行全流程的闭环控制管理。

本子系统的操作型业务有模型体系管理告、任务统筹管理、数据质量治理等业务。

下面重点阐述管控生命周期管理，其它模块的设计重点为数据模型设计，将在数据体系结构中展开。

1. 数据质量管控的生命周期管理如下图所示：

数据质量扫描得到的扫描疑点的明细信息，进入数据信息库。 ? 处理

数据扫描疑点明细信息，需要进入疑点风险评价环节，该环节是疑点信息量化的主要步骤，将通过排序等手段，生成疑点数据等级等信息。

? 消除

数据疑点信息在应对完毕之后，通过应对系统的反馈，消除该数据疑点信息。 2. 数据质量管理闭环控制

数据质量管控管理是一个闭环操作，围绕数据疑点管理战略目标实施，通过疑点数据识别、分析、评价、应对、管理全程监控及结果评估构成闭环，同时通

过不断的监控、分析报告对整个管理过程进行持续改进。

闭环需要较为完备的流程控制，以上描述的生命周期管理，将以工作流的驱动方式进行管理，工作流程图如下所示：

说明：

综合分析数据质量管控的主要功能模块，以及数据质量管控与其他子系统的关联使用，得到以下体系结构图：

数据质量管控体系结构图

说明：

1. 总体技术架构

公司的技术架构，包含前端、web、框架、通信各个层面解决手段。 2. 指标管理平台

数据质量管控基于指标管理平台设计，指标管理平台提供丰富的支撑功能。 3. 核心服务

系统的核心服务，如组件管理，运维管理等。 4. 业务逻辑层

业务逻辑的封装，隔离底层与界面层的交互。 5. Web应用功能 1) 界面层

数据质量管控主要分为7个模块：

6. 接口

数据质量管控的接口层，与外部系统的接口都在此层面规划。

3.1.2分析型业务

数据质量管控的分析型业务主要有指标预警值测算和风险扫描等，这两个业务都是依赖指标管理平台，如下图所示：

指标预警值测算是数据扫描的一个必要输入，在扫描过程中，可能会使用到指标的预警信息如均值、上下限等，这些都是需要事先预处理的，指标管理平台提供相关的指标测算服务。

扫描是对扫描方案的执行过程，在分解了扫描方案之后，主要的工作就是调用指标管理平台的分析引擎服务，执行相关的操作，并保存结果。

3.2 架构设计

3.2.1技术架构

本项目采用J2EE相关的架构进行开发，技术架构图如下：

架构说明：

1. 整个架构主要由客户层、中间层（web层、架构层、EJB层）、资源层组成。

2. 客户层：系统最终用户的使用界面和设备。一般为基于浏览器的瘦客户端，比如IE等；本项目中使用了SUI来实现展现效果。

3. 中间层：用户和系统之间的交互管理，提供用户层的展现逻辑和对资源层的访问接口。该层主要采用Front Controller, Request Processor, Command, View Dispatcher，DAO、工厂等设计模式来实现。本项目在WEB层使用Webfaster，在架构层使用SOA。

4. 资源层（EIS）：各种信息系统资源，在本系统中主要用到了：RDBMS(数据库)，以及文件数据容器（主要是在分析引擎中使用）。

3.2.2体系架构

界面管理模块的执行过程如下图所示：

展现层

说明：

用户通过操作界面与系统进行交互。

2. 用户操作的数据经过展现层、接口层、核心层，最终存储到数据层中。 3. 展现层包括了传统架构分层中的界面层、web层、架构层、业务逻辑层

的一部分。

4. 接口层、业务核心层是对传统业务逻辑层的进一步细化，业务核心层包

含了传统业务逻辑层的大部分内容；部分功能遵循此结构。

应用执行体系将设计期和运行期分离设计，将部分功能充分松耦合，达到灵活性、可扩展性和复用性，如下图所示：

说明：

扫描方案执行器接收到扫描方案实体对象，将对象解析后调用指标管理平台

提供的算法和子系统内部处理逻辑，完成扫描，输出扫描结果信息。

在设计期，系统只需要生成样扫描方案等内容，将这些内容存于数据库即可。在运行期，通过手动触发或者系统自动任务监听，读取并解析设计期的成果，生成相关的执行实例，调用分析引擎等工具，执行得到结果，写入执行结果相关数据库表。

方案是数据质量管控的关键数据对象，是扫描的基础，它需要满足风扫描这一动态执行功能的业务和技术两方面的要求，这个要求如果再做一个逻辑抽象，可以很直观地将方案划分为两个执行部分：方案的执行实体和方案执行参数。

除此之外，方案还要能提交到知识库与大家分享，方案可以方便展现出来。综上分析，这个关键数据对象的划分如下图所示：

执行实体指明的是扫描执行的具体业务对象、风险分析算法等内容，执行参数则是用于支撑动态执行所必须的周期频率、执行时间等参数。

更具体的设计内容见“关键设计”章节。

风险方案执行器在接收到扫描方案实体对像后，先进行对象的检测，以确定对象是否适应当前的执行环境。

检测通过之后，执行对象的解析，产生可以计算的实体对象，如指标信息，计分规则信息等。然后依据对象的类别调用不同的执行器实现类执行运算，运算过程中根据需要调用指标管理平台提供的算法，最终完成运算结果的输出。

具体实现流程如下图所示：

说明：

方案如果想正确执行，我们需要知道，方案是否适应当前的环境，因此，方案执行的时候系统将自动触发方案的检测，方案的检测产物主要是方案的检测状态和检测报告。

扫描方案的实体对象在检测通过之后，进入分解环节，该环节主要的分解结果是模型、指标和运行所需的参数。任务监听程序会监听运行参数，在合适的时候启动扫描流程。

扫描方案执行流程中，首先要处理的就是分解环节的模型、指标信息，这是风险扫描的关键所在，预处理通过之后才执行相关的处理流程。

3.3 数据体系设计

3.3.1 概念模型

在设计数据模型时，必须从基于合乎业务基本原理的业务规则出发，根据业务内涵来设计数据存储的模型。这点能够大大提升单位数据的处理效率，是有效解决该问题的基础。合理的数据分层规划和数据分布设计，能够更好的理顺数据间的关系，从而可以简化数据的存储、数据的处理，从而提升效率。在设计数据模型时必须遵循以下原则：

? 完整性原则：全面覆盖税务业务

? 稳定性原则：实现在保持全局稳定的前提下的持续改进 ? 适应性原则：适应各个层级、不同用户的需求 ? 高效性原则：实现数据的高效访问

数据质量管控的概念模型设计，主要是从业务处理流程展开，并考虑辅助系统的其他必须数据，总体概念模型设计如下图：

说明：

4 数据质量疑点识别的核心是数据特征库，主要包含数据指标与模型，其中疑

点数据特征指标，在获取指标管理平台的指标相关基本属性之外，还享有数据管理所需专用属性。

5 指标预警值是指标预处理的结果，供后续数据疑点分析环节使用。 6 疑点数据分析方案是分析的基础，是风险疑点数据扫描的支撑。 7 人员权限信息，用于管理系统的人员权限控制。 8 监控信息，保存系统运维的监控数据。

9 日志记录，数据质量分析流程相关处理操作统一保存在日志信息实体中，便

于操作查看和追溯。

10 配置控制，数据质量管理业务处理过程中将一些系统参数信息保存到配置信

息实体中，方便修改维护。

3.3.3 数据结构

表分类说明

平台的数据库表可分为以下几类：

在数据质量管控系统中，分析监控是最核心的业务功能需求，包括方案定义维护和分析监考，这2块的数据库设计如下图：

模型体系及分析监控

3.4 部署体系设计

3.4.1 部署结构图设计

管理部署结构如下图所示：

部署风险管理应用服务器、文件服务器、缓存服务器，数据库服务器。部署策略如下：

1. 数据管控管理应用服务器：管理应用完成界面和流程类操作。 2. 数据库服务器：数据库分为：数据仓库，风险管理库，指标管理库，统

一权限库。

3. 缓存服务器集群：负责存在子系统产生的实体数据对象。

4. 监听服务器：风险系统所有的监听服务独立部署一个但节点的应用。 3.4.2 部署硬件设计建议配置如下：

3.5 模块设计

3.5.1 模块功能结构

通过对业务需求和业务架构梳理，归纳数据质量管控功能模块框架。数据质量管控功能模块框架总体上分为三大部分，一部分是数据质量管控业务流程实现部分，其中包括数据疑点识别、疑点分析、数据疑点评价；第二部分是应对管理部分，其中包括应对管理、疑点处置；第三部分是质效评价。从界面模块以及后台模块角度考虑，得到以下模块结构图：

【电子税务局毕业论文】相关文章：

税务局电子档案管理工作经验交流材料04-29

税务局介绍信01-23