To Birkhoff:

А если серьезно - постройте кубик например из 30 parent-child измерений, глубиной например по пять уровней и общим числом листьев в районе нескольких сотен. А потом попробуйте его сагрегировать.
Даже если на нижнем уровне будет 1000 записей, для MOLAP сервера это будет очень тяжело. Не знаю выдержит ли MS AS такое? А в Cognos наверное такой эксперимент вообще поставить нельзя.

Спасибо, интересный пример. Я как то делал куб в Cognos PowerPlay с 50 измерениями и 50 показателями, но не все измерения были иерархическими. Тогда я закачал в куб 50 тысяч записей, и проблем с производительностью не наблюдал.
Думаю Ваш пример хорош для проверки качества OLAP-движка. Обязательно потестирую Cognos PowerPlay. Было бы интересно провести такой же эксперимент на MS AS, Oracle Express и Hyperion Essbase - и провести сравнительный анализ (каков получится размер куба, сколько времени он будет процесситься, сколько времени потребуется на проектирование куба).

Кстати, в чем с Вашей точки зрения сложность этого примера для MOLAP - в том, что в кубе будет очень много ячеек?

Всем привет!

Приведу описание примера по созданию куба с 30 измерениями в OLAP-сервере Cognos PowerPlay:

1) Создал в Excel 1 колонку с числами от 10001 до 11000. Далее создал 30 колонок с заголовками "izm01" ... "izm30". Далее заполнил эти колонки значениями типа "member_izm1610388" (для каждой колонки свой набор из 1000 уникальных значений). Итого - 31 колонка. Размер файла XLS - 2.1 Mb.
2) Создал в модуле PowerPlay Transformer модель куба. В источнике данных (таблица фактов) - 31 колонка из Excel + 4 вычисляемые колонки (соответственно 1, 2, 3 и 4 первых символа от первой пятисимвольной колонки). Эти 4 колонки я использовал как 4 уровня измерения для каждого из 30 измерений. 5-й, нижний уровень брался из следующих 30 колонок. Показателем сделал первую колонку.
3) Сгенерировал куб. Время генерации - 49 секунд. Размер куба - 10 Mb (в сжатом виде - 1.3 Mb). Количество категорий (members) - примерно 35 тысяч (в каждом из 30 измерений по 1000 листьев + узлы иерархии).
4) При тестировании работы куба в OLAP-клиенте PowerPlay User замедления не наблюдалось, даже когда делал глубокую вложенность (10 уровней в боковике и 3 уровня в шапке) и накладывал фильтры по другим измерениям.

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

Как думаете, интересен ли такой эксперимент? Хочет ли кто-нибудь его повторить на своем инструментарии? Если будут желающие - могу выложить на сайт http://cognos.narod.ru исходный XLS-файл для скачивания.

To Birkhoff:

Исходные данные можно скачать с http://cognos.narod.ru/Xls30izm.zip .
В модели куба у меня именно 30 измерений, в каждом из которых по 5 уровней иерархии.
По-хорошему, нужно было сделать в Excel для 30 измерений не 30, а 150 колонок, но это потребует долгой рутинной работы. Если есть на форуме волонтеры - сделайте для каждой из 30 колонок еще 4 колонки: в первой будет взят первый символ из пяти правых крайних, во второй - два первых символа из пяти правых крайних, и т.д. (три первых и четыре первых символа). Это и будут колонки для формирования уровней иерархии с первого по четвертый (искуственная классификация).
Я пошел по альтернативному пути. Создал в модели куба 4 вычисляемые колонки с помощью формулы Substring (izm01, 13, N), где N - это число от 1 до 4 (то есть были вычислены подстроки от строки из колонки izm01, начиная с 13 символа, длиной N символов. Поскольку крайние правые 5 символов у всех 30 колонок для каждой строки одинаковы, я перетащил эти 4 вычисляемые колонки друг под друга в каждое из 30 измерений. А пятый нижний уровень для первого измерения взял из колонки izm1, для второго измерения - из колонки izm2, ..., для тридцатого измерения - из колонки izm30.

Понятно ли мое объяснение?

To DimaR:

Разясните новичку, предыдущий пример, а то я ничего не пойму.

Вы не понимаете, почему куб получился довольно небольшим при таком большом количестве измерений?

Возьмем без иерархий
1000^30=1.e+90 значений

Пока все правильно, Вы вычислили число ячеек куба.

Возьмем теперь какой либо процент заполнения куба , пусть даже милионные доли процента,
Всетаки я могу представить порядок цифр и объем данных, а с иерархиями (тем более несбалансироваными) еще сложнее.

А вот здесь Вы ошибаетесь. Почему Вы думаете, что процент заполнения куба - миллионные доли процента? Ведь закачали то мы всего 1000 записей, в кубе заполнено всего 1000 ячеек, ну и в каком-то количестве ячеек созданы агрегаты (у каждого OLAP-сервера свой метод создания агрегатов). Не исключено, что реальный процент заполнения куба - не 1.e-8, а 1.е-85.

Как показывает этот пример, OLAP-движок Cognos имеет высокое качество и не подвержен проблеме лавинообразного роста размера куба.

To DimaR:

На кой черт мне OLAP сервер для анализа 1000 записей?

Вы прочитайте эту дискуссию :) В ходе нее возник вопрос, как можно умертвить MOLAP. Поступило предложение - сделать куб с 30 измерениями и закачать в него всего 1000 записей. Это было сделано с помощью Cognos PowerPlay и теперь все знают, что MOLAP - это не такая слабая штука. Теперь правда надо проверить, все-ли MOLAP-продукты могут решать такие задачи...

Как правило реальный объемы совсем другие, то что я пробовал на Express
по 2 измерениям
Иерархия Год-Месяц-День 365 дней
Иерархия Товары (несбалансированая по группам товаров от 1 до 7 уровней в ветке) 40000 товаров 400 груп (все в иерархии).

Ну правильно, раз Вы работаете с Express - то Вы знаете его слабые стороны и стараетесь избегать ситуаций, когда в кубе более 5 измерений. А теперь представьте, что аналитик поработал с Вашим кубом, увидел, что по какому-то товару прибыль маленькая, отфильтровал 1000 фактов продаж конкретно этого товара и решил провести исследование, какие факторы влияют на прибыльность по данному товару. Аналитик определился с потенциальными факторами (их предположим примерно 30 :) , подключил к таблице фактов эти несколько десятков классификаторов и захотел повертеть в кубе этот маленький, но широкий массив данных - вот мы и пришли к нашему примеру :)

Я думаю у Expreess, и у 9i ROLAP, и у Discoverer на 30 иерархиях на 1000 записей тоже не возникнет никаких проблем

Вот и сделайте доброе дело - проведите тесты на основе выложенных мною для скачивания данных ( http://cognos.narod.ru/Xls30izm.zip ), опубликуйте их результаты. В первую очередь посетителей форума интересует MOLAP-продукт Express (в нем более удобно проводить многомерный анализ с Drill-down/up по иерархиям). Лично мне очень интересно узнать, какой размер будет у куба, сколько по времени он будет процесситься, сможете ли Вы в течение 20-30 минут спроектировать куб, или у Вас уйдет больше времени, и т.п.

To Birkhoff:

уровневая иерархия она и есть уровневая - алгоритм обсчета агрегатов очень прозрачный. Собственно и ROLAPа хватит.

Я думаю на выбор между MOLAP и ROLAP влияет не только наличие или отсутствие несбалансированной иерархии, но и масса других факторов, которые довольно часто обсуждаются на OLAP-форумах...

Интересно, сможет ли кто-то это сделать именнно на 30 несбалансированных иерархиях?

Давайте уточним, что такое несбалансированная иерархия. Например:

Id, Name, Parent_Id
1, Товары, 0
2, Услуги, 0
11, Товары продовольственные, 1
12, Товары непродовольственные, 1
111, Пиво, 11
112, Водка, 11

Эта иерархия является несбалансированной?

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

Колонка1, Колонка2, Колонка3, Колонка4
Группа1, Подгруппа11, NULL, Товар15
Группа1, Подгруппа12, Подгруппа121, Товар17
Группа2, NULL, NULL, Товар24

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

Если бы у меня было лишнее свободное время - я мог бы сделать и такой пример, но уж очень муторно генерить 30 иерархических несбалансированных категорий.
Может у кого-нибудь исходные данные уже подготовлены?