密集成员和动态计算
考虑对密集维成员作以下更改:
• | 将密集维的高级别成员标记为“动态计算”。 |
• | 尝试将具有简单公式的密集维 0 级别成员标记为“动态计算”,然后评估检索时间的增加。 |
• | 不要将密集维成员标记为“动态计算和存储”。 简单公式是指不需要 Analytic Services 执行高成本计算的公式。例如,包含财务函数或交叉维运算符 (->) 的公式是复杂公式。 |
稀疏成员和动态计算
考虑对稀疏维成员作以下更改:
• | 将具有六个或更少子代的部分高级别稀疏维成员标记为“动态计算”或“动态计算和存储”。 |
• | 将具有复杂公式的稀疏维成员标记为“动态计算”或“动态计算和存储”。复杂公式需要 Analytic Services 执行高成本计算。例如,任何包含财务函数的公式都是复杂公式。 |
• | 将维中频繁重构的高级别成员标记为“动态计算”或“动态计算和存储”。 |
• | 不要将具有 20 个或更多子孙的高级别稀疏维成员标记为“动态计算”或“动态计算和存储”。 |
如果在计算脚本中明确指定“动态计算”或“动态计算和存储”成员,则计算脚本会失败。但动态成员可以参与运算(可以出现在等式右边)。以下计算脚本仅当 Qtr1 不是“动态计算”成员时有效:
FIX (East, Colas) Qtr1; ENDFIX ;
动态计算的计算顺序
当 Analytic Services 动态计算数据值时,其采用的计算顺序不同于批处理数据库计算顺序。
在批处理计算中,Analytic Services 按照以下顺序计算数据库:
1. | 标记为帐户的维 |
2. | 标记为时间的维 |
3. | 其他密集维(按其在数据库大纲中出现的顺序) |
4. | 其他稀疏维(按其在数据库大纲中出现的顺序) |
5. | 两遍计算 |
对于动态计算的值,在检索时,Analytic Services 通过按照以下顺序计算数据库来计算值:
1. | 稀疏维 |
o | 如果标记为时间的维是稀疏维且数据库大纲使用时间系列数据,Analytic Services 将以时间维为基础进行稀疏计算。 |
o | 否则,Analytic Services 将以通常用于批处理计算的维为基础进行计算。 |
2. | 密集维 |
a. | 标记为帐户的维,若为密集维 |
b. | 标记为时间的维,若为密集维 |
c. | 时间系列计算 |
d. | 其余密集维 |
e. | 两遍计算 |
f. | 属性 |
![]() | ![]() |
注释: | 如果数据检索使用属性成员,则计算顺序中的最后一个步骤为属性的合值。但在查询中使用属性成员将导致 Analytic Services 在动态计算中忽略时间余额成员的值。 在不使用属性的检索中,将时间余额成员的值应用到计算。在计算过程中使用和不使用属性成员的差异会对任何动态计算的高级别时间成员产生不同的结果。 |
![]() | ![]() |
在不使用属性的检索中,这些动态计算的成员在最后一个步骤中计算,故可以正确应用时间余额功能。但在使用属性的检索中,最后一个步骤是应用属性的合值。计算顺序的差异对动态计算的高级别时间成员产生两个不同的、可预测的结果。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7477027/viewspace-462913/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/7477027/viewspace-462913/