16

我们正在为一家银行开发一个数据仓库，并且几乎遵循标准的 Kimball 临时表模型、星型模式和 ETL 来通过流程提取数据。

Kimball 谈到了使用暂存区进行导入、清理、处理和一切操作，直到您准备好将数据放入星型模式。在实践中，这通常意味着将数据从源上传到一组表中，几乎没有修改，然后选择性地通过中间表获取数据，直到它准备好进入星型模式。这对单个实体来说是很多工作，这里没有单一的责任。

我以前工作过的系统对不同的表集进行了区分，达到了以下程度：

  • 上传表：原始源系统数据，未修改
  • 暂存表：中间处理、类型化和清理
  • 仓库表

您可以将它们粘贴在单独的模式中，然后为存档/备份/安全等应用不同的策略。其他人之一曾在一个仓库工作，那里有一个StagingInput和一个StagingOutput，类似的故事。整个团队在数据仓库和其他方面都有很多经验。

然而，尽管如此，纵观 Kimball 和网络，似乎完全没有关于为暂存数据库提供任何类型的结构的书面文件。如果相信 Kimball 先生会让我们所有人都将分期工作作为这个庞大的深黑色非结构化数据池，那将是可以原谅的。

当然，如果我们想为暂存区添加更多结构，如何去做是很明显的，但似乎没有任何关于它的文章似乎很奇怪。

那么，外面的其他人都在做什么呢？只是上演这么大的非结构化混乱还是人们有一些有趣的设计？

4

7 回答 7

4

我也遇到过同样的问题。我们有一个大型 HR 数据仓库，我正在从整个企业的系统中提取数据。我收集了很多 Fact 和 Dimension 表，但是暂存区一团糟。我不知道任何设计标准。我会遵循与您相同的路径，并提出一组标准的名称来使事情井井有条。您的建议对于命名非常好。我会继续努力。

于 2009-05-14T14:24:35.640 回答
4

请注意，Raph Kimball 和 Joe Caserta 有一本书名为“The Data Warehouse ETL Toolkit”，因此 Kimball 先生确实在这方面付出了一些努力。:)

于 2009-10-29T19:24:12.107 回答
3

我们目前正在开发一个大型保险 DWH 项目，它有点复杂，但是每个源系统表都被放入 STAGING 数据库中的单独模式中，然后我们有移动/清理/符合（MDM）数据的 ETL从 staging 数据库到 STAGINGCLEAN 数据库，然后进一步 ETL 将数据移动到 Kimball DWH。

我们发现 Staging 和 StagingClean 数据库的分离对于诊断问题非常有帮助，尤其是在数据质量方面，因为我们有脏的暂存数据以及在转换为 DWH 之前的清理版本。

于 2011-06-03T10:32:52.780 回答
2

暂存中可以有子区域。例如称为 staging1、staging2。

Staging1 可以直接从数据源中提取，无需转换。而Staging1 只保留最新的数据。

Staging2 保持数据转换并准备好进入仓库。Staging2 保留所有历史数据。

于 2009-07-28T15:43:33.613 回答
0

在这里看看这篇文章。它很好地概述了 DW 中暂存区的职责。

于 2010-09-13T06:39:19.057 回答
0

多么棒的问题。

过去，我们使用_MIRR（用于镜像）后缀用于登陆数据库的未转换数据，即。它反映了源。然后我们使用_STG来自源的转换数据，然后_DW是星型模式。

这里的临时表将在3NF. 我认为这是关键点。数据未经转换并与下一步完全规范化数据分开，然后将其全部展平到我们的星型模式中以进行报告。

于 2013-01-18T12:41:57.047 回答
-2

就个人而言，我不会去金博尔或其他地方找麻烦。

你在寻找什么样的“结构”？你觉得需要什么样的“结构”？您今天从缺乏“结构”中看到了什么问题？

我可能给你留下的印象是我不怎么看金博尔。不是这样 - 我还没有读过金博尔。除了适应某种模式之外，我只是不考虑无缘无故地改变事情。改变以解决一些现实世界的问题会很好。例如，如果您发现备份暂存表是因为缺乏结构导致暂存表和仓库表被视为相同，那么这将是更改结构的原因。但是，如果这是您的想法，那么您应该编辑您的问题以表明它。

于 2009-05-14T14:18:52.890 回答