【问题标题】:Should I use multiple fact tables for each grain or just aggregate from lowest grain?我应该为每个粒度使用多个事实表还是只从最低粒度聚合?
【发布时间】:2022-01-13 10:42:59
【问题描述】:

对于数据仓库设计和星型架构来说相当新。我们设计了一个事实表,其中存储了有关会员资格的各种度量,我们的粮食是每天的,并且该表中的一些度量是诸如新售出的数量、更新的售出数量、活跃的数量、取消的数量。

我的问题是,企业将希望查看其他粒度的措施,例如每月、每季度、每年等。因此,这里的方法通常只是汇总所需时间段的日级数据或您是否建议为我们的业务需求的“关键”时间段创建单独的事实表,例如每月、每季度、每年?我已经阅读了一些关于此的混合信息,这主要是我寻求其他意见的原因。

我读到的一些信息让人们在事实表中嵌入了一个层次结构来指定不同的粒度,然后通过“级别”类型的列进行识别,很多人都建议不要这样做,对我来说似乎也不好,那些反对我们建议每个谷物单独的事实表,但老实说,我不明白为什么我们不只是从我们拥有的每日条目中汇总,我们从每个谷物的事实表中得到什么好处,除了也许有一些轻微的性能改进?

【问题讨论】:

    标签: etl data-warehouse dimensional-modeling star-schema star-schema-datawarehouse


    【解决方案1】:

    每个数据集市都有自己的“视角”,这可能需要汇总的事实粒度。

    星型模式建模是一个“自上而下”的过程,您可以从一组问题或用例开始,构建一个让这些问题易于回答的模式。不是一个“自下而上”的过程,您从源数据开始并从那里找出架构设计。

    您最终可能会得到多个共享同一个粒度事实表的数据集市,但它们需要以不同的方式聚合它,要么是为了提高性能,要么是为了计算和存储仅在聚合颗粒。

    例如

    SalesFact (store,day,customer,product,quantiy,price,cost)
    

    StoreSalesFact(store, week, revenue, payroll_expense, last_year_revenue)
    

    【讨论】:

    • 感谢 David,特别是关于某些度量如何仅适用于某些聚合粒度的意义,这是我考虑单独聚合事实表的原因之一,或者我什至可以通过 Views 考虑这样做。
    • 视图很方便,尤其是在您没有大量查询的情况下。例如,您将数据导入 Power BI 或 SSAS 并在那里查询。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2018-10-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多