《数据仓库工具箱》- 第三章零售业务中的知识点汇总

太过爱你忘了你带给我的痛 2022-03-16 13:54 82阅读 0赞

*  ## 维度模型设计的4步过程 ##

1.选择业务过程

1.  业务过程通常用行为动词标示
2.  由某个操作型系统支撑，如订单和购买系统
3.  业务过程建立获取关键性能度量
4.  业务过程通常由输入激活，产生输出度量
5.  应该将注意力放在业务过程，而不是放在功能化的部门，可以更方便的获得一致的企业信息

2.声明粒度

粒度代表事实表中的每一行代表什么

3.确定维度

维度定义的是谁，什么时候，在哪的问题，作为聚合查询中的查询条件，分组条件，排序条件

4.确定事实

事实也可以理解为指标，是聚合查询中用来聚合的字段，如pv,uv,订单数等

确定业务过程，数据建模，不应该是数据驱动，而应该是业务驱动。

*  ## 事实表粒度 ##

设计开发的维度模型应该标示由业务过程获取的最详细的原子信息。原子粒度能提供最佳的分析灵活性，因为原子粒度可以被约束或者以任何可能的方式上卷。维度模型中的细节数据可以适应业务放比较随意的查询请求。

*  ## 事务类型事实表 ##

事物类型事实表通常一个事务一行，或者一个事务线一行。标示的是一个事务事件，比较稀疏，但是他的数量无法预测，可能会非常庞大。事务事实表返回的指标/度量通常是可加的。

在设计事务事实表初期，应该先估算一下最大表的情况，或者一个周期内的增量数量

*  ## 日期日历维度 ##

可以提前建立日期维度，预先存储10年或20年的日期信息，日期维度表中可包含日期，是否当天，所在周，月，年，假日信息等常用信息。不在sql的日期函数或者应用中计算出这些信息的原因在于：首先如果关系型数据库不能很好的处理日期类型，那么就糟糕了；其次大多数优化器都能高效的处理多维查询，没必要对关联查询谈虎色变；并且类似节日这种信息，在sql函数中是很难计算出来的。

> 1.在维度建模中，一些标示应该尽可能设置的有意义，而不是0/1,Y/N这种代码。标示采用越有意义的值，就越能够方便的转换为有意义的，能够自我解析的报表。与其在BI应用中将标示编码成难以理解的标示，不如将其编码成数据库中存储的可解释的值。这样他能够对所有用户保持一致。

> 2.在日期维度表中，虽然大多数属性不会被更新，但是像isCurrentDay,isCurrentMonth,isPrior60Days这样的属性可以加入到日期维度表中，并且每个对应的周期进行更新。该属性的建立对展示当天信息的报表有用

> 3.应该将time-of-day（当天时间）的信息单独做成一张维度表，以避免在日期维度中执行行计算的复杂性。否则，由于当天时间的加入，日期维度表的数量可能会急剧膨胀。

*  ## 维度属性，包括指标，数字化描述符和多层次 ##

1.扁平化多对一层次

在维度建模中，不需要将重复的值分解到另一个规范化的表中以节省空间。因为对比针对事实表的空间需求来说，维度表空间需求要简单的多。例如一个产品表有30000行记录，其中有50个产品分类，那么平局来说这个表的产品分类属性会有6000个重复值，按照3NF范式，应该建立一张产品分类表存储这50个分类。但是在维度表中，这6000个重复值相对于上亿的事实表来说根本不算什么，如果建立产品分类表，那么以为着更多的关联查询，节省了一点点的空间却浪费了相当大的查询性能。

将重复的低粒度值保持在主维度表中是一种基本的维度建模技术。规范化这些值将其放入不同的表将难以实现简单化和高性能的目标

2.具有内嵌含义的属性

应该将维度表中自然键的每一部分所表示的含义存储到维度表中。例如SKU（产品统一编码）中的第5-9个字符示的是制造商，则应该将制造商这个属性放入维度表

3.作为属性或事实的数字值

>  *  如果某个数字值主要用于计算，则应该放入事实表中 \* 如果类似标准价格主要用于价格变化分析，也行变化度量应该放入维度表中 \* 如果能预先定义稳定的数字值，用于约束、分组和标记，则他应该被当成产品维度属性对待 \* 如果该值，即可以用于事实计算，又可以用于维度约束，分组标记，则应该被分别保存在事实表和维度表中

*  维度模型中的空值

> 不要在事实表中使用空值键。正确的设计应该是在对应维度表中包括一行以表示该维度不可用于度量。

有时候我们会遇到维度表的属性值为空的情况，这个时候建议用描述性字符替换空值，例如用UnKown(未知)或者Not Applicable(不适用)等。

*  ## 退化维度 ##

操作型事务空值号码，如订单号，发票号，提货单号码通常产生空的维度并且表示为事务事实表中的退化维度。退化维度是没有对应维度表的维度键。

*  ## 因果维度 ##

促销维度通常被认为是一种因果维度，因为他描述了认为可能导致产品销售发生改变的因素

*  ## 维度模型的可扩展性 ##

>  *  新维度属性 \* \* 如果发现了维度的新文本描述符，可以把这些属性作为新列添加进去。所有现存的应用可以不受其影响正常工作。如果新维度属性只在某些行中可以，那么在其他行应该插入不可用或类似的描述符。 \* 新维度 \* \* 可在事实表上添加新维度，在事实表中添加新的外键列并将新维度的主键填写到该外键列上。（为了可以很方便的这样做，在前期这几事实表的时候应该尽可能以最低粒度设计事实表。过早的聚集和汇总会限制补充维度的能力，因为增加的增加的维度通常无法在更高粒度级别上应用） \* 新可度量事实 \* \* 如果新的可度量事实可用，可以方便的把他们添加到事实表，但是这样做的前提是新增加的度量与当前事实表的粒度想符，如果不相符，那么则不能直接插入到当前事实表，不同粒度的事实应该有自己粒度的事实表

*  ## 无事实的事实表 ##

无事实的事实表，通常没有度量结果，仅仅包括所有键之间的关系。不过为了便于计算，可以包括虚拟事实，如添加某一列，使得其常量值为1。

*  ## 代理键 ##

代理键简单的以自增的整数表示。代理建的作用仅仅就是连接事实表和维度表。数据仓库中事实表和维度表的连接应该尽可能的使用无意义的代理建。应该避免使用自然键作为维度表的主键。

> 使用代理建的优点有如下几点：

> 1.为数据仓库抵御操作性系统的变化。在许多组织中，历史的操作型代码，例如不活跃用户的用户编号，会在一定时间内被重新分配。但是对 DW/BI系统中，数据通常会被保存多年，代理键为数据仓库提供了一种机制，用于区分同一个操作型代码的不同实例

> 2.集成多个源系统。代理键能够确保从多个不同源系统中集成数据，通过后端整理，建立交叉应用映射可以将多个自然键连接为一个代理键

> 3.改进性能。代理键是尽可能一个小的整数，这使得事实表的索引非常小，可以大大提高关联查询性能

> 4.处理空值和未知条件。可以使用特殊的代理键来代表空值

> 5.支持维度属性变化跟踪。同一个自然键可能有多个不同的历史版本，这时候使用代理键就可以很好的进行区分

*  ## 自然键 ##

自然键一般被建模为维度表的属性，他具有明确的业务意义，由业务系统进行生成