Data Vault和维度建模之间的区别？

Question

在对数据仓库进行建模时，有什么理由比Dimensional modelling更偏爱Data Vault呢？这两者之间的主要区别是什么？

Answer 1

在我看来，维度建模仍然是分析和报告的最佳实践，并且作为一种最受业务用户理解的可视化模型。

Data Vault更适合于Bill Inmon推荐的大型企业数据仓库，但不适合分析和报告，因为您可能仍然需要维度建模来创建“虚拟”数据集市。在一些博客上达到顶峰，比如Martijn，Hennie de Nooijer或Ronald Damhof。

Data Vault更灵活，更容易添加新的数据源，更具审计能力，并始终保留所有数据，因此您将能够始终重新创建您的DM。

因此，可能得出的结论是，理想的情况是为企业数据仓库使用Data Vault，为数据仓库使用维度建模。

Answer 2

我认为这两者的结合最适合大多数大型组织。对于中间企业ODS来说，Vault将是一个很好的选择，因为较少的结构将促进灵活性和性能。然后，可以从Vault Db中提取数据，以馈送支持报告和分析的上下文特定维度数据集市。在该场景中，vault Db还可以用于支持更多大数据类型的挖掘和分析，这些挖掘和分析需要对数据关系有更成熟的理解。

Answer 3

@Danny这也是我的经验(尽管我在这个领域相对较新-来自ETL，对其他人在我的帖子上的输入非常好奇)。

我认为重要的是，要尊重客户的需求随着他们的“成熟度”而变化，不同的模型可能在不同的时间更适合。

我的感觉是Data Vault提供了操作灵活性，而现有的讨论(Kimball/Inmon)更多地围绕着“业务灵活性”(由于缺乏更好的术语)。

Data Vault允许您在其粒度对象方面与源保持接近。这使得模型是“可审计的”和可伸缩的。它有助于在源代码规范上提供灵活性。

因此，在迁移项目等方面，它是一个有用的中间层，可作为提供更多面向业务的DWH/Datamart的基础，这些DWH/Datamart需要旧的和新的集成视图。然而，我的经验是，如果您开始直接从这个模型填充Datamart，您最终会得到许多连接，特别是递归，因为您远离业务概念。在某些数据库上并不完全糟糕，所以选择在一定程度上受到软件的影响(例如，Teradata比Oracle更喜欢加入)。然而，一般来说，我的感觉是，如果你需要目标(业务)方面的灵活性，你最终会进入inmon-kimball讨论，考虑维度建模而不是在这一方面的数据库将是一个不错的开始。

因此，评估中的部分输入也应该是:业务概念的标准化程度如何？整个公司是否使用相同的KPI和数据概念？如果不是这样，在数据仓库中的某个地方靠近源(特别是如果有很多源的话)对我来说似乎是一个安全的选择。如果更成熟，请为报告需求的更大灵活性做好准备-并将数据模型的性能转移到报告端。

这并不是说业务不能发展-只是说它必须作为一个整体发展。我认为这是一个更“成熟”的客户，他们知道它可以用他们的数据做什么，对他们的业务有一个非常完整和标准化的视图，在报告方面的要求越来越复杂。因此，如果您需要为提供数据模型的灵活性而建模，并且您有一个强大的ETL工具集，那么您不妨直接设置您的数据模型，使其更接近于业务。

总而言之，我认为，随着BI环境变得更加“成熟”，企业已经学会了如何处理数据，这方面的需求变得更加复杂。Data Vault不是走在那一边的路。

然而，如果您正在进行迁移(尤其是在长达数年的并行阶段中)，或者在一个较年轻的组织中，不是所有部门都从相同的角度来看待他们的业务，但是(在您的优势中)报告要求是相当可见的，那么您可以选择预先使用data vault，并尝试从中直接输入数据-可能会在两者之间添加一些Kimball的维度。