1. 星型模型初探：什么是星型模型？为什么需要它？事实表与维度表的核心概念

大家好，欢迎来到这门课。我是你们的老朋友，一个在数据仓库里摸爬滚打多年的工程师。

咱们今天聊点实在的。你肯定听过「星型模型」这个词，对吧？很多刚入行的朋友觉得它很神秘，好像是什么高深莫测的数学公式。其实说白了，它就是一套整理数据的思路，一套让数据库跑得更快、让业务人员看得更懂的建模方法。

我刚开始做数仓那会儿，也踩过不少坑。那时候不懂什么叫建模，上来就对着业务表一顿猛建，结果报表一跑就是半小时，业务部门天天催。后来我才明白，问题就出在模型上。嗯，今天咱们就把这个「星型模型」彻底聊透。

什么是星型模型？

想象一下，你手里有一张巨大的Excel表格，里面记录了公司所有的销售数据。有日期、有客户名、有产品名、有数量、有金额……所有东西都挤在一张表里。这张表会变得非常庞大，查询起来也特别慢。

星型模型就是来解决这个问题的。它把数据拆成两类：

• 事实表：记录「发生了什么」。比如一笔交易、一次点击、一次通话。
• 维度表：描述「是谁、在哪、什么时候、什么产品」。比如客户信息、产品信息、时间信息。

事实表在中间，维度表像星星一样围绕在它周围。这就是「星型」这个名字的由来。你看，是不是很形象？

我个人习惯把星型模型比作「乐高积木」。事实表是积木的核心底座，维度表是不同颜色的积木块。你想看什么维度的数据，就把对应的积木块拼上去。灵活、快速、好理解。

为什么需要星型模型？

你可能会问：我直接用一张大表不行吗？行，但代价很大。我举个例子。

假设你有一张销售大表，里面有1000万行数据。你想统计「2024年第一季度，北京地区，手机品类的销售额」。如果用一张大表，数据库需要扫描全部1000万行，然后过滤出符合条件的行。这个过程很慢。

如果用星型模型呢？

• 事实表只存「销售金额、数量」和几个ID（日期ID、地区ID、产品ID）。
• 维度表存「日期、地区、产品」的详细信息。

查询时，数据库先在小而精的维度表里找到对应的ID，然后用这些ID去事实表里快速定位数据。整个过程就像用索引查字典，而不是一页一页翻。

我在项目中遇到过这样一个场景：某电商平台的订单查询，原来用一张大表，每次跑日报要20分钟。后来改成星型模型，同样的查询只需要3秒。业务部门的人直接惊呆了。

事实表与维度表的核心概念

咱们来细说一下这两类表。搞懂了它们，星型模型你就掌握了80%。

事实表

事实表记录的是「业务事件」的度量值。说白了，就是那些可以加加减减的数字。

特征	说明
内容	数值型度量（金额、数量、时长、次数）
粒度	每一行代表一个最细粒度的业务事件
外键	包含多个指向维度表的外键ID
特点	数据量大，会持续增长，很少更新历史数据

举个例子，一个销售事实表可能是这样的：

-- 销售事实表结构示例
CREATE TABLE fact_sales (
    sale_id         INT PRIMARY KEY,      -- 主键
    date_id         INT,                  -- 指向时间维度表
    customer_id     INT,                  -- 指向客户维度表
    product_id      INT,                  -- 指向产品维度表
    store_id        INT,                  -- 指向门店维度表
    quantity        INT,                  -- 销售数量（度量）
    amount          DECIMAL(10,2),        -- 销售金额（度量）
    discount        DECIMAL(5,2)          -- 折扣金额（度量）
);

你看，事实表里没有「客户姓名」「产品名称」这些描述性字段。它们都在维度表里。事实表只关心「谁买了什么、买了多少、花了多少钱」。

维度表

维度表是事实表的「说明书」。它告诉你事实表中的每个ID背后是什么。

特征	说明
内容	文本描述、分类属性、层级信息
粒度	每一行代表一个唯一的维度成员
主键	一个唯一的ID，被事实表引用
特点	数据量相对较小，会变化（比如客户地址变更）

比如客户维度表：

-- 客户维度表结构示例
CREATE TABLE dim_customer (
    customer_id     INT PRIMARY KEY,      -- 主键，被事实表引用
    customer_name   VARCHAR(100),         -- 客户姓名
    gender          CHAR(1),              -- 性别
    age_group       VARCHAR(20),          -- 年龄分组
    city            VARCHAR(50),          -- 所在城市
    province        VARCHAR(50),          -- 所在省份
    registration_date DATE                -- 注册日期
);

产品维度表：

-- 产品维度表结构示例
CREATE TABLE dim_product (
    product_id      INT PRIMARY KEY,      -- 主键
    product_name    VARCHAR(200),         -- 产品名称
    category        VARCHAR(50),          -- 产品品类
    brand           VARCHAR(50),          -- 品牌
    unit_price      DECIMAL(10,2)         -- 单价
);

你想想看，如果把这些描述字段都塞进事实表，事实表会变得多臃肿？每次更新客户地址，还得去更新事实表里的每一行，那简直是灾难。

星型模型的核心逻辑图

说了这么多，咱们用一张图来直观感受一下星型模型的结构。下面这张SVG图展示了典型的星型模型布局：

这张图你看懂了吗？事实表在中间，四个维度表像星星一样分布在四周。每个维度表通过一个ID与事实表相连。查询时，你从维度表出发，找到你想要的维度成员，然后通过ID快速定位到事实表中的相关数据。

什么时候用星型模型？

不是所有场景都适合星型模型。我总结了几条经验：

• 适合：报表查询、BI分析、数据大屏、OLAP场景。说白了，就是「读多写少」的场景。
• 不适合：高并发的事务处理（OLTP）、需要频繁更新单行数据的场景。这种场景用关系型数据库的范式模型更合适。