文章目录
1. 引言
1.1基本概念
事实表，顾名思义，是用来存储事实的表，这些事实通常是指可以量化的业务指标，如销售额、订单数量等。事实表的特点是有大量的行，每行代表一个业务事件的度量。
换句话说就是你要关注事物的内容，事实表就像故事中的主角，它包含我们感兴趣的主要信息（如销售金额、订购数量、利润以及它们发生的时间和地点等）。事实表中的每一行数据都代表了某种业务活动，就好比故事中的一个关键事件一样。
比如，一张记录了公司所有业务交易的清单。每一条记录都是一个事实，比如一次销售或一笔支出。
举个例子，假设我们有一个简单的销售事实表，它记录了每次销售的金额和日期：
CREATE TABLE Sales_Fact (
SaleID INT PRIMARY KEY,
ProductID INT,
SaleAmount DECIMAL(10,2),
SaleDate DATE
);
在这个例子中，SaleID 是每条销售记录的唯一标识，ProductID 与维度表相关联，SaleAmount 是销售金额，SaleDate 是销售日期。
其他详细内容可以看：数据仓库核心：揭秘事实表与维度表的角色与区别
1.2 事实表定义
事实表是数据仓库中的核心，它与维度表相对应，存储了业务过程中量化的数据，也就是我们通常所说的度量值（measures）。事实表通常包含以下主要部分：
- 度量值：这些是事实表中的主要数据，可以进行数值计算，如销售额、订单数量、产品单价等。
- 维度键：这些是指向维度表的外键，通过它们，事实表与维度表相连，从而为度量值提供上下文信息。
- 上下文信息：提供额外的业务信息，如时间戳、事务ID等。
“粒度”描述了事实表中每条记录所捕捉到的业务细节的深度。它可以通过两个维度来衡量：首先是维度属性的组合，它们决定了数据条目的详细程度；其次是数据条目所代表的具体业务含义。
如果我们选择“产品维度”的“SKU”作为粒度，那么我们的数据条目将非常详细，因为每个SKU都是独特的，能够反映单个商品的销售情况。例如，一个数据条目可能表示“在2024年6月10日，北京地区，某款智能手机的销售额为3000元”。
事实表中的数据，作为衡量业务流程的量度，通常以整数或小数形式出现，并分为三种可加性类型：
- 可加性事实：这类数据允许我们在事实表的任何维度上进行汇总。例如，我们可以将不同时间或地区的销售数据进行求和，以得到总销售额。
一个销售数据的事实表，记录了每笔交易的销售额。如果我们要计算总销售额，我们可以将所有交易的销售额相加：
2024年1月1日，北京，销售额100元。
2024年1月1日，上海，销售额200元。
2024年1月2日，北京，销售额150元。
- 半可加性事实：这类数据仅能在特定的维度上进行汇总。以库存为例，我们可以按地点或商品类别进行汇总，但如果尝试按时间维度累加每个月的库存量，这种汇总就失去了实际意义。
分析库存数据，库存数量可以按地点或商品类别进行汇总，但按时间维度累加就没有意义。例如：
2024年1月1日，北京，库存数量50件。
2024年1月1日，上海，库存数量30件。
我们可以计算北京和上海的总库存数量：80件。但如果我们尝试将1月份每天的库存数量累加，这就没有意义，因为库存数量是随时间变化的，每天的库存数量并不是独立的，而是相互关联的。
- 不可加性事实：这类度量无法通过任何维度进行汇总，例如比率或百分比。然而，即使是不可加性事实，我们通常也可以通过将其分解为可加的组成部分，来实现某种形式的聚合分析。
记录了每个订单的利润率（销售额减去成本后的百分比），这个度量就是不可加的。例如：
订单1的利润率是20%。
订单2的利润率是15%。
我们不能简单地将这两个利润率相加得到一个总体的利润率。相反，如果我们想要得到平均利润率，我们需要先计算每个订单的实际利润，然后将这些利润相加，最后除以订单的总数。例如：
订单1的销售额是100元，成本是80元，利润是20元。
订单2的销售额是150元，成本是130元，利润是20元。
总利润是40元，订单总数是2，所以平均利润率是 40/(100+150)=16.67%
2. 设计原则
2.1 原则一：全面覆盖业务相关事实
事实表设计的核心目标是全面捕捉业务流程的每一个细节。在设计时，我们应该无一遗漏地纳入所有与业务过程紧密相关的量化事实，哪怕这可能导致数据的轻微冗余。由于事实数据通常以数字形式存储，其对存储空间的影响相对较小。
案例：在一家零售店，事实表不仅记录了每笔交易的销售额，还记录了交易时间、顾客ID和购买的商品种类。即使某些信息如交易时间在某些分析中不是必需的，它的包含仍然为更全面的业务分析提供了可能。
2.2 原则二：精选与业务过程紧密相关的事实
在挑选事实时，我们必须严格筛选，确保只包含那些直接与当前业务过程相关的事实。这有助于保持数据的清晰性和分析的准确性。
案例：在一个电商平台的订单处理过程中，事实表应记录订单号、商品详情和顾客信息，而支付金额则属于支付过程的事实，应从订单事实表中排除。
2.3 原则三：拆分不可加事实为可加度量
面对不可直接汇总的度量，我们应通过创造性地拆分，将其转化为可加的组成部分，从而扩展分析的可能性。
案例：网站的用户访问数据中，如果记录了每个页面的浏览次数和独立访客数，我们可以将“购买率”这一不可加事实拆分为“购买人数”和“浏览人数”，使得原本难以聚合的数据变得可以分析。
2.4 原则四：明确声明事实表的粒度
在设计事实表时，粒度的选择至关重要。我们应从最细的原子粒度开始设计，以满足当前和未来可能的用户需求。
案例：销售事实表可能以单个交易为粒度，记录每一次购买的详细信息。而在汇总销售数据时，我们可以按商品、时间或地区等维度进行聚合。
2.5 原则五：避免同一事实表中存在不同粒度的事实
在一张事实表中，应避免混合不同粒度的事实，以防止汇总时出现重复计算的问题。
案例：如果事实表同时记录了单个订单和包含多个子订单的大订单，那么在汇总支付金额时，大订单中的子订单金额可能会被重复计算。
| 小订单ID | 大订单ID | 小订单付款金额 | 小订单购买数量 | 大订单付款金额 |
|---|---|---|---|---|
| L1001 | B1 | 100 | 1 | 300 |
| L1002 | B1 | 200 | 1 | 300 |
| L1003 | B2 | 150 | 1 | 200 |
| L1004 | B2 | 50 | 1 | 200 |
2.6 原则六：统一事实的度量单位
在事实表中，所有度量单位应保持一致，无论是货币单位还是数量单位，这有助于简化分析过程并避免混淆。
案例：在财务事实表中，所有的金额数据都应该统一为“元”或“分”，确保在进行财务分析时的一致性和准确性。
2.7 原则七：妥当处理事实的null值
由于null值在某些查询中无法参与计算，我们应事先设定规则，将null值替换为零或其他适当的默认值。
案例：如果销售事实表中的“退货数量”字段出现null，我们可以将其默认填充为0，以避免在计算总销售数量时出现错误。
2.8 原则八：使用退化维度提升事实表的可用性
通过将常用维度属性直接嵌入到事实表中，我们可以减少对维度表的依赖，提高查询效率。
案例：在销售事实表中，如果将“商品名称”作为退化维度直接包含，那么在进行商品销售分析时，就无需额外关联商品维度表，从而加快查询速度并减少I/O操作。
3. 设计方法
3.1 事实表设计流程
在构建数据仓库的事实表之前，我们必须首先深入挖掘并明确业务的核心需求，以及确定事实表所扮演的角色。这一步骤要求我们对业务流程进行全面的需求分析，洞察整个业务生命周期的每一个关键步骤，并且精准筛选出与我们需求紧密相连的业务活动。
接下来，我们必须精确地声明事实表的粒度，力求达到原子级别的细节，以便捕捉业务活动中最细微的变化。
在粒度确定之后，我们也随之锁定了事实表的主键。基于此，我们可以识别出与这些主键相关联的维度组合，以及它们所包含的维度字段。
我们还需要明确在这个业务过程中所度量的关键指标是什么，并确保将不可加的度量进行适当的拆分，以便于进行有效的数据聚合。
此外，为了优化查询性能和减少数据冗余，我们应该尽可能地将维度属性退化并直接嵌入到事实表中，这样不仅提升了数据的可用性，也简化了数据模型。
3.2 设计案例：订单事实表
案例背景：
假设我们正在为一家电子商务公司设计一个订单事实表，该公司希望分析销售数据以优化库存管理和促销策略。
步骤1：确定业务需求和事实表的类型
- 我们与业务团队合作，明确了需求：分析订单数据，包括销售额、订单量、顾客购买行为等。
步骤2：进行详细的需求分析
- 我们分析了订单处理的整个生命周期，从顾客浏览商品到最终的订单交付。
步骤3：声明粒度
- 我们选择了订单级别的原子粒度，确保每一条记录都对应一个具体的订单事件。
步骤4：确定维度
- 基于订单粒度，我们确定了以下维度：顾客、时间、产品、促销活动等。
步骤5：确定事实
- 我们确定了以下度量指标：订单总金额、订单中商品的总数量、退货数量等。对于不可加的度量，如退货率，我们进行了适当的转换以便聚合。
步骤6：冗余维度
- 为了提高查询效率，我们将一些常用的维度属性，如顾客的地区信息，退化并直接包含在事实表中。
CREATE TABLE IF NOT EXISTS order_fact_table (
order_id INT COMMENT '唯一标识每个订单的ID',
customer_id INT COMMENT '下单顾客的ID',
order_date DATE COMMENT '订单的日期',
product_id INT COMMENT '订单中商品的ID',
quantity INT COMMENT '订单中商品的数量',
unit_price DECIMAL(10, 2) COMMENT '商品的单价，保留两位小数，确保金额的精确度',
total_amount DECIMAL(15, 2) COMMENT '订单的总金额，保留两位小数，适用于大金额订单',
return_quantity INT COMMENT '订单的退货数量，默认为0，表示没有退货',
promotion_id INT COMMENT '订单参与的促销活动ID，如果有的话',
customer_region STRING COMMENT '顾客所属的地区，使用字符串存储'
)
COMMENT '订单事实表，存储订单相关的详细数据'
ROW FORMAT DELIMITED
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n'
STORED AS TEXTFILE;
4. 事务类型
4.1 单、多事务事实表
单事务事实表结构简单，易于管理，适用于单一且独立的业务记录。多事务事实表则适用于复杂的业务场景，能够记录多个相关联的事务，但设计和理解上更为复杂。
| 特性 | 单事务事实表 | 多事务事实表 |
|---|---|---|
| 业务过程 | 一个 | 多个 |
| 粒度 | 相互间不相关 | 相同粒度 |
| 维度 | 相互间不相关 | 一致 |
| 事实 | 只取当前业务过程中的事实 | 保留多个业务过程中的事实，非当前业务过程中的事实需要置零处理 |
| 理解程度 | 易于理解，不会混淆 | 难以理解，需要通过标签来限定 |
| 计算存储成本 | 较少，不同业务过程融合到一起，降低了存储计算量，但是非当前业务过程的度量存在大量零值 | 较多，每个业务过程都需要计算，存储一次 |
4.2 其他事实表
事务事实表适用于记录具体事务的瞬间数据，周期快照事实表用于定期捕获数据状态，而累积快照事实表则追踪业务过程的完整历史，提供连续的数据视图。每种表根据其更新和加载机制，服务于不同的数据分析需求。
| 特性 | 事务事实表 | 周期快照事实表 | 累积快照事实表 |
|---|---|---|---|
| 时期/时间点 | 离散事务时间点 | 以有规律的、可预测的时期间隔产生快照 | 用于时间跨度不确定的不断变化的工作流 |
| 日期维度 | 事务日期 | 快照日期 | 相关业务过程涉及的多个日期 |
| 粒度 | 每行代表一个事务 | 每行代表某时间周期的一个实体 | 每行代表一个实体的生命周期 |
| 事实 | 事务事实 | 相关业务过程事实和时间间隔事实 | 事务事实、累积事实 |
| 事实表加载 | 插入 | 插入 | 插入与更新 |
| 事实表更新 | 不更新 | 不更新 | 业务过程变更时更新 |
5. 写在最后
在本章，我们细致地构建了对事实表这一数据仓库核心元素的理解。事实表记录了企业的关键业务数据，每条记录都是业务活动的直接反映。
我们首先明确了事实表的基本功能，它集中存储了业务度量和事实，是数据分析的基础。然后，我们学习了如何根据业务需求设计事实表，挑选合适的度量，并确保通过维度键与维度表的连接，为数据分析提供必要的上下文。
我们讨论了事实表的粒度问题，这是决定我们分析细节深度的关键。我们还区分了单事务和多事务事实表，并探讨了它们在不同业务场景下的应用。
最后，我们掌握了一些高级设计原则，包括处理null值的策略、避免数据冗余的方法，以及通过退化维度来提高查询性能的技巧。这些原则有助于确保事实表的准确性和效率，支持有效的数据分析和决策制定。
随着本章的结束，希望你对事实表的设计和应用有了更清晰的认识，能够更有效地利用这一工具来挖掘数据的潜力，为企业带来价值。
标签：指南,数据仓库,业务,订单,粒度,表中,维度,解析,事实 From： https://blog.csdn.net/jankin6/article/details/139389310