我试图了解事实表相对于维度表是如何形成的。
例如销售事实表 对于按年/月/周/日的产品销售查询,我是否为每种类型的期间创建一个维度:Dim_Year、Dim_Month、Dim_Week 和 Dim_Day,每个都有自己的键?或者是否可以对所有时期只使用一个维度:Dim_Date 并且只有一个日期键?
我感到困惑的另一个领域是为什么有些事实表不包含自己的 ID?例如,Sale 事实表没有 SaleID 包含在事实表中。
我试图了解事实表相对于维度表是如何形成的。
例如销售事实表 对于按年/月/周/日的产品销售查询,我是否为每种类型的期间创建一个维度:Dim_Year、Dim_Month、Dim_Week 和 Dim_Day,每个都有自己的键?或者是否可以对所有时期只使用一个维度:Dim_Date 并且只有一个日期键?
我感到困惑的另一个领域是为什么有些事实表不包含自己的 ID?例如,Sale 事实表没有 SaleID 包含在事实表中。
日期
您的日期维度需要与事实表的粒度相对应。因此,如果您有每日销售量,您将有一个 Dim_Day,每周销售量您将有一个 Dim_Week,等等。
您的数据仓库中通常会有多个日期维度(不同粒度),因为您会有不同日期粒度的事实。
每个日期维度都将保存适用于日期层次结构中更高级别的属性。因此 Dim_Day 可能包含日、周、月、年属性;Dim_Month 可能包含月份、季度和年份属性等。
主键
在数据库中创建表时,主键很少(从来没有?)技术要求,即您可以在不定义 PK 的情况下创建表。因此,您需要考虑为什么我们通常(至少在 OLTP 数据库中)包含 PK。常见原因包括:
因此创建 PK 有充分的理由,但也存在成本开销,例如每次将新记录插入表时都需要检查 PK。
在您执行批量插入/更新的维度模型中,拥有 PK 会导致显着的性能损失。此外,插入逻辑/检查应始终在您的 ETL 流程中实现,因此无需在数据库本身中包含这些类型的检查/约束。
事实表确实有一个主键,但它通常是隐式的而不是显式的——因此事实表中的一组 FK 唯一地标识每条记录。此复合 PK 可能会记录在案,但从未启用/实施。
有时,事实表会有一个显式的单列 PK。这通常在需要更新事实表并且其隐式 PK 涉及大量列时使用。通常需要逻辑来识别要使用其 FK 更新的记录,但这会返回 PK;那么更新语句只有一个像这样的子句:
WHERE table_pk = 12345678
而不必在隐式 PK 中包含所有列:
WHERE table_sk1 = 1234
AND table_sk2 = 5678
AND table_sk3 = 9876
....
希望这可以帮助?