第2章 零 售 营 销

理解维度建模原理的最佳途径，是通过一系列切实的例子去进行实践。通过观察实际的实例，就能使设计方面的挑战与解决办法了然于心，这比仅仅通过抽象的表述进行学习要有效得多。本书中采用了大量取自诸多行业方面的实例，目的在于使读者不要为自己的业务细节所困扰而得到恰当的设计。

如果打算学习维度建模方面的知识，请不妨通读本书各章，即使不从事零售业务或者不在一个电信公司工作也要这样做。本书并不打算成为向某具体产业或者业务提供全面的解决办法的手册，各章以几乎在每种业务的维度建模中都会遇到的典型问题集的比喻形式进行内容的叙述。大学、保险公司、银行以及航空业等都几乎无一例外地需要本章所述的零售方面所使用的技能。此外，可以设想一下，如果一个人的业务总在随时间发生变化，那么会需要什么呢？当处理从自己公司获得的数据时，很容易受过去经历的复杂性影响而使事情变糟。通过走出去，然后带一两个经过充分考虑的设计原理回来，就能做到在进入纷繁的业务细节处理时，仍然能够记住设计原理的宗旨。

本章概念：

 设计维度模型的四步过程

 事务级事实表

 可加性与非可加性事实

 样本维度表属性

 诸如促销这样的因果维度

 诸如交易票据编号这样的合并维度

 维度模型的扩展

 “使用过多维度”陷阱的避免

 代理关键字

 市场容量分析 第2章 零售营销

27 ◣ 2.1 四步维度设计过程

整本书考虑一致地按照具有一定顺序的四个步骤的方式进行维度数据库的设计。这四个步骤的含义会随着各种不同设计的进行逐渐变得更加清晰起来，不过首先还是给出一些初始说明。

（1）选取要建模的业务处理过程。

业务处理过程是机构中进行的一般都由源数据收集系统提供支持的自然业务活动。听取用户的意见是选取业务处理过程的效率最高的方式。用户叫嚷着要在数据仓库中进行分析的性能度量值是从业务评测处理过程得来的。典型的业务处理过程包括原材料购买、订货、运输、开票、库存与账目管理等。要记住的重要一点是，这里谈到的业务处理过程并不是指业务部门或者职能。比如，可以建立一个用来处理订单数据的单一维度模型，而不应为要存取订单数据的销售与市场部门建立单独的模型。通过将注意力集中放在业务处理过程方面，而不是业务部门方面，就能在机构范围内更加经济地提交一致的数据。如果建立的维度模型是同部门捆绑在一起的，就无法避免出现具有不同标记与术语的数据拷贝的可能性。多重数据流向单独的维度模型，会使用户在应付不一致性的问题方面显得很脆弱。确保一致性的最佳办法是对数据进行一次性地发布。单一的发布过程还能减少ETL的开发量，以及后续数据管理与磁盘存储方面的负担。

（2）定义业务处理的粒度。

粒度定义意味着对各事实表行实际代表的内容给出明确的说明。粒度传递了同事实表度量值相联系的细节所达到的程度方面的信息。它给出了后面这个问题的答案：“如何描述事实表的单个行？”。

典型的粒度定义包括：

 顾客购物券上扫描设备一次拾取的分列项内容

 医生开出的单据项目内容

 个人登机通行证内容

 仓库中每种产品库存水平的日快照

 每个银行账号的月快照

数据仓库团队经常将这个看起来似乎不必要的步骤绕了过去。请不要这样做！对于设计团队的每个人来说，能够在事实表粒度上做到一致是很重要的。没有粒度的定义实际上是不可能达到下面第3步中提出的要求的。需要数据仓库工具箱

28 引起注意的是，一个不合适的粒度定义会使数据仓库的实现令人摸不着头脑。粒度定义是不容轻视的至关重要的步骤。说到这里，你应该能够发现在第3步或第4步中给出的粒度说明是错误的。好了，还是先回到第2步重新给出粒度的正确定义，而后再看第3步或第4步的内容。

（3）选定用于每个事实表行的维度。

维度所引出的问题是，“业务人员将如何描述从业务处理过程得到的数据？”应该用一组在每个度量上下文中取单一值而代表了所有可能情况的丰富描述，将事实表装扮起来。如果对粒度方面的内容很清楚，那么维度的确定一般是非常容易的。通过维度的选定，可以列出那些使每个维度表丰满起来的离散的文本属性。常见维度的例子包括日期、产品、顾客、事务类型和状况等。

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

事实的确定可以通过回答“要对什么内容进行评测”这个问题来进行。业务用户在这些业务处理性能度量值的分析方面具有浓厚的兴趣。设计中所有供选取的信息必须满足在第2步中定义的粒度要求。明显属于不同粒度的事实必须放在单独的事实表中。典型的事实是诸如订货量或者支出额这样的可加性数字数据。

整本书在开发各个实例研究时，都将按这样的四个步骤来展开，并以用户对业务的理解作为确定维度模型所需维度与事实的内容的依据。很显然，在按照如图2.1所示的四个步骤确定相关内容时，需要同时考虑业务用户需求和源数据本身。千万要克服只看看源数据文件就对数据进行建模的偏向。虽然说，一头扎进文件设计图与复写簿中去搜集数据比采访业务人员具有少得多的风险，但这不能代替用户的介入。遗憾的是，许多机构仍然企图使用这种受数据驱动的最省力的方法去建模，结果是很少有成功的。

◣ 2.2 零售实例的研究

这里先对在本实例研究中要使用的零售业务进行简要的描述，以使建立 业务需求

维度模型

1.业务处理

2.粒度

3.维度

4.事实

数据实际

图2.1 四步骤维度设计

过程的关键输入内容 第2章 零售营销

29 的维度与事实表更容易理解。之所以从这个行业入手，是因为它与大家都是密切相关的。设想一下在一家大型杂货连锁店总部工作的情形，其业务涵盖分布在5个州范围内的100多家杂货店。每个商店都有完整的配套部门，包括杂货、冷冻食品、奶制品、肉制品、农产品、面包店、花卉门市以及卫生/美术方面的辅助人员等，并有大致6万多个品种的产品放在货架上。每个品种的产品被称做库存储藏单位（SKUs，Stock Keeping Units）。大约55 000个SKUs来自外部的生产厂家，并在包装上印有条形码。这些条形码被叫做统一产品编码（UPCs，Universal Product Codes）。UPCs具有与单个SKUs相同的粒度。一个产品的不同包装类型具有一个单独的UPC，因而也有一个单独的SKU。

剩下的5 000个SKUs从诸如肉制品、农产品、面包店或者花卉门市等部门获取。虽然这些产品具有举国一致的可识别UPCs，杂货连锁店仍旧可以给它们分配SKU编号。既然杂货店是高度自动化的，那么完全可以为这些从其他部门取来的许多项目贴上扫描标记。尽管条形码不是UPCs，但它是确定无疑的SKU编号。

数据是从杂货店中多个令人感兴趣的地方收集得到的，其中一些最有用途的数据是在顾客购买产品时从收银机那里收集的。现代杂货店直接将条形码扫描到销售点（POS，Point-Of-Sale）系统中去，POS系统放在杂货店中对顾客外卖食品进行检测的出口处。厂家发货的后门是另外一个令人感兴趣的数据收集点。

在杂货店，管理方面所关注的是如何使产品的订购、储存与销售运作能最大限度地实现利润而开展后勤工作。利润最终要靠尽可能施加到每种产品上的管理职责、产品采购成本与额外开销的降低、以及在竞争激烈的价格战环境中吸引尽可能多的顾客等方面的一系列工作来获取。最重要的管理决策应该是关于定价与促销工作方面的。产品促销包括临时降价、在报纸与报纸夹页中加入广告内容、杂货店的陈设（包括廊端展销）和优惠券发行等工作。掀起产品销售量浪潮的最直接与最有效的方式是大幅度地降低产品的价格。

将纸巾降价一半，并为此打出配套广告和召开展销会，就可以使纸巾的销售量一下子提升10个点。遗憾的是，如此大规模的降价通常是经受不住的，因为这样的纸巾销售很可能是亏本的。这些问题说明，如何使各种形式的促销活动所产生的效能清晰可见是杂货店运营情况分析的重要部分。

在对业务实例研究进行描述之后，现在就可以开始维度建模的设计工作了。 数据仓库工具箱

30 2.2.1 第一步：选取业务处理

设计工作的第一步是，通过将对业务需求的理解与对可用数据的理解组合起来而确定建模的业务处理内容。

建立的第一个维度模型应该是一个最有影响的模型——它应该对最紧迫的业务问题做出回答，并且对数据的抽取来说是容易访问的。

在这个零售实例研究中，管理方面要做的事情就是更好地理解像POS系统记录的顾客购买情况。于是，建模所提供的业务处理就相应成为一个POS零售业务。这类数据可以用来分析出什么促销条件下的什么日子里，在什么商店正在销售什么样的产品等方面的内容。

2.2.2 第二步：定义粒度

一旦将业务处理确定下来，数据仓库团队下一个就面临关于粒度确定的严肃课题。应该在维度模型中给出何种详细程度的细节内容？这就引出了关于设计的一个重要提示。

应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子型数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。

通过在最低层面上装配数据，大多原子粒度在具有多个前端的应用场合显示出其价值所在。原子型数据是高度维结构化的。事实度量值越细微并具有原子性，就越能够确切地知道更多的事情，所有那些确切知道的事情都转换为维度。在这点上，原子型数据可以说是维度方法的一个极佳匹配。

原子型数据可为分析方面提供最大限度的灵活性，因为它可以接受任何可能形式的约束，并可以以任何可能的形式出现。维度模型的细节性数据是安如泰山的，并随时准备接受业务用户的特殊攻击。

当然，可以总是给业务处理定义较高层面的粒度，这种粒度表示最具有原子性的数据的聚集。不过，只要选取较高层面的粒度，就意味着将自己限制到更少或者细节性可能更小的维度上了。具有较少粒度性的模型容易直接遭到深入到细节内容的不可预见的用户请求的攻击。如果不让用户存取原子型数据，则他将不可避免地在分析方面撞上南墙。就如将在第16章所见到的那样，聚集概要性数据作为调整性能的一种手段起着非常重要的作用，但它 第2章 零售营销

31 绝对不能作为用户存取最低层面的细节内容的替代品。遗憾的是，有些实业界的权威人士在这方面一直显得含糊不清。他们宣称维度模型只适合于总结性数据，并批评那些认为维度建模方法可以满足预测业务需求的看法。这样的误解会随着细节性的原子型数据在维度模型中的出现而慢慢地消逝。

在该实例研究中，最佳粒度的数据是POS事务的单个分列项。为了确保得到最大限度的维度性和灵活性，所有讨论都将在这个粒度上展开。将这个粒度的定义针对第一版的原文做出修改是毫无价值的。以前，我们也将注意力集中在POS数据上，但不是考虑如何在维度模型中对事务分列项目细节进行表示，而是注重提供一天中某个商场所堆积的产品与促销方面的数据。在当时，这些每日产品总量反映了辛迪加零售数据库的技术状况。指望当时的硬件与软件能够有效地处理与各个POS事务分列项相关的数据海量的想法，是很不合时宜的。

通过访问POS事务信息，能够得出一个关于商场销售非常详细的概况。虽然用户或许对与特定POS事务相联系的单个项目的分析并不是很感兴趣，但数据库团队仍然无法预知出他们抽取数据的各种可能方式。例如，他们可能想弄清星期一相对于星期日在销售上的不同情况，或者想评估一下是否值得为诸如谷物一类的物品准备那么多不同大小的商标，或者想了解有多少购物者会对优惠50%的洗发精促销活动特别有兴趣，或者想确定如果对一个竞争很激烈的饮用苏打产品在经过了大力的促销宣传以后进行降价销售会造成什么样的影响等。虽然这些查询没有一个只对来自某单个特定事务的数据存在要求，但它们都是些需要精确切割的细节性数据的涉及面很广的问题。如果用户只能存取总结性数据，则不能回答其中的任何一个问题。

数据仓库几乎总是要求在每个维度可能得到的最低粒度上对数据进行表示的原因，并不是因为查询想看到每个低层面的行，而是因为查询希望以很精确的方式对细节知识进行抽取。

2.2.3 第三步：选定维度

一旦事实表的粒度被选定，则时期、产品与商店方面的维度就应该随之被确定下来。可以假定，日历日期是由POS系统提供的日期值。后面可以看到，随日期给出针对每一天的时间其情形又是怎么样的。在基本维度框架范围内，可能需要知道其他诸如针对某种产品的促销这样的维度是否可以分配