Dim Case维度表分析：一对一关系与无事实事实表选型困惑

针对你的Case主题分析需求，两个方案的优劣势及适用场景如下：

方案1：创建与Dim Case一对一关联的Fact Cases表 #

关于一对一关系的疑问 #

维度表与事实表的一对一关系并非绝对不推荐，只要场景合理就是可行的。这里的核心是：Dim Case是一致性维度，原本关联其他事实表，但现在需要将Case自身作为分析主体，单独承载其专属的度量逻辑，此时一对一的Fact Cases表是合理的设计。

方案优势 #

• 符合维度建模的职责分离原则：维度表（Dim Case）只存描述性属性（Case No.、Status、Manager等），事实表（Fact Cases）存度量及关联其他维度的键（Customer Key等），避免维度表臃肿。
• 灵活支持多维度交叉分析：通过关联Customer Key、Dim Date（可基于Inquiry Date/Case Start Date/Completed Date关联日期维度），能轻松实现按客户、时间区间、经理等维度统计Case开启/关闭数量、时长分布。
• 度量维护更清晰：时长类计算逻辑（Inquiry到Start的时长、Start到Completion的时长）作为事实表的度量字段，可在ETL阶段预计算存入，或在BI工具中动态计算，便于后续调整逻辑。

方案2：将度量存入Dim Case+无事实事实表 #

方案问题 #

• 违反维度表设计原则：时长属于派生度量，并非Case的固有描述属性，将其存入Dim Case会导致维度表承担事实表的职责，后续若日期字段（如Case Start Date）更新，还需同步更新时长值，维护成本高。
• 无事实事实表的冗余：无事实事实表主要用于处理多维度关联的事件匹配场景（如员工培训与考核的关联），但这里的核心是需要统计Case的数量、时长，用无事实表会让统计逻辑更复杂，不如直接用事务型事实表清晰。

最终建议 #

优先选择方案1，但需注意以下细节：

• 将Fact Cases设计为单事务事实表，每个Case对应一条记录，与Dim Case通过Case Key一对一关联。
• 度量字段（如Time_between_Inquiry_Start、Time_from_Start_Completion）建议在ETL过程中预计算，提升后续查询效率。
• 按需关联Customer Key、Dim Date等维度，满足多维度分析需求。

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