Есть системы, в которых таких проблем в принципе нет. (Посмотрите, например: www.calligraph.ru)
Пользователь сам определяет названия в формируемых документах в терминах его предметной области. Не требуется строить "кубы" - все обработка осуществляется "на лету", за один проход по OLTP-информации. Генерируемый документ не ограничивается ни количеством измерений, ни набором граничных условий для анализа (определяющих, по сути дела, разбивку документа на графы и строки), ни количеством подключаемых функций.
При этом один и тот же документ может быть представлен (по желанию пользователя), любым из (N+1)! теоретически возможных способов, где N - это количество измерений для анализа.
Т.к. "кубы" строить не надо, то это дает массу плюсов: не надо ограничивать количество измерений для анализа - все измерения равноценны, не надо округлять и загрублять данные - работать можно с точностью OLTP-потока, не надо раздувать БД - известно, что каждое измерение "куба" как минимум на порядок увеличивает требования к памяти, мощности сервера, ... и т.д.
Если уж быть точными в терминах, то системы, работающие не с OLTP-данными, (т.е. где требуется какая-либо предварительная обработка, создание "кубов" и пр.), это уже не OLAP (не On Line AP), а "посмертная" обработка.
Еще "на лету" строит документы система Buisnes Object. Вероятно, что есть и еще какие-то, но мне пока не попадались.

Еще есть вопрос, который, на мой взгляд, стоило бы обсудить:
Может быть есть смысл опубликовать на форуме классические требования к OLAP ? (E.F.Codd, 12 правил которого охватывают все прикладные системы многомерного анализа и генерации отчетов. См. “CW-M”, 1993, 38).
Оперируем (говорим), вроде бы, одними словами, а понимаем используемые термины каждый по-своему. Это неправильно.