[为数据仓库建模时，有什么理由使我们比Data Vault更喜欢Dimensional modelling吗？两者的主要区别是什么？
我认为，维度建模仍然是分析和报告的最佳做法，并且是业务用户最好理解的可见模型。
Data Vault更适合Bill Inmon推荐的大型企业数据仓库，但不适用于分析和报告，因为您仍然可能需要进行尺寸建模才能创建“虚拟”数据集市。在诸如Martijn Evers，Hennie de Nooijer或Ronald Damhof的博客中达到顶峰。
Data Vault更灵活，更易于添加新源，更具有审计能力并始终保留所有数据，因此您将能够始终重新创建DM。
因此，结论可能是理想的情况是将Data Vault用于您的企业数据仓库，并将维度建模用于您的Datamarts。
我认为将两者结合在一起将最适合大多数大型组织。对于中型企业ODS而言，保管库将是一个不错的选择，因为较少的结构可以促进灵活性和性能。然后可以从Vault Db中提取数据，以提供支持报表和分析的特定于上下文的维度数据集市。在这种情况下，金库Db也可以用于支持更多的大数据类型的挖掘和分析，这些类型的挖掘和分析需要对数据关系有更成熟的了解。
为什么您觉得您需要其中一个？它们大多是繁重的术语设计模式，用于出售书籍和培训课程。数以百万计的人发现，没有他们，他们可以过得很好。设计数据仓库真正需要的是与任何数据库相同的良好分析和建模技能。
如果您正在寻求有关构建数据仓库的有用建议，请查阅Bill Inmon的书。如果这是您的第一个商业智能项目，请从具有该领域经验的人员那里获得一些帮助，以便您避免一些常见的陷阱。
赞成任何方法通常是在经验和观点与系统需求之间取得平衡。每种建模方法在与不同情况相关时都具有某些优势，因此在确定采用哪种方法时，必须评估模型将与之交互的环境。
频繁且均匀地添加数据的高度事务处理系统通常适合于维建模方法。用于描述它的常见示例通常集中在零售和金融组织，因为随着时间的推移增加的销售或货币交易的数量符合事实和维度的概念。
@@ Danny Shaw，这也是我的经验（尽管我在该领域相对较新-来自ETL，所以很想在我的帖子中提供其他意见）。
我相信，很重要的一点是，要尊重客户的需求随着其“成熟度”而发展，并且不同的模型在不同的时间可能更合适。
[我的感觉是，Data Vault提供了操作灵活性，而现有的讨论（Kimball / Inmon）则更多地围绕'业务灵活性'（因为缺乏更好的术语）。
Data Vault使您可以在源方面保持细粒度的对象。这使得模型“可审核”且可扩展。它有助于灵活地选择SOURCE规范。
因此，它在例如迁移项目，可作为从那里提供更多面向业务的DWH / Datamarts的基础，这些DWH / Datamarts需要新旧视图的集成。但是，我的经验是，如果您直接从此模型开始填充Datamart，那么最终会导致大量的联接，尤其是递归，因为您与业务概念相去甚远。在某些数据库上并不完全不好，因此选择部分受软件的影响（例如，Teradata比Oracle更喜欢加入）。但是总的来说，我的感觉是，如果您需要在TARGET（业务）方面具有灵活性，那么您最终会陷入讨论中，那么考虑使用维度建模而不是那一侧的数据保险库将是一个不错的开始。
因此，您的评估输入的一部分还应该是：业务概念的标准化程度如何？整个公司是否使用相同的KPI和数据概念？如果不是这种情况，那么在数据仓库中某个地方靠近源（特别是如果有很多的话）似乎对我来说是一个安全的选择。如果更成熟，请准备更大的报告需求灵活性，然后将数据模型的性能转移到报告端。
这并不是说业务不能发展-只是业务必须整体发展。我认为这是一个更加“成熟”的客户，知道它可以使用他们的数据做什么，对他们的业务具有非常集成和标准化的看法，并且对报告的要求越来越复杂。因此，如果您需要建模以灵活地提供数据集市，并且您拥有强大的ETL工具集，则不妨直接设置数据模型以使其与业务更相似。
总而言之，我认为随着BI环境变得越来越'成熟'，企业已经了解了它可以处理数据的功能，并且该方面的需求也变得更加复杂。 Data Vault不会成为这种方式。
但是，如果您正在迁移中（尤其是处于长达数年的并行阶段），或者是在一个年轻的组织中，并不是所有部门都用相同的眼光看待他们的业务，但是（对您有利）报告的要求是可以监督的，可以选择预先使用数据仓库并尝试查看是否可以直接从中提供数据集市-可能会增加介于两者之间的Kimball尺寸。