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