零售营销——数据仓库建模

第2章 零售营销第2章 零 售 营 销理解维度建模原理的最佳途径，是通过一系列切实的例子去进行实践。通过观察实际的实例，就能使设计方面的挑战与解决办法了然于心，这比仅仅通过抽象的表述进行学习要有效得多。本书中采用了大量取自诸多行业方面的实例，目的在于使读者不要为自己的业务细节所困扰而得到恰当的设计。如果打算学习维度建模方面的知识，请不妨通读本书各章，即使不从事零售业务或者不在一个电信公司工作也要这样做。本书并不打算成为向某具体产业或者业务提供全面的解决办法的手册，各章以几乎在每种业务的维度建模中都会遇到的典型问题集的比喻形式进行内容的叙述。大学、保险公司、银行以及航空业等都几乎无一例外地需要本章所述的零售方面所使用的技能。此外，可以设想一下，如果一个人的业务总在随时间发生变化，那么会需要什么呢？当处理从自己公司获得的数据时，很容易受过去经历的复杂性影响而使事情变糟。通过走出去，然后带一两个经过充分考虑的设计原理回来，就能做到在进入纷繁的业务细节处理时，仍然能够记住设计原理的宗旨。本章概念：n 设计维度模型的四步过程n 事务级事实表n 可加性与非可加性事实n 样本维度表属性n 诸如促销这样的因果维度n 诸如交易票据编号这样的合并维度n 维度模型的扩展n “使用过多维度”陷阱的避免n 代理关键字n 市场容量分析 2.1 四步维度设计过程整本书考虑一致地按照具有一定顺序的四个步骤的方式进行维度数据库的设计。这四个步骤的含义会随着各种不同设计的进行逐渐变得更加清晰起来，不过首先还是给出一些初始说明。（1）选取要建模的业务处理过程。业务处理过程是机构中进行的一般都由源数据收集系统提供支持的自然业务活动。听取用户的意见是选取业务处理过程的效率最高的方式。用户叫嚷着要在数据仓库中进行分析的性能度量值是从业务评测处理过程得来的。典型的业务处理过程包括原材料购买、订货、运输、开票、库存与账目管理等。要记住的重要一点是，这里谈到的业务处理过程并不是指业务部门或者职能。比如，可以建立一个用来处理订单数据的单一维度模型，而不应为要存取订单数据的销售与市场部门建立单独的模型。通过将注意力集中放在业务处理过程方面，而不是业务部门方面，就能在机构范围内更加经济地提交一致的数据。如果建立的维度模型是同部门捆绑在一起的，就无法避免出现具有不同标记与术语的数据拷贝的可能性。多重数据流向单独的维度模型，会使用户在应付不一致性的问题方面显得很脆弱。确保一致性的最佳办法是对数据进行一次性地发布。单一的发布过程还能减少ETL的开发量，以及后续数据管理与磁盘存储方面的负担。（2）定义业务处理的粒度。粒度定义意味着对各事实表行实际代表的内容给出明确的说明。粒度传递了同事实表度量值相联系的细节所达到的程度方面的信息。它给出了后面这个问题的答案：“如何描述事实表的单个行？”。典型的粒度定义包括：o 顾客购物券上扫描设备一次拾取的分列项内容o 医生开出的单据项目内容o 个人登机通行证内容o 仓库中每种产品库存水平的日快照o 每个银行账号的月快照数据仓库团队经常将这个看起来似乎不必要的步骤绕了过去。请不要这样做！对于设计团队的每个人来说，能够在事实表粒度上做到一致是很重要的。没有粒度的定义实际上是不可能达到下面第3步中提出的要求的。需要引起注意的是，一个不合适的粒度定义会使数据仓库的实现令人摸不着头脑。粒度定义是不容轻视的至关重要的步骤。说到这里，你应该能够发现在第3步或第4步中给出的粒度说明是错误的。好了，还是先回到第2步重新给出粒度的正确定义，而后再看第3步或第4步的内容。（3）选定用于每个事实表行的维度。维度所引出的问题是，“业务人员将如何描述从业务处理过程得到的数据？”应该用一组在每个度量上下文中取单一值而代表了所有可能情况的丰富描述，将事实表装扮起来。如果对粒度方面的内容很清楚，那么维度的确定一般是非常容易的。通过维度的选定，可以列出那些使每个维度表丰满起来的离散的文本属性。常见维度的例子包括日期、产品、顾客、事务类型和状况等。（4）确定用于形成每个事实表行的数字型事实。 业务需求 维度模型1.业务处理2.粒度3.维度4.事实数据实际图2.1 四步骤维度设计过程的关键输入内容事实的确定可以通过回答“要对什么内容进行评测”这个问题来进行。业务用户在这些业务处理性能度量值的分析方面具有浓厚的兴趣。设计中所有供选取的信息必须满足在第2步中定义的粒度要求。明显属于不同粒度的事实必须放在单独的事实表中。典型的事实是诸如订货量或者支出额这样的可加性数字数据。整本书在开发各个实例研究时，都将按这样的四个步骤来展开，并以用户对业务的理解作为确定维度模型所需维度与事实的内容的依据。很显然，在按照如图2.1所示的四个步骤确定相关内容时，需要同时考虑业务用户需求和源数据本身。千万要克服只看看源数据文件就对数据进行建模的偏向。虽然说，一头扎进文件设计图与复写簿中去搜集数据比采访业务人员具有少得多的风险，但这不能代替用户的介入。遗憾的是，许多机构仍然企图使用这种受数据驱动的最省力的方法去建模，结果是很少有成功的。 2.2 零售实例的研究这里先对在本实例研究中要使用的零售业务进行简要的描述，以使建立的维度与事实表更容易理解。之所以从这个行业入手，是因为它与大家都是密切相关的。设想一下在一家大型杂货连锁店总部工作的情形，其业务涵盖分布在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个点。遗憾的是，如此大规模的降价通常是经受不住的，因为这样的纸巾销售很可能是亏本的。这些问题说明，如何使各种形式的促销活动所产生的效能清晰可见是杂货店运营情况分析的重要部分。在对业务实例研究进行描述之后，现在就可以开始维度建模的设计工作了。2.2.1 第一步：选取业务处理设计工作的第一步是，通过将对业务需求的理解与对可用数据的理解组合起来而确定建模的业务处理内容。建立的第一个维度模型应该是一个最有影响的模型它应该对最紧迫的业务问题做出回答，并且对数据的抽取来说是容易访问的。在这个零售实例研究中，管理方面要做的事情就是更好地理解像POS系统记录的顾客购买情况。于是，建模所提供的业务处理就相应成为一个POS零售业务。这类数据可以用来分析出什么促销条件下的什么日子里，在什么商店正在销售什么样的产品等方面的内容。2.2.2 第二步：定义粒度一旦将业务处理确定下来，数据仓库团队下一个就面临关于粒度确定的严肃课题。应该在维度模型中给出何种详细程度的细节内容？这就引出了关于设计的一个重要提示。应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子型数据是所收集的最详细的信息，这样的数据不能再做更进一步的细分。通过在最低层面上装配数据，大多原子粒度在具有多个前端的应用场合显示出其价值所在。原子型数据是高度维结构化的。事实度量值越细微并具有原子性，就越能够确切地知道更多的事情，所有那些确切知道的事情都转换为维度。在这点上，原子型数据可以说是维度方法的一个极佳匹配。原子型数据可为分析方面提供最大限度的灵活性，因为它可以接受任何可能形式的约束，并可以以任何可能的形式出现。维度模型的细节性数据是安如泰山的，并随时准备接受业务用户的特殊攻击。当然，可以总是给业务处理定义较高层面的粒度，这种粒度表示最具有原子性的数据的聚集。不过，只要选取较高层面的粒度，就意味着将自己限制到更少或者细节性可能更小的维度上了。具有较少粒度性的模型容易直接遭到深入到细节内容的不可预见的用户请求的攻击。如果不让用户存取原子型数据，则他将不可避免地在分析方面撞上南墙。就如将在第16章所见到的那样，聚集概要性数据作为调整性能的一种手段起着非常重要的作用，但它绝对不能作为用户存取最低层面的细节内容的替代品。遗憾的是，有些实业界的权威人士在这方面一直显得含糊不清。他们宣称维度模型只适合于总结性数据，并批评那些认为维度建模方法可以满足预测业务需求的看法。这样的误解会随着细节性的原子型数据在维度模型中的出现而慢慢地消逝。在该实例研究中，最佳粒度的数据是POS事务的单个分列项。为了确保得到最大限度的维度性和灵活性，所有讨论都将在这个粒度上展开。将这个粒度的定义针对第一版的原文做出修改是毫无价值的。以前，我们也将注意力集中在POS数据上，但不是考虑如何在维度模型中对事务分列项目细节进行表示，而是注重提供一天中某个商场所堆积的产品与促销方面的数据。在当时，这些每日产品总量反映了辛迪加零售数据库的技术状况。指望当时的硬件与软件能够有效地处理与各个POS事务分列项相关的数据海量的想法，是很不合时宜的。通过访问POS事务信息，能够得出一个关于商场销售非常详细的概况。虽然用户或许对与特定POS事务相联系的单个项目的分析并不是很感兴趣，但数据库团队仍然无法预知出他们抽取数据的各种可能方式。例如，他们可能想弄清星期一相对于星期日在销售上的不同情况，或者想评估一下是否值得为诸如谷物一类的物品准备那么多不同大小的商标，或者想了解有多少购物者会对优惠50%的洗发精促销活动特别有兴趣，或者想确定如果对一个竞争很激烈的饮用苏打产品在经过了大力的促销宣传以后进行降价销售会造成什么样的影响等。虽然这些查询没有一个只对来自某单个特定事务的数据存在要求，但它们都是些需要精确切割的细节性数据的涉及面很广的问题。如果用户只能存取总结性数据，则不能回答其中的任何一个问题。数据仓库几乎总是要求在每个维度可能得到的最低粒度上对数据进行表示的原因，并不是因为查询想看到每个低层面的行，而是因为查询希望以很精确的方式对细节知识进行抽取。2.2.3 第三步：选定维度一旦事实表的粒度被选定，则时期、产品与商店方面的维度就应该随之被确定下来。可以假定，日历日期是由POS系统提供的日期值。后面可以看到，随日期给出针对每一天的时间其情形又是怎么样的。在基本维度框架范围内，可能需要知道其他诸如针对某种产品的促销这样的维度是否可以分配数据。这个内容可表示为另外的一个设计原则。一个经过仔细考虑的粒度定义确定了事实表的基本维度特性。同时，经常也可能向事实表的基本粒度加入更多的维度，而这些附加的维度会在基本维度的每个组合值方面自然地取得惟一的值。如果附加的维度因为导致生成另外的事实行而违背了这个基本的粒度定义，那么必须对粒度定义进行修改以适应这个维度的情形。在实例研究中，已经选定的描述性维度有：日期、产品、商店与促销等。此外，还会将POS事务票据编号作为一个特殊的维度包括进来。这方面更多的内容将在本章的后面进行介绍。日期维度日期关键字（PK）待定日期属性商场维度商场关键字（PK）待定商场属性POS零售营销事务事实日期关键字（FK）产品关键字（FK）商场关键字（FK）促销关键字（FK）POS事务编号待定事实产品维度产品关键字（PK）待定产品属性促销维度促销关键字（PK）待定促销属性现在可以开始考察如图2.2所示的初步方案了。在着手利用描述属性填充维度表之前，还是先完成设计过程的最后一步吧！特别希望你确实能够对完整的四步过程感到舒心而不想使你在“游戏”的这个阶段只见树木而不见森林。图2.2 零售营销初步方案2.2.4 第四步：确定事实设计过程的第四步同时也是最后一步，在于仔细确定哪些事实要在事实表中出现。粒度定义在这里再次成为考虑问题的支点。只是需要指出，事实对于粒度必须是真实的：这里的粒度就是POS事务的各个分列项。当考虑潜在的事实时，你可能会再次发现，对早先的粒度设想或者维度选取做出调整是非常必要的。POS系统收集的事实包括销售量（比如，鸡精面汤的罐数）、单价与销售额等，其中销售额等于销售量与单价的乘积。更为复杂的POS系统也提供产品标准出厂价。假定这个价格事实容易得到，而不需要以采取一些英雄行为作为代价进行获取，就应该将它放在事实表中。到现在为止，所设计的事实表就开始显得与图2.3显示的情形相似了。销售量、销售额与成本价这三个事实在所有维度中都具有良好的可加性。完全可以自如地对事实表进行切割，并且这三个事实的每种合计值也总是有效的、正确的。日期维度日期关键字（PK）待定日期属性商场维度商场关键字（PK）待定商场属性POS零售营销事务事实日期关键字（FK）产品关键字（FK）商场关键字（FK）促销关键字（FK）POS事务编号销售量销售额成本额毛利润金额产品维度产品关键字（PK）待定产品属性促销维度促销关键字（PK）待定促销属性图2.3 零售营销方案的度量事实可以通过从销售额或者营业额中减去成本花销而计算出毛利润。尽管毛利润是经过计算得到的值，但它在各个维度中同样具有极好的可加性完全可以针对任何时期内在任意数量的商场中销售的任意产品组合，计算出其毛利润。维度建模人员不时在问，通过计算得到的事实是否应该物理地存放在数据库中？我们的意思是，应该将它物理地存放起来。在本实例中，毛利润的计算是直接进行的，但将它存储起来可以消除用户出错的可能性。用户因不当地表示毛利润所付出的代价，将远远超出增加少量存储而需要的花费。同时，将毛利润存储起来也能够确保所有的用户及其报表生成应用能够一致地引用它。既然毛利润能够通过事实表行中相邻的数据计算得到，有人可能觉得，应该在一种同表没有什么区别的视图中执行这种计算。如果所有用户都通过这样的视图去存取数据，并且没有用户使用特殊的存取工具绕开这个视图而进入物理事实表的话，这样的方法是很合乎情理的。想在节省存储空间的同时，最大限度地减少用户可能出现的错误，视图当然是一种合乎逻辑的途径，但问题是DBA一定要能够保证不会在这种视图下出现数据存取的例外情形。同样，有的机构想在查询工具中执行这类计算。不过，这只是在所有用户都使用共同的工具存取数据的情况下才有效（经验表明，这样的情形是很少出现的）。毛利润率可以用毛利润除以营业额而计算出来。毛利润率是非加型事实，因为它不能依照任何维度进行求和运算。只要在做除法之前不忘记加入营业额和成本花销，就可以算出任何产品组、任意数量的商店或者任何日期的毛利润率。这也可以表示为如下的设计原则：诸如百分比和比率这类毛利润率都是非加性的。分子与分母都应该存放在事实表中。可以用数据存取工具求出事实表任何数据形式的比率，只是要记住求取的是合计值的比率，而不是比率的求和。单价也是非加型事实。试图在任何维度范围内对单价进行求和，都会导致出现一些毫无意义的甚至显得荒谬的数值结果。要针对一系列商店或者一个时间跨度分析某种产品的平均售价，就必须在用销售总量去除销售总额之前，将相关销售额与销售量加起来。虽然数据仓库市场方面的报表生成器或者查询工具都应该自动地正确完成这个功能，但是很遗憾，其中一部分工具仍旧不能很圆满地做到这一点。在设计的早期阶段，经常对可能需要的最大表即最大事实表的行数做出估计是很有益处的。在所给出的实例研究中，这一般不过是找源系统的头头们谈一谈，从而弄清一个时间区段内将生成多少POS事务项目的问题。零售流量在一天天地剧烈波动着，因此，需要选定一个对事务活动进行了解的合理时间周期。作为选择，还可以通过用项目平均售价去除连锁店的年毛营业额，而估算出一年要加入到事实表的行数。假设每年的毛营业额为40亿美元，并假定每张顾客票据上各分列项的平均售价为2美元，那么就可以算出每年大约有20亿个事务分列项。工程师通常都要进行的这个典型评估，差点使我们惊讶得从扶手椅上跳起来去重新考虑是否将设计进行下去。但作为设计人员，总是应该不断地进行评估以确定计算是否合乎情理。 2.3 维度表属性在对四步过程走了一遍以后，现在可以回到维度表上面来，并致力于用丰富的属性将它们填充起来。2.3.1 日期维度这里首先从日期维度入手进行介绍。日期维度是几乎每个数据中心都必须提供的一个维度，因为实际上，每个数据中心都是时间系列的。事实上，日期通常是数据库进行潜在分类排序的首选维度，这样做的目的是，使按时间间隔连续加载的数据能够顺次存放到磁盘上的空白存储区中。需要提请阅读过数据仓库工具箱（The Data Warehouse Toolkit）第一版（1996年Wiley出版）的读者注意的是，该书将这个维度称做时间维度。不是揪住那个更显得模棱两可的术语不放，作者在本书中用日期维度指称按日期进行粒度定义的维度表。这有助于对时期维度和每天的时间维度进行区分，相关内容将在本章后面讨论。与其他多数维度不一样，日期维度表可以事先建立。这样的表可存放以日期表示的5到10年的历史数据行，同样，也可以将未来几年的数据行放入其中。即使针对10年的每一天都进行存储，也只不过要3650行，这是一个相当小的维度表。对于零售环境中日常的日期维度表来说，可以采用图2.4中所推荐的部分列表项。日期维度表的每列由行所代表的特定日期进行定义。“星期”一列含有每天像“星期一”这样的名称内容，该列可用于创建比较“星期一”与“星期日”的业务的报表。日历表中“月”所在列的日编号从每个月的1开始取值，然后根据月份的情况取到28、29、30或者31，这一列对于每月的同一天进行比较的情况很有好处。按照类似的方式，可给出一年中每月的编号（1，12）。纪元表示法采用一种称为恺撒日编号（即从某纪元开始连续对日期进行计数）来有效地给出日编号。当然也可以在表中给出“星期”与“月份”的绝对编号列。所有这些整数都支持跨年度跨月份的简单数据运算。在生成报表时，常常要给出像“一月”这样的月份名称。此外，为报表给定一个“年月”（YYYY-MM）列标题也是很有用途的。同样，报表中很可能需要季度编号（Q1，Q4）或者诸如2001-Q4这样的年季度编号列。如果财政年度与日历表在周期上不一致，则可以为财政年度给出类似的列。在“节假日”指示列中给出“节假日”或者“非节假日”这样的内容。要记住，维度表属性是做报表标记之用的，因此，简单地在“节假日”指示列中给出“Y”或者“N”是没有多大作用。关于这个问题，考虑一下要对某产品的节假日与非节假日的销售情况进行比较的报表应用就可以弄清楚。显然，列中给出“节假日”或者“非节假日”这样富有意义的值比一个“Y”或者“N” 之类的编码，要有用得多。还要注意，不应该在报表生成器中执行将编码标记翻译成易理解的标记这种操作，而应该将翻译内容存放在数据库中，以便使各种用户不受其报表生成工具的限制而得到一致的翻译内容。日期维度日期关键字（PK）日期完全描述星期纪元日编号纪元周编号纪元月编号日历日期编号日历周编号日历月编号财政月日编号周末指示符月末指示符日历周结束日期年度日历周数日历月名年度日历月数日历年月（YYYY-MM）日历季度日历年季度日历半年度日历年财政周年度财政周数财政月年度财政月数财政年月财政季度财政年季度财政半年度财政年节假日指示符星期指示符销售旺季重大事件SQL日期标记及其他POS零售事务事实日期关键字（FK）产品关键字（FK）商场关键字（FK）促销关键字（FK）POS事务编号销售量销售额成本额毛利润金额产品维度商场维度促销维度图2.4 零售营销方案的日期维度对于取值为“平日”与“周末”的“星期”指示列，理应做类似处理。不用说，“星期六”与“星期日”要归入“周末”之列。当然，可以对多个日期表属性进行共同约束，从而容易地实现诸如针对平日假期与周末假期进行比较这样的应用。“销售时令”列应设置为零售时节的名称，比如以美国的情形为例，这些名称可以是圣诞节、感恩节、复活节、情人节、独立日，或者标为“不是”。“重大事件”列与“销售时令”列情形类似，可以标记为诸如“超级饭碗周日”或者“劳动者罢工”这样的特殊外部事件。一般性的促销活动通常不放在日期表中处理，而以促销维度表的形式进行更加完整的描述。这样做的主要原因在于，促销事件并不是仅仅由日期来定义，而通常是由日期、产品与商店的组合形式进行定义的。有些设计人员可能在此处停下来询问为什么需要一个明确的日期维度表的原因。他们说，如果事实表的日期关键字是日期类型的字段，则任何SQL查询可以直接针对事实表日期关键字进行约束，并使用一般的SQL日期语法对月份或者年度进行过滤而避免进行想像起来开销显得很大的连接操作。有多个原因可以用来说明这个推断是站不住脚的。首先，如果关系数据库不能处理与日期维度表的高效率连接，则确实会遇到很大的麻烦。问题是，绝大多数数据库优化机制在处理维度查询方面具有非常高的效率，从而没有必要像对待瘟疫一样地对连接操作避之而惟恐不及。还有，在性能方面，绝大多数数据库不对SQL日期运算进行索引，因而由SQL运算字段进行约束的查询不会用到索引。从可用性角度讲，典型的业务用户并不精通SQL日期语法，因此他或者她不能去直接利用与日期数据类型相关的内在功效。SQL日期函数不支持通过诸如周末、节假日、财务盘点、时令或者重大事件与平日这样的属性而施加的过滤操作。假如说业务上存在比照这些非标准日期属性进行数据切割的需要，那么一个明确的日期维度表就显得很必要了。说到底，日历逻辑要归入维度表而不是应用代码中去。最后，建议你将日期关键字指定为整数类型而不是任何形式的日期数据。一个基于SQL的日期关键字在典型情况下是8字节的，因而事实表各行的每个日期关键字要浪费4个字节。本章后面将就这方面的内容进行更多的介绍。图2.5给出了取自部分日期维度表的几行数据。数据仓库总需要一个明确的维度表。有许多日期属性不能由SQL函数提供支持，这包括财务盘点、时令、节假日与周末等。与企图在查询中给定这些非标准日历运算的做法不同，而更应该在一个日期维度表中去检索它们。如果用户要存取可以针对一天的情况进行分析（例如，在下班高峰的傍晚区间或者商场的第三班时间段内）的事务时间，就应该通过与事实表相连接的一个单独日历维度表来处理它。日期与时间几乎是完全不相关的。如果将这两个维度组合在一起，日期维度表就会增大许多。于是，假如在同一个表（或者支架）中按分钟对时间进行处理的话，那么一个只有3 650行就可以对10年的数据进行处理的简洁维度，一下子将扩展到5 256 000行。比较起来，显然更应该创建一个3 650行的日期维度表和一个分开的按分钟为每天记录1 440行的维度表。第5章将讨论在单个方案中处理多个日期的情形，在第11章与第14章中还将讨论跨国际的日期与时间考虑因素。日期关键字日期日期完整描述星期日历月日历年财政年月节假日指示符周日指示符101/01/20022002年1月1日星期二1月2002年F2002-01节日平日201/02/20022002年1月2日星期三1月2002年F2002-01非节日平日301/03/20022002年1月3日星期四1月2002年F2002-01非节日平日401/04/20022002年1月4日星期五1月2002年F2002-01非节日平日501/05/20022002年1月5日星期六1月2002年F2002-01非节日周日601/06/20022002年1月6日星期日1月2002年F2002-01非节日周日701/07/20022002年1月7日星期一1月2002年F2002-01非节日平日801/08/20022002年1月8日星期二1月2002年F2002-01非节日平日图2.5 日期维度表的细节2.3.2 产品维度产品维度描述杂货店的每个SKU。虽然典型的连锁店可能存储60 000个SKUs，但在考虑跨连锁店与涵盖不再销售的历史产品的不同商品规划方案时，产品维度可能至少需要150 000行乃至多达百万行。产品维度几乎总是起源于操作型产品主文件。大多数零售商在总部对其产品主文件进行管理，并经常不间断地将文件的一部分下载到各商店的POS系统中。总部负责为每个由货物包装商创建的新UPC定义合适的产品主记录（以及具有惟一性的SKU），同时还负责定义将SKUs分配给诸如面包类食品、肉食品与农产品这些项目的规则。在产品主文件发生改变的任何时候，都要从产品主文件抽取数据并存入产品维度表中。产品主文件的一个重要作用，就是维护每个SKU的许多描述属性。商品体系就是一组重要的属性。通常，各类SKUs堆积形成商标，商标堆积形成分类，而分类则堆积形成部门，其中的每个关系都是多对一的。这个商品体系与其他属性的详细情况如图2.6给出的部分产品所示。产品关键字产品描述商标描述分类描述部门描述含脂量1低碱烤肉包烧烤面包面包房低脂2松脆全麦切片松脆面包面包房一般3松淡全麦切片松脆面包面包房低脂4脱脂小桂卷松软甜面包面包房无脂52加仑装美食香料冷裹品冷冻点心冷冻食品部无脂61品脱装黄油软奶桃鲜类冷冻点心冷冻食品部低脂71/2加仑装巧克力美食冷冻冷冻点心冷冻食品部一般81品脱装草莓冰淇淋冰冻冷冻点心冷冻食品部一般9冰淇淋三明治冰冻冷冻点心冷冻食品部一般图2.6 产品维度表的细节对于每个SKU而言，所有层次的商品体系都是经过良好定义的，并且像SKU描述之类的一些属性还具有惟一性。在这种情况下，SKU描述项至少有150 000个不同的取值。在另一个极端，可能出现部门属性只有50个不同取值的情况。于是平均下来，部门属性的每个惟一值会有3 000个重复项。不过没什么关系！没有必要考虑将这些重复值分成另一个规范化表而节省一点空间。须知，维度表的空间需求同事实表的空间考量相比显得多么不起眼。产品维度表的许多属性并不是商品体系的组成部分。例如，包装类型属性就极可能有瓶装、袋装、盒装或者其他类型。任何部门的任何产品都可能取这些值中的一个。将这类属性的约束和商品体系属性方面的约束进行组合，具有非常积极的意义。作为例子，可以看一下袋装谷物分类中的所有SKUs。换个角度来考虑这个问题，可以对维度属性进行顺次浏览看它们是否属于商品体系，或者可以使用属性进行向上或者向下探查而看它们是否属于商品体系。另外，甚至可以在产品维度表中明确地包含一个以上的体系。 产品维度表 产品关键字（PK）产品描述SKU编号（自然关键字）商标描述分类描述部门描述包装类型描述包装尺寸含脂量食物类型重量重量单位储藏类型货架期类型货架宽度货架高度货架深度其他 POS零售事务事实 日期关键字（FK）产品关键字（FK）商场关键字（FK）促销关键字（FK）POS事务编号销售量销售额成本额毛利润金额日期维度商场维度促销维度推荐用于零售杂货数据中心的部分产品维度看起来同图2.7中的情形类似。图2.7 零售营销方案的产品维度一个合理的产品维度表可以拥有50或者更多的描述属性。每个属性都是约束和构造行标题的丰富来源。从这个意义上讲，如此费心劳神除了得到能够提供更多信息的行标题之外，别无所求。还是看看已经按部门针对销售额和销售量进行了汇总的简单报表吧： 部门描述销售额销售量面包店$12 3315 088冷冻食品部$31 77615 565如果进行向下探查，实际上可以从产品维度将诸如商标这样的任何其他属性拖入紧接部门的下一级报表，并且能够自动探查到次一级的细节层次。在商品体系内，一个典型的向下探查结果与如下情形非常类似：部门描述 商标描述 销售额 销售量面包点炸油条$3 0091 138面包点脆饼$3 0241 476面包点软糕点$6 2982 474冷冻食品部雪糕$5 3212 640冷冻食品部鲜货$10 4765 234冷冻食品部冷狗$7 3283 092冷冻食品部冰糕$2 1841 437冷冻食品部速冻$6 4673 162或者可以按脂肪含量属性向下探查，即使它不在商品堆积体系之列也是如此。部门描述 脂肪含量 销售额 销售量面包点无脂$6 292 474面包点低脂$5 0272 086面包点一般$1 006528冷冻食品部无脂$5 3212 640冷冻食品部低脂$10 4765 234冷冻食品部一般$15 9797 691前面煞费苦心地给出探查例子的目的是为了得出作为设计原则来表述的观点。在数据中心进行的向下探查操作不过是通过维度表添加一些行标题，而向上探查就是删除行标题。可以通过来自多个显式体系的属性而进行向上或者向下探查操作，也可以按非体系部分的属性进行同样的操作。产品维度是几乎每个数据中心都拥有的两到三个基本维度之一。用尽可能多的描述属性对这个维度进行填充时，应该特别小心。一组丰富而完整的维度属性会转化为丰富而完整的用户数据分析能力。第4章将进一步研究产品维度，同时在那里还将讨论处理产品属性变化方面的内容。2.3.3 商场维度商场维度描述杂货连锁店的每个商场。与每个大型杂货店业务中基本上都能够得到的产品主文件不同，并不能保证存在可用的商场综合主文件。每当有新的或者变化的产品出现时，就需要将产品主文件下载到各个商场。不过，单个POS系统并不需要一个商场主文件。IT人员必须经常性地对来自总部多个操作源的商场维度必要分量进行装配。在实例研究中，商场维度是基本的地理维度，每个商场可被看成一个位置。据此，可以将商场堆积成诸如美国的ZIP编码、县与州这样的任意地理属性。商场通常也堆积成商场的一些行政区或者地区。这两种不同的维度都很容易在商场维度中表示出来，因为地理体系与商场地区体系对每个商场行来说，都是经过良好定义的。在维度表中表示多个体系是不常见的。在理想情况下，属性名与值在跨多个体系的范围内应该是惟一的。推荐在杂货店业务方面使用如图2.8所示的商场维度表。建筑平面图的类型、影印处理类型以及财务服务类型等都是描述特定商场的短文本描述内容。这些内容不应该是单个字符的编码，而应该是出现在下拉列表或者报表行标题中，显得意义明确，并经过标准化处理的10到20个字符大小的描述内容。描述销售面积的列应该是数字型的，并且在理论上是跨商场可相加的。虽然有人可能试图将它放到事实表中，不过很明显，它是商场的一个不变属性，并且作为报表约束或者行标题使用的情况比用做求和的可加分量要多得多。因为这些原因，可以确信，销售面积属于商场维度表。POS零售事务事实日期关键字（FK）产品关键字（FK）商场关键字（FK）促销关键字（FK）POS事务编号销售量销售额成本额毛利润金额日期维度产品维度促销维度商场维度商场关键字（PK）商场名称商场编号（自然关键字）商场所在街道地址商场所在城市商场所在县商场所在州商场所在邮政编码商场经理商场政区商场地区平面布置类型摄影加工类型财经服务类型销售面积总面积首次开业日最后一次重修日期及其他图2.8 零售营销方案的商场维度首度开业日期与最新重修日期一般都是连接到日期维度表拷贝的关键字。这些日期维度拷贝通过VIEW结构在SQL中进行定义，并在语义上同基本日期维度相区别。VIEW定义的形式如下：CREATE VIEW FIRST_OPEN_DATE (FIRST_OPEN_NUMBER， FIRST_OPEN_MONTH， ) AS SELECT DAY_NUMBER， MONTH， FROM DATE这样，系统运作起来就好像存在一个称做FIRST_OPEN_DATE的日期维度表拷贝。针对这个新日期表的约束不会对基本日期维度表上的约束产生任何影响。第一个开放日期视图是对商场维度来说可以允许的一个支架。要注意的是，视图的所有列都重新进行了仔细的标记，以便使它们不与基本维度表的列互相混淆。第6章还会对支架做进一步的讨论。2.3.4 促销维度促销维度是方案中可能最令人感兴趣的维度。促销维度描述产品销售的促销情形。促销情形包括临时降价、廊端展销、报纸广告与优惠券等。因为这个维度用来描述被认定会使产品销售发生变化的因素而通常被叫做因果维度（与偶然维度相对）。总部与商场的经理都对确定一个促销活动是否有效感兴趣。促销由下列一至多个因素进行评判：o 促销产品的销售是否在促销区间出现增长。这叫做上扬（lift）。上扬只有当商场能够就什么是在没有促销的情况下促销产品可以达到的销售底线而取得一致意见时，才能进行评测。底线值可以从以前的销售历史，以及在某种场合下借助于复杂的数学模型而计算出来。o 除去促销区间（过渡时间）内销售方面的增长以外，促销产品的销售是否就在促销进行之前或者随后表现出减少的情形。换句话说，销售人员实施过从正常定价产品到临时减价产品方面的销售转移吗？o 是否发生促销产品的销售出现增长，而临近货架上的其他产品销售却呈现出相应的降低情况（发生同类相食）？o 在考虑了促销之前、区间与其后的时间段因素（市场生长）的情况下，促销类别中所有产品的销售是否都经历了一个实际的总体增长？o 促销是否赢利。在通常情况下，促销利润要按促销类别的利润增量与考虑了时间过渡、同类调剂以及销售底线的比值而计算出来。其中，底线应该考虑了包括临时降价、广告、展示和优惠券在内的促销花费等因素。对销售产生潜在影响的因果情形，并不需要由POS系统进行直接的跟踪。这种事务系统要保持对降价与削价的跟踪。通常优惠券的使用也由该事务进行捕获，因为顾客在购买商品时要么出示优惠券，要么不这么做。广告与商场的展示可能需要与其他源头进行连结，各种可能的因果情形都是高度相关的。临时降价会通常与广告或者廊端展销联系在一起，优惠券通常也与广告相关联。因为这个原因，在促销维度为促销出现的每种组合都创建一行显得很有意义。在一年的进程中，可能出现1 000个广告，5 000次临时降价和1 000次廊端展销，但可能只有10 000个这三种手段的组合能够影响任何特定的产品。例如，在某给定维度中，大多数商场都会同时运作所有三种机制，而只有少数几个商场不进行廊端展销。在这种情况下，就需要两个单独的促销情形行，一个用于通常的降价并外加广告与展示，而一个用于降价并外加单纯的广告。推荐使用的一个促销维度表显示在图2.9中。POS零售事务事实日期关键字（FK）产品关键字（FK）商场关键字（FK）促销关键字（FK）POS事务编号销售量销售额成本额毛利润金额日期维度产品维度商场维度促销维度促销关键字（PK）促销名称减价类型促销媒体类型广告类型展览类型优惠券类型广告媒体名称展览提供者促销价促销起始日期促销结束日期及其他图2.9 零售营销方案的促销维度从单纯的逻辑角度看，通过将四个主要的因果维度机制（价格降低、广告、展示与优惠券）分开形成单独的维度，而不是将它们组合成一个维度，就能够记录维度方面非常相似的信息。究竟使用哪种方式，最后的选择权掌握在设计人员手中。赞成将四个维度揉合在一起，基于包括如下两个方面的考虑：o 既然四个因果机制是高度相关的，那么组合起来的单个维度就不会比分开的任何一个大许多。o 组合起来的单个维度能够高效地进行浏览，以弄清各种不同的价格降低、广告、展销与优惠券是如何在一起进行应用的。当然，这样的浏览仅仅显示了可能的组合。在维度表中所进行的浏览，并不能揭示促销对哪家商场和哪种产品产生了影响。这类信息放在事实表中。倾向于将四个因果机制分开而形成不同维度表的想法是基于对如下两个因素的权衡而产生的：o 在用户分开考虑这些机制时，分开的维度对业务群体来说更容易理解。这一点在业务需求调研区间就会显露出来。o 独立维度的管理相对组合维度的管理，表现得更加直截了当。记住，在数据仓库的信息内容方面，这两种选择之间并不存在什么不同。在典型情况下，许多销售事务分列项目会涉及到并不在促销之列的产品。因此，需要在促销维度中包括以其惟一关键字来标识“不在促销之列”的一行，从而避免在事实表中出现空促销关键字的情况。如果在作为引用维度表的外关键字而进行定义的事实表列中放置一个空值，引用完整性就会遭到破坏。除了出现引用完整性方面的警告外，空关键字还是用户疑惑不解的根源，因为他们不能对空关键字进行连接。必须避免在事实表中出现空关键字。在这方面显得比较合适的设计是在对应的维度表中包括一行来标识该维度对度量值不可用。1促销范围的非事实型事实表不管对促销维度进行如何处理，所给出的零售营销维度方案还不能对一个重要问题做出回答：什么样的促销产品没有卖出去？销售事实表仅仅记录了实际卖出的SKUs，而不存在将没有卖出去的SKUs以0事实进行表示的事实表行，因为这样做会造成事实表的过度膨胀。在关系数据库领域，需要另外的一个促销范围或者事件事实表来协助回答关于什么没有发生方面的问题。在该实例研究中，促销范围事实表的关键字是日期、产品、商场与维度。这显然看起来与刚设计的事实表显得很相似，不过，在粒度方面会存在非常大的不同。在使用促销维度事实表的情形下，不管产品卖出与否，都要在该事实表为每天（或者一周，因为许多零售促销会持续一周）中每个商场的每个促销产品创建一行。通过范围事实表可以看到由促销活动所定义的关键字之间的关系，而不必关心诸如实际产品销售这样的其他事情。之所以将它称之为非事实型事实表，是因为它不具有度量指标；它仅仅能够捕获所涉及的关键字之间的关系。为了确定什么产品属于促销之列却没有卖出，需要采取两个步骤。首先，要查询促销范围表以确定某天促销产品的范围，然后，根据POS销售事实表确定卖出了什么产品。针对先前问题的答案，取决于这两个列表之间所给出的不同内容。注意从第12章中获取关于非事实型事实表方面更为完整的内容，在那里将给出促销范围表的例子，并提供表现两表所具有的不同内容的SQL语句。如果工作场合是OLAP立方体环境，那么通常容易回答关于什么产品没有卖出之类的问题，因为这种立方体一般都含有非实际行为方面的明确信息块。2.3.5 退化的事务编号维度零售事实表包含每个分列项目行的POS事务编号。在传统的父-子关系型数据库中，POS事务编号是事务标题记录的关键字，这样的记录包含了诸如事务日期与商场标识符这样的在总体上对事务有效的所有信息。然而，在这里给出的维度模型中，已经将这个令人感兴趣的标题信息抽取出来而放到其他维度中了。不过，POS事务编号仍旧非常有用，因为它可以作为组关键字而将单个事务中售出的所有产品集中在一起。尽管POS事务编号看起来像事实表中的一个维度关键字，但这里还是将从其他方面看极可能形成一个POS事务维度的所有描述性项目内容进行了剔除。既然所形成的维度为空，那么不妨将POS事务编号称做退化维度（Degenerate Dimension）（图2.10中DD符号标识的部分）。诸如POS事务编号这样的固有操作型票据编号，应该自然而然地放在事实表中，而不用连接到维度表。退化维度在事实表粒度表示单个事务或者事务分列项目时是很常见的，因为它表示了父实体的惟一标识符。订单编号、发票编号与