angroизвиняюсь за дремучесть, а что значит зашел на огонек"замапил" их на 25-30 иерархий, которые каждый "топ" сам себе выдумал

типа какая-то аналитика проставляется в элементах? или что-то другое имеется ввиду?
Трудности перевода с узко-специализированного языка (как называет моя жена - "птичьего") на человеческий - обычный спутник т.н. "проф-форумов"...
Мне, например, тоже не совсем понятно - о каких именно "элементах" вы спрашиваете (куда какая-то аналитика, якобы, проставляется)?
В OLAP-жаргоне мне пока еще не встречалось понятие "элемента", чес-слов...
Если же переводить конкретную фразу про "замапил" их на 25-30 иерархий...", то смысл высказывания примерно в следующем:
в таблице фактов OLAP-куба лежат только ID-шники (guid'ы) ссылочных объектов, по которым формируются "разрезы" аналитики (клиент, продукт, филиал), именно объектов как таковых (для каждого типа объекта существует совершенно конкретный их перечень в виде сплошного списка, не "отягощенного" никакой структурой/иерархией) уже существующих по месту возникновения/фиксации факта;

каждому типу объекта ("разрезу", "измерению", "размерности", dimension) создается тупая до невозможности таблица иерархий (GUID, ParentGUID, FriendlyName), в которой самый верхний уровень ("корень", root) скрыт от редактирования пользователями, а начиная от первого уровня - каждый любознательный пользователь может построить себе свою собственную иерархию по любому принципу, родившемуся в его любознательной голове;

до тех пор, пока тот же самый пользователь (или кто-то вместо него) не пропишет в специальной таблице соответствия ("маппинги", mappings) между "листьями" его иерархии и конкретными объектами из списков размерностей (dimensions) - он может просто любоваться этой иерархией ради эстетического удовлетворения (в OLAP-кубе она будет пустой, или ее вообще не будет пока кто-то не пересчитает dimensions);

как только это соответствие установлено - OLAP-куб уже может быть пересчитан с целью вычисления агрегатов уже по новым "пользовательским" веткам единой "глобальной" иерархии, которые отражают фантазию пользователя в отношении "административно-территориального деления" клиентов, например...
Это то, что касается "маппинга" иерархий, представляемых в OLAP-кубе... (о чем, собственно, шла речь в ультра-лаконичной цитате).
При "маппинге" входящих фактов работает немного другой механизм, а именно т.н. "очистка данных":

все входящие факты (от любого источника) с их собственными ключами валятся в т.н. "карантинную" базу, откуда в факты OLAP-куба "нормально" попадают только те, у которых уже явно прописаны соответствия (mappings) с объектами из dimensions, остальные "неудачники" (которым еще не назначили соответствия) попадают в факты OLAP-куба в виде ссылки на специальный уровень "супер-иерархии" со значением "не определено";

ну и, периодически, когда пользователей начинает сильно напрягать количество данных в разделе "не определено" - производится "доопределение" нужных соответствий...

З.Ы. естественно, что "ручное управление" подобного рода схемами с помощью прямых SQL-запросов - занятие слишком "муторное" для свободного полета мысли нормального программиста, поэтому наиболее рутинные операции (вроде поиска соответствий по наименованиям) были почетно возложены на DTS (SSIS), а для настоящего "разруливания" был написан специализированный клиент, в котором "девочка из отдела сбыта" могла таскать драг-н-дропом "внешние неопределенные" объекты на "внутренние определенные"...

ГликогенТо, что здесь описано (внешний относительно систем-источников редактор и хранилище иерархий и маппинга кодов СИ на эти иерархии) - лежит в основе тиражных систем MDM .
Дык, жизнь-то всегда приведет всех к одному и тому же месту, хоть и разными тропинками...
Я недавно с большим удивлением у модератора на сайте узнал, что, оказывается, технология (или структура данных) хранения предрасчитанных остатков/оборотов по к.-л. "журналу операций" давно запатентована (sic!) Navision и, в общем случае, не может быть использована в других продуктах без ее на то "доброй воли"...
Вот так-то, а я-то когда придумывал структуру данных для тех же целей в нашей LegacySystem даже и не подозревал о том, что когда-то могу оказаться из-за этого "под статьей"...

З.Ы. для тех, кто не врубился - после многих проб и ошибок, структура данных таки заработала "как надо", но при этом (как выяснилось гораздо позднее) оказалась "точь-в-точь" как у Navision-а... ("А мужики-то и не знают!").