To NOpasaran:

Компанию открыто я озвучить не имею права, хотя она упоминалась на нашем форуме. Насчет связки тоже не знаю, но это не принципиально - ОЛАП и репортинг - это разные вещи, хотя я часто делаю репортинг с помощью ОЛАП-клиента...

To Сергей:

Я остро не реагировал. У меня пока руки не дошли внимательно прочитать этот отчет...

To НЕТ РЕКЛАМЕ:

Jurii - придумает он мастер передергивать великий шулер :))

В карты я играю исключительно как любитель :)

Что касается зоопарков, то хочется у Вас спросить, давно ли Вы проходили тест на определение коэффициента Вашего интеллекта? думаю понятно что я имею в виду (СУБД и BI - это разные вещи, а BI от двух разных производителей - это зоопарк).

Что касается простоты внедрения Cognos - то для меня это просто. Эксперту Birkhoff внедрять Oracle 10G сложнее, несмотря на то что он тоже эксперт в своей области...

To Jimmy:

Настоящие специалисты уровня Birkhoff или Иванова рекомендуют использование Jurii в ваших проектах
Умные интеллектуальные люди найдут в моих сообщениях немало полезной информации (с) Jurii
Очевидная польза ... для Jurii

И не стыдно Вам писать такие рекламные постинги, восхваляя свои аналитичиские способности?

To DmitryS:

Отсутствие Parent-Child измерений.

Этот вопрос в свое время обсуждался. У Cognos и MS AS есть свои плюсы и минусы. Если в иерархии мало листьев (например товаров), и она лежит только в трех, а например не в четырех полях, то в MS AS с ней работать легче. Если же листьев в дереве много - десятки или сотни тысяч, то у Cognos будет большое преимущество по производительности (в то время как MS AS будет подтормаживать). Также Cognos выигрывает, если иерархия хранится не в трех полях, а более хитро (проявится наличие интеллектуального конструктора выражений).

Отсутствие разделяемых измерений

У Cognos виртуальные вьюшки Impromptu по большому счету являются разделяемыми измерениями. Одну и ту же виртуальную вьюшку можно одновременно использовать в разных моделях разных кубов.

Отсутствие документации по VB в PP по сравнению с MDX MS AS

Это как - полная документация есть, причем с примерами... Входит в стандартную поставку.

у MS AS есьма высокая скорость внедрения

Высокая - это сколько дней? И входит ли в срок внедрения обязательное создание хранилища данных, если например данные исходные лежат в сложной структуре?

To Злобный ныпэрс:

YESSSSS !!!!
Это самый обсуждаемый топик !!!!

Ну все, теперь нам положена золотая олимпийская медаль :) И Cognos наконец то стал самым популярным OLAP-продуктом в России

To Андрей Прохоров:

Можете привести примеры задач, которые можно реализовать в Cognos и невозможно в MicroStrategy?

Очевидные примеры - это невозможность в MSTR проводить интерактивный многомерный анализ с высокой скоростью отклика, если объемы данных - приличные (миллионы записей и более). Как-то г-н Лисянский приводил пример, что среднее время отклика в одном из известных проектов MSTR измеряется не привычными для MOLAP долями секундами, а минутами.
Менее очевидные примеры - консолизация данных из разных источников, имеющих разную гранулярность, поддержка Time State Rollup (когда остаток для января берется из 31 января, а остаток для 2 квартала - из 30 июня). У MSTR решения всегда жестко централизованные (большую реляционную БД на ноутбуке не покрутишь, в то время как OLAP-кубы на основе больших БД на ноутбуке летают). Также я не уверен, что MSTR сильно в работе с несбалансированными иерархиями (справочник товаров, орг. структура). Хотя я могу в чем-то ошибаться...

No Pasaran:

Jurii, Вы не сможете привести пример таких компаний, так как их не существует в природе. Разве что пиратское использование MicroStrategy %)))).

По правде говоря, я имел в виду компанию Данон, но перечитав постинг где она упоминается я понял, что невнимательно тогда его прочитал, а другой постинг найти не могу... Г-н Лисянский говорил следующее:
"Я слышал, что в Даноне связка Microstrategy на MS." (см. /topic/85073&pg=-1 ). И почему-то я перепутал MS с MS AS :)
Но я не очень понимаю, почему не может быть компаний, где закуплены и MS AS, и MSTR? Или пользователям MSTR по каким-то причинам запрешено использовать MS AS?
Я еще могу понять, что партнерам Cognos запрещено продвигать BusinessObjects, но любая мало-мальски крупная компания всегда имеет зоопарк аналитических продуктов.

Ну а насчет того что я не знаю, что такое MSTR - Вы заблуждаетесь.

To Андрей Прохоров:

Очевидные примеры - это невозможность в MSTR проводить интерактивный многомерный анализ с высокой скоростью отклика, если объемы данных - приличные (миллионы записей и более).
Вы хотите сказать, что count метрики с переменным уровнем гранулярности будут летать в Cognos на миллионах записей за доли секунды?

Я хочу сказать, что в MOLAP-кубе Cognos заранее просчитаны агрегаты, и визуализировать их в отчете в ходе интерактивного анализа - это доли секунды, в то время как выполнить SQL-запрос с агрегированием на основе миллионов записей + с джойнами реляционных таблиц - это по-определению не быстро... А делать таблицы с агрегатами в реляционном ХД, чтобы MSTR их использовало - это малореально (слишком много будет таблиц).

Менее очевидные примеры - консолизация данных из разных источников, имеющих разную гранулярность
Схема с фактами различной гранулярности является типичной для MicroStrategy

То есть Вы хотите сказать, что MSTR легко с помощью SQL-запроса объединит детальные данные до дня и товара с агрегированными данными до месяца и до группы товаров, и еще при условии что это 2 разных источника данных (например Oracle и Excel)?

Неадитивные метрики, когда значение берется на конец периода является стандартной функциональностью MicroStrategy.

Это радует :) Вот только хотел бы уточнить - генерирует ли MSTR по дате иерархию времени Год-Квартал-Месяц-Неделя-День?

Вы же сами ставили в вину BO, что это desktop OLAP, а теперь представляете это конкурентным преимуществом Cognos.

Вряд ли контекст моего постинга про BO был именно таким. Я имел в виду, что BO умеет генерить микрокубы на клиентской машине, и это не является полноценной OLAP-серверной архитектурой.
У Cognos кубы могут крутиться либо в режиме клиент-сервер или через Web, либо в режиме файл-сервер (в т.ч. на клиентской машине). То есть возможно как решение с жесткой централизацией, так и децентрализованное решение.

Вот здесь согласен, с несбалансированными иерархиями приходится возится, хотя и эта задача решается.

Эксперты по BO говорят, что этот продукт не заточен на многомерный анализ. Думаю MSTR тоже не заточен на работу с кубами.

To Dartov:

Юрий, в MSTR есть возможность проводить анализ с высокой скоростью отклика, но, конечно не всего хранилища а только некоторого подмножества данных. Функциональность называется Intelligent Cube.

Правильно ли я понимаю, что это аналог микрокубов BO? то есть в Intelligent Cube нельзя закачать 10 миллионов записей и потом подкачать еще 5 миллионов инкрементально?

То есть большую реляционную БД не покрутишь, а кубы с ТЕМИ ЖЕ данными летают? Чит? :)
Если нет то прошу Вашего совета как эксперта. У меня есть хранилище в реляционной БД - 120Гб. Какой ноутбук Вы посоветуете для демонстрации? :-)

Каждый запрос к большой реляционной БД - это много вычислительных операций, проведение джойнов и т.п., то есть - большая работа для мощного компьютера (сервера). А процесс генерации OLAP-куба - это то же самое что спроектировать миллионы таблиц с агрегатами. Выполняется этот процесс на любом по мощности компьютере. Когда куб готов - его можно крутить на слабом компьютере, поскольку каждый запрос к кубу - это малое количество легких операций.
Что касается Вашей базы на 120Гб - то это ни о чем не говорит. Отжирается место вспомогательными полями, индексами и пустотами, а реальных данных - меньше. Приведите следующую информацию - сколько у Вас записей в таблице-таблицах фактов, сколько элементов в основных справочниках, сколько примерно показателей. И на основании этой информации я оценю, превысит ли размер куба 1 гигабайт или нет :)

To Андрей Прохоров:

Если речь идет об анализе, а не простом (пусть и ad hoc) репортинге, то агрегирование всего и вся не панацея

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

повторяю свой вопрос:
"Вы хотите сказать, что count метрики с переменным уровнем гранулярности будут летать в Cognos на миллионах записей за доли секунды?"

Я не уверен, что понимаю Ваш вопрос на 100% правильно. Я имею в виду, что метрики на основе агрегирования по сумме, среднему/средневзвешенному, минимум/максимум будут летать за доли секунды. И именно такие метрики составляют львиную долю от общего числа метрик, которые анализируются пользователями. Причем пользователи любят не только их получать, но и проводить производные вычисления на их основе в интерфейсе OLAP-клиента. Что касается дистинкт каунт - многое зависит от количества листьев, которые надо посчитать. Если листьев не много (дни продаж, кассы, кассиры и т.п.) - все летает за доли секунды. Если считаем клиентов, которых десятки-сотни тысяч - требуется "разогреть кэш" - первые запросы могут выполняться в течение секунд-десятков секунд, а то и минут.

Не нужно путать агрегирование и представление фактических данных на разных уровнях

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

Oracle и Excell? Забавно, Вы в можете пол куба в Hyperion положить, пол куба в Cognos и при этом милисекунды выжимать?

Я не говорю про ситуацию, когда в момент генерации отчета данные из разных источников джойнятся налету. Я имею в виду, что данные из Oracle и Excel - это 2 таблицы фактов для одного куба, джойнятся/агрегируются/объединяются они в процесе генерации/обновления куба.

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

Я исхожу из того, что MSTR - это аналог BusinessObjects. Я знаю, что BO не имеет стандартных средств для Time State Rollup.

Что касается иерархии времени, то она не является особой в MicroStrategy. Поэтому иерерахия времени может быть практически произвольной структуры.

Почему-то разработчики OLAP-серверов рассматривают иерархию времени отдельно. У нее есть своя специфика. Возможно Вы не сталкивались с этой спецификой на практике...

С проектом MicroStrategy также можно работать в режиме файл-сервер

Работать то можно, но как без мощного сервера будет происходить работа с большими объемами данных, не будет ли тормозов - ведь скорость выполнения SQL-запросов зависит от мощности сервера.

Однако так и не понял считаете ли Вы Desktop OLAP важным конкурентным преимуществом

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

Так Вы знаете или думаете? Есть некоторая разница между этими двумя состояниями.

:) Я высказал предположение, что MSTR и BO - это реально одно и то же. Если это утверждение никто не опровергнет - я буду ЗНАТЬ, а пока я ДУМАЮ :)

А здесь где предположение, а где знание?
Можно все-таки названия компаний привести, а то все заждались уже?

Я привел пример Данона, и прокомментировал, что перепутал MS с MS AS. Так что строго говоря в настоящее время я привести пример таких компаний не могу.

To Dartov:

Повторяю свой вопрос:
"Но я не очень понимаю, почему не может быть компаний, где закуплены и MS AS, и MSTR? Или пользователям MSTR по каким-то причинам запрешено использовать MS AS?"
Неужели MSTR в России реально используется только в одной компании - в Даноне, и поэтому Вы знаете, что пользователи MSTR не используют MS AS? :)
Или при установке MSTR происходит падение сервера MS AS?

В Intelligent Cube можно закачать данных столько сколько позволяет серверная машина. Инкрементально можно погружать в хранилище, причём одновременно с работой кубов

Так куда все-же грузятся данные - в реляционное хранилище или в Intelligent Cube? Вы же понимаете, что миллиарды записей можно заинсертить в ХД даже на слабом компьютере, но вот любой аналитический запрос к ним потребует очень много ресурсов...

To Читатель2 и backfire:

А модератору пора переснести весь топик в Просто-треп .
Или топик переименовать в OLAP.Recycler

Эта дискуссия не является оффтопной. Ее просто надо переименовать в "Сравнение аналитических продуктов".

To All:

Предлагаю открыть новую дискуссию MSTR и Эксперты по MSTR - мнение участников форума :)

Владимир,

Оба варианта мне не симпатичны.

Мне эти 2 варианта тоже не симпатичны.
Реально имеет место вариант 3:

У нас не жесткий график рабочего дня. Важно отработать не менее 8 часов.
Поэтому когда я пишу в форум, я трачу время, и соответственно попозже задерживаюсь на работе. Написание мною постингов не входит в мою должностную инструкцию. Инженером я также не являюсь :)
Кстати написание постингов в форум - это полезная деятельность, типа перекура, позволяет немного расслабиться от напряженной работы :)