问题描述
我试图了解事实表相对于维度表的形成方式。
例如销售情况表 对于查询按年/月/周/日的产品销售，我是否为每种期间类型创建维度：Dim_Year，Dim_Month，Dim_Week和Dim_Day，每个都有各自的键？ 还是可以在所有期间仅使用一个维度：Dim_Date并且只有一个日期键？
令我困惑的另一个领域是，为什么某些事实表不包含其自己的ID？例如。销售事实表的事实表中未包含SaleID。
Sale Fact Table Textbook Example
解决方法
日期
您的日期维必须与事实表的粒度相对应。因此，如果您有每日销售量，则有Dim_Day，有每周销售量，则有Dim_Week等。
您通常会在数据仓库中拥有多个日期维度（以不同的粒度表示），因为事实会以不同的日期粒度表示。
每个日期维度将包含适用于日期层次结构中更高级别的保持属性。因此Dim_Day可能包含day，week，month，year属性； Dim_Month可能包含月份，季度和年份等属性。
主要密钥
在数据库中创建表时，主键很少（从来没有？）是技术要求，即您可以在不定义PK的情况下创建表。因此，您需要考虑为什么我们通常（至少在OLTP DB中）包含PK。常见原因包括：
- 轻松识别个人记录
- 为确保重复记录（具有相同PK值的记录） 未创建
因此创建PK的理由很充分，但是会产生成本开销，例如每次将新记录插入表中时，都需要检查PK。
在要执行批量插入/更新的维模型中，拥有PK会严重影响性能。此外，插入逻辑/检查应始终在ETL流程中实现，因此无需在数据库本身中包括这些类型的检查/约束。
事实表确实具有主键，但是它通常是隐式的而不是显式的-因此事实表中的一组FK唯一地标识每个记录。该复合PK可能已记录在案，但从未启用/实现。
有时，事实表将具有显式的单列PK。通常在需要更新事实表并且其隐式PK涉及大量列时使用此方法。通常需要逻辑来使用其FK来标识要更新的记录，但这会返回PK；那么update语句只有这样的子句：
WHERE table_pk = 12345678
而不是必须将所有列都包含在隐式PK中：
WHERE table_sk1 = 1234
AND table_sk2 = 5678
AND table_sk3 = 9876
....
希望这有帮助吗？