学习还是得系统

《数据仓库工具箱》笔记：
1、每个业务过程对应企业数据仓库总线矩阵的一行，列表示维度。矩阵中的点表示维度与给定的业务过程是否存在关联关系。

2、雪花模型是当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。

3、文本注释维度
      与其将自由注释作为事实表的文本度量，不如将它们存储于事实表之外得不同的注释维度（或作为维度属性，每个事务一行，但需要注释的粒度满足唯一事务的数目），使该注释维度对应事实表中的一个外键。

4、SQL日期函数不支持以属性（例如，工作日与周末、假日、财务周期、季度）进行过滤。假定业务需要按照非标准的日期属性对日期分片，那么建立一个详尽的日期维度就是基本的需求。日历逻辑由维度表解决，而不是由应用代码来解决。

5、由于维度表属性用于报表和下拉式查询过滤列表中的值，所以该标识应该用有意义的值。标识采用越有意义的领域值，就越能够转换为有意义、能够自我解析的报表。与其在BI应用中将标识编码成难以理解的标识，不如将其编码为数据库中存储的可解释的值，这样它们能够对所有用户保持一致，无论是何种BI报表环境或工具。

6、数据仓库通过提供多维数据视图和汇总数据的预计算，数据仓库非常适合联机分析处理。联机分析处理操作使用数据的领域背景知识，允许在不同的抽象层提供数据。联机分析处理操作的例子包括下钻和上卷。他们允许用户在不同的汇总级别观察数据。在OLAP中下钻和上卷这两个术语用的真的是相当的贴切。
      例如，可以按照季度汇总的销售数据下钻，观察按月汇总的数据。也可以按城市汇总的销售数据上卷，观察按国家汇总的数据。这就是数据钻取的两个简单例子。

7、将重复的低粒度值保存在主维度表中是一种基本的维度建模技术。规范化这些值将其放入不同的表将难以实现简单化与高性能的主要目标。

8、作为属性或事实的数字值
      有时您可能会遇到某些数字值，很难判断应该将其归入维度属性分类，还是归入事实分类。经典的例子是产品的价格标准列表。产品价格很显然是个数字值，因此初始的想法可能是将其当成事实来对待。但是通常标准价格变化缓慢，不像其他事实表中的数量值，对不同的度量事件产生不同的值。
      如果某个数字值主要用于计算目的，则它可能应该属于事实表。因为标准价格是非可加的，可用它乘以数量获得扩展总额，这个值是可加的。另外，如果标准价格主要用于价格变化分析，也许变化度量应该被存储在事实表中。如果能预先定义稳定的数字值，用于过滤和分组，则它应该被当成产品维度属性对待。
      有时，数字值可同时用于计算以及过滤/分组功能。在此情况下，应当在事实表和维度表中同时存储该值。也许事实表中的标准价格表示销售事务的价格，而维度属性则标记为指示其当前情况的标准价格。
      可用于事实计算和维度约束、分组及标记的数据元素应该被保存在两个不同的位置。维度模型应尽可保持一致，应用开发应该简单可预见。涉及计算的数据应该放入事实表中，涉及约束、分组和标记的数据应该放入维度表中。

9、下钻维度属性
      合理的产品维度表可包含大约50个左右的描述性属性。每个属性可作为约束和构建行头指针标识的来源。下钻只不过是从维度表中请求行头指针以提供更多信息。上卷操作将移除行表头。

10、
floor plan: 楼层平面
zip code:邮递区号
square footage:面积；平方英尺
remodel: 重塑

11、多层次维度表
      上卷操作，要注意是否存在同值不同意的情况。如美国的城市和州不在一个层次上，但许多州都包含名称相同的城市，因此可能需要在商店维度中包含一个城市-州属性。

12、
promotion 促销活动
price reduction 价格降低
coupon (购物)优惠券

13、空外键、空属性和空事实
      如果将一个空值放在事实表中的已被声明为外键的列，则违背了参照完整性的要求。另外，参照完整性警告，包含空值的键是给用户带来困惑的主要原因，因为他们无法实现与空值的连接操作。正确的设计应在对应维度表中包括一行以表明该维度不可用于度量。
      当某一给定的维度行未被完全填充时，或者有些属性未被应用到所有维度行时，就会导致出现空值。我们建议用描述性字符串替换哪些空值，如 Unknown 或 Not Applicable 等。
      最后，有时我们可能在事实表中也会遇见空值。让事实表非空的方法可通过聚集函数处理，如 sum\min\max\count\avg等。如果用零值替换可能会使聚集计算产生倾斜。

14、过早地聚集和汇总限制了增加补充维度的能力，因为增加的维度通常无法在更高粒度级别上应用。

15、无事实的事实表
在关系世界中，关注什么未发生这样的问题需要促销范围或事件事实表。

16、维度表的唯一主键应该是代理键而不是来自于操作型系统的标识符，也就是所谓的自然键。代理键有许多其他的称谓：无意义键、整数键、非自然键、人工键和合成键等等。

17、维度中自然和持久的超自然键
      类似代理键，由操作型源系统分配和使用的自然键使用其他名称，例如，业务键、产品键和操作键等。在本书中，它们用NK标识表示。自然键通常被建模为维度表的属性。
      在跟踪维度表属性变化时，重要的是能够确定一个标识符用于唯一地和可靠地区分维度实体的属性变化。尽管操作型自然键适合做这一工作，有时出于不确定的业务规则（例如，组织合并）或要么处理重复条目要么从多源数据处理数据集成，自然键会发生变化。如果维度的自然键没有受到完全的保护和保存，ETL系统需要分配永久的持久性标识符，也被称为超自然键。持久的超自然键被DW/BI系统控制并在系统生命周期中保持不变。类似维度代理键，它是一种简单的整数序列分配方法。和自然键一样，持久的超自然键被当成维度属性处理，它不能作为维度表的代理主键的替换方法。

18、低粒度 和 高粒度
低粒度即高细节，高粒度即低细节。

19、事实表的代理键
      我们主张在维度表中使用代理键，但并未要求在事实表中一定使用代理键。事实表中的代理键通常只是对后端ETL处理有帮助。事实表的主键通常包括表外键的子集以及退化维度。

20、退化维度
      kimball书中描述退化维度如下：操作型事务控制号码，例如：订单号码、发票号码。退化维度是没有对应维度表的维度键。
维度退化在事实表中有利于使用，一般一个维度键都有对应的维表，如果退化在事实表中，可以减少关联次数，并且退化维可以用于group by操作，进行分组统计。

21、抵制规范化的冲动
      固定深度层次在维度表中应该被扁平化。规范化雪花模式维度表不利于多属性浏览并反感了位图索引的使用。通过规范化维度表所节省的磁盘空间通常不会超过整个模式所需要空间的1%。应该知道牺牲一些维度空间有利于改善性能和可用性。

22、包含大量维度的蜈蚣事实表
      即使有紧凑的格式，事实表也是维度模型中的巨兽。包含太多维度表的事实表设计，将导致事实表需要更多磁盘空间。尽管非规范化维度表需要额外的空间，但事实表仍然是最大的问题，因为事实表是最大的表，维度表与之比较不是一个数量级的。在蜈蚣表实例中，无法实现对多部份构成的键构建有效的索引。大量的连接无论是对可用性还是对性能来说都是一个问题。
      多数业务过程可以用不超过20个维度的事实表表示。如果某个设计有25个或更多维度，应该考虑才去措施合并关联的维度。具有良好关联的属性，例如，层次级别，以及具有统计相关性的属性，都应该放入一个维度中。在产生的新维度比不同维度的笛卡尔积小很多的情况下，可以考虑合并这些维度。

23、周期型快照
      通常可以接受的是在日级水平保存最后60天库存，然后回复到更细粒度的历史数据周快照。采用这样的方式，而不是在三年周期中保存1095个快照，数量将减少到208个总的快照，60天和148周快照将存储在两个具有不同周期的事实表中。