我想为分析项目设计星型模式。该分析围绕“客户”维度展开。
我很难为表格建模。这是我想出的两张表：
我会一一询问我的担忧：
我对 BI 完全陌生。所以，一个说明性的答案会很有帮助。谢谢！
【问题讨论】：
标签： data-modeling data-warehouse business-intelligence snowflake-cloud-data-platform
我会这样做，所以它一定是一个好的设计。我会称它为 dimCalendar，但那是次要的东西。
方法是创建并填充表，然后添加外键引用。
【讨论】：
你问了多个问题，所以我分开回答：
您可以拥有一个具有单日粒度的单独日历日期维度。根据所需的报告类型，您可以拥有与周、月、年、季度等相对应的详细信息。因此，您可以拥有 Date, Week_Start_Date, Week_End_Date, Month_Start_Date, Month_End_Date 等字段。生成日历日期维度的最佳方法是使用电子表格并构建它用手。对于某些字段，例如 Week_Start_Date、Week_End_Date、Month_Start_Date、Month_End_date，您可以使用 SQL。许多人在事实表中有一些无效的日期。事实表中引用特殊数据条件的外键引用必须指向日历日期表中的“非日期”日期。您至少需要日历日期表中的这些特殊记录之一，但您可能希望区分其中几种异常情况。对于不适用的日期情况，日期类型的值为不适用或NA。事实表中的外键永远不能为空，因为这违反了参照完整性。
您可以将日期维度的引用添加到 Customer Dimension 和 Fact 表，但如果您需要查看是否真的需要这个，您可以加入所有三个表（Fact-> Date_dim on Date_key、Fact-> Cust_dim on Customer_id &获取您正在寻找的详细信息。）
您应该为事实表和维度表分配正确的名称，例如 Customer_Fact、Customer_Dim。理想情况下，每个维度（即位置）应该有一个单独的维度表，并在事实表中使用外键引用。这将帮助您跟踪维度表中的变化以及您可能不需要加载整个事实的维度变化。
【讨论】：
此分析围绕“客户”维度展开
不，分析应该围绕您的事实表解决
“事实”对于事实表来说是个坏名字
您要分析的过程或事件是什么？那是你的事实表
您的日期维度应如下所示：
create table dim.date (
date_key int primary key,
name text not null unique,
date_iso date unique,
year smallint,
quarter smallint,
month smallint,
month_name text
...
);
insert into dim.date values
(0, 'N/A', null, null, null, null, null),
(20180101, 'Jan 1, 2018', '2018-01-21', 2018, 1, 1, 'January');
一般来说，您应该避免在数据库中使用智能键，但 dim.date 是一个例外。对主键使用 int 类型，但使其值表示日期（例如 20180101 表示 '2018-01-01'）。这使得将来按日期对事实表进行分区变得更加容易
此外，您不需要数据仓库中的外键。您的 ETL 工具将处理参照完整性。
您应该从一个包含分析所需的所有列的大事实表开始。如果需要节省磁盘空间，那就把一些数据拆分成维度
【讨论】：