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

我的任务是创建“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
|------------------------------------------|

每天

每个月的天数记录

每年根据其月份记录

它将如下所示：

|------------------------------------------|
|   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
|------------------------------------------|

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

---

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

在大多数情况下，在单个事实表中混合不同粒度的事实不是一个好主意。如果你真的需要存储每天、每月和每年的数据，考虑一个以上的事实表。

---

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

因此，您是否建议描述一个模型

BaseAggregatedFacts

，并继承到

AggregatedFactsPerDay

，

aggregatedfactsMonth

，

AggregatedFactsPerYear

？顺便说一句，为什么存储在一个表中是个坏主意？在我能想到的环境中，这会使检索变得更加困难。我主要考虑SQL数据库中的星型模式。我的反对意见可能不适用于某些面向OLAP的数据存储。我不知道你所说的继承是什么意思。Sry，我的意思是在MVP的ORM模型类的上下文中继承，所以保留类似的表，用一个抽象描述，但使用不同的名称OK，我不能帮助你使用MVP。很抱歉