Поскольку соседняя ветка была закрыта, а предпоследнее сообщение в ней было явной дезинформацией, привожу свой комментарий.

2 Гликоген:

Юрий зарапортовался даже по ценам.
У Cognos нельзя строить кубы меньше чем за десятку килогрин.
PPU - голый клиент.
Transformer, который кубы строит - стОит от 7К.

Да уж, как говорится - без комментариев... Я думал что сотрудники компании-партнера Cognos должны разбираться в базовых модулях Cognos...
PPU - это персональный OLAP-сервер, позволяет на любом компьютере создавать OLAP-кубы в модуле Transformer, и при этом в него входят 2 OLAP-клиента (один стандартный виндовый, второй - для работы с кубами с листа Excel) для кубов формата Cognos и для кубов MS AS, Hyperion, SAP BW и т.п.

2 amex:

Вы кажется специализируетесь в области Oracle? Зачем же тогда пишете постинги в дискуссию где обсуждается лицензирование незнакомой Вам системы Cognos?
Я не говорю что обязательно надо начинать с PPU. Когда заказчик не имеет финансовых проблем, он сразу покупает полный комплект серверных лицензий. Но есть другие заказчики, которые хотят создать крутую аналитическую систему практически бесплатно или у кого очень ограниченный бюджет... Вот они и начинают с PPU, а в дальнейшем - докупают серверные компоненты и переводят на них сделанные в PPU кубы.

впаривает пользователям вместе с Jurii не те лицензии - вместо серверных и многопользовательтских = персоналальные и писюшные - такой подход и решение приемлем только для мелких компаний - 1-2 пользователя .

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

Тем более что в этом случае (только PPU) нельзя реализовать многопользовательскую среду и разграничение прав.
Ваше решение Jurii не для SAP и прочих

Разграничение прав - это зачастую не самый принципиальный вопрос. По расписанию например можно не 1 куб сделать, а 5, для каждой группы пользователей отдельно. PPU позволяет решить проблему жесткой централизации аналитического решения, когда есть один сервер, один опытный разработчик куба, и пользователи, которые дают этому разработчику доделать кубы или сделать новые, а он зашивается и не успевает... PPU можно поставить на комп каждому менеджеру-аналитику, и они сами смогут ваять кубы, самые интересные из которых будут выкладываться на центральный сервер для общего доступа.
Что касается пользователей SAP, то они обычно первичку ведут внутри SAP, а отчеты и анализ делают в Cognos PPU (я знаю целый ряд таких компаний :)

2 Гликоген:

Ни разу не столкнулся с такой конфигурацией лицензий, правда :)
По-прежнему утверждаю, что даже дистрибутив PP Windows User не содержит Transformer-а.

Вы просто никогда не делали Custom Setup при инсталляции PPU. Модуль Transformer там по умолчанию не инсталлируется.

Учитывая перетряску прайса для 8, вполне вероятно, что однопользовательской конфигурации теперь вообще нет.

В версии 8 новый Web-функционал, а PPU только сменил название - на Mobile Analysis.

2 amex:

PPU - это полноценный OLAP-сервер,
Jurii у меня снова сложилось впечатление , что вы не знаете ПО COGNOS

В связи с тем, что OLAP-сервер PPU успешно внедрен мною в очень многих компаниях, я позволю себе с Вами не согласиться...

Разграничение прав - это зачастую не самый принципиальный вопрос.
Возможно на кухне и не важный , но к сведению Jurii, в коммерческих компаниях и госорганах - очень даже важный.

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

PPU можно поставить на комп каждому менеджеру-аналитику, и они сами смогут ваять кубы
Ну вот и договорились - каждому Useru по серверу OLAP

У Вас имеются сильные стереотипы... Чем Вам не нравится ситуация, когда менеджеры-аналитики делают сами свои кубы? PPU - это OLAP-сервер, который можно освоить за 1 день, даже не имея глубоких ИТ-навыков.

Чувствуется Вы многого не знаете , тем более как Cognos работает SAP

Да, исходных текстов программ, которые были написаны при создании SAP у меня нет :) Но нужно ли мне это знать? У Cognos есть стандартные источники данных, включая MS AS, SAP BW, и я, зная функциональность PPU, могу ничего и не знать про MS AS и SAP, но при этом я смогу строить нужные отчеты.

2 MSTR_Fan:

То есть, если я правильно понял, куб обновляется так:
1) куб попадает в production и пользователи подключаются

Да, это верно.

2) решили что нужно обновить, делаем копию куба

Хочу отметить, что обновление - это процесс, который обычно происходит по регламенту, по определенному алгоритму. Например если мы захотим обновлять куб раз в 10 минут - мы соответствующим образом настроим планировщик заданий. Либо можно настроить триггеры в СУБД, чтобы они срабатывали при добавлении новых данных или при изменении данных, и после этого запускался бы процесс обновления куба.

3) пока пользователи работают с боевым кубом, обновляем копию

Это так. Обычно это копия куба на конец закрытого периода, к которой подкачиваются все данные из открытого периода (чтобы не было проблем с изменением данных задним числом).

4) направляем всех новых пользователей на новый куб
5) как только все пользователи на новом кубе - удаляем старый

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

Правильно ли я понимаю, что минимальный интервал между обновлениями куба равен времени копирования файла куба (или кубов) на сервере?

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

2 MSTR_Fan:

То есть обновление хотя бы раз в минуту крупного куба, при сохранении доступа на чтение, невозможно.
FASMI test failed, sorry.

Похоже Вы немного запутались в этом вопросе...
Доступ на чтение к кубу для пользователей открыт постоянно. Вопрос только в том, насколько в среднем устарели данные в кубе при запросе пользователя. Например, если я делаю запрос к кубу, который был обновлен и открыт для доступа 2 секунды назад - то данные устарели на 2 секунды. Если я делаю следующий запрос через 8 секунд - то данные устарели уже на 10 секунд. Допустим третий запрос я делаю через 4 минуты, и данные устарели уже на 4 минуты 10 секунд. Ну а сделав следующий запрос еще через минуту я обнаружу что данные устарели на 45 секунд. Это означает что один цикл обновления куба составил 4 минуты 25 секунд.
В случае если требуется поддерживать более высокую свежесть данных, я могу запускать обновление куба с интервалом 15 секунд - тогда примерно каждые 15 секунд у меня будет появляться свежий куб... Можно это делать и чаще, но нужно ли это...
Практика показывает, что в большинстве проектов кубы обновляются один раз в сутки, ночью, так как за день все равно данные поступают неравномерно, уточняются, устаканиваются.

2 MSTR_Fan:

Jurii, теперь можно не оправдываться - Вы сами подтвердили что минимальный интервал между обновлениями куба равен времени копирования файла куба.
То есть, для больших кубов - минуты.

Вы немножко не въезжаете в тему... Как думаете, почему автомобили иногда сходят со сборочного конвейера раз в одну или в три минуты? Или почему так часто в Москву приезжают поезда из Питера (бывает раз в 5-10 минут, хотя по хорошему должны приходить раз в 8 часов)?
Если запускать несколько процессов обновления кубов одновременно, то в один взятый момент у нас будет несколько кубов на разных стадиях обновления. И соответственно свежесть данных в кубах можно доводить до абсолютной свежести...
И не забывайте, что мы не трогаем репортинговую функциональность Cognos, которая является аналогом MSTR и BO. Мы говорим только о том, что является преимуществом Cognos по сравнению с MSTR и BO - а именно - о кубах.

2 MSTR_Fan:

Если запускать несколько процессов обновления кубов одновременно, то в один взятый момент у нас будет несколько кубов на разных стадиях обновления. И соответственно свежесть данных в кубах можно доводить до абсолютной свежести...
Jurii, это уже бред. Ясно что по делу Вам добавить нечего.

Зря Вы называете это бредом... Это можно сказать Real-time OLAP, то что так любит Володя Иванов...

2 backfire:

Юрий, вы это собственными руками сделали зоть раз или вам сейчас эта идея пришла в голову? и все это вы будете реализовывать на bat файлах? а поодерживать и сопровождать эти "сопли" кто будет? да вас любой DBA выгонит большой метлой.

Я делал примерно такие проекты. С обновлением кубов раз в 5-6 минут. Но ничего не мешает обновлять и чаще, если параллельно запускать обновления, как на конвейере.
Также у меня был проект, когда система написанная на Delphi отслеживала изменения в хранилище и определяла, какие кубы надо обновить...

2 backfire:

Я делал примерно такие проекты. С обновлением кубов раз в 5-6 минут.
так примерно, или такие?

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

2 серый ник:

no comment

Все понятно, но что конкретно Вы имели в виду? :)

2 MSTR_admin:

APPLAUSE!
особенно понравился термин Real-time OnLine Analytical Processing

Этим высказыванием Вы хотите подчеркнуть узость своего кругозора? Real-time OLAP - это устойчивый термин, функциональность MS AS, которая на форуме много обсуждалась. У Cognos тоже есть аналогичная функциональность.