6. Kimball维度建模常用术语及概念(二)

文章目录

      • 维度表基础技术概念
        • 1. 维度表结构
        • 2. 自然键、持久性超自然键
        • 3. 下钻
        • 4. 退化维度
        • 5. 非规范化扁平维度
        • 6. 多层次维度
        • 7. 维度表中的空值属性
        • 8. 日历日期维度
      • 使用一致性维度
        • 1. 一致性维度
        • 2. 缩减维度
        • 3. 跨表钻取
        • 4. 价值链
        • 5. 企业数据仓库总线矩阵
      • 处理缓慢变化的维度
        • 1. 类型0:保留原样
        • 2. 类型1:重写
        • 3. 类型2:增加新行
        • 4. 类型3:增加新属性
        • 5. 类型4:增加微型维度
        • 6. 类型5:增加微型维度及类型1支架
        • 7. 类型6:增加类型1属性到类型2维度
        • 8. 类型7:双类型1和类型2维度
      • 处理维度层次关系
        • 1. 固定深度位置的层次
        • 2. 轻微参差不齐/可变深度层次
        • 3. 具有层次桥接表的参差不齐/可变深度层次
        • 4. 具有路径字符属性的可变深度层次

维度表基础技术概念

1. 维度表结构

  每个维度表都包含单一的主键列,且维度表的一行应与事实表行完全对应。
  维度表通常比较宽,是扁平型非规范表,包含大量的低粒度文本属性。操作代码可以作为属性看待。
  维度表属性是“查询”及“BI应用”的约束和筛选条件。

2. 自然键、持久性超自然键

  由不同业务系统建立的自然键受业务规则影响,无法被DW/BI系统控制。例如雇员的工号(自然键)可能会发生变化。而数仓系统希望为该雇员创建持久性不变的单一键,这就是持久性超自然键。最好的持久建应该独立于原始业务过程,并以整数1开始进行分配。

3. 下钻

  下钻仅需要在查询上增加一个行的头指针,指向一个维度属性,且属性可以来自任何与查询使用的事实表关联的维度。下钻不需要与现存在的层次定义。

4. 退化维度

  有时,维度除了主键外没有其他内容,例如订单编号、固有的操作型票据编号等,这些内容应该自然的放入事实表中,而不用连接到维度表。退化维度在事实表中是很常见的,订单号,发票号与提货单编号等几乎总是以退化维度的形式出现在维度模型之中。

5. 非规范化扁平维度

  维度设计者需要抵制由多年来关系数据库设计所带来的对规范化设计的要求,并将非规范化的深度层次存储为扁平维度行的不同属性。扁平维度能实现维度建模的双重目标:简化及速度。

6. 多层次维度

  多层次维度即一个维度中包含不止一个自然层次,例如日期维度存在天、周、月、年的层次。

7. 维度表中的空值属性

  当给定的维度行没有被全部填充时,或者当存在属性没有被应用到所有维度行时,推荐使用描述性字符串替代空值,如unknown、not applicable等。

8. 日历日期维度

  事实表关联的日历日期维度,使得事实度量能按日期、月份、财务周期、和日历上的特殊日期统计。相比关系数据库,我们无法用SQL计算复活节,但是可以在日历日期维度上寻找特定节日,因为日历日期维度通常包含许多描述,如周数、月份名称、国家假日等属性。
  为方便划分,日期维度的主键可以更有意义,例如用一个整数表示YYYYMMDD,而不是用自增主键。

使用一致性维度

1. 一致性维度

  当不同的维度表的属性具有相同的列名和业务内容时,称维度表具有一致性。利用一致性维度属性与每个事实表关联,可将来自不同事实表的信息合并到同一报表中。一致性维度是企业DW/BI系统的基础。

2. 缩减维度

  缩减维度是一种一致性维度,有基本维度的子集构成,当构建聚集事实表时需要缩减上卷维度。当业务过程需要获取粒度级别较高的数据时,也需要缩减维度。

3. 跨表钻取

  当每个查询的header包含相同的一致性维度时,就可以对两个或者多个事实表进行查询,这就是跨表钻取。

4. 价值链

  价值链指的是组织中某业务过程的组成。例如“分类账”的价值链包括:预算编制、承付款项、付款等;“销售商”的价值链包括购买、库存、零售额等。通常,数仓会为每个过程至少建立一个原子事实表。

5. 企业数据仓库总线矩阵

  企业数据仓库总线矩阵是用于设计并与企业数据仓库总线架构交互的基本工具。矩阵行表示业务过程,列表示维度。矩阵中的点表示维度与给定的业务过程是否存在关联关系。

处理缓慢变化的维度

1. 类型0:保留原样

  对类型0,维度属性值不会发生变化,因此事实表以原始值分组。例如,客户原始的信用卡积分等。该类型也适用于日期维度的大多数属性。

2. 类型1:重写

  对类型1,维度行中原来的属性值被新值覆盖。该类型属性总是反映最新的状态,但破坏了历史情况,使用时需要小心谨慎,可能会导致聚集事实表的重复计算。

3. 类型2:增加新行

  该类型是在维度表中增加新行,新行中采用修改的属性值。要实现该方式需要维度主键更具有一般性,不能仅采用自然键。
  该类型事件发生时,最少需要在维度行中增加三个额外列:行有效日期/时间戳列、行截止日期/时间戳列、当前行表示。

4. 类型3:增加新属性

  该类型将在维度表上增加新属性以保存原来版本的属性值,原属性以类型1的方式写入新版本的属性值。这种方式也被成为替换现实,且该方式并不常用。

5. 类型4:增加微型维度

  当维表是一个大型类型2的维度表时,如果某些维度属性变化相对较快,会导致该维表变得越来越大,加大存储和性能压力。
  此时引入类型4是一个不错的选择,将变化较快的维度属性从该大型维表中抽离出来,单独构建微型维度。比如将用户最近消费时间、消费频率、消费金额从用户维表中剥离出来,并结合业务以区间段形式表现,单独构建成微型维度,并在相关事实表中增加相应外键。

6. 类型5:增加微型维度及类型1支架

  采用类型4增加的微型维度外键,不仅保存在事实表中,也保存在主维度表中。在主维度中,此微型维度属性以类型1处理,即当该属性发生变化时,直接覆盖,不保留历史信息。
  该类型可以用于精准保存历史属性(即主维度中除微型维度之外的属性)。如某些维度,部分属性需要保存历史,而部分属性由于变化太过频繁,则不需要保存,此时可以将不需要保存且变化频繁的属性设计成类型4和类型1的叠加,需要精准保存的属性设计成类型2。

7. 类型6:增加类型1属性到类型2维度

  先以类型2的方式新增行,再以类型1的方式重写所有维度行的某属性列的值。这样,历史维度行中既有事实发生时的某些属性值,又有当前最新的某些属性值。用于处理特殊的,需要在一个维度行同时具备部分历史属性值和部分当前属性值的应用场景。

8. 类型7:双类型1和类型2维度

  该类型是用于支持过去和现在报表的最后一种混合技术。建模为类型1的维度表用于保存最新属性值,建模为类型2的维度表用于保存最新历史记录,而两个维度表的持久建均保存于事实表当中。

处理维度层次关系

1. 固定深度位置的层次

  固定深度层次是最容易理解和查询的层次关系,如从产品到品牌,再到部门。固定深度层次提供了可预测的,快速查询性能。

2. 轻微参差不齐/可变深度层次

  该类层次的深度不固定,但层次深度有限,比如地理层次深度通常包含3到6层,对待这种类型的深度层次,与其使用复杂的机制构建可变深度层次,不如取最大深度,将其变换为固定深度层次设计。

3. 具有层次桥接表的参差不齐/可变深度层次

  在关系数据库中,深度不确定的可变深度层次非常难以建模,一般的解决方法是通过在关系数据库中采用构建桥接表建模。

4. 具有路径字符属性的可变深度层次

  具有路径字符属性的可变深度层次可以直接当做字符串处理,但是在对路径做分析和替换时会稍显繁琐。

你可能感兴趣的:(数据仓库&维度建模,架构,数据仓库,维度建模)