目录
数据源
- 数据源：是指企业操作型数据库中的各种生产运营数据、办公管理数据等内部数据
和一些调查数据、市场信息等来自外环境的数据总称。这些数据是构建数据仓库系统的
基础是整个系统的数据源泉。
数据的存储与管理
- 数据仓库的存储主要由元数据的存储及数据的存储两部分组
成。元数据是关于数据的数据，其内容主要包括数据仓库的数据字典、数据的定义、数
据的抽取规则、数据的转换规则、数据加载频率等信息。各操作数据库中的数据按照元
数据库中定义的规则，经过抽取、清理、转换、集成，按照主题重新组织，依照相应的
存储结构进行存储。也可以面向应用建立一些数据集市，数据集市可以看作是数据仓库
的一个子集，它含有较少的主题域且历史时间更短数据量更少，一般只能为某个局部范
围内的管理人员服务，因此也称之为部门级数据仓库。
数据的访问
- 数据的访问：由OLAP(联机分析处理)、数据挖掘、统计报表、即席查询等几部分组
成。例如OLAP：针对特定的分析主题，设计多种可能的观察形式，设计相应的分析主题
结构（即进行事实表和维表的设计），使管理决策人员在多维数据模型的基础上进行快
速、稳定和交互性的访问，并进行各种复杂的分析和预测工作。按照存储方式来分，OLAP
可以分成MOLAP以及ROLAP等方式,MOLAP (Multi-Dimension OLAP)将OLAP分析所需的数据存放在多维数据库中。分析主题的数据可以形成一个或多个多维立方体。ROLAP
(Relational OLAP)将OLAP分析所需的数据存放在关系型数据库中。分析主题的数据以
“事实表-维表”的星型模式组织。
企业信息工厂
- 企业信息工厂（Corporate Information Factory，简称EIF）是一种构建数据仓库
的架构。企业信息工厂的创始人是数据仓库之父Inmon。
企业信息工厂主要包括集成转换层（I&T）、操作数据存储（ODS）、企业级数据仓
库（EDW）、数据集市（DM）、探索仓库（EW）等部件。这些部件有机的结合在一起，
为企业提供信息服务。
集成转换层
集成转换层的目的是将来自操作型源系统的数据集成转换到数据仓库中，它通常由
一组程序组成，而其它部件如数据仓库和数据集市等则主要由数据组成。当业务数据来
源多，业务复杂时，集成转换层会建立一些临时表，为数据处理提供方便。这时，集成
转换层包括程序和数据，也称数据准备区（Data Staging Area）。通常中等规模及以
上的数据仓库系统都会建立数据准备区。
操作数据存储（ODS）
操作数据存储（ODS）是建立在数据准备区和数据仓库之间的一个部件。用来满足
企业集成的、综合的操作型处理需要。例如，出尽可能实时的集成的操作报表等需求。
数据仓库入门教程
一般，也称操作数据存储是用来满足企业战术决策的需要。操作数据存储是个可选的部
件。
数据仓库
企业级数据仓库是企业信息工厂的核心部件，用来保存整个企业的数据。一般，也
称数据仓库，是用来满足企业战略决策的需要。数据仓库的数据来自数据准备区和操作
数据存储
数据集市
- 数据集市是为了满足企业特定部门的分析需求而专门建立的数据的集合。数据集市
的数据来源是数据仓库。企业信息工厂中的数据集市一般来说是非规范化的、定制的和
汇总的。而多维体系架构中的数据集市分为两种，分别是原子数据集市和聚集数据集市。
一般来说，企业信息工厂中的数据集市相当于多维体系架构中的聚集数据集市。 - 探索仓库或数据挖掘仓库的建立主要是为了解决大型查询，提高数据仓库的效率。
当有探索或挖掘需求时，会从数据仓库导出一部分数据提供给他们操作。
数据建立流程
企业信息工厂中的数据流向一般是从源系统到数据准备区到操作数据存储到数据
仓库到数据集市。当分析人员在数据仓库或数据集市中得出分析结论后，会有信息的回
流。这种信息回流有可能是物理数据的回流，也可能是直接改变业务部门的策略，总之，
要将分析的结果应用起来。通过这种信息的回流，企业信息工厂的不同部件可以不断的
相互调整，最终找到一种平衡。这也是称为企业信息工厂的原因。
维
维，是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维。
假定某某是个百货零售商，有一些因素会影响他的销售业务，如商品、时间、商店
或流通渠道，更具体一点，如品牌、月份、地区等。对某一给定的商品，也许他想知道
该商品在哪个商店和哪段时间的销售情况。对某一商店，也许他想知道哪个商品在哪段
时间的销售情况。在某一时间，也许他想知道哪个商店哪种产品的销售情况。因此，他
需要决策支持来帮助制定销售政策。
这里，商店、时间和产品都是维。各个商店的集合是一个维，时间的集合是一个维，
商品的集合也是一个维。
代理关键字
在数据仓库领域有一个概念叫Surrogate key，中文一般翻译为“代理关键字”。代
理关键字一般是指维度表中使用顺序（序列）分配的整数值作为主键，也称为“代理键”。
代理关键字用于维度表和事实表的连接。
在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。在维度表和事实表
的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或者智能关键字
（Smart Keys）。数据仓库中的主键不应该是智能的，也就是说，要避免通过主键的值
就可以了解一些业务信息。当然，退化维度作为事实表的复合主键之一时例外。
使用代理关键字，有很多优点。
1．使用代理关键字能够使数据仓库环境对操作型环境的变化进行缓冲。也就是说，
当数据仓库需要对来在多个操作型系统的数据进行整合时，这些系统中的数据有可能缺
乏一致的关键字编码，即有可能出现重复，这时代理关键字可以解决这个问题。
2．使用代理关键字可以带来性能上的优势。和自然关键字相比，代理关键字很小，
是整型的，可以减小事实表中记录的长度。这样，同样的IO就可以读取更多的事实表
记录。另外，整型字段作为外键联接的效率也很高。
3．使用代理关键字可以建立一些不存在的维度记录，例如 “日期待定”，“日期
不可用”等维度记录。
4．使用代理关键字可以用来处理缓慢变化维。维度表数据的历史变化信息的保存是
数据仓库设计的实施中非常重要的一部分。Kimball的缓慢变化维处理策略的核心就是
使用代理关键字。
当然，使用代理关键字也有它的缺点，代理关键字的使用使数据加载变得非常复杂。
缓慢变化维
维度建模的数据仓库中，有一个概念叫Slowly Changing Dimensions，中文一般翻
译成“缓慢变化维”，经常被简写为SCD。缓慢变化维的提出是因为在现实世界中，维
度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。这种随时间发生变化的
维度我们一般称之为缓慢变化维，并且把处理维度表的历史变化信息的问题称为处理缓
慢变化维的问题，有时也简称为处理SCD的问题。
处理缓慢变化维的方法通常有三种方式：
第一种方式是直接覆盖原值。这样处理，最容易实现，但是没有保留历史数据，无
法分析历史变化信息。第一种方式通常简称为“TYPE 1”。
第二种方式是添加维度行。这样处理，需要代理键的支持。实现方式是当有维度属
性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原
维度记录保持关联。第二种方式通常简称为“TYPE 2”。
第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添
加一列，来记录该属性变化前的值，而本属性字段使用TYPE 1来直接覆盖。这种方式
的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信
息。第三种方式通常简称为“TYPE 3”。
在实际建模中，我们可以联合使用三种方式，也可以对一个维度表中的不同属性使
用不同的方式，这些，都需要根据实际情况来决定，但目的都是一样的，就是能够支持
方便的分析历史变化情况。
退化维度
在维度建模的数据仓库中，有一种维度叫Degenerate Dimension，中文一般翻译为
“退化维度”。这种退化维度一般都是事务的编号，如订单编号、发票编号等。这类编
号需要保存到事实表中，但是不需要对应的维度表，所以称为退化维度。
退化维度经常会和其他一些维度一起组合成事实表的主键。在Kimball提出的维度
建模中，事实表应该保存最细粒度的数据。所以对于象销售单这样的事实表来说，需要
销售单编号和产品来共同作为主键，而不能用销售日期、商场、产品等用来分析的维度
共同作为主键。
退化维度在分析中可以用来做分组使用。它可以将同一个事务中销售的产品集中在
一起。
微型维度
维度建模的数据仓库中，有一种维度叫minidimension，中文一般翻译成“微型维
度”。微型维度的提出主要是为了解决快变超大维度（rapidly changing monster
dimension）。
以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中
的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计
人员一般不会使用TYPE 2的缓慢变化维处理方法，因为大家都不愿意向本来就有几百
万行的维度表中添加更多的行。
这时，有一项技术可以解决这个问题。解决的方法是，将分析频率比较高或者变化
频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度
表。
微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。
有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度
表。这时一定要注意，这个外关键字必须做TYPE 1型处理。
在微型维度表中如果有像收入这样分布范围较广的属性时，应该将它分段处理。比
如，存储￥31257.98这样过于分散的数值就不如存储￥30000－￥34999这样的范围。这
样可以极大的减少微型维度中的记录数目，也给分析带来方便。
一致性维度
维度建模的数据仓库中，有一个概念叫Conformed Dimension，中文一般翻译为“一
致性维度”。一致性维度是Kimball的多维体系结构（MD）中的三个关键性概念之一，
另两个是总线架构（Bus Architecture）和一致性事实（Conformed Fact）。
在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的
数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓
库。如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组
合成数据仓库，而一致性维度的提出正式为了解决这个问题。
一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，
这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，
都是经过数据清洗和整合后的结果。
一致性维度建立的地点是多维体系结构的后台（Back Room），即数据准备区。在
多维体系结构的数据仓库项目组内需要有专门的维度设计师，他的职责就是建立维度和
维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市
的这部分维度都是完全相同的。建立新的数据集市时，需要在后台进行一致性维度处理，
根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。这是不同
数据集市维度保持一致的要点。
在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，
要么就是一个维度在数学意义上是另一个维度的子集。例如，如果建立月维度话，月维
度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图
生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。
如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。
这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立
的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察
等操作，也就组成了数据仓库。
杂项维度
在维度建模的数据仓库中，有一种维度叫Junk Dimension，中文一般翻译为“杂项
维度”。杂项维度是由操作系统中的指示符或者标志字段组合而成，一般不在一致性维
度之列。
在操作系统中，我们定义好各种维度后，通常还会剩下一些在小范围内取离散值的
指示符或者标志字段。例如：支付类型字段，包括现金和信用卡两种类型，在源系统中
它们可能是维护在类型表中，也可能直接保存在交易表中。
一张事实表中可能会存在好几个类似的字段，如果作为事实存放在事实表中，会导
致事实表占用空间过大；如果单独建立维度表，外键关联到事实表，会出现维度过多的
情况；如果将这些字段删除，会有人不同意。
这时，我们通常的解决方案就是建立杂项维度，将这些字段建立到一个维度表中，
在事实表中只需保存一个外键。几个字段的不同取值组成一条记录，生成代理键，存入
维度表，并将该代理键保存入相应的事实表字段。建议不要直接使用所有的组合生成完
整的杂项维度表，在抽取时遇到新的组合时生成相应记录即可。杂项维度的ETL过程比
一般的维度略为复杂。
事实表
在维度建模的数据仓库中，事实表是指其中保存了大量业务度量数据的表。事实表
中的度量值一般称为事实。在事实表中最有用的事实就是数字类型的事实和可加类型的
事实。事实表的粒度决定了数据仓库中数据的详细程度。
一般来说，以粒度作为化分依据，主要有三种事实表，分别是事务粒度事实表
（Transaction Grain Fact Table），周期快照粒度事实表（Periodic Snapshot Grain Fact
Table）和累积快照粒度事实表（Accumulating Snapshot Grain Fact Table）；从用途
的不同来说，事实表可以分为三类，分别是原子事实表，聚集事实表和合并事实表。
事务粒度事实表
事务事实表（Transaction fact table）记录的事务层面的事实，保存的是最原子的数
据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通
常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，
其更新方式为增量更新。
事务事实表的日期维度记录的是事务发生的日期，它记录的事实是事务活动的内容。
用户可以通过事务事实表对事务行为进行特别详细的分析。
周期快照粒度事实表
周期快照事实表（Periodic snapshot fact table）以具有规律性的、可预见的时间间
隔来记录事实，时间间隔如每天、每月、每年等等。典型的例子如销售日快照表、库存
日快照表等。
周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是
在事务事实表之上建立的聚集表。周期快照事实表的维度个数比事务事实表要少，但是
记录的事实要比事务事实表多。
周期快照事实表的日期维度通常是记录时间段的终止日，记录的事实是这个时间段
内一些聚集事实值。事实表的数据一旦插入即不能更改，其更新方式为增量更新。
累积快照事实表
累积快照事实表（Accumulating snapshot fact table）和周期快照事实表有些相似
之处，它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同，周期快
照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。
累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常
具有多个日期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于
指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，
所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可
以对它进行更新的，来补充随后知道的日期信息。
举例来说：
订货日期
预定交货日期
实际发货日期
实际交货日期
数量
金额
运费
在这个累积快照事实表中，记录的是购买货物的整个生命周期的数据，记录第一次
产生时，实际发货日期和实际交货日期是不确定的，需要用表示未知的代理关键字来代
替。等实际发货后，需要对数据仓库中的这条记录进行更新操作，将实际发货日期补上。
原子事实表
原子事实表（Atom Fact Table）是保存最细粒度数据的事实表，也是数据仓库中保
存原子信息的场所。
聚集事实表
聚集事实表（Aggregated Fact Table）是原子事实表上的汇总数据，也称为汇总事
实表。即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度
表的子集，如用月份维度表代替日期维度表；事实数据是相应事实的汇总，即求和或求
平均值等。在做数据迁移时，当相关的维度数据和事实数据发生变化时，聚集事实表需
要做相应的刷新。物化视图是实现聚集事实表的一种有效方式，可以设定刷新方式，具
体功能由DBMS来实现。
合并事实表
合并事实表（Consolidated Fact Table）是指将位于不同事实表中处于相同粒度的
事实进行组合建模而成的一种事实表。即新建立一个事实表，它的维度是两个或多个事
实表的相同维度的集合；事实是几个事实表中感兴趣的事实。在Kimball的总线架构中，
由合并事实表为主组成的合并数据集市称为二级数据集市。合并事实表的粒度可以是原
子粒度也可以是聚集粒度。在做数据迁移时，当相关的原子事实表的数据有改变时，合
并事实表的数据需要重新刷新。合并事实表和交叉探察是两个互补的操作。
聚集事实表和合并事实表的主要差别是合并事实表一般是从多个事实表合并而来。
但是它们的差别不是绝对的，一个事实表既是聚集事实表又是合并事实表是很有可能
的。因为一般合并事实表需要按相同的维度合并，所以很可能在做合并的同时需要进行
聚集，即粒度变粗。
旋转事实表
旋转事实表（pivoted fact table）是将一条记录中的多个事实字段转化为多条记录，
其中每条记录保存一个事实字段的一种建模方法。或者反过来，也可以由多条记录转化
为一条记录。
旋转事实表建模方法的使用通常是为了简化前端数据展现的查询。它通过改变后端
的事实记录存储方式，使相应的查询需求的性能得到的极大的提高。如果在SQL或者查
询工具中进行这种转换会非常麻烦，效率也很差。
和合并事实表类似，有时当基础表中没有记录时，旋转事实表也要存储一些零值在
里面。
预连接聚集表
预连接聚集表（pre-joined aggregagte table）是通过对事实表和维度表的联合查询
而生成的一类汇总表。在预连接聚集表中，保存有维度表中的描述信息和事实表的事实
值。
通过预连接，可以避免在用户查询时RDBMS的连接操作，所以预连接聚集表的查
询效率要高很多。
在这个销售事实表，前五个字段都来自于维度表的描述字段，后两个字段来自于事
实表的事实字段。这样在用户提交查询后，RDBMS就不需要连接维度表和事实表了，
只需直接在该表中查询即可。
预连接聚集表有一个很大的缺点，它需要占用大量的存储空间。预连接事实表的记
录和事实表一样多，每条记录的长度和维度表一样长，所以对存储空间的需求是非常大
的。除非情况特殊，或者该表是高度汇总的，否则不建议建立预连接聚集表。在建立预
连接聚集表时需要平衡效率和存储空间的矛盾。
预连接聚集表的生成方式较为简单，直接使用SQL查询即可生成。
如果聚集导航器的功能很强大的话，也可以处理预连接聚集表。否则，需要用户理
解预连接聚集表，并在SQL中直接使用该表。
预连接聚集表在数据仓库领域有着很重要的作用，是汇总表的一种。它的优点和缺
点都很明显，在使用时需要综合考虑。
非事实型事实表
在非事实型事实表（Factless Fact Table），通常会保存十个左右的维度外键和多个
度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只
有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下
面举例来进行说明。
第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校需要
对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专
业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒
为1。这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况
下的注册数。
第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。
通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商
品没法回答。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表
保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出
去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。
切片事实表
切片事实表（sliced fact table）中的字段结构和相应的基础表完全相同，差别在于
存储的记录的范围。切片事实表中保存记录的是相应基础表中记录的子集，记录数通常
与某个维度记录数相同。
这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以将与之相
关的数据切片出来。相反，这种方法也常用于合并存储在不同地区的数据，即各个地区
都保存自己地区的数据，总部和所有地区的表结构都相同，然后总部将所有地区的数据
合并在一起。
切片事实表的结构与相对应的基础表相同，数据来源于相对应的基础表。切片事实
表由于缩小了表中数据的记录数，所以查询的效率得到了很大的提高。
蜈蚣事实表
蜈蚣事实表（Centipede fact table）是指那些一张事实表中有太多维度的事实表。
连接在事实表两边的维度表过多，看起来就像蜈蚣一样，所以称为“蜈蚣事实表”。
通常来说，蜈蚣事实表的出现是由于建模师对事实表和维度表逆规范化过了头。例
如，不单将产品主键放入事实表中，对于产品层级结构中的每一层的主键都放入事实表
中，这样事实表中与产品相关的就会有产品ID、商标ID、子类ID、类别ID等多个外键。
同样，也有建模师将日期相关的日期ID、月ID、年ID都放入事实表中。这些都将产生
蜈蚣事实表，使自己落入维度过多的陷阱。
蜈蚣事实表虽然使查询效率有所提高，但是伴之而来的是存储空间的大量增长。在
维度建模的数据仓库中，维度表的字段个数可以尽可能的增加，但是事实表的字段要尽
量减少，因为相比而言，事实表的记录数要远远大于维度表的记录数。
一般来说，事实表相关的维度在15个以下为正常，如果维度个数超过25个，就出现
了维度过多的蜈蚣事实表。这时，需要做的事情是自己核查，将相关的维度进行合并，
减少维度的个数。
一致性事实
一致性事实（Conformed Fact）是Kimball的多维体系结构（MD）中的三个关键性
概念之一，另两个是总线架构（Bus Architecture）和一致性维度（Conformed
Dimension）。
在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%
的工作量。余下的工作就是建立一致性事实。
一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），
发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要
查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。
为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点。第一个是
KPI的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上
就不能保持一致的话，建议不同单位的事实分开建立字段保存。
这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的
事实数据可以交叉探查，一个分布式的数据仓库就建成了。
数据集市
数据集市（Data mart）也叫做“小数据仓库”。如果说数据仓库是建立在企业级的
数据模型之上的话，那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级
业务，并且只面向某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶
颈。
即席查询
即席查询（Ad hoc queries）是指那些用户在使用系统时，根据自己当时的需求定
义的查询。
即席查询生成的方式很多，最常见的就是使用即席查询工具。一般的数据展现工具
都会提供即席查询的功能。通常的方式是，将数据仓库中的维度表和事实表映射到语义
层，用户可以通过语义层选择表，建立表间的关联，最终生成SQL语句。
即席查询与通常查询从SQL语句上来说，并没有本质的差别。它们之间的差别在于，
通常的查询在系统设计和实施时是已知的，所有我们可以在系统实施时通过建立索引、
分区等技术来优化这些查询，使这些查询的效率很高。而即席查询是用户在使用时临时
生产的，系统无法预先优化这些查询，所以即席查询也是评估数据仓库的一个重要指标。
即席查询的位置通常是在关系型的数据仓库中，即在EDW或者ROLAP中。多维数
据库有自己的存储方式，对即席查询和通常查询没有区别。
在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高，对数据
模型的对称性的要求也越高。对称性的数据模型对所有的查询都是相同的，这也是维度
建模的一个优点。
ODS
在数据仓库架构中有一种部件叫Operational Data Store（ODS），中文一般翻译为
“操作数据存储”。操作数据存储在通常的数据仓库架构中都是一个可选的部件，它和
数据仓库起到互相补充的作用。
最早给ODS下定义的是数据仓库之父Inmon。他的定义是，操作数据存储（ODS）
是面向主题的、集成的、可变的、反映当前数据值的和详细的数据的集合，用来满足企
业综合的、集成的以及操作型的处理需求。
Inmon的这个定义与他对数据仓库的定义很像。其中前两个特性和数据仓库是一样
的，即都是面向主题的和集成的，而后三个特性和数据仓库相差较大。
ODS中的数据是可以变化的：这一点是Inmon相对与他的CIF（企业信息工厂）中
的数据仓库来说的，在CIF中，数据仓库中的数据是不进行更新的，对于错误的处理通
常是采用新的快照来进行保存。而ODS是可以按常规方法进行更新的。
ODS反映当前数据值：这一点是指ODS中不会长期的保留数据，通常ODS保留的数
据的时限最长到一个月或三个月。而数据仓库可以保留五年、十年或更长的数据。
ODS中保留详细数据：这一点是说ODS中只保留原子数据，而不保留汇总数据。而
在数据仓库中原子数据和汇总数据都会进行保留。这和ODS可更新的特性相关，因为随
时可能将操作型系统的数据变化更新到ODS中，并且数据的迁移时间间隔会很短，这都
使汇总数据在ODS中的意义不大。
Inmon在给ODS下了定义之后，进一步把ODS分成了四类。根据数据到达ODS的时
间间隔，即数据从操作型系统生成开始到数据到达ODS为止的时间长短，ODS分为Class
I、Class II、Class III和Class IV四类。
Class I
Class I的ODS：指时间间隔为秒级，即对用户来说，ODS是个透明的部件，操作型系统业务发生后，数据立刻就可以在ODS中看到。这类ODS事实上是很难实现的。秒级的数据迁移间隔，我们没有时间进行数据的整合。对于此类ODS，从技术和成本上来说，都是不合算的。
Class II
指时间间隔为小时级，即操作型系统业务发生后，数据要经个几个小时才能出现在ODS部件中。
Class III
指时间间隔为天级，即我们常见到的数据仓库的迁移频率，如每天晚上进行一次数据迁移
Class IV
指时间间隔更长，可能为月级、甚至年级。Class IV和其他类尤为不同的一点是，Class IV的数据源经常是数据仓库
在Class IV的ODS中，最为常见的记录就是从数据仓库中总结出来的概况数据
（Profile Record）。概况数据是数据情况的大纲。以客户为例，可以总结的概况数据
如下：每月买衣服的件数，每周的销售量，每年会看两次眼科医生等等。ODS中的概况
数据是从大量的详细数据中总结出来的，大部分是统计和挖掘处理的结果，它们存放到
ODS中，供操作人员了解客户的情况。
由于ODS仍然存储在普通的关系数据库中，出于性能、存储和备份恢复等数据库的
角度以及对源数据库的性能影响角度，个人不建议ODS保存相当长周期的数据，同样
ODS中的数据也尽量不做转换，而是原封不动地与业务数据库保持一致。即ODS只是
业务数据库的一个备份或者映像，目的是为了使数据仓库的处理和决策支持要求与
OLTP系统相隔离，减少决策支持要求对OLTP系统的影响。
ODS的作用
为什么需要有一个ODS呢？一般在带有ODS的系统体系结构中，ODS都具备如下几
个作用：
1）在业务系统和数据仓库之间形成一个隔离层
一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理
位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容
易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、
数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据
转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。
2）转移一部分业务系统细节查询的功能
在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复
杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织
方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数
据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。
3）完成数据仓库中不能完成的一些功能
一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过
的数据和运营指标，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可
能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完
成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查
询功能。即数据仓库从宏观角度满足企业的决策支持要求，而ODS层则从微观角度反映
细节交易数据或者低粒度的数据查询要求。
在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是
根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相
当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，
而是“历史的，不再变化的”数据。这样的数据仓库的存储压力和性能压力都是比较大
的，因此对数据仓库的物理设计和逻辑设计提出了更高的要求。
元数据
正如其他种类的仓库都要保留一个库存清单一样，数据仓库也要也要保留一个‘库
存’清单，以跟踪那些数据仓库中保存的数据的结构、定义以及这些数据的‘来历’等
等。这个‘库存’清单实质上就是我们现在所说的元数据。不过元数据对于数据仓库的
意义比‘库存’对于实际意义上的仓库大得多。
随着数据仓库（DW）技术的不断成熟，企业的数据逐渐变成了决策的主要依据。
数据仓库中的数据是从许多业务处理系统中抽取、转换而来，对于这样一个复杂的企业
数据环境，如何以安全、高效的方式来对它们进行管理和访问就变得尤为重要。解决这
一问题的关键就是建立数据仓库元数据库，并对这个元数据库进行有效的管理。从某种
意义上来说，能否建立并管理好元数据，将决定着数据仓库项目的成败。
按照传统的定义，元数据（Metadata）是关于数据的数据。我们可以把它理解为比
一般意义的数据范畴更加广泛的数据。它不再仅仅表示数据的类型、名称、值等信息，
它进一步描述了数据的上下文描述信息，比如数据所属的区域、取值范围、数据间的关
系、业务规则、甚至ETL规则、甚至数据的来源信息等。
元数据可以看作是数据仓库系统的‘数据字典’，但这个数据字典比传统意义上数
据库的数据字典功能要强大的多。它可以帮助数据仓库管理员和数据仓库的开发人员非
常方便地找到他们所关心的数据；并可以回答最终用户数据仓库中有哪些数据，这些数
据从哪里来等重要的问题。
可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务/商业元
数据（Business Metadata）。
技术元数据
技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库
使用的数据，它主要包括以下信息：
1）数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，
以及数据集市的位置和内容；
2）业务系统、数据仓库和数据集市的体系结构和模式；
3）汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预
定义的查询与报告；
4）由操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据
提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。
业务/商业元数据
业务/商业元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实
际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数
据。业务/商业元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象
名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的
信息；具体包括以下信息：
1）企业概念/逻辑模型：这是业务/商业元数据所应提供的重要的信息，它表示企
业数据模型的高层信息、整个企业的业务概念和相互关系。以这个企业模型为基础，不
懂数据库技术和SQL语句的业务人员对数据仓库中的数据也能做到心中有数。
2）多维数据模型：这是企业概念模型的重要组成部分，它告诉业务分析人员在数据
集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立
方体表示某主题领域业务事实表和维表的多维组织形式。
3）业务概念模型和物理数据之间的映射、依赖：以上提到的业务/商业元数据只是
表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、多维数据库中的
表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所体现。
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、Oracle OWB、
SQLServer2000的DTS等，且不说他们的好坏。从应用角度来说，ETL的过程其实不是
非常复杂，这些工具给数据仓库工程带来和很大的便利性，特别是开发的便利和维护的
便利。这些工具为我们提供图形化界面，让我们将主要的精力放在规则上，以期提高开
发效率。
数据的抽取
这一部分需要在调研阶段做大量的工作，首先要搞清楚数据是从哪几个业务系统中
来,各个业务系统的数据库服务器运行什么DBMS,是否存在手工数据，手工数据量有多
大，是否存在非结构化的数据等等，当收集完这些信息之后才可以进行数据抽取的设计。
1）对于与存放DW的数据库系统相同的数据源处理方法
这一类数据源在设计上比较容易。一般情况下，DBMS(SQLServer、Oracle)都会提
供数据库链接功能，在DW数据库服务器和原业务系统之间建立直接的链接关系就可以
写select语句直接访问。
2）对于与DW数据库系统不同的数据源的处理方法
对于这一类数据源，一般情况下也可以通过ODBC的方式建立数据库链接——如
SQLServer和Oracle之间。如果不能建立数据库链接，可以有两种方式完成，一种是通
过工具将源数据导出成.txt或者是.xls文件，然后再将这些源系统文件导入到ODS中。另
外一种方法是通过程序接口来完成。
3）对于文件类型数据源(.txt,.xls)，可以培训业务人员利用数据库工具将这些数据导
入到指定的数据库，然后从指定的数据库中抽取。或者还可以借助工具实现，如
PowerCenter、DataStage的平面数据源和平面目标等组件导入ODS中去。
4）增量更新的问题
对于数据量大的系统，必须考虑增量抽取。一般情况下，业务系统会记录业务发生
的时间，我们可以用来做增量的标志,每次抽取之前首先判断ODS中记录最大的时间，
然后根据这个时间去业务系统取大于这个时间所有的记录。
数据的清洗转换
一般情况下，数据仓库分为ODS、DW两部分。通常的做法是从业务系统到ODS做
清洗，将脏数据和不完整数据过滤掉，在从ODS到DW的过程中转换，进行一些业务规
则的计算和聚合。
数据清洗
数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，
确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是有不完
整的数据、错误的数据、重复的数据三大类。
(1)不完整的数据：这一类数据主要是一些应该有的信息缺失，如供应商的名称、分
公司的名称、客户的区域信息缺失、业务系统中主表与明细表不能匹配等。对于这一类
数据过滤出来，按缺失的内容分别向客户提交，要求在规定的时间内补全。补全后才写
入数据仓库。
(2)错误的数据：这一类错误产生的原因是业务系统不够健全，在接收输入后没有进
行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面
有一个回车操作、日期格式不正确、日期越界等。这一类数据也要分类，对于类似于全
角字符、数据前后有不可见字符的问题，只能通过写SQL语句的方式找出来，然后要求
客户在业务系统修正之后抽取。日期格式不正确的或者是日期越界的这一类错误会导致
ETL运行失败，这一类错误需要去业务系统数据库用SQL的方式挑出来，交给业务主管
部门要求限期修正，修正之后再抽取。
(3)重复的数据：对于这一类数据——特别是维表中会出现这种情况——将重复数据
记录的所有字段导出来，让客户确认并整理。
数据清洗是一个反复的过程，不可能在几天内完成，只有不断的发现问题，解决问
题。对于是否过滤，是否修正一般要求客户确认，对于过滤掉的数据写入数据表，在
ETL开发的初期可以每天向业务单位发送过滤数据的邮件，促使他们尽快地修正错误,
同时也可以做为将来验证数据的依据。数据清洗需要注意的是不要将有用的数据过滤
掉，对于每个过滤规则认真进行验证，并要用户确认。
数据转换
数据转换的任务主要进行不一致的数据转换、数据粒度的转换，以及一些商务规则
的计算。
(1)不一致数据转换：这个过程是一个整合的过程，将不同业务系统的相同类型的数
据统一，比如同一个供应商在结算系统的编码是XX0001,而在CRM中编码是YY0001，
这样在抽取过来之后统一转换成一个编码。
(2)数据粒度的转换：业务系统一般存储非常明细的数据，而数据仓库中数据是用来
分析的，不需要非常明细的数据。一般情况下，会将业务系统数据按照数据仓库粒度进
行聚合。
(3)商务规则的计算：不同的企业有不同的业务规则、不同的数据指标，这些指标有
的时候不是简单的加加减减就能完成，这个时候需要在ETL中将这些数据指标计算好了
之后存储在数据仓库中，以供分析使用。
ETL日志、警告发送
ETL日志
ETL日志分为三类。一类是执行过程日志，这一部分日志是在ETL执行过程中每执
行一步的记录，记录每次运行每一步骤的起始时间，影响了多少行数据，流水账形式。
一类是错误日志，当某个模块出错的时候写错误日志，记录每次出错的时间、出错的模
块以及出错的信息等。第三类日志是总体日志，只记录ETL开始时间、结束时间是否成
功信息。如果使用ETL工具,ETL工具会自动产生一些日志，这一类日志也可以作为ETL
日志的一部分。记录日志的目的是随时可以知道ETL运行情况，如果出错了，可以知道
哪里出错。
警告发送
如果ETL出错了，不仅要形成ETL出错日志，而且要向系统管理员发送警告。发送
警告的方式多种，一般常用的就是给系统管理员发送邮件，并附上出错的信息，方便管
理员排查错误。
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层将不
会记录到所删除的历史数据。不可以实现数据的递增加载。
当作系统数据加载策略方案时，基于以上所列方法，及现有系统考虑：
1）、如果所集成OLTP系统为其他产商产品，则应尽量的降低因ETL而对现有系统
产生的影响，及系统风险性。而性能的影响则可以通过两方面解决，一部分由硬件的升
级进行解决，因为ETL除读表及写表操作外，所有转换均由ETL服务器在内存中完成，
故高配置服务器将大大提升ETL运行速度；一部分由加载时机进行控制，加载时机采取
在系统较为空闲时加载，同时并行多个加载等，可以降低对运行系统的影响。所以可以
使用全表比对递增加载数据的方式作为此类系统的ETL数据加载规则。
2）、如果原OLTP系统为自己开发产品，此次所作OLAP系统为在原系统上的系统，
则可以考虑使用时辍或日志表方式，区别仅为对原系统的影响大小。
3）、当数据实现递增加载时，OLAP系统中的聚合表，可由OLAP中的事实表数据
二次ETL产生，此时由于OLAP数据的完整性与准确性，可以使用全表删除插入方式。
流行的ETL工具
Informatica PowerCenter
IBM DataStage
Oracle OWB
Business Object DI.60年代，关系数据库之父E.F.Cdd提出了关系模型，促进了联机事务处理(OLTP)的
发展(数据以表格的形式而非文件方式存储)。1993年，E.F.Cdd提出了OLAP概念，认为
OLTP已不能满足终端用户对数据库查询分析的需要，SQL对大型数据库进行的简单查
询也不能满足终端用户分析的要求。用户的决策分析需要对关系数据库进行大量计算才
能得到结果，而查询的结果并不能满足决策者提出的需求。因此，E.F.Cdd提出了多维
数据库和多维分析的概念，即OLAP。
OLAP(联机分析处理，On-Line Analytical Processing) ：是使分析人员、管理人
员或执行人员能够从多种角度对从原始数据中转化出来的、能够真正为用户所理解的、
并真实反映企业维特性的信息进行快速、一致、交互地存取，从而获得对数据的更深入
了解的一类软件技术。
OLAP的目标：是满足决策支持或多维环境特定的查询和报表需求，它的技术核心
是“维”这个概念，因此OLAP也可以说是多维数据分析工具的集合。
OLTP与OLAP的不同点：
| OLTP数据 | OLAP数据 |
|---|---|
| 原始数据 | 导出数据 |
| 细节数据 | 综合性和提炼性数据 |
| 当前值数据 | 历史数据 |
| 可更新 | 不可更新，但周期性刷新 |
| 一次处理的数据量大小 | 一次处理的数据量大 |
| 面向应用，事务驱动 | 面向分析，分析驱动 |
| 面向操作人员，支持日常操作 | 面向决策人员，支持管理需要 |
OLAP相关基本概念
维：是人们观察数据的特定角度，是考虑问题时的一类属性，属性集合构成一个维(时
间维、地理维等)。
维的层次：人们观察数据的某个特定角度(即某个维)还可以存在细节程度不同的各
个描述方面(时间维：日期、月份、季度、年)。
维的成员：维的一个取值。是数据项在某维中位置的描述。(“某年某月某日”是在时
间维上位置的描述)
多维数组：维和变量的组合表示。一个多维数组可以表示为：(维1，维2，…，维n，
变量)。(时间，地区，产品，销售额)
数据单元(单元格)：多维数组的取值。(2000年1月，上海，笔记本电脑，$100000)
OLAP的特性
快速性：用户对OLAP的快速反应能力有很高的要求。系统应能在5秒内对用户的大
部分分析要求做出反应。如果终端用户在30秒内没有得到系统响应就会变得不耐烦，因
而可能失去分析主线索，影响分析质量。对于大量的数据分析要达到这个速度并不容，
因此就更需要一些技术上的支持，如专门的数据存储格式、大量的事先运算、特别的硬
件设计等。
而可能失去分析主线索，影响分析质量。对于大量的数据分析要达到这个速度并不容，
因此就更需要一些技术上的支持，如专门的数据存储格式、大量的事先运算、特别的硬
件设计等。
可分析性：OLAP系统应能处理与应用有关的任何逻辑分析和统计分析。尽管系统
需要事先编程，但并不意味着系统已定义好了所有的应用。用户无需编程就可以定义新
的专门计算，将其作为分析的一部分，并以用户理想的方式给出报告。用户可以在OLAP
平台上进行数据分析，也可以连接到其他外部分析工具上，如时间序列分析工具、成本
分配工具、意外报警、数据开采等。
多维性：多维性是OLAP的关键属性。系统必须提供对数据的多维视图和分析,包括
对层次维和多重层次维的完全支持。
信息性：不论数据量有多大，也不管数据存储在何处，OLAP系统应能及时获得信
息，并且管理大容量信息。这里有许多因素需要考虑，如数据的可复制性、可利用的磁
盘空间、OLAP产品的性能及与数据仓库的结合度等。
OLAP多维数据结构
超立方结构(Hyper cube) ：超立方结构指用三维或更多的维数来描述一个对象,每个
维彼此垂直。数据的测量值发生在维的交叉点上,数据空间的各个部分都有相同的维属
性。(超立方结构有一种变形，即收缩超立方结构。这种结构的数据密度更大,数据的维
数更少,并可加入额外的分析维)。
多立方结构(Multi cube)：即将超立方结构变为子立方结构。面向某一特定应用对维
进行分割, 它具有很强的灵活性,提高了数据(特别是稀疏数据)的分析效率。
一般来说，多立方结构灵活性较大，但超立方结构更易于理解。终端用户更容易接
近超立方结构，它可以提供高水平的报告和多维视图。但具有多维分析经验的MIS专家
更喜欢多立方结构，因为它具有良好的视图翻转性和灵活性。多立方结构是存储稀疏矩
阵的一个更有效方法，并能减少计算量。因此，复杂的系统及预先建立的通用应用倾向
于使用多立方结构，以使数据结构能更好地得到调整，满足常用的应用需求。
许多产品结合了上述两种结构，它们的数据物理结构是多立方结构，但却利用超立
方结构来进行计算，结合了超立方结构的简化性和多立方结构的旋转存储特性。
OLAP多维数据分析
切片和切块(Slice and Dice)：多维数据结构中, 在一部分维上选定值后，关心度量数
据在剩余维上的分布，如果剩余的维只有两个，则是切片；如果有三个，则是切块。如
在“城市、产品、时间”三维立方体中进行切块和切片,可得到各城市、各产品的销售
情况。
钻取(Drill) ：它是改变维的层次，变换分析的粒度。钻取包含向下钻取(Drill-down)
和向上钻取(Drill-up)/上卷(Roll-up)操作，roll up是在某一维上将低层次的细节数据概
括到高层次的汇总数据，或者减少维数；而drill down则相反，它从汇总数据深入到细
节数据进行观察或增加新维。
旋转(Rotate)/转轴(Pivot)：旋转是变换维的方向，即在表格中重新安排维的放置（例
如行列互换）。通过旋转可以得到不同视角的数据。
OLAP的多种实现方法
OLAP的实现方法，根据存储数据的方式不同可以分为ROLAP、MOLAP、HOLAP：
ROLAP表示基于关系数据库的OLAP实现（Relational OLAP）。以关系数据库为
核心,以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表：一类是事实表，用来存储数据和维关键字；另一类是维表，即对每个维至少
使用一个表来存放维的层次、成员类别等维的描述信息。维表和事实表通过主关键字和
外关键字联系在一起，形成了“星型模型”。对于层次复杂的维,为避免冗余数据占用
过大的存储空间，可以使用多个表来描述,这种星型模型的扩展称为“雪花模型”。
MOLAP表示基于多维数据组织的OLAP实现（Multidimensional OLAP）。以多维
数据组织方式为核心,也就是说,MOLAP使用多维数组存储数据。多维数据在存储中将
形成“立方块（Cube）”的结构,在MOLAP中对立方块的“旋转”、“切块”、“切
片”是产生多维数据报表的主要技术。
HOLAP表示基于混合数据组织的OLAP实现（Hybrid OLAP）。如低层是关系型
的，高层是多维矩阵型的。这种方式具有更好的灵活性。
还有其他的一些实现OLAP的方法，如提供一个专用的SQL Server，对某些存储模
式（如星型、雪片型）提供对SQL查询的特殊支持。
多维数据库
多维数据库（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 Essbase
Oracle Express
IBM DB2 OLAP Server
Microsoft analysis services
Brio
Cognos
Business Object
MicroStrategy
数据仓库架构
目前来说，数据仓库架构比较成熟并已经形成理论的主要有两个，一个是Corporate
Information Factory，简称CIF，中文一般翻译为企业信息工厂，代表人物是Bill Inmon。
另一个是Mutildimensional Architecture，简称MD，中文一般翻译为多维体系结构，
代表人物是Ralph Kimball。
企业信息工厂主要包括集成转换层（Integrated and Transformation Layer）、操作
数据存储（Operational Data Store）、数据仓库（Enterprise Data Warehouse）、数
据集市（Data Mart）、探索仓库（Exploration Warehouse）等部件。
多维体系结构分为后台（Back Room）和前台（Front Room）两部分。后台主要负
责数据准备工作，称为数据准备区（Staging Area），前台主要负责数据展示工作，称
为数据集市（Data Mart）。而数据仓库是一个虚拟的部件，它指的是全部数据集市的
集合。
两个数据仓库架构各有优缺点，一种比较流行的做法是合用两种架构，即建立CIF
的数据仓库和MD的数据集市。
HWBIS系统架构
华为BIS系统采用的就是合用CIF数据仓库和MD数据集市的架构。
技术架构
三层架构模型将传统操作业务切分成几个层次，每个层次提供不同的相关服务，如
DB服务、应用服务、Web服务等。三层架构为系统提供了复杂应用操作，同时提供对
现有应用集成及今后应用扩展强有力的支持，增强了安全机制，提高了性能，并提供对
LDAP目录服务的支持。 
三层架构包括数据库层，应用服务器层，用户终端层。其中数据库层，采用Unix平
台上的Oracle 9i系统作为数据库服务器。Oracle作为最先进的数据库产品，具有性能优
越，工作稳定可靠，适合数据仓库系统要求的海量数据存储的需要。应用服务器层运行包括ETL服务（抽取，转换，加载），元数据服务，Reporting服务，Portal服务，OLAP
服务等五种应用。用户终端层只需通过浏览器，访问华为业务智能系统各应用。
ETL服务器采用CA的ADT EME Server，它可以同时连接多达64个不同的数据源。
对华为来说，这些数据源包括Notes，SQL Server，Oracle，Text file等。这些数据通
过ADT Server进行加工转换后，进入到数据仓库中。
OLAP分析主要采用MS OLAP 与BO相结合的方式。BO作为前端可以进行钻取，切
片，旋转等多维分析操作，而MS OLAP则存放CUBE。这种方式可以将运算操作集中
于Cube服务器，而Client端无需将Cube下载到本地，节约了空间，减少了网络负载，
同时提高了数据展现的效率。通过BO的Universe方式，还可以进行灵活的查询，生成
固定格式的报表。
由于有不少的数据来源于纸面或某些数据需要调整，所以需要一个补录系统来输入
这些数据，并可以维护这些数据。补录系统采用JSP方式或Java方式进行开发，遵循J2EE
架构，可以采用的应用服务器包括Oracle FormServer，WebLogic，Websphere。
以上的前端应用均可实现Web方式的访问，只不过还需配置BO Web Server和Web
Server。
整个过程中产生的模型通过模型管理工具Erwin和ModelMart进行管理。
元数据由Repository进行管理。通过DataShopper，最终用户可以方便地浏览元数
据。通过Repository Client，管理人员可以方便地对元数据进行管理和维护。
数据架构
从5个层次来设计华为数据仓库环境的数据架构，数据储存、模式、各主题的数据概
念模型、逻辑模型和物理模型，各主题的数据概念模型、逻辑模型和物理模型在数据架
构设计中实现。
整个数据仓库环境分为4个数据区，即数据源区，数据仓库区，OLAP区和元数据区。
数据仓库从物理上分又为4个区：数据准备区（Staging Area），当前数据和历史数据
区（ODS），细节数据（BaseLine），数据集市（DataMart）。 
Staging区：对存储空间的要求是临时的，且是暂时存放每天从OLTP系统抽取的变更的
数据。
ODS区，存放两部分数据，一部分是当前变更的数据，一部分是存放从OLTP抽取的历
史数据。
BaseLine区，该区存放经过转换后的细节数据。
DataMart区，该区存放汇总数据。