事实表的数据仓库设计

Posted 2023-03-25

【中文标题】事实表的数据仓库设计

【英文标题】：Data Warehouse Design of Fact Tables

【发布时间】：2016-08-05 22:27:00

【问题描述】：

我对数据仓库设计还很陌生，并且正在努力研究如何设计给定非常相似但又有些不同的指标的事实表。假设您正在评估以下指标，您将如何分解事实表（在这种情况下，公司是客户的一个子集）。您是否可以使用一个表来完成所有这些操作，或者每个被测量的指标都需要自己的事实表，或者被测量的指标的每个部分都是一个事实表中的自己的列？

公司每天/每月/每年处理的文件总数 公司每天/每月/每年处理的总文件大小 公司每天/每月/每年的总错误文件数 公司每天/每月/每年有 # 个文件失败 客户每天/每月/每年处理的文件总数 每天/每月/每年处理的总客户文件大小 客户每天/每月/每年错误的文件总数 每天/每月/每年的客户总数 # 个文件失败

【问题讨论】：

我认为您应该重新表述您的问题并添加一些细节。你用的是什么数据库？你的输入数据是什么样的？对我来说，这些通常是创建事实表的原始事实。从那里你可以做各种有趣的事情。但我们需要了解更多。

这最终会在 Redshift 中。数据输入将以服务提供的 JSON 形式出现。我目前正在研究概念数据模型。我假设所有这些相似的指标都将成为一个事实表的一部分，在它自己的列中。

另外，如果总数需要是日、周和月的组合，该怎么办。这个事实表将如何设计来合并总数？

没有。数据仓库就是要理解业务流程。在设计事实时不要被技术所束缚。根据您的描述，这可以通过一个事实表来满足，然后任何数量的报告/BI 工具都会处理正确的汇总，例如：Excel 数据透视表。你真的应该玩一下 Excel 数据透视表，然后你就会明白这些东西是如何自动卷起的。

【参考方案1】：

从度量名称的外观来看，我认为您将获得一个单一的事实表，其中包含每个文件的记录和返回 date_dim 的链接

create table date_dim (
    date_sk        int,
    calendar_date  date,
    month_ordinal  int,
    month_name     nvarchar,
    Year           int,
..etc you've got your own one of these ..
)
create table fact_file_measures (
    date_sk,
    file_sk,           --ref the file_dim with additonal file info
    company_sk,        --ref the company_dim with the client details
    processed  int,    --should always be one, optional depending on how your reporting team like to work
    size_Kb    decimal -- specifiy a size measurement, ambiguity is bad
    error_count int    -- 1 if file had error, 0 if fine
    failed_count int   -- 1 or file failed, 0 if fine
)

所以现在你应该能够构造查询来获得你所要求的一切

例如，对于您的每月统计数据：

select 
    c.company_name,
    c.client_name,
    sum(f.file_count) total_files,
    sum(f.size_Kb)    total_files_size_Kb,
    sum(f.file_count) total_files,
    sum(f.file_count) total_files
from
    fact_file_measure f
    inner join dim_company c on f.company_sk = c.company_sk
    inner join dim_date d on f.date_sk = d.date_sk
where
    d.month = 'January' and d.year = "1984"

如果您需要并排的“日/月/年”资料，您可以构建年和月事实表来进行汇总并通过 dim_date 的月/年字段返回。 （您可以在每日事实表中包含月份和年份字段，但这些值最终可能会被经验不足的报表构建者误用）这一切都可以追溯到您的用户真正想要的 - 根据他们的要求设计您的事实表并不要'不要害怕拥有单独的事实表 - 数据仓库不是关于规范化，而是关于以一种可以使用的方式呈现数据。

祝你好运

【讨论】：

谢谢；这有助于将所有这些都纳入视野。