从已经实现 SCD 的规范化源设计维度 DB

Question

我构建了一个 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] 数据库，然后在该过程中重新实现类型 2 更新，即将 [NDS] 视为保留历史记录的“源系统”，同时复制此 [DDS] 数据库中的所有内容。但是，为什么我需要在 [NDS]和[DDS] 中保留历史记录？显然有些不对劲。

我是在为 Big Mess™ 做好准备，还是在正确的轨道上？

Answer 1

正如您所看到的，Kimball 维度建模的好处之一是数据仓库设计本质上是您的 SSAS 设计。虽然总有例外，但您通常可以在 DSV 中选择一个表并立即转向层次结构设计、多维数据集关系等。

\n\n

我建议您转向 DDS，但要注意逐步淘汰 NDS。出于您在 SCD Type II 中提到的简单原因 - 没有理由复制所有数据、ETL 和代码库。保留两者会导致解决方案过于复杂，需要大量维护和风险 - 这是您需要避免的主要 Big Mess\xe2\x84\xa2。

\n\n

理由如下：

\n\n

\n
• DDS 听起来像 Kimball 维度设计，\n任何新员工和承包商都可以轻松理解和维护
\n
• 有许多经过验证的模式和 ETL 设计与之相伴，使得设计和维护变得更加容易
\n
• 通过事实分区和列存储索引等选项更轻松地处理大量数据
\n
• 将来为您自己和高级用户提供更轻松的 DW 查询
\n
• 整体设计更简洁
\n

\n\n

仅当您拥有少量数据、没有显着的增长预期并且没有切换到数据仓库的能力时，我才建议采用替代设计。该建议最终包括许多本来会进入 DW 的设计工作，因此类似于保留 NDS 并创建 DDS：

\n\n

您可以使用显示为视图或硬编码到 DSV 中的查询来创建多维数据集。

\n\n

听起来您克服了很多障碍并使用 NDS 创建了一个出色的功能解决方案。不幸的是，它没有做维度建模提供的两个重要的事情：简单的查询模式和轻松转换为多维分析。值得庆幸的是，许多 ETL 设计可能可用作加载不同表结构的模板或起点。

\n