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

Question

在经典的关系数据仓库设计中，变化缓慢的属性（不经常更改的属性）存储在具有类似于以下架构的表中：

EntityKey、StartDate、EndDate、Attribute1、Attribute2、Attribute3...

（这可能与快速变化的属性形成对比，后者可以存储为：
EntityKey、Timestamp、Attribute1、Attribute2、Attribute3...）

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

当然，您可以为每个时间间隔创建一个这样的表（每周属性表、每月表、每年表等），但在现实世界中，各种属性会在不同的时间点发生变化，而不是必然根据任何模式。此外，对于某些实体，相同属性的更改可能比其他实体更频繁。

我很好奇是否有人对不经常更改但频率不同（即，有些每天更改，有些每周更改等）的此类属性的不同存储模式有建议或想法。也许有一些我不知道的（非关系）数据库技术更适合这类问题？

Answer 1

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

这就是仓库的意义所在。重复信息以表示 (a) 发生的历史事实和 (b) 减少连接的数量。

如果 Attribute1 每周更改一次，而 Attribute2 每年仅更改一次，那么您最终会每周重复 Attribute2 冗余。如果你有很多可以加起来的属性。

错了。它根本不会很快加起来。

您似乎在谈论星型架构中的维度。它们相对较小。与事实表相比，存储无关紧要。不要规范化或优化。考虑这是一个“预连接”、“高速”、“非规范化”、“仅报告”表。对非标准化数据感到满意：它更快。

如果您谈论的是事实表，那么这些更改具有不同的时间粒度，并且从不应该在同一个事实表中。