星型模型基础设计咨询：日期维度构建及数据加载疑问

1. 星型模型可行性 #

你设计的星型模型完全符合数据仓库设计规范，是可行的，核心原因如下：

• 事实表FACT_SALES聚焦核心度量值（VOLUME、AMOUNT），通过外键关联维度表，避免数据冗余，契合事实表的设计原则；
• DIM_PRODUCT将产品描述与主键分离，把静态属性从事实表抽离，后续维护（如修改产品描述）只需更新维度表，更高效；
• DIM_DATE拆解日期为年、月、日维度，是数据仓库中日期维度表的标准设计，能大幅简化按时间维度的聚合分析（比如年度销售汇总、月度趋势统计）。

补充建议：FACT_SALES的主键建议设为复合主键（CUSTOMER_KEY + PRODUCT_KEY + DATE）；如果是单条交易记录，还可额外加入交易流水号作为主键的一部分，避免出现重复事实记录。

2. DIM_DATE字段填充问题 #

DIM_DATE的YEAR、MONTH、DAY不会自动填充，也不需要提前在原始数据集里创建这些字段——你可以在数据加载的ETL过程中，通过数据库的日期函数，从原始DATE字段（格式'YYYY-MM-DD'）直接提取生成。

常见数据库的字段提取示例： #

• MySQL/MariaDB：

SELECT 
  DATE AS DATE,
  YEAR(DATE) AS YEAR,
  MONTH(DATE) AS MONTH,
  DAY(DATE) AS DAY
FROM (SELECT DISTINCT DATE FROM 原始数据集) AS unique_dates;

• PostgreSQL：

SELECT 
  DATE AS DATE,
  EXTRACT(YEAR FROM DATE)::INT AS YEAR,
  EXTRACT(MONTH FROM DATE)::INT AS MONTH,
  EXTRACT(DAY FROM DATE)::INT AS DAY
FROM (SELECT DISTINCT DATE FROM 原始数据集) AS unique_dates;

• SQL Server：

SELECT 
  DATE AS DATE,
  DATEPART(YEAR, DATE) AS YEAR,
  DATEPART(MONTH, DATE) AS MONTH,
  DATEPART(DAY, DATE) AS DAY
FROM (SELECT DISTINCT DATE FROM 原始数据集) AS unique_dates;

数据加载的常规流程： #

1. 先加载DIM_DATE：从原始数据集中提取不重复的DATE值，用上述SQL生成年、月、日字段后插入到DIM_DATE表；
2. 再加载DIM_PRODUCT：从原始数据集中提取不重复的PRODUCT_KEY和PRODUCT_DESCRIPTION组合，插入到DIM_PRODUCT表；
3. 最后加载FACT_SALES：将原始数据中的CUSTOMER_KEY、PRODUCT_KEY、DATE、VOLUME、AMOUNT插入事实表，确保DATE值已存在于DIM_DATE中（可通过外键约束或ETL校验保证）。

内容的提问来源于stack exchange，提问作者user19653607