事实表（事实模型，又称事实逻辑表）作为数据仓库维度建模的核心，紧紧围绕着业务过程进行设计。业务过程是通过事实表的度量、引用的维度与业务过程有关属性的方式获取。
表命名规范
命名规则：{project_name}.dwd{业务缩写/pub}{数据域缩写}{业务过程缩写}[{自定义表命名标签缩写}]{刷新周期标识}{单分区增量全量标识}
命名说明：
- pub表示数据包括多个业务的数据
- 单分区增量全量标识：i表示增量，f表示全量
两种类型的事实表
事务型事实表：用于描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为原子事实表
周期快照型事实表：以具有规律性的、可预见的时间间隔（例如每天、每月、每年等）记录事实
事实表设计原则
尽可能包含所有与业务过程相关的事实
设计事实表的目的是度量业务过程，所以分析哪些事实与业务过程有关，是事实表设计中至关重要的。在事实表中应该尽量包含所有与业务过程相关的事实，即使存在冗余，但是因为事实通常为数字型，带来的存储开销不会很大
只选择与业务过程相关的事实
在选择事实时应该注意，只选择与业务过程有关的事实。例如，A公司的订单交易业务流程中，在设计下单这个业务过程的事实表时，不能包含支付金额这个表示支付业务过程的事实
在选择维度和事实之前，必须先声明粒度
粒度（数据行数的最小单位，非统计粒度）的声明是事实表设计中不可忽视的重要一步。粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性。在选择维度和事实之前，必须先声明粒度，且每个维度和事实必须与所定义的粒度保持一致。在事实表中，通常通过业务描述来表述粒度并定义事实表主键，但对于聚集性事实表的粒度描述（例如存在下单、支付等多个事务），可以基于多个字段拼接，形成新的字段作为事实表主键，也可以不定义主键，这样一行记录即最小粒度
在同一个事实表中，不能包含多种不同粒度的事实
事实表中所有事实的粒度需要与表声明的粒度保持一致，在同一个事实表中不能有多种不同粒度的事实
事实的单位要保持一致
在同一个事实表中，事实的单位应该保持一致。例如，原订单金额、 订单优惠金额、订单运费金额这三个事实，应该采用一致的计量单位，例如统一为元，以方便使用
事务型事实表设计准则
事务型事实表主要用于分析行为与追踪事件。事务事实表获取业务过程中的事件或者行为细节，然后通过事实与维度之间关联，可以非常方便地统计各种事件相关的度量，例如浏览UV，搜索次数等等。
- 基于数据应用需求的分析设计事务型事实表，如果下游存在较大的针对某个业务过程事件的分析指标需求，可以考虑基于某一个事件过程构建事务型事实表。
- 事务型事实表一般选用事件发生日期或时间作为分区字段，这种分区方式可以方便下游的作业数据扫描执行分区裁剪。
- 明细层事实表的冗余子集的原则能有利于降低上层数据访问的IO开销。
- 明细层事实表维度退化到事实表原则能有利于减少上层数据访问的JOIN成本。
周期快照型事实表
周期快照型事实表主要用于分析状态型或者存量型事实。快照是指以预定的时间间隔来采样状态度量。
累计快照事实表
累计快照事实表是基于多个业务过程联合分析从而构建的事实表，如采购单的流转环节等。
累计快照事实表主要用于分析事件之间的时间间隔与周期。例如，用交易的支付与发货之间的间隔，来分析发货速度，或在支付和退款环节分析支付退款率等等。
累计快照事实表同时也可以用于帮助分析一些少量的、且对刷新时间不是非常敏感的指标统计。例如，在当前事务型事实表不支持，且只有少量的统计指标时，需要分析交易的关闭和发货，就可以基于累计快照事实表进行计算。
事实表设计方法
任何类型的事件都可以被理解为一种事务。例如，交易过程中的创建订单、买家付款，物流过程中的揽货、发货、签收，退款过程中的申请退款、申请客服介入等，都可以被理解为一种事务。事务型事实表，即针对这些过程构建的一类事实表，用以跟踪定义业务过程的个体行为，提供丰富的分析能力，作为数据仓库CDM层的明细数据。
下面以A公司的订单交易事务型事实表为例，阐述事务型事实表的一般设计过程。
选择业务过程。按照之前的业务流程分析，A公司的交易订单流程包含四个重要过程：创建订单、买家付款、卖家发货、确认收货，即下单、支付、发货和收货四个业务过程。这四个业务过程不仅是交易过程中的重要时间节点，而且也是下游统计分析的重点，因此A公司的交易事务事实表设计着重从这四个业务过程进行展开。为了便于进行独立的分析研究，我们应该为每个业务过程建立一个事实表。本教程中，我们选择交易成功这个业务过程，建立事务型事实表。
确定粒度。事实表中一条记录所表达的业务细节程度被称为粒度。通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度；一种是所表示的具体业务含义（例如商品）。业务过程选定之后，就要针对业务过程确定一个粒度，即确定事务型事实表每一行所表达的细节层次。明确的粒度能确保对事实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录。如果有字段可以表达这个粒度，可以定义为事实表的主键。应该尽量选择最细级别的粒度，以确保事实表的应用具有最大的灵活性。对于订单过程而言，每一种商品结算后都会产生一个订单，交易成功这个业务过程的粒度可以选择为订单。订单ID如果唯一，可以作为事实表主键以描述粒度。
确定维度。选定好业务过程并且确定粒度之后，就可以确定维度信息了，应该选择能够描述清楚业务过程所处的环境的维度信息。例如，在A公司的交易订单事务事实表设计过程中，粒度为订单，确定的维度包含：买家、卖家、商品名称、商品类目、发货地区、收货地区、订单时间等维度。
确定事实。作为度量业务过程的核心，事实通常为整型或浮点型的十进制数值。事实表应该包含与业务过程描述有关的所有事实，且事实的粒度要与所确定的事实表的粒度一致。例如，在下单业务过程中，需要包含商品ID、商品价格、购买数量。在支付业务过程中，需要包含支付金额、红包金额、积分金额。在收货业务过程中，需要包含确认收货金额等。
关联维度。在确定维度时，包含了买卖家维度、商品维度、类目维度、收发货维度等。维度建模理论建议在事实表中只保存这些维表的外键， 而A公司电商交易事务事实表在维度建模基础之上做了进一步的优化，将买卖家星级、标签、店铺名称、商品类型、商品特征、商品属性、 类目层级等维度都关联到事实表中，提高对事实表进行过滤查询、统计聚合的效率。
数据存储及生命周期管理规范
CDM明细层的表的类型为事实表，存储方式为按天分区。
事务型事实表一般永久保存。周期快照型事实表根据业务需求设置生命周期管理。您可依据3个月内的最大需要访问的跨度设置保留策略，具体计算方式如下：
- 当3个月内的最大访问跨度小于或等于4天时，建议将保留天数设为7天。
- 当3个月内的最大访问跨度小于或等于12天时，建议将保留天数设为15天。
- 当3个月内的最大访问跨度小于或等于30天时， 建议将保留天数设为33天。
- 当3个月内的最大访问跨度小于或等于90天时，建议将保留天数设为93天。
- 当3个月内的最大访问跨度小于或等于180天时， 建议将保留天数设为183天。
- 当3个月内的最大访问跨度小于或等于365天时，建议将保留天数设为368天。
若有收获，就点个赞吧
0 人点赞
