数据仓库概念汇总

目录

一、术语.......................................................................................................................................................................

3二、数据仓库基础.......................................................................................................................................................

4

2.1相关概念.........................................................................................................................................................

4

2.1.1数据仓库..............................................................................................................................................

4

2.1.2企业信息工厂......................................................................................................................................

6

2.1.3数据集市..............................................................................................................................................

6

2.1.4维..........................................................................................................................................................

7

2.1.5事实表..................................................................................................................................................

9

2.1.6操作数据存储ODS ............................................................................................................................

12

2.1.7元数据................................................................................................................................................

13

2.1.8 ETL

.......................................................................................................................................................

14

2.1.9 OLAP

....................................................................................................................................................

17

2.1.10多维数据库......................................................................................................................................

19

2.2数据仓库架构...............................................................................................................................................

20

一、术语

BI

Business

Intelligence，即商业智能，也看到有些媒体里写作商务智能综合企业所有沉淀下来的信息，用科学的分析方法，为企业领导提供科学决策信息的过程。

BOSS

业务运营支撑系统：Business Operations Support Systems简称BOSS

BPM

Business

Performance Management (企业绩效管理)，是以商业智能(BI)技术、平衡计分卡(BSC)和个人关键绩效指标(KPIs)等先进信息技术和管理理论为基础的战略管理的工具，在财务、客户、内部流程和学习与发展四个维度上进行综合绩效评测，帮助企业从整体上实现对战略实现过程的贯彻和控制。

BPR

业务流程重整（Business

Process Reengineering），指利用数据仓库技术，发现并纠正企业业务流程中的弊端的一项工作。数据仓库的重要作用之一。

CRM

Customer

Relationship Management客户关系管理。CRM是选择和管理有价值客户及其关系的一种商业策略，CRM要求以客户为中心的商业哲学和企业文化来支持有效的市场营销、销售与服务流程。

CUBE

立方体

DM（Datamart）

即数据集市，或者叫做“小数据仓库”。如果说数据仓库是建立在企业级的数据模型之上的话。那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。

DM（DataMine）

数据挖掘是一个从大型数据库中提取以前未知的，可理解的，可执行的信息并用它来进行关键的商业决策的过程。

DSS

决策支持系统（Decision

Support System），相当于基于数据仓库的应用。决策支持就是在收集所有有关数据和信息，经过加工整理，来为企业决策管理层提供信息，为决策者的决策提供依据。

DW

Data

Warehouse，本世纪80年代中期，“数据仓库之父”WilliamH。Inmon先生在其《建立数据仓库》一书中定义了数据仓库的概念，随后又给出了更为精确的定义：数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。与其他数据库应用不同的是，数据仓库更像一种过程，对分布在企业内部各处的业务数据的整合、加工和分析的过程。而不是一种可以购买的产品。

EDM

Enterprise

Data Model企业数据模型

ERP

Enterprise Resource Planning企业资源规划。它是一个以管理会计为核心的信息系统，识别和规划企业资

源，从而获取客户订单，完成加工和交付，最后得到客户付款。换言之，ERP将企业内部所有资源整合在一起，对采购、生产、成本、库存、分销、运输、财务、人力资源进行规划，从而达到最佳资源组合，取得最佳效益。

ETL

数据抽取（Extract）、转换（Transform）、清洗（Cleansing）、装载（Load）的过程。构建数据仓库的重要一环，用户从数据源抽取出所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去。

KDD

KDD（Knowledge Discovery in Database）数据库中知识发现。是基于数据库的知识发现，指的是从大型数据库或数据仓库中提取人们感兴趣的知识，这些知识是隐含的、事先未知的、潜在有用的、易被理解的模式。

KPI

企业关键业绩指标(KPI：Key Process Indication)是通过对组织内部流程的输入端、输出端的关键参数进行设

置、取样、计算、分析，衡量流程绩效的一种目标式量化管理指标，是把企业的战略目标分解为可操作的工作目标的工具，是企业绩效管理的基础。

LDM

逻辑数据模型(Logic Data Model)

MDD

多维数据库（Multi-Dimensional

Database，MDD）可以简单地理解为：将数据存放在一个n维数组中，而

不是像关系数据库那样以记录的形式存放。因此它存在大量稀疏矩阵，人们可以通过多维视图来观察数据。多维数据库增加了一个时间维，与关系数据库相比，它的优势在于可以提高数据处理速度，加快反应时间，提高查询效率。

Metadata

Metadata(元数据)，它是“关于数据的数据”在地理空间信息中用于描述地理数据集的内容、质量、表示方式、空间参考、管理方式以及数据集的其他特征，它是实现地理空间信息共享的核心标准之一。目前，国际上对空间元数据标准内容进行研究的组织主要有三个，分别是欧洲标准化委员会(CEN/TC287)、美国联邦地理数据委员会(FGDC)和国际标准化组织地理信息/地球信息技术委员会(ISO/TC211)。

MOLAP

严格遵照Codd的定义，自行建立了多维数据库，来存放联机分析系统数据的Arbor

Software，开创了多维数据存储的先河，后来的很多家公司纷纷采用多维数据存储。被人们称为Multi-Dimension

OLAP，简称MOLAP，代表产品有Hyperion(原Arbor Software)Essbase、Showcase STRATEGY等。

ODS

(Operational Data Store)操作型数据存储，对于一些准实时的业务数据库当中的数据的暂时存储，支持一些同时关连到历史数据与实时数据分析的数据暂时存储区域。

二、数据仓库基础

2.1相关概念

2.1.1数据仓库

目前，数据仓库一词尚没有一个统一的定义，著名的数据仓库专家W。H。Inmon在其著作《Building the

Data Warehouse》一书中给予如下描述：数据仓库（Data Warehouse）是一个面向主题的（Subject

Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（TimeVariant）的数据集合，用于支持管理决策。

对于数据仓库的概念我们可以从两个层次予以理解，首先，数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库；其次，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。

根据数据仓库概念的含义，数据仓库拥有以下四个特点：1）面向主题。传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据；数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的；而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜

(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。

[if !supportLists]2）[endif]集成的。面向事务处理的操作型数据库通常与某些特定的应用相关，数据库之间相互独立，并且往往是异构的。而数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

[if !supportLists]3）[endif]相对稳定的。操作型数据库中的数据通常实时更新，数据根据需要及时发生变化。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期的加载、刷新。

[if !supportLists]4）[endif]反映历史变化。操作型数据库主要关心当前某一个时间段内的数据，而数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。

企业数据仓库的建设，是以现有企业业务系统和大量业务数据的积累为基础。数据仓库不是静态的概念，只有把信息及时交给需要这些信息的使用者，供他们做出改善其业务经营的决策，信息才能发挥作用，信息才有意义。而把信息加以整理归纳和重组，并及时提供给相应的管理决策人员，是数据仓库的根本任务。因此，从产业界的角度看，数据仓库建设是一个工程，是一个过程。

下图是一个典型的企业数据仓库系统，通常包含数据源、数据存储与管理、数据的访问三个部分：

[if !vml]

[endif]

数据源：是指企业操作型数据库中的各种生产运营数据、办公管理数据等内部数据和一些调查数据、市场信息等来自外环境的数据总称。这些数据是构建数据仓库系统的基础是整个系统的数据源泉。

数据的存储与管理：数据仓库的存储主要由元数据的存储及数据的存储两部分组成。元数据是关于数据的数据，其内容主要包括数据仓库的数据字典、数据的定义、数据的抽取规则、数据的转换规则、数据加载频率等信息。各操作数据库中的数据按照元数据库中定义的规则，经过抽取、清理、转换、集成，按照主题重新组织，依照相应的存储结构进行存储。也可以面向应用建立一些数据集市，数据集市可以看作是数据仓库的一个子集，它含有较少的主题域且历史时间更短数据量更少，一般只能为某个局部范围内的管理人员服务，因此也称之为部门级数据仓库。

数据的访问：由OLAP(联机分析处理)、数据挖掘、统计报表、即席查询等几部分组成。例如OLAP：针对特定的分析主题，设计多种可能的观察形式，设计相应的分析主题结构（即进行事实表和维表的设计），使管理决

策人员在多维数据模型的基础上进行快速、稳定和交互性的访问，并进行各种复杂的分析和预测工作。按照存

储方式来分，OLAP可以分成MOLAP以及ROLAP等方式，MOLAP(Multi-Dimension

OLAP)将OLAP分析所需的数据存放在多维数据库中。分析主题的数据可以形成一个或多个多维立方体。ROLAP(Relational OLAP)将OLAP分析所需的数据存放在关系型数据库中。分析主题的数据以“事实表-维表”的星型模式组织。

2.1.2企业信息工厂

企业信息工厂（Corporate Information Factory，简称EIF）是一种构建数据仓库的架构。企业信息工厂的创始人是数据仓库之父Inmon。

企业信息工厂主要包括集成转换层（I&T）、操作数据存储（ODS）、企业级数据仓库（EDW）、数据集市

（DM）、探索仓库（EW）等部件。这些部件有机的结合在一起，为企业提供信息服务。

集成转换层的目的是将来自操作型源系统的数据集成转换到数据仓库中，它通常由一组程序组成，而其它部件如数据仓库和数据集市等则主要由数据组成。当业务数据来源多，业务复杂时，集成转换层会建立一些临时

表，为数据处理提供方便。这时，集成转换层包括程序和数据，也称数据准备区（Data Staging Area）。通常中等规模及以上的数据仓库系统都会建立数据准备区。

操作数据存储（ODS）是建立在数据准备区和数据仓库之间的一个部件。用来满足企业集成的、综合的操作型处理需要。例如，出尽可能实时的集成的操作报表等需求。一般，也称操作数据存储是用来满足企业战术决策的需要。操作数据存储是个可选的部件。

企业级数据仓库是企业信息工厂的核心部件，用来保存整个企业的数据。一般，也称数据仓库，是用来满足企业战略决策的需要。数据仓库的数据来自数据准备区和操作数据存储。

数据集市是为了满足企业特定部门的分析需求而专门建立的数据的集合。数据集市的数据来源是数据仓库。企业信息工厂中的数据集市一般来说是非规范化的、定制的和汇总的。而多维体系架构中的数据集市分为两种，分别是原子数据集市和聚集数据集市。一般来说，企业信息工厂中的数据集市相当于多维体系架构中的聚集数据集市。

探索仓库或数据挖掘仓库的建立主要是为了解决大型查询，提高数据仓库的效率。当有探索或挖掘需求时，会从数据仓库导出一部分数据提供给他们操作。

企业信息工厂中的数据流向一般是从源系统到数据准备区到操作数据存储到数据仓库到数据集市。当分析人员在数据仓库或数据集市中得出分析结论后，会有信息的回流。这种信息回流有可能是物理数据的回流，也可能是直接改变业务部门的策略，总之，要将分析的结果应用起来。通过这种信息的回流，企业信息工厂的不同部件可以不断的相互调整，最终找到一种平衡。这也是它称为企业信息工厂的原因。

2.1.3数据集市

数据集市（Datamart）也叫做“小数据仓库”。如果说数据仓库是建立在企业级的数据模型之上的话，那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。

即席查询

即席查询（Adhocqueries）是指那些用户在使用系统时，根据自己当时的需求定义的查询。

即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。

即席查询与通常查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，通常的查询在系统设计和实施时是已知的，所有我们可以在系统实施时通过建立索引、分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时生产的，系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。

即席查询的位置通常是在关系型的数据仓库中，即在EDW或者ROLAP中。多维数据库有自己的存储方式，对即席查询和通常查询没有区别。

在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高，对数据模型的对称性的要求也越高。对称性的数据模型对所有的查询都是相同的，这也是维度建模的一个优点。

代理关键字－－surrogate key

在数据仓库领域有一个概念叫Surrogate key，中文一般翻译为“代理关键字”。代理关键字一般是指维度表中使用顺序分配的整数值作为主键，也称为“代理键”。代理关键字用于维度表和事实表的连接。

代理关键字的称呼有surrogate keys，meaningless keys，integer

keys，nonnatural keys，artificial

keys，synthetic keys等。与之相对的自然关键字的称呼有natural keys，samat keys等。

在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。在维度表和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字（natural keys）或者智能关键字（Smart Keys）。数据仓库中的主键不应该是智能的，也就是说，要避免通过主键的值就可以了解一些业务信息。当然，退化维度作为事实表的复合主键之一时例外。

使用代理关键字，有很多优点。

1．使用代理关键字能够使数据仓库环境对操作型环境的变化进行缓冲。也就是说，当数据仓库需要对来自多个操作型系统的数据进行整合时，这些系统中的数据有可能缺乏一致的关键字编码，即有可能出现重复，这时代理关键字可以解决这个问题。

2．使用代理关键字可以带来性能上的优势。和自然关键字相比，代理关键字很小，是整型的，可以减小事实表中记录的长度。这样，同样的IO就可以读取更多的事实表记录。另外，整型字段作为外键联接的效率也很高。

3．使用代理关键字可以建立一些不存在的维度记录，例如“不在促销之列”，“日期待定”，“日期不可用”等维度记录。

4．使用代理关键字可以用来处理缓慢变化维。维度表数据的历史变化信息的保存是数据仓库设计的实施中非常重要的一部分。Kimball的缓慢变化维处理策略的核心就是使用代理关键字。

当然，使用代理关键字也有它的缺点，代理关键字的使用使数据加载变得非常复杂。有关使用代理关键字的维度表和事实表的加载方法在ETLToolkit中有详细的描述。使用代理关键字是一个从长远考虑的策略。

2.1.4维

维，是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维。

假定某某是个百货零售商，有一些因素会影响他的销售业务，如商品、时间、商店或流通渠道，更具体一点，如品牌、月份、地区等。对某一给定的商品，也许他想知道该商品在哪个商店和哪段时间的销售情况。对某一商店，也许他想知道哪个商品在哪段时间的销售情况。在某一时间，也许他想知道哪个商店哪种产品的销售情况。因此，他需要决策支持来帮助制定销售政策。

这里，商店、时间和产品都是维。各个商店的集合是一个维，时间的集合是一个维，商品的集合也是一个

维。

缓慢变化维

维度建模的数据仓库中，有一个概念叫Slowly Changing Dimensions，中文一般翻译成“缓慢变化维”，经常被简写为SCD。缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题，有时也简称为处理SCD的问题。

处理缓慢变化维的方法通常分为三种方式。第一种方式是直接覆盖原值。这样处理，最容易实现，但是没有保留历史数据，无法分析历史变化信息。第一种方式通常简称为“TYPE1”。

第二种方式是添加维度行。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。第二种方式通常简称为

“TYPE2”。

第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。第三种方式通常简称为“TYPE3”。

在实际建模中，我们可以联合使用三种方式，也可以对一个维度表中的不同属性使用不同的方式，这些，都需要根据实际情况来决定，但目的都是一样的，就是能够支持方便的分析历史变化情况。

退化维度

在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为“退化维度”。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。

退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。

退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于像销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。

退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在一起。

微型维度

在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为“退化维度”。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。

退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，尤其是对维度建模的入门者。

退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度建模中，事实表应该保存最细粒度的数据。所以对于像销售单这样的事实表来说，需要销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度共同作为主键。

退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在一起。

一致性维度

维度建模的数据仓库中，有一个概念叫Conformed Dimension，中文一般翻译为“一致性维度”。一致性维度是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性事实（Conformed Fact）。

在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。

一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结果。

一致性维度建立的地点是多维体系结构的后台（Back Room），即数据准备区。在多维体系结构的数据仓库项目组内需要有专门的维度设计师，他的职责就是建立维度和维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同的。建立新的数据集市时，需要在后台进行一致性维度处理，根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。

在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取

等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。

这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。

杂项维度

在维度建模的数据仓库中，有一种维度叫Junk Dimension，中文一般翻译为“杂项维度”。杂项维度是由操作系统中的指示符或者标志字段组合而成，一般不在一致性维度之列。

在操作系统中，我们定义好各种维度后，通常还会剩下一些在小范围内取离散值的指示符或者标志字段。例如：支付类型字段，包括现金和信用卡两种类型，在源系统中它们可能是维护在类型表中，也可能直接保存在交易表中。

一张事实表中可能会存在好几个类似的字段，如果作为事实存放在事实表中，会导致事实表占用空间过大；如果单独建立维度表，外键关联到事实表，会出现维度过多的情况；如果将这些字段删除，会有人不同意。

这时，我们通常的解决方案就是建立杂项维度，将这些字段建立到一个维度表中，在事实表中只需保存一个外键。几个字段的不同取值组成一条记录，生成代理键，存入维度表，并将该代理键保存入相应的事实表字段。建议不要直接使用所有的组合生成完整的杂项维度表，在抽取时遇到新的组合时生成相应记录即可。杂项维度的ETL过程比一般的维度略为复杂。

2.1.5事实表

在维度建模的数据仓库中，事实表是指其中保存了大量业务度量数据的表。事实表中的度量值一般称为事实。在事实表中最有用的事实就是数字类型的事实和可加类型的事实。事实表的粒度决定了数据仓库中数据的详细程度。

1）一般来说，以粒度作为化分依据，主要有三种事实表，分别是事务粒度事实表，周期快照粒度事实表和累积快照粒度事实表。

事务粒度事实表（Transaction Grain Fact Table）中的一条记录代表了业务系统中的一个事件。事务出现以后，就会在事实中出现一条记录。事务粒度事实表也称为原子粒度。典型的例子是销售单分列项事实表。事务事实表的日期维度记录的是事务发生的日期，它记录的事实是事务活动的内容。用户可以通过事务事实表对事务行为进行特别详细的分析。

周期快照粒度事实表（Periodic Snapshot Grain Fact Table）以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。典型的例子如销售日快照表、库存日快照表等。

周期快照粒度事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。周期快照事实表的维度个数比事务事实表要少，但是记录的事实要比事务事实表多。

周期快照粒度事实表的日期维度通常是记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值。事实表的数据一旦插入即不能更改，其更新方式为增量更新。

累积快照事实表（Accumulating Snapshot Grain Fact Table）一般用来涵盖一个事务的生命周期内的不确定的时间跨度。典型的例子是KDT#2中描述的具有多个日期字段的发货事实表。它和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。

累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。

举例来说：订货日期预定交货日期实际发货日期实际交货日期数量金额运费

在这个累积快照事实表中，记录的是购买货物的整个生命周期的数据，记录第一次产生时，实际发货日期和实际交货日期是不确定的，需要用表示未知的代理关键字来代替。等实际发货后，需要对数据仓库中的这条记录进行更新操作，将实际发货日期补上。

通常来说，事务和快照是建模中的两个非常重要的特点，将两者相结合可以使模型建立的更完整。

2）从用途的不同来说，事实表可以分为三类，分别是原子事实表，聚集事实表和合并事实表。

原子事实表（Atom Fact Table）是保存最细粒度数据的事实表，也是数据仓库中保存原子信息的场所。事务事实表（Transactionfacttable）记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

聚集事实表（Aggregated Fact Table）是原子事实表上的汇总数据，也称为汇总事实表。即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度表的子集，如用月份维度表代替日期维度表；事实数据是相应事实的汇总，即求和或求平均值等。在做数据迁移时，当相关的维度数据和事实数据发生变化

时，聚集事实表需要做相应的刷新。物化视图是实现聚集事实表的一种有效方式，可以设定刷新方式，具体功能由DBMS来实现。

合并事实表（Consolidated Fact Table）是指将位于不同事实表中处于相同粒度的事实进行组合建模而成的一种事实表。即新建立一个事实表，它的维度是两个或多个事实表的相同维度的集合；事实是几个事实表中感兴趣的事实。在Kimball的总线架构中，由合并事实表为主组成的合并数据集市称为二级数据集市。合并事实表的粒度可以是原子粒度也可以是聚集粒度。在做数据迁移时，当相关的原子事实表的数据有改变时，合并事实表的数据需要重新刷新。合并事实表和交叉探察是两个互补的操作。

聚集事实表和合并事实表的主要差别是合并事实表一般是从多个事实表合并而来。但是它们的差别不是绝对的，一个事实表既是聚集事实表又是合并事实表是很有可能的。因为一般合并事实表需要按相同的维度合并，所以很可能在做合并的同时需要进行聚集，即粒度变粗。

旋转事实表旋转事实表（pivotedfacttable）是将一条记录中的多个事实字段转化为多条记录，其中每条记录保存一个事实字段的一种建模方法。或者反过来，也可以由多条记录转化为一条记录。

旋转事实表建模方法的使用通常是为了简化前端数据展现的查询。它通过改变后端的事实记录存储方式，使相应的查询需求的性能得到的极大的提高。如果在SQL或者查询工具中进行这种转换会非常麻烦，效率也很差。和合并事实表类似，有时当基础表中没有记录时，旋转事实表也要存储一些零值在里面。

预连接聚集表

预连接聚集表（pre-joinedaggregagtetable）是通过对事实表和维度表的联合查询而生成的一类汇总表。在预连接聚集表中，保存有维度表中的描述信息和事实表的事实值。通过预连接，可以避免在用户查询时RDBMS的连接操作，所以预连接聚集表的查询效率要高很多。典型的预连接聚集表如下例所示的销售事实表：

产品名称商标名称年份 月份 销售人员名称 销售量 销售金额

在这个销售事实表，前五个字段都来自于维度表的描述字段，后两个字段来自于事实表的事实字段。这样在用户提交查询后，RDBMS就不需要连接维度表和事实表了，只需直接在该表中查询即可。

预连接聚集表有一个很大的缺点，它需要占用大量的存储空间。预连接事实表的记录和事实表一样多，每条记录的长度和维度表一样长，所以对存储空间的需求是非常大的。除非情况特殊，或者该表是高度汇总的，否则不建议建立预连接聚集表。在建立预连接聚集表时需要平衡效率和存储空间的矛盾。

预连接聚集表的生成方式较为简单，直接使用SQL查询即可生成。如果聚集导航器的功能很强大的话，也可以处理预连接聚集表。否则，需要用户理解预连接聚集表，并在SQL中直接使用该表。

预连接聚集表在数据仓库领域有着很重要的作用，是汇总表的一种。它的优点和缺点都很明显，在使用时需要综合考虑。

非事实型事实表

在非事实型事实表（Factless Fact Table），通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。

第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况下的注册数。

第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法回答。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。

切片事实表

切片事实表（Sliced Fact Table）中的字段结构和相应的基础表完全相同，差别在于存储的记录的范围。

切片事实表中保存记录的是相应基础表中记录的子集，记录数通常与某个维度记录数相同。

这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以将与之相关的数据切片出来。相反，这种方法也常用于合并存储在不同地区的数据，即各个地区都保存自己地区的数据，总部和所有地区的表结构都相同，然后总部将所有地区的数据合并在一起。

切片事实表的结构与相对应的基础表相同，数据来源于相对应的基础表。切片事实表由于缩小了表中数据的记录数，所以查询的效率得到了很大的提高。

蜈蚣事实表

蜈蚣事实表（Centipedefacttable）是指那些一张事实表中有太多维度的事实表。连接在事实表两边的维度表过多，看起来就像蜈蚣一样，所以称为“蜈蚣事实表”。

通常来说，蜈蚣事实表的出现是由于建模师对事实表和维度表逆规范化过了头。例如，不单将产品主键放入事实表中，对于产品层级结构中的每一层的主键都放入事实表中，这样事实表中与产品相关的就会有产品

ID、商标ID、子类ID、类别ID等多个外键。同样，也有建模师将日期相关的日期ID、月ID、年ID都放入事实表中。这些都将产生蜈蚣事实表，使自己落入维度过多的陷阱。

蜈蚣事实表虽然使查询效率有所提高，但是伴之而来的是存储空间的大量增长。在维度建模的数据仓库中，维度表的字段个数可以尽可能的增加，但是事实表的字段要尽量减少，因为相比而言，事实表的记录数要远远大于维度表的记录数。

一般来说，事实表相关的维度在15个以下为正常，如果维度个数超过25个，就出现了维度过多的蜈蚣事实表。这时，需要做的事情是自己核查，将相关的维度进行合并，减少维度的个数。

一致性事实

一致性事实（ConformedFact）是Kimball的多维体系结构（MD）中的三个关键性概念之一，另两个是总线架构（Bus Architecture）和一致性维度（Conformed Dimension）。

在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事实。

一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（BackRoom），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drillacross）来实现。

为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点。第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。

这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探查，一个分布式的数据仓库就建成了。

2.1.6操作数据存储ODS

在数据仓库架构中有一种部件叫Operational

Data Store（ODS），中文一般翻译为“操作数据存储”。操作数据存储在通常的数据仓库架构中都是一个可选的部件，它和数据仓库起到互相补充的作用。

最早给ODS下定义的是数据仓库之父Inmon。他的定义是，操作数据存储（ODS）是面向主题的、集成的、可变的、反映当前数据值的和详细的数据的集合，用来满足企业综合的、集成的以及操作型的处理需求。

Inmon的这个定义与他对数据仓库的定义很像。其中前两个特性和数据仓库是一样的，即都是面向主题的和集成的，而后三个特性和数据仓库相差较大。

ODS中的数据是可以变化的：这一点是Inmon相对与他的CIF（企业信息工厂）中的数据仓库来说的，在CIF中，数据仓库中的数据是不进行更新的，对于错误的处理通常是采用新的快照来进行保存。而ODS是可以按常规方法进行更新的。

ODS反映当前数据值：这一点是指ODS中不会长期的保留数据，通常ODS保留的数据的时限最长到一个月或三个月。而数据仓库可以保留五年、十年或更长的数据。

ODS中保留详细数据：这一点是说ODS中只保留原子数据，而不保留汇总数据。而在数据仓库中原子数据和汇总数据都会进行保留。这和ODS可更新的特性相关，因为随时可能将操作型系统的数据变化更新到ODS中，并且数据的迁移时间间隔会很短，这都使汇总数据在ODS中的意义不大。

•ODS分类

Inmon在给ODS下了定义之后，进一步把ODS分成了四类。根据数据到达ODS的时间间隔，即数据从操作型系统生成开始到数据到达ODS为止的时间长短，ODS分为ClassI、ClassII、ClassIII和ClassIV四类。

ClassI的ODS：指时间间隔为秒级，即对用户来说，ODS是个透明的部件，操作型系统业务发生后，数据立刻就可以在ODS中看到。这类ODS事实上是很难实现的。秒级的数据迁移间隔，我们没有时间进行数据的整合。对于此类ODS，从技术和成本上来说，都是不合算的。

ClassII的ODS：指时间间隔为小时级，即操作型系统业务发生后，数据要经个几个小时才能出现在ODS部件中。

ClassIII的ODS：指时间间隔为天级，即我们常见到的数据仓库的迁移频率，如每天晚上进行一次数据迁移。

ClassIV的ODS：指时间间隔更长，可能为月级、甚至年级。ClassIV和其他类尤为不同的一点是，ClassIV的数据源经常是数据仓库。

ClassI的ODS是实时数据仓库的一种实现方式。ClassII和ClassIII的ODS是比较通常的ODS实现方式。

ClassIV的ODS非常有用的一类ODS实现方式。

在ClassIV的ODS中，最为常见的记录就是从数据仓库中总结出来的概况数据（ProfileRecord）。概况数据

是数据情况的大纲。以客户为例，可以总结的概况数据如下：每月买衣服的件数，每周的销售量，每年会看两次眼科医生等等。ODS中的概况数据是从大量的详细数据中总结出来的，大部分是统计和挖掘处理的结果，它们存放到ODS中，供操作人员了解客户的情况。

需要说明的一点是，虽然ODS从概念上分成这样的四类，但是在进行数据仓库的架构时，我们不必过于刻板，四类ODS同时使用也应该是很正常的选择。例如，对于非常敏感的个别数据，我们可以选择ClassI，而对于一般的数据，选择ClassII或者ClassIII。个人感觉，ClassIV是Inmon尤为推荐的一类。

由于ODS仍然存储在普通的关系数据库中，出于性能、存储和备份恢复等数据库的角度以及对源数据库的性能影响角度，个人不建议ODS保存相当长周期的数据，同样ODS中的数据也尽量不做转换，而是原封不动地与业务数据库保持一致。即ODS只是业务数据库的一个备份或者映像，目的是为了使数据仓库的处理和决策支持要求与OLTP系统相隔离，减少决策支持要求对OLTP系统的影响。

•ODS的作用

为什么需要有一个ODS呢？一般在带有ODS的系统体系结构中，ODS都具备如下几个作用：

[if !supportLists]1）[endif]在业务系统和数据仓库之间形成一个隔离层一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。

[if !supportLists]2）[endif]转移一部分业务系统细节查询的功能在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。

[if !supportLists]3）[endif]完成数据仓库中不能完成的一些功能一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据和运营指标，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。即数据仓库从宏观角度满足企业的决策支持要求，而ODS层则从微观角度反映细节交易数据或者低粒度的数据查询要求。

在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。这样的数据仓库的存储压力和性能压力都是比较大的，因此对数据仓库的物理设计和逻辑设计提出了更高的要求。

2.1.7元数据正如其他种类的仓库都要保留一个库存清单一样，数据仓库也要也要保留一个‘库存’清单，以跟踪那些数据仓库中保存的数据的结构、定义以及这些数据的‘来历’等等。这个‘库存’清单实质上就是我们现在所说的元数据。不过元数据对于数据仓库的意义比‘库存’对于实际意义上的仓库大得多。

随着数据仓库（DW）技术的不断成熟，企业的数据逐渐变成了决策的主要依据。数据仓库中的数据是从许多业务处理系统中抽取、转换而来，对于这样一个复杂的企业数据环境，如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这一问题的关键就是建立数据仓库元数据库，并对这个元数据库进行有效的管理。从某种意义上来说，能否建立并管理好元数据，将决定着数据仓库项目的成败。

按照传统的定义，元数据（Metadata）是关于数据的数据。我们可以把它理解为比一般意义的数据范畴更加广泛的数据。它不再仅仅表示数据的类型、名称、值等信息，它进一步描述了数据的上下文描述信息，比如数据所属的区域、取值范围、数据间的关系、业务规则、甚至ETL规则、甚至数据的来源信息等。

元数据可以看作是数据仓库系统的‘数据字典’，但这个数据字典比传统意义上数据库的数据字典功能要强大的多。它可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；并可以回答最终用户数据仓库中有哪些数据，这些数据从哪里来等重要的问题。

可将其按用途的不同分为两类：技术元数据（Technical

Metadata）和业务/商业元数据（Business

Metadata）。

[if !supportLists]•[endif]技术元数据

技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息：

[if !supportLists]1）[endif]数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；

[if !supportLists]2）[endif]业务系统、数据仓库和数据集市的体系结构和模式；

[if !supportLists]3）[endif]汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告；

[if !supportLists]4）[endif]由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。

[if !supportLists]•[endif]业务/商业元数据

业务/商业元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务/商业元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的信息；具体包括以下信息：

[if !supportLists]1）[endif]企业概念/逻辑模型：这是业务/商业元数据所应提供的重要的信息，它表示企业数据模型的高层信息、整个企业的业务概念和相互关系。以这个企业模型为基础，不懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数。

[if !supportLists]2）[endif]多维数据模型：这是企业概念模型的重要组成部分，它告诉业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式。

[if !supportLists]3）[endif]业务概念模型和物理数据之间的映射、依赖：以上提到的业务/商业元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、多维数据库中的表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所体现。

2.1.8 ETL

ETL是将业务系统的数据经过抽取（Extract）、清洗转换（Transform）之后加载（Load）到数据仓库的过

程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。ETL是BI项目重要的一个环节。通常情况下，在BI项目中ETL会花掉整个项目的1/3的时间，ETL设计的好坏直接关接到BI项目的成败。

ETL的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计ETL的时候我们也是从这三部分出发。数据的抽取是从各个不同的数据源抽取到ODS(OperationalDataStore，操作型数据存储)中——这个过程也可

以做一些数据的清洗和转换)，在抽取的过程中需要挑选不同的抽取方法，尽可能的提高ETL的运行效率。ETL三个部分中，花费时间最长的是“T”(Transform，清洗、转换)的部分，一般情况下这部分工作量是整个ETL的2/3。

数据的加载一般在数据清洗完了之后直接写入DW(DataWarehousing，数据仓库)中去。

ETL的实现有多种方法，常用的有三种。一种是借助ETL工具实现，一种是SQL方式实现，另外一种是ETL工具和SQL相结合。前两种方法各有各的优缺点，借助工具可以快速的建立起ETL工程，屏蔽了复杂的编码任务，提高了速度，降低了难度，但是缺少灵活性。SQL的方法优点是灵活，提高ETL运行效率，但是编码复杂，对技术要求比较高。第三种是综合了前面二种的优点，会极大地提高ETL的开发速度和效率。

现在有很多成熟的工具提供ETL功能，例如PowerCenter、DataStage、OracleOWB、SQLServer2000的DTS等，且不说他们的好坏。从应用角度来说，ETL的过程其实不是非常复杂，这些工具给数据仓库工程带来和很大的便利性，特别是开发的便利和维护的便利。这些工具为我们提供图形化界面，让我们将主要的精力放在规则上，以期提高开发效率。

[if !supportLists]•[endif]数据的抽取

这一部分需要在调研阶段做大量的工作，首先要搞清楚数据是从哪几个业务系统中来，各个业务系统的数据库服务器运行什么DBMS，是否存在手工数据，手工数据量有多大，是否存在非结构化的数据等等，当收集完这些信息之后才可以进行数据抽取的设计。

[if !supportLists]1）[endif]对于与存放DW的数据库系统相同的数据源处理方法这一类数据源在设计上比较容易。一般情况下，

DBMS(SQLServer、Oracle)都会提供数据库链接功能，在DW数据库服务器和原业务系统之间建立直接的链接关系就可以写select语句直接访问。

[if !supportLists]2）[endif]对于与DW数据库系统不同的数据源的处理方法对于这一类数据源，一般情况下也可以通过ODBC的方式建立数据库链接——如SQLServer和Oracle之间。如果不能建立数据库链接，可以有两种方式完成，一种是通过工具将源数据导出成。txt或者是。xls文件，然后再将这些源系统文件导入到ODS中。另外一种方法是通过程序接口来完成。

[if !supportLists]3）[endif]对于文件类型数据源(。txt，。xls)，可以培训业务人员利用数据库工具将这些数据导入到指定的数据库，然后从指定的数据库中抽取。或者还可以借助工具实现，如PowerCenter、DataStage的平面数据源和平面目标等组件导入ODS中去。

[if !supportLists]4）[endif]增量更新的问题对于数据量大的系统，必须考虑增量抽取。一般情况下，业务系统会记录业务发生的时间，我们可以用来做增量的标志，每次抽取之前首先判断ODS中记录最大的时间，然后根据这个时间去业务系统取大于这个时间所有的记录。

[if !supportLists]•[endif]数据的清洗转换

一般情况下，数据仓库分为ODS、DW两部分。通常的做法是从业务系统到ODS做清洗，将脏数据和不完整数据过滤掉，在从ODS到DW的过程中转换，进行一些业务规则的计算和聚合。

²数据清洗

数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由

业务单位修正之后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。

(1)不完整的数据：这一类数据主要是一些应该有的信息缺失，如供应商的名称、分公司的名称、客户的区域信息缺失、业务系统中主表与明细表不能匹配等。对于这一类数据过滤出来，按缺失的内容分别向客户提交，要求在规定的时间内补全。补全后才写入数据仓库。

(2)错误的数据：这一类错误产生的原因是业务系统不够健全，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。

这一类数据也要分类，对于类似于全角字符、数据前后有不可见字符的问题，只能通过写SQL语句的方式找出来，然后要求客户在业务系统修正之后抽取。日期格式不正确的或者是日期越界的这一类错误会导致ETL运行失

败，这一类错误需要去业务系统数据库用SQL的方式挑出来，交给业务主管部门要求限期修正，修正之后再抽取。

(3)重复的数据：对于这一类数据——特别是维表中会出现这种情况——将重复数据记录的所有字段导出来，让客户确认并整理。

数据清洗是一个反复的过程，不可能在几天内完成，只有不断的发现问题，解决问题。对于是否过滤，是否修正一般要求客户确认，对于过滤掉的数据写入数据表，在ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快地修正错误，同时也可以做为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤掉，对于每个过滤规则认真进行验证，并要用户确认。

²数据转换

数据转换的任务主要进行不一致的数据转换、数据粒度的转换，以及一些商务规则的计算。

(1)不一致数据转换：这个过程是一个整合的过程，将不同业务系统的相同类型的数据统一，比如同一个供应商在结算系统的编码是XX0001，而在CRM中编码是YY0001，这样在抽取过来之后统一转换成一个编码。

(2)数据粒度的转换：业务系统一般存储非常明细的数据，而数据仓库中数据是用来分析的，不需要非常明细的数据。一般情况下，会将业务系统数据按照数据仓库粒度进行聚合。

(3)商务规则的计算：不同的企业有不同的业务规则、不同的数据指标，这些指标有的时候不是简单的加加减减就能完成，这个时候需要在ETL中将这些数据指标计算好了之后存储在数据仓库中，以供分析使用。

[if !supportLists]•[endif]ETL日志、警告发送

[if !supportLists]²[endif]ETL日志

ETL日志分为三类。一类是执行过程日志，这一部分日志是在ETL执行过程中每执行一步的记录，记录每次运行每一步骤的起始时间，影响了多少行数据，流水账形式。一类是错误日志，当某个模块出错的时候写错误日志，记录每次出错的时间、出错的模块以及出错的信息等。第三类日志是总体日志，只记录ETL开始时间、结束时间是否成功信息。如果使用ETL工具，ETL工具会自动产生一些日志，这一类日志也可以作为ETL日志的一部分。记录日志的目的是随时可以知道ETL运行情况，如果出错了，可以知道哪里出错。

[if !supportLists]²[endif]警告发送

如果ETL出错了，不仅要形成ETL出错日志，而且要向系统管理员发送警告。发送警告的方式多种，一般常用的就是给系统管理员发送邮件，并附上出错的信息，方便管理员排查错误。

[if !supportLists]•[endif]ETL数据加载策略

下面提到的数据加载策略以OLTP系统作为源系统，并进行ETL数据加载到数据仓库系统中所采用的一般数据加载策略。

根据该方式的特定性，此时ETL数据加载一般存在以下四种方案：

1)、时戳方式需要在OLTP系统中业务表中统一添加时间字段作为时戳（如表中已有相应的时间字段，可以不必添加），每当OLTP系统中更新修改业务数据时，同时修改时戳字段值。当作ETL加载时，通过系统时间与时戳字段的比较来决定进行何种数据抽取。

优点：ETL系统设计清晰，源数据抽取相对清楚简单，速度快。可以实现数据的递增加载。缺点：时戳维护需要由OLTP系统完成，需要修改原OLTP系统中业务表结构；且所有添加时戳的表，在业务系统中，数据发生变化时，同时更新时戳字段，需要对原OLTP系统业务操作程序作修改，工作量大，改动面大，风险大。

2)、日志表方式在OLTP系统中添加系统日志表，当业务数据发生变化时，更新维护日志表内容，当作ETL加载时，通过读日志表数据决定加载那些数据及如何加载。

优点：不需要修改OLTP表结构，源数据抽取清楚，速度较快。可以实现数据的递增加载。缺点：日志表维护需要由OLTP系统完成，需要对OLTP系统业务操作程序作修改，记录日志信息。日志表维护较为麻烦，对原有系统有较大影响。工作量较大，改动较大。有一定风险。

3)、全表比对方式在ETL过程中，抽取所有源数据，并进行相应规则转换，完成后先不插入目标，而对每条数据进行目标表比对。根据主键值进行插入与更新的判定，目标表已存在该主键值的，表示该记录已有，并进行其余字段比对，如有不同，进行Update操作，如目标表没有存在该主键值，表示该记录还没有，即进行Insert操作。

优点：对已有系统表结构不产生影响，不需要修改业务操作程序，所有抽取规则由ETL完成，管理维护统一，可以实现数据的递增加载。没有风险。缺点：ETL比对较复杂，设计较为复杂，速度较慢

4)、全表删除插入方式每次ETL操作均删除目标表数据，由ETL全新加载数据。

优点：ETL加载规则简单，速度快。缺点：对于维表加代理键不适应，当OLTP系统产生删除数据操作时，

OLAP层将不会记录到所删除的历史数据。不可以实现数据的递增加载。

当作系统数据加载策略方案时，基于以上所列方法，及现有系统考虑：

[if !supportLists]1）[endif]、如果所集成OLTP系统为其他产商产品，则应尽量的降低因ETL而对现有系统产生的影响，及系统风险性。而性能的影响则可以通过两方面解决，一部分由硬件的升级进行解决，因为ETL除读表及写表操作外，所有转换均由ETL服务器在内存中完成，故高配置服务器将大大提升ETL运行速度；一部分由加载时机进行控制，加载时机采取在系统较为空闲时加载，同时并行多个加载等，可以降低对运行系统的影响。所以可以使用全表比对递增加载数据的方式作为此类系统的ETL数据加载规则。

[if !supportLists]2）[endif]、如果原OLTP系统为自己开发产品，此次所作OLAP系统为在原系统上的系统，则可以考虑使用时辍或日志表方式，区别仅为对原系统的影响大小。

[if !supportLists]3）[endif]、当数据实现递增加载时，OLAP系统中的聚合表，可由OLAP中的事实表数据二次ETL产生，此时由于

OLAP数据的完整性与准确性，可以使用全表删除插入方式。

•流行的ETL工具

Informatica PowerCenterIBM DataStageOracleOWBBusiness Object DI

2.1.9 OLAP

60年代，关系数据库之父E。F。Cdd提出了关系模型，促进了联机事务处理(OLTP)的发展(数据以表格的形式而非文件方式存储)。1993年，E。F。Cdd提出了OLAP概念，认为OLTP已不能满足终端用户对数据库查询分析的需要，SQL对大型数据库进行的简单查询也不能满足终端用户分析的要求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，E。F。Cdd提出了多维数据库和多维分析的概念，即OLAP。

OLAP(联机分析处理，On-LineAnalyticalProcessing)：是使分析人员、管理人员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、并真实反映企业维特性的信息进行快速、一致、交互地存取，从而获得对数据的更深入了解的一类软件技术。

OLAP的目标：是满足决策支持或多维环境特定的查询和报表需求，它的技术核心是“维”这个概念，因此

OLAP也可以说是多维数据分析工具的集合。

OLTP与OLAP的不同点：

OLTP数据OLAP数据

原始数据导出数据

细节性数据综合性和提炼性数据

当前值数据历史数据

可更新不可更新，但周期性刷新

一次处理的数据量小一次处理的数据量大

面向应用，事务驱动面向分析，分析驱动

面向操作人员，支持日常操作面向决策人员，支持管理需要

OLAP相关基本概念

维：是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维(时间维、地理维等)。维的层次：人们观察数据的某个特定角度(即某个维)还可以存在细节程度不同的各个描述方面(时间维：日期、月份、季度、年)。

维的成员：维的一个取值。是数据项在某维中位置的描述。(“某年某月某日”是在时间维上位置的描述)多维数组：维和变量的组合表示。一个多维数组可以表示为：(维1，维2，……，维n，变量) (时间，地区，产品，销售额)

数据单元(单元格)：多维数组的取值。(2000年1月，上海，笔记本电脑，$100000)

快速性：用户对OLAP的快速反应能力有很高的要求。系统应能在5秒内对用户的大部分分析要求做出反应。如果终端用户在30秒内没有得到系统响应就会变得不耐烦，因而可能失去分析主线索，影响分析质量。对于大量的数据分析要达到这个速度并不容，因此就更需要一些技术上的支持，如专门的数据存储格式、大量的事先运算、特别的硬件设计等。

可分析性：OLAP系统应能处理与应用有关的任何逻辑分析和统计分析。尽管系统需要事先编程，但并不意味着系统已定义好了所有的应用。用户无需编程就可以定义新的专门计算，将其作为分析的一部分，并以用户理想的方式给出报告。用户可以在OLAP平台上进行数据分析，也可以连接到其他外部分析工具上，如时间序列分析工具、成本分配工具、意外报警、数据开采等。

多维性：多维性是OLAP的关键属性。系统必须提供对数据的多维视图和分析，包括对层次维和多重层次维的完全支持。

信息性：不论数据量有多大，也不管数据存储在何处，OLAP系统应能及时获得信息，并且管理大容量信息。这里有许多因素需要考虑，如数据的可复制性、可利用的磁盘空间、OLAP产品的性能及与数据仓库的结合度等。

OLAP多维数据结构

超立方结构(Hypercube)：超立方结构指用三维或更多的维数来描述一个对象，每个维彼此垂直。数据的测量值发生在维的交叉点上，数据空间的各个部分都有相同的维属性。(超立方结构有一种变形，即收缩超立方结构。这种结构的数据密度更大，数据的维数更少，并可加入额外的分析维)。

多立方结构(Multicube)：即将超立方结构变为子立方结构。面向某一特定应用对维进行分割，它具有很强的灵活性，提高了数据(特别是稀疏数据)的分析效率。

一般来说，多立方结构灵活性较大，但超立方结构更易于理解。终端用户更容易接近超立方结构，它可以提供高水平的报告和多维视图。但具有多维分析经验的MIS专家更喜欢多立方结构，因为它具有良好的视图翻转性和灵活性。多立方结构是存储稀疏矩阵的一个更有效方法，并能减少计算量。因此，复杂的系统及预先建立的通用应用倾向于使用多立方结构，以使数据结构能更好地得到调整，满足常用的应用需求。许多产品结合了上述两种结构，它们的数据物理结构是多立方结构，但却利用超立方结构来进行计算，结合了超立方结构的简化性和多立方结构的旋转存储特性。

OLAP多维数据分析

切片和切块(SliceandDice)：多维数据结构中，在一部分维上选定值后，关心度量数据在剩余维上的分布，如果剩余的维只有两个，则是切片；如果有三个，则是切块。如在“城市、产品、时间”三维立方体中进行切块和切片，可得到各城市、各产品的销售情况。

钻取(Drill)：它是改变维的层次，变换分析的粒度。钻取包含向下钻取(Drill-down)和向上钻取(Drill-up)/上卷(Roll-up)操作，rollup是在某一维上将低层次的细节数据概括到高层次的汇总数据，或者减少维数；而drilldown则相反，它从汇总数据深入到细节数据进行观察或增加新维。

旋转(Rotate)/转轴(Pivot)：旋转是变换维的方向，即在表格中重新安排维的放置（例如行列互换）。通过旋转可以得到不同视角的数据。

OLAP的多种实现方法

OLAP的实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP：

ROLAP表示基于关系数据库的OLAP实现（Relational OLAP）。以关系数据库为核心，以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表：一类是事实表，用来存储数据和维关键字；另一类是维表，即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。维表和事实表通过主关键字和外关键字联系在一起，形成了“星型模型”。对于层次复杂的维，为避免冗余数据占用过大的存储空间，可以使用多个表来描述，这种星型模型的扩展称为“雪花模型”。

MOLAP表示基于多维数据组织的OLAP实现（Multi-Dimensional OLAP）。以多维数据组织方式为核心，也就是说，MOLAP使用多维数组存储数据。多维数据在存储中将形成“立方块（Cube）”的结构，在MOLAP中对立方块的“旋转”、“切块”、“切片”是产生多维数据报表的主要技术。

HOLAP表示基于混合数据组织的OLAP实现（HybridOLAP）。如低层是关系型的，高层是多维矩阵型的。这种方式具有更好的灵活性。

还有其他的一些实现OLAP的方法，如提供一个专用的SQLServer，对某些存储模式（如星型、雪片型）提供对SQL查询的特殊支持。

2.1.10多维数据库

多维数据库（Multi-Dimesional Database，MDD）可以简单地理解为：将数据存放在一个n维数组中，而不

是像关系数据库那样以记录的形式存放。因此它存在大量稀疏矩阵，人们可以通过多维视图来观察数据。多维数据库增加了一个时间维，与关系数据库相比，它的优势在于可以提高数据处理速度，加快反应时间，提高查询效率。

目前有两种MDD的OLAP产品：基于多维数据库的MOLAP和基于关系数据库的ROLAP。ROLAP建立了一种新的体系，即星型结构。

MDD并没有公认的多维模型，也没有像关系模型那样标准地取得数据的方法(如SQL、API等)。基于MDD的OLAP产品，依据决策支持的内容使用范围也有很大的不同。

在低端，用户使用基于单用户或小型LAN的工具来观察多维数据。这些工具的功能性和实用性可能相当不错，但由于受到规模的限制，它们不具备OLAP的所有特性。这些工具使用超立方结构，将模型限制在n维形态。当模型足够大且稀疏数据没有控制好时，这种模型将会不堪一击。这些工具使用数据库的大小是以MB来计量的，而不是以GB计量的，因此只能进行只读操作，且具备有限的复杂计算。

在高端，OLAP工具用4GL提供了完善的开发环境、统计分析、时间序列分析、财政报告、用户接口、多层体系结构、图表等许多其他功能。尽管不同的OLAP工具都使用了它们自己的多维数据库，但它们在不同程度上也利用了关系数据库作为存储媒体。因为关系数据库和OLAP工具同时在高端服务器上处理，所以速度和效率仍然很快。

纯多维数据库引擎也被开发出来。尽管这些工具缺乏4GL及充分的开发环境，但却有比高端MDD工具所使用的数据库更为复杂的数据库。这些工具也具有统计分析、财务分析和时间序列分析等功能，并有自己的API，允许其对前端的开发环境开放。

MDD能提供优良的查询性能。存储在MDD中的信息比在关系数据库中的信息具有更详细的索引，可以常驻在内存中。MDD的信息是以数组形式存放的，所以它可以在不影响索引的情况下更新数据。因此MDD非常适合于读写应用。

流行的OLAP工具

Hyperion EssbaseIBM DB2 OLAP ServerBrioMicroStrategy

Oracle ExpressMicrosoft analysis servicesCognosBusiness Object

2.2数据仓库架构

目前来说，数据仓库架构比较成熟并已经形成理论的主要有两个，一个是Corporate Information Factory，简称CIF，中文一般翻译为企业信息工厂，代表人物是BillInmon。另一个是Mutil-Dimensional Architecture，简称

MD，中文一般翻译为多维体系结构，代表人物是RalphKimball。

企业信息工厂主要包括集成转换层（Integratedand Transformation Layer）、操作数据存储（Operational

DataStore）、数据仓库（Enterprise Data Warehouse）、数据集市（Data

Mart）、探索仓库（Exploration Warehouse）等部件。

多维体系结构分为后台（Back

Room）和前台（Front Room）两部分。后台主要负责数据准备工作，称为数据准备区（StagingArea），前台主要负责数据展示工作，称为数据集市（DataMart）。而数据仓库是一个虚拟的部件，它指的是全部数据集市的集合。

两个数据仓库架构各有优缺点，一种比较流行的做法是合用两种架构，即建立CIF的数据仓库和MD的数据集市。

HWBIS系统架构

华为BIS系统采用的就是合用CIF数据仓库和MD数据集市的架构。

技术架构

三层架构模型将传统操作业务切分成几个层次，每个层次提供不同的相关服务，如DB服务、应用服务、

Web服务等。三层架构为系统提供了复杂应用操作，同时提供对现有应用集成及今后应用扩展强有力的支持，增强了安全机制，提高了性能，并提供对LDAP目录服务的支持。

[if !vml]

[endif]

三层架构包括数据库层，应用服务器层，用户终端层。其中数据库层，采用Unix平台上的Oracle9i系统作为数据库服务器。Oracle作为最先进的数据库产品，具有性能优越，工作稳定可靠，适合数据仓库系统要求的海量数据存储的需要。应用服务器层运行包括ETL服务（抽取，转换，加载），元数据服务，Reporting服务，

Portal服务，OLAP服务等五种应用。用户终端层只需通过浏览器，访问华为业务智能系统各应用。

ETL服务器采用CA的ADTEMEServer，它可以同时连接多达64个不同的数据源。对华为来说，这些数据源包括Notes，SQLServer，Oracle，Textfile等。这些数据通过ADTServer进行加工转换后，进入到数据仓库中。

OLAP分析主要采用MSOLAP与BO相结合的方式。BO作为前端可以进行钻取，切片，旋转等多维分析操作，而MSOLAP则存放CUBE。这种方式可以将运算操作集中于Cube服务器，而Client端无需将Cube下载到本地，节约了空间，减少了网络负载，同时提高了数据展现的效率。通过BO的Universe方式，还可以进行灵活的查询，生成固定格式的报表。

由于有不少的数据来源于纸面或某些数据需要调整，所以需要一个补录系统来输入这些数据，并可以维护这些数据。补录系统采用JSP方式或Java方式进行开发，遵循J2EE架构，可以采用的应用服务器包括Oracle

Form Server，WebLogic，Websphere。

以上的前端应用均可实现Web方式的访问，只不过还需配置BO WebServer和WebServer。整个过程中产生的模型通过模型管理工具Erwin和ModelMart进行管理。

元数据由Repository进行管理。通过Data Shopper，最终用户可以方便地浏览元数据。通过Repository

Client，管理人员可以方便地对元数据进行管理和维护。

数据架构

从5个层次来设计华为数据仓库环境的数据架构，数据储存、模式、各主题的数据概念模型、逻辑模型和物理模型，各主题的数据概念模型、逻辑模型和物理模型在数据架构设计中实现。

整个数据仓库环境分为4个数据区，即数据源区，数据仓库区，OLAP区和元数据区。数据仓库从物理上分

又为4个区：数据准备区（Staging Area），当前数据和历史数据区（ODS），细节数据（Base Line），数据集市

（Data

Mart）。

HWBIS数据仓库环境的数据储存架构

[if !vml]

[endif]

Staging区：对存储空间的要求是临时的，且是暂时存放每天从OLTP系统抽取的变更的数据。

ODS区，存放两部分数据，一部分是当前变更的数据，一部分是存放从OLTP抽取的历史数据。

BaseLine区，该区存放经过转换后的细节数据。

DataMart区，该区存放汇总数据。