Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
29.04.2004, 10:43
|
|||
|---|---|---|---|
|
|||
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры |
|||
|
#18+
Допустим, существует некий куб с измерениями Geo, Time, Article и мерами Summa и Stavka. Необходимо получить итоговую меру Sred, представляющую, например, средневзвешенное по всем измерениям. Несколько способов, пришедших на ум: - Последовательно вычисляем средневзвешенное по каждому измерению. Сначала по Geo (для простоты опустим проверку Summa на 0) iif(IsLeaf([Geo].Currentmember), [Measures].[Stavka], iif(IsLeaf([Geo].Currentmember.FirstChild), Sum([Geo].Children, [Measures].[Summa]*[Measures].[Stavka])/[Measures].Summa], Sum([Geo].Children, [Measures].[Summa]*[Measures].[GeoSred])/ [Measures].[Summa])) Затем по Time на основе предыдущего Calc Member (GeoSred), и только 3-ий Member по Article будет искомым Sred. Понятно, что при большом количестве измерений не самый рациональный способ. Хотя в своем случае я пока остановился на нем. - Использование Custom Rollup Formula. Не пробовал, но из минусов полное отсутствие преаггрегации (поправьте, если ошибаюсь), поскольку Custom Rollup будет по всем измерениям, и невозможность стандартно аггрегировать сумму в том же кубе. - Возможно, оптимальным было бы использовать что-то вроде такой формулы: iif((IsLeaf([Geo].Currentmember) AND IsLeaf([Time].Currentmember) AND IsLeaf([Article].Currentmember)), [Measures].[Stavka], Sum(Crossjoin( iif(IsLeaf([Geo].Currentmember), [Geo].Currentmember.Siblings,[Geo].Currentmember.Children), iif(IsLeaf([Time].Currentmember), [Time].Currentmember.Siblings, [Time].Currentmember.Children), iif(IsLeaf([Article].Currentmember), [Article].Currentmember.Siblings, [Article].Currentmember.Children)), [Measures].[Summa]*[Measures].[Sred]) /[Measures].[Summa]) Но, к сожалению, iif может возвращать только строковые или числовые значения, а не множества, поэтому MDX ругается на iif в crossjoin. Замена на конструкции типа iif(IsLeaf([Geo].Currentmember), [Geo].Currentmember.FirstSibling,[Geo].Currentmember.FirstChild) : iif(IsLeaf([Geo].Currentmember),[Geo].Currentmember.LastSibling, [Geo].Currentmember.LastChild) тоже не помогла. Может MDX вообще не разрешает использовать iif в crossjoin? Есть ли у кого-нибудь идеи по этой формуле и по теме в целом? Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.04.2004, 11:27
|
|||
|---|---|---|---|
|
|||
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры |
|||
|
#18+
Если я правильно понял вашу задачу, то селайте еще одну физическую меру c выражением newMeasure = dbo.FactTable.Summa * dbo.FactTable.Stavka которую сделаете Unvisible. После этого выражение для Calculated Measure для Weighted Average будет элементарным Weighted Average = Measures.newMeasure / Measures.Summa и что самое главное - очень производительным ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.04.2004, 11:53
|
|||
|---|---|---|---|
|
|||
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры |
|||
|
#18+
To backfire: авторnewMeasure = dbo.FactTable.Summa * dbo.FactTable.Stavka Нет, в таком случае мы получим в качестве newMeasure произведение суммы Summa на сумму Stavka, а это не то же самое, что сумма соответствующих произведений: (4+4)*(3+3) <> 4*3+4*3 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.04.2004, 11:55
|
|||
|---|---|---|---|
|
|||
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры |
|||
|
#18+
PS: для любого уровня выше листового ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.04.2004, 12:31
|
|||
|---|---|---|---|
|
|||
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры |
|||
|
#18+
Нет, в таком случае мы получим в качестве newMeasure произведение суммы Summa на сумму Stavka, а это не то же самое, что сумма соответствующих произведений: (4+4)*(3+3) <> 4*3+4*3 Как раз нет, т.к. мера не калькулированная, а физическая, то на уровне выше листового вы получите сумму произыведений, а не произведенение сумм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
29.04.2004, 12:46
|
|||
|---|---|---|---|
|
|||
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры |
|||
|
#18+
Сорри, невнимательно прочитал, что меру надо делать физической. В таком случае действительно должно все получиться, мне самому как-то в голову не пришло. Спасибо большое! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=49&tablet=1&tid=1872655]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 345ms |

| 0 / 0 |
