细化维度表属性.docx

细化维度表属性.docx

《细化维度表属性.docx》由会员分享，可在线阅读，更多相关《细化维度表属性.docx（10页珍藏版）》请在冰豆网上搜索。

细化维度表属性

《TheDataWarehouseToolkit,2rd》读书笔记

数据仓库受业务驱动的最终目标

数据仓库必须使组织机构的信息变得容易存取

数据仓库必须一致地展示组织机构的信息

数据仓库必须具有广泛的适应性和便于修改

数据仓库必须发挥安全堡垒作用以保护信息资产

数据仓库必须在推动有效决策方面承担最基本的角色

数据仓库被业务群体所接受才能认定是成功的

数据仓库体系的主要构件

操作型源系统，数据聚集，数据展示，数据存储工具

操作型源系统：

外部的操作型数据库

数据聚集：

数据存储和ETL（extract-transformation-load）

数据展示：

数据组织、存储，便于其他应用直接查询

数据存储工具：

存储、读取数据的工具

事实表和维度表术语

元数据：

描述数据的数据，也就是数据属性。

例如下图中，“出版者”、“出版日期”是元数据项目，“中信出版社”、“2011”是元数据内容。

事实表：

包含数字数据（事实），多个索引（维度表的主键）。

例如下图中，“ProductKey”、“StoreKey”是索引，“QuantitySold”、“DollarSalesAmount”是数字数据。

维度表：

包含主键（事实表的索引），详细信息。

例如下图中，“ProductKey”是主键，“Weight”、“ProductDescription”等是商品的详细信息。

粒度：

数据单位中保存数据的细化或综合程度的级别。

细化程度越高，粒度级就越小；相反，细化程度越低，粒度级就越大。

连接事实表和维度表

理解了事实和维度表之后，现在就考虑将两个组块一起融合到维度模型中去的问题。

如下图所示，有数字型度量值组成的事实表连接到一组填满描述属性的维度表上。

这个星型特征结构通常被叫做星型连接方案。

该术语可以追溯到最早的关系数据库时期。

关于其中用到的维度方案，应该注意的第一件事就是其简明性与对称性。

很显然，业务用户会因为数据容易理解和浏览而从简明性方面受益。

上图设计方案的魅力就在于它能够充分地被业务人员所认可。

在针对几百个相关实例所做的自由评测活动中，用户们一致认为维度模型正是他们所要的东西。

特别是，表格数量的减少和富有意义的业务描述符号的使用，更进一步减少了出现误解的可能性。

如果有一张已经存在的规范化ER图，将它转换为一组维度模型的第一步是，将ER图分成一些分散的业务处理过程，然后分别单独建模。

第二步是选出ER图中那些含有数字型与可加性非关键字事实的多对多关系，并将它们标记为事实表。

最后一步是，将剩下的所有表复合成具有直接连接到事实表的单连关键字的平面表，这些表成为维度表。

有关维度建模的讹传

神话1维度模型与数据中心都只是应用于概要性数据方面的

神话2维度模型与数据中心是针对部门而不是针对企业的解决方案

神话3维度模型与数据中心是不可升级的

神话4维度模型与数据中心仅当可预见的使用模式时才适合

神话5维度模型与数据中心是不能集成的，从而只能形成直通的解决方案

数据仓库构建需要避免的常见疏误

疏误10过多地将心思放在技术和数据上了，而不关注业务的要求和目标

疏误9未能实现或者再现像数据仓库业务主管所具备的看起来有影响、易访问而又合乎情理的管理功能梦想而耿耿于怀

疏误8扭住指定一个庞大的多年工程计划不放，而不是去追求一个更易处理的可能也是更急迫的可以进行迭代开发的方案

疏误7将精力全部投入到构造规范化数据结构中去了，而在建造一个基于维度模型的可行的展示环节时，却已经用光了给定的投入

疏误6把注意力放在后台的作业性能和容易开发上，而不是放在前台的查询性能与容易使用

疏误5把展示环节中假定为可查询的数据做得过于复杂。

喜欢一个显得更为复杂的展示的数据库设计人员必定要花费一年的时间向业务用户提供（使用）支持，所以应该去建立一个在突出简明性更为人们所欣赏的解决方案。

疏误4在孤立应用的基础上建立维度模型，而没有考虑到采用共享的一致的维度将这些模型捆绑在一起的数据体系结构

疏误3仅仅将总结性数据加入到展示环节的维度中

疏误2把业务、业务需求与分析内容以及基本数据与支持技术等都看成是静态的

疏误1忽视了数据仓库的成功直接系于用户的接受程度这样的认识。

设计维度模型的四步过程

1、选取要建模的业务处理过程

2、定义业务处理的粒度

3、选定用于每个事实表行的维度

4、确定用于形成每个事实表行的数字型事实

以零售为例：

第一步：

选取业务处理

POS零售业务，什么促销条件下的什么日子里，在什么商店正在销售什么样的产品。

第二步：

定义粒度

通过访问POS事务信息，粒度最好是原子性的，以便能够得出一个关于商场销售非常详细的概况。

例如，想弄清星期一相对于星期日在销售上的不同情况，是否值得为谷物一类的物品准备那么多不同大小的商标，想了解有多少购物者对优惠50%的洗发精促销活动特别感兴趣，想确定如果对一个竞争很激烈的饮用苏打产品进行了大力的促销宣传以后进行降价销售会造成什么样的影响。

第三步：

选定维度

根据实例研究，可以确定的描述性维度有：

日期、产品、商店与促销

第四步：

确定事实

根据实例研究，可以确定的事实有：

销售量、销售额、成本额、毛利润金额

细化维度表属性

日期维度表

日期维度表的每列由行所代表的特定日期进行定义。

“星期”一列含有每天像“星期一”这样的名称内容，该列可用于创建比较“星期一”与“星期日”的业务的报表。

日历表中“月”所在列的日编号从每个月的1开始取值，然后根据月份的情况取到28、29、30或者31，这一列对于每月的同一天进行比较的情况很有好处。

按照类似的方式，可给出一年中每月的编号（1，……，12）。

纪元表示法采用一种称为凯撒日编号（即从某纪元开始连续对日期进行计数）来有效地给出日编号。

当然也可以在表中给出“星期”与“月份”的绝对编号列。

所有这些整数都支持跨年度跨月份的简单数据运算。

在生成报表时，常常要给出像“一月”这样的月份名称。

此外，为报表给定一个“年月”（YYYY-MM）列标题也是很有用途的。

同样，报表中很可能需要季度编号（Q1，……，Q4）或者诸如2001-Q4这样的年季度编号列。

如果财政年度与日历表在周期上不一致，则可以为财政年度给出类似的列。

在“节假日”指示列中给出“节假日”或者“非节假日”这样的内容。

要记住，维度表属性是做报表标记之用的，因此，简单地在“节假日”指示列中给出“Y”或者“N”是没有多大作用。

关于这个问题，考虑以下要对某产品的节假日与非节假日的销售情况进行比较的报表应用就可以弄清楚。

显然，列中给出“节假日”或者“非节假日”这样富有意义的值比一个“Y”或者“N”之类的编码，要有用得多。

还要注意，不应该在报表生成器中执行将编码标记翻译成易理解的标记这种操作，而应该将翻译内容存放在数据库中，以便使各种用户不受其报表生成工具的限制而得到一致的翻译内容。

如果用户要存取可以针对一天的情况进行分析（例如，在下班高峰的傍晚区间或者商场的第三班时间段内）的事务时间，就应该通过与事实表相连接的一个单独日历维度表来处理它。

日期与时间几乎是完全不相关的。

如果将这两个维度组合在一起，日期维度表就会增大许多。

于是，加入在同一个表（或者支架）中按分钟对时间进行处理的话，那么一个只有3650行就可以对10年的数据进行处理的简洁维度，一下子将扩展到5256000行。

比较起来，显然更应该创建一个3650行的日期维度表和一个分开的按分钟为每天记录1440行的维度表。

产品维度表

产品维度描述杂货店的每个SKU。

虽然典型的连锁店可能存储60000个SKUs，但在考虑跨连锁店与涵盖不再销售的历史产品的不同商品规划方案时，产品维度可能至少需要150000行乃至多达百万行。

产品维度几乎总是起源于操作型产品主文件。

大多数零售商在总部对其产品主文件进行管理，并经常不间断地将文件的一部分下载到各商店的POS系统中。

总部负责为每个由货物包装商创建的新UPC定义合适的产品主记录（以及具有唯一性的SKU），同时还负责定义将SKUs分配给诸如面包类食品、肉食品与农产品这些项目的规则。

在产品主文件发生改变的任何时候，都要从主文件抽取数据并存入产品维度表中。

产品主文件的一个重要作用，就是维护每个SKU的许多描述属性。

商品体系就是一组重要的属性。

通常，各类SKUs堆积形成商标，商标堆积形成分类，而分类则堆积形成部门，其中的每个关系都是多对一的。

这个商品体系与其他属性的详细情况如下图所示。

对于每个SKU而言，所有层次的商品体系都是经过良好定义的，并且像SKU描述之类的一些属性还具有唯一性。

在这种情况下，SKU描述项至少有150000个不同的取值。

在另一个极端，可能出现部门属性只有50个不同取值的情况。

于是平均下来，部门属性的每个唯一值会有3000个重复项。

不过没什么关系！

没有必要考虑将这些重复值分成另一个规范化表而节省一点空间。

须知，维度表的空间需求同事实表的空间考量相比显得多么不起眼。

产品维度表的许多属性并不是商品体系的组成部分。

例如，包装类型属性就极可能有瓶装、袋装、盒装或者其他类型。

任何部门的任何产品都可能去这些值的一个。

将这类属性的约束和商品体系属性方面的约束进行组合，具有非常积极的意义。

座位例子，可以看一下袋装谷物分类中的所有SKUs。

换个角度来考虑这个问题，可以对维度属性进行顺次浏览看它们是否属于商品体系，或者可以使用属性进行向上或者向下探查而看他们是否属于商品体系。

另外，甚至可以在产品维度表中明确地包含一个以上的体系。

一个合理的产品维度表可以拥有50或者更多的描述属性。

每个属性都是约束和构造行标题的丰富来源。

从这个意义上讲，如此费心劳神除了得到能够提供更多信息的行标题外，别无所求。

还是看看已经按部门针对销售额和销售量进行了汇总的简单报表吧：

如果进行向下探查，实际上可以从产品维度将诸如商标这样的任何其他属性拖入紧接部门的下一级报表，并且能够自动探查到次一级的细节层次。

在商品体系内，一个典型的向下探查结果与如下情形非常类似：

或者可以按脂肪含量属性向下探查，即使它不在商品堆积体系之列也是如此。

前面煞费苦心地给出探查例子的目的就是为了得出座位设计原则来表述的观点。

商店维度表

商店维度描述杂货连锁店的每个商场。

与每个大型杂货店业务中基本上都能够得到的产品主文件不同，并不能保证存在可用的商场综合主文件。

每当有新的或者变化的产品出现时，就需要将产品主文件下载到各个商场。

不过，单个POS系统并不需要一个商场主文件。

IT人员必须经常性地对来自总部多个操作源的商场维度必要分量进行装配。

促销维度表

促销维度使方案中可能最令人感兴趣的维度。

促销维度描述产品销售的促销情形。

促销情形包括临时降价、廊端展销、报纸广告与优惠券等。

因为这个维度用来描述被认为会使产品销售发生变化的因素而通常被叫做因果维度。

总部与商场的经理都对一个促销活动是否有效感兴趣。

促销由下列一至多个因素进行评判：

●促销活动的销售是否在促销区间出现增长。

这叫做上扬

●除去促销区间（过渡时间）内销售方面的增长外，促销活动的销售是否就在促销进行之前或者随后表现出减少的情形。

●是否发生促销产品的销售出现增长，而临近货架上的其他产品销售却呈现出相应的降低情况

●在考虑了促销之前、区间与其后的时间段因素（市场生长）的情况下，促销类别中所有产品的销售是否都经历了一个实际的总体增长？

●促销是否盈利？

对销售产生潜在影响的因果情形，并不需要由POS系统进行直接的跟踪。

这种事务系统要保持对降价与削价的跟踪。

通常优惠券的使用也由该事务进行捕获，因为顾客在购买商品时要么出示优惠券，要么不这么做。

广告与商场的展示可能需要与其他源头进行连结，各种可能的因果情形都是高度相关的。

临时降价通常与广告或廊端展销联系在一起，优惠券通常也与广告相关联。

因为这个原因，在促销维度