我试图了解事实表相对于维度表是如何形成的。
例如销售情况表 对于按年/月/周/日的产品销售查询，我是否为每种类型的期间创建一个维度：Dim_Year、Dim_Month、Dim_Week 和 Dim_Day，每个都有自己的键？ 或者是否可以对所有时期只使用一个维度：Dim_Date 并且只有一个日期键？
我感到困惑的另一个方面是为什么有些事实表不包含自己的 ID？例如。销售事实表没有包含在事实表中的 SaleID。
【问题讨论】：
标签： database data-warehouse star-schema fact-table
日期
您的日期维度需要与事实表的粒度相对应。因此，如果您有每日销售量，您将有一个 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
....
希望这有帮助吗？
【讨论】：