У меня есть самописный компонент заточенный под ORACLE.
Cube + Grid + Navigator.
Грид по внешнему виду и функционалу напоминает ORACLE EXPRESS'овский.
Работает одновременно с несколькими столбцами.
Отдельная закачка справочников (значений измерений).
Поддерживает экспорт в EXCEL.
Предназначен для малых и средних кубов.
Работает быстро (на несколько порядков быстрее чем DecisionCube),
много памяти не ест (на сколько это возможно).
Требует постоянной связи с сервером, т.к. при смене порядка измерений выполняется новые запросы.

Нормально работает в 2-х проектах.
Хотела сделать еще под MSSQL заточку, но пока руки не дошли.

Simply Guest2Анастасия М.
Ваш куб использует Оракловый OLAP? Или просто генерит многомерный куб на клиенте?
Данный куб может работать в нескольких режимах:
1. Генерация неполного куба на сервере (два пересекающихся дерева измерений и наполнение плоской матрицы значений по всем точкам пересечений значений измерений). Конкретно:
для 9i:
1.1SELECT sum(c1) c1, max(c2) c2, a1, a2, a3, a4
FROM source
GROUP BY ROLLUP(a1, a2), ROLLUP(a3, a4)для 8i (двойной ROLLUP в одном запросе не поддерживается):
1.2SELECT sum(c1) c1, max(c2) c2, a1, a2, a3, a4
FROM (
SELECT sum(c1) c1, max(c2) c2, a1, a2, a3, a4
FROM source
GROUP BY ROLLUP(a3, a4), a1, a2
)
GROUP BY ROLLUP(a1, a2), a3, a4
Результаты запросов 1.1 и 1.2 получаются абсолютно аналогичными, за исключением порядка записей
В запросе 1.2 сложно делать аналитические агрегации.
Так например чтобы сделать COUNT(c3) с3 в 1.2, придется во внутреннем запросе делать COUNT(c3) c3, а во внешнем Sum(c3) c3, иначе получим неверные значения.

2.Для избежания сложностей аналитических запросов под 8i
пришлось реализовать формирование полного куба на сервере.
А для сокращения памяти клиента и сетевого трафика - генерацию соответствующего HAVING, который отбирает только то, что возвращают запросы 1.1 и 1.2.
2.1SELECT sum(c1), max(c2), count(1) c3
FROM Base_source
GROUP BY CUBE(a1, a2, a3, a4)
HAVING (не помню по памяти, но все логично вычисляется)
Но тогда придется все равно считать куб каждый раз.
Для избежания этого компонент может работать с таблицей(витриной), содержащей полный куб аля
CREATE TABLE source AS
SELECT sum(c1), max(c2), count(1) c3
FROM Base_source
GROUP BY CUBE(a1, a2, a3, a4);
только таблицу лучше делать index based
И отбирать из нее записи необходимы для отображения:
2.2SELECT c1, c2, c3
FROM source
WHERE (аналогично HAVING'у из 2.1)

Как показывает практика наиболее жизнеспособный вариант это 1.1.


Далее компонент разбирает ДатаСет (довольно шустро - алгоритмы проработаны оч. хорошо), строит по нему два массива (дереда) индексов (вертикальный и горизонтальный) и выводит в специальный грид аля ORACLE EXPRESS (по виду и функционалу).
В гриде можно сворачивать и разворачивать деревья (вертикальное и горизонтальное) измерений. Реализован поиск по значениям измерений. Ну и всякий другой вункционал, в т.ч. генерация SQL для отображения всех записей из source на конкретную агригацию (по значениям измерений).
Еще есть Navigator (как в DecisionCube? только более навернутый и редакотором фильтров).

ЗЫ. Весь SQL генерится автоматом надо только в дизайнтайме настроить измерения и агрегации. Можно и в рантайме, считывая из метаданных.

Вот такие пироги.

А с оракловыми кубами компонент не работает
Все начиналось еще под 8i, в котором кубов не было.

Забыла написать:
в приведенных примерах
c1, c2, c3 - агрегации;
a1, a2 - измерения отображающиеся по горизонтали;
а3, а4 - измерения отображающиеся по вертикали.

Анастасия М.
2.2SELECT c1, c2, c3
FROM source
WHERE (аналогично HAVING'у из 2.1)

Читать как 2.2SELECT c1, c2, c3, a1, a2, a3, a4
FROM source
WHERE (аналогично HAVING'у из 2.1)