我创建了一个维度模型，其结构类似于 AdventureworksDW 环境中的财务报告设计，其中每个帐户的值作为事实表中的单个值列保存，并且维度赋予数据其语义含义。
此模型中有超过一千列，因此可以很好地添加或删除其他列。这是一个关于这个设计的非常好的博客：http: //garrettedmondson.wordpress.com/2011/10/26/Dimension-modeling-financial-data-in-ssas/
虽然这个模型在查询维度模型方面效果很好，并且有一些例子支持这个模型进行维度分析，但我担心这个模型不是多维数据集开发或数据挖掘的标准，它们似乎更喜欢更宽的表。
问题：此设计是否被归类为实体-属性-值 (EAV)？
使用多个事实表的设计会更好吗？如此多的宽事实表（最多 10 个），每列最多 200-300 列，但行数更少。
我是否应该期待更宽的表会出现更多性能问题？
您是对的，特定设计被视为 EAV 模型。
通过使用这样的设计，您可以轻松添加新帐户、层次结构等。您无需更新模型。
我不建议每个度量方法一列。大多数帐户在大多数行中将为空。同样使用这样的设计，即使您只需要检索其中一个，您也需要阅读所有度量。
我们在多维数据集中大量使用帐户维度。不幸的是，像共享成员这样的事情在 SSAS 中并不像在 Essbase 中那样容易处理。
您需要创建一个作为父子的帐户维度，并且您需要像往常一样在事实表中拥有该帐户维度的键。通过使用帐户维度，您可以很好地支持时间平衡功能。使用 SSAS 的时间平衡功能应该比自定义 MDX 代码更快。
目前，我们正在将一元运算符和父子关系转换为公式。所以基本上我们有正常的公式，层次结构中的父级也可以作为公式。最后，我们正在扁平化层次结构。所以不可能在账户维度下钻取。我们仅使用帐户维度作为计算引擎。也可以有适当的层次结构，但我们决定不要同时混合自定义汇总成员和一元运算符。
共享成员和我们作为自定义汇总成员实施的所有公式。