《数据仓库生命周期工具箱》读书笔记 1

今天读的是这本书的第6章，这一章讲解的是维度建模介绍。（这是本章第一部分笔记）
这本书讲解是如何使用作者提出的生命周期原理创建BI相关软件。这里我能够使用到的只有相关概念章节，加深对BI相关软件的理解。
前面的章节都是讲解对我暂时无用的东西忽略掉直接到第6章看一下维度建模的介绍。

1、什么事维度建模
维度建模时一种将数据结构化的设计方法，因此他们对业务用户来说很直观，并且能够提供较快的查询性能。
维度建模将客观世界划分为度量和上下文。度量是由机构的业务过程和支持他们的业务源系统来捕捉的，常常以数值形式出现，我们将它们称作“事实”。
事实由大量文本形式的上下文包围着，这些文本形式的上下文只有当事实本记录时才为真。这种上下文被直观地分割成多个独立的逻辑块，我们将其称作“维”。维度描述了度量上下文的5W（who、what、when、where和why）信息，以及这些上下文是如何作用的。
机构的每一个业务过程都可以用维度模型来描述，维度模型由一系列含有数值型度量的事实表组成，而事实表中的数据型度量则被一系列带有文本形式上下文的维度表所环绕。

2、维度建模的好处
可理解性是维度模型得意广泛应用的一个主要原因。
查询性能是维度建模的第二个主要驱动因素。
最后，对维度模型进行扩展也比较容易，这样可以容纳那些事先未预料到的新数据。

3、维度建模入门

3.1 事实表
事实表存储了从机构业务活动或者事件中提炼出来的性能度量，术语“事实”其实就是指每种性能度量 。一般来说，你不会预先知道 某个事实的价值，因为事实也是变化的。
需要注意的是：并非所有的数值型的值都存放在事实表中，例如，某个设备的面积就是一项静态描述，应当放到设备维中，而不是放在事实表中。一个比较好的经验型法则是看看属性是否是离散取值的，以及是否用于过滤和标记，如果满足这些条件就应当放在维度中。如果属性有许多值可选，并且可以用于计算，这应该将其放入事实表。这种经验性法则能够解决您所遇到的99%的数值问题，剩下的那些可以通过实施或维度属性中的任一个来解决，也可以同时利用二者来解决。

3.1.1 事实表键
事实表是由一个多方键（multipart key）表示的，该多方键是有来自同一业务过程中若干相交维度表的外键所组成的。多方键意味着事实表通常描述的是多对多关系。
事实表中的每一个外键都必须对应维度表中的唯一主键。也就是说事实表的外键应当不为空，因为如果为空这违背了参照完整性。有事一个合法的度量事件中也会缺少维度值，如某个顾客在购买过程中没有使用常用的客户会员卡。这种情况下，事实表就应当参照能够表达“不是常客‘这一含义的客户维度中的某个特定键，来确定恰当的外键-主键值。
事实表的主键一般是维度表外键的子集。有时，事实表中唯一标示某一行的主键可能包含退化键。

3.1.2 事实表粒度
事实表的粒度是产生事实行的度量事件的业务定义。粒度确定了事实表的主键，而粒度本身是以业务术语表达的，要预先检查是否存在可能出现的外键。
事实表中的所有表都应当有统一的粒度。粒度是由数据源的物理实体所确定的，在您构想整个度量过程时，他的声明就已经明确了。在设计过程中，一旦粒度确定下来，就可以继续确定在细节层次上修饰度量的那些维度。按照先声明粒度在组织维度上下文这一逻辑顺序 进行维度设计师非常有益的，这也是维度设计过程中的一项重要特征。粒度就是您的锚点：维度设计中必须包含足够的维度上下文来实现粒度，而且你也必须将那些违背该粒度的维度上下文排除在外。
注意：提交的维度模型如果具有最细节的数据，那么久可能使模型就有最大的灵活性和可扩展性。如果在维度模型中遗漏了若干内容，就会破坏建立见状的商业智能所需要的基础。

3.1.3维度表
事实表仅由键和数值型度量所组成，因此他们具有健壮性和完整性的特点。与事实表不同，维度表不具有健壮性和完整性，他们当中充满了“大而笨重”的描述性字段。维度表的属性一般有两个主要用途：查询违约/过滤和标记查询结果集。很多情况下，数据仓库的功能都与维度属性的质量和深度成比例，健壮的维才能够产生健壮的查询和分析功能。
注意：您可以通过“按照-by”这个词来区分维度或其属性（如按照年、按照产品、按照区域等），在请求查询或报表时，业务人事经常使用这样的字眼。
维度属性一般都是文本字段，或者是作用和文本相同的离散数字。维度模型的优点在于所有的属性在成为过滤条件或者标记的时候都是等价的，维度属性应当具有以下特点：
·是冗长的（名字有完整词汇组成）
·是描述性的
·是完整型的（没有遗漏值）
·是离散取值的（维度表中的每一行进取一个值）
·质量是有保证的（没有错误拼写、不可能的取值、舍弃的值和同一属性的不同版本）
维度表几乎必然会用于表示层次关系，在一个单独的维里面解析截个多对一的层次关系的情况很常见，这也是返规范化的必然结果。例如，如果产品可以上卷到品牌，而品牌可以上卷到类别，就可以用一个单独的产品维度表来 表示该层次关系，该表中有和品牌及类别描述相对应的属性。我们认为这样的做法会在每个产品行都产生有关品牌和类别描述的冗余存储。尽管可以通过将品牌和类别解码存储在单独的维中，但这样做仍然会干扰可理解性和查询性能。

3.1.3.1 维度表键
尽管事实表有一个多方键，但唯独行确实由单一键字段唯一标示的。强烈建议维度表的主键应指定为从1开始的简单整数序列 ，这就是说我们为新的维度记录创建键时，仅需要在上一个值上加1就足够了。这些代理键（surrogate key）本身都是没有意义的，他们仅作为维度表和事实表之间的连接字段。
这样做有如下好处：
·性能高效
·运营键管理实践提供的缓冲。
·通过映射集成不同的数据源
·处理位置或者不适用的条件
·跟踪维度属性值的变化
  这里要说的是尽管维度表要比事实表稳定的多，但是他们仍然会改变，后面会讲解缓慢变化维，捕捉维度变化最常见和最合规的一种方法就是创建一个新的唯独行以表达新的属性特征，并且指派下一个可用的代理键作为其主键。

4、维度设计过程

1）选择业务过程

2）声明粒度
当在业务协商过程中定义事实表粒度时需要非常仔细，不要跳过这一步。粒度就是从业务角度对“准确来说，什么是事实表行？”这一问题做出的回答。

3）确定维
一旦事实表的粒度已经稳固地确定下来，对维的选择就相当简单了。也正是在此时，可以开始考虑外键的问题了。一般来说，粒度本身就能够确定一个基本的或者最小的维度集合，设计过程就是再此基础上添加其他维。这些维在已经声明的事实表粒度中都有一个唯一对应的值。

4）确定事实

5、面向部门的独立解决方案常常被称为数据集市。