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