ssas - 关于BI维度度量的思考

标签 ssas data-warehouse

我正在与一位顾问合作,他建议创建一个度量维度,然后将度量维度键添加到我们的事实表中。

我可以看到这如何通过仅添加行而不是在事实表中实际创建列来使添加新度量变得更容易。我还可以看到这如何向 ETL 过程添加工作,向星型模式添加另一个连接,在事实表中添加一个通用列来保存所有度量数据等。

我很想知道其他人是如何处理这种情况的。我们目前有近二十项措施。

最佳答案

本能地,我不喜欢它:它是 EAV 模型,不是很流行(您可以谷歌其原因)。

  • EAV模型普遍被认为是一个令人头疼的查询和维护
  • 不同的措施对应不同的维度;这种方法很容易变成“一个巨大的事实表来处理所有事情”,而不是针对特定报告领域的多个较小的事实表
  • 我怀疑您最终会创建 View 以提供多个事实表的外观
  • 您会将事实表中的行数乘以度量数,从而得到一个更大的物理表
  • 即使使用良好的索引/分区方案,包含多个度量的查询也必须读取更多行才能获取数据
  • 不同数据类型的度量如何?
  • 您的报告工具是否可以轻松支持这一点?

我敢肯定还有其他问题,但那些是立即浮现在脑海中的问题。根据经验,如果有人建议在任何情况下实现 EAV,您应该非常小心并询问他们究竟提供了哪些优势以及随着数据和复杂性的增加将如何管理它。但我认为您已经确定了一些关键的关注领域。

关于ssas - 关于BI维度度量的思考,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8229028/

相关文章:

xml - SSAS 多维数据集的 JSON 结果

reporting - 准确地平均一段时间内的数据

mysql - 如何实现从 mySQL 操作数据库到 Azure SQL 数据库的更新以进行报告

mysql - abinitio 中从字符串到 window-1252 的字符集转换

filtering - MDX:定义维度子集并显示总计

sql-server - SSAS 多维数据集的文档模板

excel - SSAS 日期在 Excel 筛选器中不起作用

data-modeling - 维度表中的主键是否必须是事实表中主键的一部分?

mysql - AD 日期的数据仓库

sql-server - [All] 既是级别又是成员(member)