什么是星型模式？

星型模式是维度模型的基本形式，其中数据被组织成事实和维度。 事实是被计数或测量的事件，例如销售或登录。 维度包括有关事实的参考数据，例如日期、商品或客户。

星型模式是一种关系模式，其设计代表多维数据模型。 星型模式是显式的数据仓库模式。 它被称为星型模式，因为该模式的实体关系图模拟了一个星形，其点从一个中心表发散。 模式的中心由一个大的事实表组成，星形的点是维度表。

事实表

星型模式中的一个表，其中包含事实并连接到维度。 事实表有两种类型的列：包含事实的列和作为维度表外键的列。 事实表的主键通常是一个由其所有外键组成的复合键。

事实表可能涉及详细级别事实或已聚合的事实（包含聚合事实的事实表通常被称为摘要表）。 事实表通常包含具有相同聚合级别的事实。

维度表

维度是一种通常由一个或多个对数据进行分类的层次结构组成的架构。 如果一个维度没有层次结构和级别，则称为平面维度或列表。 每个维度表的主键都是事实表复合主键的一部分。 维度属性有助于定义维度值。 它们通常是描述性的文本值。 维度表通常比事实表小。

事实表存储有关销售的数据，而维度表存储有关地理区域（市场、城市）、客户、产品、时间和渠道的数据。

星型模式的特征

由于以下特征，星型模式非常适合数据仓库数据库设计

• 它创建一个非规范化的数据库，可以快速提供查询响应。
• 它提供了一个灵活的设计，可以在整个开发周期中轻松更改或添加，并且随着数据库的增长。
• 它在设计上提供了与最终用户通常思考和使用数据的方式的并行性。
• 它降低了开发人员和最终用户的元数据复杂性。

星型模式的优点

星型模式易于最终用户和应用程序理解和导航。 通过精心设计的模式，客户可以立即分析大型的多维数据集。

星型模式在决策支持环境中的主要优点是

查询性能

星型模式数据库的表数量有限，并且有清晰的连接路径，查询运行速度比针对 OLTP 系统的速度更快。 小的单表查询，通常是对维度表的查询，几乎是瞬时的。 包含多个表的大型连接查询只需几秒钟或几分钟即可运行。

在星型模式数据库设计中，维度仅通过中心事实表连接。 当在查询中使用两个维度表时，在这两个表之间仅存在一个连接路径，与事实表相交。 此设计功能可确保真实且一致的查询结果。

加载性能和管理

结构简单性也减少了将大量记录加载到星型模式数据库所需的时间。 通过描述事实和维度并将它们分离到各个表中，可以减少加载结构的影响。 维度表可以只填充一次并偶尔刷新。 我们可以通过将记录附加到事实表中来定期和选择性地添加新事实。

内置引用完整性

当信息被加载时，星型模式具有内置的引用完整性。 引用完整性已得到执行，因为维度表中的每个数据都有一个唯一的主键，并且事实表中的所有键都是从维度表得出的合法外键。 事实表中与维度未正确关联的记录无法获得正确的主键值以被检索。

易于理解

星型模式易于理解和导航，维度仅通过事实表连接。 这些连接对最终用户而言更为重要，因为它们代表了底层业务各部分之间的基本关系。 客户还可以在构建查询之前浏览维度表属性。

星型模式的缺点

星型模式无法满足某些条件，例如用户和银行账户之间的关系无法描述为星型模式，因为它们之间的关系是多对多的。

示例：假设一个星型模式由一个事实表 SALES 和几个连接到它的维度表组成，分别用于时间、分支、项目和地理位置。

TIME 表有用于每天、每月、每季度和每年的列。 ITEM 表具有 item_Key、item_name、brand、type、supplier_type 的列。 BRANCH 表具有每个 branch_key、branch_name、branch_type 的列。 LOCATION 表具有地理数据列，包括街道、城市、州和国家/地区。

在这种情况下，SALES 表仅包含来自维度表 TIME、ITEM、BRANCH 和 LOCATION 的四个 ID 列，而不是用于时间数据的四列、用于 ITEM 数据的四列、用于 BRANCH 数据的三列以及用于 LOCATION 数据的四列。 因此，事实表的大小大大减小。 当我们需要更改一个项目时，我们只需要在维度表中进行一次更改，而不是在事实表中进行多次更改。

我们可以通过将维度表规范化为几个表来创建更复杂的星型模式。 规范化的维度表称为雪花。