数据仓库设计，多维还是一维带属性？答案

【问题标题】：Data warehouse design, multiple dimensions or one dimension with attributes?数据仓库设计，多维还是一维带属性？
【发布时间】：2013-05-21 14:49:24
【问题描述】：

在数据仓库上工作，正在寻找有关具有多个维度与具有属性的大维度的建议。

我们目前有 DimEntity、DimStation、DimZone、DimGroup、DimCompany，并且有多个事实表，其中包含来自每个维度的键。这是最好的方法，还是只有一个维度 DimEntity 并包括站、区域、组和公司作为实体的属性更好？

我们已经使用 ETL 实现了单独维度的路线，因此填充和构建星型模式的工作不是问题。性能和可维护性很重要。这些尺寸不会经常变化，因此请寻求有关处理此类尺寸的最佳方法的指导。

事实表有超过 1 亿条记录。实体维度有大约 1000 条记录，其他列出的每条记录不到 200 条。

【问题讨论】：

不幸的是，如果不了解有关您的实体是什么、它们的属性是什么、您的事实表代表什么、用户希望如何查看数据、哪些功能等详细信息，就无法真正回答这个问题您的报告工具有等。也许如果您可以使您的问题更具体，您可能会得到更好的答复。
感谢您的反对！
我希望投反对票的人给出一个理由。同样对于那些说添加更多信息的人来说，在你投票之前给这个人时间更新怎么样。有些人实际上是有生命的，而不是 24/7 时刻盯着他们的电脑。获得生命。
我没有投票给你，但 FWIW 匿名投票已经在元网站上讨论了 many times 并且结论 - 到目前为止 - 一直是允许它。您可以阅读这些线程以查看双方的各种论点。
没问题，我不认为是我，但我认为向您指出一些关于否决投票以及为什么您不能指望 cmets 的信息可能会很有用

【解决方案1】：

如果不知道您的星型模式表定义、数据基数等，很难给出是或否。这将是一个平衡的行为。

为了提高读取性能，事实表应尽可能精简，维度应尽可能短（行数少）。合并维度通常意味着当维度记录数增加时，事实表会变得更小。

如果您可以在不向合并维度添加大量行的情况下合并维度，则可能值得研究。可能您可以将低基数维度组合成垃圾维度并实现良好的平衡。不应合并具有高基数属性的维度。

Here's Kimball 大学一篇关于维度建模的好文章。具体看看他在哪里处理蜈蚣事实表以及他如何建议使用垃圾维度。

【讨论】：