星型模式

在计算领域，星型模式是最简单的数据集市模式，也是最广泛用于开发数据仓库和维度数据集市的方法。 星型模式由一个或多个事实表组成，这些事实表引用任意数量的维表。星型模式是雪花型模式的一个重要特例，对于处理更简单的查询更有效。

星型模式的名称来源于物理模型与星形的相似性。事实表位于中心，维表周围代表星形的点。

模型

星型模式将业务流程数据分为事实和维度，事实保存有关业务的可测量的定量数据，维度是与事实数据相关的描述性属性。事实数据的示例包括销售价格、销售数量以及时间、距离、速度和重量测量。相关维度属性示例包括产品型号、产品颜色、产品尺寸、地理位置和销售人员姓名。

具有多个维度的星型模式有时称为蜈蚣模式。 维度仅包含几个属性，虽然更易于维护，但会导致查询中包含许多表连接，并使星型模式不太易于使用。

事实表

事实表记录特定事件的测量或指标。事实表通常由数值和保存描述性信息的维度数据的外键组成。 事实表被设计为低水平的统一细节（称为“粒度”或“粒度”），这意味着事实可以在非常原子的级别上记录事件。随着时间的推移，这可能会导致事实表中积累大量记录。事实表定义为以下三种类型之一：

• 交易事实表记录有关特定事件（例如销售事件）的事实
• 快照事实表记录给定时间点的事实（例如，月底的帐户详细信息）
• 累积快照表记录给定时间点的聚合事实（例如，产品本月至今的总销售额）

事实表通常分配一个代理键以确保每一行都可以唯一标识。该键是一个简单的主键。

维表

与事实表相比，维表通常具有相对较少数量的记录，但每条记录可能具有大量属性来描述事实数据。维度可以定义多种特征，但维表定义的一些最常见的属性包括：

• 时间维度表描述了星型模式中记录事件的最低时间粒度级别的时间
• 地理维度表描述位置数据，例如国家、州或城市
• 产品尺寸表描述产品
• 员工维度表描述员工，例如销售人员
• 范围维度表描述时间、美元价值或其他可测量数量的范围，以简化报告

维表通常分配一个代理主键，通常是单列整数数据类型，映射到形成自然键的维度属性的组合。

好处

星型模式是非规范化的，这意味着在星型模式设计和实现期间，放宽了应用于事务关系数据库的典型规范化规则。星型模式非规范化的好处是：

• 更简单的查询 - 星型模式连接逻辑通常比从高度规范化的事务模式检索数据所需的连接逻辑更简单。
• 简化的业务报告逻辑——与高度规范化的模式相比，星型模式简化了常见的业务报告逻辑，例如同期报告和当前报告。
• 查询性能提升——与高度标准化的模式相比，星型模式可以为只读报告应用程序提供性能增强。
• 快速聚合——针对星型模式的更简单的查询可以提高聚合操作的性能。
• 提供多维数据集——所有OLAP系统都使用星型模式来高效构建专有的OLAP 多维数据集；事实上，大多数主要的 OLAP 系统都提供ROLAP操作模式，可以直接使用星型模式作为源，而无需构建专有的多维数据集结构。

例子

示例查询使用的星型模式。

比如一个来自连锁店的销售数据库，按日期、商店和产品分类。右侧的架构图像是雪花模式文章中提供的示例架构的星型架构版本。

Fact_Sales是事实表，有三个维度表Dim_Date 、 Dim_Store和Dim_Product 。

每个维表的Id列上都有一个主键，与Fact_Sales表的三列（复合）主键（ Date_Id 、 Store_Id 、 Product_Id ）的列之一（在示例架构中视为行）相关。本示例中事实表的非主键Units_Sold列表示可用于计算和分析的度量或指标。维表的非主键列表示维度的附加属性（例如Dim_Date维度的Year ）。

例如，以下查询回答 1997 年每个品牌和国家/地区销售了多少台电视机：

SELECT
	P.Brand,
	S.Country AS Countries,
	SUM(F.Units_Sold)

FROM Fact_Sales F
INNER JOIN Dim_Date D    ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S   ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)

WHERE D.Year = 1997 AND  P.Product_Category = 'tv'

GROUP BY
	P.Brand,
	S.Country

相关资料

• 数据仓库
• 在线分析处理
• 反向星型模式
• 雪花模式
• 事实星座
• 活动图式

外部链接

• 星星：查询优化模式的模式语言 （页面存档备份，存于互联网档案馆）
• 事实星座图 （页面存档备份，存于互联网档案馆）