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

Mat*_*don 6 sql-server ssas slowly-changing-dimension dimensional-modeling ssis-2014

我构建了一个 SSIS ETL 来将各种数据源(一个来自 MySQL,两个来自 SQL Server)集成到一个单独的 SQL Server 关系和规范化数据库中,我称之为 [NDS]。

SSIS ETL 处理类型 2 更新,因此 [NDS] 生成代理键和 SCD 表包括一个 [_EffectiveFrom] 时间戳和一个可为空的 [_EffectiveTo] 列,并且对链接所有的自然键和漂亮的外键有约束数据一起。

现在,我想用它构建一个 SSAS 维度数据库,没过多久我意识到我正在为雪花模式设置自己:

描述表关系示例的 yUML 图

所以我正在考虑添加一个新的 [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™ 做好准备,还是在正确的轨道上?

Dav*_*ave 3

正如您所看到的,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