EDW DWM CONCEPT

 

 

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

在维度建模的数据仓库中，有一种事实表叫Factless Fact Table，中文一般翻译为“非事实型事实表”。在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。

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

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

事实表――fact table

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

一般来说，以粒度作为化分依据，主要有三种事实表，分别是事务粒度事实表（Transaction Grain Fact Table），周期快照粒度事实表（Periodic Snapshot Grain Fact Table）和累积快照粒度事实表（Accumulating Snapshot Grain Fact Table）。

事务粒度事实表中的一条记录代表了业务系统中的一个事件。事务出现以后，就会在事实中出现一条记录。事务粒度事实表也称为原子粒度。典型的例子是销售单分列项事实表。

周期快照粒度事实表用来记录有规律的，可预见时间间隔的业务累计数据。通常的时间间隔可以是每天、每周或者每月。典型的例子是库存日快照事实表。

累积快照事实表一般用来涵盖一个事务的生命周期内的不确定的时间跨度。典型的例子是KDT#2中描述的具有多个日期字段的发货事实表。

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

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

 

原子事实表（Atom Fact Table）是保存最细粒度数据的事实表，也是数据仓库中保存原子信息的场所。

 

聚集事实表（Aggregated Fact Table）是原子事实表上的汇总数据，也称为汇总事实表。即新建立一个事实表，它的维度表是比原维度表要少，或者某些维度表是原维度表的子集，如用月份维度表代替日期维度表；事实数据是相应事实的汇总，即求和或求平均值等。在做数据迁移时，当相关的维度数据和事实数据发生变化时，聚集事实表需要做相应的刷新。物化视图是实现聚集事实表的一种有效方式，可以设定刷新方式，具体功能由DBMS来实现。

退化维度――degenerate dimension

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

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

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

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

微型维度――minidimension

维度建模的数据仓库中，有一种维度叫minidimension，中文一般翻译成“微型维度”。微型维度的提出主要是为了解决快变超大维度（rapidly changing monster dimension）。

以客户维度举例来说，如果维度表中有数百万行记录或者还要多，而且这些记录中的字段又经常变化，这样的维度表一般称之为快变超大维度。对于快变超大维度，设计人员一般不会使用TYPE 2的缓慢变化维处理方法，因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。

这时，有一项技术可以解决这个问题。解决的方法是，将分析频率比较高或者变化频率比较大的字段提取出来，建立一个单独的维度表。这个单独的维度表就是微型维度表。

微型维度表有自己的关键字，这个关键字和原客户维度表的关键字一起进入事实表。有时为了分析的方便，可以把微型维度的关键字的最新值作为外关键字进入客户维度表。这时一定要注意，这个外关键字必须做TYPE 1型处理。

在微型维度表中如果有像收入这样分布范围较广的属性时，应该将它分段处理。比如，存储￥31257.98这样过于分散的数值就不如存储￥30000－￥34999这样的范围。这样可以极大的减少微型维度中的记录数目，也给分析带来方便。

杂项维度――junk dimension

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

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

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

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