Добрый день,

Интересно читать дискуссии о сравнении аналитических программных продуктов, в которых принимают участие знатоки этих продуктов.

Подобные дискуссии имели место и на форуме сайта www.olap.ru (Cognos vs BusinessObjects, MS AS vs Oracle Express и т.п.)

С моей точки зрения, существует 2 основных типа аналитических продуктов класса OLAP/BI: MOLAP- и ROLAP- продукты.

MS AS, а также Oracle Express, Hyperion Essbase, Cognos PowerPlay - относятся к классу MOLAP. В свою очередь, Microstrategy, BusinessObjects, Oracle Discoverer, Brio, Actuate, Cognos Impromptu - это ROLAP-продукты. У каждого из этих продуктов есть что-то (некоторая функциональность), чего нет ни у кого другого. Вопрос только в том, насколько ценна такая функциональность.

Очевидно, что некоторые задачи нужно решать с помщью MOLAP (многомерный интерактивный анализ со временем отклика 1-5 секунд, консолидация данных из нескольких источников, построение отчетов, в которых присутствуют агрегированные показатели, и которые сложно вычислить с помощью обычного SQL). Для других задач необходим ROLAP (построение несложных отчетов с ON-line доступом к РСУБД, построение отчетов, в которых форма важнее содержания, а скорость генерации не критична, построение отчетов, которые неудобно строить с помощью MOLAP-продуктов и т.п.).

MOLAP-продукты обычно характеризуются отсутствием серьезных визуальных средств для создания запросов к РСУБД и для проектирования структуры кубов. В случае использования MS AS нужно сздавать вручную вьюшки с помощью SQL, а структуру куба с помощью MDX. ROLAP-продукты, напротив, имеют хорошие визуальные средсва, но не умеют создавать многомерные кубы.

Таким образом, я бы провел параллель с типичной жизненной ситуацией, когда молодой человек думает, с какой девушкой познакомиться: с умной, но не очень красивой, или с красивой, но не наделенной высоким интеллектом :)

В большинстве компаний есть потребность и в MOLAP, и в ROLAP. И соответственно взникает вопрос - покупать ли MS AS для целей MOLAP, и одновременно Microstrategy для целей ROLAP? Такой вариант конечно имеет право на существование, но вряд ли является оптимальным, поскольку лучше покупать все у одного производителя. Если провести небольшое исследование рынка, то становится очевидным, что лишь 2 компании поставляют одновременно и MOLAP, и ROLAP: это Cognos (PowerPlay + Impromptu) и Oracle (Oracle Express + Oracle Discoverer). Причем интеграция, когда с помощью ROLAP создаются SQL-запросы визуальными средствами к источникам данных, а MOLAP использует эти запросы, имеет место лишь у Cognos.

Возможно я незаслуженно не уделил внимания какой-либо другой компании, которая поставляет MOLAP + ROLAP в интегрированном виде. Знаком ли кто-либо из посетителей этого форума с инструментарием, аналогичным инструментарию Cognos (или хотя бы Oracle)? Было бы интересно получить такую информацию, поскольку в форуме www.olap.ru этот вопрос задавался много месяцев назад, но никто на него так и не ответил...


С уважением,
Юрий
Cognos@narod.ru

Добрый день,

Полагаю, что профессионалы в области OLAP/BI, знакомые не с единственным, а хотя бы с несколькими известными аналитическими продуктами, поняли, что я имел в виду...

Однако, поскольку здесь на форуме сообщения читают и люди пожилого возраста, и школьники :) , я дам дополнительные комментарии.

Я безусловно НЕ ИМЕЛ В ВИДУ, что MS AS обладает такой узкой функциональностью и хранит данные только в многомерном виде.

Под термином MOLAP я в своем сообщении имел в виду те программные продукты, которые умеют строить многомерные кубы (не многомерный кэш на клиенте, который создается налету, а именно серьезные кубы, которые могут неплохо масштабироваться), и этих продуктов не так много. Если Вам не нравится термин MOLAP в этом контексте - пусть это будут "Решения с кубами", или OLAP-сервера.

Под термином ROLAP я имел в виду те продукты, которые кубов не создают, а делают отчеты лишь на основе SQL-запросов, и таких продуктов очень много. Вместо ROLAP можно назвать это "Решениями без кубов", или продуктами класса Query & Reporting.

О клиентском интерфейсе я вообще не упоминал, это не самое важное, во всех продуктах есть либо свой интерфейс, либо клиентские приложения других разработчиков.

Под визуальными средствами я имел в виду следующее:

1) Создание запросов к источникам данных: Возможность мышкой выбрать нужные таблицы из источников данных, создать сложные связи между таблицами, наложить фильтры, создать вычисляемые поля - чтобы это делалось без необходимости писать SQL вручную.
Кто-то скажет, что MS Access или редактор кубов MS AS все это делает, но там нельзя создавать СЛОЖНЫЕ связи, а конструктор выражений (для создания фильтров и вычисляемых колонок) скорее напоминает текстовый редактор, с помощью которого тяжело наваять что-то содержательное.

2) Проектирование структуры куба: согласен, если в таблице фактов и в таблицах измерений имеются все необходимые поля, то в MS AS куб проектируется визуальными средствами. Однако, в жизни все обстит несколько сложнее, и чтобы построить сдержателный куб, зачастую нужно использовать несколько таблиц фактов, создавать вычисляемые измерения, показатели, категории и т.п. Под наличием визуальных средств я понимаю возможность делать это без необходимости программирования/создания MDX-выражений в текстовом редакторе.

Тот факт, что Microsoft не делает ничего подобного Интеллектуальному Конструктору Выражений Cognos, видимо говорит о том, что Microsoft позиционирует себя на рынке OLAP как поставщик инструментальных средств, а не законченных аналитических продуктов. Или может это бъясняется тем, что команда разработчиков MS AS - это гениальные математики/программисты, считающие, что пользователи, разбирающиеся в бизнес-процессах, без участия которых процесс проектирования многомерных кубов немыслим, также хороши в роли профессиональных программистов (или профессиональные программисты всегда обладают превосходным знанием предметной области).

А что касается этого форума - то он действительно намного круче, чем на www.olap.ru . Жаль правда, что это приведет к тому, что те, кому интересна тема OLAP, наткнутся лишь на запущенный форум на том сайте, а сюда дорогу не найдут.

Добрый день,

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

Руководитель/аналитик и любое другое лицо, принимающее решения, обычно находятся в постоянном творческом поиске, и им тяжело сформулировать все свои потребности. Нельзя просто провести обследование, перечислить все аналитические пожелания, сделать нужные кубы/отчеты и повесить все это на шедулер, чтобы вечно работало. Нужно иметь возможность легко и быстро дорабатывать аналитические модели. И очевидно, что когда модель представляет из себя набор объектов и не содержит скриптов, в ней легче делать изменения и доработки.

Идеальный вариант - это когда не только программист, но и аналитик/опытный пользователь проходят обучение по работе с OLAP-продуктом на продвинутом уровне, на уровне администратора. Далее программист решает вопросы с подключением к источникам данных, создает/поддерживает семантический слой, переводя названия таблиц и полей в бизнес-термины пользователей, ограничивает права пользователей, чтобы они не делали "бесполезных" запросов к БД, пишет дополнительные функции для СУБД (UDF), если функций OLAP-продукта недостаточно и т.п. Аналитик же должен уметь создавать связи между таблицами, ваять SQL-запросы/делать выборки из БД визуальными средствами. Только так, видя данные перед глазами, он сможет прочувствовать, какие есть возможности для создания производных/вычисляемых аналитических разрезов (факторов) и показателей (целевых функций) на основе имеющихся данных, или какую аналитику нужно вести (какие данные дополнительно собирать) и вносить в учетную систему. Если аналитик увидит, что к имеющимся данным нужно добавить данные из другого источника (например, планы продаж, внешний классификатор, цены конкурентов из файлов Excel), то хорошо, если у него будет возможность сделать это сразу несколькими кликами мышки, а не писать ТЗ для программиста, который перепроектирует OLTP-систему/ХД, с помощью ETL-средств закачает туда эти внешние данные, напишет на MDX алгоритмы консолидации и т.п.

Аналитик должен общаться с руководителями, настраивать для них многомерные отчеты/кубы.

Вообще говоря, я не согласен с тем, что Вы понимаете под "законченным аналитическим продуктом". Продолжая Вашу аналогию, можно, например, сказать, что ни один из реляционных серверов баз данных не является "законченным". Ну как же - ведь ни для SQL Server, ни для Oracle, ни для DB2, ни для Sybase и т.д. до сих пор не создано универсального клиента. Смешно, правда?

Совершенству нет границ... Однако, не забывайте про принцип "80 на 20". Если аналитический продукт имеет пункты меню/опции/визарды для решения большинства классических типов задач (количество которых не так уж велико), то его можно называть вполне законченым. В противном случае можно докатиться до идеи, что самый лучший OLAP-продукт - это клавиатура, с помощью которой можно создать в машинных кодах универсальный exe-файл, запустить его и решить все аналитические задачи :)

Вы говорите: "Возможность мышкой выбрать нужные таблицы из источников данных, создать сложные связи между таблицами, наложить фильтры, создать вычисляемые поля - чтобы это делалось без необходимости писать SQL вручную". Это кто будет делать? Это аналитик будет делать? Или, может быть, руководитель? Да они понятия не имеют о том, где в какой табличке что лежит.

Руководитель этого делать не должен. На мой взгляд, в ходе внедрения аналитических продуктов профессионал/руководитель проекта должен добиться того, чтобы аналитик, как опытный пользователь (но не являющийся профессиональным программистом), научился работать с семантическим слоем (который будет создан в процессе внедрения), чтобы в будущем уметь развивать/усложнять аналитическую систему.

Я думаю, что Вы это написали просто не разобравшись в средствах построения вышеперечисленных вещей в MS AS. И слова о сложности создания выражений на языке MDX в MDX Editor Вы неправы. Для создания сложных выражений он удобнее любого визуального конструктора. Правда надо оговориться что человек должен быть подготовленным.

Интересно, сколько времени потребуется, чтобы довести опытного пользователя/аналитика до уровня свободного владения MDX... Наверное столько же, сколько потребуется для превращения профессионального программиста в знатока бизнес-процессов :) За 3 дня такому не научишь...
И даже если человек хорошо знает MDX и будет создавать аналитические модели не визуальными средствами, то это почти то же самое, что наслаждаться просмотром фильмов (AVI-файлов) не в Windows Media Player, а в текстовом редакторе...

И еще. Коли уж Вы сравниваете MS AS и Cognos, говоря что Cognos лучший, и приводя в качестве примера те параметры, которые являются преимуществами ROLAP Query and Reporting систем, то тогда уж возьмите в качестве контрольного образца, например, Business Objects, как типичного представителя Query and Reporting, и в своем сравнении напишите чем Ваш продукт лучше.

Я не говорил, что Cognos во всем лучше, чем MS AS. Сильная сторона Cognos состоит в наличии модулей OLAP/MOLAP + Query & Reporting/ROLAP в одном флаконе. Мне интересно выяснить, объясняется ли популярность MS AS объективными факторами (функциональность, соотношение цена/качество), или раскрученностью имени Microsoft, или может те, кто знаком с MS AS, никогда не видели ничего другого...
Что касается BusinessObjects, то Cognos с ним сравнивался неоднократно на форуме www.olap.ru. Функциональность BO сравнима с функциональностью Microstrategy или с модулем Cognos Impromptu.
Связка MS AS + Business Objects - это интересное решение (MOLAP + Query & Reporting), но хотелось бы, чтобы стоимость такого решения была не так высока, да и степень интеграции этих продуктов оставляет желать лучшего.

To Kvazimoda:

Я знаком с несколькими профи по MS AS, они умеют решать серьезные задачи. Другое дело, что поскольку MS AS - это очень доступный продукт, удельный вес профессионалов к общему количеству пользователей очень мал... Этим частично и объясняется невысокое среднее качество внедрений MS AS (другая причина - что сам продукт еще молодой и довольно сырой, да и разрабатывался он изначально не компанией Microsoft).

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