Data Vault玩转数据仓库（二）

最新推荐文章于 2022-10-10 22:29:42 发布

哥本哈士奇

最新推荐文章于 2022-10-10 22:29:42 发布

阅读量445

点赞数

分类专栏： BI

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文链接：https://blog.csdn.net/aspnetx/article/details/108564028

版权

本文探讨了数据仓库中哈希计算的重要性，包括HASH KEY、HASH DIF和其它关键设计元素如RECORD SOURCE、LOAD DATE及CHANGE INDICATOR。作者分析了哈希计算在数据整合和性能优化中的角色，以及在不同场景下如何选择合适的设计策略。文章还提到了Data Vault方法论的演变，并对各项元素的适用度给出了评分。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

写在前面

本篇先不讨论Data Vault其本身，因为不见得所有人都接受这个。但是里边有一些很不错的东西跟主流的数据仓库方法是有共同点的，所以这里主要讨论这些共同的方法，在笔者看来，无论是Kimball还是DV，这些方法都是很有用的。这个系列为作者本人哥本哈士奇的个人理解和总结，可能会有理解上的偏差，也欢迎大家一起来讨论。

哈希计算

常用的哈希计算，HASH KEY, HASH FULL, HASH DIF，这里会有简单的介绍。

关于如何做哈希计算，可以参考这个链接：

https://www.hansmichiels.com/2016/04/09/hash-diff-calculation-with-sql-server-datavault-series/

HASH KEY

哈希键，通常是根据业务键来生成的，比如车辆的唯一识别号，如果已知一个系统的业务键跟另外一个系统的业务键可能有重合，那么可以考虑把RECORD SOURCE（后面会有介绍）也加进来参与计算。

在传统的数据仓库方法论里，出于性能角度的考虑，会在维度加载的时候去维护一个维度键和代理键的映射表，生成一个数值作为代理键，然后在维度表里只保留这个数值。维度加载完毕之后，加载事实表的时候，遇到了这个维度键，先会去映射表里查对应的代理键ÿ

最低0.47元/天解锁文章

评论

被折叠的条评论为什么被折叠?

到【灌水乐园】发言

查看更多评论

添加红包

成就一亿技术人!

hope_wisdom

发出的红包

实付元

使用余额支付

点击重新获取

扫码支付

钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。