【问题标题】:Best practice to store diverse time intervals in OLAP cube在 OLAP 多维数据集中存储不同时间间隔的最佳实践
【发布时间】:2021-04-07 15:49:07
【问题描述】:

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

因此,假设事实表将存储聚合:

  1. 每天
  2. 基于其天数记录的每个月
  3. 基于其月记录的每一年

它看起来像这样:

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

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

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

【问题讨论】:

    标签: database-design olap


    【解决方案1】:

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

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

    【讨论】:

    • 那么,你会推荐描述一个模型BaseAggregatedFacts并继承到AggregatedFactsPerDayAggregatedFactsPerMonthAggregatedFactsPerYear吗?顺便说一句,为什么存储在一张表中是个坏主意?
    • 在我能想到的环境中,它使检索变得更加困难。我主要考虑 SQL 数据库中的星型模式。可能有一些面向 OLAP 的数据存储不适用我的反对意见。
    • 不知道你说的继承是什么意思。
    • 对不起,我的意思是在 MVP 的 ORM-Model 类的上下文中继承,所以保留相似的表,用一个抽象描述,但名称不同
    • 好的,我不能帮你做 MVP。对不起。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2017-02-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-10-16
    • 1970-01-01
    相关资源
    最近更新 更多