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