gta3手机版攻略:构建税收数据省局大集中分析展现平台的研究

    构建税收数据省局大集中分析展现平台是税务系统信息化建设从低级向高级发展的必然选择，是当前全国税务系统都在积极研究与探索的一个重要课题。构建税收数据省局大集中分析展现平台指将各级税务机关的税收征管数据通过网络集中到省税务局，并通过数据仓库（IT）等技术手段对集中后形成的海量数据进行有效地分类处理，实现省税务局对全省税务系统税收数据的分析利用和宏观展现，为决策支持服务。构建平台要区分两种情况，一种是省局已经实现生产数据大集中。这种情况下所有的生产数据都集中存储在省局数据中心，所有的数据指标定义都一致，构建平台只需将数据通过建立数据集市模型导入数据仓库中就可实现，技术较为简单。另一种情况是省局没有实现生产数据大集中，这种情况下税收数据分散存储在地市级或县级数据库中，数据指标定义也不尽相同，构建平台需先进行数据复制、抽取和代码转换，然后才能通过建立数据集市模型导入数据仓库，技术较为复杂。我区地税的目前的情况是核心征管系统为地市级集中，数据生产存储在在各地市，符合第二种情况。本文从我区地税的现状出发，探讨构建我区地税税收数据省局大集中分析展现平台的有效途径。
    一、自治区局数据中心建设
    自治区局数据中心是全区地税数据集中的载体，其功能是将全区各市分散的数据自动实时集中到自治区局数据库中，进行数据分类、代码转化等数据清洗工作，然后按数据分析统计及展现的维度汇总到数据仓库中。自治区局数据中心建设包括数据集中架构设计；标准数据指标体系建设；ODS（操作型数据存储）数据库设计和建设；DW（数据仓库）设计和建设；ETL（数据抽取、转换、加载）过程设计和建设等几个方面内容。其中关键之处在于四个方面：一是采取合适的技术架构保证数据集中的实时性；二是建立一套标准的数据指标体系；三是ETL过程设计；四是数据仓库设计。
    （一）数据集中采用的技术架构设计。
    数据集中的过程有很多种方式可以实现，例如基于数据库复制的方式、基于存储复制的方式等等。经过对各种技术的了解和研究，我区地税较适合使用基于SYBASE Replication Server（SYBASE复制服务器）的复制技术实现数据的实时集中，其理由有下列几点：
    1.我区地税核心征管系统《广西地税信息系统》使用的数据库是SYBASE ASE数据库，SYBASE复制技术和SYBASE ASE技术同源，结合度高，可靠性好。
    2.Sybase复制服务器作为Sybase公司产品系列的重要组件，构成了在世界范围内的企业级用户/服务器数据分布环境的基础。复制服务器可以解决用户在分布式运作和分布式数据环境下的六个最重要的需求：
    （1）高可用的数据：数据分布通过可靠的复制服务器架构减少计算机系统失败的对业务系统的影响。
    （2）一致的信息传送：复制服务器传送信息同时保持数据事务完整性。
    （3）高性能：复制服务器不增加要复制的数据源负担，通过智能路由利用网络资源，并且允许各节点优化访问复制数据。
    （4）简单的集中管理：复制服务器包括强大的系统管理工具、复制服务器管理器（RSM）。从单一节点，利用图形用户界面、RSM允许管理员监视和管理复制系统的各个部件。
    （5）异构数据来源存取：复制服务器结合Sybase公司Open Server/Open Client和OMNI服务器技术允许用户从非Sybase的数据源复制数据。
    （6）本地自治：每个Sybase复制环境中的节点自由的决定哪些数据需要接收，怎样查看数据，怎样编辑数据。
    3.SYBASE复制技术在我区地税系统已成功的运用了5年多，技术上是比较成熟和稳定的。在全国采用SYBASE复制技术实现数据集中的成功案例有很多，如广东工商、湖北地税等等。
    （二）建立标准的数据指标体系。
    由于我区地税的核心征管系统《广西地税信息系统》是地市级集中，因此数据指标各地市有一部分数据指标定义不一致，不能够满足代码唯一性的要求，集中后会导致数据混乱。另外，数据集中需要从其他业务系统中抽取数据，如《地方税纳税人数据采集和报送平台》、《建筑房地产营业税项目管理系统》等等，这些系统的数据指标定义也自成体系，也不能直接抽取过来使用。因此，必须建立一套全区地税系统统一的代码规范体系设计。设计的原则和方法如下：
    1.应尽量遵循国家税务总局制定的税务信息代码标准。目前，关于数据采集和交换接口方面，国家税务总局制定了国家税务总局SW 5001-2005标准体系，我区地税系统的代码设置涉及到这方面的标准应遵照执行。
    2.建立全区地税统一定义的代码库，包括税务机关、税务人员、行业、经济性质、预算级次等所有需要统一定义的代码。这些代码的设计既要满足目前的工作需要，又要有前瞻性和扩展性。
    3.对需要抽取数据的数据库，其系统代码如果与统一定义的代码表存在歧义，就需要建立相应的代码对照表，以便在ETL过程中将数据转化为统一的含义。
    （三）数据ETL过程设计。
    通常数据ETL过程分为抽取、清洗、转换、装载几个步骤：
    抽取主要是针对各个业务系统及不同网点的分散数据，充分理解数据定义后，规划需要的数据源及数据定义，制定可操作的数据源，制定增量抽取的定义。
    清洗主要是针对系统的各个环节可能出现的数据二义性、重复、不完整、违反业务规则等问题，允许通过试抽取，将有问题的纪录先剔除出来，根据实际情况调整相应的清洗操作。
    转换主要是针对数据仓库建立的模型，通过一系列的转换来实现将数据从业务模型到分析模型，通过内建的库函数、自定义脚本或其他的扩展方式，实现了各种复杂的转换，并且支持调试环境，清楚的监控数据转换的状态。
    装载主要是将经过转换的数据装载到数据仓库里面，可以通过数据文件直接装载或直连数据库的方式来进行数据装载，可以充分体现高效性。在应用的时候可以随时调整数据抽取工作的运行方式，可以灵活的集成到其他管理系统中。
    数据ETL过程可以直接编写程序或者利用数据库的存储过程来完成，但这种方式开发效率较低，维护困难，不适合经常性大数据量的数据ETL过程。必须使用合适的ETL开发工具提高系统开发的集成度和可维护性，对ETL工具的技术要求如下：
    （1）必须是成熟的商业化产品，有10年以上的产品历史和研发历史，在国内外都有大量成功案例。
    （2）ETL支持主流硬件平台和操作系统，如Windows、AIX、UNIX、Linux等；
    （3）支持多种数据库接口，支持多数据源和目标；支持Oracle， SQL Server，Sybase，Informix， DB2五大数据库的专用数据库驱动接口；支持包括文件在内的广泛数据源，以及各种应用系统如SAP；Peoplesoft； Siebel，适应不断的变化。支持消息队列、Domino以及Web Service应用接口；
    （4）ETL处理过程对数据源系统的影响应尽可能的小；
    （5）支持多个不同物理地址的数据源并行高速数据抽取；
    （6）ETL软件部署支持集群功能，能够充分利用集群的并行能力，提供作业的运行效率；
    （7）提供独立的数据处理引擎，不占用数据库资源。支持网格计算，性能无限可扩展；
    （8）提供图形化的操作界面，不需编程，通过鼠标拖拽方式即可实现自定义的ETL过程；
    （9）具有很好的版本管理的功能，无论是图形的job还是整个工程，都可以管理，而且发布只读的版本到生产环境，确保团队共同开发时对最新版本的维护；
    （10）提供图形化应用；
    （11）字符集支持：处理过程支持各种字符集的转换，支持双字节的中文汉字内码与三字节的Unicode之间的直接数据交换；
    （12）支持多步骤流水线的管道处理能力，上一步骤的处理结果无需落地存储即可作为下一步骤的数据输入；
    （13）提供预置函数和组件，对多种常用函数都提供现成的函数或选项，提供现成的函数来支持key的生成。
    （14）设计界面中，直接可以检测到速度。允许一次设计，多次执行；
    （15）应具有完善的元数据管理功能，动态元数据分析，包括差异分析、冲突分析和世系分析；
    （16）ETL软件必须包括有统一调度、监控和管理的功能，具有完整的日志管理和数据审计功能，并且有相关的图形化的监控预警机制；
    （17）能对每一个ETL过程进行严密的监控，包括数据处理的流程到了哪一步，每一步处理了多少数据，性能参数是多少；
    （18）具备错误监控处理机制，可以对交互的过程和状态进行监控，支持失败时的错误恢复等，完备的错误日志；
    （19）支持完整的备份恢复功能，支持一个工程或单个作业的恢复备份；
    （20）数据抽取过程支持增量抽取、完全抽取等抽取策略，对于数据源系统支持异步抽取或同步抽取；
    （21）线性开发，并行配置；数据抽取和转换过程支持并行处理，除了SMP结构外还支持MPP和cluster架构。
    （22）支持SOA架构（图略）。
    根据上述要求，我们选择IBM DataStage作为本次开发的ETL工具。
    （四）ODS数据库设计
    ODS（OperationalDataStore）为数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征与OLTP系统的部分特征，它为“面向主题的、集成的、当前或接近当前的、不断变化的”数据。增加ODS数据库有如下几个作用：
    1.在业务系统与数据仓库之间形成一个隔离层
    一般的数据仓库应用系统均具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不为一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上均与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。
    2.转移一部分业务系统细节查询的功能
    在数据仓库建立之前，大量的报表、分析为由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面均保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。
    3.完成数据仓库中不能完成的一些功能
    一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能，因此操作数据存储（ODS）是用于支持企业日常的全局应用的数据集合，ODS的数据具有面向主题、集成的、可变的和数据是当前的或是接近当前的4个基本特征。同样也可以看出ODS是介于DB和DW之间的一种数据存储技术，和原来面向应用的分散的DB相比，ODS中的数据组织方式和数据仓库（DW）一样也是面向主题的和集成的，所以对进入ODS的数据也象进入数据仓库的数据一样进行集成处理。另外ODS只是存放当前或接近当前的数据，如果需要的话还可以对ODS中的数据进行增、删和更新等操作，虽然DW中的数据也是面向主题和集成的，但这些数据一般不进行修改，所以ODS和DW的区别主要体现数据的可变性、当前性、稳定性、汇总度上。
    由于ODS仍然存储在普通的关系数据库中，出于性能、存储和备份恢复等数据库的角度以及对源数据库的性能影响角度，ODS不宜保存相当长周期的数据，同样ODS中的数据也尽量不做转换，而是原封不动地与业务数据库保持一致。即ODS只是业务数据库的一个备份或者映像，目的是为了使数据仓库的处理和决策支持要求与OLTP系统（联机事务处理系统）相隔离，减少决策支持要求对OLTP系统的影响。
    ODS设计与DW设计在着眼点上有所不同，ODS重点考虑业务系统数据为什么样子的，关系怎样，在业务流程处理的哪个环节，以及数据抽取接口等问题。
    （五）数据仓库设计
    “数据仓库之父”William H.Inmon先生在其《建立数据仓库》一书中定义了数据仓库的概念，随后又给出了更为精确的定义：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。与其他数据库应用不同的是，数据仓库更像一种过程，对分布在信息系统内部各处的业务数据的整合、加工和分析的过程。因此，数据仓库是一个环境，而不是一个产品；数据仓库是一个过程，而不是一个项目。
    传统的数据库技术是以单一的数据资源，即数据库为中心，进行事务处理、批处理、决策分析等各种数据处理工作，主要的划分为两大类：操作型处理和分析型处理（或信息型处理）。操作型处理也叫事务处理，是指对数据库联机的日常操作，通常是对一个或一组纪录的查询和修改，主要针对特定的应用服务，注重响应时间，数据的安全性和完整性；分析型处理则用于管理人员的决策分析，经常要访问大量的历史数据。而传统数据库系统优于日常事务的处理工作，而难于实现对数据分析处理要求，已经无法满足数据处理多样化的要求。操作型处理和分析型处理的分离成为必然。数据仓库最根本的特点是物理地存放数据，而且这些数据并不是最新的、专有的，而是来源于其它数据库的。
    数据仓库的建立并不是要取代数据库，它要建立在一个较全面和完善的信息应用的基础上，用于支持高层决策分析，而事务处理数据库在企业的信息环境中承担的是日常操作性的任务。数据仓库是数据库技术的一种新的应用，而且到目前为止，数据仓库还是用关系数据库管理系统来管理其中的数据。数据仓库系统包括：①数据仓库技术；②联机分析处理技术（On-Line Analytical Processing，简称OLAP）；③数据挖掘技术（Data Mining，简称DM）。
    税务信息的数据仓库解决方案有很多种，比如ORACLE公司的数据仓库解决方案；INFORMIXGONGSI的公司的数据仓库解决方案；Sybase公司的交互式数据仓库解决方案等等。
    SYBASE公司专门针对对海量数据进行复杂查询统计等应用而开发的数据库引擎－SYBASE IQ以独创的体系架构以及占据压倒性优势的测试效果是我区地税数据仓库系统的最佳选择。SYBASE IQ优势主要体现在以下几个方面：
    首先，SYBASE IQ与传统的关系型数据库最大的不同也是最强的优势在于SYBASE IQ是按列而不是按行存储和访问表数据。决策处理中的很多查询只需要很少量的列数据，因而与传统的RDBMS相比，这种方法在选择满足查询条件的数据时，只须涉及到很少的数据页面。
    其二，按列存储数据时由于相邻接的字段值具有相同的数据类型，所以使SYBASEIQ更容易对数据作压缩处理。但在传统的按行存储数据的情况下，就不可能有这样的效果，因为列与列之间数据类型通常是不同的。数据压缩的另一好处，是经去规范化处理而形成的表不会对磁盘空间有过量的要求，因为重复的数据经压缩实际上就消除了。数据的列式存储所带来的另一好处，是当需要一列新数据时不会引起数据库结构的改变，而对于很多传统的RDBMS而言，在这种情况下数据库结构的改变恰恰是免不了的事。
    其三，比特式（bit-wise）索引及相应的压缩技术是Sybase的一项专利。SYBASEIQ运用这一技术对数据仓库中的所有字段建索引，由此不仅带来查询效率的大幅度提高，而且还降低了对磁盘空间的占用。
    （六）实施步骤
    1.数据准确性监测
    明确数据是否准确，这是我们在构建决策支持系统对数据准确性的要求。准确的东西需要一个标准，但首先要保证这个标准是准确的。
    数据的不准确主要由以下原因产生，首先在数据源那里，可以分为下面几类：
    （1）数据格式错误。例如缺失数据、数据值超出范围或是数据格式非法等。要知道对于同样处理大数据量的数据源系统，他们通常会舍弃一些数据库自身的检查机制，例如字段约束等。他们尽可能将数据检查在入库前保证，但是这一点是很难确保的。这类情况诸如身份证号码、手机号、非日期类型的日期字段等。
    （2）数据一致性。同样，数据源系统为了性能的考虑，会在一定程度上舍弃外键约束，这通常会导致数据不一致。例如在表中会出现一个用户表中没有的用户ID，在例如有些代码在代码表中找不到等。
    （3）业务逻辑的合理性。这一点很难说对与错。通常，数据源系统的设计并不是非常严谨，例如让用户开户日期晚于用户销户日期都是有可能发生的，一个用户表中存在多个用户ID也是有可能发生的。
    在ETL过程要有处理这些质量有问题数据的保证。一定要正面这些脏数据，是丢弃还是处理，无法逃避。如果没有质量保证，那么在这个过程中，错误会逐渐放大。
    再者是ETL过程中下列因素对数据准确性会产生重大影响。
    （1）规则描述错误。上面提到对设计人员对数据源系统理解的不充分，导致规则理解错误，这是一方面。另一方面，是规则的描述，如果无二义性地描述规则也是要探求的一个课题。规则是依附于目标字段的，在探求之三中，提到规则的分类。但是规则总不能总是用文字描述，必须有严格的数学表达方式。我甚至想过，如果设计人员能够使用某种规则语言来描述，那么我们的ETL单元就可以自动生成、同步，省去很多手工操作了。
    （2）ETL开发错误。即时规则很明确，ETL开发的过程中也会发生一些错误，例如逻辑错误、书写错误等。例如对于一个分段值，开区间闭区间是需要指定的，但是常常开发人员没注意，一个大于等于号写成大于号就导致数据错误。
    （3）人为处理错误。在整体ETL流程没有完成之前，为了图省事，通常会手工运行ETL过程，这其中一个重大的问题就是你不会按照正常流程去运行了，而是按照自己的理解去运行，发生的错误可能是误删了数据、重复装载数据等。
    目前我们系统数据准确的标准只能是国库返回的入库数。通过同国库返回的电子、纸质数据的对帐，我们发现国库的电子数据仍然存在一些错误，针对这些错误，我们已经向区国库反映，并得到了解决，这样我们就以这个数据作为我们系统入库数的标准，在以此为依据建立一个对帐功能来核实我们数据的准确性，并制定相关的制度确保数据的准确。
    2.ODS数据库建设
    在数据仓库设计方法与信息模型建模方法中，前人的著作对各种思路与方法均做过大量的研究与对比，重点集中在ER模型与维模型的比较与应用上。根据咱们的实践经验，ER模型与维模型在数据仓库设计中并非绝对对立，尤其在ODS设计上，从宏观的角度来看数据之间的关系，以ER模型最为清晰，但从实现出来的数据结构上看，用维模型更加符合实际的需要。因此孤立地看ER模型或者维模型均缺乏科学客观的精神，需要从具体应用上去考虑怎样应用不同的设计方法，但目标为一定的，就是要能够把企业的数据从宏观到微观能够清晰表达，并且能够实现出来。
    基于上述研究，我们在复制服务器和DW（数据仓库）之间增加一个ODS数据库，这个数据库主要存放下列数据：1、新建立的所有的标准代码库和对应不同系统的代码对照表。2、数据集中起来的生产数据库中的核心数据表，如户籍库中的SWDJB，NSRBCGLZL等表，申报库中的SBZBJG、SJYDB等表。利用ETL工具将所有生产的数据集中到一起，按原有的数据结构原原本本的保存。3、按照便于增量统计和分析利用的原则，对原始生产数据表结构进行拆分，生成新的数据库表，如将SJYDB拆分成入库表（SB_ZSXX）、减免税表（SB_JMXX）、提退表（SB_TTXX），SBZBJG拆分成申报表、欠税表、开票表等等。
    3.数据仓库建设
    第一步：确定数据范围
    确定数据范围实际上为对ODS进行主题划分的过程，这种划分为基于对业务系统的调研的基础上而进行的，并不十分关心整个数据仓库系统上端应用需求，但是需要把上端应用需求与ODS数据范围进行验证，以确保应用所需的数据均已经从业务系统中抽取出来，并且得到了很好的组织。一般来讲，主题的划分为以业务系统的信息模型为依据的，设计者需要综合各种业务系统的信息模型，并进行宏观的归并，得到企业范围内的高层数据视图，并加以抽象，划定几个逻辑的数据主题范围。在这个阶段，以ER模型表示数据主题关系最为恰当。
    第二步：根据数据范围进行进一步的数据分析与主题定义。在第一步中定义出来了企业范围内的高层数据视图，以及所收集到的各种业务系统的资料，在这一步中，需要对大的数据主题进行分解，并进行主题定义，直到每个主题能够直接对应一个主题数据模型为止。在这个阶段，将把第一步生成的每个ER图中的实体进行分解，分解的结果仍以ER表示为佳。
    第三步：定义主题元素。定义维、度量、主题、粒度、存储期限，定义维的概念特性：维名称，名称应该能够清晰表示出这个维的业务含义。维成员，也就是这个维所代表的具体的数据。维层次，维成员之间的隶属与包含的层次关系，每个层次需要定义名称。定义度量的概念特性：度量名称，名称应该能够清晰标书这个度量的业务含义。定义主题的概念特性：主题名称与含义，说明该主题主要包含哪些数据，用于什么分析；主题所包含的维与度量；主题的事实表，以及事实表的数据。定义粒度：主题中事实表的数据粒度说明，这种粒度可以通过对维的层次限制加以说明，也可以通过对事实表数据的业务细节程度进行说明。定义存储期限：主题中事实表中的数据存储周期。
    第四步：迭代，归并维、度量的定义。
    二、数据实时展现平台建设
    （一）总体技术路线
    应用支撑平台应基于SOA架构、WebService标准，构建而成。
    1. SOA架构。SOA技术架构被誉为下一代Web服务的基础架构，SOA的目标在于让IT变得更有弹性，以更快地响应业务单位的需求，实现实时服务。它的优点是：SOA使得政务应用摆脱面向技术的解决方案的束缚，轻松应对服务变化、发展的需要；在不用修改现有系统架构的情况下，SOA可以将系统和应用迅速转换为服务；通过一组有效设计和组合的粗粒度服务，业务专家就能够有效地组合出新的业务流程和应用程序了。
    2.WebService标准。WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求，轻量级的独立的通讯技术。这种技术允许网络上的所有系统进行交互。
    3.安全保障机制：XML作为实现跨平台信息交换和提高异构系统之间的互操作性的最佳解决方案的提出，极大地促进了数据交换应用的发展。而基于XML强大的可扩展性而提出的XML安全服务标准，使我们可以在考虑XML数据信息交换的安全问题上，完全采用基于XML标准的体系结构，继承XML的灵活性和可扩展性。
    4.ESB（企业服务总线）：企业服务总线将为用户提供一个面向服务的基础架构，不但能够提高IT系统的敏捷性，而且可使用户技术部门以较低成本来满足业务需要。企业服务总线是传统中间件技术与XML、Web服务等技术结合的产物，是可以提供可靠的、有保证的消息技术的最新方法。企业服务总线能够帮助用户成功地实现应用整合平台并实施SOA，能够满足用户交互信息发布，业务流程管理，内部系统与外部机构的服务交换，数据集成和安全性的业务需求。具体应满足以下技术要求：
    （1）J2EE接口：系统的每一个组件都应提供J2EE/RMI接口供其它系统调用，同时，也应该能够调用其它J2EE系统。
    （2）WEB SERVICE接口：系统的每一个组件都应可作为一个Web服务供其它系统调用，也可调用其它WEB SERVICE界面，接口定义是WSDL.
    （3）CORBA接口：每一个组件都可应提供CORBA接口供其它系统调用，通过IDL数据接口调用其它CORBA界面。
    （4）Connector：连接器应满足J2EE/JCA标准，提供多种多样的现成连接器用以连接各种应用系统，如：
    o各种数据库：ORACLE、DB2、SQL SERVER、SYBASE、INFORMIX.
    o各种现存应用：如常用CRM/ERP等。
    o各种技术连接器：如File、HTTP、FTP、E-MAIL、SMS、SOCKET等。
    oConnector又可根据消息获取方式的不同分为两大类：
    o主动向应用系统获取数据；
    o应用系统更新数据触发事件，向Connector发布数据，Connector实时获取变更的数据。
    oConnector SDK：提供连接器开发环境包，来开发特别系统的连接器。
    根据不同的系统，可以选用适当的接口方式。集成平台主要负责插件间的流程调度。
    （二）满足数据展示实时性要求技术方案
    要满足数据展示实时性的要求，我们采取如下的技术方案：
    1.每天晚上定时用ETL工具从复制服务器和其他与纳税人征管信息有关的数据库服务器上抽取、转换所有数据至ODS（操作数据存储）数据库上。这个过程基本保持数据表结构的一致。
    2.利用ETL工具按数据仓库的模型对ODS数据进行抽取、清洗和加载，将不活动的数据迁入到IQ数据仓库服务器中去，建立不同的维度数据库，以便数据能够快速查询统计。
    3.根据数据集市的设计，预先生成到今天为止的数据的累计数。
    4.需要实时查询的数据统计分两部分：（1）当天以前的数据通过IQ数据仓库或者ODS数据库服务器中已经预加工完成的统计表进行查询统计（具体查询对象按查询条件由系统自行确定）；（2）当天的实时数据通过ETL工具对复制服务器进行实时查询统计。系统将自动的把这两部分数据叠加，实时生成动态数据。
    （三）数据分析展示
    数据查询是最简单的数据分析的应用，输出报表是最直接的产物，根据数据连接，加工过程及用途，应用模式大致可以分为四种：格式报表；在线分析；数据可视化；数据挖掘。
    1.格式报表：带格式的数据集合，如：交叉表等。
    2.在线分析：多维数据集合，如：Cube等。
    3.数据可视化：信息以尽可能多的形式展现出来，目的是使决策者通过图形这种直观的表现方式迅速获得信息中蕴藏的知识，如柱图，仪表盘等。
    4.数据挖掘：从大量的数据中，抽取出潜在的、有价值的知识（模型或规则）的过程。分析方法有下列几种：
    o分类（Classification）
    o估值（Estimation）
    o预言（Prediction）
    o相关性分组或关联规则（Affinity grouping or association rules）
    o聚集（Clustering）
    o描述和可视化（的scription and Visualization）
    数据挖掘号称能通过历史数据的分析，预测用户的行为，而事实上，用户自己可能都不明确自己下一步要作什么。所以，数据挖掘的结果，没有人们想象中神秘，它不可能是完全正确的。用户的行为是与实际环境相关连的，所以数据挖掘本身也受环境的影响。
    数据展现工具的技术要求：
    5、产品应该具有良好的整体性，通过一个产品一个服务提供完整的BI展现的功能。包括了即席查询，报表，多维分析，仪表盘等功能。
    6、前端展现产品本身应该具有良好的扩展性，产品本身就要具有负载均衡和容错保护的功能。
    7、数据展现应该具有统一的元数据模型，不需要为每个前端展现工具分别定义元数据。
    8、使用统一集中的安全认证，拥有统一的用户管理机制，统一的权限控制机制，系统所有模块之间无需复制安全性信息。
    9、产品应采用先进的SOA构架，采用纯B/S方式，不能使用插件或Applet.
    10、提供通用的C/S接口、ODBC接口、JDBC接口（至少支持JDBC接口），能够为流行的前端工具访问，数据存储本身不应对前端设计、管理和展现软件的选型构成限制；
    11、支持多种通用数据库，包括ORACLE、SYBASE、DB2、SQL SERVER等。
    12、提供高性能OLAP多维分析服务器，支持大规模并行加载和查询处理，支持以文件形式高效的存储多维立方体，支持对多维立方体进行虚拟分区。
    13、支持用户在纯浏览器界面上进行各种OLAP分析，不需要安装插件，不使用Applet，支持用户使用简单的拖拽的方式进行多角度分析。
    14、支持异构数据源访问；
    15、OLAP分析支持上钻，下钻，切片，旋转，过滤等标准的OLAP操作
    16、OLAP分析支持图表一起展现和图表联动，支持柱图，饼图，折线图，堆积图，面积图等各种常用图形
    17、支持同比，环比，百分比等各种比例分析
    18、能将报表的数据转换为仪表板进行监控分析。
    19、提供丰富的二次开发接口，支持Web Service的接口调用，支持在各个平台上，尤其是Unix平台上方便的进行二次开发。
    根据上述要求，我们选择IBM Cognos工具作为数据展示工具，它使用简单，能够定制风格的信息门户平台，具有强大的报表开发功能，数据分析功能，能够实现多维分析、上下文的钻取、KPI仪表盘展示，数据挖掘功能，报警功能等等。
    （四）实施方案基于系统现状与数据平台要求，实施方案如下：
    1.利用前端展现工具Cognos，系统提供一个灵活查询与统计功能将提供简单易用的数据查询与统计环境，适合非IT专业技术人员理解和使用，方便、准确、完整地向决策人员提供多层次的综合性信息，并能做到在中间表中查询与统计所需的信息。所有报表与分析均通过Cognos产品进行展示，用户用户端无须安装Cognos软件，只需使用浏览器即可。
    2.根据业务需求开发报表与多维分析。系统前端应用的根本用途是为各业务部门提供类型丰富的统计、分析与报表功能，为实现这一目标，前端应用包括设计定制与展现两部分。
    （1）设计定制功能是用户前端展现的基础，包括：OLAP（在线分析系统）模型定制功能。前端平台将提供基于大连港各业务与主题的OLAP多维分析功能，为实现OLAP多维分析，我们必须首先基于IQ/DataStage/COGNOS产品定制OLAP多维模型。由于构建基于广西地税完整的GXLTBI系统将是一个长期的过程，因此，我们实现广西地税吞吐量OLAP多维模型。报表模板定制功能。前端平台前端展现的最终结果是报表，这里面包括从OLAP分析、灵活查询得到的灵活报表，也包括固定格式的复杂报表（或报告）。报表模板的设计与定制，将为今后用户的报表功能提供基础。
    （2）展现功能包括：
    （a）固定报表功能。固定报表是GXLTBI查询与统计（前端展现报表或数据项）的直接输出结果。固定报表功能可以实现大连港支持业务、管理、决策等一系列工作的固定报表需求。在固定报表的实现上，可以按照重要性与紧急性的优先级排序并逐步实施。报表的展现方式：以固定的业务逻辑形式，编排报表，使用用户习惯的使用方法展现报表，包括表格、图形、打印、输出和保存等，让用户体会到固定报表展现与数据仓库系统统计分析的速度快感。
    （b）灵活查询与统计功能。前端灵活查询与统计功能将提供简单易用的数据查询与统计环境，适合非IT专业技术人员理解和使用，方便、准确、完整地向决策人员提供多层次的综合性信息，并能做到在中间表中查询与统计所需的信息。
    （c）OLAP分析功能。OLAP多维分析是前端主要数据展现和分析手段之一，企业用户通过浏览器与OLAP Service连接，快速、一致、交互地访问OLAP模型定制模块中预先定制的OLAP多维数据模型，展示多维模型各种可能的信息视图，洞察数据深处，掌握隐于其中的规律。
    定制OLAP模型处理流程如下：创建数据库（OLAP Service）->指定数据源->创建多维数据集（Cube）->创建维度（Dimension）->创建专用维度->创建共享维度->创建层次结构（Hierarchy）->创建度量（Measure）->处理数据库（加载）->定义OLAP安全角色->分配OLAP安全角色。
    3.前端应用系统设计。前端应用功能划分为若干个模块，分别包括定制、实现、展现、管理等功能。必须理解，由于所有模块均与GXLTBI前端应用有关，因此，我们同样将定制与管理等模块归结于前端应用。这些模块并非适用于所有前端用户，也并非所有前端用户都有权限去操作或使用部分模块，同时，在同一个模块中，也并非所有前端用户都拥有相同的功能。前端应用设计涵盖以下部分：（1）OLAP模型定制模块报表模型定制模块；（2）报表（报告）模板定制模块；（3）固定报表模块；（4）灵活查询与统计模块；（5）OLAP分析模块；（6）Portal集成设计；（7）前端应用权限设计。
    4.大集中分析系统界面设计
    在该界面中，右边是系统数据区，存放结果数据及进行数据组织或变换，同时可以分多页显示报表；左边是系统菜单管理器，所有查询所用到的对象都会放在管理器列表中。在工具栏上单击右键可定制工具栏，实现菜单中定义的各种报表或数据变换功能。状态栏将可以显示查询时间，查询进度，报表名等各种状态信息。
    5.大屏幕展示设计。大屏幕是数据展现的一个重要的平台。由于自治区局的大厅大屏幕不是标准分辨率（768*448），因此大屏幕的设计要针对现有大屏幕的分辨率定制，此项工作的设计比较繁琐，要确保每个页面的内容刚好能在大屏幕上全部展示出来。大屏幕的设计原则上控制在6屏以内，轮询展示。展示的内容包括：全区地税税源分布、税收收入完成情况、重点税源和重大项目监控情况等几个方面。
    作者单位：
    广西自治区地税局计算机中心

    申报人：李早春 唐运球 陈志军
            邰  阳 王其莉 何思阳
            陈品高 何  凡 朱  华
            邱忠文 梁  剑 黄  华 林  达