Насколько я помню, на форуме www.olap.ru сравнивались MS AS и Oracle. В итоге было решено, что MS AS - это более круто. Если посмотреть отчет Gartner ( http://mediaproducts.gartner.com/reprints/cognos/116968.html ) - то у MS AS тоже заметное преимущество. По доле рынка (на сайте www.olapreport.com ) Microsoft тоже опережает Oracle...

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

))))))))))))
Анекдот в тему: Сидят фанаты сборных России и Украины по футболу, и обсуждают - какая сборная лучше. А такие экзотические сборные, как Бразильская и Ватиканская, даже в расчет не принимают )))))))))))

Вроде как если почитать форумы, где сравниваются Когнос и его конкуренты, Когнос никак нельзя назвать экзотическим. По крайней мере - это один из старейших продуктов на рынке аналитических систем.

to breakdancer:

Вернемся еще раз к отчету компании Gartner:
http://mediaproducts.gartner.com/reprints/cognos/116968.html

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

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

Если Вы сомневаетесь, что человека (аналитика, руководителя), мало знакомого с информационными технологиями можно научить за считанные дни создавать сложные OLAP-кубы и другие типы аналитических моделей Cognos - я могу привести реальные примеры из жизни (в то же время я согласен, что продукты MS и Oracle изучить во много раз сложнее, поскольку они требуют знания SQL, MDX и т.п.).

И не забывайте, что Cognos умеет работать напрямую со всеми популярными РСУБД (в том числе MS SQL, Oracle, DB2), и умеет поддерживать гетерогенные источники данных в одной аналитической модели.

To Birkhoff:

Построили сторонние консультанты систему на Express Server, систему не очень большую, не то чтобы ее обслуживать должны были 20 человек. Да и вообще практически в обслуживании не нуждалась - данные исправно грузились каждый день, разработки новой практически не нужно было

Похоже это была не аналитическая система. Любая аналитическая система постоянно совершенствуется, развивается, иначе можно отстать от конкурентов... :)

А админы редко любят учиться чему-то что лежит сильно в сторону от их непосредственной деятельности.

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

To Birkhoff:

Почему? Новые отчеты создавать они могли.

Это понятно, только проблема в том, что аппетит аналитика/руководителя растет во время еды, и хочется добавить в отчет новые аналитические разрезы, которые в кубе не были предусмотрены. Соответственно приходится перепроектировать и перегенерировать куб на OLAP-сервере.

Приницпиально новые данные загрузить было сложнее

Вот тут и встает вопрос - может ли аналитик перепроектировать куб самостоятельно, или ему надо писать тех. задание для технического специалиста/стороннего консультанта... В Oracle Express добавить новые измерения в куб - это не легко.

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

А это уже вопрос о мощности OLAP-движка. Если например для велосипеда груз 100 килограмм - это перебор, то для грузовика - это ничтожная нагрузка.
Если не секрет, что значит "очень большая база данных"? Интересно было бы узнать кол-во записей в таблицах фактов и кол-во листьев куба.

А вашем случае администратором работает кто? Аналитик/руководитель?

В тех проектах, где в БД было более 50 миллионов записей, обычно администратором выступал представитель отдела АСУ. Но таких проектов - меньшенство. В большинстве проектов объемы данных измеряются миллионами или даже меньше. И в таких компаниях нет большого отдела АСУ, а есть админ БД (он же админ по железу), и не более того. В таких случаях я обучаю аналитиков полному циклу - от соединения с реляционной БД из модуля Cognos Impromptu до создания виртуальных вьюшек и проектирования кубов в PowerPlay. После этого аналитик администрирует аналитическую систему, и лишь иногда консультируется с админом по структуре БД (в каких таблицах что лежит).

To Birkhoff:

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

Приличные объемы данных, прямо как в метрополитене Лондона, где Cognos PowerPlay используется для анализа поездок пассажиров.
Удивительно, что Oracle Express справляется с таким объемами (если конечно они предварительно не агрегируются).

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

Согласен, по политическим мотивам админы таких серьезных баз данных обычно не допускают до них пользователей, и разработка/оптимизация запросов в Impromptu ведется под контролем сотрудника отдела АСУ.
Однако, в тех случаях, когда аналитик хочет доработать аналитическую модель, ему не всегда требуется изменять запрос Impromptu. Зачастую достаточно войти в модуль проектирования куба, добавить новые вычисляемые колонки, измерения, уровни иерархии, показатели, категории и т.п., и все это не будет увеличивать нагрузку на сервер реляционной БД, а увеличит нагрузку на OLAP-сервер (личный компьютер аналитика).

To Birkhoff:

У вас есть более подробная информация об этом проекте?

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

Любой OLAP сервер будет агрегировать такие объемы данных иначе смысл потеряется.

Все зависит от наличия исходных данных. Если карточки для проезда в метро - обезличены, то придется в кубе ограничиться лишь измерениями Время (год-квартал-месяц-неделя-день-час-минута), Станция отправления, Возможно станция назначения, Тип карточки + другие характеристики карточки, + возможно производные аналитические разрезы (например, сколько времени человек пробыл в метро). Однако, если даже в России появляются центры персонификации, то в Лондоне это есть точно - то есть у многих карточек имеется целый набор дополнительных аналитических признаков, которые полезно включать в куб как дополнительные измерения.
А чем больше детальных измерений в кубе - тем меньше степень агрегации данных на OLAP-сервере. Смысл закачки детальных данных в куб состоит в том, что это расширяет границы для анализа и отчетности.

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

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

А что касается вставки вычисляемых показателей - так кто мешает это сделать на Express?

Я имел в виду, что на основе вычисляемых показателей пользователь Cognos PowerPlay может добавить визуальными средствами измерения/уровни иерархии и т.п в куб, и перепроцессить куб без увеличения нагрузки на реляционный сервер. Подобное возможно в Express, или Вы говорите про вычисляемые показатели только внутри интерфейса при работе с готовым кубом Express?

To Aleksm:

Как обычно: тема дискусии "срввнение MS AS, Oracle Express и 9i OLAP"
,а обсуждение свелось к "замечательному продукту Cognos".

Дело в том, что г-н breakdancer сформулировал название этой дискуссии не совсем однозначно (непонятно, хотел ли он сравнить технологии MS и Oracle, или просто выбрать лучший продукт из имеющихся на рынке). Продукт Cognos он посчитал экзотическим, хотя реально это говорит о его недостаточной осведомленности (например, не все знают, что к Oracle можно коннектиться не только через ODBC, но и через прямой драйвер Net8, или что в другой город можно позвонить не только через восьмерку, но и с помощью карточки IP-телефонии :)

И хотелось бы почитать описание проекта "Когнос в метрополитене Лондона", да и краткое описание методики анализа.

Мне пока не удалось найти то описание, которое я когда-то читал на английском языке. Но зато нашел статью на немецком языке:

http://www.cognos1.de/app/281/index.jsp?reportId=58

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

могу высказать гипотезу, что для хранения данных используется DB2 или Oracle, а анализ производится только над агрегированными данными, например: Измерения: "Станция"-"Час дня" показатель:"К-во пассажиров"

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