2 Kaniovski:

Я ознакомился с Cognos несколько дней назад, спасибо Юрию
После беседы с Юрием его специалистами

Интересно, с каким же Юрием Вы общались? :) Тут какое-то недоразумение, я с Вами не общался... Я лишь получил от Вас письмо на адрес cognos@narod.ru , ответил, но ответа от Вас не получал... Так что видимо Юриев, которые занимаются Когносом, в России несколько...

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

Чем дальше, тем смешнее.
Во всем "стандарте" утверждения "is our key requirement" и "system must provide" относятся только к поддержке иерархий. В результате фривольной трактовки Вы свели "стандарт" к туманному требованию поддержки многмерного взгляда на данные.

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

2 MSTR_Fan:

методологию Active Data Warehouse от Teradata - создание хранилища, пополняемого near real-time одновременно из множества источников данных и используемого для выполнения большого (соизмеримого с числом транзакций в оперативной системе) количества сложных тактических запросов. Как в таком случае использовать Cognos?

А вот в этом нет ничего сложного, у меня в практике были подобные проекты. Cognos позволяет иметь для одного OLAP-куба множество источников данных (таблиц фактов/измерений), обновление (в частности - инкрементальное обновление) куба можно запускать очень часто либо по триггеру СУБД, и при этом можно обеспечить, чтобы куб во время обновления был доступен 24 часа в сутки, 7 дней в неделю. Но все это я не называю многопоточным пополнением куба, есть только один процесс (который можно распараллелить по процессорам), обрабатывающий множество источников данных.

Jurii, Вы сами себе противоречите - выдвигаете такие высокие требования к системе (а ТЕСТ FASMI - это высокие требования IMHO) и предлагаете для этого самый кондовый MOLAP

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

Даже сам Cognos отвечая новым потребностям делает ставку на ROLAP решение - пора бы и Вам квалификацию повысить

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

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

В свое время на форуме была дискуссия на тему поддержки SCD в Cognos. Не хочется повторяться. Пример со структурой 1С может не самый удачный если есть задача поддержки SCD, хотя 1С 8 вроде как приблизилась к этому, там есть элементы темпоральности (как в ERP-системах).
Еще раз повторюсь, что я сам руковожу проектами по созданию ХД с поддержкой SCD, поверх которых ставлю Cognos, но хранилища не всегда нужны...

2 Виктор Сакович:

Ну это Вы просто на основы DWH замахнулись, если для Вас база 1С - это прототип хранилища. Может быть, Вы всё-таки классиков почитаете, Инмона, Кимбалла

Когда-то не было MOLAP, и все обходились простыми реляционными запросами, создавались хранилища. Но когда появился MOLAP (который можно назвать многомерным хранилищем данных), понятия о необходимости ХД изменились... Постарайтесь расширить свой кругозор, не замыкайтесь на MSTR, которая без оптимизированного ХД не умеет работать. Есть еще и другие системы, тот же Cognos.

2 Kaniovski:

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

Это неправда, Вас злостно обманули. Cognos автоматом делает DrillThrough через тот запрос, который соответствует таблице фактов.

Вообщем если есть средства, то в принципе посмотреть в сторону Cognos стоит

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

Но ведь невсегда есть необходимость иметь всю функциональность которую предоставляет эта система. Есть множество примеров когда от такого рода системы требуется быть только клиентом к уже существующему OLAP серверу. Так что нужно десять раз подумать...

Не понял вопроса... Многие компании имеют свои OLAP-сервера (Microsoft AS, Oracle Express, Hyperion Essbase, SAP BW) и используют ограниченную функциональность Cognos (функциональность OLAP-клиента).

Какая разница будет куб занимать 700Мб или 400Мб, сейчас могу поспорить что люди которые покупают такие решения не стеснены объемами жестких дисков на серверах

Ну как сказать... Если взять малый бизнес, или некоторые бедные гос. структуры, у которых денег совсем мало, то они 1-2 тыс. долларов на Cognos наскребут, а железо новое закупать не захотят.

2 Bormoglot:

А если речь не о мегабайтах, а о сотнях гигабайт реаляционного ХД, тогда Юрина программка просто находка: любой отчет на любом объеме за пять секунд

Да, Вы правы, хотя те у кого хранилища размером сотни гигабайт это поняли давно и давно используют Cognos для получения среднего отклика не более 5 секунд.

Или может, таким образом Jurii заранее отвергает плачевные для его системы и авторитета результаты тестирования Kaniovski???
Тогда мы еще с большим нетерпением ждем результатов тестов Kaniovski....

Было бы что отвергать Видно же что г-н Kaniovski введен в заблуждение каким-то новичком, который незаконно использует мое имя :) Ну ладно, это излечимо, я в меру своих сил помогу г-ну Kaniovski докопаться до истины.

2 MSTR_Fan:

Cognos позволяет иметь для одного OLAP-куба множество источников данных (таблиц фактов/измерений), обновление (в частности - инкрементальное обновление) куба можно запускать очень часто либо по триггеру СУБД, и при этом можно обеспечить, чтобы куб во время обновления был доступен 24 часа в сутки, 7 дней в неделю
А вот это очень интересно, а можно о механике процесса подробнее? Как обеспечивается одновременное чтение-запись? Блокировки, версионнность, что-то ещё?

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

Я запутался. Скажите, если я пользуюсь OLAP продуктом, нужно ли мне строить хранилище?

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

2 настоящий Guestz:

Если не ошибаюсь от объема куба зависит объем занимаемой при работе с ним оперативной памяти-а это уже может быть критично... Если ошибаюсь, прошу Юрия меня поправить...

Поправляю. Объем (размер) куба не связан с размером оперативной памяти. Например если куб имеет размер 1 гигабайт, с ним легко можно работать на компьютере с оперативкой 256 мегабайт. А если использовать технологию тонкого клиента, то можно вообще не задумываться над вопросом оперативной памяти.

если есть лишняя пара тысяч долларов, уже можно внедрить аналитическую систему Cognos на основе лицензионного ПО (а если средств больше - тем круче получится система, тем больше можно подключить к ней пользователей).
???

Если у предприятия есть пара тысяч долларов, то этого бюджета хватит чтобы купить лицензионное ПО Cognos - OLAP-сервер PowerPlay User (на это нужно меньше чем 2000$), и полезно к этому докупить средство класса Query & Reporting/ROLAP - Impromptu Administrator (PPU + IA стоят подороже чем 2000$, но не на много). Это ПО позволит создавать OLAP-кубы и аналитические отчеты на основе больших объемов данных (десятки-сотни миллионов записей), иметь при этом в среднем 5-секундный отклик в стиле OLAP (по стандарту FASMI), и кроме всего этого делать по расписанию всю стандартную корпоративную отчетность с высоким уровнем форматирования отчетов (с точностью до миллиметра). Вряд ли можно купить что-либо другое от другого производителя, даже за миллион долларов, что по функциональности было бы сильнее чем связка этих базовых модулей Cognos... Хочу отметить, что я не призываю кого-либо это покупать, просто рассказываю о лицензионной политике Cognos. PPU и IA - это модули, которые например не предоставляют ИНТЕРАКТИВНОГО доступа через Web-браузер к своим аналитическим моделям и отчетам. Поэтому зачастую проект начинается с PPU + IA, а потом докупается Web-компонента на столько то рабочих мест, для визуализации того что было сделано с помощью PPU + IA на корпоративном Web-портале.

красиво красиво
учитывая что я не зарегистрированный пользователь такую ситуацию можно было предположить, но надеялся что до такого мы не дойдем...
Господа-ЭТО НЕ МОЕ сообщение!!!

Чтобы таких казусов не возникало, надо регистрироваться. Но думаю что модераторы форума быстро вычислят злоумышленника, прикрывшегося Вашим именем.
А его шутка про сравнение PPU + IA с текстовым редактором выдает его не слишком высокий уровень в области OLAP/BI. Не завидую его клиентам...

2 Ненастоящий Guestz:

Если же вам нужно использовать несколько источников и динамический DrillThrough - ищите настоящий продукт с поддержкой ROLAP и MOLAP.

Вышеупомянутые PPU + IA за примерно 2k$ позволяют делать DrillThrough из куба в любые реляционные источники (например пользователь стоя в кубе по продажам на ячейке может выбрать, либо сделать DrillThrough в ту базу, на основе которой был сделан этот куб, либо сделать DrillThrough в другую БД).