在对数据仓库进行建模时,是否有任何理由我们应该偏爱Data Vault而不是维度建模?这两者之间的主要区别是什么?
5 回答
在我看来,维度建模仍然是分析和报告的最佳实践,也是业务用户最能理解的可视模型。
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,需要一个新旧的集成视图。然而,我的经验是,如果你直接从这个模型开始填充数据集市,你最终会得到很多连接,尤其是递归,因为你远离业务概念。在某些数据库上并不完全糟糕,因此选择部分受软件影响(例如,Teradata 比 Oracle 更喜欢加入)。但是总的来说,我的感觉是,如果您需要 TARGET(业务)方面的灵活性,那么您最终会陷入 inmon-kimball 讨论中,并且在该方面考虑维度建模而不是数据库并不是一个糟糕的开始。
因此,您评估中的部分输入还应该是:业务概念的标准化程度如何?整个公司是否使用相同的 KPI 和数据概念?如果不是这种情况,那么在您的数据仓库中的某处靠近源(尤其是如果有很多源)对我来说似乎是一个安全的选择。如果更成熟,请为报告需求的更大灵活性做好准备 - 并将数据模型的性能转移到报告方面。
这并不是说业务不能发展——只是它必须作为一个整体发展。我认为这是一个更“成熟”的客户,他们知道可以用他们的数据做什么,对他们的业务有一个非常集成和标准化的视图,在报告方面有越来越复杂的要求。因此,如果您需要为提供数据集市的灵活性进行建模,并且您拥有强大的 ETL 工具集,那么您不妨直接设置您的数据模型以更加类似于业务。
总而言之,我认为随着 BI 环境变得更加“成熟”,企业已经学会了如何处理数据,而这方面的需求也变得更加复杂。Data Vault 不会是那方面的出路。
但是,如果您处于迁移中(尤其是在长达数年的并行阶段),或者在一个年轻的组织中,并非所有部门都以相同的眼光看待他们的业务,但是(对您有利)报告要求是相当可监督的,它会可以选择预先使用数据保险库,并尝试查看是否可以直接从中提供数据集市 - 可能会在两者之间添加 Kimball 尺寸的味道。
偏爱任何方法通常是平衡经验和意见与系统的需求和要求的问题。每种建模方法在与不同情况相关时都有一定的优势,因此在确定采用哪种方法时,您必须评估模型将与之交互的环境。
频繁且统一地添加数据的高度事务性系统通常适合维度建模方法。用于描述它的常见示例通常集中在零售和金融组织,因为随着时间的推移添加的销售或货币交易数量符合事实和维度概念。
为什么你觉得你需要他们中的任何一个?它们大多是用于销售书籍和培训课程的大量专业术语的设计模式。数以百万计的人发现,没有他们他们也能过得很好。设计数据仓库真正需要的是任何数据库所需的良好分析和建模技能。
如果您正在寻求有关构建数据仓库的有用建议,请查看 Bill Inmon 的书籍。如果这是您的第一个商业智能项目,那么请从该领域有经验的人那里获得一些帮助,这样您就可以避免一些常见的陷阱。