To oracle9idba:

относительно недорого (дешевле решений от MS, руководству твоему должно понравится :)

Насколько я знаю, у Microsoft вообще нет решений класса Query & Reporting (по крайней мере пока). Так что я бы сравнивал Discoverer с Cognos Impromptu...

Правда ли, что Discoverer заточен на анализ, но при этом не является профессиональным генератором отчетов?
И есть ли в Oracle Discoverer интеллектуальный конструктор выражений?

Действительно, если есть БД на MS SQL + несколько других источников можно создать ХД в Oracle, подцепить к нему Discoverer, Oracle Reports, навесить Oracle Express... Правда стоимость и трудоемкость реализации такого решения будет немалая.
Помнится на форуме (то ли на этом, то ли на www.olap.ru ) обсуждался вопрос, что если есть БД Oracle, почему бы к ней не прикрутить MS AS - а хранилище в MS SQL Server будет бесплатным подарком :)
Интересно, бывают ли в жизни такие случаи с одновременной поддержкой двух СУБД - Oracle и MS SQL? То что к Oracle прикупают MS SQL - я слышал, а вот обратные случаи - не слышал...

To .dba

Юра, про этот "интеллектуальный конструктор выражений" вы упоминаете в каждом втором постинге, используется для определения column calculation или mesure calculation.

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

в Discoverer тоже такой есть причем с возможностью использовать широкий спектр оракловских аналитических ф-й (очень интересная штука кстате - позволяет совмещать группированный и не группированный результат в одном sql запросе).

А вот в Discoverer - насколько я помню, конструктор не является контекстно-ориенторованным. Что касается функций - то Cognos Impromptu позволяет увидеть и использовать оракловские функции. Хранимые функции оракла тоже можно подключить в общий список функций.
Impromptu также позволяет совмещать группированный и негруппированный результат в одном запросе. Например, если в БД - 1 миллион строк по 10 тысячам клиентов, 50 тысячам товаров и по 10 филиалам - мы можем получить 1 миллион строк результата - в одном поле будет детальный показатель, а в соседних полях мы увидим итог по клиентам, товарам и филиалам. Таким образом я часто провожу разбиение клиентов на крупных, средних и мелких, используя поверх итога функцию квантиль.

неужели если я хочу затянуть из базы негруппированный рез-тат например некую shipment_date я должен обязательно использовать count(shipment_date) в исходном sql запросе, а вот определить mesure (или column) calculation как count(shipment_date) не могу, т.к. групповые функции там уже недоступны?
Насколько я изучил ваши постинги - вы в таком случае затягиваете в куб уже группированный (в sql запросе) результат. Но вот например в MS AS в свойствах mesure/"source column" можно указать count.

В Cognos PowerPlay тоже можно указать Count в свойствах Measure. Не очень понятен Ваш пример. Если например есть таблица фактов - строки документов, но мне детальный куб не нужен, я обычно в виртуальном view использую другую таблицу фактов - шапки документов.
Видимо либо Ваш пример очень сложен - тогда я прошу сформулировать его подробнее, либо Вам просто стоит пройти небольшой тренинг по Cognos, чтобы изучить базовую функциональность и прочувствовать, как работает связка Powerplay + Impromptu при решении различных классических задач...

To Birkhoff:

Нормальная Enterprise система будет стоить не один десяток, а то и сотню тысяч долларов, даже у нас в стране.

Согласен, аналитическая система для крупной компании не может стоить копейки. Однако здесь на форуме есть представители из разных регионов, и не только из крупных компаний. Для массового рынка хорошо, если для начала нужно заплатить немного, и можно быстро получить первые результаты, покрывающие 60-70% потребностей. Такие продукты сушествуют (Cognos, MS AS).

Oracle, в общем то, ориентируется на Enterprise решения и для них дает целую линейку мощных продуктов, с помощью которых можно сделать практически все, что угодно при наличии грамотных спецов и достаточного финансирования

С моей точки зрения, у Oracle - хорошая РСУБД, но все остальные продукты - не являются лидерами в своих нишах. Лидирующие аналитические продукты не хуже дружат с РСУБД Oracle, чем оракловые аналитические продукты. А то что например Oracle Express или Discoverer мощнее тех же PowerPlay и Impromptu - верится с трудом. Просто Oracle лучше раскручен с маркетинговой точки зрения.

Системы класса Business Objects и других предполагают что ты купил за 2-5 тысяч коробку и можешь с помощью нее что то сделать, устроит это тебя или нет - неизвестно. Но настоящее Enterprise решение не построишь на таком софте. Более того, даже используя линейку Microsoft не так то просто построить нормальную систему. :)

Ну положим BO - стоит не 2-5 тыс., а подороже. За 2 тыс. можно купить Cognos PowerPlay + Impromptu. С помощью этих продуктов можно решать сложные задачи в пределах локальной сети компании (если не рассматривать кривое, но имеющее право на существование терминальное решение). Если нужно создать единый портал для всех филиалов - придется докупить портальное решение (либо простое и дешевое, либо навороченное и дорогое), но ядром аналитической системы будут все равно недорогие Windows-версии этих продуктов.
И я бы не сказал, что нормальную корпоративную аналитическую систему можно создать только с помошью продуктов Oracle.

Поэтому подсчет стоимости лицензий, начиная с некоторого уровня практически теряет смысл.

А вот с этим я согласен. Если даже не брать Москву и Питер, где годовая зарплата IT-специалиста не так мала, а рассмотреть например Новосибирскую область, где зарплата 200-300$ в месяц, то за год эта зарплата перекроет стоимость лицензий навороченнейших аналитических продуктов :)

To Birkhoff:

Легко можно устроить ситуацию, когда даже на 1000 исходных записей MOLAP сервер умрет из-за объема просчитываемых данных, а вот для ROLAP это будет совершенно не в напряг.

Не могли бы Вы привести такой пример. Ни разу не видел, как MOLAP умирает...