星型模式用事实表与维度表拆分事件本身和事件属性

和OLTP领域数据模型百花齐放不同，[[OLTP与OLAP访问模式的本质差异催生独立的数据仓库]] 里的数据仓库用得最多的是一种相当公式化的模式——星型模式（也叫维度建模）。模式中心 是一张事实表，每一行代表一个特定时刻发生的事件（比如一次商品购买、一次页面浏览）； 事实表里有些列是数值属性（如销售价格、采购成本，用于计算利润），另一些列是指向 “维度表”的外键——维度代表这个事件发生的地点、时间、方式、原因（比如”哪个商品被卖了” 对应dim_product维度表，甚至日期本身也常用维度表表示，以便编码”是否公共假期”这类 附加信息）。因为每一行事实都被当作独立事件保留（以便后续分析获得最大灵活性）， 事实表会变得极其庞大——大企业的数据仓库里事实表可能有几十PB历史交易数据，而维度表 通常小得多（数百万行级别）。这个模式之所以叫”星型”，是因为可视化表关系时，事实表 在中央、被维度表包围，连接看起来像星星发出的光芒。它的一个变体叫雪花模式：把维度 进一步拆解成子维度（比如把品牌和类别单独建表），比星型模式更规范化，但星型模式 通常仍是首选，因为分析师用起来更简单。典型数据仓库的表非常”宽”——事实表常有上百 列，维度表也可能包含大量可能与分析相关的元数据字段。

结构图：

flowchart LR
    D1[dim_date 维度表] --> F[fact_sales 事实表<br/>每行=一次事件]
    D2[dim_product 维度表] --> F
    D3[dim_store 维度表] --> F
    D4[dim_customer 维度表] --> F
    F -.事实表: 数值属性+指向维度表的外键, 行数可达数十PB.-> F