-
数据仓库概念一览
浅析冰山查询――
iceberg query
在数据仓库领域有一个概念叫
Iceberg query
，中文一般翻译为
冰山查询
。冰山查询在一个属性或属性集上计算一个聚集函数，以找出大于某个指定阈<
/p>
值的聚集值。
以销售数据为例，你想产
生这样的一个顾客
-
商品对的列表，这些顾客购买
商品的数量达到
3
件或更多。这可以用下面的冰山查
询表示：
Select _ID,_ID,SUM()
From Purchase P
Group by
_ID,_ID Having SUM()=3
这种在给出大量输入数据元组的情况
下，使用
having
字句中的阈值来进行
过滤的查询方法就叫做冰山查询。输出结果可以看作
冰山顶
，而
冰山
是输
入数据。
<
/p>
这种冰山查询在数据仓库的数据概况分析阶段、数据质量检查阶段和数据
< br>挖掘的购物篮分析中都经常使用。而且，冰山查询也是面试中出现频率非常高
的一
道题，经常用来检测
SQL
能力。
操作集市――
oper mart
在数据仓库领域有一个概念叫
Oper Mart
，中文一般翻译为
操作集市
。
操作集市是为了企业战术性的分析提供支持，它的数据来源是
操作数据存储
(ODS)
。它是
ODS
在分析功能上的扩展，使用户可以对操作型数据进行多维分析。
一个操作集市应该有如下特征：
1.
操作集市是
ODS
的子集，数据来源于
ODS
，用于战略分析和报表。
2.
操作集市中的数据和
ODS
中的数据同步更新。
3.
操作集市以多维技术进行建模，即星型结构。
4.
操作集市是一个临时的结构，当不在需要时会清掉所有数据，即不保存
历
史数据。
操作集市和数据集市很相似，但是它不能用来取代用
于战略性分析的数据
集市。由于操作集市的数据来源于
ODS<
/p>
，所以它的数据比数据集市的数据要新。
但是出于容量的考虑，操
作集市中不保存历史数据，是一个临时的结构。
操作数据存储――
operational data
store Kimball
对操作数据存储的
定义是，面向主
题的、集成的、经常更新的细节数据存储，用集成的数据来支
持事务系统。
Kimball
也认可
Inmon
< br>对
ODS
的分类，但是他认为
O
DS
应该以星
型结构来进行建模。
<
/p>
虽然
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
的维度建模领域里，是强烈推荐使用代理关键字的。在维度表
和事实表的每一个联接中都应该使用代理关键字，而不应该使用自然关键字或
< br>者智能关键字
(Smart Keys)
。数据仓库中的
主键不应该是智能的，也就是说，
要避免通过主键的值就可以了解一些业务信息。当然，
退化维度作为事实表的
复合主键之一时例外。
使用代理关键字，有很多优点。
1.
使用代理关键字能够使数据仓库环境对操作型环境的变化进行缓冲。也
< br>就是说，当数据仓库需要对来在多个操作型系统的数据进行整合时，这些系统
中的
数据有可能缺乏一致的关键字编码，即有可能出现重复，这时代理关键字
可以解决这个问
题。
2.
使用代理关键字可以带来性
能上的优势。和自然关键字相比，代理关键
字很小，是整型的，可以减小事实表中记录的
长度。这样，同样的
IO
就可以读
取更
多的事实表记录。另外，整型字段作为外键联接的效率也很高。
3.
使用代理关键字可以建立一些不存在的维度记录，例如
<
/p>
不在促销之列
，
日期待定
，
<
/p>
日期不可用
等维度记录。
4.
使用代理关键字可以用来处理缓慢变化维。维度
表数据的历史变化信息
的保存是数据仓库设计的实施中非常重要的一部分。
Kimball
的缓慢变化维处
理策略的核心就是使
用代理关键字。
当然，使用代理关键字也有它的缺点，代理关
键字的使用使数据加载变得
非常复杂。有关使用代理关键字的维度表和事实表的加载方法
在
ETL Toolkit
中有详细的描述。使用代理关键字是
一个从长远考虑的策略。
多值维度――
multivalue dimension
在维度建模的数据仓库中，有一种维度表叫
multivalu
e dimension
，中文
一般翻译为
多值维度
。
多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多
个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。
这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是
多对多的
关系。正因为一个帐户可能会有多个对应的顾客，所以不能直接将顾
客
< br>ID
放入帐户维度表中。而帐户维度表中的这种情况就叫做多值维度。
多值维度的第二种情况是事实表在某个维度表中有多条对应记录。举例来
说，对于一个健康护理单分列项事实表来说，它的粒度是一个健康护理单，但
是该护理单却有可能有多次诊断，即该事实表与诊断维度的是一对多的关系。
这个与事实表粒度不匹配的诊断维度也称之为多值维度。
处
理多值维度最好的办法是降低事实表的粒度。如第二种情况中，将健康
护理单分列项事实
表的粒度降低到具体的诊断粒度上，这样就避免了多值维度
的出现。这种处理方式也是维
度建模的一个原则，即事实表应该建立在最细粒
度上。这样的处理，需要对事实表的事实
进行分摊。
但是有些时候，事实表的粒度是不能降低的，多值
维度的出现是无法避免
的。如第一种情况中，事实表是月帐户快照事实表，这张事实表与
顾客维度没
有直接的关系，不能将数据粒度进行细分，即使细分的话帐户余额也很难分摊
。
这时，可以采用桥接表技术进行处理。在帐户维度表和顾客维度表之间建立个
帐户
-
顾客桥接表。这个桥接表可以解决掉帐户
维度和顾客维度之间的多对多关
系，也解决掉的帐户维度表的多值维度问题。
总之，多值维度是应该尽量避免的，它给数据处理带来了很大的麻烦。如
果多值维度不能避免的话，应该建立桥接表来进行处理。
非事实型事实表――
factless fact
table
在维度建模的数据仓库中，有一种事实表叫
Factless
Fact Table
，中文
一般翻译为
非事实型事实表
。在事实表中，通常
会保存十个左右的维度外键
和多个度量事实，度量事实是事实表的关键所在。在非事实型
事实表中没有这
些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件
或者
说明某些活动的范围。下面举例来进行说明。
第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，
学
校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、
学生维度、注
册专业维度和取得学分维度，而事实表是由这些维度的主键组成，
事实只有注册数，并且
恒为
1
。这样的事实表可以回答大量关于大学开课注册
方面的问题，主要是回答各种情况下的注册数。
第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范
围事实表。通
常销售事实表可以回答如促销商品的销售情况，但是对于那些没
有销售出去的促销商品没
法回答。这时，通过建立促销范围事实表，将商场需
要促销的商品单独建立事实表保存。
然后，通过这个促销范围事实表和销售事
实表即可得出哪些促销商品没有销售出去。这样
的促销范围事实表只是用来说
明促销活动的范围，其中没有任何事实度量。
合并事实表
-consolidated/merged
fact table
在数据仓库领域有一个概念叫
merged fact
table
，或者
consolidated
fact table
，中文一般都翻译为
合并事实表
。合并事实表是将不同
事实表的
事实合并到同一张事实表的建模方法，合并的事实要保证在相同的粒度。
这种建模方法通常被用来横跨多个业务主题域来建立数据集市，
Kimball
将这样的数据集市称为第二级的数据集市。使用合并
事实表技术，可以避免性
能较差的交叉探察操作。
但是，这种合并事实表和使用交叉探察操作还有着细微的不同，在一些基
础
表中没有记录的时候，合并事实表中可能会存储一条记录，字段值保存为零。
合并事实表可以给数据仓库带来很大的性能提升，提供的跨主题的事实数
据也给用户带来了很大的方便。但是，合并事实表给
ETL
工作
带来了较大的麻
烦。对于合并事实表中涉及到的维度，需要在数据准备区保证它们是一致
性维
度。
缓慢变化维――
slowly changing
dimension
维度建模的数据仓库中，有一个概念叫
Slowly
Changing Dimensions
，中
文一般翻译成<
/p>
缓慢变化维
，经
常被简写为
SCD
。缓慢变化维的提出是因为在
现实世界中，维度的属性并不是静态的，它会随着时间的流失发生缓慢的变化。
这种随时间发生变化的维度我们一般称之为缓慢变化维，并且把处理维度表的
历史变化信
息的问题称为处理缓慢变化维的问题，有时也简称为处理
SCD
的问
题。
处理缓慢变化维的方法通常分为三种方式。
< br>第一种方式是直接覆盖原值。这样处理，最容易实现，但是没有保留历史
数据，无
法分析历史变化信息。第一种方式通常简称为
。
第二种方式是添加维度行。这样处理，需要代理键的支持。实现方式是当
有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通
过自然键可以和原维度记录保持关联。第二种方式通常简称为
< br>。
第三种方式是添加属性列。这种处理的实现方式是对
于需要分析历史信息
的属性添加一列，来记录该属性变化前的值，而本属性字段使用
TYPE 1
来直接
覆盖。这种方式的优点
是可以同时分析当前及前一次变化的属性值，缺点是只
保留了最后一次变化信息。第三种
方式通常简称为
。
< br>在实际建模中，我们可以联合使用三种方式，也可以对一个维度表中的不
同属性使
用不同的方式，这些，都需要根据实际情况来决定，但目的都是一样
的，就是能够支持方
便的分析历史变化情况。
即席查询――
ad hoc queries
在数据仓库领域有一个概念叫
Ad hoc queries<
/p>
，中文一般翻译为
即席查
询
。即席查询是指那些用户在使用系统时，根据自己当
时的需求定义的查询。
即席查询生成的方式很多，最常见的就
是使用即席查询工具。一般的数据
展现工具都会提供即席查询的功能。通常的方式是，将
数据仓库中的维度表和
事实表映射到语义层，用户可以通过语义层选择表，建立表间的关
联，最终生
成
SQL
语句。
即席查询与通常查询从
SQL
< br>语句上来说，并没有本质的差别。它们之间的
差别在于，通常的查询在系统设计和
实施时是已知的，所有我们可以在系统实
施时通过建立索引、分区等技术来优化这些查询
，使这些查询的效率很高。而
即席查询是用户在使用时临时生产的，系统无法预先优化这
些查询，所以即席
查询也是评估数据仓库的一个重要指标。
<
/p>
即席查询的位置通常是在关系型的数据仓库中，即在
EDW
或者
ROLAP
中。
多维数据库有自己的存储方式，对即席查询和通常查询没有区别。
在一个数据仓库系统中，即席查询使用的越多，对数据仓库的要求就越高，
对数据模
型的对称性的要求也越高。对称性的数据模型对所有的查询都是相同
的，这也是维度建模
的一个优点。
交叉探察――
drill across
在维度建模的数据仓库中，有一种操作叫
Drill Acro
ss
，中文一般翻译为
交叉探查
。鉴于经验的局限，在这里我只能进行一下浅显的分析。
在基于总线架构
(Bus Architectu
re)
的维度建模中，大部分的维度表是由
事实表共有的。比如
营销事务事实表
和
库存快照事实表
< br>就会有相同的维度
表，
日期维度
、
产品维度<
/p>
和
商场维度
。这时，如果有个需求是想按共有
维度来对
比查看销售和库存的事实，这时就需要发出两个
SQL
，分别查
出按维
度统计出的销售数据和库存数据。然后再基于共有的维度进行外连接，将数据
合并。这种发出多路
SQL
再进行合并的操
作就是交叉探查。
当这种交叉探查的需求很常用时，有一种建
模方法可以避免交叉探查，就
是合并事实表
(Consolid
ated Fact Table)
。合并事实表是指将位于不同事实表
中处于相同粒度的事实进行组合的一种建模方法。即新建立一个事实表，它的
维
度是两个或多个事实表的相同维度的集合，事实是几个事实表中感兴趣的事
实。这个事实
表的数据和其他事实表的数据一样来自
Staging
Area
。
合并事实表在性能和易用
性上都比交叉探查要好，但是被组合的事实表必
须处于相同的粒度和维度层次上。
角色模仿维度
-role-playing
dimensions
在数据仓库领域有一个概念叫
Role-playing di
mensions
，中文一般翻译
为
<
/p>
角色模仿维度
。角色模仿维度是为了处理
一个维度在一个事实表中同时出
现多次而使用的一种技术处理手段。
在建立了角色模仿维度以后，在底层只有一个物理表存在，但是针对这个
物理表会建立多个角色提供给数据访问工具，而且对数据访问工具来说这多个
角色是不同的。例如对与累计快照事实表中会出现多个日期字段联接到日期维
度。这
时就可以针对日期维度建立多个角色模仿维度。
角色模仿维度
的建立方法通常是使用视图来完成。例如订单日期维度表如
下所示：
CREATE VIEW
order_date(or
der_date_key,order_day_of_week,order_month,
…
)
AS SELECT data_key,da
y_of_week,month,
…
FROM DATA
使用同样的方式还可以建立多个不同日期的角色模仿维度。
<
/p>
需要补充的一点是，目前市场上的大部分展现工具，都提供了对一个表选
< br>择多次的功能。也就是说，角色模仿维度的功能展现工具自己就可以实现。这
样，
就不需要我们在数据库中建立角色模仿维度的视图了，而直接使用展现工
具完成即可。<
/p>
聚集事实表
-aggregated
fact table
累计快照事实表
-accumulating
snapshot fact table
桥接表
-bridge table
切片事实表
-sliced fact table
在数据仓库领域有一个概念叫
sliced fact tab
le
，中文一般翻译为
切片
事实表
。切片事实表中的字段结构和相应的基础表
完全相同，差别在于存储的
记录的范围。切片事实表中保存记录的是相应基础表中记录的
子集，记录数通
常与某个维度记录数相同。
< br>这种建模方法一般用来满足特殊需要，如需要分析某些特殊问题时，可以
将与之相
关的数据切片出来。相反，这种方法也常用于合并存储在不同地区的
数据，即各个地区都
保存自己地区的数据，总部和所有地区的表结构都相同，
然后总部将所有地区的数据合并
在一起。
切片事实表的结构与相对应的基础表相同，数据来源
于相对应的基础表。
切片事实表由于缩小了表中数据的记录数，所以查询的效率得到了很
大的提高。
事实表
(
一
)(
二
)
< br>――
fact table
在维度建模的数据仓库中
，事实表是指其中保存了大量业务度量数据的表。
事实表中的度量值一般称为事实。在事
实表中最有用的事实就是数字类型的事
实和可加类型的事实。事实表的粒度决定了数据仓
库中数据的详细程度。
一般来说，以粒度作为化分依据，主要
有三种事实表，分别是事务粒度事
实表
(Transactio
n Grain Fact
Table)
，周期快照粒度事实表
(Periodic
Snapshot Grain Fact Table)
和累
积快照粒度事实表
(Accumulating Snapshot
Grain Fact
Table)
。
事务粒度事实表中的
一条记录代表了业务系统中的一个事件。事务出现以
后，就会在事实中出现一条记录。事
务粒度事实表也称为原子粒度。典型的例
子是销售单分列项事实表。
周期快照粒度事实表用来记录有规律的，可预见时间间隔的业务累计数据。
通常的时间间隔可以是每天、每周或者每月。典型的例子是库存日快照事实表。
累积快照事实表一般用来涵盖一个事务的生命周期内的不确定的时间跨度。<
/p>
典型的例子是
KDT#2
中描述的具有多
个日期字段的发货事实表。
通常来说，事务和快照是建模中的
两个非常重要的特点，将两者相结合可
以使模型建立的更完整。
从用途的不同来说，事实表可以分为三类，分别是原子事实表，聚集事实
表和合并事实表。
-
-
-
-
-
-
-
-
-
上一篇：大象版六年级下册教学工作总结十二篇
下一篇：网神运维安全管理与审计系统操作手册