Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры / 7 сообщений из 7, страница 1 из 1
29.04.2004, 10:43
    #32502034
ArtemL
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры
Допустим, существует некий куб с измерениями 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?

Есть ли у кого-нибудь идеи по этой формуле и по теме в целом?

Спасибо.
...
Рейтинг: 0 / 0
29.04.2004, 11:27
    #32502160
Владимир Штепа
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры
Если я правильно понял вашу задачу, то
селайте еще одну физическую меру c выражением

newMeasure = dbo.FactTable.Summa * dbo.FactTable.Stavka

которую сделаете Unvisible.


После этого выражение для Calculated Measure для Weighted Average будет элементарным

Weighted Average = Measures.newMeasure / Measures.Summa

и что самое главное - очень производительным
...
Рейтинг: 0 / 0
29.04.2004, 11:53
    #32502236
ArtemL
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры
To backfire:
авторnewMeasure = dbo.FactTable.Summa * dbo.FactTable.Stavka
Нет, в таком случае мы получим в качестве newMeasure произведение суммы Summa на сумму Stavka, а это не то же самое, что сумма соответствующих произведений:
(4+4)*(3+3) <> 4*3+4*3
...
Рейтинг: 0 / 0
29.04.2004, 11:55
    #32502244
ArtemL
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры
PS: для любого уровня выше листового
...
Рейтинг: 0 / 0
29.04.2004, 12:31
    #32502365
Владимир Штепа
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры
Нет, в таком случае мы получим в качестве newMeasure произведение суммы Summa на сумму Stavka, а это не то же самое, что сумма соответствующих произведений:
(4+4)*(3+3) <> 4*3+4*3



Как раз нет, т.к. мера не калькулированная, а физическая, то на уровне выше листового вы получите сумму произыведений, а не произведенение сумм.
...
Рейтинг: 0 / 0
29.04.2004, 12:46
    #32502415
ArtemL
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры
Сорри, невнимательно прочитал, что меру надо делать физической.
В таком случае действительно должно все получиться, мне самому как-то в голову не пришло.
Спасибо большое!
...
Рейтинг: 0 / 0
29.04.2004, 12:58
    #32502456
Владимир Штепа
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры
В том то и весь kick, что мера физическая.
...
Рейтинг: 0 / 0
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / MS AS: наиболее правильный подход для проектирования нестандартно аггрегируемой меры / 7 сообщений из 7, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]