财政大数据中心-大数据管理系统目录1. 数据标准管理 11.1 财政基础数据标准 11.2 财政业务实体数据标准 11.3 财政业务流程标准 21.4 数据接口标准 21.

在本一体化项目中，将以财政部应用支撑平台2.0为基础，建立数据交换机制，制定财政与外部单位数据交换的接口标准,包括国税数据接口标准、地税数据接口标准、人行数据接口标准、商业银行支付数据接口标准、商业银行非税收入数据接口标准、执收单位票据数据接口标准、固定资产数据接口标准、预算单位数据交换接口标准等。

1.5 财政数据资源管理

建立数据资源管理管理机制是本项目的核心内容之一，不仅涉及元数据管理、数据仓库模型建立、数据采集管理和数据最终展现等功能，还包括采集规范的制定、数据质量评价体系等规范。在本节只对数据资源管理的基础性功能进行设计，通过定义数据资源分类和存储机制，在财政数据中心建立统一的数据结构，形成财政“标准数据库”，为采集全面、规范的财政业务数据打下基础。

数据资源管理是围绕业务数据对象进行管理，将财政通用重要的业务基础数据归纳在一起统一管理，数据对象的描述严格需要遵循的《财政业务基础数据规范》。提供的主要功能包括：给出财政数据分类和扩展规范、定义公用数据结构、封装数据资源管理服务来规范财政数据的更新和检索操作。

1.5.1 数据资源管理框架

数据资源管理需要基于统一的元数据描述，确保与采集模块、数据仓库和查询分析模块有统一的“语言”，数据资源管理主要模块包括数据资源目录维护、数据资源的定义、发布和维护功能。

数据资源管理框架

财政数据中心是生产库和数据仓库之间纽带。一方面，财政数据中心规范化存储财政应用系统生产库必需使用的公共数据，包括：公用基础数据（功能分类等）、单位基本信息（人员情况等）、预算标准数据（定额标准等）等；另一方面，财政数据中心规范化存储财政业务数据，为数据仓库提供标准数据源。通过指标账、资金账和公共数据表等方式存储，为财政应用系统的跨年度、跨应用的参照查询提供支持。

数据资源管理与其他模块的关系主要体现在：

1、数据采集模块

横向采集模块和纵向采集模块从各类外部数据源的获取原始数据，整理成数据资源定义的统一格式，调用数据资源管理的写入接口，将财政数据存储在财政数据中心中。

2、为数据仓库提供数据源

数据资源管理确保财政中心的所有数据都是经过清洗、整理后的核心业务数据，为数据仓库搭建提供了干净、有效以及规范的数据源。

3、财政分析挖掘

基于财政数据中心，可以进行历年预算、执行数据分析；预算与调整对比分析；预算与执行对比分析；财力情况、收入结构分析等。从而满足了财政管理业务基本的查询、统计与分析功能。

1.5.2 数据资源分类

数据资源管理需要按照分类进行管理，从不同角度对业务数据中心有不同的分，对数据资源描述可以有多种分类方式，参考的分类方式包括：

1、按来源分类。按照数据来源的特点进行区分，可以分为：来自平台、来自统计报表、来自业务系统等。

2、按业务分类。按照数据归属的业务，可以分为：宏观经济数据类、财政基础资料、财政收支旬月报等。

3、按存储方式分类。数据资源支持有三种基本方式：增量存储、版本存储和覆盖存储。

按照数据类型分类，如下：

1、宏观经济数据：包括宏观年度经济指标、宏观月度经济指标等。

2、财政基础信息库：根据财政管理各阶段需参考使用的基础信息进行分类统一管理；主要有：单位基础信息、人员信息、资产信息等。

3、财政收支旬月报：以收支旬月报数据为基础，定期反映全国各级财政的一般预算、政府基金预算、国有资本经营预算执行情况。

4、预算执行数据：对财政的核心业务数据进行统一管理，也是总账控制引擎的关键所在，主要来源于平台，主要包含预算指标数据、国库支付数据、非税收入数据和税收收入数据等；

5、转移支付项目：以中央转移支付项目为主线，实现财政上下级之间资金分配和使用信息的收据，全面反映中央转移支付项目资金的安排、配套、执行情况。

6、专项数据库：围绕专项应用需要，单独建立的数据结构，如：地方政府性债务按照债务项目的借、用和还信息等。

说明：财政数据中心数据分在类逻辑结构层面存在交叉和重复的情况，如：地方的“转移支付信息”既是预算执行数据，也是转移支付数据。

1.5.3 数据资源定义

在数据资源管理中需要统一维护财政数据中心的各类数据，提供基本的维护功能，包括：

1、注册数据资源。依据数据采集或数据仓库的需要，注册一个新的数据资源，以便在采集或查询定义时直接引用。

2、更新数据资源。财政业务在不停地进行变革，可以依据业务发展的需要，对数据数据资源描述进行更新。

3、停用数据资源。随着收支统计分析业务的需要，少量的数据资源将不再使用，不能简单地进行删除处理，而是要在资源目录中进行停用。

数据资源的属性依据数据管理的需要不断丰富，基本的属性包括。

属性描述	是否必须		说明
资源分类	是		记录标准的业务分类
资源代码	是		英文的描述，作为唯一标识
资源名称	是		中文的描述
资源类型	是		数据管理的习惯分类，包括：基础数据、业务数据、维度数据、主题数据等
对应存储	是		对应到数据库中的具体物理表或视图
资源描述		否	对资源的简要描述
元数据集合		是	描述改资源引用的元数据
资源更新方式		是	增量、全量等更新方式
是否含附属资源		否	描述是否有子资源
依赖主资源		否	如果该资源为附属资源，需要制定主资源代码

数据资源主要属性

数据资源在维护的过程中，对应的数据表（Table）或视图（View）可以依据对应元数据的具体描述进行动态的更新。

数据采集管理

数据采集是从财政内部系统或财政外部数据源收集原始数据。数据源可以是财政业务数据库或互联网。数据采集管理包括批量采集、实时采集、网络爬虫采集等多种方式。

1、数据采集的主要工作：

1）数据范围过滤，完全抽取源表所有记录或按指定日期进行增量抽取；

2）抽取字段过滤，全部抽取源表所有字段或过滤掉不需要的源数据字段；

3）抽取条件过滤，如过虑到指定条件的记录；

4）数据排序，如按照抽取的指定字段进行排序；

5）去除回车换行符。

数据采集可以采用PULL和PUSH两种方式。PUSH就是指由源系统按照双方定义的数据格式，主动将符合要求的数据主动传送到接口数据表或数据视图供ETL系统使用。PULL则是由ETL程序直接访问数据源来获取数据的方式。

2、数据采集的接口设计

典型的数据采集接口包括数据库接口和文件接口，对于不同数据平台、不同源数据形式、不同性能要求和业务量的业务系统以及不同数据量的源数据，采取不同的数据采集接口。在数据采集时需要重点考虑数据采集的效率，以及对现有业务系统性能及安全的影响。

如果系统的源数据具有如下特点：

1）数据量特别大；

2）大部分业务系统工作负荷重，7*24工作；

3）业务系统性能、实时性的要求较高。

则对于数据采集接口一般情况下采用专用数据库驱动接口，必要的时候采用API接口编程实现数据的抽取，以提高数据采集效率同时减少对业务系统的性能的影响。

3、数据采集的方法设计

1）全量抽取

全量抽取类似于数据迁移或数据复制，它将数据源中的表或视图的数据原封不动的从数据库中抽取出来，并转换成自己的ETL工具可以识别的格式。全量抽取比较简单。

2）增量抽取

增量抽取只抽取自上次抽取以来数据库中要抽取的表中新增或修改的数据。在ETL使用过程中。增量抽取较全量抽取应用更广。如何捕获变化的数据是增量抽取的关键。对捕获方法一般有两点要求：准确性，能够将业务系统中的变化数据按一定的频率准确地捕获到；性能，不能对业务系统造成太大的压力，影响现有业务。目前增量数据采集中常用的捕获变化数据的方法有：

（1）触发器

在要抽取的表上建立需要的触发器，一般要建立插入、修改、删除三个触发器，每当源表中的数据发生变化，就被相应的触发器将变化的数据写入一个临时表，抽取线程从临时表中抽取数据，临时表中抽取过的数据被标记或删除。触发器方式的优点是数据采集的性能较高，缺点是要求业务表建立触发器，对业务系统有一定的影响。

（2）时间戳

它是一种基于快照比较的变化数据捕获方式，在源表上增加一个时间戳字段，系统中更新修改表数据的时候，同时修改时间戳字段的值。当进行数据采集时，通过比较系统时间与时间戳字段的值来决定抽取哪些数据。有的数据库的时间戳支持自动更新，即表的其它字段的数据发生改变时，自动更新时间戳字段的值。有的数据库不支持时间戳的自动更新，这就要求业务系统在更新业务数据时，手工更新时间戳字段。同触发器方式一样，时间戳方式的性能也比较好，数据采集相对清楚简单，但对业务系统也有很大的倾入性（加入额外的时间戳字段），特别是对不支持时间戳的自动更新的数据库，还要求业务系统进行额外的更新时间戳操作。另外，无法捕获对时间戳以前数据的delete和update操作，在数据准确性上受到了一定的限制。

（3）全表比对

典型的全表比对的方式是采用MD5校验码。ETL工具事先为要抽取的表建立一个结构类似的MD5临时表，该临时表记录源表主键以及根据所有字段的数据计算出来的MD5校验码。每次进行数据采集时，对源表和MD5临时表进行MD5校验码的比对，从而决定源表中的数据是新增、修改还是删除，同时更新MD5校验码。MD5方式的优点是对源系统的倾入性较小（仅需要建立一个MD5临时表），但缺点也是显而易见的，与触发器和时间戳方式中的主动通知不同，MD5方式是被动的进行全表数据的比对，性能较差。当表中没有主键或唯一列且含有重复记录时，MD5方式的准确性较差。

（4）日志对比

通过分析数据库自身的日志来判断变化的数据。Oracle的改变数据捕获（CDC，Changed Data Capture）技术是这方面的代表。CDC 特性是在Oracle9i数据库中引入的。CDC能够帮助用户识别从上次抽取之后发生变化的数据。利用CDC，在对源表进行insert、update或 delete等操作的同时就可以提取数据，并且变化的数据被保存在数据库的变化表中。这样就可以捕获发生变化的数据，然后利用数据库视图以一种可控的方式提供给目标系统。CDC体系结构基于发布者/订阅者模型。发布者捕捉变化数据并提供给订阅者。订阅者使用从发布者那里获得的变化数据。通常，CDC系统拥有一个发布者和多个订阅者。发布者首先需要识别捕获变化数据所需的源表。然后，它捕捉变化的数据并将其保存在特别创建的变化表中。它还使订阅者能够控制对变化数据的访问。订阅者需要清楚自己感兴趣的是哪些变化数据。一个订阅者可能不会对发布者发布的所有数据都感兴趣。订阅者需要创建一个订阅者视图来访问经发布者授权可以访问的变化数据。CDC分为同步模式和异步模式，同步模式实时的捕获变化数据并存储到变化表中，发布者与订阅都位于同一数据库中。异步模式则是基于Oracle的流复制技术。

ETL处理的数据源除了关系数据库外，还可能是文件，例如txt文件、excel文件、xml文件等。对文件数据的抽取一般是进行全量抽取，一次抽取前可保存文件的时间戳或计算文件的MD5校验码，下次抽取时进行比对，如果相同则可忽略本次抽取。

4、数据采集策略设计

对源数据的抽取必须能够充分满足数据仓库决策分析应用的需要，又能保证不影响业务系统的性能，所以进行数据采集时应制定相应的策略，包括抽取方式、抽取时机、抽取周期等内容。进行数据采集时必须充分考虑以下因素，制定相应的策略：

1）满足对多种不同数据来源的抽取处理。支持多种数据源，包括相应业务系统、外部数据源；能够提供某些数据的人工输入功能。

2）支持多种不同系统平台和数据类型的数据采集。包括各种关系型数据库系统、各种文件方式的源数据等。

3）充分考虑数据源系统的性能要求。根据业务量大小和数据量大小，尽量减少对数据源系统的影响。

源数据分类

通常情况下，流水型增长且数据量大的数据适合采用增量抽取的方式，最为典型的是清单、帐单类数据；变化更新的数据适合采用完全抽取的方式，最为典型的是反映当前状态的资源配置类数据；对于两者结合的数据，如果能提取增量信息，则进行增量抽取，否则采用完全抽取的方式进行，最为典型的是客户资料变更数据或其他的服务记录数据。此外，对于抽取时机要尽可能避开业务系统的高峰时段，可选择在夜间业务系统比较闲时进行；对于抽取周期要考虑实际业务的需求和抽取进行的系统代价，在可能的情况下，尽量缩短抽取周期。

5、数据采集的异常处理设计

提供丰富的错误控制及监控等功能；

1）对于单个作业，每个作业都做Error Handling 设定：

（1）定义当此作业失败时如何处理父对象，可设定为失败父对象；

（2）定义作业允许出错的记录数，例如：超过5条记录出错，即失败此作业

（3）定义当调用的存储过程、命令行或SQL出错时，是停止此作业，还是忽略错误并继续执行；

（4）定义出错信息的存储属性，可将数据的错误，写入文件、记入日志或写的数据库表中，以方便后继验证。

2）对一组任务组成的流程提供错误控制

提供流程异常分支流程设计功能，对可执行命令行、email或控制组件，每个link （线），均可输入条件。例如：如果上一个作业的状态是失败，则执行此分支流程。提供email 控件，可把错误或成功信息以email的形式，发送给指定的管理人员，达到错误报警的功能。可把详细的作业信息，发送出去，其内容由参数控制。

3）提供日志监控与审计功能

提供两种作业运行的监控模式（Task View和Gantt Chart），可以查看任务运行成功与否，耗时统计，Session成功读取记录数，成功装载记录数，失败装载记录数等信息。

4）在作业处理过程中，提供很好的容错机制。主要有下面几种方式：

（1）挂起。当作业运行时，如果发现某些作业出现异常错误，整个抽取、转换、加载任务就被挂起，等问题排解后再运行；

（2）错误次数。通过设置参数，限制作业出错次数，一旦达到设置的上限就会停止。

（3）将错误数据保存。通过设置参数，将作业运行过程中的错误数据可以以文件和数据的方式保存下来，供单独处理。

（4）断点续传。当作业在运行过程中，由于主机、网络等原因使得机器停机、网络中断，不能够正常工作，通过参数设置，实现断点续传，当环境恢复后，作业会在断点处继续抽取、加载、转换。同时可以实现服务的自动切换，让数据交换得以继续执行。

（5）支持异构操作系统的高可用性（HA）功能。如果因为网络或机器断电导致作业执行一半，则另外一台机器自动接管此作业，从断点的地方继续执行下去。

数据预处理

数据预处理是将原始数据转换为符合质量要求和计算要求的标准结构化数据。基本方法是，根据财政数据标准管理中的规范规则，进行财政基础数据的扫描、监测和比对，识别出这些数据的完整性、有效性和合理性，包括数据本身质量，数据语义质量管理，通过数据质量规则引擎工具，对数据进行扫描、去重、清洗、转换、比对等一系列的加工处理，最终输出为符合规范的基础数据，同时筛选出不符合规范的数据，并形成数据质量报告，通过数据管控流程将不一致的数据发给数据源单位修复，实现数据溯源，让使用者、管理者清楚数据的来龙去脉及问题追溯。

1. 1. 1. 单数据源质量问题解决

对各主要数据内容，进行剖析、归类、监控（Profiling）、评估。从数据的几个属性着手，进行底层数据的摸底工作。

数据质量评估

通过评估数据质量，能够发掘所有数据源的完整准确信息，并揭示隐藏在数据源内的数据质量问题、差距、不一致和不兼容之处。为数据标准化规则、字典知识库的准备提供了第一步的基础保障。

完成数据分析并了解相关问题后，将对在分析过程中被识别为低质量数据的数据实例进行标准化和扩充。

数据标准化将标准化数据格式，同时通过对一系列过滤器和参考词典之间的值进行对比来验证和增强数据。标准化操作包括基本的“噪音消除”或多个定制的业务规则。数据标准化操作通常根据类型（例如字词、数字、代码）探查数据并对离散组件中的数据字符串进行分析。这一操作可将数据内部的元素信息展示出来，并标准化数据本身。

1. 1. 1. 多数据源交互集成时的数据质量问题解决

数据中心数据涉及本级核心业务系统，还包括外部数据，会极大存大多数据源交互时的数据质量问题。

主要技术手段：

1.多数据源的关系分析，将永远没有被关联到的数据提取出来，进行问题确认。

2.模糊匹配分析，没有关系到的数据进行数据的模糊匹配。采用模糊匹配算法，并针对评分结果进行加权平均。最终得到记录的相似度。以此为结果提供给业务人员或数据管理者，进行数据关系的定位。

1. 1. 1. 元数据的质量管理

元数据质量管理的主要目标是提高元数据自身的质量，建立有效的元数据质量检查机制，及时发现、报告和处理元数据的质量问题对经营分析系统元数据应用至关重要。

元数据管理模块应具备对元数据本身质量进行检查的功能。元数据质量检查包含但不限于以下内容：元数据一致性、元数据关系的健全性、元数据属性的填充率、元数据名称重复性、元数据关键属性的填充率和元数据关键属性值的唯一性。对于以上检查结果，元数据管理模块可生成详细的检查报告，并能够支持相关人员对检查报告的检索和查找，能够把指定的检查报告导出成Excel、PPT等更易于阅读的文档。

1、元数据一致性检查

一致性检查主要是指从数据中心中抽取元数据，并与元数据库的对应信息进行比较，及时发现系统的应用变更，保证元数据的及时更新。一致性检查包括两种方法：自动检查和人工检查。

自动检查是指：对于需要检查的元数据，利用API或其它形式接口对经营分析系统中的元数据进行直接查询访问，获得相应的元数据，然后进行比较，从而确定相应的元数据是否保持同步。自动检查又可以分为实时自动检查和定期自动检查。

元数据一致性检查示例图

人工检查是指：对于无法进行自动检查的元数据，需要与元数据库之间进行人工比较，从而确定相应的元数据是否保持同步。人工检查可以分为不定期人工检查和定期人工检查。

在一致性检查发现差异时，原则上不能直接修改元数据库中的元数据，而是给出各类元数据的差异报告，结合元数据变更管理流程，并由元数据管理员确认并审核后，利用元数据维护工具进行元数据的更新。

对于一致性检查工作，可以从以下几个方面进行评估：

1）元数据实体匹配情况：是指对以下三种情况所占比例进行评估：

（1）在数据中心中和元数据库中同时存在的实体；

（2）在数据中心中存在，但是元数据库中不存在的实体；

（3）在数据中心中没有，但是元数据库中存在的实体。

如果采用自动检查方式，可以用实体命名进行比较；如果采用人工检查方式，则可以根据实际情况综合判断；

2）元数据属性匹配情况

对于数据中心中和元数据库中同时存在的实体，可以对其属性进行比较，找出属性值不一致的实体，并统计这些实体所占比例。

2、元数据关系健全性检查

在数据中心元数据库中，除个别类型元数据之外，各类元数据之间都有着千丝万缕的联系，并且相互间的关联关系需要保持一致，不应出现空链或者错链的情况（即存在外键或链接，但所链接的内容不存在或错误）；各个子系统内部的元数据之间的关联也要保持一致；同时，子系统之间的元数据关联也要保持一致（不能出现某一个系统引用另一个系统中出现的元数据对象，却在另一个系统中找不到这个对象的情况）。

元数据管理模块通过元数据的这些关系描述了数据流向、过程依赖和业务承载等各种内在的规律。元数据关系是否健全直接影响到维护人员的问题判断和处理结果，直接影响着开发者对数据流向的分析和判断，因此，元数据管理模块必须在元数据的关联关系健全性方面作好保障检查工作。

对于元数据关系健全性检查工作，可以从以下几个方面进行：

1）数据处理关系检查

数据处理关系是数据实体和数据处理过程之间的关系。数据处理关系检查是从元数据库中找出缺乏应有数据处理关系的数据实体和数据处理过程。例如，找出没有与任何数据处理过程建立数据处理关系的数据实体和找出没有与数据实体建立数据输入输出关系的数据处理过程。

2）上下级关系检查

上下级关系是在元数据库中对经营分析系统实体进行分级管理所形成的元数据关系，例如将指标按业务主题和业务子主题进行分级管理。上下级关系检查是在元数据库中找出存在不合理上下级关系的实体，例如找出没有与任何业务主体建立关系的指标。

3）组合关系检查

组合关系是经营分析系统实体之间的整体和部分关系，例如数据库表和字段之间的关系。组合关系检查时在元数据库中找出存在不合理组合关系的元数据，例如找出没有与任何数据库表建立关系的字段。

3、元数据属性检查

元数据属性检查是对元数据库中实体属性详细信息方面的检查，包括元数据属性填充率检查、元数据名称重复性检查和元数据关键属性值的唯一性检查等。

1. 1. 1. 数据质量管理业务内容

应将数据质量管理纳入数据中心中统一建设，在进行建设过程中全面考虑数据质量：

数据质量框架图

标准：数据质量管理的一大关键功能是建立数据标准。需要建立数据定义和分类法、定义主数据、开发数据模型、执行与数据相关的开发和技术标准。

政策和程序：围绕数据创建、开发和管理制定并实施一套政策和程序，这是有效进行数据质量管理的基础。用户需要定义数据和与数据相关的业务规则、控制数据访问和交付、建立持续监控和评估机制，以及管理数据变化。

组织：用户在启动数据质量管理方案时需解决的最为重要的问题就是如何设计用户组织结构。用户需要确定数据相关人员的角色和职责。可在不同级别（例如数据管理和数据分析）设立多个不同角色，包括业务和 IT 人员，这些人员来自从执行理事会到日常实施者等不同部门。解决培训和组织更改管理问题同样是至关重要的一环，因为它关系到数据治理计划能否顺利进行。无论用户结构如何，对用户范围内数据质量管理的承诺均十分重要。

技术：通过数据质量管理工具协助完成我数据质量管理任务。

1. 1. 1. 数据质量优化方案

如下图表所示，数据质量是一个迭代流程，随着新数据不断涌现，数据质量管理将在数据中心内持续发挥作用。通过预先定义流程，可增强有效利用数据质量解决方案的能力，因为用户组织内负责数据质量实施和监控的部门将在规则和程序的限制下进行操作。

数据质量持续维护方案

进入数据的采集是由数据交换平台提供，来源于规划的数据准备区、数据仓库、数据集市内的数据。

数据质量实施是一次性的，后继将进入迭代循环的维持过程：清洗、监控、维维护。

数据质量实施图

确定并衡量数据质量：在前述数据质量维度的限制下对数据进行了解是执行业务规则和流程的基础。如果没有进行预先评估，有效执行数据质量策略的能力将大打折扣。从当前角度分析，数据质量评估允许相关人员查看所采用的数据质量流程如何提高数据质量。此外，随着新数据不断涌入系统内部，评估还将为数据质量流程提供有关持续修改的关键信息。

定义数据质量规则和目标：一旦完成评估即将进入第二个分析阶段，其中包括对结果进行评分，以便为数据质量管理方案制定合适的成功标准和指标。从当前角度分析，这一阶段将包括对数据和规则进行合理的趋势分析，确保数据持续符合在数据质量管理方案内采用的规则。

设计质量改善流程：这一阶段包括对数据进行处理，以便符合所实施的业务规则。潜在的改善示例包括：标准化、消除干扰、调配产品属性、度量或分类。

实施质量改善流程：一旦对数据进行标准化之后，即将进入质量强化流程的第二阶段，这包括确定重复数据并根据所确定的业务规则采取行动。由于数据质量是一种迭代流程，用于确定及处理重复数据问题的规则也将持续改进。随着数据管理员对数据的理解不断加深、数据治理委员会制定的策略和程序在组织内广泛采用，业务规则就会随之发展。在这种情况下，能否找到其他重复数据或能否找到新的数据关系成了数据中心需面临的新难题。

监控数据质量与目标：具备监控数据质量流程的能力是关键的一环，因为它能够为系统快速提供其内部数据健康状况快照。通过对记分卡结果进行分析，数据治理委员会将获得所需信息，以便可靠地根据需要对数据质量策略进行适度修改。相反，记分卡和趋势分析结果可使用户不必再操心数据质量问题是否已得到有效解决。

数据仓库管理

对于处理后的标准化结构数据，建立数据存储管理子系统，归集到底层数据仓库，并基于数据仓库，对其内部数据分解成各类数据集市。

1. 1. 1. 设计要求

数据仓库设计是整个数据仓库系统的核心，其设计的好坏关系着整个数据仓库系统建设的成败。根据数据仓库系统需求及Oracle数据库系统的特性，我们对数据仓库系统的数据库设计应遵循如下设计原则：

1、规范化原则：数据仓库系统是一个数据量大，开发周期长，投入资金大，涉及面广的系统工程。为开发和将来系统维护的方便我们对数据仓库中的所有对象如表空间、数据文件、日志文件、表、视图、索引、存储过程、列，都要求有严格的命名规范。

2、简洁性原则：数据仓库设计尽可能简洁和易理解，对常用的数据集可通过自定义数据类型来实现。

3、高效性原则：数据仓库中的数据达到TB级别，对查询速度的提高是我们考虑的重点，可通过建Index，Cluster，尽可能的用存储过程，允许适当的数据冗余等技术来保证查询效率。

4、灵活性原则：设计要充分考虑主题，指标等的变化。

5、合理性原则：数据应在源头输入。数据仓库的生成和维护应尽量靠近信息源和使用点，使信息按最短的路径存取，以确保信息合理和快速流动。

6、独立性原则：数据仓库与应用程序严格的相互独立，确保数据的存贮对应用程序的独立性，它的改变不影响应用程序。

7、安全性原则：由于财税信息对特定的用户有特定的保密要求，我们在设计数据仓库时要有必要的安全机制设计严格的数据操作权限和级别控制，保证数据不被非法用户访问，数据仓库不被黑客破坏，如在数据仓库的主键中加入操作用户的信息等等。

1. 1. 1. 数据分区方案

数据仓库是面向主题的、集成的、稳定的、随时间不断变化的数据集合。数据仓库建设有两种方案：

一种方案自下而上的建设。这种方法的特点是先建设部门级应用，即先建设数据集市，满足部门级的应用，当部门级应用多到一定规模的时候，再建设数据仓库。这种方法的特点是起步规模小，容易实现，风险比较小，缺点是部门在设计数据集市的时候很难全面控制发展方向，最后形成信息孤岛，造成资源浪费。

另一种方案自上而下的建设。这种方法的特点是总体规划，全面入手，优点是不容易形成信息孤岛，建设周期比较短。缺点是风险比较大。

我们推荐的建设方案是自上而下的建设。根据我们在项目上的经验，自上而下建设的数据仓库整体规划型好，数据利用率高，生命周期长，运行效率高，总投资额比较低。我们有多年数据仓库实施的经验，有能力也能够避免风险。

数据仓库的结构如下图所示：

说明: DW.png

数据仓库的结构图

数据仓库在逻辑上可以分成三个区域：数据准备区，数据加工区和数据利用区。

1. 1. 1. 1. 数据准备区

数据准备区作用有四个：一是接受大型业务系统的ODS数据库的数据；二是直接抽取小型业务系统的数据；三是完成主要的数据清洗转化工作；四是便于对原始数据追踪。在这个区域数据主要以视图的形式存在，所以叫统一视图。数据准备区的视图有两种形式，即物化视图和非物化视图。物化视图以实体的形式需要加载数据，非物化视图只保存了一定的逻辑关系并不保存实体数据。什么情况下保存实体视图什么情况下不保存实体视图要根据数据源来确定，一般情况下以增量更新的数据保存为实体，变化比较缓慢的数据可以保存为实体，数据量比较小而且变化比较快的数据可以保存为逻辑视图。

1. 1. 1. 1. 加工区

数据加工区的任务有三个：

一是按照元数据规则把业务数据整理成业务元数据。业务数据的生命周期是从这里开始计算的。元数据比较规范，业务数据的生命周期就长，实际上在数据仓库的生命周期里面元数据的生命周期起了非常重要的作用。建设的比较好的数据仓库的生命周期可以长达几十年。

二是按照数据库第五范式（5NF）的要求：汇总的数据要能够追踪到原始数据。建设数据加工流，保持前后数据的一致性。

三是以业务元数据为纬度建设主题域。

1. 1. 1. 1. 数据利用区

原始数据经过数据加工进行数据利用区，构成主题数据层和汇总数据层的内容。

1、主题数据层

主题数据层是数据平台底层存储的核心，主要功能是存储和管理从原始数据层通过ETL过程得到的历史和当前的业务明细数据，但数据的组织方式不同于原始的业务系统。主题数据层数据结构一般符合第三范式要求，保存全量的最细粒度数据。

主题数据层建模符合面向主题分析的需求，考虑到未来的变化，应具有很好的稳定性和可扩展性，一方面是业务系统变化时模型应保持稳定，一方面是平台需求的变化时模型应保持稳定。主题的确定应该保证其具有独立的内涵和明确的界限，并能为数据应用提供所要求的一切内容。

在数据应用的运行和使用过程中，主题数据层的作用主要体现在以下几个方面：

1）直接支持前端查询、预警、报表等应用；

2）为基于汇总层的统计分析应用提供明细数据。

2、汇总数据层

汇总层中的数据由主题数据层的详细数据聚合而来，根据数据聚合程度的不同包含轻度聚合、中度聚合和高度聚合三种不同的层次。汇总的方式将依据数据量的大小、使用需求和使用频度综合考虑。根据业务需求分类成多个不同的子区，每个子区完成不同的应用需求。

在数据应用过程中，汇总层的作用主要体现在以下几个方面：

1）服务于应用主题，根据用户需求灵活定制；

2）满足统计、报表、电子台帐、绩效考核等需求；

3）利用存储空间换时间，提升系统运行效率；

4）汇总层面向聚集数据，在聚集数据上的分析可下钻到明细数据。

数据利用区主要功能是为前台展示层提供数据源，也是数据加工区的结果集部署。数据利用区主要考虑的因素是数据仓库的优化处理，通常考虑的因数是用户的并发能力和数据的搜索速度。常用的技术与数据库管理技术相似，如分区技术，创建索引，集群技术，控制会话时间等等。

数据利用部署的是主题域数据，为了发挥展示的效力，设计中考虑数据的粒度和细致度。

数据的粒度和细致度要根据不同的业务需求来部署，一般情况下，报表类和宏观分析类应用数据的粒度比较大，细致度比较低，查询类和微观分析类应用的数据粒度比较小，细致度比较高。要同时满足三个层次人员（决策层，管理层，应用层）需要就必须精心设计每一个主题域。

数据的粒度大小设计是工程问题，粒度的大小什么时候是最恰当的往往没有对错之分，只有效率问题。

数据利用区的效率与硬件环境因素有关，相同的粒度在不同运算能力的计算机上运行的速度是不一样的。粒度大数据的聚合度高，数据加工时消耗的硬件资源多。粒度小，记录数多，前台展示速度慢，必须根据实际的硬件环境找到一个恰当的数值。有经验的工程技术人员在设计数据仓库之前要在实际环境测试硬件环境和系统环境的特性值，求出运行环境的特性曲线，根据特性曲线和业务要求设计合理的粒度，现在很多多维分析展示工具是把数据下载到客户端运行，就更应该考虑数据粒度的大小。

1. 1. 1. 数据规划及分层
      1. 数据规划

数据应用的数据规划，通过对大量生产数据的整合、加工和处理，实现从数据到信息再到知识的阶梯性转换过程，形成的统一视图、数据仓库和数据集市，建成的平台满足财税的业务需求和可持续发展能力，从而为数据分析、决策管理和数据资源管理提供保障。

数据流程关系

1. 1. 1. 1. 数据分层

平台的数据层在逻辑上也可以分成三层，分别由数据集成层，数据质量监控层（数据治理）和数据支撑层组成。三层之间通过ETL方法贯穿，即层与层之间用ETL方法实现。一般的ETL方法可以借用BI工具，复杂的ETL方法也可以由程序员写代码实现。

数据分层

4.2.5.1 数据集成层

数据集成层也可称为数据集成平台，数据集成平台的作用是将各个业务系统的数据集成到操作型数据库ODS中，它主要有三个方面的作用：

集成功能：归集各类业务数据；

为生产系统减负：提供一些简单的实时业务查询（OLTP），以减轻交易类生产系统的压力；

数据交换：向其它需要数据的地方提供数据。

4.2.5.2 数据质量监控层

数据质量是平台建设的生命线，要保证整个系统的顺利运行，就必须保证进入数据仓库之前的数据是基本准确的数据，特别是主业务数据更是重中之重。

数据清洗示意图

数据质量监控平台的任务是清洗或转换一些不规则的数据，以提高整个系统的容错能力，数据质量监控的方法主要有两种：

实时监控一些不规则的数据，按一定的规则进行实时的清洗或转（Transform），以提高数据的可信度；

事后监控，在服务器比较空闲的时候对ODS数据库扫描，检测出不规则数据返回前台由业务操作员订正。

数据质量监控平台是架设在ODS上的逻辑平台，不一定需要专门的服务器。

4.2.5.3 数据分析支撑层

数据分析支撑层

数据分析支撑层是系统建设的核心，它实质上是遵循财税业务规则，适用于财税分析管理的专业数据仓库。

1. 1. 1. 元数据管理
  2. 设计目标

元数据管理的设计目标分为后台支撑和前台展现两大块：

1、后台支撑：数据仓库平台中的很多功能，必须依赖于元数据的支撑。

通过技术、业务和管理元数据，数据仓库平台可以在相应环节直观地通过人机交互，统一、关联、共享、顺序地定义数据项、定义表单、定义ETL和加工规则、定义物理表、定义多维模型、定义展现结果数据集；并将定义结果以相应的标准协议提交给物理表建立工具、ETL工具、多维模型建立工具、结果展现工具等底层工具；实现以上各个过程的过程可控、可跟踪；结果有案可查，不可抵赖；提示清晰，帮助友好，智能交互的计算机管理；实现数据治理的一体化，主动地进行元数据管理。

2、前台展现：通过元数据管理前台实现传统元数据管理的诸多功能。

能够管理各种技术元数据、业务元数据、管理元数据，以及数据标准；并在此基础上根据行业信息系统的建设发展实际需要，提供相应的元数据维护与应用功能，实现元数据管理和建立元数据应用体系。

元数据管理系统应采用高内聚、低耦合的组件式产品架构，丰富功能组件，搭建功能强大的元数据管理平台，同时向集成商全面开放元数据功能调用接口，并提供整套应用开发方法论。使业务人员在完成元数据管理、维护等基础功能的同时，方便集成商实现二次开发，快速满足业务应用的针对性需求。

元数据管理是数据仓库构建过程中十分重要的一环，元数据管理应满足以下要求：

1、元数据的存储：元数据应以数据库存储，便于管理，维护和扩展。

2、数据交换：支持以XML等标准进行数据交换。

3、应用编程接口（API）：通过API接入为元数据管理提供所需的灵活性。

4、元数据集中控制：元数据为整个税费监控平台的信息资源提供了记录，应对元数据集中管理控制，以确保信息的一致性和准确性。

5、影响分析：从元数据中发现任何变化给全厅带来的影响，确定某个实体的用途和与其它实体的关联。

6、版本控制：指测试和生产过程中的版本控制，应按部门进行。允许多个开发人员同时开发项目，并且开发人员可以根据要求修改对象，而不影响其他开发人员。

1. 1. 元数据类型

元数据管理贯穿平台构建、运行和维护的整个生命周期，是平台构建过程中重要的一环。同时，在数据仓库构建的整个过程中，如数据源分析、ETL过程、数据库结构、数据模型、业务应用主题的组织和前端展示等，均需要对相应的元数据的有力支撑。

1、元数据源层

元数据源层包括平台的数据源系统，ETL工具、数据仓库产品、数据集市产品、OLAP服务器、前端展现工具、数据挖掘工具等。

2、元数据获取层

元数据获取层实现元数据源层中各个系统的元数据采集。元数据连接桥（或称适配器）通过符合CWM规范的接口或者各个产品提供的特定接口实现元数据的抽取，并把抽取出的元数据存入元数据存储层中的元数据库。

3、元数据存储层

元数据存储层实现元数据的存储，存储的元数据包括业务元数据、技术元数据和管理元数据，元数据按照主题组织。存储库的逻辑模型设计需兼顾效率和实现符合CWM规范的接口的方便性与灵活性。

4、元数据管理层

元数据管理层提供符合CWM规范的接口实现，包括CORBAIDL接口实现/JMI接口实现，和XMI接口实现；并且实现元数据查询、元数据浏览、元数据访问、元数据分析、元数据导入、元数据导出等基本功能模块。

5、元数据访问层

元数据访问层包括元数据管理工具前端、二级税费监控平台和中央元数据采集服务器。这些系统通过元数据管理层访问元数据存储层的元数据。

按照元数据的使用情况和面向对象的不同，可以将元数据分为业务元数据、技术元数据和管理元数据。

1. 1. 业务元数据

业务元数据用业务名称、定义、描述和别名来表示数据仓库和业务系统中的各种属性，直接供业务分析人员使用。业务元数据使平台使用人员能够更好理解、使用数据，成为系统使用人员在数据使用中的业务向导。

业务元数据在平台的数据仓库中的体现是全方位的，平台使用人员通过浏览元数据可以清晰地了解各指标代表什么业务、如何计算得出的、以什么为单位等相关描述信息。

4.4.3.1 技术元数据

技术元数据描述了数据源、数据转换、抽取过程、加载策略以及目标数据库的定义等。技术元数据可供信息系统人员和一部分监控人员使用，用来进行影响分析、变化管理、数据库优化、任务调度和安全管理等。

数据在不同系统之间的处理、加载也是复杂和涉及多方面的。技术元数据对数据在系统间处理、加载的规则、过程、相关策略进行了描述。

在实际应用中业务元数据和技术元数据是相互参照和关联的，对业务元数据的全面了解、描述、表达能够推动数据仓库的应用，使平台使用人员真正使用、了解数据仓库。对系统中的技术元数据的获取、描述、应用，能够使数据及时、正确地得到应用和维护。

4.4.3.1管理元数据

管理元数据是描述平台中管理领域相关概念、关系和规则的数据，主要包括人员角色、岗位职责和管理流程等信息。

1. 1. 技术结构

元数据管理模块的技术结构对内要求具有良好扩展性，以及能力公开的特性。对外要求提供方便的集成方式，其前端界面需要集成到分析门户中。

元数据管理模块的技术结构如图所示。

元数据管理模块技术结构图

元数据、元模型和相关配置信息统一存储在关系数据库中。其中的元数据信息通过数据对象映射，转换成满足CWM规范的数据对象，为元数据获取组件和功能组件提供面向对象的数据存取服务。

元数据获取的数据源包括数据处理过程、ER逻辑模型、OLAP对象和数据库对象等。

元数据获取组件为元数据自动获取提供了一个可扩展的框架。在该框架中，可以针对每种不同的数据源，提供专用的元数据获取适配器。例如，对于数据处理元数据，可以提供SQL脚本解析器。

元数据功能组件包括元数据的管理和应用的基础功能组件。例如对血缘分析、影响分析、元数据检索和差异比较等功能。元数据功能组件为元数据应用所调用，同时通过REST风格的Web服务实现元数据访问接口的封装，对外能力公开元数据访问能力。

元数据应用可以通过Portlet和IFrame等方式集成到分析门户中。

此外，元数据管理模块还要包括调度控制、流程控制和权限管理等基础控制功能，为元数据应用组件、功能组件和获取组件的有机配合提供支持。例如，对元数据变更流程的支持和对元数据定时自动获取的支持。

1. 1. 元数据获取

元数据获取支持多种数据获取方式，包括在线电子报表填报（包括提交中间文件，例如excel文件）、调用Web Service服务、直接读取源数据库、MQ数据交换等多种采集方式。

系统提供元数据批量加载的功能，作为对手工维护元数据的增强，可加载按一定格式组织到XLS文件的元数据、XML格式存储的元数据。系统可自动产生XLS模板并且可将元数据批量导出为XLS文件。

通过元数据管理工具，可以支持手工获取XMI/Excel文件中的元数据进行导入。同时，支持SQL脚本自动解析功能，即通过对SQL脚本的词法、语法和语义分析，生成满足规范要求的数据处理元数据，并存储到元数据管理系统中进行统一管理。

1、XLS格式元数据批量导入

系统提供XLS格式元数据的批量加载，把不能自动获取的元数据以业务人员能理解的格式进行组织，并批量加载到元数据存储库，导入过程提供导入错误日志，系统对导入操作进行日志记录。

2、XML格式元数据批量导入

与XLS格式的元数据批量导入一样，系统提供XML格式的元数据的批量导入功能。

3、元数据整理模板生成

XLS格式元数据批量加载时，XLS文件中的元模型属性要与元数据系统的定义一致，定义不一致将导致导入失败。用户每次导入前，需检查所用模板是否最新版本，如不一致则要手工修改模板。

元数据管理提供自动生成模板的功能，以减少人工维护导入模板的工作量。根据系统最新的元模型自动生成XLS导入模板，导入模板在客户手工整理元数据时使用。产生的模板为XLS文件，每个元模型对应一个工作表。

4、元数据批量导出为XLS

将所有或指定范围的元数据导出系统，保存为XLS文件。本功能为与其他系统的整合提供数据的接口，也是元数据备份的一种方法，主要由管理员级别的用户使用。

用户进入元数据批量导出界面，选择要导出的元数据（可选择全部），按确定，选择导出文件的保存路径和文件名，系统将指定范围的元数据和关系数据导出为指定名称的XLS文件，保存在所选路径。

5、元数据批量导出为XML

系统的元数据与市信息中心元数据系统的交换方法之一是以XML格式作为元数据上传、下传的接口规范。系统提供将所有或指定范围的元数据导出系统的功能，保存为XML文件，用于与其他元数据系统交换元数据。

元数据的整合获取需遵循以下原则：

1、能够进行数据源统一管理配置，将数据源中不同种类，不同结构的数据源进行统一管理。数据源的管理包括数据源的选择，数据源的配置等操作。数据源的管理，涉及到下面几个要素：

区划、业务年度、库类型、存储类型、数据库名称、用户名称、密码、主机名、端口号等等。

2、能通过元数据批量获取从各层中向系统导入元数据。并通过视图化的界面，将业务元数据和技术元数据进行关系建立。用户可以通过界面操作进行元数据的导入及关系的建立，元数据关系建立后提供测试验证功能，能对关系进行有效验证及可行性验证。

3、能够通过导入作业功能，对抽取元数据作业的参数配置进行设置（作业名称、数据源、导入路径、入库名称、抽取增量方式等）。通过元数据采集工具，由用户定制抽取方式、抽取时间、数据源配置等。根据定时任务自动获取元数据，也可以手动获取元数据。系统提供一系列配置，供用户对元数据进行方便的抽取、导入。

4、能够通过定义过滤规则，可以对要抽取的对象进行过滤或转换。通过规则的设置到达对数据源抽取、过滤、转换的控制。

通过数据库工具或脚本的管理功能来实现，需要有事务管理的机制，定期实现抽取。抽取流程：

抽取流程

1）分析：体现在对数据进行校验，对无法实现抽取的数据给出明确提示。

2）清洗：更多体现在数据条件（SQL语句）的筛选上，将无用的数据（Where字句）和无用的列（Select子句）进行剔除，进行相关的运算，如：sum。

3）转换：将数据转换成系统能够理解的数据格式。

4）插入：使用稳定的方法插入，如批插入，并根据需要刷新视图。

5、系统提供任务调度服务配置，通过设置可以对抽取任务的运行时间、周期等执行情况进行控制。系统可以在任务调度列表中按时间、周期进行自动获取数据。系统提供日志记录功能，用户通过查看调度服务日志可方便查询到成功或失败的调取信息、原因、建议的解决方法等等。

1. 1. 元数据基本维护

系统提供包括获取层元数据维护、存储层元数据维护、访问层元数据维护、交换层元数据维护以及元数据的检索、浏览、打印等功能。下面以获取层元数据的维护为例说明元数据维护，获取层数据包括ETL程序元数据维护、接口数据表元数据维护等。

1、ETL程序元数据维护

ETL是数据中心的核心组成部分，此处ETL程序是广义的，包括TCL、SH、Datastage Job等各种形式的程序。

提供对ETL程序元数据的增加、删除、修改及浏览功能。可以按树型方式逐步展开元数据进行浏览，点击某个ETL元数据节点后，可显示该元数据的详细信息，可以对该元数据的内容进行编辑。

用户选择增加ETL元数据，系统提示输入ETL元数据相关属性值，点击确定按钮后，ETL程序元数据存入存储库。

用户选择了某个ETL程序元数据之后，可以对该元数据进行修改。系统列出原来各个属性的值，提示用户输入新的值。点击确定按钮后，新的ETL程序元数据存入存储库。用户选择了某个ETL程序元数据之后，可以对该元数据进行删除。系统提示用户确认。

2、接口数据表元数据维护

提供对接口数据表元数据的增加、删除、修改及浏览功能。可以按树型方式逐步展开元数据进行浏览，点击某个接口文件元数据节点后，可显示该元数据的详细信息，可以对该元数据的内容进行编辑。

用户选择增加接口数据表元数据，系统提示输入接口数据表元数据相关属性值，点击确定按钮后，接口数据表数据存入存储库。

用户选择了某个接口数据表元数据之后，可以对该元数据进行修改。系统列出原来各个属性的值，提示用户输入新的值。点击确定按钮后，新的接口数据表元数据存入存储库。用户选择了某个接口数据表元数据之后，可以对该元数据进行删除。系统提示用户确认。

3、系统提供对元模型和元数据的基本维护功能，包括元模型和元数据的添加、删除、修改等维护功能。在维护时提供良好的提示信息，如增加时如果元数据重复，则提示用户此元数据已经存在，不能重复添加；删除时给用户提示进行确认，防止由于不小心操作而影响系统运行。

4、系统能够实现对于元数据自身质量核查、元数据查询、元数据统计、元数据使用情况分析、元数据变更、元数据版本管理等基本功能。同时包括血缘分析（血统分析）、影响分析、实体关联分析、实体影响分析、主机拓扑分析、指标一致性分析等分析功能。提供符合技术环境规范的接口，供外部系统取用。

5、建立全省统一的元数据管理环境，实现各类业务和技术元数据的集中定义和管理；基于元数据体系提供对各类数据的审核管理机制，维护数据的完整性、准确性以及一致性；实现数据生命周期管理、数据标准、数据质量控制、数据审计等各项功能。

1. 1. 元数据关系维护

元数据关系维护包括：OLAP与表元数据关系维护、表与ETL元数据关系维护、ETL与接口文件元数据关系维护、ETL与ETL元数据关系维护、ETL程序字段映射关系维护等。

元数据关联和影响分析用于描述数据仓库对象和对象之间的依赖关系。用户可以对数据仓库中的一个对象和其它对象之间的联系进行分析，用户可能需要了解一个报表的数据是如何生成的，计算公式是什么，下图是元数据关系维护图。

元数据关系维护图

1、OLAP与表元数据关系维护

以图形化方式维护OLAP与数据库表元数据之间的关系，或删除关系。要求关系的建立完全按照元模型的定义。

2、ETL与ETL元数据关系维护

这种关系以图形化方式维护ETL程序之间（包括DataStage作业、TCL程序、汇总程序等）的关系，以及增加、修改、删除等关系。

3、ETL程序字段映射关系维护

维护ETL程序所用到的数据表、字段的映射关系，包括关系建立、修改、删除、浏览。

用户选择了某个ETL程序元数据之后，可以对该元数据的字段映射关系进行浏览。选择映射关系维护时，系统根据该ETL程序与DB2（或Oracle）表元数据的关系，列出相关的输入、输出表及其包含的字段，用户则可以在此基础上增加、修改、删除字段之间的映射关系。

元数据关系维护遵循以下规则：

1、根据元数据建立的属性及规则，可自动建立关系，可以不需要人工维护，当元数据转移时，能够在元数据采集、导入、存储的过程中元数据关系随元数据被抽取、导入、存储。转移后无需重新设置元数据之间的关系，从而保持了原型的有效性原则。

2、元数据之间不但可以自动建立关系，也可通过手动方式进行关系维护，包括增加、删除、修改。手动维护时由用户采用人工工作方式对元数据之间进行关系的定义、建立。

3、建立统一的标准接口来访问元模型及元数据，在对财税行业的应用系统进行开发时，可直接调用标准接口实现按需对元数据存储库中的元模型、元数据进行调用。可以设置元数据访问规则及权限控制，在调用标准接口时传输不同参数来限制元数据的访问。

1. 1. 主要功能

1、元模型获取

元数据管理系统提供统一的数据源管理，可以将包括源系统信息、ETL过程、数据库结构、数据模型、业务应用、前端展示和门户管理等数据源进行统一管理，实现主流BI工具元数据的自动获取，并支持手工获取XMI/Excel文件中的元数据。

同时，元数据管理系统支持SQL脚本自动解析功能，即通过对SQL脚本的词法、语法和语义分析，生成满足CWM规范要求的数据处理元数据。

2、元模型管理

元模型是对元数据的定义，具备可视化的元模型管理功能，并且能让用户完全定制元模型，持续满足用户在不同时期对元数据的不同需要。

3、元数据基本管理

元数据基本管理实现产品架构中功能层包含的部分功能，实现针对元数据的基本管理功能。包括元模型添加、删除、修改等维护功能；元数据的添加、删除、修改属性等维护功能；元数据之间关系的建立、删除等关系维护功能；元数据自身质量核查、元数据查询、元数据统计、元数据使用情况分析、元数据变更、元数据版本管理等基本功能。提供符合CWM规范的接口。

4、元数据分析

元数据分析功能实现产品架构中功能层包含的除基本管理以外的部分功能，实现针对元数据的基本分析功能。包括血缘分析（血统分析）、影响分析、实体关联分析、实体影响分析、主机拓扑分析、指标一致性分析等。

5、元数据发布

提供元数据发布流程管理，可以更好地管理和跟踪元数据的整个生命周期。能够将元数据以相应的标准协议提交给物理表建立工具、ETL工具、多维模型建立工具、结果展现工具等底层工具，实现数据治理的一体化。

6、元数据支撑

元数据支撑元数据的后台支撑部分。

1. 1. 1. 数据结构建设

数据结构建设可以分为数据建模和主题域结构建设两部分来阐述。

1. 1. 数据模型建设

数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。

1. 1. 数据建模原则

为保证模型的稳定性和对业务支持的灵活性，我们遵循以下的原则：

1、继承性原则：模型中，对于核心实体和相关概念，在不影响理解的前提下，尽量不提出新的概念；

2、稳定性原则：为保证模型的稳定性，实体与规则分离，突出核心实体的描述，提出规则点，对规则本身不做详尽描述；

3、前瞻性原则：为保证模型的前瞻性，模型适当超前，能够适用业务的发展变化。

1. 1. 数据模型分类

根据不同的分类标准，有不同的数据模型，如按建模方式分类有概念数据模型、逻辑数据模型、物理数据模型，按存储模式分类有实体关系模型、多维数据模型等。

针对不同的模型，我们的设计要求及其侧重点不尽相同，下面分别举例论述：

1、基础数据类模型：基础数据类模型是对财税业务的高度抽象，提供对业务数据的存储、组织和整理的数据存储结构，是平台建设的基础。这个基础数据模型应满足但不限于以下要求：

概念上应是高度抽象的、中性的、共享的。可有效、全面、完整地适应与涵盖财税业务范畴以及数据范围，不针对某个特别的具体应用而设计。

结构上应是稳定的、灵活的、可扩展的。能以满足第五范式的方法构建模型，存放最详尽的数据，保证足够的灵活性，适应复杂的实际业务情况，在业务发生变化或者新增数据源时易于扩展，核心结构在很长时间内应保持稳定性，便于回答不断产生、不断变化且无法预先定义的业务问题。

表现形式上应是规范的，易懂的。包括各类命名规范，业务规则定义，度量方式等。使用统一的业务语言进行模型设计，易于业务人员的理解和使用，也有利于技术部门和业务部门人员的沟通。

2、多维分析模型：维度建模提供给业务人员一种多视角的数据分析的手段，常用的模型是星型模型和雪花模型。多维分析模型与业务紧密相关，由业务驱动，主要在数据集市中构建。应满足但不限于以下设计要求：

1）高性能：支持的维度理论上应不受限制，处理能力强，为了提高性能，可以进行预处理，如按照维度进行预先的统计、分类、排序等。同时根据具体业务需求，支持ROLAP、MOLAP 及HOLAP。

2）易扩展：多维分析模型是由业务驱动构建，业务的需求是不断变化的，要求实现的多维模型可以不断扩展，以满足业务要求。

存储效率高：构建的多维分析模型要求节省存储空间，降低数据冗余。

3、数据分析和数据挖掘类模型：这类模型用途最广泛，来源也及其复杂，

大致可以分为狭义和广义两大类，狭义的数据分析模型是有一定口径、算法及其数据的集合。如，若干指标组成的为解决特定问题的集合。广义的数据分析模型指的是为解决特定业务问题而组成的由指标、规则、流程和数据的完整解决方案。如纳税评估模型、绩效考核模型等。这里所指的模型主要是狭义的数据分析模型。

该类模型应满足但不限于以下设计要求：

1）规范性：数据分析模型必须基于一致、统一的标准规范设计。

2）可共享：应能实现模型打包复用，在其他地方经过简单配置，就可以完整的使用，从而实现一处建设，多处共享的目标。

3）易管理：有着完整的生命周期管理功能，从模型的创建、占用空间的限制、用户权限的控制、模型的注销等，都必须有完善的管理手段。

数据模型	用户	用途	构建环境	规则标准	建模方法论	要求及约束
业务模型	普通业务人员	满足基础数据的管理需要，数据起点即业务库，是形成后续数据处理的最小粒度信息	业务数据库	满足第五范式	范式建模法
数据仓库模型	普通业务人员，业务管理以及决策层面人员	提供对海量业务数据的存储、组织和整理的数据存储结构	数据仓库	满足第五范式或维度建模	维度建模法
多维模型	普通业务人员，业务管理	提供给业务人员一种多视角的数据分析的手段	主要为数据集市	星型或者雪花模型	维度建模法
应用分析模型	普通业务人员，业务管理	解决特定问题的集合	数据仓库
决策支持模型	决策人员	宏观决策	数据仓库
…..

1. 1. 数据模型维护与管理

数据模型完整的生命周期分为模型定义、模型生成、模型使用、模型删除四部分，关键要求如下：

1、模型定义：

1）定义者：应用分析模型可由基本应用用户定义，数据仓库模型由开发人员定义，今后也可以由发展支持用户定义，决策支持模型由高端用户定义。

2）定义步骤：数据仓库模型数可分为业务建模、领域概念建模、逻辑建模、物理建模四个阶段：而应用分析模型可简化为逻辑建模和物理建模两个阶段。

2、模型生成：

1）规则加载：不同的数据模型根据其复杂程度，其规则加载方式也不一样，有手工加载、工具加载、元数据加载等。

2）数据加载：根据不同的用户和使用环境，数据加载策略也不尽相关，应用分析模型可由基本应用用户自行加载数据，数据仓库模型先期可由开发人员加载，今后可由发展支持用户加载。

3、模型使用：

1）数据环境：这里所指的数据环境是指模型的建立和使用所依赖的具体数据库，数据库大致分为数据准备区、统一数据视图、明细汇总库、多维数据库等。

2）应用环境：各类数据模型有着不同的应用环境及其相应的技术支撑手段。

4、模型删除：

1）对不再使用的数据模型，提供注销或归档的手段。

基础数据类模型是设计数据库和数据仓库的核心，这类数据模型应当满足以下三个要求：

1、符合用户的要求。既能包含用户需要处理的所有数据，又能支持用户提出的所有处理功能的实现；

2、能被某个现有的数据库系统（DBMS）所接受

3、具有较高的质量，如易于理解、便于维护、没有数据冲突、完整性好、效率高等。

基础数据类模型主要分为业务建模、领域概念建模、逻辑建模、物理建模四个阶段。

1）业务建模：调查和分析用户的业务活动和数据的使用情况，弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况，确定用户对数据库系统的使用要求和各种约束条件等，形成用户需求规约。

2）概念建模：对用户要求描述的现实世界，通过对其中住处的分类、聚集和概括，建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。所建立的模型应避开数据库在计算机上的具体实现细节，用一种抽象的形式表示出来。以（E-R模型）联系模型方法为例，第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等，从而给出各部门内所用信息的厅部描述（在数据库中称为用户的厅部视图）。第二步再将前面得到的多个用户的厅部视图集成为一个全厅视图，即用户要描述的现实世界的概念数据模型。

3）逻辑建模：主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式，即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时，可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。

4）物理建模：根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施，对具体的应用任务选定最合适的物理存储结构（包括文件类型、索引结构和数据的存放次序与位逻辑等）、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。

多维数据模型：数据仓库的概念模型设计是在需求分析模型基础上，一方面，通过原有的数据库的设计文档、在数据字典中的数据库关系模式以及分析各种其它格式的数据，可以得出对现有的数据库中的内容一个完整而清晰的认识；另一方面，数据仓库的概念模型是面向企业全厅建立的，它为集成来自各个面向应用的数据库和其它形式的数据提供了同样的概念视图。概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时，不用考虑具体技术条件的限制。数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求。信息管理系统项目中往往把需求分析阶段的模型映射为主题，确定系统所包含的主题，然后对每个主题的内容进行更加明确的描述，描述的内容包括：主题的公共码键、主题之间的联系、主题的属性组等信息来源。

数据仓库逻辑模型是在概念模型设计的基础上，把概念模型的商业信息映射为相应的数据库的数据。它是数据仓库物理模型设计的基础，但与物理模型不同的是，它不依赖具体的数据库软件，主要目的是方便从一个数据库软件系统迁移到另一个数据库软件系统。

逻辑模型的工作主要有：分析主题，确定当前要装载的主题；确定粒度层次划分；确定数据分割策略；关系模型定义；一记录系统定义。逻辑模型设计的成果是对每个当前要装载的主题和逻辑实现进行定义，并将相关内容一记录在数据仓库的元数据中。

1、分析主题：在数据仓库的概念模型中，我们确定了多个基本的主题，但是，数据仓库的主要设计方法是原型法，是一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地迁移，工作逐步完成的。所以，我们必须对概念模型设计步骤中确定的几个基本主题进行分析，并选择首先要实施的主题。选择一个主题所要考虑的是它的规模适当，首先要足够大，以便使得该主题能建设成为一个可应用的系统；它还要足够小，以便于开发和较快地实施。如果所选择的主题太大并且很复杂，我们甚至可以针对它的一个有意义的子集来开发。在每一次的反馈过程中，都要进行主题分析。

2、粒度层次划分：数据仓库逻辑设计中要解决的一个重要问题是决定数据仓库的粒度划分层次，适当地划分粒度层次直接影响到数据仓库中的数据量和所适合的查询类型。确定数据仓库的粒度划分，来确定是采用单一粒度还是多重粒度，以及粒度划分的层次。单一粒度策略是指在直接存储细节数据，并定期对细节数据进行汇总。单一粒度策略适用于数据量较小的情况。多重粒度策略指数据仓库只保留近期的细节数据，而将距离目前时间较远的数据从数据仓库中迁移到备份存储设备中或删除，只在数据仓库或OLAP模型中保留其汇总数据，多重粒度策略适用于海量数据的情况。单一粒度策略和多重粒度策略的差别在于细节数据在数据仓库总存储时间的长短。

3、确定数据分割策略：要选择适当的数据分割标准，一般要考虑以下几方面因素：数据量（不是表中的一记录行数）、数据分析处理的实际情况、简单易行程度以及粒度划分策略等。数据量的大小是决定是否进行数据分割和如何分割的主要因素；数据分析处理的要求是选择数据分割标准的一个重要依据，因为数据分割是跟数据分析处理的对象紧密联系的；还要考虑到所选择的数据分割标准应是自然的、易于实施的；同时也要考虑时间分割的标准与粒度划分层次是相适应的。

4、关系模式定义：数据仓库的每个主题都是由多个表来实现的，这些表之间依靠主题的公共码键（表现为维度的主键和事实表的外键）联系在一起，形成一个完整的模型。在概念模型设计时，就确定数据仓库的基本主题，并对每个主题的公共码键、基本内容等做了描述，在这一步里，将要对选定的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模型，一般是星型模型或雪花模型。但随着技术的发展，在软件厂商的推动下，用统一维度模型来描述多个主题和整个数据仓库结构。在统一维度模型中，事实表与维度表没有明显的区别，一个星型模型的事实表也可以作为另一个星型模型的维度表。

1. 1. 维度建模设计

数据仓库的维度建模技术是数据仓库的重要数据建模基础理论，只有充分把握数据仓库的维度建模技术的设计原则和方法才能对平台中的相关数据进行合理的建模。

维度建模是一套用于组织数据仓库数据的方法和技术，是按照用户分析数据的方式构建模型的。其基本思想是：几乎所有的业务数据都可以表示成某种数据立方体，该立方体的每一个单元格包含的是各种测度值，立方体的边是数据维度。

1、事实表（fact table）每个数据仓库都包含一个或多个数据表。事实数据表可能包含业务数据，如税款入库数，事实数据表通常包含大量的行。一般事实表中只存放数字或者一些Flag用来统计，如税费、数量、支出。

2、维度表（dimension table）维度表可以看做是用户来分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用的信息，维度表包含帮助汇总数据的特性的层次结构。

维度建模方式有三种：

1、星形

2、雪花性

3、多维建模OLAP

1. 1. 1. 粒度层次

确定粒度是数据仓库维度设计需要面对的一个最重要的设计问题。如果数据仓库的粒度确定得合理，设计和实现中的其余方面就可以非常顺畅地进行；反之，如果粒度确定得不合理就会使得其它所有方面都很难进行。粒度对于数据仓库体系结构设计人员来说也非常重要，因为粒度会影响到那些依赖于从中获得数据的数据仓库的所有环境。粒度的主要问题是使其处于一个合适的级别，粒度的级别既不能太高也不能太低。低的粒度级别能提供详尽的数据，但要占用较多的存储空间和需要较长的查询时间。高的粒度级别能快速方便的进行查询，但不能提供过细的数据。在选择合适粒度级别的过程中，要结合业务的特点，分析的类型、依据的总的存储空间的等因素综合考虑。其中分析的类型是最主要的因素。数据仓库中的粒度模型

所谓粒度，指的是数据仓库中数据单元的细节程度或综合程度的级别，是数据仓库中记录数据或对数据进行综合时所使用的时间段参数M。它决定了数据仓库中所存储的数据中数据综合程度高低的一个度量，它既影响到数据仓库中数据量的多少，也能影响到数据仓库所能回答的讯问的种类。粒度越小，则详细程度越高，综合程度就越低，回答询问的种类也越多；相反，粒度越大，则详细程度越低，综合程度就越高，回答询问的种类也就越少。另一种形式的粒度是样本数据库粒度，与通常意义下的粒度不同，样本数据库的粒度级别不是根据综合程度的不同来划分的，而是根据采样率的高低来划分的。采样粒度不同的样本数据库可以具有相同的综合级别。

样本数据库一般是以一定的采样率从细节档案数据或轻度综合数据中抽取的一个子集。它不是一般日的数据库，而是根据一定需求从数据源中获得的一个样本，因而也就不能回答一些细节性的问题。样本数据库的抽取可以按照数据的重要程度不同来进行。粒度的划分是数据仓库设计工作中一向重要内容。

1. 1. 1. 1. 粒度的划分

在实际中，上述两种形式的粒度都是存在的。在传统的操作型数据库系统中，对数据的处理和操作都是在详细级别上进行的，即在最低级别的粒度上进行的。由于数据仓库环境中心用的主要是分析处理，为了方便各种级别的分析应用，一般情况下，数据仓库中的业务数据可以按照粒度的分为4级：当前细节级、历史细节级、轻度汇总级和高度汇总级。对当前细节级的数据，一般保留在较低的粒度水平，数据具有较高的细节。随着时间的推移，按设定的时间阀值和粒度阀值，数据逐步汇总，依次形成轻度汇总级、高度汇总级的数据，以节约存储空间，降低系统开销。不同粒度级别的数据用于不同类型的分析处理。

进行粒度划分首先要做的是对数据仓库中的数据行数和所需的DASD（直接存取存储设备）数进行粗略估算。而往往也只是一个对数量级的估计。

第一步是确定数据仓库中要创建的所有表的数据及每个表的行数，然后估计表中每一行的大小。估算数据仓库中需要建立的表数目，估算每个表的行数，通常需要估计行数的上、下限。由于数据仓库的数据存取是通过存取所引来实现的，而索引是对应表中的行来组织的，即在某个索引中每行总有一个索引项。索引的大小只与表的总行数有关，与表的数据量无关。所以粒度的划分是总的行数而不是总的数据量决定的。

第二步是估计一年内表中可能的最少行数和最多行数。这是设计者要解决的最大问题。如：纳税人登记表，就要估计当前的纳税人数。如果当前没有业务，就将其估计为总的业务量与期望值的乘积。总之，以纳税人数的合理估算作为出发点；接下来，估计完一年的内数据仓库中数据单元的数量（用上下限推测法）后，用同样的方法对五年的数据进行估计。粗略数据估计完成之后，还要估算索引数据所占的空间。确定每张表的关键字或数据元素的长度，并弄清楚是否表中的每条记录都存在关键字。这每个表的数据存储空间就可以用表的存储空间与相应的索引空间之和表示。

对数据仓库的大小的粗略估计完成后，接下来需将数据仓库环境中的总行数与表进行比较。需要根据数据仓库环境中将具有的总行数的多少，采取不同的设计、开发及存储方法。以一年期为例，如果总行数少于100000行，那么任何的设计和实现实际上都是可行的，没有数据需要转移到溢出存储设备中去。如果总行数是100000行或略少，那么设计时需小心谨慎，但也不一定有数据转移到溢出存储器。如果在一年内总行数超过100000行，设计时不但要小心谨慎，而且有一些数据要转移到溢出存储器。

1. 1. 1. 1. 确定粒度级别

在数据仓库中确定粒度时，需要考虑以下几个因素：要接受的分析类型、可接受的数据最低粒度、能够存储的数据量。

计划在数据仓库中进行的分析类型将直接影响到数据仓库的糙度划分。将粒度的层次定义得越高，就越不能在该数据仓库进行更细致的操作。如：将粒度的层次定义为月份时，就不可能利用数据仓库进行按日汇总的信息分析。数据仓库通常在同一模式中使用多重粒度。其中可以有今年创建的数据力度和以前创建的数据粒度，这是以数据仓库中所需的最低粒度级别为基础设置的。如：可以用低粒度数据保存近期的财务数据和汇总数据，对时间较远的财务数据只保留粒度较大的汇总数据。这样既可以对财务近况进行细节分析，又可以利用汇总数据对财务趋势进行分析。

定义数据仓库粒度的另一个重要因素，是数据仓库中可以使用多种存储介质的空间量。如果存储资源有一定限制，就只能采用较高粒度的数据划分策略。这种粒度划分策略必须依据用户对数据需求的了解和信息占用数据仓库空间大小来确定。

数据粒度的确定实质是业务决策分析、硬件、软件和数据仓库使用方法的一个折中。从分析需求的角度看，希望数据能以最原始的，即细节化的状态保存，这样分析的结论才是最可靠的。但是，过低的粒度、过人的数据规模，会在分析过程中给系统的CPU和I/O通道增加过人的负担，从而降低系统的效率。因此必须结合业务数据的特点，确定合理的粒度值。系统的存储空间是另一个要考虑的因素。过小的粒度，非常细节化的数据，意味着极大的空间需求成本，极大的CPU与I/O压力。

从这个角度看，高粒度是合适的，但非常概括的数据往往意味着细节的损失和分析结论可靠性的降低。总之，粒度的确定没有严格的标准，它是在对业务模型深入了解的基础七，对分析需求、系统开销、软件能力等各方面因素进行综合考虑的折中，它的确定过程也是一个决策过程。

1. 1. 1. 维度建模的原则

遵循这些原则进行维度建模可以保证数据粒度合理，模型灵活，能够适应未来的信息资源，违反这些原则你将会把用户弄糊涂，并且会遇到数据仓库障碍。

原则1、载入详细的原子数据到维度结构中

维度建模应该使用最基础的原子数据进行填充，以支持不可预知的来自用户查询的过滤和分组请求，用户通常不希望每次只看到一个单一的记录，但是你无法预测用户想要掩盖哪些数据，想要显示哪些数据，如果只有汇总数据，那么你已经设定了数据的使用模式，当用户想要深入挖掘数据时他们就会遇到障碍。当然，原子数据也可以通过概要维度建模进行补充，但用户无法只在汇总数据上工作，他们需要原始数据回答不断变化的问题。

原则2、围绕业务流程构建维度模型

业务流程是组织执行的活动，它们代表可测量的事件，如下一个订单或做一次结算，业务流程通常会捕获或生成唯一的与某个事件相关的性能指标，这些数据转换成事实后，每个业务流程都用一个原子事实表表示，除了单个流程事实表外，有时会从多个流程事实表合并成一个事实表，而且合并事实表是对单一流程事实表的一个很好的补充，并不能代替它们。

原则3、确保每个事实表都有一个与之关联的日期维度表

原则2中描述的可测量事件总有一个日期戳信息，每个事实表至少都有一个外键，关联到一个日期维度表，它的粒度就是一天，使用日历属性和非标准的关于测量事件日期的特性，如财务月，有时一个事实表中有多个日期外键。

原则4、确保每个事实表中的事实具有相同的粒度或同级的详细程度

在组织事实表时粒度上有三个基本原则：事务，周期快照或累加快照。无论粒度类型如何，事实表中的度量单位都必须达到相同水平的详细程度，如果事实表中的事实表现的粒度不一样，企业用户会被搞晕，BI应用程序会很脆弱，或者返回的结果根本就不对。

原则5、解决事实表中的多对多关系

由于事实表存储的是业务流程事件的结果，因此在它们的外键之间存在多对多（M：M）的关系，如多个仓库中的多个产品在多天销售，这些外键字段不能为空，有时一个维度可以为单个测量事件赋予多个值，如一个保健对应多个诊断，或多个客户有一个银行账号，在这些情况下，它的不合理直接解决了事实表中多值维度，这可能违反了测量事件的天然粒度，因此我们使用多对多，双键桥接表连接事实表。

原则6、解决维度表中多对一的关系

属性之间分层的、多对一（M：1）的关系通常未规范化，或者被收缩的扁平型维度表中，要将其规范化或将M：1关系拆分成更小的子维度，维度反向规范化是维度建模中常用的词汇。

在单个维度表中多对一（M：1）的关系非常常见，一对一的关系，如一个产品描述对应一个产品代码，也可以在维度表中处理，在事实表中偶然也有多对一关系，如详细当维度表中有上百万条记录时，它推出的属性又经常发生变化。不管怎样，在事实表中要慎用M：1关系。

原则7、存储报告标记和过滤维度表中的范围值

更重要的是，编码和关联的解码及用于标记和查询过滤的描述符应该被捕获到维度表中，避免在事实表中存储神秘的编码字段或庞大的描述符字段，同样，不要只在维度表中存储编码，假定用户不需要描述性的解码，或它们将在BI应用程序中得到解决。如果它是一个行/列标记或下拉菜单过滤器，那么它应该当作一个维度属性处理。

尽管我们在原则5中已经陈述过，事实表外键不应该为空，同时在维度表的属性字段中使用“NA”或另一个默认值替换空值来避免空值也是明智的，这样可以减少用户的困惑。

原则8、确定维度表使用了代理键

按顺序分配代理键（除了日期维度）可以获得一系列的操作优势，包括更小的事实表、索引以及性能改善，如果你正在跟踪维度属性的变化，为每个变化使用一个新的维度记录，那么确实需要代理键，即使你的商业用户没有初始化跟踪属性改变的设想值，使用代理也会使下游策略变化更宽松，代理也允许你使用多个业务键映射到一个普通的配置文件，有利于你缓冲意想不到的业务活动，如废弃产品编号的回收或收购另一个家公司的编码方案。

原则9、创建一致的维度集成整个企业的数据

对于企业数据仓库一致的维度（也叫做通用维度、标准或参考维度）是最基本的原则，在ETL系统中管理一次，然后在所有事实表中都可以重用，一致的维度在整个维度模型中可以获得一致的描述属性，可以支持从多个业务流程中整合数据，企业数据仓库总线矩阵是最关键的架构蓝图，它展现了组织的核心业务流程和关联的维度，重用一致的维度可以缩短产品的上市时间，也消除了冗余设计和开发过程，但一致的维度需要在数据管理和治理方面有较大的投入。

原则10、不断平衡需求和现实，提供用户可接受的并能够支持他们决策的DW/BI解决方案。

维度建模需要不断在用户需求和数据源事实之间进行平衡，才能够提交可执行性好的设计，更重要的是，要符号业务的需要，需求和事实之间的平衡是DW/BI从业人员必须面对的事实，无论是你集中在维度建模，还是项目策略，技术/ETL/BI架构或开发/维护规划都要面对这一事实。

1. 1. 1. 维度表更新设计

数据仓库维度表的变化类型一般包括以下几种类型，维度表更新方法的选择依赖于其变化类型及数据仓库必须保存信息的类型。

1、大维度

通常根据两个因素来判断一个维度是否是大维度。一是大维度很深，就是有很多的记录；二是大维度很宽，即有很多的属性。大维度表的典型特征是有几千万条记录和超过100个的维度属性，且有多种层次结构。如税款主题中纳税人维度是典型的大维度表。由于数据量大，很多包含大维度的数据仓库运行效率可能很低，对事实表的查询涉及大维度表时效率会更低，需要选择正确的索引或其他的优化技术来处理许多问题。比如，向大维度表中填充数据；不限制维度的浏览性能，尤其是那些属性基数较小的维度；限制维度属性值的浏览时间等。

2、慢速变化的维度

通常大多数纳税人维度的修改并不频繁，年均大约一到两次。如果记录的数目只有几千行，那么为新属性值增加新记录的方法是可行的。即使纳税人维度的记录在100000行左右，数据操纵管理也不难。但对大维度表而言，即使是慢速变化的维度，数据更新效率也将大打折扣。通过考察修改维度表的因素，可以发现慢速变化的维度具有如下特征：绝大多数维度都不变；很多维度虽会变化，但变化很慢；源记录的纳税人键不会改变；纳税人描述及其他属性的改变都很缓慢；在源OLTP系统中，新的值会覆盖旧的值，但在数据仓库中，覆盖维度表的属性并不总是适当的做法。在运用维度表更新技术时应特别注意这些特征。

3、快速变化的维度

正如纳税人维度表一样，许多维度表有超过百万记录的数据，且在数据仓库管理过程中可能要对记录的属性进行大量修改，为保留历史数据，常使用修改后的属性值添加一条附加的维度记录的方法进行更新。如果这个属性再次修改，就要为最新的属性值再添加一条新的记录。如果一个客户维度的重要属性一年修改多次，这种快速变化的大维度表的更新问题就大了，在每一次增量装载后会产生大量的新记录，维度表将会变得杂乱无章。

如果快速变化的维度符合以下情况，那么上述数据更新技术在星型模式中依然是不错的选择。这种情况包括：

1）如果维度表保持扁平，并允许在维度表中不同属性间进行对称的浏览；

2）即使加入了额外的维度表行，维度表基本结构不变，事实表通过外键和所有维度表连接起来，仍将保持星型模式所具有的优势；

3）只有当最终用户的查询涉及修改过的属性时，同一位客户的多行记录才显现出来，其他的查询是看不出有多行记录的。当维度表太大且变化太快时，常用维度表更新方法是将大维度表分解成一个或多个较简单的小维度表，将快速变化的属性放到一个维度表中，而将缓慢变化的属性放在原来的表里。通过对大型、快速变化的维度分解，更新过的维度表基本会符合上述提及的三种情况

4、废弃维度

源OLTP系统或外部数据源中的大多数字段在维度表中是经常使用的，但有些标志或文本字段，如是/否标志、文本代码及自由格式的文本，是不会在维度表中出现的，部分字段还可能过时。不管怎样，原则上它们是不应被遗弃的。如何对这类属性进行处理?忽略掉所有的标志和文本不是一个好的选择，因为这样做可能会丢掉一些有用信息，部分字段在查询分析中也可能会用到。将标志和文本原封不动的放在事实表中将增大事实表的体积。不加选择地为这些标志和文本建立一个独立的维度表，其维度数目仍将很客观。较好的做法是选择那些有意义的标志和文本将放在一个单独的维度表中，那些“废弃”维度表属性对涉及标志/文本的查询来说是有用的。

1. 1. 1. 维度模型设计

维存在于关系式的表中，包含了键值和支持的属性，而且属性与所陈述的事实高度相关。对于属性一般使用简单易用的文字信息，不应该有代码或缩写，没有空值或NULL，没有无用或过时的数值。

维度使用解析过的时间、名字或地址元素，这样可以使你的查询更灵活。比如时间可分为年、季度、月、周和日等；个人的名字可以分为姓氏和称谓（如先生或小姐）；组织名可以用部门来区分；地址则可以用地理区域来区分（如国家、州省和、城市）。

不要使用业务数据库的键值，对每个维表另外增加一个额外的惟—值字段作为主键来识别维表实体，这个在维表中新设定的键也叫代理键。

维表至少包含一个决策因子，每个决策因子字段可以通过使用相关的主键来响应用户的查询。维度表应该包含有随时间变化的数据记录字段，当数据集市或数据仓库的数据随时间变化而有额外增加或改变时，维表的数据行应该随着维属性的变化而变化。

在数据仓库设计中，有一些维度是常用的，下面将列举几个常用的维度设计：

日期类维度设计

日期维度一般属于公共维度，根据不同行业特点，日期维度代表不同业务含义，也可以添加行业独特的日期属性。

系统中有许多税收业务日期属性都可以统一用日期维度来表示。

如下表：

申报征收
申报日期错误	缴款期限	填表日期	更正日期	录入日期
修改日期	调帐日期	应征发生日期	缴款发生日期	上解日期
上解销号日期	入库日期	入库销号日期	开票日期	作废日期
有效期起	有效期止	……
发票
发票销售日期	发票退票日期	发票缴销日期	发票鉴定日期	结存日期
有效期起	有效期止	领购日期	遗失被盗日期	。。。
违法违章和稽查法制
案源登记日期	案源处理日期	实施登记日期	实施移转日期	审理登记日期
案件结束日期	文书送达日期	实际履行日期	执行完毕日期	处理处罚决定日期
处理处罚入库日期	……

日期维度的属性一般可以有日期全称、日历月、日历季度、日历年、节假日标志、月首标志、月末标志等等。

税务里面另一个重要的带业务含义的日期类维度是所属时期维度。由于其和税种、税款和业务的紧密关联性，可单独构建一个维度，而不是用业务系统中的所属时期起、所属时期止两个日期。

所属时期维度主要属性如下表：

属性名称	属性描述	举例
所属时期起、止	税款所属时期起止日期	2017-6-1~2017-6-30
所属时期名称	税款所属时期全称	2017年1月
所属时期类型	税款所属时期的月、季度、年类型	月、季度、年
所属时期月	税款所属时期的月份	2017年1月、2017年2月
所属时期季度	所属时期的季度	2017年Q1、2017年Q2
所属时期年	所属时期的年度	2017年

单位维度设计

单位维度是系统中最重要的维度，也就是客户维度。

单位维度对应于生产系统中的单位基本信息表、单位基本信息扩展表，另外在此基础上可添加其他统计类属性等。

单位维度属于大型渐变维度，在实际应用中可适当进行优化处理。一般方法是将分析频率高或者变化频度大的属性拆成微型维度，微型维度关键字直接放入事实表中这种微型维度一般不要超过10万行记录。如果超过，可以再进行拆分。

也可以根据业务类型进行筛选，如针对小规模企业的业务分析，可单独建立小企业维度。依此方法可得到一般企业维度、重点企业维度等等。

代码表转维度表

代码表转维度分几种情况

1、简单代码表

只有代码、名称。如申报方式、征收方式等。转换也最简单，分两类：如果代码表只是客户维度的属性，那么直接按属性走，不单独建维度。例如“法人证件类型”；

如果代码表非常独立，直接体现在事实中，那么直接建立最简单的维度。

2、带固定层次的代码表

一个或者多个代码表构建的层次代码表，例如行业（由行业门类、行业大类、行业等多个代码表构建）、登记注册类型（单个代码表构建）直接构建具有层次关系的维度，将层次关系体现在最小代码的属性中。例如行业维度，将行业门类和行业大类作为行业维度的属性放到行业维度表中；

3、带非固定层次的代码表

代码具有层次关系，但没有固定层次深度，例如行政区划，则通过构建“桥接表”来做维度表和事实表间桥接作用，实现层次查询统计需求；

4、普通代码表，多个文本属性

直接构建维度；

5、普通代码表，属性中带有其他代码表，但无层级关系。

此种类型有以下三种处理方式：

第一种，如果属性代码表只是和该代码表相关，并且本身无名称外其他属性，则直接作为属性存储文本。

第二种，如果属性代码表只是和该代码表相关，但身有很多文本属性。那么小型表可以引入交叉组合共同组成普通代码表的属性。如果记录数多，也可以采用扩展雪花型。这种情况较少。

第三种，如果属性代码表本身具有成立单独维度需要。那么这里需要考虑联合分析的重要性，如果不是很重要，那么不建议用雪花模型扩展（代码表维度属性存储属性代码表的维度关键字），而是采用同时存储属性代码的代码和名称，这样既满足本身统计需求，万一需要进行关联分析，也可以通过代码表关联到单独维度进行访问。典型设计为纳税人维度中行业代码和行业名称的存储。

维度属性一般直接采用规则性文本而不是生产业务系统的业务代码，这样可以有效提高模型的易读性。但是，在实际项目应用中往往还是会把代码和名称属性同时放入维度属性中，主要针对需要展示代码的需求。在代码和名称属性同时存在的时候，两个属性的渐变维度处理类型必须一致。

在维度建模过程中，往往会发现维度其实就是很多业务表单中各种除去各类业务数据项外的各类时间、日期、人员、机关和业务代码类信息，事实上也是如此。一般各类业务日期、组织结构、组织人员、业务代码表都会成为最终的维度或者维度属性。

1. 1. 基础汇总表的建设及数据整理
    1. 编码表的整理

随着时间的推移任何业务系统的编码都有可能发生变化。而数据仓库要保存数十年的数据，对历史数据进行经常性的替换是不可能想象的事情。怎么解决这个问题对数据仓库来说是个至关重要的问题。

项目建设中必须对历年的编码标记时间戳，在还原数据或展现数据时以当年的编码还原，以保证历史数据的真实性。

1. 1. 1. 聚合表的建设

为了提高数据利用的效率，对经常使用的数据可以进行适当的聚合，其目的是增大数据的粒度，降低细致度，减少记录数，提高OLAP分析的效率。

数据采集、转换、加工的轨迹可以这时候可以用E-R图进行数据仓库内容的具体设计。要注意的是E-R的设计基础是基于第三范式（3NF）。虽然第三范式（3NF）是基础，但是仅仅满足于第三范式对数据仓库来说是不够的，为了提高展示层查询速度和多维分析的方便性，在部分实体里可以适当的保持一定的稳定的字节数不长的不经常变化的冗余。

1. 1. 1. 衍生表的建设

数据仓库中总有一部分数据是重要的，经常使用的，我们称其为重点数据。对重点数据的分析往往要求比较高的细致度。而细致度高，粒度就小，数据量就大。这与效率又形成了矛盾。解决这个问题的方法就是建设衍生表。

衍生表加载的是没有聚合的原始粒度的数据的其中一部分数据。

1. 1. 1. 汇总的几个关键

基础汇总的建设过程中把握下列几个关键：

1、设计和实施过程中始终以主题为目标；

2、各个主题单独设计，不能交叉；

3、数据加载（Load）的实体不建议使用物理表，以便于对ETL过程的追踪；

4、在数据汇总之前要遵循数据库第四范式（4NF）的设计要求将多对多的数据转换成一对多的数据；

5、合理的设计粒度的大小，粒度太大，影响数据挖掘的效果，粒度太小，影响查询统计的速度；

6、经常调整口径的部位不建议采用实体；

7、运算复杂的部位不建议采用实体；

1. 1. 1. 满足第五范式（5NF）的要求

在汇总过程中要遵循数据库第五范式（5NF）的设计要求保证汇总的数据能追踪到原始数据。

1. 1. 多维分析（OLAP）建设

多维分析常被人们解释为OLAP，其实多维分析的概念比OLAP更早，到今天为止国际上对多维分析（或OLAP）还没有一个标准，只有工程经验，更没有上升到理论。

多维分析建模图

多维数据集的维度与事实（也称为“量度”）相关联。用关系术语来讲，事实与维度之间具有多对一关系。维度和事实都存储在单个表上。因此，用关系术语来讲，事实表是维度表的子表。目前世界上研究和实践多维分析的人们越来越多，归集起来都是从两个方向展开，一个方向从展示层展开，开发可以交由前台操作人员直接使用的OLAP工具，他们的贡献在于将多维数据集与SQL集成在一起。另一个方向是从数据存储方向展开。多维数据库是其中的实例。多维数据库不是数据仓库，而数据仓库可以包容多维数据库。因此本系统可以根据业务需求在数据仓库中建设支持业务分析的多维数据库。

多维分析库的建设是基于数据库第三范式（3NF）的理论，在同一个主体域内的数据往往有多种状态，每一个状态都有一个多维分析实体，多个实体之间的钩稽关系的校验往往比较困难。这样就容易形成单个的多维分析实体都是正确的，但是多种状态之间的钩稽关系方面会出现重复，这也是当前多维理论不完善的情况下，在同一套数据源生成的多个多维分析结果会出现不一致的情况。

分析其中的原因就是同一类业务数据在同一个时刻在不同的状态发生了两个以上的业务，这在理论上是不可能的，但是业务操作型软件是无法避免的，特别是在大数据量情况下的操作很难幸免。

所以在数据仓库建设中应该引入数据库第四范式（4NF）理论，解决多对多的问题。这部分将在主题域建设中讨论。

1. 1. 主题域的划分与建设
    1. 主题的概念

主题（Subject）是在较高层次上将平台中的数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对应某一宏观分析领域所涉及的分析对象。

面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及部门的各项数据，以及数据之间的联系。所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。例如，一个数据仓库所组织的主题可能有税款分析、税务登记分析和发票分析等。而按应用来组织则可能为征收系统、登记管理子系统、发票管理子系统、稽查子系统和流程管理子系统。

主题是根据分析的要求来确定的。这与按照数据处理或应用的要求来组织数据是不同的。如在税务厅中，同样是征收数据，在操作型数据库系统中，人们所关心的是怎样更方便和更快捷地进行税款征收的业务处理；而在进行分析处理时，人们就应该关心的是税款的税种和入库是否及时，以及入库的预算级次等。

数据仓库面向在数据模型中已经定义好的主要主题领域。例如主题领域包括税款信息、登记信息、发票信息稽查信息、纳税人财务信息、政策执行信息、执法信息、管理过程信息以及纳税评估信息和税收预警信息的状态和结果。

从上述文字的描述我们可以看出主题的划分出元数据的整理就开始了，实际上元数据的分类方法就是主题的分类方法。

1. 1. 1. 主题域的获取

主题域是对某个主题进行分析后确定的主题的边界。分析主题域，确定要装载到数据仓库的主题是信息打包技术的第一步。而在进行数据仓库设计时，一般是一次先建立一个主题或部门全部主题中的一部分，因此在大多数数据仓库的设计过程中都有一个主题域的选择过程。主题域的确定必须由最终用户和数据仓库的设计人员共同完成。

主题域设计的关键是确定主题的边界，主题的边界确定依赖于业务边界的确定，而业务边界常常有交叉，业务部门常常有同等的地位和解释权，而数据仓库的主题不允许有模糊的边界，这就需要用户协调或由上一级用户确定业务的边界，在内部称为统一口径。

举例如下：

申报税款是征管部门的口径，在计划统计部门就没有这个名词，因为申报税款在经过一定时期以后可能在计划统计部门就变成了本年新欠或往年陈欠。而主题的最起码的要求就是在同一个时刻元数据只能允许有一个状态。在那么在税款主题边界划分时怎么确定统计口径必须由最终用户和数据仓库设计人员共同完成。

1. 1. 1. 主题的设计原则

1、确定数据规划中整理的业务元数据中的状态元数据的业务边界；

2、按照业务元数据中的状态元数据划分主题；

3、将状态元数据作为作为主题的基础维度，按照一类状态元数据只有一个主题的原则规划和设计主题。这一步操作可以借用工具也可以在纸上进行；

4、检查主题的数量，在全厅数据仓库中主题应该是唯一的；

5、检查所有主题的的基础维度，在全厅数据仓库中基础维度应该是唯一的；

6、按照状态元数据的分类检查在各个主题中有没有交叉，不允许同一类状态元数据在不同的主题中出现；

7、根据分析业务的需要和细致度（或粒度）设计的要求对每个主题补充属性类元数据。属性类元数据作为属性类维度出现在各个主题中，属性类维度允许在不同的主题中有交叉有重复。

8、以各个主题为目标寻找数据源，这就是数据驱动。

9.根据数据源归集的难易程度和自己掌握的工具情况设计主题的结构，可以选择雪花型或星型结构，有条件的尽量选择星型结构。前面已经论述过星型结构运行效率高，磁盘空间耗用少，数据之间的钩稽关系便于检查。如果仅仅会使用工具而难于编程选择雪花型结构容易实现。无论那种结构都可满足数据仓库的设计要求。

1. 1. 1. 主题结构

数据仓库的数据结构有两种方式：雪花型数据仓库和星型数据仓库，星型结构就是在同一张表里有不同的列，雪花型的结构是在不同的表里有相同的列。这里的列是指的数据列（数据项），也就是基础状态元数据。以税金的运动过程举例：税金类的基础状态元数据是应征、上解、入库。在星型结构里把应征、上解、入库放在同一张数据表里，这三列数据反映了税金的三个状态，如果税金的运动走过了全过程并且中间没有发生变化，那么在这三列里都可以看见数据，而且数据的大小是一样的。

而雪花型把三个税金类的基础状态元数据分别存放在三张数据表里，每张表里只有一个数据项，形成了应征税金表，上解税金表和入库税金表。三张数据表才能反映税金运动的全过程。两种结构方式各有优缺点。

1. 1. 1. 雪花型数据结构

雪花型数据仓库的优点是数据模型直观，部署简单，操作容易，一般支持第三范式（3NF）的工具都可以部署。缺点是占用磁盘空间比较大，数据更新效率比较低，数据的钩稽关系难于校验。在做多状态数据分析的时候，联结（JOIN）比较多，运行效率不高，在加工带有数据状态报表的时候效率更低。

在简单多维分析的情况下可以采用这种方式，一般复杂状态查询和加工报表都不推荐这种方式。以下以涉税数据建模为例：

应征税金雪花型结构：

入库税金雪花型结构：

欠税税金雪花型结构：

从结构图可以看出，雪花型结构要描述税款运动过程中的4个状态需要部署4个实体。

1. 1. 1. 星型数据结构

星型数据仓库的优点是把同一类型业务不同状态的元数据放在同一实体里（同一表里有不同的列），多级星型级联可以形成一套树状结构，数据之间的钩稽关系易于校验。便于对数据仓库中的数据进行跟踪和维护。对业务过程的状态分析比较容易，不需要很多的关联（JOIN）。在相同的主题域的情况下占用磁盘空间比雪花型少。数据更新效率相对比较高。缺点是数据建模比较麻烦，操作相对困难，有些复杂的星型结构用一般的工具很难部署，甚至需要专业程序员写代码。

一般复杂状态数据分析和加工报表等类业务推荐这种方式。

1. 1. 1. 实例：税款主题数据的模型设计及数据加工路径

本方案选取税款主题说明数据模型的设计和数据加工（从数据源到主题数据，再到汇总层）的过程。

税款的逻辑数据模型如下图所示：

由于税款的元数据比较多，推荐按星型主题结构设计，其优点如下：

1、结构简单易于物理数据模型（physical data mode）的实现；

2、元数据集中存放，便于勾稽关系的校验；

3、便于数据一致性的检查；

4、磁盘空间占用较少；

5、数据加工耗时少，有利于提高数据仓库运行效率；

6、前台BI的展现开发易于读取，简化BI的设计，提高BI的开发效率；

由于税款数据逐年增加，数据量和数据的变化量比较大，有利于分区管理（在数据生命周期管理里面论述）；

下图是数据聚合的过程：

经过数据加工、聚合后，税款类的数据结构变为税款主题的数据仓库模型结构，数据的粒度逐渐变大。

1. 1. 物理模型

物理模型确定数据的存储结构、索引策略、数据存放位置、存储分配。确定数据仓库实现的物理模型，要求设计人员必须做到以下几方面：全面理解所选用的数据库管理系统，特别是存储结构和存取方法；了解行业特定的数据环境、数据的使用额度、使用方式、数据规模以及用户对响应时间要求等，这些是对时间和空间效率进行平衡和优化的重要依据；了解外部存储设备的特性，如数据文件的分配、分块原则、块大小的特性等。

1、数据的存储结构：一个行业的数据库管理系统往往都提供多种存储结构供设计人员选用，不同的存储结构有不同的实现方式，各有各的适用范围和优缺点，项目设计人员在选择合适的存储结构时应该权衡三个方面的主要因素；存取时间、存储空间利用率和维护代价。

2、索引策略：数据仓库的数据量很大，因而需要对实际的存取路径进行仔细的设计和选择。由于数据仓库的时间是比较稳定的，但涉及到延后计算的数据往往需要保留中间结果，经常需要对表进行插入（INSERT）、修改（UPDATE）、删除（DELETE）操作，这与传统数据库管理项目非常相似，因而可以设计多种多样的索引结构来提高数据存取效率。

3、数据存放位置：在物理设计时，项目中常常要按数据的重要程度、使用频率以及对响应时间的要求进行分类，并将不同类型的数据分别存储在不同的存储设备中。重要程度高、经常存取并对响应时间要求高的数据就存放在高速存储设备上，如硬盘或其它高速设备；存取频率低或对存取响应时间要求低的数据则可以放在低速存储设备上，如磁盘或磁带。

1. 1. 存储分配

许多数据库管理系统提供了一些存储分配的参数供数据仓库设计者进行物理配置，优化数据的处理，如：块的尺寸、缓存区的大小和个数等，它们都要在物理设计时确定。这同创建数据库系统时的考虑是一样的，不同的是应该明自数据仓库项目的特点是读和查询操作的性能优先，而不是写操作。

1. 1. 1. 数据集市建设

在许多应用环境中，部门/工作组要求在内部获得一种适合自身应用、容易操作、可自行定向、方便高效的开放式数据接口工具。与数据仓库相比，这种工具应更紧密集成、拥有完整的图形用户接口和更吸引人的价格。数据集市将满足部门/工作组的这种需求。数据集市是一种更小、更集中的数据仓库，它提供了一条部门/工作组级的分析数据的相对廉价的选择。数据集市具备的特性包括：规模小、面向特定的应用、面向部门/工作组、快速实现、投资规模小、易使用、全面支持异种机平台等。用户可根据自己的需求，以自己的方式来建立数据集市，而且数据集市间可以相互对话、沟通。

1. 1. 数据集市的分布

以获取数据源的两种不同方式可以将数据集市可以分为非独立性的数据集市和独立性的数据集市。

1. 1. 非独立型数据集市

非独立性的数据集市是以数据仓库为数据源的数据集市，通过定期更新接收来自主数据仓库的部分数据，为特定的部门/工作组提供信息。

1. 1. 独立型数据集市

而独立性的数据集市是以当前应用环境为数据源的完全独立的数据仓库，作为分布式数据库的成员补充总体结构。

无论数据集市以何种形式存在，他们都必须被设计为主数据仓库的组件，以使数据的组织、格式和结构在整个数据仓库体系结构中保持一致，这样使得信息在整个企业内保持一致和可用。

在前面已经论述了系统采用了“自上而下”的数据仓库设计方式，那么这里的数据集市就没有必要采用独立类型，而最好采用非独立的数据集市。这样更简单快捷，数据一致性好，便于横向和纵向发展，扩展性好，同时满足全厅数据的钩稽关系，不会形成信息孤岛。方法如下图所示

非独立类数据集市原理图

非独立集市可以规矩业务规则直接从主题域里抽取元数据从而形成自己的部门级数据。由于抽取的是业务元数据一般都不需要再进行二次转换和清洗，可以直接将一个或多个主题的元数据加载到数据集市里去。这种方法简单有效，而且运行效率高，查询速度快，计算机资源消耗少。

1. 1. 1. 数据生命周期管理

4.7.1 数据生命周期的特点

数据生命周期具有下列特点：

1、数据生成后，随着时间的推移，其访问频率将逐步下降。

2、数据被保留的时间越来越长。

3、被删除的数据越来越少。

不常访问的数据被迁移到较便宜的介质上，以节省存储投资。

4.7.2 数据生命周期管理的方法

数据生命周期管理是一种基于策略的方法，用于管理信息系统的数据在整个生命周期内的流动：从创建和初始存储，到维护和发布，最后到它过时被删除。

通常通过分层存储管理提高数据利用率，实现数据和存储基础结构的简化和自动化管理，获得成本高效的数据存取、业务连续性和保护解决方案。

作为一项规则，较新的数据和那些很可能被更加频繁访问的数据，应该存储在更快的，并且更昂贵的存储媒介上，而那些不是很重要的数据则存储在比较便宜的，稍微慢些的媒介上。通过将存储基础结构和管理与数据的价值相匹配，从而以最低的数据持有成本提供最大的数据利用价值。

4.7.3 具体实现策略

根据不同生命周期的数据的活跃程度制定不同的管理、存储和迁移策略，如活跃类型的数据应保存在高性能存储设备上，如高性能的存储阵列，而对于历史或归档的数据可存储在在线归档存储或磁带等离线存储上，以减少不必要的存储成本等等。

平台将所有数据分为四个层次管理，分别为数据准备区，统一数据视图，明细汇总库和数据集市及归档数据，如下图所示。

平台数据管理层次图

数据准备区：抽取各个生产系统和外部交换系统的数据，包括主数据以及原始表单形成数据准备区。

统一数据视图：分主题汇集的主数据。

数据仓库和数据集市：数据仓库抽取、转换、加载来自统一数据视图的数据，数据粒度包括从明细到轻度汇总、中度汇总、高度汇总。汇总程度越高，数据粒度越大，数据在线保留时间越长，所体现的业务事实越宏观。数据集市是数据仓库的子集，通常将明细数据聚合为汇总数据，同时在汇总数据上的分析可下钻到明细数据，主要目的是支持各种不同的前端主题应用。

归档数据：来自于各个层面很少用或不用的数据迁移，建议该层数据按照国家最高级别，并以符合国家电子档案标准的形式保存。

实现思路：

数据仓库中不仅包括事实表和维表，还包括大量的实视图，因而对数据仓库的增量式维护必须针对它们分别进行。由于维表的变动非常小，如时间维的信息，一年十二个月，每年分为四个季度这些信息都是固定的，再如地理位置信息，城市名和地区名变化的可能性非常小，因而本文中的增量式刷新机制将主要围绕事实表和实视图来讨论。

为了保存历史数据，对数据仓库的更新通常只涉及到插入操作，但是为了叙述的完整性，以及以后扩充的需要，本文所讨论的更新操作也将包括删除的情况。只要将相关的算法稍作修改，就可以适用于只包含插入的情况，而且此时的算法复杂性只会更低。事实上，采用本文所提出的体系框架，即使包括删除操作，也很容易实现对历史数据的保存。至于UPDAT操作，在文中将被分解为删除（DELETE）和插入（INSERTION）两个操作。

对事实表的刷新相对来说要简单一些，但对事实图的维护就要复杂的多，因为它包含了许多聚集函数，如（SUM，COUNT，MIN，MAX等）。聚集函数的存在增加了实视图维护的复杂性，这种复杂性使得实视图的维护周期变长，考虑到在维护的过程中这些实视图对用户是锁定的，为了减少它们对用户不可见的时间，实视图的维护过程将被分为两个阶段完成，它们分别是传送阶段（PROPAGATE和刷新阶段（REFRESH）。其中，在传送阶段数据仓库对用户来说仍然是可以访问的，而在刷新阶段仓。

数据模型管理
1. 统计分析模型

本系统重点在于对数据的整理和分析，分析的方法有多种，主要有比较分析法、比率分析法、构成分析法、趋势分析法、图表分析法、因素分析法、平衡分析法、因素归纳法等等。

分析功能是以比率分析和比较分析为主，其中比较分析法中的历史对比、计划对比还作为另一条横线贯穿于比率分析、同类型比较分析、结构分析中。

所有分析项目如各种比率、因素、结构层次等均可以自行定义，用户可以根据实际需要进行修改、增加操作，这样大大提高了系统的灵活性和适应性，软件提供了一套和报表几乎一样的取数公式，可以直接从报表系统内的各种报表中直接取数，也提供了鼠标直接点击式的报表取数单元功能，可以方便地从某类表的某单元内取数，此外，还允许一定程度上的手工直接输入数据，如计划、预算、参考数等。对于财分析结果，软件提供打印输出、以Excel、文本文件输出或以Windows的块拷贝转出，并且还可以以多种统计图形方式显示，如直方图、折线图、圆饼图等等，图形还可以是二维、三维效果。

由于软件的分析项目全部可以自由设置，并且都可以设置一个计划值（包括月计划、季计划、年计划），所以在操作上比较灵活。

一般地说，在手工操作中，进行分析需由以下几个相互联系的步骤组成：

1）确定分析目的，制定分析计划；

2）收集资料（数据和信息）

3）整理资料

4）提出分析报告

而在本系统中，用户只需通过"设置分析项目"这一操作过程即可完成以上操作步骤，然后通过"分析"菜单即可查看到相应的分析报告，并可将其打印出来

1、交叉汇总分析

系统可以根据需要定义各类预算执行分析报表，并以链接的方式发布到系统菜单中，终端用户（用户）可以直接使用该报表。

系统可以定义分组汇总列（如预算科目，税种，区划）查询时可以逐级汇总。

系统可以定义统计列（每日发生额，本年累计发生额）等按照预算级次、区划、或者月份、年度、季度等展开。

2、向下追溯和向上汇总

系统可以按照已经定义好的各类组合，层层向下追溯，直至追溯到明细。对税收收入类数据可以按照行政区划（本级、区县）、月份、季度、年度、收入分类等进行向下挖掘，并最终能追溯到明细。非税收入类数据可以按照月份、季度、年度、非税收入项目、主管部门等进行追溯，并最终能追溯到明细。

系统可以实现区划，收入分类等逐级向上汇总，即可以通过上钻的方式，分不同的页面显示不同层次上的汇总信息，也可以实现在一个页面内以表格的方式展示每个级次的汇总信息。

3、同期或不同期对比分析

系统可以将统计列衍生出同期对比统计列，如收入本年累计完成可以衍生上年或历年累计数，上年或历年对比增长率；收入本月累计完成可以衍生当月、当季、当年累计、上年或历年同期对比、同期增长率。报表比较分析主要有以下两种方式：

1）对同一时期（在本系统中指某个月、季、年）的相关数据进行的比较。

2）对不同时期间（年、月）的相关数据进行对比。此种对比分析作为另一条横线惯穿于比率分析、同类型比较分析、结构分析中。

对于这种对比系统提供3种方法：全年对比、当前条款全年对比、当前条款所有年度同期对比。对比分析的结果都用图形表示。

4、结构比重分析

结构分析是指将同一财务报表内部各项目之间进行比较，即将财务报表上的某一关键项目的金额设为100%，而将其余项目与之相比，以显示各项目的相对地位，分析各项目的比重是否合理，所以也称结构百分比。下面将详细介绍结构分析法中“设置分析项目”和“分析”的操作方法。

5、比率分析

比率分析是将两项相互依存、相互影响的财务指标进行商除计算，这是从现象到本质的一种认识深化。比率分析包括：设置比率分析项目、比率分析、比率对比。

关于计划对比，只要再选择分析功能中的“计划对比”项，软件将列出所有的年、季、月供选择，选择后图形中将增加计划的线条。

6、趋势分析

趋势分析必须建立影响预计发生值的参数模型。

1. 预测分析模型

1、时间序列预测法

时间序列，也叫时间数列、历史复数或动态数列。它是将某种统计指标的数值，按时间先后顺序排到所形成的数列。时间序列预测法就是通过编制和分析时间序列，根据时间序列所反映出来的发展过程、方向和趋势，进行类推或延伸，借以预测下一段时间或以后若干年内可能达到的水平。其内容包括：收集与整理某种社会现象的历史资料；对这些资料进行检查鉴别，排成数列；分析时间数列，从中寻找该社会现象随时间变化而变化的规律，得出一定的模式；以此模式去预测该社会现象将来的情况。

时间序列预测法可用于短期、中期和长期预测。根据对资料分析方法的不同，又可分为：简单序时平均数法、加权序时平均数法、移动平均法、加权移动平均法、趋势预测法、指数平滑法、季节性趋势预测法、市场寿命周期预测法等。

2、多元线性回归

回归分析是通过一组预测变量（自变量）来预测一个或多个响应变量（因变量）的统计方法。多元线性回归分析一般有以下五种方法：加入回归法、逐步回归法、移除回归法、向前回归法和向后回归法。在预测变量较多、变量之间存在共线性的情况下，一般采用逐步回归法：

1）考虑所有可能的简单线性回归，找出能够解释最大部分Y变差的变量。

2）下一个被列入模型的是对回归平方和贡献最显著的变量，贡献的显著性由F检验确定。

3）如果一个新的变量加入模型，则利用F检验来检验每个变量对回归平方和贡献的显著性。

4）重复步骤2和步骤3，直到所有可能增添的变量均不显著，所有可能剔除的变量均显著时为止。

3、ARIMA模型

ARIMA是通过自身（或多元时间序列）的过去值、过去误差进行趋势序列预测的建模过程。ARIMA建模过程一般包括三个阶段：

1）识别变换阶段。Arima建模的前提是序列的期望值和自协方差都不依赖于时间，即要求噪音序列必须平稳。一般的解决方法是数据变换、平滑或差分，直至符合建模的基本要求为止。

2）估计诊断阶段。我们可以进行Log转换、P阶自回归、Q阶滑动平均、D阶差分等Ariam模型的估计和诊断操作，计算出参数估计值等一系列诊断检验结果。

3）修正预测阶段。根据不断的修正和择优，运用最后确定的变量和参数估计建立Arima模型，再利用模型方程计算出预测值、标准误差以及置信区间。

4、Forecast过程

Forecast是通过自动趋势外推进行一元时间序列（或多元时间序列）拟合参数的建模过程。Forecast预报过程包括三种方法：一是在具有短期波动（或同时具有时间趋势的短期波动）的模型中，适用Stepar方法，它使用向后逐步选择参数的方法对趋势模型的残差拟合自回归。二是在具有长期确定性波动的模型中，适用Expo方法，它使用类似于整体移动平均的方法对趋势模型拟合参数。三是在具有季节性波动（或具有时间趋势的季节波动）的模型中，适用Winters（或Addwinters）方法，它使用类似于指数平滑的修正方程对趋势序列拟合参数。数据挖掘方法

5、神经网络方法

神经网络由于本身良好的健壮性、自组织自适应性、并行处理、分布存储和高度容错等特性非常适合解决数据挖掘的问题，因此近年来越来越受到人们的关注。典型的神经网络模型主要分3大类：以感知机、BP反向传播模型、函数型网络为代表的，用于分类、预测和模式识别的前馈式神经网络模型；以Hopfield的离散模型和连续模型为代表的，分别用于联想记忆和优化计算的反馈式神经网络模型；以ART模型、Koholon模型为代表的，用于聚类的自组织映射方法。神经网络方法的缺点是"黑箱"性，人们难以理解网络的学习和决策过程。

6、遗传算法

遗传算法是一种基于生物自然选择与遗传机理的随机搜索算法，是一种仿生全局优化方法。遗传算法具有的隐含并行性、易于和其它模型结合等性质使得它在数据挖掘中被加以应用。

Sunil已成功地开发了一个基于遗传算法的数据挖掘工具，利用该工具对两个飞机失事的真实数据库进行了数据挖掘实验，结果表明遗传算法是进行数据挖掘的有效方法之一。遗传算法的应用还体现在与神经网络、粗集等技术的结合上。如利用遗传算法优化神经网络结构，在不增加错误率的前提下，删除多余的连接和隐层单元；用遗传算法和BP算法结合训练神经网络，然后从网络提取规则等。但遗传算法的算法较复杂，收敛于局部极小的较早收敛问题尚未解决。

7、决策树方法

决策树是一种常用于预测模型的算法，它通过将大量数据有目的分类，从中找到一些有价值的，潜在的信息。它的主要优点是描述简单，分类速度快，特别适合大规模的数据处理。最有影响和最早的决策树方法是由Quinlan提出的著名的基于信息熵的ID3算法。它的主要问题是：ID3是非递增学习算法；ID3决策树是单变量决策树，复杂概念的表达困难；同性间的相互关系强调不够；抗噪性差。针对上述问题，出现了许多较好的改进算法，如 Schlimmer和Fisher设计了ID4递增式学习算法；钟鸣，陈文伟等提出了IBLE算法等。

8、粗集方法

粗集理论是一种研究不精确、不确定知识的数学工具。粗集方法有几个优点：不需要给出额外信息；简化输入信息的表达空间；算法简单，易于操作。粗集处理的对象是类似二维关系表的信息表。目前成熟的关系数据库管理系统和新发展起来的数据仓库管理系统，为粗集的数据挖掘奠定了坚实的基础。但粗集的数学基础是集合论，难以直接处理连续的属性。而现实信息表中连续属性是普遍存在的。因此连续属性的离散化是制约粗集理论实用化的难点。现在国际上已经研制出来了一些基于粗集的工具应用软件，如加拿大Regina大学开发的KDD-R；美国Kansas大学开发的LERS等。

9、覆盖正例排斥反例方法

它是利用覆盖所有正例、排斥所有反例的思想来寻找规则。首先在正例集合中任选一个种子，到反例集合中逐个比较。与字段取值构成的选择子相容则舍去，相反则保留。按此思想循环所有正例种子，将得到正例的规则（选择子的合取式）。比较典型的算法有Michalski的AQ11方法、洪家荣改进的AQ15方法以及他的AE5方法。

10、统计分析方法

在数据库字段项之间存在两种关系：函数关系（能用函数公式表示的确定性关系）和相关关系（不能用函数公式表示，但仍是相关确定性关系），对它们的分析可采用统计学方法，即利用统计学原理对数据库中的信息进行分析。可进行常用统计（求大量数据中的最大值、最小值、总和、平均值等）、回归分析（用回归方程来表示变量间的数量关系）、相关分析（用相关系数来度量变量间的相关程度）、差异分析（从样本统计量的值得出差异来确定总体参数之间是否存在差异）等。

11、模糊集方法

即利用模糊集合理论对实际问题进行模糊评判、模糊决策、模糊模式识别和模糊聚类分析。系统的复杂性越高，模糊性越强，一般模糊集合理论是用隶属度来刻画模糊事物的亦此亦彼性的。李德毅等人在传统模糊理论和概率统计的基础上，提出了定性定量不确定性转换模型--云模型，并形成了云理论。

大数据服务平台

财政大数据服务平台主要是为了提高财政服务水平，坚持“共建共享、服务决策、支撑改革”的大数据服务建设理念，为外部提供数据包进行再利用，依据数据标准提供财政专用数据包供政府部门间共享，同时为财政生产系统提供便利化辅助支出，从而实现财政服务管理互联网化、移动化和专业化。

1. 1. 1. 模块功能描述

随着国家大数据战略的推进和大数据应用的深化，政府为民服务的大数据时代已经来临。对政府公共服务而言，大数据之为重要的意义在于用数据创造更大的公共价值，提升政府服务能力，形成 “互联网+政务服务”新格局。

财政部门作为政府的重要职能部门，也要通过大数据服务功能服务于社会，基于财政数据资源库、多主题数据库、模型数据库，结合不同类型业务特征，提供专项数据推送服务，形成财政信息资源服务平台。

政务大数据平台建设主要目标如下

1、通过数据标准，打破政务信息孤岛，实现政务数据共享

通过建设一套符合政务数据共享交换的数据标准，以数据的采集、清洗、存储为基础，提供政府内部共享数据包，推送数据到政府共享平台或者相关单位，从而打破政府各部门的信息壁垒，实现政务大数据资源对内共享与对外开放，将为推动经济结构调整，促进经济稳定运行，提升部门工作协同，服务领导决策奠定基础。

2、通过财政业务外包应用，为社会大众提供服务

通过财政数据的开放以及创新创业资源的聚集，建设一系列对外数据开放应用，比如财政业务公开数据包，财政报告数据等，推送到商水县财政厅网站、省政府数据服务网、省财政厅微公共信号、APP上等，供公众浏览和下载，便于用户进行进步数据利用。

3、通过财政智能应用，为生产系统提供服务

通过从一体化系统抽取内部数据，结合外部系统的数据进行综合分析和利用，形成大数据知识库，并通过接口的形式供财政业务系统调用，如提供预算项目审批帮手功能，帮助用户审批更加准确等。

1. 1. 1. 处室、单位及岗位

应用级次：省级集中，分级授权查询。

使用处室及单位：省财政厅、财政部门管理权限；主管部门、预算单位、社会公众查看、下载权限。

	数据采集	数据维护	生产系统服务	政府共享服务	社会公众服务
信息处	●	●	●
业务处室			●
财政部门			●	●	●
主管单位				●	●
预算单位				●	●
社会公众					●

1. 1. 1. 业务流程描述

大数据服务平台的业务流程如下图：

说明：

1、首先对财政内生数据和外部数据进行采集，采集的内容相似不在累述。

2、根据实际需要对采集的数据进行数据处理，并进行关联、整合和建模，从而形成了辅助支持数据、政府共享数据和公共开放数据等类型。

3、提供两类服务，即内部服务和外部服务，内部服务包括对生产系统的辅助支持，如项目审批、预算审批、执行审批辅助等，也包括对其他政府部门提供共享数据包的服务；外部服务主要是通过网站、微信号、APP等载体提供公共浏览和下载再利用的数据包。

1. 1. 1. 业务数据源描述

财政大数据平台的数据源包括所有的财政内生数据源和外部数据源，同时包括从各个渠道采集的数据源，具体请参阅

1、【财政内生数据分析】中【采集数据源及描述】

2、【财经数据挖掘分析】中【采集数据源及描述】

上述数据源要根据大数据标准和具体需求进行关联、整合和建模，生成相关的数据包和服务接口，以满足对内服务和对外推送的要求。下面仅仅以财政项目库数据源为案例对数据源所需字段和内容进行描述，实际使用以具体需求为准：

1、项目数据源：采集所有项目的数据，包括单位编码、项目级次、是否纳入预算、单位名称、项目编码、项目名称、当年及其后两年的资金安排等。

2、指标数据：项目库形成的指标，需要与项目关联，包括总指标、处室指标和单位指标等。

3、支付数据：项目指标所形成的支付数据，为项目支付结果。

4、其他数据：如项目评审结果、项目监督数据、项目绩效数据、项目竣工数据等。

1. 1. 1. 详细描述
  2. 辅助支持服务

通过对上述数据的采集，衔接各个属性形成知识库，通过项目建模后形成各种服务接口，为一体化系统提供服务，如生产系统可以通过URL连接调用的方式来调研财政决策支持系统提供的应用服务：

场景1：业务办理人员在审批预算单位项目后，不能确定项目计划是否合理，或者金额是否合理等，则可依据该服务接口，得到历年同类项目的审批情况，计划情况、评审情况和项目金额，并可通过图表分析历史项目的审批记录，给业务办理人员审批项目提供可参考的结果。

场景2：业务办理人员接到预算单位项目资金拨付申请后，不能确定是否必须拨付，则可依据该服务接口，得到相关项目资金拨付进度、拨付金额，并可通过监控和绩效服务得出历年项目支付的合理性时间，为项目资金拨付提供判断依据。

场景3：业务办理人员接到预算单位项目追加资金申请后，可依据该服务接口，得到相关项目资金执行进度、监控情况、绩效情况等，为项目资金拨付提供判断依据。

场景4：四本预决算：辅助预决算审批，展示相关图形，并能够提供智能帮助。

场景5：总体收支情况：辅助资金审批，展示相关图形，并能够提供帮助。

场景6：总体收支趋势：辅助资金审批，展示相关图形，并能够提供帮助。

场景7：一般公共预算收入动态分析：辅助资金审批，展示相关图形，并能够提供帮助。

场景8：财政总收入结构分析：辅助资金审批，展示相关图形，并能够提供帮助。

场景9：预算执行进度：辅助资金支出审批，展示相关预警图形，便于业务办理人员控制执行。

场景10：重点项目支出情况：辅助项目资金支出审批，展示相关执行进度和预警图形，便于业务办理人员控制项目执行进度。

……

1. 1. 数据共享服务

数据共享服务指的是通过政府部门制定的共享规划和标准，定期上传到政府数据资源网上（如类似政府数据服务网和资源共享管理平台等机构，平台提供标准接口格式，各个委办局利用接口将公开的数据上传到平台上供其他委办局利用），供政府其他部门下载和再利用，同时财政也可以通过这种方式下载其他部门的数据包；另外也可与特点部门进行点对点的数据包推送服务。

1、共享服务内容：共享服务内容是在安全的前提下，以共享平台和需求单位的进行组织数据、定期发送数据。如：

1）省行政事业性收费项目目录

2）省政府性基金项目目录

3）省级预算调整方案（草案）

4）省2016年预算执行情况与2017年预算草案的报告

5）省级财政决算草案

6）2017年上半年预算执行情况的报告

……

2、共享形式：共享形式以发送到专网上供其他单位申请、订阅和下载，如下图

未标题-2

上图中，以资源类型、数据领域、数据提供单位和具体内容为导向，展示了共享资源的形式。

1. 1. 数据公开服务

数据公开服务指的是通过政府部门制定的数据公开标准，定期公开到互联网、微信公众号和APP等介质，供社会机构和人员再利用。

1、共享服务内容：共享服务内容是在安全的前提下，及时发布财政厅发布的相关财政政策法规、财政收入与支出公开信息数据包等，向社会公众提供财政收入、支出进度及重点项目支出明细信息。及时向社会公众发布政府资金建设项目的绩效信息，并让社会公众监督项目的执行，向社会公众征求项目绩效评价信息，做好多方面、全面、公平、公正、公开地评价项目绩效。如：

1）、省行政事业性收费项目目录

2）、省政府性基金项目目录

3）、省级预算调整方案（草案）

4）、省2016年预算执行情况与2017年预算草案的报告

5）、省级财政决算草案

6）、2017年上半年预算执行情况的报告

7）、政府采购系统商品平均成交价格，输入：期间、商品分类码；输出（单值）：商品唯一码、商品名称、均值、最高、最低、中位数。

8）、主要电商系统商品平均成交价格，输入：期间、商品分类码；输出（单值）：商品唯一码、商品名称、均值、最高、最低、中位数。

9）、**年*月省一般公共预算收支完成情况

……

2、共享形式：

1）、互联网服务平台。借助于财政厅门户信息网站发布数据包，供公众下载，如下图（与专网相似）

未标题-2

上图中，以资源类型、数据领域、数据提供单位和具体内容为导向，展示了共享资源的形式。

2）、微信公众号。借助【省财政厅】微信公众号，定期发布公开数据包进行下载利用。如下图

财政厅

在上图中增加【数据公开】菜单，将数据包全部传输到上面，打开如下图

未标题-3

上图的数据包即可进行下载和再利用。

3）、APP服务：与微信服务类似。

1. 1. 1. 其他业务要求

由于大数据服务平台是对内、对外的窗口，所以必须满足以下的业务要求：

1、安全要求：对内和对外的数据必要在确保安全的前提下进行开放和共享。

2、流程要求：对外和对内的共享必须要经过严格的流程管理和审核。

3、标准要求：对外和对内的共享必须符合大数据开放的标准。

1. 1. 1. 管理特例

无

附：术语说明

为了便于用户阅读财政大数据需求文档，对其涉及的专业术语进行解释。

生态主题。以大数据技术为核心，以挖掘价值为导向，通过纵向深挖内生数据潜在规律，横向发掘与外缘数据的关联特性，打破传统系统边界以及信息壁垒。让数据互联互通，彼此关联、相互作用，形成数据与业务场景交织的生态主题网络。
数据仓库。是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。
主数据（MD Master Data）。指系统间共享数据（例如，客户、供应商、账户和组织部门相关数据）。与记录业务活动、波动较大的交易数据相比，主数据（也称基准数据）变化缓慢。在正规的关系数据模型中，交易记录（例如，订单行项）可通过关键字（例如，订单头或发票编号和产品代码）调出主数据。主数据必须存在并加以正确维护，才能保证交易系统的参照完整性。
ETL。是数据抽取（Extract）、清洗（Cleaning）、转换（Transform）、装载（Load）的过程。是构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。
元数据。在数据仓库领域中，元数据被定义为描述数据及其环境的数据。元数据用于建立、管理、维护和使用数据仓库的整个过程。按照元数据的使用情况和面向对象的不同，通常把元数据分为技术元数据、业务元数据和操作型元数据。
量度。是指我们对进行分析的目标采用量化的数值，如支出金额、人员数量、发生频率等。
维度。是用来反映业务的一类属性或者是对目标对象进行分析时的某个角度，这类属性角度集合构成一个维度。
事实表。一个存放数据信息的表，事实表的主要特点是存放数字数据（事实），并且这些数字信息可以汇总。例如预算收入事实表中包含有预算收入，收入金额，收入笔数等，这些都是实际发生的金额和数量，都是具体的“数值”。
维度表。维度表可以看作是用户来分析数据的窗口，维度表中包含事实数据表中事实记录的特性，有些特性提供描述性信息，有些特性指定如何汇总事实数据表数据，以便为分析者提供有用信息，维度表包含帮助汇总数据特性的层次结构。
星型模型。是数据仓库应用程序的最佳设计模式。它的命名是因其在物理上表现为中心实体，典型内容包括指标数据、辐射数据，通常是有助于浏览和聚集指标数据的维度。星形图模型得到的结果常常是查询式数据结构，能够为快速响应用户的查询要求提供最优的数据结构。
雪花模型。指一种扩展的星形图。星形图通常生成一个两层结构，即只有维度和指标，雪花图生成了附加层。实际数据仓库系统建设过程中，通常只扩展三层：维度（维度实体）、指标（指标实体）和相关的描述数据（类目细节实体）超过三层的雪花图模型在数据仓库系统中应该避免。

数据资产管理

数据资产简介

大数据时代已经来临，数据被业界公认为是企业最宝贵的资产之一，其价值得到了普遍认同。然而，绝大部份传统企业在尝试挖掘数据资产价值的过程中，都出现各种各样的问题，如：

v 数据架构混乱：系统越来越多，系统复杂度也越来越高，管理难度随之越来越大，没人能弄清整个系统的数据架构和数据流向，数据架构与业务流程、应用架构之间的关系不清晰。

v 架构管理滞后：甲方越来越依赖开发商，自身的系统数据架构管理力度不断减弱。同时，开发商以实现功能为主，对非功能性需求不太在意，导致版本质量不高，先实现后优化，优化效果滞后。

v 架构变更失控：大多数系统都处于积术式叠代开发，有新需求就加一堆表，使系统数据模型越来越雍肿；数据模型设计缺少审查，导致数据模型混乱、复杂、扩展性差。

v 数据无序增长：企业核心业务系统数据容量无序增长，长期处于“系统扩容 - 数据膨胀 - 性能低下 - 系统扩容”的怪圈之中。

v 数据标准缺失：缺少企业级别统一的数据标准，数据模型相关含义令开发和运维人员难以理解；同时，亦使得企业不同应用间的数据集成和数据共享困难。

v 数据安全突出：对企业的敏感数据、用户、访问权限仍然缺少认识和控制，敏感数据泄漏的安全事件屡见不鲜。

v 数据质量参差：数据处理环节中产生大量的错误和质量差的数据，数据错误发现和处理流程不及时，导致更多的后续错误。

数据资产管理（Data Asset Management，简称DAM）是规划、控制、和提供数据这种企业资产的一组业务职能，包括开发、执行和监督有关数据的计划、政策、方案、项目、流程、方案和程序。企业依赖有效数据资产管理为其提供可靠、有价值和高质量的数据，提供更好的产品和服务，降低开发和运维成本，控制风险，以及为企业提供更明智和更有效的决策数据支持。