如何解读遗留SSAS模型？RLS相关架构与配置疑问咨询

1. 大量表是冗余还是标准做法？ #

这种分层拆分的维度表设计是星型/雪花模型的标准操作，并非冗余。这类模型的核心价值在于：

• 保证数据一致性：把重复的维度属性（比如用户所属部门、区域信息）拆分到独立表，避免在事实表中重复存储，减少数据不一致的风险；
• 简化权限规则：可以针对不同维度层级（比如用户组、部门、区域）精准配置RLS，不用在庞大的事实表中写复杂规则；
• 便于维护：维度属性变更时，只需要修改对应维度表，不用更新所有关联的事实表。

如果把所有维度属性都塞进事实表，反而会导致数据冗余膨胀、维护成本飙升，权限规则也会变得臃肿难改。

2. 双向关系存在的原因？ #

你提到只希望筛选流向Fact表，但双向关系的存在通常是为了覆盖更多场景：

• 支持反向权限验证：当用户从维度表（比如用户表）发起查询时，双向关系能让维度表的RLS规则反向过滤事实表，确保只能看到自己权限范围内的事实数据；
• 兼容报表需求：部分报表需要从维度出发聚合事实数据（比如按部门统计销售额），双向关系能保证权限筛选在这种场景下依然生效；
• 遗留兼容：可能是为了适配旧版BI工具的筛选逻辑，或是早期权限规则设计时需要双向传递才能覆盖所有查询路径。

如果确认当前业务只需要单向筛选，可以逐步测试取消双向关系，验证权限是否依然正常生效——毕竟双向关系可能带来性能损耗或筛选逻辑混乱。

3. RLS过滤器最优放置位置？ #

最优方案是把RLS过滤器放在最核心的底层维度表（或用户/权限映射表），而非直接放在事实表：

• 效率更高：维度表的数据量远小于事实表，过滤器在小表上执行的性能开销更低；
• 规则复用：如果多个事实表共享同一个维度，只需要在维度表配置一次规则，所有关联事实表都会自动继承权限筛选，避免重复写规则；
• 易于维护：权限规则集中在核心维度，后续修改时只需要调整一处，不用逐个修改所有事实表的规则。

只有当某个事实表有独立于维度的特殊权限逻辑时，才需要单独在该事实表添加过滤器。

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