《大数据之路1》笔记2：数据模型

一 数据建模综述

1.1 为什么要数据建模

• 背景：
  随着DT时代的来临，数据爆发式增长，如何对数据有序，有结构地分类组织额存储是关键

• 定义：
  数据模型时数据组织和存储的方法，强调从业务、数据存取、使用角度 合理存储数据

• 优点：

  • 性能-帮助我们快速查询数据，减少数据I/O吞吐
  • 成本-减少不必要的数据冗余，降低大数据系统的存储和计算成本
  • 效率-改善用户使用数据的体验，提高数据使用效率
  • 质量-改善数据统计口径的不一致性，减少数据计算错误的可能性

数据建模方法能帮助我们更好地组织和存储数据，以便在性能、成本、效率、质量之间取得平衡。

数据建模的作用，我认为这和我们管理自己的知识体系一样，我们的知识体系讲究层级和网状并存，来实现我们了解的信息既能够准确分类，又能够连接产生新的想法，产生知识创新，我认为数据建模就是为了使得信息高效流通，是一个不断萃取的过程，从数据到信息，再到知识，最重是智慧，一句话就是一个知识管理模型

1.2 关系数据库系统和数据仓库

不管是Hadoop、Spark还是阿里巴巴的MaxComputer系统，仍然使用sql进行数据加工，使用table存储数据，使用关系理论描述数据之间的关系，只是在大数据领域，基于数据存取特点在关系数据模型的范式上有了不同的选择

关于大数据领域的建模基础可供参考《数据库系统概念》

1.3 从OLAP和OLTP的区别看模型方法论的选择

• OLTP：OLTP系统通常面向数据操作的随机读写，主要采用满足3NF的实体关系模型存储数据，从而在事务处理中解决数据的冗余和一致性问题

• OLAP：OLAP系统面向主要数据操作是批量读写，事物处理中的一致性不是OLAP所关注的，主要关注数据的整合，以及在一次性的复杂大数据查询和处理中的性能，因此它需要采用一些不同的数据建模方法

1.4 典型的数据仓库建模方法论

1.4.1 ER模型（实体关系模型，符合3NF）

数仓中的ER模型是站在企业的角度上，使用3NF来整合数据，将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策.
OLAP中的ER模型是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象

• 特点

  • 需要全面了解企业业务和数据
  • 实施周期非常长
  • 对建模人员的能力要求非常高

• 建模步骤分为3步：

  1. 高层建模：一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况
  2. 中层建模：细化主题的数据项
  3. 物理建模：在中层模型基础上，进行物理建模，比如表的合并、分区设计等

1.4.2 维度模型

• 适合场景
  • 从分析决策的需求出发构建模型，为分析服务，重点关注用户如何更快速完成需求分析，同时具有较好的大规模复杂查询能力
• 典型代表是：星型模型、雪花模型
• 构建步骤
  1. 选择需要分析决策的业务过程（业务过程可以是单个业务事件，也可以是事件的状态，也可以是一系列相关业务事件。具体要看我们分析的是某事件发生情况，还是当前状态，或是事件流转效率
  2. 选择粒度，即一行数据
  3. 识别维度
  4. 选择事实。确定分析需要衡量的指标

1.4.3 Data Vault模型

• ER模型的衍生，目的是为了是实现数据的整合，但不能直接用于数据分析决策。强调建立一个可审计的基础数据层，也就是强调数据的历史性、可追溯性、原子性，而不要求对数据进行过度的一致性处理和整合，同时基于主题概念将企业数据进行结构化组织，并引入更进一步的范式处理来优化模型，来应对源系统变更的扩展性。

• 组成

  • Hub：企业的核心业务实体。由实体key、数据仓库序列代理键、装载时间、数据来源组成
  • Link：代表Hub之间的关系，与ER模型最大的区别是将关系作为一个独立的单元抽象，可以提升模型的扩展性
  • Satellite：描述Hub的详细描述内容，一个Hub可以有多个Satellite

• 核心：Hub 可以想象成人的骨架， Link 就是连接骨架的韧带，而 SateIIite 就是骨架上面的血肉

1.4.4 Anchor模型

• 是对Data Vault模型做进一步规范化处理，为了高度可扩展的模型，核心思想是所有扩展知识田间而不是修改，模型规范到6NF，基本变成k-v结构化模型

• 组成

  • Anchors：代表业务实体，且只有主键
  • Attributes：将其全部k-v结构化，一个表只有一个Anchors的属性描述
  • Ties：类似于Data Vault的Link，提升模型的扩展能力
  • Knots：属性

1.5 阿里巴巴数据模型实践综述

阿里选择维度建模为核心理念的模型方法论，同时对其进行一定的升级和扩展

数据公共层建设的目的是着力解决数据存储和计算的共享问题

阿里巴巴数据公共层建设的指导方法是一套统一化的集团数据整合及管理的方法体系，集团内部成为‘OneData’，其包括一致性的指标定义体系、模型设计方法体系以及配套工具

二 阿里巴巴数据整合及管理体系

2.1. 概述

• 构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势

• 核心 ：从业务架构设计到模型设计，从数据研发到数据服务，做到数据可管理 、可追溯、可规避重复建设

• 定位： 建设统一的、规范化的数据接入层（ODS）和数据中间层（DWD和DWS），通过数据服务和数据产品，完成服务于阿里巴巴的大数据体系建设，即数据公共程建设。提供标准的（Standard）、共享的（Shared）、数据服务（Service）能力，降低数据互通成本，释放计算、存储、人力等资源，以消除业务和技术之痛

• 体系架构

  • 业务板块
  • 规范定义： 根据行业数据仓库建设经验和公司数据自身特点，设计出一套数据规范命名体系，规范定义将会被用在模型设计中
  • 模型设计： 以维度建模理论为基础，基于维度建模总线架构，构建一致性的维度和事实（进行规范定义）。同时，在落地表模型时，基于公司自身业务特点，设计一套表现规范命名体系

2.2 规范定义

• 规范定义：指以维度建模作为理论基础 构建总线矩阵，划分和定义数据域、业务过程、维度、度量 原子指标、修饰类型、修饰词、时间周期、派生指标。

• 名词术语：数据域、业务过程、时间周期、修饰类型、修饰词、度量/原子指标、维度、维度属性、派生指标

• 指标体系

  1. 基本原则：组成体系之间的关系，原子指标 + 时间周期修饰词 + 其他修饰词 = 派生指标
  2. 操作细则
     • 了解原子指标、派生指标、修饰词、时间周期
     • 命名约定
     • 算法：原子指标、修饰词、派生指标的算法的计算逻辑
     • 派生指标的种类
       • 事物型指标：对业务活动进行衡量的指标。如订单支付金额，商品数…
       • 存量型指标：指对实体对象某些状态的统计
       • 复合性指标：在事物型指标和存量型指标的基础上复合而成的，一般是什么什么率，占比
  3. 其他规则

2.3 模型设计

阿里巴巴数据公共层设计理念主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。
指导理论遵循维度建模思想，可参考 Star Schern The Complete Reference The Dαtα Warehouse Toolkit-The Definitive Guide to Dimensional Modeling。

2.3.1 模型层次

• 操作数据层（ODS）

  • 同步：结构化数据增量或全量同步到集群
  • 结构化：非结构化（日志）结构化处理并存储集群
  • 累计历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据

• 公共维度层（CDM），又分为明细数据层（DWD）、汇总数据层（DWS)
  存放明细事实数据、维表数据及公共指标汇总数据 其中明细事实数据、维表数 一般根据 ODS 层数据加工生成 ：公共指标汇总数据 般根据维表数据和明细事实数据加工生成。

  明细数据层和汇总数据层，采用维度模型方法，更多采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性；同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提高公共指标的复用性，较少重复加工

• ADS层
  存放数据产品个性化的统计指标数据，根据CDM层和ODS层加工生成

数据调用服务优先使用公共维度模型层（ CDM）数据，当公共层没有数据时，需评估是否需要创建公共层数据，当不需要建设公用的公共层时，方可直接使用操作数据层（ ODS ）数据。应用数据层（ ADS)作为产品特有的个性化数据，一般不对外提供数据服务，但是 ADS 作为被服务方也需要遵守这个约定。

2.3.2 基本原则

• 1. 高内聚和低耦合
• 2. 核心模型与扩展模型分离
• 3. 公共处理逻辑下沉及单一
• 4. 成本与性能平衡
• 5. 数据可回滚
• 6. 一致性
• 7. 命名清洗、可理解

2.4 模型实施

模型的实施主要关注 如何从具体的需求或项目转换为可实施的解决方案，如何进行需求分析、架构设计、详细模型设计等

2.4.1 业界常用的模型实施过程

• Kimball模型
  • 步骤1： 探讨需求分析
  • 步骤2：高层模型设计 定义业务过程维度模型的范围，提供每种星形模式技术和功能描述。产出目标是创建高层维度模型图，它是对业务过程中的维表和事实表的图形描述，确定维表创建初始属性列表，为每个事实表创建提议度量
  • 步骤3：详细模型设计 对每个星形模型添加属性和度量信息。是为了给高层模型填补缺失信息，解决设计问题，并不断测试模型是否能满足业务需求，确保模型的完备性。确定每个维表 的属性和每个事实表的度量，并确定信息来源的位置、定义、确定属性和度量如何填入模型的初步业务规则
  • 步骤4：模型审查、再审计和验证 产生详细设计文档，提交ETL设计和开发；召集相关人员进行模型的审查和验证，根据审查结果对详细维度进行再设计
• Inmon模型
  • Inmon 对数据模型的定位是：扮演着通往数据仓库其他部分的智能路线图的角色。由于数据仓库的建设不是一蹴而就的，为了协调不同人员的工作以及适应不同类型的用户，非常有必要建立一个路线图——数据模型，描述数据仓库各部分是如何结合在一起的
  • ERD层：实体关系图
  • DIS层：数据项集
  • 物理层：物理模型
• 其他模型实施过程
  1. 业务建模，生成业务模型，解决业务层面的分解和程序化
  2. 领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型
  3. 逻辑建模，生成逻辑模型，主要将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化
  4. 物理建模，生成物理模型，主要解决逻辑建模对不同关系数据库的物理化以及性能等一些具体 的技术问题

2.4.2 指导方针

1. 数据调研。在建设大数据数据仓库时，要进行充分的业务调研和需求分析

   • 业务调研：数据仓库是要涵盖所有业务领域，还是各个业务领域独自建设，业务领域内的业务线也同样面临着这个问题。所以要构建大数据数据仓库，就需要了解各个业务领域、业务线的业务有什么共同点和不同点，以及各个业务线可以细分为哪几个业务员板块，每个业务板块具体的业务流程又是怎样的

   • 需求调研：通过分析师、业务运营人员去了解；通过报表系统中现有的报表进行研究分析

2. 数据总体架构设计。主要是根据数据域对数据进行划分，按照维度建模理论，构建总线矩阵、抽象出业务过程和维度

   1. 数据域划分：是指面向业务分析，将业务过程或者维度进行抽象的集合，业务过程是一个个不可拆分的行为事件，数据域需要抽象提炼，并且长期维护和更新，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或者扩展新的数据域。

   2. 构建总线矩阵：明确两件事：明确每个数据域下有哪些业务过程；业务过程与哪些维度相关，并确定每个数据域下的业务过程和维度

3. 规范定义。主要定义指标体系，包括原子指标，修饰词，时间周期和派生指标

4. 模型设计：主要包括维度及属性的规范定义，维表、明细事实表和汇总事实表的模型设计

5. 代码研发和运维

OneData 的实施过程是一个高度迭代和动态的过程， 般采用螺旋式实施方法。在总体架构设计完成之后，开始根据数据域进行迭代式模型设计和评审。在架构设计、规范定义和模型设计等模型实施过程中，都会引人评审机制，以确保模型实施过程的正确性。

三 维度设计

3.1 维度设计基础

这就像描述一个事物，需要各种条件来限定，对其进行锁定，维度就是环境条件，事实就是度量，代表其程度

• 基本概念

  • 在维度建模中，将度量称为”事实“，将环境描述为”维度“，维度是用于分析事实所需要的多样环境

  • 维度所包含的表示维度的列，称为维度属性。维度属性是查询约束条件、分组和报表标签生成的基本来源，是数据易用性的关键。

  • 维度使用主键标识其唯一性，主键也是确保与之相连的任何事实表之间存在引用完整性的基础。主键有两种：代理键和自然键，它们都是用于标识某维度的具体值。但代理键是不具有业务含义的键，一般用于处理缓慢变化维；自然键是具有业务含义的键

  • 如何获取维度或维度属性？如上面所提到的，一方面，可以在报表中获取；另一方面，可以在和业务人员的交谈中发现维度或维度属性。

• 设计方法
  维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库易用性的关键。正如 Kimball 所说的，数据仓库的能力直接与维度属性的质量和深度成正比。

  • 方法：
    1. 选择维度或新建维度，作为维度模型的核心，必须保证维度的唯一性
    2. 确定主维表，其一般是ODS层
    3. 确定相关维表， 数据仓库是业务源系统的数据整合，不同业务系统或者同 业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。
    4. 确定维度属性。一般是两个阶段，一是从主维表中选择维度属性或生成新的维度属性；第二阶段是从相关维表中选择维度属性或生成新的维度属性
  • 提示
    • 尽可能生成丰富的维度属性
    • 尽可能多地给出宝库奥一些富有意义的文字性描述
    • 区分数值型属性和事实
    • 尽量沉淀出通用的维度属性

• 层次结构
  维度中的一些描述属性以层次方式或一对多的方式相互关联，可以被理解为包含连续主从关系的属性层次。层次的最底层代表维度中描述最低级别的详细信息，最高层代表最高级别的概要信息。维度常常有多个这样的嵌入式层次结构。比如淘宝商品维度，有卖家、类目、品牌等。商品属于类目，类目属于行业，其中类目的最低级别是叶子类目，叶子类目属于二级类目，二级类目属于一级类目。

• 规范化和反规范化

  • 在OLTP中，为了避免数据冗余导致的不一致性，会采用范式的处理，
  • 在OLAP中，由于数据量大，注重读写查询，所以会牺牲掉一部分存储性能，来提高查询速度

  将维度的属性层次合并到单个维度中的操作称为反规范化。分析系统的主要目的是用于数据分析和统计，如何更方便用户进行统计分析决定了分析系统的优劣。采用雪花模式，用户在统计分析的过程中需要量的关联操作，使用复杂度高，同时查询性能很差；而采用反规范化处理，则方便、易用且性能好。

• 一致性维度和交叉探查
  Kimball 的数据仓库总线架构提供了 种分解企 级数据仓库规划任务的合理方法，通过构建企业范围内 致性维度和事实来构建总线架构。
  维度一致性的表现形式： 共享维表； 一致性上卷；交叉属性

3.2 维度设计高级主题

• 维度整合

  • 数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合，用来支持管理人员的决策，其中集成是数据仓库的四个特性中最重要一个

  • 数据仓库的数据来源是不同的面向应用的操作型环境，不同的应用是设计考虑不一样，应用之间差异巨大，导致整合难度大，但非常重要

  • 差异表现：

    • 应用在编码、命名习惯、度量单位等方面会存在很大的差异
    • 应用出于性能和扩展性的考虑，或者随技术架构的演变，以及业务的发展，采用不同的物理实现

  • 数据由面向应用的操作型环境进入数据仓库后，需要进行集成。将面向应用的数据转换为面向主题的数据仓库数据，本身就是一种集合。

  集成规范：

  • 命名规范的统一，表名、字段名等的统一
  • 字段类型的统一
  • 公共代码及代码值的统一
  • 业务含义相同的表的统一：
    • 1）采用主从表的设计方式
    • 2）直接合并
    • 3）不合并
  • 垂直整合
  • 水平整合

• 水平拆分
  维度通常可以按照类别或类型进行细分，如何设计维度

  • 两种解决方案：
    1. 将维度的不同分类实例化为不同的维度，同时在主维度中保存公共属性
    2. 维护单一维度，包含所有可能的属性

  选择哪种方案：

  • 三个原则（扩展性，效能，易用性）
  • 两个依据：
    1. 是维度的不同分类的属性差异情况
    2. 业务的关联程度

• 垂直拆分
  出于扩展性、产出时间、易用性等方面的考虑，设计主从维度。主维表存放稳定 产出时间早、热度高的属性；从维表存放变化较快、产出时间晚、热度低的属性。

• 历史归档
  顾名思义，定期将历史数据归档至历史维表

  • 归档策略
    • 归档策略 一：同前台归档策略，在数据仓库中实现前台归档算法，定期对历史数据进行归档
    • 归档策略 二：同前台归档策略，但采用数据库变更日志的方式
    • 归档策略 三：数据仓库自定义归档策略。

3.3 维度变化

• 缓慢变化维
  缓慢变化维的提出是因为在现实世界中，维度的属性并不是静态的，它会随着时间的流逝发生缓慢的变化与数据增长较为快速的事实表相比，维度变化相对缓慢。

  • Kimball 的理论中，种处理缓慢变化维的方式
    • 1. 第一种处理方式 ：重写维度值。采用此种方式，不保留历史数据，始终取最新数据。
    • 2. 第二种处理方式：插入新的维度行。采用此种方式，保留历史数据，维度值变化前的事实和过去的维度值关联，维度值变化后的事实和当前维度值关联
    • 3. 第三种处理方式：添加维度列。采用此种处理方式不能将变化前后记录的事实归 为变化前的维度或者归 为变化后的维度。

  选择哪种处理方式没有一个固定的方式，可以根据业务需求进行选择

• 快照维表
  在阿里巴巴数据仓库实践中，处理缓慢变化维的方法是采用快照方式，数据仓库的计算周期一般是每天一次，基于此周期，处理维度变化的方式就是每天保留一份全量快照数据

  • 原因：
    在 Kimball的维度建模中，必须使用代理键作为每个维表的主键，用于处理缓慢变化维。但在阿里的数据量巨大，对于分布式计算系统，不存在事务的概念，对于每个表的记录生成稳定的全局唯一的代理键难度很大；使用代理建会大大增加ETL的复杂性，对ETL的开发和维护成本很高。而快照维表很好的解决了这个问题，数据仓库的计算周期 一般是每天 1次，基于此周期，处理维度变化的方式就是每天保留一份全量快照数据。

  • 优点：简单而有效，开发和维护成本低；使用方便，理解性好

  • 弊端：存储上的极大浪费。此方法主要就是实现了牺牲存储获取 ETL 效率的优化和逻辑上的简化。但是 一定要杜绝过度使用这种方法，而且必须要有对应的数据生命周期制度，清除无用的历史数据。

• 极限存储
  极限存储是比快照维表更优的方法，即可以实现快照维表的优点，又可以避免存储浪费。
  历史拉链存储是指利用维度模型中缓慢变化维的第二种处理方式。这种处理方式是通过新增两个时间戳字段(start_dt end_dt ），将所有以天为粒度的变更数据都记录下来。通常分区字段也是时间戳字段。
  但是这种存储方式对于下游使用方存在一定的理解障碍，另外，这种储方式用 start_dt end_dt 做分区，随 时间的推移，分区数量会极度膨胀，而现行的数据库系统都有分区数量限制。
  为了解决上述问题，采用极限存储采用

  • 透明化
  • 分月做历史拉链表

  采用极限存储的处理方式，极大地压缩了全量存储的成本，又可以达到对下游用户透明的效果，是一种比较理想的存储方式。但是其本身也有一定 的局限性，首先，其产出效率很低，大部分极限存储通常需要t-2。 其次，对于变化频率高的数据并不能达到节约成本的效果

• 微型维度
  微型维度的创建是通过将一部分不稳定的属性从主维度中移出，并将它们放置到拥有自己代理键的新表中来实现的。这些属性相互之间没有直接关联，不存在自然键。通过为每个组合创建新行的一次性过程来加载数据。可以解决维度的过度增长导致极限存储效果大打折扣的问题。其中一种解决方法就是上一节提到的垂直拆分，保持主维度的稳定性；另一种解决方式是采用微型维度。

3.4 特殊维度

• 递归层次
  维度的递归层次，按照层级是否固定分为均衡层次结构和非均衡层次结构。

  • 层次结构扁平化
    降低递归层次使用复杂度的最简单和有效的方法是层次结构的扁平化，通过建立维度 的固定数量级别的属性来实现，可以在一定程度上解决上钻和下钻的问题。对于均衡层次结构，采用扁平化最有效
  • 层次桥接表：
    针对层次结构扁平化所存在的问题，可以采用桥接表的方式来解决，不需要预先知道所属层级，不需要回填，也可解决非均衡层次结构的问题。与扁平化方法相比，该方法适合解决更宽泛的分析问题，灵活性好；但复杂性高，使用成本高。

• 行为维度（类似的维度，都和事实相关，如交易、物流等，称之为“行为维度”，或“事实衍生的维度”。）

• 多值维度

  • 三种处理方式，可根据业务的表现形式和统计分析需求进行选择
    • 第一种，处理方式是降低事实表的粒度
    • 第二种，采用多字段
    • 第三种，采用较为通用的桥接表

• 多值属性

• 杂项维度

四 事实表设计

4.1 事实表基础

4.1.1 事实表特性

事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。

事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度；一种是所表示的具体业务含义

作为度量业务过程的事实，一般为整型或浮点型的十进制数值，有可加性、半可加性和不可加性三种类型

维度属性也可以存储到事实表中，这种存储到事实表中的维度列被称为“退化维度”。与其他存储在维表中的维度一样 ，退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。

事实表有三种类型：事物事实表、周期快照事实表、累计快照事实表。

• 事物事实表： 用来描述业务过程，跟踪空间或事件上某点的度量事件，保存的是最原子的数据，也成为“原子事实表”
• 周期快照事实表： 以具有规律性的、可预见性的事件间隔记录事实，时间间隔如每天、每月…
• 累计快照事实表： 用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间带你，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改

4.1.2 事实表设计原则

1. 尽可能包含所有与业务过程相关的事实
2. 只选择与业务过程相关的事实
3. 分解不可加性事实为可加的组件
4. 在选择维度和事实之前必须先声明粒度
5. 在同一个事实表中不能有多种不同粒度的事实
6. 事实的单位要保持一致
7. 对事实的null值要处理
8. 使用退化维度提高事实表的易用性

4.1.3 事实表设计方法

1. 选择业务员过程及确定事实表类型
   在明确了业务需求以后，接下来需要进行详细的需求分析，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程。
   在明确了流程所包含的业务过程后，需要根据具体的业务需求来选择与维度建模有关的业务过程
2. 声明粒度
   粒度的声明是事实表建模非常重要的一步，意味着精确定义事实表的每一行所表示的业务含义，粒度传递的是与事实表度量有关的细节层次。明确的粒度能确保对事实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录。
   应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。
3. 确定维度
4. 确定事实
   确定事实的过程需要将不可加性事实分解为可加的组件
5. 冗余维度
   是为了方便下游用户使用效率提高

4.2 事物事实表

任何类型的事件都可以被理解为 种事务。比如交易过程中的创订单、买家付款，物流过程中的揽货、发货、签收，退款中的申请退款、申请小 介入等，都可以被理解为 种事务。事务事实表， 即针对这些过程构建的一类事实表，用以跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库原子的明细数据。

• 设计过程

  • 1. 选择业务过程
  • 2. 确定粒度
  • 3. 确定维度
  • 4. 确定事实
  • 5. 冗余维度

• 单事物事实表

• 多事物事实表
  两种方法进行事实的处理：

  1. 不同业务过程的事实使用不同的事实字段进行存放；
  2. 不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签

• 设计过程分析

  • 业务过程： 单事务：一个； 多事务：多个
  • 粒度和维度： 单事务：相互间不相关； 多事务：粒度和维度一致
  • 事实： 单事务：只取当前业务过程中的事实； 多事务：保留多个业务过程中的事实，非当前业务过程中的事实需要置零处理
  • 下游业务使用： 单事务：易于理解，不会混淆； 多事务：难以理解，需要通过标签来限定
  • 计算存储成本： 单事务：较多，每个业务过程都需要计算存储一次； 多事务：较少 ，不同业务过程融合到一起，降低了存储计算成本，但是非当前业务过程的度量存在大量零值

• 事实的设计准则

  • 1. 事实的完整性
  • 2. 事实的一致性
  • 3. 事实可加性

4.3 周期快照事实表

• 定义：
  快照事实表在确定的间隔内对实体的度量进行抽样，这样可以很容易地研究实体的度量值，而不需要聚集长期的事务历史。

• 种类：

  • 单维度快照事实表
  • 混合维度快照事实表
  • 全量快照事实表

• 特性
  快照事实表的设计有一些 区别于事务事实表设计的性质。事务事实表的粒度能以多 种方式表达，但快照事实表的粒度通常以维度形式声明；事务事实表是稀疏的，但快照事实表是稠密的 事务事实表中的事实是完全可加的，但快照模型将至少包含一个用来展示半可加性质的事实。

  • 用快照采样状态
  • 快照粒度
  • 密度与稀疏性
  • 半可加性

• 设计步骤

  • 1. 确定快照事 表的快照粒度。
  • 2. 确定快照事实表采样的状态度量。

• 注意事项

  • 1. 事务与快照成对设计
  • 2. 附加事实
  • 3. 周期到日期度量

4.4 累积快照事实表

• 设计过程
  • 1. 选择业务过程
  • 2. 确定粒度
  • 3. 确定维度
  • 4. 确定事实
  • 5. 确定维度
• 特点
  • 1. 数据不断更新
  • 2. 多业务过程日期
• 特殊处理
  • 1. 非线性过程
  • 2. 多源过程
  • 3. 业务过程取舍
• 物理实现
  • 第一种方式是全量表的形式
  • 第二种方式是全量表的变化形式
  • 第三种方式是以业务实体的结束时间分区

4.5 三种事实表的比较

4.6 无事实的事实表

4.7 聚集型事实表

聚集主要是通过汇总明细粒度数据来获得改进查询性能的效果。通过访问聚集数据，可以减少数据库在响应查询时必须执行的工作量，能够快速响应用户的查询，同时有利于减少不同用户访问明细数据带来的结果不一致问题。尽管聚集能带来良好的收益，但需要事先对其进行加载和维护这将会对给 ETL 带来更多的挑战。

• 基本原则
  • 一致性
  • 避免单一表设计
  • 聚集粒度可不同
• 聚集的基本步骤
  • 1. 确定聚集维度
  • 2. 确定一致性上钻
  • 3. 确定聚集事实