我已经构建了一个 SSIS ETL 来将各种数据源（一个来自 MySQL，两个来自 SQL Server）集成到一个 SQL Server 关系和规范化数据库中，我称之为 [NDS]。
SSIS ETL 处理类型 2 更新，因此 [NDS] 生成代理键，SCD 表包含一个 [_EffectiveFrom] 时间戳和一个可为空的 [_EffectiveTo] 列，并且对链接所有数据在一起。
现在，我想用它构建一个 SSAS 维度数据库，没过多久我就意识到我正在为雪花模式设置自己：
所以我正在考虑添加一个新的 [DDS]（关系）数据库，以创建实际的维度和事实表，这些表将为 SSAS 数据库提供 DSV。
这个 [DDS] 数据库将尽可能地非规范化，以便将事实和维度“扁平化”（例如，[OrderHeaders]+[OrderDetails] 到 [Orders] 事实表，以及 [CustomerStores]+[Customers]+ [SalesReps] 到一些 [Customers] 维度表中）——这样做不仅可以让我更容易地在 SSAS 中构建维度层次结构，还可以更容易地提出一个实际的星型模式。
我有几个问题：
- 我可以重用现有代理键的子集吗？我正在考虑将现有密钥用于最精细的级别，并将其作为维度密钥。这是一个好方法，还是我应该忽略 [NDS] 代理键并使 [DDS]（关系数据库）生成一组新的代理键？
- 如何处理 SCD？例如，当源系统中某些特定字段发生变化时，“材料”和“供应商”将在 [NDS] 中生成新记录......我想我必须设计 SSIS ETL 以仅加载“最后图像”记录进入 [DDS] 数据库，然后在该过程中重新实现 type-2 更新，即将 [NDS] 视为保留历史的“源系统”，同时复制此 [DDS] 数据库中的所有内容。但是，为什么我需要在 [NDS]和[DDS] 中保留历史记录？显然有些不对劲。
我是在为 Big Mess™ 做准备，还是在正确的轨道上？
如您所见，Kimball Dimensional Modeling 的好处之一是数据仓库设计本质上就是您的 SSAS 设计。虽然总有例外，但您通常可以在 DSV 中选择一个表，然后立即转到层次结构设计、多维数据集关系等。
我建议转向 DDS，但要注意逐步淘汰 NDS。出于您提到的 SCD Type II 的简单原因——没有理由复制所有这些数据、ETL 和代码库。保留两者会导致过于复杂的解决方案，需要大量维护和风险——这是您需要避免的主要 Big Mess™。
这是理由：
仅当您拥有少量数据、没有明显的增长预期并且没有能力切换到数据仓库时，我才建议使用替代设计。这个建议最终包括很多设计工作，否则这些工作将进入 DW，因此类似于保留 NDS 和创建 DDS：
您可以使用显示为视图或硬编码到 DSV 中的查询来创建多维数据集。
听起来您克服了很多障碍并使用 NDS 创建了一个功能强大的解决方案。不幸的是，它没有做的是维度建模提供的两件重要事情：简单的查询模式和轻松转换为多维分析。值得庆幸的是，很多 ETL 设计都可能用作加载不同表结构的模板或起点。