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

在经典的关系数据仓库设计中，缓慢变化的属性（很少变化的属性）存储在一个表中，其模式类似于：

EntityKey、StartDate、EndDate、Attribute1、Attribute2、Attribute3

（这可能与快速变化的属性形成对比，这些属性可以存储为：
EntityKey、时间戳、属性1、属性2、属性3…）

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

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

我很好奇，是否有人对这种属性的不同存储模式提出了建议或想法，这些属性很少更改，但更改频率不同（例如，有些每天更改，有些每周更改，等等）。也许有一些（非关系型）数据库技术更适合这种类型的问题

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

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

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

错。加起来一点也不快

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

---

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

我不想将数据限定为维度或事实，因为情况（缓慢变化的属性，在Kimble文献中称为类型2）事实数据和维度数据都可能发生。我同意这种模式通常应用于维度数据，并且维度数据增长相对缓慢（可能与事实数据相比）。尽管如此，我仍然很好奇是否还有其他方法可以更有效地存储缓慢变化的属性，即使冗余数据没有那么大。我确实明白您关于将这些表视为“预联接”的观点。不。缓慢更改属性不能发生在事实表中。这有一个定义良好的方法：创建一个新的事实行。不是对现有事实行的更改。“缓慢更改”仅适用于维度，因为维度属性更改是一项棘手的工作。事实不会改变。新的事实产生于不同的适用日期。