维度模型设计的4步过程
第1步：选择业务过程
业务过程是由组织完成的微观活动，（如：获得订单、开具发票、注册学生等）。
业务过程的公共特征，理解它们将有助于区分组织中不同的业务过程：
1.业务过程通常用动词表示，因为它们通常表示业务执行的活动。与之相关的维度描述与每个业务过程事件关联的描述性环境。
2.业务过程通常由某个操作型系统支撑，（如：账单或购买系统）
3.业务过程建立或获取关键性能度量。有时这些度量是业务过程的直接结果，度量从其他时间获得。
4.业务过程通常由输入激活，产生输出度量。
第2步：声明粒度
声明粒度意味着定义某个事实表的每一行表示什么。粒度传递的是与事实表度量有关的细节级别。粒度由获取业务过程事件的操作型系统的物理实现确定。
典型的粒度声明如下：
1.客户销售事务上的每个产品扫描到一行中
2.医生开具的票据的列表内容项采用一行表示
3.机场登机口处理的每个登机牌采用一行表示
4.仓库中每种材料库存水平的每日快照采用一行表示
5.每个银行账户每月的情况采用一行表示
上述粒度声明以业务术语表示。无论何时，都应该以业务术语表示粒度。
第3步：确定维度
维度要解决的问题是“业务人员如何描述来自业务过程度量事件的数据？”应当使用健壮的维度集合来装饰事实表。常见维度的实例包括日期、产品、客户、雇员、设备等。在选择每个维度时，应该列出所有具体的、文本类型的属性以充实每个维度表。
第4步：确定事实
可以通过回答“过程的度量是什么？”这一问题来确定事实。设计中的所有候选事实必须符合第2步的粒度定义。明显属于不同粒度的事实必须放在不同的事实表中。
图片来自书中.png
零售业务案例研究
在某个大型食品杂货连锁店总部工作。该连锁店由100分布于5个不同州的分店组成。每个商店都有完整的部门，包括杂货、冷冻食品，日常生活用品、肉类、农产品、等。每个商店包含被为产品统一编号（SKU）的60000中不同的上架产品。
数据存放在商店的几个不同地方。对零售商店来说，管理方面主要关注对订单、库存、销售产品的组织工作，目的是实现利润最大化。利润最终来源于赚取每种商品尽可能多的差价，降低获得产品的开销，提供具有较强竞争力的环境以吸引更多的顾客消费。显然，管理决策与价格和促销有关。
维度模型的设计问题：
第1步：选择业务过程
设计的第1步是通过对业务需求以及可用数据源的综合考虑，决定对那种业务过程开展建模工作。
注：第1个DW/BI项目应该将注意力放在最为关键的、最易实现的用户业务过程。最易实现涉及一系统列的考虑，包含数据可用性与质量，以及组织的准备工作等。
第2步：声明粒度
有许多理由要求以最低的原子粒度处理数据。原子粒度数据具有强大的多维性。事实度量越详细，越能获得更确定的事实。将所知的所有的确定的事情转换成维度。在这点上，原子数据与多维方法能够实现最佳匹配。
注：设计开发的维度模型应该表示由业务过程获取得最详细的原子信息。
定义汇总粒度来表示对原子数据的聚集。一旦选择了级别较高的粒度，就限制了建立更细节的维度的可能性。粒度较高的模型无法实现用户下钻的细节的需求。如果用户不能访问原子数据，则不可避免会面临分析障碍。尽管聚集数据对性能调整有很好的效果，但这种相关的获得仍然不能替代允许用户访问最低粒度的细节。用户可以方便地通过细节数据获得汇总数据，但不能从汇总数据得到细节数据。
注：DW/BI系统几乎总是要求数据尽可能最细粒度来表示，不是因为需要查询单独的某行，而是因为查询需要以非常精确的方式对细节进行切分。
确定维度
事实表粒度选择完毕后，维度选择比较直接。在主维度框架内，可以考虑其他维度是否可以被属性化为POS属性（如：销售日期，销售商店等）。
注：详细的粒度说明确定了事实表的主要维度。然后可以将更多维度增加到事实表上，只要这些额外的维度自然地承担主维度合并某个值。如果附加的维度会产生与粒度不符的其他事实行，则取消该维度或重新考虑粒度声明。
以下的描述性维度应用于该案例中：日期、产品、门店、促销、收银员、支付方式。
确定事实
设计的最后一步是确认应该将哪些事实放到事实表中。粒度声明有助于稳定相关的考虑。事实必须与粒度吻合：放入POS交易的单独产品线项。在考虑可能存在的事实时，可能会发现仍然需要调整早期的粒度声明或维度选择。
书上图片.png
4类事实——涉及所有维度的销售数量、销售可扩展额、销售、成本额——均是完全可加的。可以对事实表按照维度属性不受限制地开展切片或切块操作。针对这4类事实开展的汇总工作都是合法正确的。
1.计算获得的事实
可通过从扩展销售总额中减去扩展成本总额的方式获得总利润额，也称为收入。通过计算所得，但对所有维度来说，总利润额也是完全可加的。可以计算任意时间段内，所有商店所销售产品的任意组合的总利润额。（如：百分比或比率，则必须由BI工具计算，因为此类计算不能被预先计算出来并存储在事实表中。OLAP多维数据库更适合这样的环境。）
2.不可加事实
利润率可通过利润总额除以扩展销售总额获得。利润率是非可加事实，因为它不能从任何维度被汇总。可以计算任意产品集合、商店或日期的利润率，方法是分别记录收入汇总，以及开销汇总，然后作除法计算。
注：百分比和比率（如：利润率）是不可加的。应当将其分子分母分别存储在事实表中，比率可采用BI工具计算事实表的任意分片，只需要记住计算的是汇总的比率，而不是比率的汇总。
单价是另一种不可加事实。基本的非可加的事实（如：温度）通常是从其他源系统获得的。此类非可加事实需要通过多个记录求平均值来获得。如果业务分析师同意这样做，将非可加事实存储在事实表中也有意义。
3.事务事实表
事务型业务过程是最常见的业务过程。表示这些过程的事实表具有以下特征：
1.原子事务事实表的粒度可在事务环境下被简洁地描述，(如：每个事务一行或每个事务线一行)。
2.由于这些事实表记录的是一个事务事件，所以它们通常是比较稀疏的。
3.即使事务事实表无法预测，分布稀疏，它们仍然可能非常庞大。数据仓库中多数包含数十亿、数万亿行的表往往都是事务事实表。
4.事务事实表趋向成为多维化。
5.事务事件返回的度量通常是可加的，只要它们通过数量来扩展，而不是获取单位度量。
在设计初期，先估计一下最大的表情况，也就是估计事实表的行数是非常有必要的。假定销售总额为40亿美元，客户票据中均每项价格为2美元，可以计算出每年大约有20亿事务项。这种估算方式是典型的工程化估计，能够使您获得非常接近实际的设计。作为一个设计者，应该始终通过多角度测量来确定您的计算是否合理。
维度表设计细节
日期维度
日期维度是一种特殊的维度，因为它几乎出现在所有的维度模型中。实际上每个业务过程都需要获取时间序列的性能度量。事实上，日期通常是数据库分区模式下首先需要考虑的维度，连续的时间间隔数据加载被放置于磁盘上的新区中。“日期维度”表示粒度按天处理的维度表。这有助于区分日期维度和当天时间（time-of-day）维度。
与多数其他维度不同，可以提前建立日期维度表。可以在表中按行表示10--20年的不同日期，因此可以涵盖存储的历史，也可以包含未来的几年。
日期维度表中的每列由行表示的特定日期定义。周天列包含天的名称，如周一。
对于报表，需要增加长标识和缩写标识，（如：希望存在月名属性，包含如1月这样的值）。
图片来自书中.png
维度模型总是需要详尽的日期维度表。SQL日期函数不支持范围广泛的日期属性，包括周、财务周期、季节、假日等。与其试图将这些非标准日历计算放入查询中，不如放在日期维度表中，通过查询直接获得。
1.文本属性的标识和标志
与大多数操作型标志与标识类似，日期维度的假日标识是一种简单的带有两个可能值的标识。由于维度表属性用于报表和下拉式查询过滤列表中的值。所以该标识应该用有意义的值，（如：假日或非假日，而不是用神秘的Y/N、1/0或真/假表示。）
2.当前与相对日期属性
大多数日期维度属性不应该更新。IsCurrentDay显然每天都需要更新。该属性对建立总是指向当前天的报表有用。大多数数据仓库按天加载数据，因此IsCurrentDay涉及昨天（或者更准确地说，是最近的加载日期）。可在日期维度中增加属性表示您的企业日历。
滞后日期列中值为0表示今天，-1表示昨天，+1表示明天等等。该属性易于成为可计算列而不是物理地存储。可用于为月、季度和年设置类似结构。许多BI工具包括实现前期计算的功能，因此这些滞后列可能没有存在的必要。
3.将当天时间（time-of-day）作为维度或事实
尽管日期和时间可以合起来作为操作型日期/时间戳，当天时间通常从日期维度中分离出来。以避免在日期维度中执行行计算的复杂性。
商业用户通常对滞后时间更感兴趣。（如，事务的持续时间，而不是离散的开始时间和结束时间。滞后时间可方便地通过获得不同的时间戳来计算。这些日期/时间戳也许允许应用程序确定两个不同事务之间的时间差别，即使这些事务存在于不同的日期、月份或年。
产品维度
产品维度描述仓库中存储的每个SKU（产品统一编码）。产品维度几乎总是来源于操作型产品主文件。多数零售商在其总部管理其产品主文件，并将部分子集频繁地下载到每个商店的POS系统上。为每个新产品定义适当的产品主记录（唯一的SKU号）是管理层的职责。
1.扁平化多对一层次
产品维度表示每个SKU的大多数描述性属性。商品层次是属性的主要分组之一。单个的SKU上卷到品牌，品牌上卷到类别，类别分类上卷到部门。每一不同层次都存在多对一关系。
书上图片.png
注：将重复的低粒度值保存在主维度表中是一种基本的维度建模技术。规范化这些值将其放入不同的表将难以实现简单化与高性能的主要目标。
产品维度表中的大多数属性并不是商品层次的组成部分。包装类型属性的值可能包括瓶、包、盒等。任何部门的任何SKU可能采用类型属性的某一个值。将该属性上的约束合并为对整个商品层次属性的约束，往往是比较有意义的。产品维度表通常包含多个明确的层次。
2.具有内嵌含义的属性
在维度表中按照自然键概念确定的操作型产品代码通常情况下具有内嵌的含义，不同部分表示产品的不同特征。
3.作为属性或事实的数字值
有时很可能会遇到某些数字值，很难判断应该将其归入维度属性分类，还是归入事实分类。产品价格很显然是一个数字值，初始想法将前期当成事实来对待。但通常标准价格变化缓慢，不像其他事实表中的数量值，对不同的度量事件产生不同的值。
如果某个数字值主要用于计算目的，则它可能应该属于事实表。因为标准价格是非可加的，可用它乘以数量获得扩展总额，这个值是可加的。价格变化分析，变化度量应该被存在事实表中。如果能预先定义稳定的数字值，用于过滤和分组，则它应该被当成产品维度属性对待。
数字值可同时用于计算以及过滤/分组功能。在此情况下，应当在事实表和维度表中同时存储该值。
注：可用于事实计算和维度约束、分组及标记的数据元素应该被保存在两个不同的位置，即使聪明的程序员可以编写应用程序来访问单一地址的这些数据元素。涉及计算的数据应该放入事实表，涉及约束、分组和标记的数据应该放入维度表中。
4.下钻维度属性
合理的产品维度表可包含大约50个左右的描述性属性。每个属性可作为约束和构建行头指针标识的来源。下钻只不过是从维度表中请求行头指针以提供更多信息。
图片来自书上.png
注：在维度模型上下钻只不过从维度表中增加了行头指针属性。上卷操作将移除行表头。可以根据属性从多个层次上卷或下钻，其中部分属性不是层次的组成部分。
构建产品维度可能使用大量的描述性属性。健壮完整的维度属性集合将会转换为商业用户的健壮完整的分析能力。
商店维度
商店维度描述零售连锁店的每个门店。与产品主文件在每个大型食品杂货连锁业都已经存在不同，一般没有一个全面完整的商店主文件。POS系统可能仅仅支持交易记录上的商店号。项目组必须从多个操作型源汇集构建商店维度所需的各种元素。通常在总部都会存在一个商店的房产部门，利用该部门的信息可定义详细的商店主文件。
1.多层次维度表
商店维度案例中主要的地理维度。每个商店可以考虑为一个地址。可按任何地理属性对商店进行上卷操作，（如：邮编，国家等）。
商店也可能按照内部组织层次上卷，这种层次包含商店街区和地区。
注：在一个维度表中表示多个层次并不常见。跨多个层次的属性名称和值应该具有唯一性。
2.维度表中的日期
商店维度中的首次开店日期与最后改建日期是日期类型的列。然而，如果用户希望按照非标准的日历属性（如：开店日的财务周期）分组和约束。
网友评论