2 maxol66

Кстати поддержка некоторых фич из списка про OLAP пока не поддерживается клиентами такими как Discoverer for OLAP или Spreadsheet Add-In.

Что я вам могу конкретного ответить, например, на ваш вопрос "работает очень медленно (медленная сортировка, иногда уровень разворачивается за 2 секунды, иногда за 30 секунд)" ?
А у меня все работает очень быстро, доли секунды?
Я же не знаю что вы там наваяли в вашей системе? Как можно что то сравнивать вслепую?

Или

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

Или

"Неудобство использования SQL и OLAP DML для работы с кубом. MS MDX гораздо удобнее, проще и понятнее"
Ну раз вам это проще и понятнее - кто же вам мешает использовать MDX?
Только почему тут половина вопросов на форуме - как вот это написать на MDX и как вот это? На 80% этих вопросов на OLAP DML можно написать ответ без обращения к форуму. Кстати насчет майнинга? Вам что-то конкретное нужно или вообще "(а он непременно понадобится)" ?

Или

"отличающиеся в худшую сторону буквально все аспекты работы с Excel Add-In по сравнению с MS PivotTable (с которой пользователи активно работают и, в принципе довольны, и которая стала еще лучше в даже бете нового Офиса" Ну я не знаю что вы там используете в Pivot Table, у меня никогда не получалось его использовать как нормальное аналитическое средство. Хотя может сейчас функционал дорос - не знаю.

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

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

Нет смысла брать на сайтах Microsoft сравнения по ценам с конкурентами - эти сравнения всегда будут в пользу Microsoft. Лицензирование имеет много тонкостей. См. выше.
На сайте Cognos всегда будет выгодно читать про Cognos и т.д.

Если вам нужен именно OLAP с MDX - то брать Oracle вам наверное не нужно.
Действительно опуститься по цене ниже 10К сложно. (можно если у вас уже есть Oracle EE)
Естественно Standard Edition будет дешевле чем Enterprise.
Для 15 чел Enterprise не нужен.

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

Jurii2 Birkhoff:
Самодостаточный продукт - Express, до сих пор продается.

Это не совсем законченный аналитический продукт, это средство разработки... Достаточно трудоемко в нем ваять аналитические модели.Интересно что вы понимаете под моделями и видели ли вы Express? И вообще вы любите оперировать терминами вроде "удобно-не удобно" Никакой конкретики что это значит.

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

OLAP служит не только для анализа данных на экране - задача отчетности, которую он эффективно решает, тоже важна.Обычно для этого есть специализированные продукты. У них и требования другие.

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

Если самостоятельно написать OLAP-клиента к OLAP-серверу Cognos - это будет бесплатно, но функциональности получится меньше, чем в стандартных OLAP-клиентах от Cognos. То же самое справедливо и для MS AS - можно брать бесплатных OLAP-клиентов, которые довольно слабы, можно покупать навороченные коммерческие OLAP-клиенты.Я к тому, что (не знаю как в Cognos или MSFT) но, например в Oracle если вы соединятетсь хоть из бесплатного продукта хоть из своего собственного - вы все равно являетесь пользователем сервера и на вас должна быть лицензия. Сомневаюсь что у Cognos или Microsoft оставлена такая дыра в лицензировании. Какой смысл тогда использовать родные продукты Cognos и платить за них?

Jurii2 Birkhoff:

Интересно что вы понимаете под моделями и видели ли вы Express? И вообще вы любите оперировать терминами вроде "удобно-не удобно" Никакой конкретики что это значит.

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

JuriiExpress я видел, и хотя сам на нем не разрабатывал - читал книжки, дискуссии на форуме, общался с коллегами, которые разрабатывали на Express. То что он менее удобен, чем Cognos - это на мой взгляд аксиома, и это справедливо как для работы с источниками данных, так и при проектировании кубов. На Express тяжело провести тест-драйв за 2 часа :)То, что вы для оценки работы со сложными продуктами употребляете слово "аксиома" - говорит само за себя.
А на счет тест-драйва - можно провести тест драйв Notepad за 10 минут. Говорит ли это о его возможностях? Или может это говорит о его возможностях?

Jurii Я к тому, что (не знаю как в Cognos или MSFT) но, например в Oracle если вы соединятетсь хоть из бесплатного продукта хоть из своего собственного - вы все равно являетесь пользователем сервера и на вас должна быть лицензия. Сомневаюсь что у Cognos или Microsoft оставлена такая дыра в лицензировании. Какой смысл тогда использовать родные продукты Cognos и платить за них?

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

Jurii2 Birkhoff:

А на счет тест-драйва - можно провести тест драйв Notepad за 10 минут. Говорит ли это о его возможностях? Или может это говорит о его возможностях?

Тот факт, что Cognos позволяет провести тест-драйв за 2 часа (то есть с нуля спроектировать аналитическую модель на основе неизвестного заранее источника данных, наполнить ее данными и создать отчеты), означает, что при использовании Cognos пользователь не должен что-то программировать (за него все запрограммировали разработчики), пользователь концентрируется на решении бизнес-задачи визуальными средствами, при необходимости делая вычисления с помощью конструкторов формул.
А что касается ограниченности возможностей по сравнению с какими-либо другими OLAP-серверами, то это сомнительно... Этот вопрос на форуме обсуждалася много раз, и еще не найдено задач, которые где-то можно решить, а в Cognos нельзя.Юра, дело в том, что в реальных условиях часто проблема не в том, чтобы мышкой сказать откуда брать данные, а вообще разобраться в структуре этих данных и как их связать.
Я очень сомневаюсь, что если для сбора данных по каким нибудь остаткам из OLTP системы можно написать запрос на несколько десятков строк, объединяя десятка два таблиц, то тоже самое можно сделать на Cognos мышкой за два часа. Не говоря уж о том, что сам такой запрос можно писать и отлаживать несколько дней. Это уже после того как будет ясна структура данных. Когда данные подготовлены - затащить их можно в любую систему.

Jurii Я бы поискал доказательство. Как то это слишком маловероятно (для меня)

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

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

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

С остатками кстати тоже.
Хотя может быть вы демонстрируете саму возможность получить "какой-то" отчет, на основе данных клиента, а выдает ли этот отчет информацию или ахинею для демонстрационных целей не важно.
Это было бы понятно.

Jurii2 Birkhoff:

Признайте, что подобные случаи - редки... Если провести опрос среди участиников форума, то у большинства не будет вопросов по поводу где таблица фактов, а где справочник.Мне видимо не везет. Что ни заказчик, то самопальная система, программисты которой давно уволились и работает она давно в автопилоте.
JuriiМой опыт говорит, что даже не зная структуры БД и не имея возможности проконсультироваться у админа, я могу за 30-60 минут методом банальной эрудиции (просмотром содержимого таблиц, сравнением их размера, проверки на наличие поля дата, символьных полей с русскими названиями и т.п.) худо-бедно разобраться в структуре. Хотя это бывает редко, обычно имеется какая-либо из популярных учетных систем с известной структурой.Худо-бедно это не интересно. А на популярных системах часто уже накручена популярная же аналитика.

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

JuriiВ ходе тест-драйва я обычно использую одну-две таблицы фактов за большой период времени либо за всю историю, подключаю справочники, создаю один или несколько кубиков. Какая тут может быть ахинея, откуда ей взяться? Совершенно конкретные получаются модели для анализа продаж, закупок, остатков, дебиторки-кредиторки...Ахинея может быть где угодно, в задвоениях, в непопадании в интервалы, в неизвлечении всех данных, в суммировании данных не имеющих к друг другу отношения и т.д. Если отчет показывает только что-то похожее на правду - он никому не нужен.

JuriiP.S. Если все Ваши проекты связаны с анализом CDR, то согласен, требуется время на их предварительную обработку. С ними можно и не успеть уложиться в 2 часа. Но там где есть CDR - уже есть реляционная БД, где они хранятся :)Проекты бывают самые разные, а телеком в данном контексте отличается только большими объемами данных, разбираться со структурой также сложно/просто.