Kimball维度建模技术概述

刘超 5天前 ⋅ 86 阅读   编辑

目录

  1、基本概念
  2、事实表技术基础
  3、维度表技术基础
  4、使用一致性维度集成
  5、处理缓慢变化维度属性
  6、处理维度层次关系
  7、高级事实表技术
  8、高级维度技术
  9、特殊目的模式

 

一、基本概念

  1、收集业务需求与数据实现
  开始维度建模工作前,项目组需要理解业务需求,以及作为基础的源数据的实际情况。通过与业务代表交流来发现需求,用于理解他们的基于关键性能指标、竞争性商业问题、决策制定过程、支持分析需求的目标。同时,数据实际情况可以通过与源系统专家交流,构建高层次数据分析访问数据可行性来揭示。

  2、协作维度建模研讨
  维度模型应该由主题专家与企业数据管理代表合作设计而成。工作由数据建模者负责,但模型应该通过与业务代表开展一系列高级别交互讨论获得。这些讨论组也为丰富业务需求提供了一种机会。维度模型不应该由那些不懂业务以及业务需求的人来设计,协作是成功的关键。

  3、4步骤维度设计过程
  维度模型设计期间主要涉及4 个主要的决策:
  (1) 选择业务过程
  (2) 声明粒度
  (3) 确认维度
  (4) 确认事实
  要回答上述问题, 需要考虑业务需求以及协作建模阶段涉及的底层数据源。按照业务过程、粒度、维度、事实声明的流程, 设计组确定表名和列名、示例领域值以及业务规则。而业务数据管理代表必须参与详细的设计活动,以确保涵盖正确的业务。

  4、业务过程
  业务过程是组织完成的操作型活动,例如,获得订单、处理保险索赔、学生课程注册或每个月每个账单的快照等。业务过程事件建立或获取性能度量, 并转换为事实表中的事实。多数事实表关注某一业务过程的结果。过程的选择是非常重要的,因为过程定义了特定的设计目标以及对粒度、维度、事实的定义。每个业务过程对应企业数据仓库总线矩阵的一行。

  5、粒度
  声明粒度是维度设计的重要步骤。粒度用于确定某一事实表中的行表示什么。粒度声明是设计必须履行的合同。在选择维度或事实前必须声明粒度,因为每个候选维度或事实必须与定义的粒度保持一致。在所有维度设计中强制实行一致性是保证BI应用性能和易用性的关键。在从给定的业务过程获取数据时,原子粒度是最低级别的粒度。我们强烈建议从关注原子级别粒度数据开始设计, 因为原子粒度数据能够承受无法预期的用户查询。上卷汇总粒度对性能调整来说非常重要, 但这样的粒度往往要猜测业务公共问题。针对不同的事实表粒度,要建立不同的物理表,在同一事实表中不要混用多种不同的粒度。

  6、描述环境的维度
  维度提供围绕某一业务过程事件所涉及的"谁、什么、何处、何时、为什么、如何"等背景。维度表包含Bl 应用所需要的用于过滤及分类事实的描述性属性。牢牢掌握事实表的粒度,就能够将所有可能存在的维度区分开。当与给定事实表行关联时,任何情况下都应使维度保持单一值。
  维度表有时被称为数据仓库的" 灵魂",因为维度表包含确保DW/BI系统能够被用作业务分析的入口和描述性标识。主要的工作都放在数据管理与维度表的开发方面, 因为它们是用户BI经验的驱动者。

  7、用于度量的事实
  事实涉及来自业务过程事件的度量,基本上都是以数量值表示。一个事实表行与按照事实表粒度描述的度量事件之间存在一对一关系, 因此事实表对应一个物理可观察的事件。在事实表内,所有事实只允许与声明的粒度保持一致。例如,在零售事务中,销售产品的数量与其总额是良好的事实,然而商店经理的工资不允许存在于零售事务中。

  8、星型模式与OLAP多维数据库
  星型模式是部署在关系数据库管理系统(RDBMS)之上的多维结构。典型地,主要包含事实表,以及通过主键/外键关系与之关联的维度表。联机分析处理(OLAP) 多维数据库是实现在多维数据库之上的多维结构,它与关系型星型模式内容等价,或者说来源于关系型星型模式。OLAP多维数据库包含维度属性和事实表,但它能够使用比SQL语言具有更强的分析能力的语言访问,例如,XMLA和MDX等。OLAP多维数据库包含在基本技术的列表中,因为OLAP多维数据库通常是部署维度DW/BI系统的最后步骤,或者作为一种基于多个原子关系型星型模式的聚集结构。

  9、方便地扩展到维度模型
  维度模型对数据关系发生变化具有灵活的适应性。当发生以下所列举的变化时,不需要改变现存的BI 查询或应用, 就可以方便地适应,且查询结果不会有任何改变。
  a、当事实与存在的事实表粒度一致时,可以创建新列。
  b、通过建立新的外键列,可以将维度关联到己经存在的事实表上,前提是维度列与事实表粒度保持一致。
  c、可以在维度表上通过建立新列添加属性。
  d、可以使事实表的粒度更原子化,方法是在维度表上增加属性, 然后以更细的粒度重置事实表,小心保存事实表及维度表的列名。

二、事实表技术基础

  1、事实表结构
  发生在现实世界中的操作型事件,其所产生的可度量数值,存储在事实表中。从最低的粒度级别来看, 事实表行对应一个度量事件,反之亦然。因此, 事实表的设计完全依赖于物理活动,不受可能产生的最终报表的影响。除数字度量外, 事实表总是包含外键, 用于关联与之相关的维度,也包含可选的退化维度键和日期/时间戳。查询请求的主要目标是基于事实开展计算和聚集操作。

  2、可加、半可加、不可加事实
  事实表中的数字度量可划分为三类。
  a、最灵活、最有用的事实是完全可加 ,可加性度量可以按照与事实表关联的任意维度汇总。
  b、半可加度量可以对某些维度汇总,但不能对所有维度汇总。差额是常见的半可加事实,除了时间维度外,它们可以跨所有维度进行加法操作。
  c、另外, 一些度量是完全不可加的,例如,比率。
  对非可加事实, 一种好的方法是,尽可能存储非可加度量的完全可加的分量, 并在计算出最终的非可加事实前, 将这些分量汇总到最终的结果集合中。最终计算通常发生在BI层或OLAP多维数据库层。

  3、事实表中的空值
  事实表中可以存在空值度量。所有聚集函数(SUM 、COUNT 、MIN 、MAX 、AVG)均可针对空值事实计算。然而,在事实表的外键中不能存在空值,否则会导致违反参照完整性的情况发生。关联的维度表必须用默认行(代理键)而不是空值外键表示未知的或无法应用的条件。

  4、一致性事实
  如果某些度量出现在不同的事实表中,需要注意, 如果需要比较或计算不同事实表中的事实,应保证针对事实的技术定义是相同的。如果不同的事实表定义是一致的,则这些一致性事实应该具有相同的命名,如果它们不兼容,则应该有不同的命名用于告诫业务用户和BI应用。

  5、事务事实表
  事务事实表的一行对应空间或时间上某点的度量事件。原子事务粒度事实表是维度化及可表达的事实表,这类健壮的维度确保对事务数据的最大化分片和分块。事务事实表可以是稠密的,也可以是稀疏的,因为仅当存在度量时才会建立行。这些事实表总是包含一个与维度表关联的外键,也可能包含精确的时间戳和退化维度键。度量数字事实必须与事务粒度保持一致。

  6、周期快照事实表
  周期快照事实表中的每行汇总了发生在某一标准周期,如某一天、某周、某月的多个度量事件。粒度是周期性的,而不是个体的事务。周期快照事实表通常包含许多事实,因为任何与事实表粒度一致的度量事件都是被允许存在的。这些事实表其外键的密度是均匀的,因为即使周期内没有活动发生,也会在事实表中为每个事实插入包含0或空值的行。

  7、累积快照事实表
  累积快照事实表的行汇总了发生在过程开始和结束之间可预测步骤内的度量事件。管道或工作流过程(例如,履行订单或索赔过程)具有定义的开始点,标准中间过程,定义的结束点,它们在此类事实表中都可以被建模。通常在事实表中针对过程中的关键步骤都包含日期外键。累积快照事实表中的一行,对应某一具体的订单,当订单产生时会插入一行。当管道过程发生时,累积事实表行被访问井修改。这种对累积快照事实表行的一致性修改在三种类型事实表中具有特性, 除了日期外键与每个关键过程步骤关联外,累积快照事实表包含其他维度和可选退化维度的外键。通常包含数字化的与粒度保持一致的,符合里程碑完成计数的滞后性度量。

  8、无事实的事实表
  尽管多数度量事件获取的结果是数字化的,但也存在某些事件仅仅记录一系列某一时刻发生的多维实体。例如,在给定的某一天中发生的学生参加课程的事件,可能没有可记录的数字化事实,但该事实行带有一个包含日历天、学生、教师、地点、课程等定义良好的外键。同样,客户交际也是一种事件,但没有相关的度量。利用无事实的事实表也可以分析发生了什么。这类查询总是包含两个部分:包含所有可能事件的无事实覆盖表,包含实际发生的事件的活动表。当活动从覆盖表中减除时,其结果是尚未发生的事件。

  9、聚集事实表或OLAP多维数据库
  聚集事实表是对原子粒度事实表数据进行简单的数字化上卷操作,目的是为了提高查询性能。这些聚集事实表以及原子事实表可以同时被BI层使用,这样BI工具在查询时可以平滑地选择适当的聚集层次。这一被称为聚集导航的过程是开放的,以便报表制作者、查询工具、BI应用都能够获得同样的性能优势。适当设计的聚集集合应该类似数据库索引,能够提高查询性能,但不需要直接面对BI 应用或商业用户。聚集事实表包含外键以缩小一致性维度,聚集事实的构建是通过对来自多个原子事实表的度量的汇总而获得的。最后,使用汇总而度量聚集OLAP多维数据库一般与关系类型的聚集方法类似,但是OLAP多维数据库可以被商业用户直接访问。

  10、合并事实表
  通常将来自多个过程的,以相同粒度表示的事实合并为一个单一的合并事实表,这样做能够带来方便。例如,现货销售可以与销售预测合并为一张事实表,与针对多个不同的非实表采用下钻应用比较,这样做可使对现货及预测任务的分析工作变得简单快捷。合并事实表会增加ETL处理过程的负担,但降低了BI 应用的分析代价。合并事实表特别适合那些经常需要共同分析的多过程度量。

三、维度表技术基础

  1、维度表结构
  每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键,当然,维度表行的描述环境应与事实表行完全对应。维度表通常比较宽,是扁平型非规范表,包含大量的低粒度的文本属性。操作代码与指示器可作为属性对待,最强有力的维度属性采用冗氏的描述填充。维度表属性是查询及BI应用的约束和分组定义的主要目标。报表的描述性标识通常是维度表属性领域值。

  2、维度代理键
  维度表中会包含一个列,表示唯一主键。该主键不是操作型系统的自然键,由于需要跟踪变化,因此若采用自然键,将需要多个维度行表示。另外,维度的自然健可能由多个源系统建立,这些自然键将出现兼容性问题,难以管理。DW/BI系统需要声明对所有维度的主键的控制,而无法采用单一的自然键或附加日期的自然键,可以为每个维度建立无语义的整型主键。这些维度代理键是按顺序分配的简单整数,以值1 始。每当需要新键时,键值自动加l。日期维度不需要遵守代理键规则,日期维度是高度可预测的且稳定的维度,可以采用更有意义的主键。

  3、自然键、持久键和超自然键
  由操作型系统建立的自然键受业务规则影响,无法被DW/BI系统控制。例如,如果雇员辞职,然后重新工作,则雇员号码(自然键)可能会发生变化。数据仓库希望为该雇员创建单一键,这就需要建立新的持久键以确保在此种情况下,雇员号保持持久性不会发生变化。该键有时被称为持久性超自然键。最好的持久键其格式应该独立于原始的业务过程,并以整数l开始进行分配。多个代理键与某一个雇员关联时,若描述发生变化时,持久键不会变化。

  4、下钻
  下钻是商业用户分析数据的最基本的方法。下钻仅需要在查询上增加一个行头指针。新行的头指针是一个维度属性,附加了SQL 语言的GROUP BY 表达式。属性可以来自任何与查询使用的事实表关联的维度。下钻不需要预先存在层次的定义,或者是下钻路径。

  5、退化维度
  有时,维度除了主键外没有其他内容。例如, 当某一发票包含多个数据项时,数据项事实行继承了发票的所有描述性维度外键,发票除了外键外无其他工页。但发票数量仍然是在此数据项级别的合法维度键。这种退化维度被放入事实表中,清楚地表明没有关联的维度表。退化维度常见于交易和累计快照事实表中。

  6、非规范化扁平维度
  一般来说,维度设计者需要抵制由多年来操作型数据库设计所带来的对规范化设计的要求,并将非规范化的多对一固定深度层次引入扁平维度行的不同属性。非规范化维度能够实现维度建模的双重目标: 简化及速度。

  7、多层次维度
  多数维度包含不止一个自然层次。例如,日历日期维度可以按照财务周期层次从天到周进行划分,也可能存在从天到月再到年的层次。位置密集型维度可能包含多个地理层次。所有这些情况下,在同一维度中可以存在不同的层次。

  8、文档属性的标识与指示器
  令人迷惑的缩写、真/假标识以及业务指标可以作为维度表中文本字词含义的补充解释。操作代码值所包含的意义应分解成不同的表示不同描述性维度属性的部分。

  9、维度表中的空值属性
  当给定维度行没有被全部填充时,或者当存在属性没有被应用到所有维度行时,将产生空值维度属性。上述两种情况下,我们推荐采用描述性字符串替代空值。例如,使用Unknown 或Not Applicable 替换空值。应该避免在维度属性中使用空值,因为不同的数据库系统在处理分组和约束时,针对空值的处理方法不一致。

  10、日历日期维度
  连接到实际事实表的日历日期维度,使得能够对事实表,按照熟悉的日期、月份、财务周期和日历上的特殊日期进行导航。不要指望能够用SQL计算复活节,但可以在日历日期维度上寻找复活节。日历日期维度通常包含许多描述,例如,周数、月份名称、财务周期、国家假日等属性。为方便划分,日期维度的主键可以更有意义,例如,用一个整数表示YYYYMMDO ,而不是用顺序分配的代理键。然而,日期维度表需要特定的行表示未知或待定的日期。若需要更详细的精确度,可以在事实表中增加不同的日期时间戳。日期时间戳并不是维度表的外健,但以单独列的形式存在。如果商业用户按照当天时间(time-of-day)属性进行约束或分组,例如,按当天时间或其他数字分组,则需要在事实表上增加一个"当天时间(time -of-day) "维度外键。

  11、扮演角色的维度
  单个物理维度可以被事实表多次引用,每个引用连接逻辑上存在差异的角色维度。例如, 事实表可以有多个日期,每个日期通过外键表示不同的日期维度,原则上每个外键表示不同的日期维度视图,这样引用具有不同的含义。这些不同的维度视图(唯一的属性列名)被称为角色。

  12、杂项维度
  事务型商业过程通常产生一系列混杂的、低粒度的标识和指示器。与其为每个标识或属性定义不同的维度,不如建立单独的将不同维度合并到一起的杂项维度。这些维度,通常在一个模式中标记为事务型概要维度,不需要所有属性可能值的笛卡尔积,但应该只包含实际发生在源数据中的合并值。

  13、雪花维度
  当维度表中的层次关系是规范的时,低粒度属性作为辅助表通过属性键连接到基本维度表。当这一过程包含多重维度表层次时,建立的多级层次结构被称为雪花模式。尽管雪花模式可精确表示层次化的数据,但还是应该避免使用雪花模式,因为对商业用户来说,理解雪花模式并在其中查询是非常困难的。雪花模式还会影响查询性能。扁平化的、非规范的维度表完全能够获得与雪花模式相同的信息。

  14、支架维度
  维度可包含对其他维度的引用。例如,银行账户维度可以引用表示开户日期的维度。这些被引用的辅助维度称为支架维度。支架维度可以使用,但应该尽量少用。多数情况下,维度之间的关联应该由事实表来实现。在事实表中通过两个维度的不同外键相关联。

四、使用一致性维度集成

  维度建模方法最成功的方面之一就是为集成来自不同商业过程的数据而定义了简单而强大的解决方案。

  1、一致性维度
  当不同的维度表的属性具有相同列名和领域内容时,称维度表具有一致性。利用一致性维度属性与每个事实表关联,可将来自不同事实表的信息合并到同一报表中。当一致性属性被用作行头(就是说,用作SQL查询中的分组列) 时,来自不同事实表的结果可以排列到跨钻报表的同一行中。以上实现是集成企业DW/BI系统的基础。一致性维度一旦在与业务数据管理方共同定义后,就可以被所有事实表重用。该方法可获得分析一致性并减少未来开发的开销,因为不需要重新创建。

  2、缩减维度
  缩减维度是一种一致性维度,由基本维度的列与(或)行的子集构成。当构建聚集事实表时需要缩减上卷维度。当商业过程自然地获取粒度级别较高的数据时,也需要缩减维度,例如某个按月和品牌进行的预测(不需要与销售数据关联的更原子级别的数据和产品)。另外一种情况下,也就是当两个维度具有同样粒度级别的细节数据, 但其中一个仅表示行的部分子集时,也需要一致性维度子集。

  3、跨表钻取
  简单地说,跨表钻取意思是当每个查询的行头包含相同的一致性属性时,使不同的查询能够针对两个或更多的事实表进行查询。来自两个查询的回答集合将针对公共维度属性行头,通过执行排序-融合操作实现排列。BI工具提供商对这些功能有多种不同的命名方法,包括编织和多遍查询等。

  4、价值链
  价值链用于区分组织中主要业务过程的自然流程。例如,销售商的价值链可能包括购买、库存、零售额等。一般的分类账价值链可能包括预算编制、承付款项、付款等。操作型源系统通常为价值链上的每个步骤建立事务或快照。因为每个过程在特定时间间隔, 采用特定的粒度和维度建立唯一的度量,所以每个过程通常至少建立一个原子事实表。

  5、企业数据仓库总线架构
  企业数据仓库总线架构提供一种建立企业DW/BI 系统的增量式方法。这一架构通过关注业务过程将DW/BI规划过程分解为可管理的模块,通过重用跨不同过程的标准化一致性维度发布实现集成。企业数据仓库总线架构提供了一种架构性框架,同时也支持可管理敏捷实现对应企业数据仓库总线矩阵。总线架构中技术与数据库平台是独立的,无论是关系数据库或者是OLAP维度结构都能参与其中。

  6、企业数据仓库总线矩阵
  企业数据仓库总线矩阵是用于设计并与企业数据仓库总线架构交互的基本工具。矩阵的行表示业务过程, 列表示维度。矩阵中的点表示维度与给定的业务过程是否存在关联关系。设计小组分析每一行,用于测试是否为业务过程定义好相关的候选维度,同时也能分析每个列,考虑某一维度需要跨多个业务过程并保持一致性。除技术设计细节外,当设计小组实现矩阵中的某行时,总线矩阵还可用作输入帮助确定优先处理DW/BI项目过程管理。

  7、总线矩阵实现细节
  总线矩阵实现细节是一个更加粒度化的总线矩阵,其中扩展每个业务过程行以展示特定事实表或OLAP多维数据库。在此细节粒度上,可以文档化精确的粒度描述以及事实列表。

  8、机会/利益相关方矩阵
  在确定了企业数据仓库总线矩阵行之后,可以通过替换包含业务功能(例如,市场、销售、财务等)的维度列规划不同的矩阵。通过确定矩阵点以表示哪些业务功能与哪些业务过程行相关。机会/利益相关方矩阵可用于区分哪些业务过程分组应该与过程中心行相关。

五、处理缓慢变化维度属性

  这里描述处理缓慢变化维度(Slowly Changing Dimension, SCD)属性的基本方法。对同一维度表中属性的变化,采用不同的变化跟踪技术是比较常见的方法。

  1、类型0: 原样保留
  对类型0 ,维度属性值不会发生变化, 因此事实表以原始值分组。类型0适合属性标记为"原型"的情况。例如,客户原始的信用卡积分或持久型标识符。该类型也适用于日期维度的太多数属性。

  2、类型1 :重写
  对类型1 ,维度行中原来的属性值被新值覆盖。类型l属性总是反映最近的工作, 因此该技术破坏了历史情况。尽管该方法易于实现且不需要建立额外的维度行,但使用时需小心,因为受此影响的聚集事实表和OLAP多维数据库将会重复计算。

  3、类型2: 增加新行
  对类型2 ,将在维度表中增加新行,新行中采用修改的属性值。要实现该方式需要维度主键更具有一般性,不能仅采用自然键或持久键,因为采用该方法时经常会出现多行描述同样成员的情况。在为维度成员建立新行时,将为其分配新的主代理键,在修改发生后,将其作为所有事实表的外键,直到后续变化产生新维度键并更新维度行。当变化类型2发生时,最少需要在维度行中增加三个额外列: ①行有效的日期/时间戳列:②行截止日期/时间戳列:③当前行标识。

  4、类型3: 增加新属性
  对类型3 ,将在维度表上增加新属性以保存原来的属性值,新属性值以变化类型l方式重写主属性。这种类型3变化有时称为替换现实。商业用户可以利用当前值或替换现实来分组或过滤事实数据。此种缓慢变化维度技术不太常用。

  5、类型4: 增加微型维度
  对类型4 ,当维度中的一组属性快速变化并划分为微型维度时采用。此种情况下的维度通常被称为快速变化魔鬼维度。通常在包含几百万行的维度表中使用的属性是微型维度设计的候选,即使它们并不经常变化。变化类型4 微型维度需要自己的唯一主键, 基维度和微型维度主键从相关的事实表中获取。

  6、类型5: 增加微型维度及类型1支架
  对类型5 ,用于精确保存历史属性值,按照当前属性值,增加报表的历史事实。类型5建立在类型4微型维度之上,并嵌入当前类型l引用基维度中的微型维度。这样才能确保当前分配的微型维度属性能够与基维度上其他微型维度一起被访问,而不必通过事实表连接。逻辑上说,应该将基维度及微型维度支架表示为展现区域中的单一表。每当当前微型维度分配发生变化时, ETL小组需要重写类型l微型维度引用。

  7、类型6: 增加类型1 属性到类型2 维度
  与类型5 类似,类型6 也保存历史和当前维度属性值。类型6 建立在类型2 的基础上,同时嵌入维度行属性的当前类型l 版本,因此事实行可以被过滤或分组,要么按照当度量发生时有效的类型2 属性值,要么按照、属性的当前值。在此环境中, 当属性发生变化时,类型1属性由系统自动重写与特定持久键关联的所有行。

  8、类型7: 双类型1和类型2维度
  类型7是用于支持过去和现在报表的最后一种混合技术。事实表可以被访问,通过被建模为类型l 维度仅仅展示最新属性值,建模为类型2 维度展示最新历史概要。同样的维度表确保实现两方面的观点。维度的持久键和主代理键同时存在事实表上。从类型l 角度看, 维度的当前标识被约束至当前,通过持久键与事实表连接。从类型2 角度看,当前标识无约束,事实表通过代理键主键连接。此两种方法可以按照不同的视图部署到BI 应用上。

六、处理维度层次关系

  维度往往存在层次关系。描述处理层次关系的方法,从最基本的情况开始讨论。

  1、固定深度位置的层次
  固定深度层次是多对一关系的一种,例如,从产品到品牌,再到分类,到部门。当固定深度层次定义完成后,层次就具有商定的名字,层次级别作为维度表中的不同位置属性出现。只要满足上述条件,固定深度层次就是最容易理解和查询的层次关系,固定层次也能够提供可预测的、快速的查询性能。当层次不是多对一关系,或层次的深度不定,以致层次没有稳定的命名时,就需要接下来将描述的非固定层次技术。

  2、轻微参差不齐/可变深度层次
  轻微参差不齐层次没有固定的层次深度,但层次深度有限。地理层次深度通常包含3到6层。与其使用复杂的机制构建难以预测的可变深度层次,不如将其变换为固定深度位置设计,针对不同的维度属性确立最大深度,然后基于业务规则放置属性值。

  3、具有层次桥接表的参差不齐/可变深度层次
  在关系数据库中,深度不确定的可变深度层次非常难以建模。尽管SQL扩展和OLAP访问语言对递归父子关系提供了一些支持,但方法极为有限。采用SQL 扩展,在查询时,不能替换参差不齐层次,不支持对自身层次结构的共享,同时也不支持随时间变化的参差不齐层次。以上所有问题可以通过在关系数据库中采用构建桥接表方式建模参差不齐层次米解决。这样的桥接表对每个可能的路径保留一行,确保能够遍历所有层次的形式,采用标准SQL 而不是用特定语言扩展来实现。

  4、具有路径字符属性的可变深度层次
  可以在维度中采用路径字符属性,以避免使用桥接表表示可变深度层次。对维度中的每行,路径字符属性包含特定的嵌入文本字符,包含从层次最高节点到特定维度行所描述节点的完整路径描述。多数标准层次分析需求可以通过标准SQL处理,不必采用SQL语言扩展。然而,路径字符方法不能确保其他层次的快速替换,也无法保证共享自身层次。路径字符方法也难于构建可变路径层次的变化,可能需要重新标记整个层次。

七、高级事实表技术

  1、事实表代理键
  代理键可用作所有维度表的主键。此外,可使用单列代理,事实键,尽管不太需要。不任何维度关联的事实表代现键,是在ETL加载过程中顺次分配的,可用于①作为事实表的唯一主键列: ②在ETL中,用作事实表行的直接标识符,不必查询多个维度: ③允许将事实表更新操作分解为风险更小的插入和删除操作。

  2、蜈蚣事实表
  一些设计者为多对一层次的每层建立不同的规范化维度,例如,日期维度、月份维度、季度维度和年维度等,并将所有外键包含在一个事实表中。这将产生娱蛤事实表,包含与维度相关的多个维度。应该避免使用娱蛤事实表。所有这些固定深度的、多对一层次化关联的维度都应该回到它们最细节的粒度上,例如,上例中提到的日期。当设计者将多个外键嵌入到单一低粒度维度表中,而不是建立杂项维度时,也会产生娱蛤事实表。

  3、属性或事实的数字值
  设计者有时会遇到一些数字值,难以确定将这些数字值分类到维度表或是事实表的情况。典型的实例是产品的标准价格。如果该数字值主要用于计算目的,则可能属于事实表。如果该数字值主要用于确定分组或过滤, 则应将其定义为维度属性,离散数字值用值范围属性进行补充(例如,O$~50$) 。某些情况下,将数字值既建模为维度又建模为属性是非常有益的,例如,定量准时交货度量以及定性文本描述符。

  4、日志/持续时间事实
  累积快照事实表获取多个过程里程碑,每个都包含日期外键并可能包含日期/时间戳。商业用户通常希望分析这些里程碑之间的滞后及延迟时间。有时这些延迟仅仅是日期上的差异, 但某些情况下,延迟可能基于更复杂的业务规则。如果流水线包含大量的步骤,则可能存在上百个延迟。与其要求用户查询通过日期/时间戳或者日期维度外键计算每个可能存在的延迟,不如根据过程的开始时间点为每个度量步骤存储一个时间延迟。这样做可以方便地通过利用存储在事实表中的两个延迟, 简单地用减法计算任何两个步骤间可能存在的延迟。

  5、头/行事实表
  操作型交易系统通常包括事务头指针行,头指针行与多个事务行关联。采用头/行模式(也称为父/子模式),所有头指针级别维度外键与退化维度应该被包含在行级别事实表。

  6、分配的事实
  头指针/行事务数据与对应的事实具有不同粒度这样的情况经常发生,例如,头表示货运费用。应该尽量分配头指针事实,使其基于业务所提供的规则划分为行级别,分配的事实可以按照所有维度进行分片并上钻操作。多数情况下,可避免建立头指针级别的事实表,除非这样的聚集能够获得查询性能的改善。

  7、利用分配建立利润与损失事实表
  事实表揭示利润等价方程是企业DW/BI 应用能够发布的最强大的结果。利润方程是:收入-开销=利润。理想地实现利润方程的事实表应为原子收入事务粒度并包含许多开销项。因为这些表处于原子粒度,才能实现数字化的上卷,包括客户利润,产品利润,促销利润,渠道利润等。然而,建立这些事实表存在一定难度,因为开销项必须从其原始来源划分到事实表粒度。这一分配步骤通常由ETL子系统完成,这一过程是一个与业务相关的步骤,需要高层经理的支持。出于以上原因,利润与损失事实表通常在DW/BI程序的早期实现阶段不会被处理。

  8、多种货币事实
  以多种货币单位记录财务事务的事实表行应该包含一对列。其中一列包含以真实币种表示的事实, 另外一列包含同样的,但以整个事实表统一的单一标准币种表示的事实。标准币种值在ETL 过程中按照规定的货币转换规则建立。该事实表也必须有一个货币维度用于区分事务的真正货币。

  9、多种度量事实单位
  某些业务过程需要事实同时以多种度量单位表示。例如,按照业务用户的观点,供应链可能需要对相同事实以平台、船运、零售以及单个扫描单元构建报表。如果事实表包含大量事实,而每个事实都必须以所有度量单位表示,此时较好的方法是将事实以公认的标准度量单位存储,同时存储标准度量与其他度量的转换系数。这种事实表可按照不同用户的观点部署,使用适当选择的转换系数。转换系数必须存储在事实表行中以确保计算简单正确,并尽量降低查询复杂性。

  10、年-日事实
  商业用户在事实表中通常需要年-日(year-to-date ,YTD)值。很难反对单个请求,但是YTD 请求很容易变换为"财务周期结束时的YTD" 或者"财务周期日"。一种更可靠、可扩展的处理这些请求的方法是在BI应用或OLAP多维数据库中计算YTD矩阵,而不是在事实表中查出YTD事实。

  11、多遍SQL以避免事实表间的连接
  BI 应用绝不应该跨事实表的外键处理两个事实表的连接操作。在关系数据库中,控制此类连接操作的回答集的基数是不可能的,将会产生不正确的结果。例如,如果两个事实表包含客户产品出货和返回,则这两个表不能按照客户和产品外键直接连接。要采用跨钻方式使用两个事实表,并对结果按照公共行头指针属性值,进行排序-融合操作以产生正确结果。

  12、针对事实表的时间跟踪
  存在三种基本事实表粒度: 事务级别、周期快照和累积快照。个别情况下,在事实表中增加行有效时期、行截止日期和当前行标识是非常有用的,与采用类型2 缓慢变化维度,在事实行有效时获取时间的方式类似。尽管不太常用, 但该模型能够解决诸如缓慢变化库存平衡的场景,其中频繁周期快照可以在每个快照上加载同一行。

  13、迟到的事实
  迟到事实是指如果用于新事实行的多数当前维度内容无法匹配输入行的情况。这通常发生在当事实行延迟产生时。在此情况下, 当迟到度量事件出现时,必须搜索相关维度以发现有效的维度键。

八、高级维度技术

  1、维度表连接
  维度表可以包含到其他维度表的引用。尽管此类关系可以采用支架维度建设实现,但某些情况下,存在于基本维度上的指向支架维度的外键的存在将导致基本维度爆炸性增长,因为支架表中的类型2变化强制需要在基本维度表中对应处理类型2变化。如果通过将支架表中的外键放入事实表中而不是放置在基本维度表中,降低维度表之间的关联,则此类增长通常可被避免。该方法意味着发现维度之间的关联,仅需要通过遍历事实表,这是可以接受的,特别是当事实表示周期快照,其所有维度的所有键都会在每个报表周期内出现。

  2、多值维度与桥接表
  经典维度模型中,每个与事实表关联的维度都有一个与事实表粒度一致的单一值。但是某些情况下,维度存在合理的多值。例如,某个病人接受了一次健康体检,可能同时出现多个诊断。在此情况下,多值维度必须通过一组维度键通过桥接表使一组中的每个诊断与事实表一行关联。

  3、随时间变化的多值桥接表
  多值桥接表可能需要基于缓慢变化类型2维度。例如,实现银行账户与单独客户的多对多关系的桥接表,通常必须基于类型2的账户与客户维度。在此情况下,为防止账户与客户之间的不正确连接,桥接表必须包含有效期和截止日期/时间戳,请求的应用必须约束桥接表,使其满足特定时刻以产生一致的快照。

  4、标签的时间序列行为
  数据仓库中几乎所有的文本都是维度表中的描述性文本。数据挖掘客户聚类分析通常产生文本化的行为标签,通常可以用作区分周期。在此情况下,跨时间范围的客户行为度量成为由这些行为标签构成的一种序列,该时间序列应该以位置属性被存储在客户维度中,包含可选文本串,构成完整的序列标签。行为标签在位置设计时建立,因为行为标签是复杂并发查询而不是数字计算的目标。

  5、行为研究分组
  有时可以通过执行多次迭代分析,来发现复杂的客户行为。在此情况下,将行为分析嵌入到BI应用,以约束所有客户维度的成员,获得复杂的行为,这样的做法是不现实的。复杂行为分析的结果,可以通过某些简单表获取,这些表成为研究分组,仅包含客户的持久键。在查询时,通过约束研究组表的列与目标模式中客户维度的持久键,该静态表可当成一种可应用于任何带有客户维度的维度模式的过滤器。可以定义多个研究组,导出的研究组可以通过遍历、联合、设置差异等方式建立。

  6、聚集事实作为维度属性
  商业用户通常对于基于聚集性能度量的客户维度感兴趣,例如,过滤去年或整个阶段所有花费超过一定数额的客户。选择聚集事实可以放入作为约束和作为行为标识报表的目标维度。度量通过表示为维度表中的带状范围。维度属性表示聚集性能度量将增加ETL处理负担,但是可以方便BI应用层的分析功能。

  7、动态值范围
  动态值范围报表由一系列报表行头组成,这些报表行头为目标数字化事实定义了范围不断变化的集合。例如,一个银行的公共值范围报表包含带有标签的多个行,例如从“从0$到$10的平账”,”从$10.01到$25的平账“等等。此类报表是动态报表,因为每次查询时都定义了特定的行头,而不是在ETL过程中定义的。行定义可以通过在小值范围维度表实现,通过大于连接或小于连接而与事实表实现连接,定义可以仅存在于SQL CASE语句中。该值范围维度方法可能获得更高的性能,特别是针对列数据库,因为CASE语句方法包含针对几乎所有事实表的无约束关系扫描。

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

  9、多时区
  为在多时区应用中获得通用标准时间以及本地时间,应该在受影响的事实表中设置双外键,用以连接两个不同角色的日期(和可能的当天时间(time-of-day))维度表。

  10、度量类型维度
  有时当事实表每行包含一长列存储的事实时,可以建立度量类型维度,通过度量类型维度将事实表行变成单一通用事实。我们一般不推荐采用该方法。尽管它消除了所有空的事实表列,但按照每行中占用列的平均数量,这增加了事实表大小,并且使内部列的计算更加困难。当潜在事实的数量达到极限(几百个),但是没有多少需要应用到任何给定事实表行时,可以采用该技术。

  11、步骤维度
  序列过程(例如,web页事件)通常在事务事实表中用不同行表示过程中的每一步。为了告知哪个步骤满足整个回话,使用步骤维度展示当前步骤的步骤号以及完成该会话共有多少步骤。

  12、热交换维度
  当同一个事实表与相同维度的不同拷贝交换搭配时,可使用热交换维度。例如,某事实表包含股票行情,可以同时展示给不同的投资人,不同的投资人对不同的股票有不同的属性要求。

  13、抽象通用维度

  一些建模者喜欢使用抽象通用维度。例如,他们的模式包含单一通用位置维度而不是关于商店、仓库和客户维度的嵌入式的地理属性。类似地,其人员维度包含雇员、客户和供应商行,因为尽管每种类型都包含显然不同的属性,但他们都是人。在维度建模时应尽量避免使用抽象通用维度。与每种类型关联的属性集合通常存在差异。如果属性是通用的,例如,地理州,应将它们唯一标识以区分商店所在州与客户所在州。最后,将所有不同的位置、人员、产品放入单一维度将产生大型的维度表。数据抽象可以适当运用于操作型源系统或ETL 处理,但对查询性能有负面影响,并会对维度模型的易读性带来负面影响。

  14、审计维度
  当事实表行是在ETL 之后建立时,建立包含当时己知的ETL过程元数据的审计维度是很好的方法。简单的审计维度行可包含一个或多个数据质量的基本标识,也许来自对错误事件模式的检验,记录数据处理是发现的数据质量问题。另外,使用审计维度属性可以包含描述建立事实行或ETL执行时间戳的ETL 代码版本环境变量。这些环境变量对审计意图特别有用,因为它们确保BI工具下钻以确定!那些行是由哪些ETL软件版本建立的。

  15、最后产生的维度
  有时来自操作型业务过程的事实在关联维度内容前,以分钟、小时、天或周产生。例如,在实时日期发布环境下,订单消耗行可能会到来,显示客户提交的购买特定商品的自然键。在实时ETL系统中,该行必须提交到BI层,即使客户或产品还不能立即确定下米。在此情况下,将建立特殊的维度行,包含作为属性的未分解的自然键。当然,这些维度行必须包含通用未知值,用于多数描述性列;推测适当的维度内容将会从源获得。当这些维度内容最后获得时,占位维度行用类型l重写。当采用类型2 维度属性的追溯性变化发生后,最后达到的维度数据也会产生。在此情况下,新行需要插入维度表中,然后需要重新定义关联事实行。

九、特殊目的模式

  下列设计模式适用于特定的用例

  1、异构产品的超类与子类模式
  金融服务与其他商业通常提供不同业务类型的广泛的产品。例如,零售银行可以提供许多不同类型的账目,从支票账户到抵押贷款到商业贷款,但是所有这些都是账户的实例。试图建立单一的、固定的事实表,将所有可能的事实都包含在内,联系维度表包含所有不同产品的属性,是不会成功的,因为存在大量的不兼容事实和属性。解决方案是建立单一的超类事实表,该事实表遍历所有账户类型的事实表(以及包含公共属性的超类维度表),然后系统化地为不同子类建立不同的事实表(与维度表关联)。超类与子类事实表也被称为核心或自定义事实表。

  2、实时事实表
  实时事实表需要比传统的夜间批处理过程更频繁地被更新。有许多技术可用于支持这一需求。采用何种技术要考虑最后部署到BI报表层的DBMS或OLAP多维数据库能力。例如,“热分区”可以定义一个事实表占用专用物理内存。不用再该分区上建立聚集和索引。其他DBMS或OLAP多维数据库可能支持延迟更新,允许已存在的运行完毕的查询,依然可执行更新。

  3、错误事件模式
  数据仓库中数据质量的管理需要一个综合性系统,管理数据质量通过屏幕或过滤器来实现,用于测试从源系统到BI平台的数据。当数据质量屏幕检测到错误时,该事件将被记录在特殊的维度模式中,该维度模式仅能被ETL后端处理系统处理。这一模式包含错误事件事实表,其粒度为单独错误事件和相关错误事件详细事实表,相关错误事件详细事实表粒度为参与错误事件的每个表中的列。


注意:本文归作者所有,未经作者允许,不得转载

全部评论: 0

    我有话说: