Вот такое вот безобразие кому-нибудь удавалось получить?

Так кто мешает суммирование поставить?

Какое еще суммирование?! Наоборот надо получить возможность разворачивать иерархию без агрегирования и видеть напротив определенного узла определенное значение. То есть данные из дочерних узлов не должны поступать на родительские узлы.

Там дело не в суммировании. Есть проведённые узлы со значениями. И на узле показывается СУММА всех нижележащих листьев и узлов. А должно показываться само значение проведённого узла (которое мы видим, если поставить галочку "показ проведённых узлов"). Я в своё время подавил логикой экстрактора записав нужные значение в атрибут признака.
Но мне говорили, что такая хрень может быть достигнута использованием переменной "путь замены" и заменить на внешний атрибут самого признака, а затем умножить эту переменную еще на что-то. Я мучался несколько часов, затем забил на это.

Есть еще способы - но они совсем через задницу, (создание ограниченных показателей на каждое значение проведённых узлов и галкой константа-выбор).

Сам хотел бы понять, есть ли нормальные пути.

Я промучался сегодня полдня, но все-таки сделал, хотя и действительно, от элегантности далековато... но ограниченные показатели создавать не пришлось, про константу-выбор я вообще не пойму как с ней работать. Сделал через расчетные показатели на провайдере со всякими булевыми формулами и с использованием стандартных формул в структуре показателей запроса... работает... хотя решение все-таки не слишком универсальным получилось...

Вот это в хелпе нашёл. Не знаю, могло бы оно помочь.

Мне кажется здесь речь идет о возможности посредством переменной замены влиять на результат агрегации по конкретному признаку, то есть определить переменную замены для активного признака (используемого в отчете) с тем, чтобы потом проверять его ключевые значения в формулах и кое-что дорасчитывать. С иерархиями дело обстоит сложнее. Кстати, я тоже сначала долго ковырялся с переменной замены, но в итоге сделал без нее.

Избавлялись от таких проблем, загружая в кубы данные только только по листьям иерерахии...

может лучше так?

А что это даст ?

Пример:

Головная компания и 2 дочерних.
В головной компании работает 5 человек, плюс один босс
В дочерних по 10 и по одному боссу.

Всего под руководством босса головной компании работает 27 человек, а под непосредственным руководством - только 5.

В отчете надо видеть иерархическую структуру компаний и количество непосредственно подчиненных для каждого босса напротив наименования компании.

И все-таки как же решить эту проблему (свой собственный вариант я забраковал, как слишком частный случай). Ну хоть зацепку дайте

чтобы получить это:
1 10
|-2 20
|-3 30

надо запостить вот это:
2 20
3 30
1 -40 (или 10 - 50)

и скрыть в бекс значения проведенных узлов

опять же вариант для статической иерархии, но тоже решение
к тому же он реализован и благополучно работает

Все подобные решения прокатывают только как было отмечено для тех иерархий, которые невелики по размеру и не изменяются с течением времени. Тогда можно использовать подобные приёмы, а также делать ограниченные показатели на обьекты-узлы иерархии с параметром "константа-выбор" и тому-подобные извращения. Но, если, скажем иерархия сотрудников, состоящая из десятков (а то и сотен) тысяч листьев и тысяч узлов, загружается каждый день и постоянно меняется - тады не проканает.

Не прокатывает так же по причине необходимости по желанию пользователя скрывать часть узлов иерархии. Например выводятся
Родитель и его дочки. Иерархия построена на базе признака A, у которого есть атрибут B. И пользователь хочет посмотреть только те дочки родителя, которые имеют атрибут B равным B1, а все остальные скрыть. В результате в отчете значение на родительском узле станет некорректным.

Кстати, пробовал как-то задействовать константу-выбор. Так и не смог понять где ее вообще используют и чего она дает. У меня что с ней, что без нее результаты показателей не меняются?!

Вопрос с отображением фиксированных значений теоретически решаем, но только в том случае, если удастся отличать между собой тип агрегируемых узлов. Например, по уровню иерархии или по атрибуту "Тип узла" у признака, на базе которого построена иерархия. Однако, я так и не смог заставить переменной замены для агрегированного узла в иерахии вернуть правильное значение. Если это формула, то возвражается X (то есть невозможно определить), если расчетный показатель на уровне провайдера, то возвражает сумму дочек (почему сумму, так и не понял... мог бы и произведение вернуть что ли, фигня какая-то).

Если есть у кого шаманский SAP-бубен прошу поделиться...

Константу-выбор изначала выдумали для сравнительного анализа. Предположим у вас есть чемпион по продажам в какой-либо отрасли, а вы хотите получить процентное соотношение количества продаж конкурентов к количеству продаж чемпиона. На западе подобные исследования называют benchmarking. Например чемпион продаж автомобилей в мире сейчас Toyota. GM продаёт 90% от того количества, которое продала Toyota, Ford 80% и так далее.

Пусть у нас есть 2 продавца Иван и Пётр. Продают они яблоки и апельсины. Вот таблица фактов

Day Salesp Product QTY IVAN-RESTR IVAN-CONST
01 IVAN APPLE 2 2 2
01 PETR APPLE 3 0 2
01 IVAN ORANGE 1 1 1
01 PETR ORANGE 4 0 1


В столбце QTY - количество проданных фруктов. В столбце IVAN-RESTR ограниченный показатель Количество по продавцу Иван. А столбец IVAN-CONST - тоже самое, но IVAN с константа-выбор.

Почуствуйте разницу.

А работает это так.

Берём определённую строку (например 2-ю)
Какое значение выберется из таблицы фактов ? Значения признаков - День 01, Продавец- Пётр, Продукт - Яблоко. В таблице фактов "напротив" этих значений признаков лежит значение 3. В случае "константа-выбор" система "заменит" продавца на значение Иван и сделает соответствующий Select. Какое значение лежит в таблице фактов, если взять строку 2 (со значениями, рассмотренными ранее) и заменить в ней значение Пётр на Иван ? Это будет 2. Для всех остальных строк буден использоваться аналогичный алгоритм, то есть значение признака продавец будет всегда Иван, и будет выбрано соответствующее значение поразателей в таблице фактов.

Не знаю, может сумбурно обьяснил, попробуйте сами поэкспериментировать

2 RSA1

Спасибо. Даже очень вполне понятно. Попробую поколдовать с иерархией...