IBM数据仓库解决方案(简).doc

1.1 技术架构设计成功地实施一个仓库项目，通常需要很长的时间。如果仅仅着眼于短期成果，缺乏整体考虑，采用一种不健全的体系结构，不仅会增加系统开发和维护成本，而且必将对发挥数据仓库的作用造成不利的影响。因此一个综合，清晰的远景规划及技术实施蓝图将在整个项目的实施过程中起到重要作用。技术架构必须具有高度先进性和可扩展性，以满足业务需求的不断变化。一个完整的数据仓库系统包括数据源、数据转换区、数据仓库、数据集市、和数据展现层，通过数据仓库不同层次之间的加工过程，实现财政从数据资产向信息资产的转化过程。在不同层次之间的数据加工过程需要通过ETL技术实现，并对整个过程进行有效的元数据管理。基于对需求的理解，基于财政部的信息系统框架模型基础之上的财政决策支持系统技术架构如下图所示：如上图所示意，通过搭建灵活的、可扩展技术架构，在保持数据集市稳定性的同时，可以不断增加数据源，增加应用数据层、增加应用层，满足不断增加的业务分析应用需求。采用DW+ODS的数据仓库体系结构，使用全新的ETL模式对ODS进程每日数据更新，按周或月周期对数据仓库执行ETL过程。使用COGNOS BI做为前端的查询分析和数据挖掘工具，可满足各种日常数据处理操作，从即时简单报表查询到多维多级数据分析和挖掘，都能够在统一COGNOS BI平台上完成。1.1.1 数据源和数据接口数据源指存储于财政各个业务系统的业务数据，以及未来的财政监管和外部数据。数据仓库系统将整合来自于这些系统的数据，形成财政统一的、一致的基础数据集，并提供给不同的应用主题形成数据集市。各个系统在体系架构、开发平台、数据定义、接口标准都会存在不同程度的差异；另外由于业务的不断变化，历史数据与当前数据之间的含义也可能存在不同，因此数据整合必须充分考虑源系统在技术和数据方面存在的差异。数据仓库系统将采用文本文件的方式从源系统获取数据。每个源系统会就与数据仓库之间就传输数据接口文件（IFF）的格式和方法制定标准，称之为接口规范。每个数据源会首先通过各自的数据导出程序（Extractor）生成接口文件存储在各自的文件缓冲区内。这个Extractor负责各自范围内导出数据的完备性和一致性，包括：1） 依照各自的业务规则确定增量数据的导出方法2） 保证导出文件的格式符合接口规范的要求3） 保证导出文件的传输时间的及时性4） 保证接口文件的数据质量，不错数、不丢数、不多数1.1.2 财政数据仓库财政数据仓库（EDW），存储和管理来自源数据系统的数据，按照数据模型分主题进行组织和存放，包括当期的和较长时间的历史数据。数据仓库的核心是企业级数据模型的规划和设计，是所有应用的基础。接下来我们分别对EDW每个数据区域做详细介绍。1） 接口文件区接口文件区是存储和处理接口文件的区域，如前面章节所述，接口文件区在系统下按照特定的目录结构组织起来。用一些系统命令和工具来管理。对每个目录按照其特定的用途设定对不同用户的访问权限，比如谁能读，谁能写，谁能改等。2） 细节数据暂存区SSA（SOR Staging Area）SSA的主要目的是支持把接口文件的装载到数据库，对其进行验证和处理，然后把数据整合到SOR内。验证的方法主要是将新转载的数据与SOR内已有的数据进行查找和比较。SSA内数据结构的设计原则是最大限度的利用接口文件的数据结构，尽量降低实体的个数，同时很好的支持后续的ETL过程。3） 细节数据SOR（System Of Record）SOR是基于模型开发的一套符合3NF范式规范的表结构。SOR存储了数据仓库内最细节层次的数据，按照不同的主题域进一步分分类组织。此模型是整个数据仓库数据模型的核心，其设计为具有足够的灵活性，以能够应对添加更多的数据源，支持更多分析需求，同时也能够支持进一步升级和更新。为了能够在数据仓库内记录数据的变化以支持历史趋势和变化分析，SOR在一些关键的属性值上会跟踪变化（比如客户的信用度、状态等）。跟踪变化的常见方法就是利用渐变维的Type 2方法来处理记录，在表内增加一条记录变化数据的新记录。同时为了降低不必要的存储空间的浪费（相同数据的重复存储），我们可以把实体中动态变化的属性与静态不变或只需覆盖不需跟踪变化的属性分开。比如对用户，我们可以用一张表存放不变化的用户静态属性，用另一张表存放经常变化的用户行为属性，当跟踪用户行为的变化时我们只需在用户行为表内添加记录就行了，没必要把没有发生变化的用户静态表内的数据也复制一份。4） 汇总数据区Summary汇总数据区是为了方便查询和后续多维数据的更新，创建一些常用的中间汇总表，以提高性能和降低后续ETL工作的复杂性。由于SOR是高度规范化的数据，因此要完成一个查询需要大量的关联操作；同时数据集市中的数据粒度往往要比SOR高很多，对要成生数据集市所需数据也需要大量的汇总计算，因此如果我们把常用的数据预先关联和汇总好，并让其尽量多在多个数据集市的计算中共享，就能大幅度的提高整个ETL工作和数据仓库查询的性能。5） 反馈数据区（Feedback Area）反馈数据区主要记录的是数据仓库自身生成的结果。比如用户对营销活动的反馈等。数据仓库的特性决定了用户在原则上不能直接修改数据仓库中的数据，因此用户的修改数据和其它生成数据必须单独记录，以便于追踪历史和进行比较。6） 元数据存储MDR（Meta Data Repository）元数据存储用来保存关于数据仓库中的过程、数据的信息（日志、数据词典、配置信息等）。由于各个工具和系统都会生成自己的元数据，同时我们还利用元数据管理工具把这些元数据尽可能的集中存储到数据仓库中的MDR内，因此MDR总的来说只是一个共享元数据供用户集中访问的地方，真正元数据的维护地还是在生成这些元数据的系统或工具内。1.1.3 数据集市数据集市设计用途是要满足特定的目的，同时具有查询、多维分析、报表和数据挖掘功能。这与企业数据仓库截然不同，设计时企业数据仓库在信息内容与结构方面尽可能拥有开放性与灵活性。数据集市有以下特征：n 为特定用途而设计数据集市设计的目的，是支持特定用户对数据子集的特定范围的查询。它以用户所要求的方式提供企业数据仓库的细节汇总。n 优化数据集市为了支持特定工具的访问而优化。根据工具、根据企业数据仓库提供的信息子集来设计数据集市，而不是让用户直接访问企业数据仓库中的大型数据库，这可以改善数据集市的性能。n 虚拟或物理数据集市数据集市可以是物理的实现，也可以是企业数据仓库表的各种视图。使用视图（虚拟数据集市）可以避免存储数据的多个副本，简化了数据管理。数据集市，即Data Mart，指面向专项应用领域的分析主题。Data Mart即是通过OLAP技术或者数据挖掘技术，利用数据仓库的数据根据用户需求建立的数据集市模型，大大提高了前端查询访问的效率，用户能方便地实现灵活、动态、快速、多角度、多层次地分析企业数据。同时，也可以通过定制灵活的OLTP查询来了解明细数据。1.1.4 数据的抽取、转换、加载（ETL）数据仓库的数据来源于业务处理系统，但是数据仓库的数据并不是对源系统数据的简单叠加，它需要按照数据仓库的逻辑模型和物理模型，在源系统数据分析的基础上，按照源系统数据和数据仓库数据之间的映射关系，经过数据的抽取(Extraction)、转换 (Transformation)和加载(Loading)等环节方可进入数据仓库，这个过程简称为ETL处理。数据经过数据抽取、转换和加载处理进入数据仓库的整个过程可以简称为ETL过程。ETL是搭建数据仓库数据平台的基础，也是保证数据仓库的数据质量的具体实现。根据基于数据仓库项目开发的经验，在大多数据仓库的实施过程当中，ETL都是一个非常复杂、耗时的过程，其工作量约占整个数据仓库项目的40-50%，占数据仓库设计阶段工作量的70-80%，有许多原因影响这一阶段的时间和进度。比如对原有业务系统和旧的操作环境的了解有限，原系统文档不全等。因为这些原因，使ETL任务花了许多时间在了解旧的业务应用以及如何抽取数据上。ETL实施困难另一个原因是原有的系统平台没有足够的容量/系统资源来支持数据抽取处理，系统资源不足可能表现为：CPU、磁盘空间、I/O带宽或没有一个有效的窗口去运行抽取、转换程序。ETL过程不仅工作量大，而且还受到很多时间窗口的限制，它不仅需要在不同的特定（非确定）的时间抽取数据，而且还必须要在特定的时间范围内把数据加载到数据仓库。由于ETL过程是数据仓库应用系统每天都要进行的工作， ETL设计的科学性和效率性是非常重要的，关系到数据仓库项目的成败。ETL遵循如下设计原则：n 灵活性：不同的时间段中能够进行数据获取、转换、装载。n 可重复性：支持失败的ETL任务行数据重新装载。n 模块化：ETL过程分步实施，每个过程通过不同的模块组件来完成。并尽可能复用这些组件；从而提高ETL实施效率，增加数据仓库的可维护性。n 迭代方法：满足当前的业务需求，尽可能搭建满足未来的业务需求的平台上不断开发实施。n ETL逻辑顺序：依赖业务系统数据处理方式，来定义ETL处理流程控制。例如：在银行的ETL过程中，交易记录信息的数据装载应该在账户信息进入数据仓库之后进行。1.1.4.1 第一步：数据抽取在源系统上启动数据抽取控制程序，完成以下工作：1、数据采集考虑到数据来源的多样性和复杂性，数据采集主要包括：l 对业务系统的数据采集：在日终结后，当日数据自动、增量地转储到数据备份机上，作为数据仓库的数据源并成为数据备份策略的一部分。l 对于税收计划、外部数据、纳税人财务报表的数据采集。可根据实际需要，采用多种途径。2、数据发送在数据采集完成后，各系统上的抽取控制程序将数据文件和校验文件通过局域网发送到数据转换区。1.1.4.2 第二步：数据装入转换区1.检查数据是否到位根据校验文件，检查源系统数据是否到位、是否存在传输错误等异常情况。如果数据不全或传输出现错误，如果出错，将出错结果写入错误日志，重新执行第一步。2.将外部数据文件装入数据库把来自外部源数据源的格式化数据转化成数据库、表结构。3.修改系统状态：待该步骤工作完成后，将系统状态改为抽取工作完成。注：若直接从业务系统数据库中抽取数据，则无须数据转换区步骤。1.1.4.3 第三步：数据质量检查和出错处理1.状态检查：查询参数表，如果数据抽取工作已经完成，开始执行该步骤工作。2.数据质量检查：根据检查规则，数据质量检查程序扫描源数据数据表，根据规则检查数据是否合法，给出检查报告和最终的数据质量报告并写入数据库，数据质量检查结果写入质量检查报告。3.出错处理：如果出现严重出错，停止ETL工作，需要系统维护人员现场做出相应的处理，修改正确后，重新执行该步骤工作；对于警告级出错，继续进行下述步骤。4.修改系统状态：待该步骤工作完成后，将系统状态改为数据质量检查工作完成。1.1.4.4 第四步：数据转换1、状态检查查询参数表，如果数据质量检查工作已经完成，开始执行该步工作。2、数据转换根据数据仓库要求的数据源格式在Staging Area中进行并行转换处理，并将转换的结果数据存放在待装载数据存放区。3、生成转换报告记录数据转换情况，并写入数据库转换日志中。4、修改系统状态： 待该步骤工作完成后，将系统状态改为数据转换工作完成。1.1.4.5 第五步：数据加载1、状态检查查询参数表，如果数据质量检查工作已经完成，开始执行该步骤工作。2、数据装入数据仓库采用非依赖数据并行加载的策略，将待装载数据区的数据装入中心数据仓库，如果标准代码表发生变化，数据装载程序将标准代码的变化情况增量加载到数据仓库代码表中。3、数据加载情况报告记录数据加载情况，并写入数据仓库数据库的参数表中。4、修改系统状态： 待该步骤工作完成后，将系统状态改为数据转换工作完成。1.1.4.6 第六步：加载时间维1.状态检查查询参数表，如果数据加载工作已经完成，开始执行该步骤工作。2.加载时间维根据当前的时间，依据数据集市多维模型，完成时间维的加载工作。3.修改系统状态：待该步骤工作完成后，将系统状态改为时间维加载工作完成。1.1.4.7 第七步：加载事实表1.状态检查查询参数表，如果时间维加载工作已经完成，开始执行该步骤工作。2.加载事实表以数据仓库数据为数据源，依据数据集市多维模型，完成事实表的加载工作。3.修改系统状态：待该步骤工作完成后，将系统状态改为事实表加载工作完成。1.1.4.8 第八步：加载聚合表1.状态检查查询参数表，如果事实表加载工作已经完成，开始执行该步骤工作。2.加载聚合表以事实表为数据源，依据数据集市多维模型，完成聚合表的加载工作。3.修改系统状态：待该步骤工作完成后，将系统状态改为ETL工作结束。1.1.5 数据展现数据访问及展现是通过信息门户，将各类数据集市应用通过统一的平台展现给财政各类用户。同时提供数据分析结果的表达、共享与传递的功能，是信息服务的主要界面，主要包括信息展现与人机交互、信息发布等。 本次的展现选择*的报表分析平台，详细功能见附件一。1.2 数据架构设计数据仓库的体系结构包括4 个层次的数据：数据源、数据仓库层和数据集市层。1） 数据源（业务系统）包含面向操作应用的原始数据以及外部录入数据，主要服务于高性能的事务处理。2） 数据仓库层（包括ODS 和DW）存储企业的历史数据，其数据是规范的、稳定的。i. 数据仓库包含当前数据、综合数据、历史数据的组织和整理。通过数据抽取平台获取的各业务数据，从逻辑上和业务上是独立的、分散的，要实现一体化的查询功能，必须对分散的业务数据进行抽取和整合。如将分散的单位基础信息、预算数据、支出数据通过一定的策略，整理形成一套编码统一、业务连贯的数据体系，这是一体化查询系统成功的关键。3） 数据集市层（包括Relational Data Mart 和Star-Schema Data Mart 和OLAP）是面向部门的、满足最终用户需求的数据，数据集市中的数据是反规范的、汇总的。数据整理平台基于各业务数据，可以根据不同的用户查询需求，定制数据整理策略。根据查询角度的不同，按决策的主题要求形成当前的基本数据层，按综合决策的要求构成综合数据层，随着时问的推移，由时间控制机制将当前基本数据层转为历史数据层。4） 数据展现层（前端展现）是面向业务用户的需求展现，包括使用报表、多维分析、即席查询等基本功能，提供告警、统计算法等高级功能。第二章 基于基础资料系统的数据模型设计2.1 基本纬度数据模型设计“金财工程”一体化需以系统统一的数据字典和统一的编码体系为基础，以统一的应用支撑平台作保障，通过本级财政业务流程的整合，实现对任一笔资金的跟踪和回溯。为了实现对数据的集中使用，就要从需求出发，在充分考虑到数据的可共享性、系统未来的可扩展性等因素，定义一套标准数据格式，为系统的建设打下一个良好的基础。它包括各种涉及的基础编码表：如预算科目表、经济科目表、预算单位编码表、企业登记表、税种表、预算级次表等。数据字典是财政业务系统间需要统一维护管理、支持同步和共享的数据元、基础代码集、基础配置数据和相关命名规范的统称。其中数据元又称数据类型，包括定义、标识、表示以及允许值等一系列属性描述的数据单元。通常所说的业务要素就是财政业务系统中构成业务数据的比较重要的数据元，该类数据元均有相应的基础代码集。数据字典中主要包括的内容：财政业务管理涉及到的所有的数据元及共享的基础代码集；共用的用户列表；相关配置数据及系统开发需遵循的命名规范。我们将按照省厅建设的基础数据资料库来进行基本纬度模型的建设。2.2 基础资料系统维护功能模块功能模块功能说明框架单点登录多系统实现单点登录权限控制统一的功能权限控制机制日志统一的系统级、功能级、数据级操作日志选择年度选择所需要操作的年度和帐套，设置默认的年度；修改密码修改当前用户的登录系统密码；注销注销当前用户，退出系统，返回到登录页面；帮助隐藏隐藏和显示页面上方软件标题栏和左方菜单栏；基础资料创建新年度系统设置应用设置设置应用的名称以及一些基础信息；选项表设置设置选项表以及下拉菜单信息；参数设置设置各个应用的所在服务器的IP值以及一些其他的固定的参数；应用权限设置设置数据授权中的用户和单位对应用中的要素的权限是否公有；用户对账本年度设置用户与账本年度对应关系，也即用户访问账本年度的权限；缓存管理刷新缓存的功能；要素维护预算单位设置预算单位名称以及基本信息；功能科目设置功能科目名称以及基本信息；会计科目设置会计科目名称以及基本信息；经济科目设置经济科目名称以及基本信息；预算项目设置预算项目名称以及基本信息；收费项目设置收费项目名称以及基本信息；资金来源设置资金来源名称以及基本信息；指标类型设置指标类型名称以及基本信息；资金性质设置资金性质名称以及基本信息；财政归口部门设置财政归口部门名称以及基本信息；数据授权用户对预算单位设置用户与预算单位对应关系；用户对会计科目设置用户与会计科目对应关系；用户对功能科目设置用户与功能科目对应关系；用户对经济科目设置用户与经济科目对应关系；用户对预算项目设置用户与预算项目对应关系；用户对收费项目设置用户与收费项目对应关系；用户对指标类型设置用户与指标类型对应关系；用户对资金来源设置用户与资金来源对应关系；单位对会计科目设置预算单位与会计科目对应关系；单位对功能科目设置预算单位与功能科目对应关系；单位对经济科目设置预算单位与经济科目对应关系；单位对预算项目设置预算单位与预算项目对应关系；处室对单位设置财政归口部门与预算单位之间的对应关系；用户对归口设置用户与财政归口部门之间的对应关系；功能授权用户设置用户的基本信息以及用户与财政归口部门和预算单位之间的对应关系；岗位设置岗位的基本信息；功能设置功能（也即各个应用的菜单和按钮）的基本信息和链接地址等；功能转授把当前用户的功能转授给其他用户的设置；用户对岗位设置用户与岗位的对应关系；岗位对功能设置岗位与功能的对应关系；权限转授用户对会计科目把当前用户会计科目的数据权限转授给其他用户；用户对经济科目把当前用户经济科目的数据权限转授给其他用户；用户对指标类型把当前用户指标类型的数据权限转授给其他用户；用户对收费项目把当前用户收费项目的数据权限转授给其他用户；用户对预算项目把当前用户预算项目的数据权限转授给其他用户；用户对资金来源把当前用户资金来源的数据权限转授给其他用户；2.3 数据逻辑建模逻辑建模是数据仓库实施中的重要一环, 因为它能直接反映出决策者管理者的需求, 同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式(3NF, 即 Third Normal Form)和星型模式 (Star-Schema)，3NF 是数据库设计的基础理论，这里不再展开。星型模式是一种多维的数据关系,它由一个事实表(Fact Table)和一组维表(Dimension Table)组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。事实表的非主键属性称为事实 (Fact),它们一般都是数值或其他可以进行计算的数据; 而维大都是文字、时间等类型的数据，按这种方式组织好数据我们就可以按照不同的维(事实表的主键的部分或全部)来对这些事实数据进行求和(summary)、求平均(average)、计数(count)、百分比(percent)的聚集计算，甚至可以做20-80 分析。这样就可以从不同的角度数字来分析业务主题的情况，下面给出一个直观的例子。功能分类维功能分类标准码类款项业务处室维业务处室编码业务处室名称时间维时间代码年季度月单位维单位编码一级单位编码一级单位名称二级单位编码预算执行情况分析功能分类标准码业务处室编码时间代码单位编码指标金额计划金额支付金额图8-3 预算执行情况星型模型图三是一个典型的财政预算执行情况分析的模型设计，其中加边框的为主关键字(PK, Primary Key)，其中预算执行情况分析表是一个事实表，其中的指标金额，计划金额，支付金额是需要从各角度观察的数据(事实)，而观察的角度是有功能分类、业务处室、时间和单位这四个方面组合进行，这些分析角度的有机组合，可以对指标金额、计划金额和支付金额进行多种组合的数据统计分析，以此实现对预算执行情况的多角度(维)多层次(数据不同的汇总程度)的分析，预算执行情况分析人员既可以宏观地看到财政业务的整体情况，又可以微观地观察到具体某预算单位某天支出的细节信息。多维分析的时候，维度选择越多数据越细节(划分得更细了)，维度选择越少数据越汇总越宏观。这样一个中间一个大表形成主表，周围一组小表与主表相关联的结构，形态上呈星星和雪花的形状，星型模型是数据仓库的数据模型与其他数据库应用相区分的一个重要特征。星型雪花数据仓库典型的逻辑模型形状第三章 数据抽取平台建设数据转换平台是将分布式物理存储的源数据，转换到统一存储的数据仓库中。从分布式源数据库中获取对财政一体化查询系统用户有用的数据、过滤掉不需要的内容、验证数据的质量、数据清理、数据融合、到最后数据装载入数据仓库中。数据抽取是数据进入仓库的入口，财政一体化查询系统涉及多个分布式数据源，需要通过抽取过程将数据从联机事务处理系统、外部数据源、脱机的数据存储介质中导入到数据仓库。根据源数据的不同性质，应选用不同的数据抽取方法。本系统中，对于Oracle、sybase等关系数据库中的数据，我们通过交易日志的方法进行数据抽取，而对于其它半结构化或非结构化数据，我们选用静态数据、时间标记、文件比较等方法实现数据抽取。3.1 设计原则 l 高数据质量原则：保证进入数据仓库数据的质量，将垃圾数据排除在数据仓库之外。l 自动化原则：ETL过程应尽量自动完成，减少人为干预程度。l 可追溯原则：ETL的相关工作结果，应留有痕迹，给出相应的报告，以便跟踪和分析。l 参数化设计原则：采用参数化的设计思想，减少编程的工作量，增强系统的灵活性和可维护性。l 效率性原则：采用并行处理等设计方法，减少ETL时间，提高ETL效率。l 源系统不修改原则：尽量不对源系统进行修改，将对源系统的影响降低到最低程度。l 方便性原则。设计应充分考虑系统运行后管理和维护的方便性和易用性。3.2 ETL抽取过程设计ETL工具采用Cognos产品本身的ETL工具3.2.1 ETL过程概述ETL流程是指源系统数据经过数据抽取、转换和加载处理进入数据仓库的整个过程。ETL流程主要包括以下主要步骤：1. 数据抽取：数据抽取就是将数据仓库需要的业务数据抽取到数据转换区的过程。（这里的数据转换区也可以仅仅是一个逻辑的概念，即数据的抽取到转换采取数据不落地的方式完成）2. 数据检查和出错处理：在数据转换区中，对源系统数据质量进行检查，形成检查报告，并进行相应的出错处理，对于严重错误，需要系统维护人员现场做出相应的处理。3. 数据转换：数据转换包括对源系统数据进行整理、剔除、合并、验证等一系列转换工作，最后形成数据仓库物理数据结构所需的数据，存放在转换区的数据表中。4. 数据加载：数据加载将数据转换的结果数据加载到数据仓库，并形成数据加载情况的报告。3.2.2 ETL过程详述本期项目ETL的过程具体描述如下：第一步： 数据抽取在源系统上启动数据抽取控制程序，完成以下工作：1、 数据采集考虑到数据来源的多样性和复杂性，数据采集主要包括：l 对业务系统的数据采集：在日终结后，当日数据自动、增量地转储到数据备份机上，作为数据仓库的数据源并成为数据备份策略的一部分。l 对于税收计划、外部数据、纳税人财务报表的数据采集。可根据实际需要，采用多种途径。2、 数据发送在数据采集完成后，各系统上的抽取控制程序将数据文件和校验文件通过局域网发送到数据转换区。第二步：数据装入转换区1. 检查数据是否到位根据校验文件，检查源系统数据是否到位、是否存在传输错误等异常情况。如果数据不全或传输出现错误，如果出错，将出错结果写入错误日志，重新执行第一步。2. 将外部数据文件装入oracle数据库把来自外部源数据源的格式化数据转化成oracle数据库、表结构。3. 修改系统状态：待该步骤工作完成后，将系统状态改为抽取工作完成。注：若直接从业务系统数据库中抽取数据，则无须数据转换区步骤。第三步：数据质量检查和出错处理1. 状态检查：查询参数表，如果数据抽取工作已经完成，开始执行该步骤工作。2. 数据质量检查：根据检查规则，数据质量检查程序扫描源数据数据表，根据规则检查数据是否合法，给出检查报告和最终的数据质量报告并写入数据库，数据质量检查结果写入质量检查报告。3. 出错处理：如果出现严重出错，停止ETL工作，需要系统维护人员现场做出相应的处理，修改正确后，重新执行该步骤工作；对于警告级出错，继续进行下述步骤。4. 修改系统状态：待该步骤工作完成后，将系统状态改为数据质量检查工作完成。第四步：数据转换1、 状态检查查询参数表，如果数据质量检查工作已经完成，开始执行该步工作。2、 数据转换根据数据仓库要求的数据源格式在Staging Area中进行并行转换处理，并将转换的结果数据存放在待装载数据存放区。3、 生成转换报告记录数据转换情况，并写入数据库转换日志中。4、 修改系统状态： 待该步骤工作完成后，将系统状态改为数据转换工作完成。第五步：数据加载l 状态检查查询参数表，如果数据质量检查工作已经完成，开始执行该步骤工作。l 数据装入数据仓库采用非依赖数据并行加载的策略，将待装载数据区的数据装入中心数据仓库，如果标准代码表发生变化，数据装载程序将标准代码的变化情况增量加载到数据仓库代码表中。l 数据加载情况报告记录数据加载情况，并写入数据仓库数据库的参数表中。l 修改系统状态： 待该步骤工作完成后，将系统状态改为数据转换工作完成。第六步：加载时间维1. 状态检查查询参数表，如果数据加载工作已经完成，开始执行该步骤工作。2. 加载时间维根据当前的时间，依据数据集市多维模型，完成时间维的加载工作。3. 修改系统状态：待该步骤工作完成后，将系统状态改为时间维加载工作完成。第七步：加载事实表1. 状态检查查询参数表，如果时间维加载工作已经完成，开始执行该步骤工作。2. 加载事实表以数据仓库数据为数据源，依据数据集市多维模型，完成事实表的加载工作。3. 修改系统状态：待该步骤工作完成后，将系统状态改为事实表加载工作完成。第八步：加载聚合表1. 状态检查查询参数表，如果事实表加载工作已经完成，开始执行该步骤工作。2. 加载聚合表以事实表为数据源，依据数据集市多维模型，完成聚合表的加载工作。3. 修改系统状态：待该步骤工作完成后，将系统状态改为ETL工作结束。3.2.3 ETL时间约束数据抽取的范围涉及财政核心业务系统数据，主要是五大块内容：税收收入数据、非税收入数据、部门预算、支出数据、专项支出数据、其他系统数据。其中：其他系统数据包含固定资产、统发工资等相关财政业务系统数据。平台在数据抽取时根据用户对数据的查询需求，可以实时、按天、按月取数。是指对在每天的特定时间必须要完成的事件进行严格的控制。对时间的限制建议可以表示为下图：图4-2：ETL时间阶段示意图从上图可以看出，为了保证每天业务人员及时使用数据仓库系统，对ETL时间通常有如下要求：n 3:30之前完成数据从源系统到数据转换区的数据抽取工作。n 5:00之前完成数据转换区内的数据转换工作。n 6:00之前完成转换后数据到数据仓库的数据加载工作。n 8:00之前完成数据仓库到数据集市多维数据库的ETL工作。ETL的时间窗口通常在4-6小时，考虑到将来系统数据的增长，ETL工具的处理效率和扩展性是关键。3.3 后台对应规则的设置平台中的数据由于来自不同的业务系统，各数据的编码可能不一致，系统能与后台设置各编码的进行对应关系管理；用户对预算单位设置用户与预算单位对应关系；用户对会计科目设置用户与会计科目对应关系；用户对功能科目设置用户与功能科目对应关系；用户对经济科目设置用户与经济科目对应关系；用户对预算项目设置用户与预算项目对应关系；用户对收费项目设置用户与收费项目对应关系；用户对指标类型设置用户与指标类型对应关系；用户对资金来源设置用户与资金来源对应关系；单位对会计科目设置预算单位与会计科目对应关系；单位对功能科目设置预算单位与功能科目对应关系；单位对经济科目设置预算单位与经济科目对应关系；单位对预算项目设置预算单位与预算项目对应关系；处室对单位设置财政归口部门与预算单位之间的对应关系；用户对归口设置用户与财政归口部门之间的对应关系；预算项目对执行项目设置预算项目与执行项目之间的对应关系.3.3.1 数据抽取程序的设计原则数据仓库需要的数据存在于不同种类、不同技术平台的业务系统中，数据抽取就是从这些不同的数据源中抽取数据作为数据仓库的原材料。本项目数据抽取设计时，采用以下方法：1. 直接从源业务系统抽取最原始的数据，不抽取派生数据。2. 只抽取源系统中本期项目需要的数据库表。3.3.2 数据抽取方式1. 初始抽取数据初始抽取指按照需求设计要求，把数据仓库要求的各业务系统的数据源一次性抽取并加载到数据仓库，本项目初始抽取的数据范围为源业务系统当天日终后的数据。初次加载时间可定为投入运行的当月业务系统处理结束后进行。2. 增量抽取在数据仓库系统投入运行后，只抽取业务系统的增量数据到数据仓库，增量数据包括业务系统新增数据和变化数据两部分，采用增量抽取的方法确保每次最小的数据子集加载到数据仓库里。第四章 数据整理平台建设 数据整理平台实现数据仓库中当前数据、综合数据、历史数据的组织和整理。通过数据抽取平台获取的各业务数据，从逻辑上和业务上是独立的、分散的，要实现一体化的查询功能，必须对分散的业务数据进行抽取和整合。如将分散的单位基础信息、预算数据、支出数据通过一定的策略，整理形成一套编码统一、业务连贯的数据体系，这是一体化查询系统成功的关键。数据整理平台基于各业务数据，可以根据不同的用户查询需求，定制数据整理策略。根据查询角度的不同，按决策的主题要求形成当前的基本数据层，按综合决策的要求构成综合数据层，随着时问的推移，由时间控制机制将当前基本数据层转为历史数据层。4.1 数据转换设计4.1.1 数据转换的工作内容数据转换是数据仓库项目中数据管理部分的核心内容，这个过程会直接影响数据仓库数据的质量，数据转换主要设计以下工作内容：l 数据整理：这一处理过程将数据从源系统中的结构和格式转换成数据仓库所需的结构和格式。l 数据清理：数据清理通常用来处理已知的某一数据源的数据质量问题，数据清理主要是根据相关的业务规则来纠正数据质量问题，给数据仓库中的数据一个合理的取值。l 数据验证：这一过程确保所选择的数据成功采集、在转换处理过程中保证数据的完整性。4.1.2 数据转换程序的设计原则根据本次的项目特点，数据转换设计采用如下设计方法：1. 数据转换程序首先完成数据整理工作，保证数据格式的正确性。2. 数据仓库中不需要的数据（记录和/或字段）应该尽早剥离掉。3. 只有数据质量问题无法在源应用系统中修复的时候才采用数据清洗的方法。这些问题可能需要源应用系统中相应程序的改变，也可能只需要用户执行一个数据清扫的任务。4. 数据转换时，确证满足数据仓库的数据参考完整性要求。5. 采用参数化的设计方法，以便新的条件和规则增加时，只需要做最少的配置参数的工作。6. 转换程序的设计采用模块化的设计方法，以便于数据仓库的后续阶段的共享。4.2 数据质量检查和出错处理4.2.1 数据质量检查数据质量检查是为了保证数据仓库中数据的正确性，防止不符合规则的数据进入数据仓库。由于源业务系统的多种多样，以及对各自业务关注点的不同，很有可能会有一些数据是不完整的，也就是不能满足数据仓库分析功能的需要。为了保证数据分析的正确性，我们就需要对这些数据进行质量检查，使正确的数据进入数据仓库，同时在数据转换区内保留不完整的数据，这些被保留的数据经过数据管理员和业务人员的共同维护，使之满足数据仓库分析功能的需要，并能正确反映业务系统的实际情况。由于数据质量检查内容的不同，我们在数据ETL的不同阶段进行不同的数据质量检查任务，并根据检查结果进行相应的出错处理。4.2.2 出错级别将源数据的质量分为三级：正常级、警告级和严重错误级。三种定义为：l 正常级：数据符合业务规则所赋予的意义和数据库数据格式的定义。l 警告级：源数据的非关键属性残缺、内容和长度不符规范等一些非关键错误。l 错误级：数据质量发现严重的错误，不能启动数据转换和加载过程。4.2.3 出错处理设计如果在检查过程中发现了存在有警告级和错误级错误，则将错误记录的信息记录在检查错误结果表中，根据不同的错误级别采取不同的处理方式：l 警告级： 记录出错信息，可以继续后续工作。l 错误级： 只要存在错误级错误，则停止执行后续工作，需要系统维护人员现场做出相应的处理，修改正确后，重新执行数据质量检查工作。