模型设计

模型设计概述

为什么需要模型设计？

Linux 的创始人 Torvalds 有一段关于“什么才是优秀程序员”的话:“烂程序员关心的是代码，好程序员关心的是数据结构和它们之间的关系”，其阐述了数据模型的重要性。有了适合业务和基础数据存储环境的模型，那么大数据就能获得以下好处。

性能 :良好的数据模型能帮助我们快速查询所需要的数据，减少数据的吞吐。
成本 :良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，极大地降低大数据系统中的存储和计算成本。
效率 :良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。
质量 :良好的数据模型能改善数据统计口径的不一致性，减少数据计算错误的可能性。

因此，毋庸置疑，大数据系统需要数据模型方法来帮助更好地组织和存储数据，以便在性能、成本、效率和质量之间取得最佳平衡。

模型设计理论

两种经典的数据仓库建模方法

维度建模理论

维度模型是数据仓库领域大师Ralph Kimball 所倡导的。他的 The Data Warehouse Tolkit-The Complete Guide to Dimensional Modeling 是数据仓库工程领域最流行的数据仓库建模的经典。维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能，更直接面向业务。典型的代表是我们比较熟知的星形模型。

星型模型由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。

其设计分为以下几个步骤。

选择需要进行分析决策的业务过程。业务过程可以是单个业务事件，比如交易的支付、退款等;也可以是某个事件的状态，比如当前的账户余额等;还可以是一系列相关业务事件组成的业务流程，具体需要看我们分析的是某些事件发生情况，还是当前状态，或是事件流转效率。
选择粒度。在事件分析中，我们要预判所有分析需要细分的程度，从而决定选择的粒度。粒度是维度的一个组合。
识别维表。选择好粒度之后，就需要基于此粒度设计维表，包括维度属性，用于分析时进行分组和筛选。
选择事实。确定分析需要衡量的指标.

优点：技术要求不高，快速上手，敏捷迭代，快速交付；更快速完成分析需求，较好的大规模复杂查询的响应性能。

缺点：维度表的冗余会较多，视野狭窄。

现在使用较多的就是维度建模。我们主要讲述的也是维度建模。

ER建模理论

也叫关系建模

数据仓库之父Bill lnmon推崇的、从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象。它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。

雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。

其建模步骤分为三个阶段。

高层模型:一个高度抽象的模型，描述主要的主题以及主题间的关系，用于描述企业的业务总体概况。
中层模型:在高层模型的基础上，细化主题的数据项。
物理模型(也叫底层模型):在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一

些表的合并、分区的设计等。

ER 模型在实践中最典型的代表是 Teradata 公司基于金融业务发布的 FS-LDM (Financial Services Logical Data Model)，它通过对金融业务的高度抽象和总结，将金融业务划分为 10 大主题，并以设计面向金融仓库模型的核心为基础，企业基于此模型做适当调整和扩展就能快速落地实施。

优点：规范性较好，冗余小，数据集成和数据一致性方面得到重视，比如运营商可以参考国际电信运营业务流程规范（ETOM），有所谓的最佳实践。

缺点：需要全面了解企业业务、数据和关系；实施周期非常长，成本昂贵；对建模人员的能力要求也非常高，容易烂尾。

模型设计基本原则

高内聚和低辑合

一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低藕合原则。主要从数据业务特性和访问特性两个角度来考虑 :将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型:将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。

核心模型与扩展模型分离

建立核心模型与扩展模型体系，核心模型包括的宇段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的宇段过度侵人核心模型，以免破坏核心模型的架构简洁性与可维护性。

公共处理逻辑下沉及单一

越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。

成本与性能平衡

适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。

数据可回滚

处理逻辑不变，在不同时间多次运行数据结果确定不变。

一致性

具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。

命名清晰、可理解

表命名需清晰、一致，表名需易于消费者理解和使用。

模型设计分层规范

分层目标

为了让数据体系更加有序，我们需要一套行之有效的数据组织和管理方法，这就是数据分层。数据分层并不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：

清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解
减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题
数据血缘追踪：能够快速准确地定位到问题，并清楚它的危害范围。

分层规范

数据仓库封层并没有绝对的规范，具体分层方式取决于设计者的设计思路，但大致的分层方式是一致的。我们将数据仓库分为四层：

ODS层：原始数据层，主要内容：
- 同步，数据增量或全量同步到数据仓库。
- 存放原始数据，直接加载原始日志、数据，数据保持原貌不做处理。
DWD层：明细数据层，主要有两部分内容：
- 对ODS层数据进行清洗（去除空值、脏数据、超过极限范围的数据）、按主题归类。
- 进行维度建模。维度退化、脱敏等。
- 累计历史数据。增量合并成全量。

DWS层：服务数据层，服务层是核心层，主要有三部分内容：

* 以DWD层的数据为基础，按维度（通常是时间维度：日，月等）进行轻度汇总。

* 数据宽表，通常安装某个主题进行汇总，获得每个主题的全量数据表。

* 核心KPI表。

ADS层：数据应用层，面向实际的数据需求，为各种统计报表提供数据
DIM层：数据维度层，存放清洗后的维度表，整个模型共用一套维度。

分层理念

分层的思路如下：

从对应用的支持来讲，我们希望越靠上层次，越对应用友好。比如ADS层，基本是完全为应用来设计的，很易懂，DWS层的话，相对来讲就会有一点点理解成本，因为它的维度可能会比较多，而且一个需求可能要多张表经过很复杂的计算才能完成。
从能力范围来讲，我们希望80%需求由20%的表来支持。直接点讲，就是大部分（80%以上）的需求，都用DWS的表来支持就行，DWS支持不了的，就用DWD的表来支持，这些都支持不了的极少一部分数据需要从原始数据中捞取。结合第一点来讲的话就是：80%的需求，我们都希望以对应用很友好的方式来支持，而不是直接暴露给应用方原始日志。
从数据聚合程度来讲，我们希望，越上层数据的聚合程度越高，看上面的例子即可，ODS和DWD的数据基本是原始日志的粒度，不做任何聚合操作，DWS做了更高的聚合操作。从这个角度来看，我们又可以理解为我们是按照数据的聚合程度来划分数据层次的。
从数据流向来讲，我们希望数据从底层向高层流动，上层调用下层的数据，禁止下层调用上层的数据。DWD层可以调用ODS层数据，DWS层调用DWD层数据，但DWD不能调用DWS层数据。

命名规范

DIM命名规范

{project_name}.dim_{维度名称}[_{自定义命名标签}]。

例如： bdp.dim_sku_info（商品维度表） bdp.dim_activity（活动维度表);

ODS层命名规范

表命名规范 :

非去重增量数据（只有新增）：{project_name}.ods_{源系统表名}_add
增量数据(数据有更新)：{project_name}.ods_{源系统表名}_delta
全量数据 (每个分区全量数据): {project_name}.ods_{源系统表名}_all
非分区表： {project_name}.ods_{源系统表名}
ODS ETL过程的临时表：{project_name}.ods_tmp_{临时表所在过程的输出表}_{从0开始的序号}
按小时的非去重增量数据（只有新增）：{project_name}.ods_{源系统表名}_add_hh
按小时的增量表(数据有更新)：{project_name}.ods_{源系统表名}{delta}{hh}
按小时的全量表：{project_name}.ods_{源系统表名}_all_{hh}
当从不同源系统同步到一个project下表命名冲突时，后进来的表的命名加上源系统的_dbname。

字段命名规范

字段默认使用源系统字段名称
字段名与数据库关键字冲突时处理规则：加一个”_col”后缀，即：源字段名_col

DWD层命名规范

{project_name}.dwd_{PUB/数据主题缩写}_{业务过程缩写}[_{自定义表命名标签缩写}]_{刷新周期标识}{单分区增量全量标识}

pub表示数据包括多个主题的数据.

刷新周期标识：h表示小时更新，d表示天更新，m表示月更新，y表示年更新。

单分区增量全量标识：i表示增量，f表示全量。

bdp.dwd_trd_order_info_di 订单表

bdp.dwd_tb_rsk_remark_df

DWS层命名规范

{project_name}.dws_{PUB/数据主题缩写}_{业务过程缩写}[_{自定义表命名标签缩写}]_{刷新周期标识}{单分区增量全量标识}

pub表示数据包括多个主题的数据.

刷新周期标识：h表示小时更新，d表示天更新，m表示月更新，y表示年更新。

单分区增量全量标识：i表示增量，f表示全量。

bdp.dws_trd_order_info_di 订单表

bdp.dws_tb_rsk_remark_full_df

宽表的命名 di或df前面加 _full

仓库实施过程

数据调研

一般电商业务的功能模块：

商品管理：商品上架、下架、商品名称修改、商品类目修改、库存管理、商品页面管理等。
用户管理：新增用户、用户注册、登录、信息修改、用户积分、等级等。
交易过程：加购物车，下单，支付，发货，收货，退货，退款等。
用户行为：商品浏览、页面点击操作等。
用户互动：商品评价，分享等。
物流管理：发货，签收等、物流公司管理。
供应链：采购、入库，供应商管理。
客服：投诉，举报，问题咨询。
营销：营销活动策划，商品宣传。

主要的业务过程：

1、购物过程：加购物车–>下单–>支付–>发货–>收货–>退货–>退款。

2、采购过程

3、营销过程

主题划分规范

数据仓库都是面向主题的，主题通常根据业务过程进行划分。划分主题是为了对事实表进行归类，方便找到。最好做到望文知意，根据主题名称就知道想要的数据在哪个主题下。

根据业务过程，主题划分如下：

日志主题：也是用户行为主题，跟日志相关的业务过程，主题简称：log。
交易主题：跟交易过程相关的数据。订单表、订单明细表、支付表、加购物车标。主题简称： trd 。
互动主题：跟商品喜好与评价相关的数据，评价表。主题简称： com。
营销主题：跟营销和活动以及优惠相关的数据。优惠券领用表、营销活动表。主题简称：mrk 。
物流主题：跟物流相关数据。物流单表。主题简称 logi
用户主题：用户相关数据。用户注册、登录，积分。
商品主题: 商品上架，下架，库存，宣传物料等。
供应链主题：采购相关数据。采购，入库，出口等。
客服主题：客户相关数据。投诉、举报、咨询等。

业务总线

在进行充分的业务调研和需求调研后，就要构建总线矩阵了。需要做两件事情 :明确每个数据域下有哪些业务过程;业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。

业务过程	时间	买家	商品	优惠券	地域	物流公司	度量
下单	√	√	√	√	√		订单金额/件数/折扣金额
支付	√	√					支付金额
发货	√	√			√	√	件数
收货	√	√	√

维度设计

维度定义

维度是维度建模的基础和灵魂。在维度建模中，将度量称为事实 ，将环境描述为维度，维度是用于分析事实所需要的多样环境。例如，在分析交易过程时，可以通过买家、商品和时间等维度描述交易发生的环境。

维度设计的基本步骤

第一步:选择维度或新建维度。作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以商品维度为例，有且只允许有一个维度定义。
第二步:确定主维表。此处的主维表一般是 ODS 表，直接与业务系统同步。以商品维度为例，SKU表是主维表。
第三步:确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生维度属性。以商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、 SPU、品牌维度存在关联关系。
第四步 :确定维度属性。本步骤主要包括两个阶段，其中第一个阶段是从主维表中选择维度属性或生成新的维度属性;第二个阶段是从相关维表中选择维度属性或生成新的维度属性。
- 维度属性的设计方法：
  
  (1)尽可能生成丰富的维度属性

比如SKU商品维度有很多个维度属性，为下游的数据统计、分析、探查提供了良好的基础。

比如：用户维表：综合了用户的基本属性，用户使用的手机硬件属性和用户积分等级属性内容。

（2)尽可能多地给出包括一些富有意义的文字性描述

属性不应该是编码，而应该是真正的文字。一般是编码和文字同时存在，比如SKU维度中的SKU ID 和SKU名称、类目 ID 和类目名称等。 ID 一般用于不同表之间的关联，而名称一般用于报表标签。

(3)区分数值型属性和事实

数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性; 如果通常用于参与度量的计算，则是作为事实。比如SKU商品价格，可以用于查询约束条件或统计价格区间的商品数量，此时是作为维度属性使用的;也可以用于统计某类目下商品的平均价格，此时是作为事实使用的。另外，如果数值型字段是离散值，则作为维度属性存在的可能性较大;如果数值型宇段是连续值，则作为度量存在的可能性较大，但并不绝对，需要同时参考宇段的具体用途。

(4)尽量沉淀出通用的维度属性

有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表的不同宇段混合处理得到，或者通过对单表的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进行沉淀。一方面，可以提高下游使用的方便性，减少复杂度; 一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。

维度的层次结构设计（维度退化）

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

当属性层次被实例化为一系列维度，而不是单一的维度时，被称为雪花模式。大多数联机事务处理系统( OLTP)的底层数据结构在设计时采用此种规范化技术，通过规范化处理将重复属性移至其自身所属的表中，删除冗余数据。

这种方法用在 OLTP 系统中可以有效避免数据冗余导致的不一致

性。比如在 OLTP 系统中，存在商品表和类目表，且商品表中有冗余的类目表的属性字段，假设对某类目进行更新，则必须更新商品表和类目表，且由于商品和类目是一对多的关系，商品表可能每次需要更新几十万甚至上百万条记录，这是不合理的。而对于联机分析处理系统( OLAP) 来说，数据是稳定的，不存在 OLTP 系统中所存在的问题。

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

维度层次缩减是维度设计的核心内容。也称之为维度退化。

在本例中，地区表和省份表退化为地区维度表，SKU商品表、品牌表、商品三级品类表、商品二级品类表、商品一级品类表退化为商品维度表，活动订单关联表和优惠规则表退化为活动维度表。

事实表设计

设计过程

(1)选择业务过程

业务过程通常使用行为动词表示业务执行的活动。比如交易单的业务过程有四个:创建订单、买家付款、卖家发货、买家确认收货。在明确了流程所包含的业务过程后，需要根据具体的业务需求来选择与维度建模有关的业务过程。比如是选择买家付款这个业务过程，还是选择创建订单和买家付款这两个业务过程，具体根据业务情况来确定。

在选择了业务过程以后，相应的事实表类型也随之确定了。比如选择买家付款这个业务过程，那么事实表应为只包含买家付款这一个业务过程的单事务事实表;如果选择的是所有四个业务过程，并且需要分析各个业务过程之间的时间间隔，那么所建立的事实表应为包含了所有四个业务过程的累积快照事实表。

(2)确定粒度

粒度的声明是事实表建模非常重要的一步，意味着精确定义事实表的每一行所表示的业务含义，粒度传递的是与事实表度量有关的细节层次。明确的粒度能确保对事实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录。

应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。同时对于订单过程而言，粒度可以被定义为最细的订单级别。比如在订单中有订单和订单详情（子订单）的概念，即一个订单详情对应一种商品，如果拍下了多种商品，则每种商品对应一个订单详情；这些订单详情（子订单）一同结算的话，则会生成一个订单。那么在这个例子中，事实表的粒度应该选择为子订单级别。

(3)确定维度

完成粒度声明以后，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。比如在付款事务事实表中，粒度为订单，相关的维度有买家、商品、收货人信息、订单时间等维度。

(4)确定事实

事实可以通过回答“过程的度量是什么”来确定。应该选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致。事实有可加性、半可加性、非可加性三种类型，需要将不可加性事实分解为可加的组件。

比如在淘宝订单付款事务事实表中，支付金额是事实。

(5)冗余维度

在传统的维度建模的星形模型中，对维度的处理是需要单独存放在专门的维表中的，通过事实表的外键获取维度。这样做的目的是为了减少事实表的维度冗余，从而减少存储消耗。而在大数据的事实表模型设计中，考虑更多的是提高下游用户的使用效率，降低数据获取的复杂性，减少关联的表数量。所以通常事实表中会冗余方便下游用户使用的常用维度，以实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等操作。

比如在付款事务事实表中，通常会冗余大量的常用维度字段，以及商品类目、卖家店铺等维度信息。

设计原则

原则 1 :尽可能包含所有与业务过程相关的事实

事实表设计的目的是为了度量业务过程，所以分析哪些事实与业务过程有关是设计中非常重要的关注点。在事实表中应该尽量包含所有与业务过程相关的事实，即使存在冗余，但是因为事实通常为数字型，带来的存储开销也不会很大。
原则 2:只选择与业务过程相关的事实

在选择事实时，应该注意只选择与业务过程有关的事实。比如在订单的下单这个业务过程的事实表设计中，不应该存在支付金额这个表示支付业务过程的事实。
原则 3: 分解不可加性事实为可加的组件

对于不具备可加性条件的事实，需要分解为可加的组件。比如订单的优惠率，应该分解为订单原价金额与订单优惠金额两个事实存储在事实表中。
原则 4:在选择维度和事实之前必须先声明粒度

粒度的声明是事实表设计中不可忽视的重要一步，粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性，在选择维度和事实之前必须先声明粒度，且每个维度和事实必须与所定义的粒度保持一致。在设计事实表的过程中，粒度定义得越细越好，建议从最低级别的原子粒度开始，因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求。在事实表中，通常通过业务描述来表述粒度，但对于聚集性事实表的粒度描述，可采用维度或维度属性组合的方式。
原则 5: 在同一个事实表中不能有多种不同粒度的事实事实表中的所有事实需要与表定义的粒度保持一致，在同一个事实表中不能有多种不同粒度的事实。
原则 6:事实的单位要保持一致

对于同一个事实表中事实的单位，应该保持一致。比如原订单金额、订单优惠金额、订单运费金额这三个事实，应该采用一致的计量单位，统一为元或分，以方便使用。
原则 7: 对事实的 null值要处理

对于事实表中事实度量为 null 值的处理，因为在数据库中 null 值对常用数字型字段的 SQL 过滤条件都不生效，比如大于、小于、等于、大于或等于、小于或等于，建议用零值填充。
原则 8:使用退化维度提高事实表的易用性

在 Kimball 的维度建模中，通常按照星形模型的方式来设计，对于维度的获取采用的是通过事实表的外键关联专门的维表的方式，谨慎使用退化维度。而在大数据领域的事实表设计中，则大量采用退化维度的方式，在事实表中存储各种类型的常用维度信息。这样设计的目的主要是为了减少下游用户使用时关联多个表的操作，直接通过退化维度实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等。通过增加冗余存储的方式减少计算开销，提高使用效率。

单事务事实表

单事务事实表，顾名思义，即针对每个业务过程设计一个事实表。这样设计的优点不言而喻，可以方便地对每个业务过程进行独立的分析研究。

多事务事实表

多事务事实表，将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。多事务事实表在设计时有两种方法进行事实的处理 :

1、不同业务过程的事实使用不同的事实字段进行存放。

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

周期快照事实表

当需要一些状态度量时，比如账户余额、商品库存、卖家累积交易额等，则需要聚集与之相关的事务才能进行识别计算 ;或者聚集事务无法识别，比如温度等。对于这些状态度量，事务事实表是无效率的，而这些度量也和度量事务本身一样是有用的，因此，维度建模理论给出了第二种常见的事实表一一周期快照事实表，简称“快照事实表”。快照事实表在确定的问隔内对实体的度量进行抽样，这样可以很容易地研究实体的度量值，而不需要聚集长期的事务历史。

在本项目中，用户积分表和DWS层宽表都是采用周期快照事实表进行设计。

累计快照事实表

针对电商交易，设计了电商交易下单/支付/确认收货事务事实表，用于统计下单/支付/确认收货的子订单数， GMV 等。但仍然有很多需求，此事务事实表很难满足，比如统计买家下单到支付的时长、买家支付到卖家发货的时长、买家从下单到确认收货的时长等。如果使用事务事实表进行统计，则逻辑复杂且性能很差。对于类似于研究事件之间时间间隔的需求，采用累积快照事实表可以很好地解决。累计快照事实表一条记录通常描述一个完整的业务过程，使用起来也比较方便。

本项目中，订单表用累积快照事实表进行设计。

无事实的事实表

维度模型中，事实表用事实来度量业务过程，不包含事实或度的事实表称为“无事实的事实表\虽然没有明确的事实，但可以用来支持业务过程的度量。

常见的无事实的事实表主要有如下两种:

第一种是事件类的，记录事件的发生。最常见的是日志类事实表。比如用户的浏览日志，某会员某时间点浏览了首页、某会员某时间点浏览了某商品详情页等。对于每次点击，其事实为1，但一般不会保存此事实。

第二种是条件、范围或资格类的，记录维度与维度多对多之间的关系。比如客户和销售人员的分配情况、产品的促销范围等。

在本项目中，用户行为日志采用无事实事实表设计。页面日志表，启动日志表，错误日志表。

聚集型事实表

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