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 错误级：
只要存在错误级错误，则停止实施后续工作，需要系统维护人员现场做出对应处理，修更正确后，重新实施数据质量检验工作。