在传统的关系数据仓库设计中，缓慢变化的属性（不经常更改的属性）存储在一个表格中，其表格类似于：
EntityKey，StartDate，EndDate，Attribute1，Attribute2，Attribute3 ......
（这可能与快速变化的属性形成对比，快速变化的属性可以存储为：
EntityKey，Timestamp，Attribute1，Attribute2，Attribute3 ...... ）
我不喜欢这种方法是有很多重复的信息。如果Attribute1每周更改一次而Attribute2每年更改一次，则最终会每周冗余地重复Attribute2。如果你有很多可以加起来的属性。
当然，你可以为每个时间间隔创建一个这样的表（一个表用于每周属性，一个用于每月，一个用于每年等）但在现实世界中，各种属性将在不同的时间点发生变化，而不是必须按照任何模式。同样对于某些实体，相同的属性可能比其他实体更频繁地更改。
我很好奇是否有人对这些属性的不同存储模式提出了建议或想法，这些属性不经常改变但频率不同（即每天有一些变化，有些是每周变化等）。也许有些（非关系型）数据库技术我不知道哪种更适合这类问题？
答案 0 :(得分：7)
我不喜欢这种方法，因为有很多重复的信息。
这就是仓库的重点。重复该信息以表示（a）发生的历史事实和（b）减少连接数。
如果Attribute1每周更改一次而Attribute2每年更改一次，则最终会每周冗余重复一次Attribute2。如果你有很多可以加起来的属性。
错误。它根本不会很快加起来。
您似乎在谈论星型模式中的维度。它们相对较小。与事实表相比，存储无关紧要。不要正常化或优化。考虑这个＆＃34;预加入＆＃34;，＆＃34;高速＆＃34;，＆＃34;非规范化＆＃34;，＆＃34;仅报告＆＃34;表。对非标准化数据感到满意：它更快。
如果您正在谈论事实表，那么这些更改会有不同的时间粒度，永远不会应该在同一个事实表中。