零售业务

1.维度建模设计的四个步骤

1. 选择业务过程
   业务过程通常表示业务执行的活动。与之相关的维度描述与每个业务过程事件关联的描述性环境。业务过程通常由某个操作型系统支撑,例如,账单或购买系统。业务过程建立或获取关键性能度量。有时这些度量是业务过程的直接结果,度量,从其他时间获得。分析人员总是想通过过滤器和约束的不同组合,来审查和评估这些度量。业务过程通常由输入激活,产生输出度量。在许多组织中,包含一系列过程,它们既是某些过程的输出,也是某些过程的输入。用维度建模人员的话来说,一系列过程产生一系列事实表。
   我们也需要了解业务过程不是什么。企业业务部门或企业功能职责并不等于业务过程。将注意力放在业务过程,而不是放在功能化的部门,可以更方便地获得一致的企业信息。如果以部门为边界建立维度模型,则不可避免地会将不同标号的数据及数据值重复使用。确保一致性的最好方法是一次发布数据。

2. 声明粒度
   声明粒度意味着精确定义某个事实表的每一行表示什么。粒度传递的是与事实表度量有关的细节级别。它回答“如何描述事实表中每个行的内容? ”这一问题。粒度由获取业务过程事件的操作型系统的物理实现确定。

3. 确定维度
   维度要解决的问题是“业务人员如何描述来自业务过程度量事件的数据? ”应当使用健壮的维度集合来装饰事实表,这些维度表示承担每个度量环境中所有可能的单值描述符。如果粒度清楚,维度通常易于区分,因为它们表示的是与“谁、什么、何处、何时、为何、如何”关联的事件。常见维度的实例包括日期、产品、客户、雇员、设备等。在选择每个维度时,应该列出所有具体的、文本类型的属性以充实每个维度表。

4. 确定事实
   可以通过回答“过程的度量是什么? ”这一问题来确定事实。商业用户非常愿意分析这些性能度量。设计中的所有候选事实必须符合第2步的粒度定义。明显属于不同粒度的事实必须放在不同的事实表中。典型事实是可加性数值,例如,订货数量或以美元计的成本总额等。不能只考虑数据来源来建模数据,数据不能代替业务用户的输入

维度模型设计的关键输入

2.零售业务案例研究

第1个DW/BI项目应该将注意力放在最为关键的、最易实现的用户业务过程。最易实现涉及一系列的考虑,包括数据可用性与质量,以及组织的准备工作等
设计开发的维度模型应该表示由业务过程获取的最详细的原子信息
DW/BI系统几乎总是要求数据尽可能最细粒度来表示,不是因为需要查询单独的某行,而是因为查询需要以非常精确的方式对细节进行切分
详细的粒度说明确定了事实表的主要维度。然后可以将更多维度增加到事实表上,只要这些额外的维度自然地承担主维度合并的某个值。如果附加的维度会产生与粒度不符的其他事实行,则取消该维度或重新考虑粒度声明

可度量事实

1. 计算获得的事实:数据分析师无法从DWS层获取想要的数据,只能从DWD层获取数据,对于这种情况,数据仓库是一个迭代开发的过程,不断完成主题建模,提供数据给分析师,或者为DWD的数据生成一个视图,避免直接对物理层操作,提供给分析师(书中描述的内容,我加工了一下,可能是这个意思吧...)
2. 不可加事实:例如对比率事实要准确汇总
3. 事务事实表:准确估算这种事实表的大小,来合理设计数据仓库

3.维度表设计细节

日期维度

日期维表

日期维度表中的每列由行表示的特定日期定义。周天列包含天的名称,如周一。使用该列可建立用于比较周一与周日业务的报表。日期数字是日历月列从每月1号开始,根据不同的月份以28,29,30,31日结束。该列用于比较每个月的相同一天的情况。类似地,可以用每年的月号码(1....12)。所有这些整数支持跨月或年的简单日期计算。对于报表,需要增加长标识和缩写标识。例如,希望存在月名属性,包含如1月这样的值。此外,年-月(YYYY-MM)列作为报表的表头非常有效。也可能希望季度号码(Q1....Q4),以及2013-Q1这样的年-季度属性。可以包括财务周期相同,但日历周期不同的列。

日期维度样例

为什么设计这么宽的日期维表

我的理解他的意思是说,把这些字段提供给用户,用户不会SQL查询,我的问题是在实际的,面向内部的日期维度会这么大??直接SQL日期函数查询不就行了???,特殊意义的字段搞一个外键不就行了???

1. 文本属性的标识或者字段
   与大多数操作型标志与标识类似, 日期维度的假日标识是一种简单的带有两个可能值的标识。由于维度表属性用于报表和下拉式查询过滤列表中的值,所以该标识应该用有意义的值,例如,假日或非假日,而不是用神秘的Y/N, 1/0或真/假表示。标识采用越有意义的领域值,就越能够转换为有意义的、能够自我解析的报表。
   

   文本标识

2. 当前时间与相对时间属性(没看懂??企业日历,我知道了就是今天的日期同下面的对滞后属性的处理,新增一个字段)
   大多数日期维度属性不应该更新。2013年6月1日将始终上卷到6月、日历第2季度、2013年。然而,某些属性可以增加到基本日期维度中,这些属性可随时间改变,包括IsCurrentDay,IsCurrentMonth, IsPrior60Days等。IsCurrentDay显然每天都需要更新。该属性对建立总是指向当前天的报表有用。需要细致考虑的是日期IsCurrentDay所涉及的日期。大多数数据仓库按天加载数据,因此IsCurrentDay涉及昨天(或者更准确地说,是最近的加载日期)。可在日期维度中增加属性表示您的企业日历,例如IsFiscalMonthEnd.
   一些维度属性包括对滞后属性的更新。滞后日期列中值为0表示今天, -1表示昨天,+1表示明天等等。该属性易于成为可计算列而不是物理地存储。可用于为月、季度和年设置类似结构(难点)

3. 将当天时间(time-of-day)作为维度或事实
   尽管日期和时间可以合起来作为操作型日期/时间戳,当天时间通常从日期维度中分离出来,以避免在日期维度中执行行计算的复杂性。正如前文所提到的那样, 20年的日期维,度历史记录人约包含7300行。如果改变维度的粒度为每行表示每天的每分钟,则将会由每天的1440分钟产生将近1000万行。如果将时间跟踪到秒级别,则每年将产生3100万行。由于日期维度可能是最常用的约束模式中的维度,因此应该尽量使其保持较小的容量,易于管理。

产品维度

1. 扁平化多对一

   
   
   产品维度示例
   
   
   作者推荐的产品维度表示例
   
   

   与上面的没什么区别,作者强调维度表的层次要一致

2. 具有内嵌含义的属性值
   在维度表中按照自然键概念确定的操作型产品代码通常情况下具有内嵌的含义,不同部分表示产品的不同特征。在此情况下,由多个部分组成的属性应该完整保存在维度表中,也可以分解到不同的组成部件上,将被当成不同属性处理。例如,操作型代码的第5到第9个字符表示制造商,则制造商的名称也应该被包含在维度表属性中。

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

4. 下钻维度属性
   合理的产品维度表可包含大约50个左右的描述性属性。每个属性可作为约束和构建行头指针标识的来源。下钻只不过是从维度表中请求行头指针以提供更多信息。假定您有一个简单报表,用于按部门汇总销售额。如图,如果需要下钻,可从产品维度中拖任何属性,如品牌,放入报表,紧靠部门之后,可以自动下钻下一个层次的细节情况。可以根据脂肪含量属性下钻,即使该属性并不在需要上卷的商品层次上。

维度属性下钻示例

商店维度

1. 多层次维度表

   
   
   作者推荐的商店维度表
   
   

   图中的Floor Plan类型, Photo Processing类型以及Financial Services类型都是短文本描述符,描述特定的商店。不要用一位字符代码描述它们,而应该采用10~20个字符的描述符,这样当使用下拉方式过滤列表时或使用报表标记时能够具有可理解的含义。描述Selling Square Footage的列是数字并且理论上是跨商店可加的。可能您会试图将其放入事实表中,然而,很显然,它是商店的一种约束属性,用于约束或标记的可能比作为可加元素进行计算的可能大。出于该原因,将该属性放入商店维度表中。

2. 维度表中的日期

促销维度

促销维度可能是零售业模式中最有趣的维度。促销维度描述了销售商品的促销条件。促销条件包括临时降价、终端通道展示、报纸广告、礼券等。促销维度通常被认为是一种·因果维度,因为它描述了认为可能导致产品销售发生改变的因素。无论是总部还是商店的商业分析师都希望能够确定的是,某个促销是否有效。促销基于以下一个或多个因素来判断:

1. 促销产品的销售是否在促销期间获得大幅增加,也称为提升。提升多少的度量可以根据未进行促销活动时,该产品的基本销售情况来定。基本销售情况可以从先前历史销售情况估计出来,某些情况下,可通过复杂模型获得。
2. 促销产品在促销前或促销后的销售,与促销期间的销售比较,是否有降低,这种降低是否抵消了促销期间的销售增益。换句话说,您是否将常规价格产品的销售转换到降价销售产品上?
3. 促销产品在销售方面表现良好,但是其他与其相邻的产品的销售却显著降低了。(销售侵蚀)
4. 促销分类中的所有产品是否都获得了销售方面的净总增益,将考虑促销前、促销期间、促销后的时间段(市场增大)。
5. 促销是否有利可图。通常促销的利润考虑整个促销分类的利润与基本销售利润之,比,当然需要考虑促销期间和销售侵蚀,以及促销开销的影响。

促销维度

因果关系的维度属性是否应该再一张维度表中

解释

空外键 空属性 空事实的处理方法

通常,许多销售事务包括未被促销的产品。客户并不会只将促销产品放入其购物车中,您当然希望他们的购物车中装满付全价购买的商品。促销维度必须包含一行,具有唯一键0或-1,用以表示这不含促销条件,避免事实表中出现空的促销键。如果将一个空值放在事实表中的已被声明为外键的列,则违背了参照完整性的要求。另外,参照完整性警告,包含空值的键是给用户带来困惑的主要原因,因为他们无法实现与空值的连接操作。
有时我们可能在事实表中也会遇见空值。让事实表非空的方法可通过聚集函数处理,如SUM,MIN, MAX、COUNT和AVG等。如果用零值替换可能会使聚集计算产生倾斜。

实际销售模式

实际销售模式

扩展能力(难点)

1. 新维度属性。如果发现了维度的新文本描述符,可以把这些属性作为新列增加进去。所有现存的应用将可以不受这些属性的影响而继续其工作。如果新属性仅在某特定时间点可用,则老的维度行中将插入不可用或类似的描述。要警告的是,如果商业用户想要根据新确定的属性跟踪历史数据变化,则该场景将更加复杂。
2. 新维度。如前所述,可在事实表上增加新维度,在事实表上增加新的外键列并将新维度的主键填写到该外键列上。
3. 新可度量事实。如果新的可度量事实可用,可以将它们方便地增加到事实表。最简单的实例是当新事实在同一个度量事件中可用,并与已经存在的事实粒度相同时。此时,事实表被改变,增加了新列,值被填充至表中。如果新事实仅在某个时间点可用,则将空值填充到旧事实表行中。更复杂的情况是,当新的可度量事实以不同粒度出现时,如果新事实不能分配或分派到事实表的原始粒度,新事实应有属于自己的事实表,因为在同一个事实表中出现不同的粒度是错误的。

支架表(雪花型的一种)

支架表

尽管可以使用支架表,但出于对其潜在影响的考虑,维度模型尽量不要大量使用支架表。尽量不要使用支架表,纵然使用也是不得已,而不应该当成一条原则来使用。

蜈蚣表

蜈蚣表

大量的维度通常表明某些维度不是完全独立的,应该合并为一个维度。将同一层次的元素表示为事实表中不同维度是维度建模常见的错误。

维度与事实表键(这个是难点)

1. 维度表代理键:连接作用
2. 维度表中的自然键和持续的超自然键:维度表的一个属性,可作为可靠的标识符
3. 退化维度的代理键:用来关联维度表???
4. 日期维度的代理键
5. 事实表的代理键(作用??)

维度模型设计的4步过程
事实表粒度
事务类型事实表
可加、不可加以及抽取的事实
维度属性,包括指标、数字化描述符以及多层次
日历日期维度,加上当天时间(time-of-day)维度☆
因果维度,例如,促销维度☆
退化维度,例如,交易收据号码
维度模型中的空值维度
模型的可扩展性
无事实的事实表
代理键、自然键与持久键☆
基于雪花模式的维度属性
包含“太多维度的”蜈蚣事实表