Bмеем нехорошего вида OLTP. с историей изменений и кривым дизайном. бывает... OLTP содержит 2 таблицы - в одной георгафия, в другой unit, которые по географии разложены посредством таблицы связи unitregion(unitid, regionid)

table region:
сожержит географическую иерархию от региона (канада) до этажа (работа с отелями и комплексами аппартаметтов) (is, name, parentid, levelid).
где уровни:
1 region
2 subregion
3 state
4 island
5 city
6 area
7 complex
8 building
8 floor

иерархия сбалансирована посредством значений по умолчанию. вида
Parent Name+ ' No ' + level name
например Colorado No Island и так далее. то есть все 9 уровней для любого пути если идти от листа. (что снимает ограничение несбалансированного дерева, которое умеет Discoverer for OLAP Если я не ошибаюсь).

Далее мы имеем дименшен Unit: представляет собой
дом в комплексе (например как котедж)
номер в отеле (например пентхауз на 2-х этажах здание II, комплех - 2 здания)
номер в отеле на конкретном этаже (комплех из 1 или более зданий, типа горнолыжного курорта и так далее)

итого Unit может быть join на уровень complex, building, floor.

Требуется испечь отчет, которые связывает unit<->region hierarhy, например сколько их висит под каждым уровнем и открыть детали.

индусы утверждают, нельзя такое сделать ни в каком виде в discoverer. То есть они не могут провязать Unit на иерархию 3 раза. Я им застала здоровую staging table на эту тему с сообщением вот вам таблицы, тут все есть, разбирайте по чатям как хотите, там только = и inner/left jojn, но все равно упорствуют.

Версия Discoverer 10.1.2

Вопрос: можно или нельзя, и как если можно.

после некоторого упорного пинания индусов и посылки им некоторого количества функций было получено следующее:
используется тот факт, что все юниты принадлежат какому-то комплексу, то есть комплех-юнит это 1-n, 2-х комплексов у одного юнита быть не может, то есть комплекс - это must.
после чего строится на лету staging table которая выдает regionid, complexid, unitid и кое-что еще, где complexid - это в каком кмплексе юнит сидит, regionid - это кто собственно папа комплекса, это дело пихается в custom folder в discoverer, вроде как дергается, юниты не теряет... есть еще один staging, который возвращает
complexid, buildingid, floorid, regionid, unitid, level - это вся подноготная под комплексом,
еще один staging - это то же самое как выше, только от уровмя Region (верхнего) до floor (нижнего).
вобщем индусы теперь развлекаются.
правда заставила их запросы переписать, они там впаяли 7 лишних join да еще в куче с connect by который им там нафиг не нужен.. вобщем развлекаемся пока.
некоторое количество отчетов с такой структурой живет намного лучше...
остается вопрос как по такому drill down делать... вот это пока не совсем ясно...