维度表规模能否超过事实表？星型架构异常情况问询

维度表记录数超过事实表不一定是异常信号，核心取决于维度的设计逻辑，尤其是数据仓库中常见的**缓慢变化维度（SCD）**场景，结合你给出的例子具体分析如下：

你的例子本质是SCD Type 2设计 #

你提供的Dim_DogBowl表，用狗碗编号+周数作为组合主键，为同一个狗碗的每个时间版本（每周的食物类型变化）保留独立记录，这是典型的**SCD Type 2（缓慢变化维度类型2）**设计——用于追踪维度属性的历史变化，是数据仓库中实现历史数据回溯的标准方案。

星型架构 vs 规范化模型的核心差异 #

规范化模型以减少数据冗余为目标，而星型架构（数据仓库场景）优先保障查询性能和历史数据的可追溯性：

• 事实表记录的是业务事件（比如你例子中“狗狗使用狗碗”的单次/多次事件），每条记录对应一个具体事件；
• 维度表则为每个维度的历史版本生成独立记录，当一个维度的属性随时间多次变化时，维度表的记录数会自然累积，甚至超过事实表的事件数，这完全符合星型架构的设计逻辑。

如何判断是否为真正的星型架构 #

只要满足以下核心特征，即使维度表采用SCD Type 2设计，依然属于星型架构：

• 存在一个核心事实表，所有维度表直接关联到事实表；
• 维度表之间没有直接关联（即不存在维度表互相引用的情况）。

你给出的例子中，Fact_Dog作为核心事实表关联Dim_DogBowl，维度表之间无关联，完全符合星型架构的核心结构，只是维度采用了历史版本化的设计。

需要警惕的异常情况 #

如果维度表记录数过多是由以下原因导致，才属于设计或数据异常：

• 维度表存在大量重复数据（非历史版本的冗余）；
• 维度表的主键设计不合理（比如仅用狗碗编号作为主键，无法区分不同时间版本）；
• 事实表与维度表的关联逻辑错误（比如事实表的外键仅关联狗碗编号，而非维度表的版本主键，导致属性查询错误）。

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