数据仓库（九）：维度设计与OWB实战：建立维表与事实表

最新推荐文章于 2023-04-27 10:43:20 发布

kingzone_2008

最新推荐文章于 2023-04-27 10:43:20 发布

阅读量1.3w

点赞数 2

分类专栏： Data Warehouse 文章标签： OWB 维度设计维表事实表 Oracle Warehouse Bui

本文链接：https://blog.csdn.net/kingzone_2008/article/details/8996858

版权

Data Warehouse 专栏收录该内容

9 篇文章 2 订阅

订阅专栏

1 维度表

在星型模式中，每个维度表都分配有一个代理键（surrogate key，SK）。该列是维度表的唯一标识符，是维度表的事实主键（这里事实主键是指事实意义上的主键，能唯一标识维度表中的一行），只在数据仓库中创建。代理键在星型模式的加载过程中分配和维护。代理键没有内在的含义，通常表现为一个整数。代理键有时指的是warehouse key，是维度表的主键。

维度表中也包含类似操作型系统中存在的用于唯一区分实体的键列。这些操作型系统中的键通常称为自然键（natural key，NK）。NK在维度表中未必唯一标识一条记录，即并非维度表的事实主键。

在数据仓库中，区分代理键和自然键的目的是跟踪在操作性系统中无须考虑的数据变化情况。例如，假定客户A在操作型系统中以customer_id 10711标识。如果客户的位置发生变化，操作型系统中只需对customer_id为10711的记录修改；而从分析角度考虑，可能需要根据地区统计，因此不能直接覆盖维度表中相关记录。因为星型模式的客户维度表中不以customer_id作为事实主键，仅作为NK，因此可以存储多个版本的客户A的信息，这些版本都具有相同的customer_id。不同版本的信息可以通过不同的代理键加以区分。这样就通过增加带有序号的自然键的方式对变化进行跟踪。代理键可以基于单一的列实现事实表和维度表之间的连接操作。

这与缓慢变化维有关。

维度表中包含的列应该尽可能全面。如对于操作型系统中为代码（如，使用0和1代表男和女）的列，维度表中应该包含该代码（0或1）和代码描述（男或女）。

2 事实表

事实表由紧凑的包含引用维度和事实的外键构成。
事实表应该包含所有与过程有关的事实，即使某些事实可以由其他事实计算得来。
类似比率等非可加事实应该分解为完全可加的组成部分，其计算应该在创建报表时执行。
事实表是稀疏的，只有当某些事实发生时才产生相应的记录行。
对事实表粒度的声明非常重要，要么以维度术语声明，要么以业务术语声明。
存储在事实表中的维度被称为退化维度。这种技术通常用于具有较高基数（cardinality）的事务标识符中。

记录在事实表中的行表示业务活动的发生情况，这意味着事实表中的行没有包含所有可能的维度组合。出现在事实表中的组合数量远远小于可能存在的组合数量。事实表的这项特性称为稀疏性。例如，某客户在某天未从某销售商处购买特定产品，则不会有此项记录。

多数情况下，模式设计者会避免在将数据加载到事实表之前聚合数据。尽可能保持最细粒度的数据，星型模式就能解决范围更加宽泛的分析型需求（即扩展性更好）。无论采用何种数据仓库结构（多维数据仓库或企业信息化工厂，CIF），这一指导原则都普遍适用。对多维数据仓库来说，事实表包含细粒度数据至关重要，因为多维数据仓库是细节数据的集中存储仓库。对于CIF，这一指导原则可以宽松一些，因为数据仓库中包含细粒度数据，因此数据集市的事实表可以聚集数据，而不用担心丢失信息。不过这些数据集市可能无法满足新需求。

存储到事实表中的维度列被称为退化维度，简称退化维。虽然被存储在事实表中，但该列仍被视为维度。与其他表中的维度列一样，其值仍然可以用于过滤查询、控制聚合层次、排序数据、定义主从关系等。应该改谨慎使用退化维度，因为事实表累计记录的速度很快，包含退化维度可能会造成存储空间的过度消耗，特别是当退化维度为文本元素时。多数情况下，适合选作退化维度的维度最好放置到杂项维度中，事务标识除外。
事务标识通常作为退化维度存储。它也可以作为事实表中行的唯一标识，并用于定义事实表的粒度。

3 缓慢变化维

维度表中的数据来源于操作型系统。在多维数据仓库（Kimball）或独立型数据集市中，数据直接来源于操作型系统。在企业信息化工厂（Inmon）中，来自于操作型系统的数据首先移到企业数据仓库中，然后进入多维数据集市。进入到维度表中的信息，在操作型系统中可能发生变化。因此维度设计中需要确定维度表如何处理数据源的发生变化的情况，这种维度表称为缓慢变化的维度，简称缓慢变维。

由于维度表引入了代理键作为其主键，因此不需要与源系统采用相同的处理方式。操作型系统可以跟踪数据变化的历史情况，也可以简单地采用重写变化值的方式。对于任何一种情况，星型模式都可以采用两种响应方式：变化类型1、变化类型2。

变化类型1在响应数据源变化时，重写维度属性。这样维度表不能反映历史情况，已存在事实的历史环境被改变了。

变化类型2在源数据值发生改变时，创建一个新版本的维度行。变化类型2保存了变化的历史事实。描述变化前的事件的事实与过去的值关联，描述变化后的事件的事实将与新值关联。多数操作型系统的变化采用变化类型2处理。

4 OWB操作

使用OWB的“维”右键“新建”“使用时间向导”创建完成后，会生成对应的表、序列、映射、维。注意四者的部署顺序，若顺序错误，会报错或警告，一般按表、序列、映射、维的顺序。

owb中每种操作跟sql的对应关系如下：

Owb operator	Sql
复制器Deduplicator	Distinct
过滤器Filter	where
连接器Joiner	join
关键字查找Key lookup	join
移动表头区Pivot	一条记录拆分成多条
Unpivot	与pivot相反
映射序列Sequence	Currval,nextval
集合运算Set	Union,union all,intersect,minus
排序器Sorter	Ordre by
拆分器Spliter	Mutiple table where
聚集函数Aggregator	Group by,having
常数Constant