数据仓库设计 - 具有频繁变化的维度键的定期快照
Data warehouse design - periodic snapshot with frequently changing dimension keys
想象一个事实 table 在一段时间内（比如 1 小时）的措施总和。
Start Date | Measure 1 | Measure 2
-------------------------------------------
2018-09-08 00:00:00 | 5 | 10
2018-09-08 00:01:00 | 12 | 20
理想情况下，我们希望保持每行恰好为 1 小时的粒度。但是，每一行都引用了可能“破坏”纹理的尺寸。例如：
Start Date | Measure 1 | Measure 2 | Dim 1
---------------------------------------------------
2018-09-08 00:00:00 | 5 | 10 | key 1
2018-09-08 00:01:00 | 12 | 20 | key 2
维度值可能会从 30 分钟变为小时，在这种情况下，上述内容将不准确，应如下表示：
Start Date | Measure 1 | Measure 2 | Dim 1
---------------------------------------------------
2018-09-08 00:00:00 | 5 | 10 | val 1
2018-09-08 00:00:30 | 5 | 10 | val 2
2018-09-08 00:01:00 | 12 | 20 | val 2
在我们的场景中，数据需要按至少 5 个维度键进行切片，查询如下：
sum(measure1) where dim1 = x and dim2 = y..
这个需求有设计模式吗？我考虑过“定期快照”，但我还没有在任何地方读到过这种在维度变化时进行行拆分的内容。
我只能看到两个选项：
- 存储每行中出现最多的维度值（例如，如果某个维度值在一小时内的大部分时间都为真，则使用此值）。这会导致一些准确性损失。
- 在每次维度更改时拆分每一行。这在 ETL 中很复杂，创建了更多数据并打破了事实 table.
中的粒度规则
选项 2 是当前的解决方案，可以达到目的，但更难维护。有没有更好的方法或其他选择？
通过一个真实的例子，这个系统记录了制造环境中的生产数据，所以数据是这样的：
Line | Date | Crew | Product | Running Time (mins)
-----------------------------------------------------------------------
Line 1 | 2018-09-08 00:00:00 | Crew A | Product A | 60
如前所述，工作人员、产品或任何其他维度可能会在一小时内多次更改。
您不需要拆分事实的时间部分 table，因为您显然想要报告每小时的数据，但您应该有两条记录，每个记录对应一个维度值。如果这是事务性事实 table 的聚合，则每小时加载 table 的进程应该按每个维度键对每个记录进行分组。所以在你上面的例子中，你应该有两个小时的记录，如下所示：
Start Date | Measure 1 | Measure 2 | Dim 1
---------------------------------------------------
2018-09-08 00:00:00 | 5 | 10 | val 1
2018-09-08 00:01:00 | 5 | 10 | val 1
2018-09-08 00:01:00 | 12 | 10 | val 2
您还需要考虑其他措施，并确保它们都进入正确的桶（val 1 或 val 2）。我在示例中将它们平均分配。
现在，如果您按小时 1 和暗淡 1 值 2 进行切片，您将只会看到 12（测量值 1），如果您按小时 1 进行切片，暗淡 1 值 1，您将只会看到 5，如果你只在第 1 小时切片，你会看到 17。
记住，你的粒度是由每个维度的水平来定义的，而不仅仅是时间维度。 HTH.
想象一个事实 table 在一段时间内（比如 1 小时）的措施总和。
Start Date | Measure 1 | Measure 2
-------------------------------------------
2018-09-08 00:00:00 | 5 | 10
2018-09-08 00:01:00 | 12 | 20
理想情况下，我们希望保持每行恰好为 1 小时的粒度。但是，每一行都引用了可能“破坏”纹理的尺寸。例如：
Start Date | Measure 1 | Measure 2 | Dim 1
---------------------------------------------------
2018-09-08 00:00:00 | 5 | 10 | key 1
2018-09-08 00:01:00 | 12 | 20 | key 2
维度值可能会从 30 分钟变为小时，在这种情况下，上述内容将不准确，应如下表示：
Start Date | Measure 1 | Measure 2 | Dim 1
---------------------------------------------------
2018-09-08 00:00:00 | 5 | 10 | val 1
2018-09-08 00:00:30 | 5 | 10 | val 2
2018-09-08 00:01:00 | 12 | 20 | val 2
在我们的场景中，数据需要按至少 5 个维度键进行切片，查询如下：
sum(measure1) where dim1 = x and dim2 = y..
这个需求有设计模式吗？我考虑过“定期快照”，但我还没有在任何地方读到过这种在维度变化时进行行拆分的内容。
我只能看到两个选项：
- 存储每行中出现最多的维度值（例如，如果某个维度值在一小时内的大部分时间都为真，则使用此值）。这会导致一些准确性损失。
- 在每次维度更改时拆分每一行。这在 ETL 中很复杂，创建了更多数据并打破了事实 table. 中的粒度规则
选项 2 是当前的解决方案，可以达到目的，但更难维护。有没有更好的方法或其他选择？
通过一个真实的例子，这个系统记录了制造环境中的生产数据，所以数据是这样的：
Line | Date | Crew | Product | Running Time (mins)
-----------------------------------------------------------------------
Line 1 | 2018-09-08 00:00:00 | Crew A | Product A | 60
如前所述，工作人员、产品或任何其他维度可能会在一小时内多次更改。
您不需要拆分事实的时间部分 table，因为您显然想要报告每小时的数据，但您应该有两条记录，每个记录对应一个维度值。如果这是事务性事实 table 的聚合，则每小时加载 table 的进程应该按每个维度键对每个记录进行分组。所以在你上面的例子中，你应该有两个小时的记录，如下所示：
Start Date | Measure 1 | Measure 2 | Dim 1
---------------------------------------------------
2018-09-08 00:00:00 | 5 | 10 | val 1
2018-09-08 00:01:00 | 5 | 10 | val 1
2018-09-08 00:01:00 | 12 | 10 | val 2
您还需要考虑其他措施，并确保它们都进入正确的桶（val 1 或 val 2）。我在示例中将它们平均分配。
现在，如果您按小时 1 和暗淡 1 值 2 进行切片，您将只会看到 12（测量值 1），如果您按小时 1 进行切片，暗淡 1 值 1，您将只会看到 5，如果你只在第 1 小时切片，你会看到 17。
记住，你的粒度是由每个维度的水平来定义的，而不仅仅是时间维度。 HTH.