我最近找到了对“Data Vault Modeling”的引用' 作为数据仓库的模型。我以前见过的模型是 Inmon 和 Kimball。作者提到了由于需要连接而可能出现的性能问题。它看起来像一个不错的模型，但我想知道其中的陷阱。网上有经验报告吗？

最佳答案

我们一直在使用对 Data Vault 的自制修改多年来，称为“链接建模”，它只有实体和链接；从 neo4j 中汲取原理，但在 SQL 数据库中实现。

Link Modeling 和 Data Vault 都是与 Kimball/Inmon 模型截然不同的思维方式。

我下面的评论涉及使用以下结构构建的系统:一个临时暂存数据库、一个 DWH，然后是从 DWH 构建的许多集市。还有其他方法来构建 DWH 解决方案，但这是非常典型的。

与 Kimball/Inmon

• 数据在进入 DWH 的途中被清理，但有时在进入登台数据库的途中被应用
• 业务规则和MDM (通常)在暂存数据库和 DWH 之间应用
• 集市通常是特定主题领域的

使用数据仓库/链接建模

• 数据在暂存阶段保持不变
• 这些数据也未清理地传递给 DWH，但以实体/链接形式存储
• 在 DWH 和集市之间应用数据清理、MDM 和业务规则。
• 集市基于学科领域的特定需求(同上)。
• 对我们来说，我们经常(但不总是)构建 Kimball Star Schema 风格的集市，因为最终用户很容易理解这些集市的数据结构。

Link Modeled DWH 出现的情况如下(使用 Kimball 术语来表达问题)

• 有时，用户会询问“为什么特定数字具有此值？”。在传统的 Kimball/Inmon 中，数据在进入的途中被清理，无法知道原始值是多少。链接模型在 DWH 中有原始数据。
• 当不存在链接多个维度的交易记录时，需要能够报告完整的数据集，例如提出诸如“特定经纪人出售的多少保单没有支付理赔交易？”之类的问题。
• MDM在2型Kimball或Inmon DWH中的应用会导致大量2型变更记录被写入Dimensions，其中往往包含所有数据值，因此存在大量重复数据。使用链接模型/数据仓库，新的维度值只会导致在链接表中创建新的类型 2 链接，该链接表只有实体表的外键。这通常在 Kimball DWH 中通过缓慢变化的尺寸和 fast changing dimension 来克服。 ，这是一个公平的解决方法。
• 在保险业和其他需要能够生成“截至日期”报告的行业中，事实表也会慢慢发生变化，针对第 2 类事实记录的第 2 类维度跟踪是一场噩梦。
• 从开发的角度来看，向大型 Kimball 维度添加新列需要谨慎进行，并且考虑回填很重要，但是对于链接模型，向实体添加额外的列相对微不足道。

在 Kimball 方法论中总是有解决这些问题的方法，但它们需要一些仔细的思考，有时还需要一些跳跃。

从我们的角度来看，链接建模几乎没有缺点。

我与任何营销/生产 Kimball/Inmon 或 Data Vault 方法的公司没有关联。

https://stackoverflow.com/questions/3048585/