在数据仓库中存储缓慢变化的属性的最佳方法是什么？

Question

在传统的关系数据仓库设计中,缓慢变化的属性(不经常更改的属性)存储在具有类似于此的模式的表中:

EntityKey,StartDate,EndDate,Attribute1,Attribute2,Attribute3 ......

(这可能与快速更改的属性形成对比,快速更改的属性可以存储为:
EntityKey,Timestamp,Attribute1,Attribute2,Attribute3 ......)

我不喜欢这种方法是有很多重复的信息.如果Attribute1每周更改一次而Attribute2每年更改一次,则最终会每周冗余地重复Attribute2.如果你有很多可以加起来的属性.

当然,你可以为每个时间间隔创建一个这样的表(一个表用于每周属性,一个用于每月,一个用于每年等)但在现实世界中,各种属性将在不同的时间点发生变化,不一定根据任何模式.此外,对于某些实体,相同属性可能比其他实体更频繁地更改.

我很好奇是否有人对这些属性的不同存储模式提出了建议或想法,这些属性不经常改变但频率不同(即每天更改一次,其他每周更改等).也许有些(非关系型)数据库技术我不知道哪种更适合这类问题？

Answer 1

我不喜欢这种方法是有很多重复的信息.

这就是仓库的重点.重复该信息以表示(a)发生的历史事实和(b)减少连接数.

如果Attribute1每周更改一次而Attribute2每年更改一次,则最终会每周冗余地重复Attribute2.如果你有很多可以加起来的属性.

错误.它根本不会很快加起来.

您似乎在谈论星型模式中的维度.它们相对较小.与事实表相比,存储无关紧要.不要标准化或优化.将此视为"预加入","高速","非规范化","仅报告"表.对非标准化数据感到满意:它更快.

如果您正在谈论事实表,那么这些更改具有不同的时间粒度,并且永远不应该在同一个事实表中.