Eddie昌的博客 Eddie昌的博客
首页
  • 数据理论

    • 《数据仓库工具箱》
    • 《阿里巴巴大数据之路》
    • 《DAMA数据治理》
  • 数据实践

    • TypeScript
  • 数据分析1
  • 数据分析2
  • Hadoop生态
  • Linux
  • Git
  • 爱SQL
  • 学习
  • 面试
  • 心情杂货
  • 实用技巧
  • 分类
  • 标签
  • 归档

Eddie昌

数据领域小学生
首页
  • 数据理论

    • 《数据仓库工具箱》
    • 《阿里巴巴大数据之路》
    • 《DAMA数据治理》
  • 数据实践

    • TypeScript
  • 数据分析1
  • 数据分析2
  • Hadoop生态
  • Linux
  • Git
  • 爱SQL
  • 学习
  • 面试
  • 心情杂货
  • 实用技巧
  • 分类
  • 标签
  • 归档
  • 《数据仓库工具箱》

    • 维度建模技术

      • 维度建模概述
      • 事实表技术
      • 维度表技术
  • 《阿里巴巴大数据之路》

  • 《DAMA数据治理》

  • 测试文章

  • 数据开发
  • 《数据仓库工具箱》
  • 维度建模技术
Eddie昌
2025-05-11

维度建模概述原创

# 基本概念

  1. 收集业务需求与数据实现

    开始建模前需要了解业务需求,作为基础源数据的实际情况。主要是跟业务代表了解关键性能指标、竞争性商业问题、决策制作过程、支持分析需求的目标。

  2. 协作维度建模研讨

    维度模型应该由主题专家与企业数据管理代表合作设计而成,维度模型不应该由不同业务以及业务需求的人来设计。

  3. 维度建模4步骤

    选择业务过程=》声明粒度=》确认维度=》确认事实=》维度退化

    业务过程:组织完成的操作型活动,例如获得订单、处理保险金索赔。过程定义了特定的设计目标以及对粒度、维度、事实的定义。每个业务过程对应企业数据仓库矩阵中的一行。

    粒度:用于确定某一事实表终的行表示什么。在选择维度以及事实前必须声明粒度,因为每个候选维度或事实必须与定义的粒度一致。强烈建议从关注原子级别的粒度设计开始设计。上卷汇总粒度对性能调整来说非常重要,但这样的粒度往往需要猜测业务公共问题。针对不同的事实粒度,要建立不同的物理表,在同一事实表中***不要混用多种不同的粒度***。

    维度:维度围绕某一业务过程事件所涉及的:谁、什么、何处、何时、为什么、、如何(5W1H)。维度表包含BI应用所需要的用于过滤(WHERE)、分组(GROUP BY)以及分类事实的描述性属性。与给定事实表关联时,应使维度保持单一值。

    事实:来自业务过程时间的度量,基本上都是以数值表示。事实表行与按照事实表粒度描述的度量事件之间存在一对一关系,表示一个物理可观察的时间。所有事实必须与声明的粒度一致。

  4. 星型模型与OLAP多维数据库

    星型模型:部署在关系型数据库,包括事实表以及通过主键/外键关系与之关联的维度表。

    OLAP:构建于多维数据库之上,与关系型星型模式内容等价,OLAP包括维度属性和事实表,能比SQL语言具有更强的语言能力和语言访问。

  5. 方便的扩展到维度模型

    维度模型对数据关系发生变化具有灵活的适应性,发生以下变化时,不需要改变现有的BI查询或应用:

    • 当事实与存在的事实表粒度一致时,可以创建新列;
    • 通过建立新的外键列,可以将维度关联到已存在的事实表上,前提是维度列于事实表粒度一致;
    • 可以在维度表上通过建立新列添加属性;
    • 可以使事实表的粒度更原子化,方法是在维度表上增加属性,然后以更细的粒度重置事实表,小心保存事实表及维度表的列名。

# 事实表基础

  1. 事实表结构:事实表对应一个度量事件,除数字度量外,事实表总是包含外键,用于关联与之相关的维度,也包含可选的退化维度和日期/时间戳。主要目标是对事实表开展计算和聚集操作。
  2. 可加、半可加、不可加事实:不可加事实如比率可以存储可加事实之后再计算。
  3. 事实表的空值:可存在空值度量,聚集函数如MAX、SUM等可正常处理。但是事实表的外键不可以为空值,维度表的空值必须用默认的值填充,如UNKNOWN。
  4. 一致性事实:某些度量出现在不同的事实表中,如果计算和比较计算不同事实表中的事实,应保证事实的技术定义是相同的。如果事实是一致的,则必须使用相同的命名,否则必须有不同的命名。
  5. 事务事实表:事务事实表的一行对应空间或时间上某点的度量事件。尽量存储最细原子粒度的事实,是维度变化及可表达的事实,可最大化分片和分块。事实表可以是稀疏或者稠密的,只有存在度量时才会建立行。度量数字必须于事务粒度保持一致。
  6. 周期快照事实表:每行汇总了发生在某一标准周期,如某一天、某周、某月的多个度量事件。粒度是周期性的,而不是个体的事务。周期快照事实表通常包含***许多事实***,任何与事实表粒度相同的度量都可放在一起。事实表及其外键的密度是均匀的,即使周期内没有活动发生,也会在事实表中为每个事实插入包含0或者空值的行。
  7. 累计快照事实表:汇总了发生在过程开始和结束之间可预测步骤内的度量事件。在事实表中针对过程的关键步骤都包含日期外键。累积快照事实表的一行对应某一具体订单,当订单产生时会插入一行,当管道过程发生时,累积快照事实表行被访问并修改。累积快照事实表也可包含其他维度和可选退化维度的外键。
  8. 无事实的事实表:某些事件仅仅记录一系列某一时刻发生的多维实体。例如某一天中发生的学生参加课程的事件,可能没有可记录的数字化事实,但该事实行带有一个包含日历天、学生、教师、地点、课程等定义良好的外键。
  9. 聚集事实表或OLAP多维数据库:聚集事实表时对原子粒度事实表数据进行简单的数字化上卷操作(类似DWS层)。OLAP的聚集可以直接被商业用户访问。
  10. 合并事实表:将来自多个过程的,以相同粒度表示的事实合并为一个单一的合并事实表,可带来方便。如现货销售和销售预测合并为一张事实表,与针对多个不同的事实表采用下钻比较会比简单快捷。合并事实表特别适合经常需要共同分析的多过程度量。

# 高级事实表技术

  1. 事实表代理键:代理健可用作所有维度表的主键。另外也可以使用单列代理事实键,通过ETL加载过程中顺次分配的,可以做事实表的1-主键列,2-事实表直接标识符,不用查询多个维度,3-将事实表的更新操作分解为风险更小的插入和删除操作。
  2. 蜈蚣事实表:一些设计者为多对一层次的每层建立不同的规范化维度。例如日期维度、月份维度、季维度和年维度等,并将所有外键包含在一个事实表中,这将产生蜈蚣事实表。正确做法是关联的维度都回到他们最细节的粒度上。当将所有外键嵌入到单一低粒度维表而不是建立杂项维度,也会产生蜈蚣事实表。
  3. 属性或事实的数字值:遇到数值时,不知道是分类到事实还是维度,典型的是产品的标准价格。如果该数值主要用于计算目的,则可能属于事实,如果适用于确定分组或过滤,则应将其定义为维度属性,高离散数字值用值范围进行补充,例如$5-50。某些情况下数字值既建模为维度又建模为属性是非常有益的。
  4. 日志/持续事件事实:累积快照事实表获取多个过程里程碑,每个都包含日期外键并可能包含日志/时间戳,商业用户希望分析这些里程碑之间滞后及延迟时间,可计算每一个步骤到第一个步骤的延迟时间。需要计算中间2个任意步骤的时间间隔可通过各自到第一个步骤的时间进行计算。
  5. 头/行事实表:操作型交易系统通常包含事务头指针行,与多个事务行关联。采用头/行模式(父子模式),所有头指针级别维度外键与退化维度应该被包含在行级别事实表。
  6. 分配的事实:头指针/行事务数据与对应的事实具有不同粒度这样的情况经常发生,例如头表示货运费用。应该尽量分配头指针事实,使其基于业务所提供的规则划分为行级别,分配的事实可以按照所有维度进行分片并上钻。多数情况可避免建立头指针级别的事实,除非这样的聚集能够获得查询性能的改善。
  7. 利用分配建立利润与损失事实表:事实表揭示利润等价方程:收入-开销=利润。理想的把实现利润方程的事实表应为原子收入实务粒度并包含许多开销项。因为这些表处于原子粒度才能实现数字化的上卷,包括客户利润、产品利润、促销利润、渠道利润等。然而建立这些事实表存在一定难度,因为开销项必须从其原始来源划分到事实表粒度,是一个与业务相关的步骤,需要高层经理的支持。利润与损失相关事实表通常在早期的实现阶段不会被处理。
  8. 多货币事实:多货币单位记录财务事务的事实表行应该包含本币、标准币的一对列。该事实表也必须有一个货币维度用于区分事务的真正货币。各货币的汇率可以通过建立货币维表实现。
  9. 多种度量事实单位:某些业务过程需要事实间以多种度量单位表示,例如按照业务用户的观点,供应链可能需要对相同事实以平台、船运、零售以及单个扫描单元构建报表。最好的方法是将事实以工人的标准度量单位存储,同时存储标准度量与其他度量的转换系数。这种事实表可按照不同用户的观点部署,转换系数必须存储在事实表行中以确保计算简单正确,并尽量降低查询复杂度。
  10. 年-日事实:商业用户在事实表中通常需要年-日值(YTD)。YTP很容易转换为“财务周期结束时的YTD”或者“财务周期日”。更可靠、可扩展的处理方法是在BI或者OLAP中计算YTD矩阵,而不是在事实表中查出YTD事实。
  11. 多遍SQL以避免事实表间的连接:不应该跨事实表的外键处理2个事实表的连接操作。在如果2个事实表包含客户产品的出货和返回,则这两个表不能按照客户和产品外键直接连接。要采用跨钻方式方式使用2个事实表,并对结果按照公共行头指针属性值进行排序-融合操作以产生正确的结果。
  12. 针对事实表的时间跟踪:个别情况在事实表中增加行有效时期、行截止日期和当前行标识是非常有用的,与采用类型2缓慢变化维类似。
  13. 迟到的事实:新事实无法与维度匹配,当迟到度量事件出现时,必须搜索相关维度以发现有效的维度键。

# 维度表技术基础

  1. 维度表结构:包含单一主键列,维度表通常比较宽的扁平化非规范表,包含大量的低粒度文本属性。操作代码与指示器可作为属性对待。维度表属性是查询及BI应用的约束和分组定义的主要目标。报表的描述性标识通常是维度表属性领域值。
  2. 维度代理健:维度表中的唯一主键,不是操作型系统的自然间,一般是无语义的整形自增主键。日期维度不需要遵循代理键规则,可采用更有意义的主键。
  3. 自然键、持久键和超自然键:当雇员重新入职会分配不同的雇员号码,则雇员号码为自然键,如果数仓希望创建单一键不因为入职影响,则这个为持久键或者超自然键。
  4. 下钻:在查询上增加一个行头指针,对应一个维度属性,附加GROUP BY表达式。属性可以来自任何与查询使用的事实表关联的维度。
  5. 退化维度:若维度除了主键外没有其他内容,例如当某一发票包含多个数据项时,数据项事实行继承了发票所有描述性维度外键,发票除了外键外无其他项。但发票数量任然是在此数据项级别的合法维度键。这种退化维度被放入事实表中,清楚地表明没有关联的维度表。常见于交易和累计快照事实表。
  6. 非规范化扁平维度:维度建模需要抵制规范化涉及,将非规范化的多对一固定层次引入扁平维度行的不同属性,可实现设计简化及访问速度提升。
  7. 多层次维度:多数维度包含不止一个层次,如日期维度可以按照财务周期层次从天到周划分,也可能存在天到月再到年的参差,位置维度也类似。
  8. 文档属性的标识与指示器:令人迷惑的缩写、标识及业务指标使用维度表中文字词含义补充解释。操作代码包含的含义应该分解成不同的维度属性。
  9. 维度表中的空值:与事实表不同,维度表不能存在空值。空值应该用描述性字符串替代,因为数据库处理分组和约束时,针对空值的处理方法不一致。
  10. 日历日期维度:连接到事实表的日历日期维度应该使事实表按照熟悉的日期、月份、财务周期和日历上的特殊日期进行导航。不要通过SQL去计算类似复活节这种日期,而是应该在日期维度中存储。日期维度的主键可以用yyyyMMdd表示,而不是代理健。事实表可以添加时间戳,如果有当天时间的分组则需要在事实表添加一个当天时间的维度外键。
  11. 扮演角色的维度:单个物理维度可以被事实表多次引用,每个引用连接逻辑上存在的差异的角色维度。例如事实表可以有多个日期,每个日期通过外键连接不同的日期维度,原则上每个外键表示不同的日期维度视图。
  12. 杂项维度:事务型商业过程通常产生一系列混杂的、低粒度的标识和指示器。与其为每个标识或属性定义不同的维度,不如建立单独的将不同维度合并到一起的杂项维度。通常在一个模式中标记为事务型概要维度,不需要所有笛卡尔积,只需要记录实际发生的合并值。
  13. 雪花维度:当维度表中的层次关系是规范的时,低粒度属性作为辅助表通过属性键连接到基本维度表,这种建立的多层结构为雪花模式。不要使用雪花模式,扁平化、反规范化的维度表完全能获得同样信息。
  14. 支架维度:维度可包含对其他维度的引用,这种叫支架维度,如银行账户维度可以引用表示开户日期的维度。尽量少用支架维度,多数维度的关联应该由事实表来实现,在事实表中通过2个维度的不同外键相关联。

# 使用一致性维度继承

  1. 一致性维度:不同维度表的属性具有相同列名和领域内容时,称维度表具有一致性。利用一致性维度属性与每个事实表关联,可将不同事实表的信息合并到同一报表中,实现跨钻。
  2. 缩减维度:属于一种一致性维度。①当需要聚集时需要缩减上卷;②获取更高粒度的数据时;③两个维度具有同样粒度级别数据,但其中一个仅是另外一个的部分子集,也需要一致性维度子集。
  3. 跨表钻取:每个查询行头包含相同一致性属性时,使不同的查询能够针对2个或者更多的事实表进行查询。
  4. 价值链:用于区分组织中主要业务过程的自然流程,一般操作型原系统通常为价值链上的每个步骤建立事务或者快照。每个过程在特定时间间隔,采用特定的粒度和维度建立唯一度量。
  5. 企业数据仓库总线架构:将关注的业务过程将数仓规划过程分解为可管理模块,通过重用跨不同过程的标准化一致性维度实现继承,可实现敏捷实现对应企业数据仓库总线矩阵。
  6. 企业数据仓库总线矩阵:设计与企业数据仓库总线架构交互的基本工具,行表示业务过程,列表示维度。设计时考虑是否为业务过程定义好相关候选维度、某一维度需要跨多个业务过程并保持一致性。
  7. 总线矩阵实现细节:数仓总线矩阵每个业务过程行可以扩展信息:粒度、事实列表。
  8. 机会/利益相关方矩阵:确定数仓总线矩阵厚,可通过替换包含业务功能的维度列规划不同的矩阵。通过矩阵点表示哪些业务功能与哪些业务过程相关。

# 处理缓慢变化维度属性

  1. 类型0:保留原样,用于属性标记为“原始”的属性,如客户原始积分。
  2. 类型1:重写,维度行中原来属性被新值覆盖,总是反应最近的工作,但破坏了历史情况。
  3. 类型2:增加新行,拉链表并且有1列为当前标志。支持用维度历史值关联历史事实、维度最新值关联历史事实。
  4. 类型3:增加新属性,在维表上新增属性以保存原来的属性值,新属性值以变化类型1方式重写主属性,可以利用当前值或者历史值分组过滤事实数据,不太常用。
  5. 类型4:增加卫星维度,当维度中一组属性快速变化并划分为微型维度时采用。微型维度需要自己的唯一主键,及维度和微型维度主键从相关事实表获取。
  6. 类型5:增加微型维度及类型1支架。用于精确保存历史属性值,建立在类型4微型维度上并嵌入当前类型1引用及维度中的微型维度。当当前维度分配发生变化时,ETL小组需要重写类型1微型维度引用。
  7. 类型6:增加类型1属性到类型2维度。建立在类型2的基础上,同时嵌入维度行属性的当前类型1版本,因此事实行可以被过滤或分组,要么按照当度量发生时有效的类型2属性值,要么按照属性的当前值。当属性发生变化时,类型1属性由系统自动重写与持久键关联的所有行。
  8. 类型7:双类型1和类型2维度。用于支持过去和现在报表的最后一种混合技术。事实表可以被访问,通过被建模为类型1维度仅仅展示最新属性值,建模为类型2维度展示最新历史概要。维度的持久键和主代理健同时存在事实表上。从类型1角度看,维度的当前标识被约束至当前,通过持久键与事实表连接。从类型2角度看,当前标识无越苏,事实表通过代理健主键连接。可通过不同的视图部署到BI应用上。

# 处理维度层次关系

  1. 固定深度位置的层次:多对一关系的一种,如从产品到品牌再到分类,到部门。深度固定,层次就具有商定的名字,层次级别作为维度表中的不同位置属性出现。
  2. 轻微参差不齐/客编深度层次:没有固定深度,但层次深度有限。地理层次深度通常包含3到6层。可将其变换为固定深度位置设计,针对不同的维度属性确定最大深度,然后基于业务规则放置属性值。
  3. 具有层次桥接表的参差不齐/可变深度层次:可通过再关系型数据库中采用构建桥接表方式建模参差不齐层次来解决。桥接表对每个可能的路径保留一行,确保能够遍历所有层次的形式。
  4. 具有路径字符属性的可变深度层次:可在维度中采用路径字符属性,以避免使用桥接表表示可变深度。维度中每行,路径字符属性包含特定的嵌入文本字符,包含从层次最好节点到特定维度行所描述节点的完整路径描述。然而路径字符方法不能确保其他层次的快速替换,也无法保证共享自身层次,也难于构建可变路径层次的变化,可能需要重新标记整个层次。

# 高级维度技术

  1. 维度表连接:维度表可以采用支架维度建模表示到其他维度表的引用,但会导致维度爆炸(如处理支架的维度是SDC类型2时尤为突出)。一般是将支架表中的外键嵌入事实表中而不是放置在基本维度表中,降低维度表之间的关联。
  2. 多值维度与桥接表:某些情况下,维度存在合理的多值,例如某个病人接受一次健康体检,可能同时出现多个诊断,这种情况下多值维度必须通过一组维度键通过桥接表使一组中的每个诊断与事实表一行关联。
  3. 随时间变化的多值桥接表:多值桥接表可能需要基于缓慢变化类型2维度,如实现银行账户与单独客户的多对多关系的桥接表,通常必须基于类型2的账户与客户维度。为防止账户与客户间的不正确连接,桥接表必须包含有效期和截止日期/时间错,请求的应用必须约束桥接表,使其满足特定时刻以产生一致的快照。
  4. 标签的时间序列行为:几乎所有的文本都是维度表中的描述文本。数据挖掘客户聚类分析通常产生文本化的行为标签,通常可以用作区分周期。跨时间范围的客户行为度量成为由这些行为标签构成的一种序列,该时间序列应该以位置属性被存储在客户维度中,包含可选文本串,构成完整的序列标签。
  5. 行为研究分组:通过执行多次迭代分析,来分析复杂的客户行为。将行为分析嵌入到BI应用,以约束所有客户维度的成员,获取复杂的行为的做法是不现实的。复杂行为分析的结果可以通过某些简单表获取,这些表称为研究分组,仅包含客户的持久键。查询时通过约束研究组表的列与目标模式中客户维度的持久键,该静态表可当成一种可应用于任何带有客户维度的维度模式过滤器。
  6. 聚集事实作为维度属性:商业用户通常对基于聚集性能度量的客户维度感兴趣,如过滤去年或整个阶段所有花费超过一定数额的客户。聚集事实可以放入作为约束和作为行标识报表的目标为维度。度量通常表示为维度表中的带状范围。
  7. 动态值范围:动态值范围报表由一系列报表行头组成,这些报表行头为目标数字化事实定义了范围不断变化的集合。如一个银行的公共值域范围报表包含带有标签的多个行,如“从0到$10的平帐”,“从10.01到$25的平账”等等。此类报表是动态报表,因为每次查询时都定义了特定的行头,而不是在ETL过程中定义的。
  8. 文本注释维度:与其将自由注释作为事实表的文本度量,不如将他们存储与事实表之外的不同的注释维度,每个事务一行,需要注释的粒度满足唯一事务的数目,使该注释维度对应事实表中的一个外键。
  9. 多时区:为在多时区应用中获得通用标准时间以及本地时间,应该在受影响的事实表中设置双外键,用以连接两个不同角色的日期维度表。
  10. 度量类型维度:有时当事实表每行包含一长列稀疏存储的事实时,可以建立度量类型维度,通过度量类型维度将事实表行变成单一通用事实。我们一般不建议采用该方法,尽管它消除了所有空的事实表列。当潜在事实的数量达到极限(几百个),但是没有多少需要应用到任何给定事实表行时,可以采用该技术。
  11. 步骤维度:序列过程(例如WEB页事件)通常在事务事实表中用不同行表示过程中的每一步。为了告知哪个步骤满足整个绘画,使用步骤维度展示当前步骤的步骤号以及完成该会话共由多少步骤。
  12. 热交换维度:同一个事实表与相同维度的不同拷贝交替搭配时,可使用热交换维度。例如某事实表包含股票行情,可以同时展示给不同的投资人,不同的投资人对不同的股票由不同的属性要求。
  13. 抽象通用维度:抽象即把事物往上级靠。如单一的位置维度而不是关于商店、仓库和客户维度的嵌入地理属性。人员维度包含雇员、客户和供应商。应该避免使用抽象通用维度。
  14. 审计维度:当事实表行是在ETL之后建立时,建立包含当时已知的ETL过程元数据的审计维度是很好的方法。审计维度行可包含一个或多个数据质量的基本标识,也许来自对错事件模式的检验,记录数据处理是发现的数据质量问题。审计维度属性可以包含描述建立事实行或ETL执行时间戳的ETL代码版本环境变量。
  15. 最后产生的维度:业务过程的事实在关联维度内容前,以分钟、小时、天或周产生。如在实时日期发布环境下,订单消耗行可能会到来,显示客户提交的购买特定商品的自然键。在实时ETL系统中,该行必须提交到BI层,即使客户或产品还不能立即确定下来。在此情况下,建立特殊的维度行,包含作为属性的为分界的自然键,这些维度行必须包含通用未知值,当这些维度内容最后获取时,占用维度行用类型1重写。

# 特殊目的模式

  1. 异构产品的超类与子类模式:金融服务与其他商业通常提供不同业务类型的广泛产品。如零售银行可以提供许多不同类型的账户,从支票账户到抵押贷款到商业贷款,但是所有这些都使账户的实力。视图建立单一的、固定的事实表,将所有可能的事实都包含在内,联系维度表包含所有不同产品的属性是不会成功的。因为存在大量的不兼容事实和属性,解决方案是建立单一的超类事实表,该事实表遍历所有账户类型的事实表然后系统化地为不同子类建立不同的事实表(与维度表关联)。超类与子类事实表也被成为核心或自定义事实表。
  2. 实时事实表:实时事实比传统的夜间批处理过程更频繁地被更新。
  3. 错误事件模式:数仓中数据质量管理需要一个综合性系统,管理数据质量通过屏幕或过滤器来实现,用于测试从源系统到BI平台的数据。当数据质量屏幕监测到错误时,该事件将被记录在特殊的维度模式中,仅能被ETL后端处理系统处理。包含错误事件事实表,粒度为单独错误事件和相关错误事件详细事实表,相关错误事件详细事实表粒度为参与错误事件的每个表中的列。

#数据仓库#数仓笔记#《数据仓库工具箱》
上次更新: 2025/06/22, 18:51:19
事实表技术

事实表技术→

最近更新
01
维度表技术 原创
05-29
02
事实表技术 原创
05-17
03
06.搭建一套源生hadoop、Spark、Flink集群3-Hive安装 原创
04-26
更多文章>
Theme by Vdoing | Copyright © 2019-2025 Evan Xu | MIT License | 粤ICP备2023070487号-1 | 粤公网安备44200102445447
  • 跟随系统
  • 浅色模式
  • 深色模式
  • 阅读模式