Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
Есть измерение Номенклатура - несбалансированное парент-чайлд. Количество элементов 110000. Есть измерение Магазины в которых эта номенклатура продается. Суть АБСД анализа - определить ассортимент номенклатуры, составляющий для каждого магазина 85% от прибыли - это будет группа А. Для групп БСД тоже есть границы по прибыли. Сложность в том, что ассортимент для вхождения в группы надо анализировать не весь, а в рамках соответсвующих товарных групп. Товарные группы находятся на уровне 4 измерения номенклатура. Вот и не понятно как сделать хитрый МДХ, где по строкам номенклатура, по колонкам магазины, а в области данных - группа номенклатуры для магазина. Может кто подскажет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 14:02 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
А если у вас номенклатура - parent/child dimension. То почему же Товарные группы находятся на 4 уровне. Может parent/child это лишнее? Вы можете более подробно описать реальную структуру фактически имеющихся данных в вашем измерении? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 14:59 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
Фактические данные - это несбалансированное парент-чайлд измерение, с максимальным количеством уровней 8. С коммерческим директором проанализировали дерево измерения и решили, что анализ АБСД стоит производить в рамках потомков элементов, находящихся на 4 уровне измерения - там только группы, глубже уже появляются элементы. Так что смотрю я на функцию Rank() и думаю с какой стороны к ней подойти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 15:09 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
To Вжик: на 4 уровне измерения - там только группы, глубже уже появляются элементы. Так что смотрю я на функцию Rank() и думаю с какой стороны к ней подойти. Я бы на Вашем месте увидел Ваш 4-й уровень иерархии через диалоговое окошко работы с подмножествами в OLAP-клиенте Cognos PowerPlay. Перетащил бы в отчет это подмножество (которое всегда будет отслеживать, не появились ли новые элементы на 4-м уровне, и если появились - они появятся в отчете автоматически). А потом бы применил к этим мемберам сначала функцию ранжирования, а затем взял бы нарастающий процент от базы, где база - сумма всех мемберов. В итоге я бы увидел, сколько мемберов дают первые N1%, сколько мемберов - первые N2% и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 19:07 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
привожу на примере FoodMart. Если есть вопросы к нижеприведенному - рад буду прокомментировать. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 20:16 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
JuriiЯ бы на Вашем месте увидел Ваш 4-й уровень иерархии через диалоговое окошко работы с подмножествами в OLAP-клиенте Cognos PowerPlay. Перетащил бы в отчет это подмножество (которое всегда будет отслеживать, не появились ли новые элементы на 4-м уровне, и если появились - они появятся в отчете автоматически). А потом бы применил к этим мемберам сначала функцию ранжирования, а затем взял бы нарастающий процент от базы, где база - сумма всех мемберов. В итоге я бы увидел, сколько мемберов дают первые N1%, сколько мемберов - первые N2% и т.д. вас человек спросил о МДХ для MS AS, а вы ему про Cognos, в котором МДХ НЕТ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 20:19 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
Вот немного другая вариация Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 21:47 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
Интересный Вопрос - "хватает ли ума" у MDX query процессора, не рассчитывать каждый раз Код: plaintext ведь в одном столбце, его результат не меняется, ведь контекст вычисления не изменяется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.10.2004, 23:36 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
Спасибо огромное! Примерно так и я мыслил на прошедших выходных. Буду пробовать. А по поводу "хватает ли ума" ответ такой - сеты считаются только раз, так что при нормальном подходе и результат будет соответствующий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2004, 09:50 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
Если не секрет - откуда примеры? Из собственного опыта или литературы? Если из литературы - нельзя ли название? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2004, 10:05 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
Возникает вопрос, если сеты считаются при процессинге - то не проще ли сделать ABC-классификацию в SQL? Лично я делаю именно так, т.к. в Cognos PowerPlay runtime-вычисления не очень развиты. И, к тому же, SQL может быть источником для реляционных отчетов в ReportNet etc., а MDX-нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2004, 10:16 |
|
||
|
Непростая задача про АБСД анализ.
|
|||
|---|---|---|---|
|
#18+
Пока я делаю так, потому, что применение МДХ обеспечивает гибкость. SQL, по моему мнению - это больше шаблонности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2004, 10:24 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=32761279&tid=1872115]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
150ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 493ms |

| 0 / 0 |
