DWH 建模最佳实践：二维使用的日期键

Posted 2023-03-29

【中文标题】DWH 建模最佳实践：二维使用的日期键

【英文标题】：DWH Modeling Best Practices: Date Key Used by 2 Dimensions

【发布时间】：2020-03-11 05:23:43

【问题描述】：

我正在学习 BI 开发课程，为了巩固我目前所学的所有技能，我开始了一个动手项目（DWH 设计、ETL 应用程序、数据建模等）。

在 DWH 设计过程中，我遇到了一个难题，因此我希望从更有经验的专业人士那里获得一些最佳实践。

它有二维表：

DimWeather - 存储天气数据的表。每行是一天。主键当然是对应日期的日期。

DimDate - 一个简单的日历表。在这种情况下，主键也是一个日期。

两个表都连接到存储自行车租赁日志的 Fact 表。

按照 DWH 设计最佳实践，我需要为两个表创建一个代理键 - 我们将其命名为 DateKey。

我在想，这种情况下怎么执行？

据我所知，每个表的代理键必须是唯一的，但另一方面，此代理键具有相同的逻辑。

我很高兴听到你会做什么？

非常感谢您投入时间和精力

【参考方案1】：

在我看来，DimWeather 应该是一个事实表，如果它存储有关特定日期的天气（温度、气压、湿度等）的测量值和数值数据，并且此表中的 dateID 应该引用“常规” DimDate桌子。

根据定义，维度表应包含不同的属性/层次结构，以便将事实表中的度量置于特定上下文（时间、位置、人口统计等）中。在您的场景中，您可以将天气测量放在特定的上下文中（即 2020 年 2 月纽约市的平均温度；2019 年 12 月洛杉矶的最大湿度等，具体取决于您的天气表的结构）。

除此之外，代理键只是一个无意义的值（通常是具有标识特征的整数值，以确保键的唯一性），除了 DimDate 维度，您可以通过创建基于整数值的整数值来赋予代理键含义日期值（例如：“2020-03-11”的 20200311）。当然，不禁止使用源主键作为维度表中的键，但这是一种不好的做法，因为在不同的源系统中可能会发生相同的值，并且在将数据加载到 DWH 时可能会导致问题。

【讨论】：

您好，感谢您的回复。我也有一种感觉，天气表自然是事实，而不是 DIM。在这种情况下，处理 2 个 FACT 表（非典型架构）的最佳实践是什么？

嗨，我不会说在一个数据模型中拥有 2 个或更多事实表是不典型的。我看到很多情况下拥有多个事实表完全有意义。例如，您可以每个业务流程都有事实表（在您的场景中，一个用于天气数据，另一个用于租赁日志）并使用一致的维度将数字放在特定的上下文中。您还可以为相同的业务流程提供两个事实表，但使用不同的粒度（假设您创建了一个事实表，其中包含按月汇总的数据和按日汇总的其他数据）。希望它有所帮助。

抱歉回复晚了。你的解释听起来合乎逻辑，我会继续下去。在这种情况下，我将如何制作桌子的钥匙？ DimDate 表 - 主键将是 Datekey（日期代理键），正如您建议的 FactWeather - 从逻辑上讲，主键也应该是日期。在这种情况下，我如何创建一个与 DimDate 不同的代理项。当两个表在逻辑上具有相同的 PK 逻辑时，最佳实践是什么？我想到的是一个任意字符串，作为 FactWeather 的 PK 将其连接到 FaceBikeRentals。