数据仓库概念一览

数据仓库概念一览

浅析冰山查询―― iceberg query

在数据仓库领域有一个概念叫Iceberg query，中文一般翻译为"冰山查询"。冰山查询在一个属性或属性集上计算一个聚集函数，以找出大于某个指定阈值的聚集值。

以销售数据为例，你想产生这样的一个顾客-商品对的列表，这些顾客购买商品的数量达到3件或更多。这可以用下面的冰山查询表示：

Select P.cust_ID,P.item_ID,SUM(P.qty)

From Purchase P

Group by P.cust_ID,P.item_ID Having SUM(P.qty)=3

这种在给出大量输入数据元组的情况下，使用having字句中的阈值来进行过滤的查询方法就叫做冰山查询。输出结果可以看作"冰山顶"，而"冰山"是输

入数据。

这种冰山查询在数据仓库的数据概况分析阶段、数据质量检查阶段和数据

挖掘的购物篮分析中都经常使用。而且，冰山查询也是面试中出现频率非常高

的一道题，经常用来检测SQL能力。

操作集市―― oper mart

在数据仓库领域有一个概念叫Oper Mart，中文一般翻译为"操作集市"。

操作集市是为了企业战术性的分析提供支持，它的数据来源是操作数据存储(ODS)。它是ODS在分析功能上的扩展，使用户可以对操作型数据进行多维分析。

一个操作集市应该有如下特征：

1.操作集市是ODS的子集，数据来源于ODS，用于战略分析和报表。

2.操作集市中的数据和ODS中的数据同步更新。

3.操作集市以多维技术进行建模，即星型结构。

4.操作集市是一个临时的结构，当不在需要时会清掉所有数据，即不保存

历史数据。

操作集市和数据集市很相似，但是它不能用来取代用于战略性分析的数据

集市。由于操作集市的数据来源于ODS，所以它的数据比数据集市的数据要新。但是出于容量的考虑，操作集市中不保存历史数据，是一个临时的结构。

操作数据存储―― operational data store Kimball对操作数据存储的

定义是，面向主题的、集成的、经常更新的细节数据存储，用集成的数据来支

持事务系统。Kimball也认可Inmon对ODS的分类，但是他认为ODS应该以星

型结构来进行建模。

虽然Kimball对操作数据存储(ODS)的定义和Inmon基本上一样，但是他对操作数据存储的理解、作用与实现和Inmon有着较大的不同。

Kimball认为ODS在两种情况下是需要的：第一种情况是提供操作型报表，这些报表需要提供面向主题的、集成的数据，所以操作型的源系统无法提供；

这些报表和数据仓库中的报表也不相同，因为它们可以是一些定制好的，写死

在程序中的报表。第二种情况是需要提供实时的信息时，由于数据仓库的更新

频率一般都是24小时，而用户会有更急切的需求来了解数据源的信息，这时，建立操作数据存储是很有必要的。

对于ODS是保存最细粒度数据的地方的说法，Kimball认为对于最细粒度

数据，即原子数据层，应该保存在数据仓库中，而且应该置于维度框架和总线

架构中。

代理关键字-surrogate key

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

代理键"。代理关键字用于维度表和事实表的连接。

代理关键字的称呼有surrogate keys，meaningless keys，integer keys，nonnatural keys，artificial keys，synthetic keys等。与之相对的自然关

键字的称呼有natural keys，samat keys等。

在Kimball的维度建模领域里，是强烈推荐使用代理关键字的。在维度表

和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或

者智能关键字(Smart Keys)。数据仓库中的主键不应该是智能的，也就是说，

要避免通过主键的值就可以了解一些业务信息。当然，退化维度作为事实表的

复合主键之一时例外。

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

1.使用代理关键字能够使数据仓库环境对操作型环境的变化进行缓冲。也

就是说，当数据仓库需要对来在多个操作型系统的数据进行整合时，这些系统

中的数据有可能缺乏一致的关键字编码，即有可能出现重复，这时代理关键字

可以解决这个问题。

2.使用代理关键字可以带来性能上的优势。和自然关键字相比，代理关键

字很小，是整型的，可以减小事实表中记录的长度。这样，同样的IO就可以读取更多的事实表记录。另外，整型字段作为外键联接的效率也很高。

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

4.使用代理关键字可以用来处理缓慢变化维。维度表数据的历史变化信息

的保存是数据仓库设计的实施中非常重要的一部分。Kimball的缓慢变化维处

理策略的核心就是使用代理关键字。

当然，使用代理关键字也有它的缺点，代理关键字的使用使数据加载变得

非常复杂。有关使用代理关键字的维度表和事实表的加载方法在ETL Toolkit

中有详细的描述。使用代理关键字是一个从长远考虑的策略。

多值维度―― multivalue dimension

在维度建模的数据仓库中，有一种维度表叫multivalue dimension，中文

一般翻译为"多值维度"。

多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多

个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。

这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是

多对多的关系。正因为一个帐户可能会有多个对应的顾客，所以不能直接将顾

客ID放入帐户维度表中。而帐户维度表中的这种情况就叫做多值维度。

多值维度的第二种情况是事实表在某个维度表中有多条对应记录。举例来说，对于一个健康护理单分列项事实表来说，它的粒度是一个健康护理单，但

是该护理单却有可能有多次诊断，即该事实表与诊断维度的是一对多的关系。

这个与事实表粒度不匹配的诊断维度也称之为多值维度。

处理多值维度最好的办法是降低事实表的粒度。如第二种情况中，将健康

护理单分列项事实表的粒度降低到具体的诊断粒度上，这样就避免了多值维度

的出现。这种处理方式也是维度建模的一个原则，即事实表应该建立在最细粒

度上。这样的处理，需要对事实表的事实进行分摊。

但是有些时候，事实表的粒度是不能降低的，多值维度的出现是无法避免的。如第一种情况中，事实表是月帐户快照事实表，这张事实表与顾客维度没

有直接的关系，不能将数据粒度进行细分，即使细分的话帐户余额也很难分摊。这时，可以采用桥接表技术进行处理。在帐户维度表和顾客维度表之间建立个

帐户-顾客桥接表。这个桥接表可以解决掉帐户维度和顾客维度之间的多对多关系，也解决掉的帐户维度表的多值维度问题。

总之，多值维度是应该尽量避免的，它给数据处理带来了很大的麻烦。如

果多值维度不能避免的话，应该建立桥接表来进行处理。

非事实型事实表―― factless fact table

在维度建模的数据仓库中，有一种事实表叫Factless Fact Table，中文

一般翻译为"非事实型事实表"。在事实表中，通常会保存十个左右的维度外键

和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这