在 OLAP 多维数据集中存储不同时间间隔的最佳实践

Posted 2023-03-25

【中文标题】在 OLAP 多维数据集中存储不同时间间隔的最佳实践

【英文标题】：Best practice to store diverse time intervals in OLAP cube

【发布时间】：2021-04-07 15:49:07

【问题描述】：

我的任务是制作“OLAP 立方体”，按时间间隔聚合

因此，假设事实表将存储聚合：

每天 基于其天数记录的每个月 基于其月记录的每一年

它看起来像这样：

|------------------------------------------|
|   id |  day | month | year | total_sales |
|------------------------------------------|
|    1 |    1 |     1 | 2020 |          10 |
|    2 |    2 |     1 | 2020 |          10 |
| ...N | ...N |  ...N | 2020 |          10 |
|   32 | null |     1 | 2020 |         310 |  # total for Jan 2020
| ...N | null |  ...N | 2020 |         300 |
|  378 | null |  null | 2020 |        3600 |  # total for 2020
|------------------------------------------|

那么，总的来说，这是一个好的计划吗？

将日、月、年作为一个独立的维度会更好，还是无关紧要？

【参考方案1】：

在大多数情况下，将不同粒度的事实混合在一个事实表中并不是一个好主意。如果您确实需要存储每日、每月和每年的数据，请考虑使用多个事实表。

您还可以拥有一个每天一行的维度表以及便于聚合的各种属性，例如会计年度。

【讨论】：

那么，你会推荐描述一个模型BaseAggregatedFacts并继承到AggregatedFactsPerDay、AggregatedFactsPerMonth、AggregatedFactsPerYear吗？顺便说一句，为什么存储在一张表中是个坏主意？

在我能想到的环境中，它使检索变得更加困难。我主要考虑 SQL 数据库中的星型模式。可能有一些面向 OLAP 的数据存储不适用我的反对意见。

不知道你说的继承是什么意思。

对不起，我的意思是在 MVP 的 ORM-Model 类的上下文中继承，所以保留相似的表，用一个抽象描述，但名称不同

好的，我不能帮你做 MVP。对不起。