事实表与维度表的关联构建及两类技术问题问询

哈哈，这两个问题都是刚入门数据仓库时特别容易纠结的点，我来给你梳理清楚～

绝对不需要拆成Dim_Year、Dim_Month、Dim_Week、Dim_Day这些单独的维度表——单一的Dim_Date维度表才是数据仓库领域的标准实践，原因如下：

• 一个完整的日期维度表会包含所有你需要的时间层级属性，比如DateKey（通常用YYYYMMDD格式的整数，比如20240520）、FullDate（日期类型）、Year、MonthNumber、MonthName、WeekOfYear、DayOfMonth、DayOfWeekName等。
• 事实表只需要通过一个DateKey关联到Dim_Date，就能轻松实现按年/月/周/日任意粒度的查询聚合，比如想查2024年5月每周的销售数据，直接关联后GROUP BY d.Year, d.MonthNumber, d.WeekOfYear即可，效率比关联多个维度表高得多。
• 维护成本低：只需要生成一次日期维度表（通常覆盖几十年的日期），后续不用维护多个表的关联关系，也不会出现数据不一致的问题。

举个简单的Dim_Date结构示例：

CREATE TABLE Dim_Date (
    DateKey INT PRIMARY KEY,
    FullDate DATE NOT NULL,
    Year INT NOT NULL,
    MonthNumber INT NOT NULL,
    MonthName VARCHAR(20) NOT NULL,
    WeekOfYear INT NOT NULL,
    DayOfMonth INT NOT NULL,
    DayOfWeekName VARCHAR(20) NOT NULL
);

销售事实表只需要保留一个DateKey字段，和这个表关联就够了。

这个问题核心在于事实表的粒度和主键设计，分两种情况来看：

• 复合主键替代单一ID：很多事务型事实表的主键是复合主键，由所有关联的维度键组合而成。比如如果你的销售事实表粒度是「每一笔独立的销售明细」，但每一行的DateKey+ProductKey+StoreKey+CustomerKey已经能唯一标识这笔销售（不存在同一时间、同一产品、同一门店、同一客户有两笔完全一样的销售），那这组复合键就可以作为主键，不需要额外的SaleID。教材里的示例往往是简化了场景，用复合主键来演示，所以没加单独的SaleID。
• 汇总型事实表不需要ID：如果是汇总后的销售事实表（比如按「日+产品」汇总的销售数量和金额），这时候DateKey+ProductKey就是唯一标识一行的复合主键，自然不需要SaleID——因为它代表的是一组销售记录的汇总，不是单一的销售事务。

当然，如果你的业务场景中存在同一维度组合下有多笔独立销售的情况（比如同一客户在同一时间同一门店买了两次同一款产品，是两笔独立的交易），那还是需要单独的SaleID来作为唯一标识，这时候SaleID会作为主键，维度键作为外键存在。

内容的提问来源于stack exchange，提问作者Jin Yu Chan