Вот в соседнем топике о таком решении и речь.
(Oracle Business Intelligence 10g)
http://www.sql.ru/forum/actualthread.aspx?tid=148254
Не все перечисленные вами фичи там присутствуют, но зато есть много того, чего нет в BO.

В смысле?
Кто и что не видел?

Извините, но это, мягко говоря, чушь.
Oracle очень давно находится на этом рынке.
А решение, о котором я говорю - просто следующий шаг.

Почему же тогда покупают Discoverer?
Это вопрос личных предпочтений.
Мне, например, интерфейс BO не нравится.
Хотя там есть несколько фич, которых нет в Disco. Ну и что с того?

С Express вы тоже не правы. На нем можно сдлеать что угодно. Там даже RAD средство есть, на случай, если вы не знаете.
Я все еще считаю, что может быть движок-цифромолотилка у MS сейчас лучше, чем у Express, но во всем остальном Express лучше. Начиная с языка запросов и кончая возможностью строить интерфейсы, которой у MS практически нет.

Zohar В конечные данные аналитики не лезли, а сосредотачивались на массе однообразных отчетов - как я понял Disco для этого и подходит, но большинство отчетов, это простые выписки.

Для отчетов подходит Oracle Reports, Dicoverer - не система печатных отчетов.
В Oracle раздяляются функции по разным приложениям, которые, однако же, поставляются в рамках небольшого числа продуктов.

ZoharКогда пробовал сам - очень удручили графики - некрасивые и скудные,

В Desktop варианте с графиками да, не очень. Но в Plus, который в основном и развивается последние несколько лет - с графиками все ок.

Zoharотсутствует экспорт в Excel,
Неправда.

Zohar трудности с кириллицей
Какого рода? Единственная проблема которую я знаю - это слет шрифтов в поставке 9.0.2, но которая все известна и лечится заменой двух маленьких файликов. Других проблем с кирилицей я не видел.

Zohar, в общем - тяжело и неудобно, с BO не сравниться - последний намного более понравился, кроме того Disco идет кажется в комплекте с пакетом средств разработки, но под потребности аналитика заточен скудно.

А комплект средств разработчика это минус?

Это дело вкуса, как я уже сказал.
У одного заказчика была интересная ситуация. Была группа аналитиков в опытом работы в BO (проши курсы). Потом им показали Discoverer.
И что интересно, мнения разделились примерно поровну. Одни говорили что BO более удобен, другие, что Disco.
Лично для меня тоже Disco более удобен, но конечно в BO есть фичи, которых там нет и наоборот.

ZoharНапример нет (или не нашел) возможности - на клиенте объединить информацию из корпоративной базы данных и из пользовательского источника - типичная задача при наших неполных данных в учетных системах, а руками планы или прогнозы заталкивать в RDBS - очень трудоемко, в BO это делается гораздо удобнее.
Что то можно сделать и из Discoverer, но в основном он заточен для работы с хранилищем данных и желательно на Oracle :)

Если вам нужно ворочать базу на Oracle на 100 миллионов записей, уверен что BO не сможет с ней работать, а Discoverer - вполне нормально.

ZoharКоллеги, есть кто нить, кто реально поднимал систему корпоративной отчетности на ORACLE-овых средствах, как я пришел к выводу - Хранилище (или сервер с данными для аналитиков)+BO+MS AS - в принципе позволяет закрыть основную массу потребностей, в частности малоподвижность BO на больших таблицах с фактами спасают кубы MS AS, но какая нужна архитектура в ORACLE - чтобы с одного клиента и в кубы нырять и в реляционное хранилище, да еще это публиковать в интрасети и обновлять по расписанию.

Oracle Application Server Enterprise Edition или Oracle Business Intelligence, о котором речь в другом топике.

Zohar2 Birkhoff

Проблема в том что кроме BO, ну еще Improptu, я не видел средства, в котором можно было бы по идентичным полям объединять данных из разных источников. Аналитикам, да и вообще экономистам - требуются данные из разных источников - порой в таких форматах - что руки опускаются что-либо делать. данных.
...

Это хороший вопрос.
Вы описали реальную проблему, которая часто встречается на реальных предприятиях с плохим уровнем организации обмена данными между подразделениями и работниками.
Но. Во первых, вся идея хранилищ данных и заключается в том, что нужно бороться с бардаком, а не распространять его дальше.
Oracle являясь идеологом "правильного" подхода к обработке информации, видимо считает что неправильно собирать данные из кучи искаженных эксель таблиц и аксессных баз, прямо на машине у пользователя, так как мусор на входе порождает и мусор на выходе. Поэтому я скажу, что видимо, Discoverer не подходит для решения подобной задачи.

Во-вторых, задачи на разных предприятиях разные. Например на том, что вы описали проблема в том, что источников данных много, они несогласованы и разрознены, но объем данных в каждом, по видимому не велик.
На других предприятиях проблемы разных источников вообще не возникает, так как основная боль там в скорости извлечения данных из табличек, содержащих сотни миллионов записей. Поэтому они не поймут, что за проблема на первом предприятии.
Или может быть проблема заключается в одновременном доступе к базе данных тысяч сотрудников, распределенных по всему миру...
Ну и так далее.

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

Выбирать нужно то средство, которое подходит лично вам.
Заметьте, я нигде не говорил, что Discoverer лучше, чем BO или чем Cognos или еще что-то. Я говорю о том, что у всех продуктов есть свои плюсы и минусы, и в каждой конкретной ситуации какой то плюс или минус может сыграть решающую роль.


ZoharТеперь вопрос - в каком продукте я должен работать, чтобы:
а) пользоваться корпоративными данными из учетной системы + мои исторически сложившиеся EXCEL и обновлять отчеты на их основе по одной кнопке;
б) скажем опубликовать эти отчеты на корпоративном сайте (портале отчетности), при этом поставив обновление отчета по расписанию и т.п.
с) вся эта система, желательно лежала не на плечах целого отряда IT, а предельно прозрачна была бы для меня самого.

Может быть Excel здесь подходит лучше всего? :)
Нельзя делать выбор, не изучив проблему. И даже после изучения у кого то может быть подход - взять лучшее от каждого вендора, а кто то не хочет плодить зоопарк и берет все от одного, смиряясь с отдельными недостатками.


Zohar2 Birkoff - Disco + - что такое, что нужно чтобы поставить и посмотреть, что туда входит и где скачать, готов изучить, если это аналог BO, в BO тоже много чего нет, но про него есть у кого спросить, a c DISCO мало кто работал, во всяком случае - приверженники Оракл рекомендуют, но доходит до проблемы - все в кусты.
Неправда, что с Disco мало кто работал. Думаю в СНГ гораздо больше людей, имеющих опыт работы с Disco, чем с BO. Возможно, что просто среди ваших знакомых таких мало.

Что такое Discoverer PLUS?

Discoverer для пользователя существует в нескольких ипостасях, каждая из которых имеет свои плюсы и минусы.
1. Discoverer Desktop - Windows приложение, работающее на локальной машине пользователя.
Плюсы -легкое, нересурсоемкое приложение, которое всегда под рукой.
Минусы - так как оно установлено на локальной машине, то исталляция и апгрейд в случае если у вас пользователей от нескольких десятков или они сидят в разных городах - целая проблема. Еще один минус в том, что последнее время он мало развивается.
2. Discoverer PLUS - функционально аналог Discoverer Desktop, но реализованный на технологии Java.
Минусы - Java приложение обычно тяжелее чем Windows. Также необходим сервер приложений, который обслуживает пользователей с браузерами.
Плюсы. Не надо устанавливать на каждую машину пользователя - пользователь коннектится через браузер и ему автоматом скачивается апплет.
Последнее время в основном он и развивается и функцинал постоянно наращивается.
3. Discoverer Viewer - в основном предназначен для просмотра уже готовых отчетов, созданных в Desktop или Viewer. Средство для начальников.
Плюсы. В отличие от PLUS, реализован на JSP, поэтому пользователю на машину ничего не скачивается, он работает просто с обычными HTML веб страницами.
Минусы. Нужен сервер приложений. Функционал серьезно ограниченней по сравнению с Desktop или Plus.

Я ответил на вопрос о том, что такое PLUS?
Discoverer (всех вариантов) входит в состав пакета Oracle Business Intelligence 10g, так что можно его скачать и поставить.
http://www.oracle.com/technology/products/bi/index.html
Тут есть линк на скачку и демонстрашки.

Zohar Для отчетов подходит Oracle Reports, Dicoverer - не система печатных отчетов.
В Oracle раздяляются функции по разным приложениям, которые, однако же, поставляются в рамках небольшого числа продуктов.

Проблема многих инструментов такая - для кубов один интерфейс, для реляционных запросов - другой, для стандартного репортинга третий и все с разными возможностями. Это неудобно !!! Мне, как конечному пользователю все равно что предоставляет мои данные - SQL, MDX, DML и еще чего там.
Также мне безразлично разделение на MOLAP, OLAP, ROLAP и пр. Моя задача - на данных помочь руководителям принять решение, показать в цифрах. На разных уровнях - по разному - обычному менеджеру - каждодневный оперативный отчетец подавай, руководителю повыше - более индивидуальный, ну а большим боссам - распечатанный приноси.
Мне хочется работать из одного интерфейса - в котором и можно делать анализ по срезам данных, а результат - оформлять в виде отчета -и хотелось бы чтобы этот делала машина, публиковала в WEB.

Пока еще никто не сделал универсального средства и для анализа и для репортинга и для веб публикаций и для реляционки и для олапа.
Хотя вот в том же Oracle BI интерфейс реляционного Discoverera настолько приближен к Discoverer для OLAP, что для того, чтобы понять в чем ты работаешь надо еще присмотреться. Ну а Viewer вообще отчеты открывает любые.
Кстати и средва экпорта там есть и печати и послыки по емейлу. Ну это так, к слову.


Zohar Birkhoff
А комплект средств разработчика это минус?

Что мне простому смертному на нем можно сделать, я и едва макросы осиливаю ?

Ну, батенька, вам не угодишь. По моему вы ищете средство состоящее из одной красной кнопки "РАБОТА" :)
Кстати, для ленивых в этих средствах разработки очень многое можно сделать просто мышкой, без кодирования.

Zohar Birkhoff
Если вам нужно ворочать базу на Oracle на 100 миллионов записей, уверен что BO не сможет с ней работать, а Discoverer - вполне нормально

Поясните, за счет чего ? Как можно на реляционной таблице в 100 миллионов записей сделать быстрый запрос ? здесь все равны перед объемом и производительностью сервера, организации базы данных и пр.
Разница в том, что Discoverer знает, что он работает с базой данных Oracle и знает о ее продвинутых фичах, и их и использует.
А BO, в силу своей универсальности по отношению к источникам, много работы берет на себя и при больших объемах получается что роль сервера баз данных начинает играть слабенькая клиентская машина.
А Discoverer всю ресурсоемкую работу старается отправлять на сервер.

Шургин Сергей Birkhoff
Разница в том, что Discoverer знает, что он работает с базой данных Oracle и знает о ее продвинутых фичах, и их и использует.

BO тоже знает с чем работает. Более того. Когда-то в Oracle работал и основатель BO :)

Встречный вопрос. Что значит "знает"? В чем это выражается? :)

Шургин Сергей Birkhoff
А BO, в силу своей универсальности по отношению к источникам, много работы берет на себя и при больших объемах получается что роль сервера баз данных начинает играть слабенькая клиентская машина.

Есть такая штука, ZABO - в роли слабенькой клиентской машинки можно использовать кластер из Win и UNIX-серверов.

А как это работает?

Шургин Сергей Birkhoff Шургин СергейЕсть такая штука, ZABO - в роли слабенькой клиентской машинки можно использовать кластер из Win и UNIX-серверов.

А как это работает?

Не совсем понятно, что понимается под этим вопросом?

Ну в этом и вопрос, объясните как это работает (ZABO) когда он может работать и какие преимущества дает?

И вот еще вопрос я так и не понял ответа. Что значит что он различает Oracle и SqlServer? Он может использовать конструкции типа Rank over partition в генерящихся запросах? (это не наезд, это вопрос :-) )

Alexander StoulovУ меня предложение, давайте поконкретнее, а то все обсуждение сваливается на маркетинговые лозунги.

Это где же вы у меня маркетинг то усмотрели? Упоминание торговых марок? :)

Alexander StoulovПриведите конкретные примеры, когда BO берет на себя роль сервера и какие таки фичи Oracle он

а) принципиально не может использовать
б) может использовать принципиально, но не в стандартной манере (визуально)

Принципиально что угодно может использовать что угодно. Вопрос как.
Тут есть несколько моментов.
Конечно можно написать произвольный SQL, который будет засылаться на сервер и там исполняться. Но это не стандартная фича. Обычный пользователь не сможет написать такой запрос, а сам он не сгенерится.
Второй момент - в Disco можно использовать например аналитические функции Oracle типа LAG, LEAD, RANK и так далее в рамках стандартного функционала Disco, а не написания произвольного запроса (хотя такая возможность тоже есть). Можно ли в BO прописать использование функций типа RANK , чтобы они вставлялись в сгенеренный SQL? (проблема в том, что это не обыные функции, а имеющие специальный синтаксис в SQL)
Еще вопрос, как обслуживаются вычисляемые выражения в BO? Они обсчитываются на сервере или на клиенте?

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

Вот какую проблему я видел и не смог обойти. (Хотя возможно кривые руки)
Результат запроса, посланного BO на сервер находится в памяти клиента и все вращения кубов происходят тоже там же. Если же объем выборки велик, то компьютер клиента при этом практически умирает.
Наверное, можно использовать фильтры для уменьшения выборки. Но что, если нужно использовать хитрые конструкции типа вложенных аналитических функций или конструкций типа ROLLUP?
Они обcчитываются на всей выборке, но в случае Disco обсчет идет на сервере, а в случае BO на клиенте. (По крайней мере, я не нашел обратного)


Потом, когда делаешь Drill Down, такое впечатление что BO достает все данные по всем уровням, а потом в памяти их объединяет, что вызывает жуткие тормоза при глубоких иерархиях.

Ну и так далее...

Alexander Stoulov
Теперь по возможности объединять в ВО данные из разных источников. В 90 % случаев эта возможность используется для создания отчетности по одному источнику (DWH и оно чистое). Просто в отчете необходимо объединить результаты различных SQL выражений (разных таблиц фактов).
Какой SQL генерит в этом случае DISCO? Например, сравнить фактические продажи по дням с тремя видами планов. Все это сгруппировать по неделям и месяцам, плюс в группировке по месяцам добавить отдельной строкой данные за прошлый год.
Если между этими таблицами определены связи, то и будет генериться SQL выражение, объединяющее три таблицы.
Еще один вариант - создается custom folder, который содержит UNION, объединяющий три таблицы, но а дальше работаем как с одной таблицей

Zohar
Существуют проекты на BO, которые работают по таблицам фактов более 100 млн. записей - в одном из крупных европейских банков подобное существует, за счет чего - не знаю, знаю, что в BO есть возможность использование родных функций ORACLE, в частности вполне удобно часть расчетов отдать серверу, здесь уже нужны знания серверной части и его производительности, но то, что BO может работать на больших объемах - это факт.

Да я думаю дело не столько в возможностях BO, а в том как построена аналитическая система в целом. Можно и из Excel читать данные из 100 миллионной таблицы и все будет работать быстро, если сервер настроен правильно и запрос простой.

Zohar
Вопрос не в производительности, посмотрим и Disco Plus -(Backfire спасибо за разъяснение ситуации с продуктом Oracle Discoverer и +, выглядит вроде как надо). Меня интересует еще один момент - Disco + может работать как с кубами, так и с реляционными данными, объединять их в одном отчете, например ? Какие службы (продукты) необходимо поднять, какая конфигурация требуется для этого ?
В одном отчете нельзя объединить данные из двух отчетов, но можно делать переходы от олап данных к реляционным.
Что нужно чтобы поднять.
СУБД Oracle (если хотите использовать Disco для OLAP, то база должна быть не ниже 9.2.0.5 и с OLAP опцией)
Oracle Business Intelligence (по сути Application Server в минимальном наборе для запуска Discoverer-ов)
Операционная система из списка поддерживаемых, на ваш выбор.

Если будете работать с OLAP из Excel - то нужно установить на клиенте Excel Addin. Если разработку будете свою делать, то JDeveloper еще c BI Beans. (Это все на диске Tools)
Сервер базы и апсервер можно поставить на одну машину, но лучше на две.
У меня все для экпериментов стоит на одной машине-персоналке и ничего так работает, правда памяти надо побольше.

Zohar
Теперь еще один момент - объединение пользовательских данных с данными корпоративными - это самое важное при выборе BI инструмента, на самом деле - поскольку не всегда все данные храняться в учетных системах, а это означает, что всегда будет область данных, находящихся в персональных файлах, порой их так даже выгоднее держать - например в процессе планирования происходят много изменений, что требует - быстро, что называется на ходу, подложить обновленный XLS и переформировать отчет - BO этим сильно подкупает, в Improptu тоже можно организовать подобное, как с этим обстоит в Disco +.
C Excel сложнее, Disco может работать с данными, лежащими на других серверах или источниках, но этот источник дожен быть зарегистрирован на сервере БД. В произвольный момент времени произвольный пользователь этого сделать не сможет.
Остается вариант - делать выборку в Disco, перекидовать в Excel (Copy-Paste)
ну а дальше в экселе сверять с чем угодно :)
Ну такой способ, думаю вы и так знаете.

P.S. backfire это не я :)

Шургин Сергей Birkhoff
Ну в этом и вопрос, объясните как это работает (ZABO) когда он может работать и какие преимущества дает?

Пользователь заходит на портал InfoView и закачивается себе специальный плаг-ин. Связь с источниками данных идет через тот же сервер, что используется в WebIntelligence. Функционал ZABO не отличается от BO (за небольшим исключением).

То есть, правильно я понимаю, что это плагин, внешне похожий на desktop вариант BO (не знаю как он правильно называется)?
А вращение уже скачанных данных где происходит? Тоже на сервере?

2 Alexander Stoulov

Я видел, по крайней мере в той версии BO, что была у меня что он знает о существовании RANK в Oracle. Но как прицепить LAG и LEAD, а тем более сделать их вложенными (Lead внутри Rank), я не нашел. Мне просто интересно посмотреть на пример как это делается в BO, так как я потратил довольно много времени чтобы найти этот функционал. Но возможно версия у меня была старая и с тех пор прогресс ушел вперед. Может быть есть линк какой нибудь в интернете, где подобный пример описывается?

В любом случае в качестве резюме, у любого продукта есть свои сильные и слабые стороны. Выбирая продукт, нужно смотреть насколько продукт подходит именно под ваши условия, и, в том числе, анализировать достоинства и недостатки.
Я как то сказал выше, что Disco ориентирован прежде всего для работы над СУБД Oracle и от этого идут тоже и достоинства и недостатки.
BO универсален и от этого у него тоже есть и плюсы и минусы.
Мне кажется, что BO и Disco хоть и пересекаются, но при этом заточены немного под разные ниши.
Я не сторонник бить себя пяткой в грудь и кричать что какой то продукт панацея и подходит всем.

Alexander Stoulov
Что значит, если связи определены между таблицами? Есть четыре таблицы фактов (фактически продажи, производственный план, внутренний план продаж, внешний план продаж). Для простоты, примем, что они опираются на одни измерения.
Что такое custom folder и как он может содержать UNION. К стыду своему, я пока вообще не представляю, что такле DISCO. Во что это трансформируется для сервера БД?

Custom folder это возможность создать в репозитории Disco как бы VIEW, которое однако же будет связано со всеми другими таблицами, так как будто это настоящая таблица Oracle. То есть Disco будет генерить SQL, на основе этого View и связанных с ним других таблиц или views.
То есть, если мы внутри этого фолдера поместим SQL выражение с View, объединяющим наши три таблицы, а потом укажем, что у него есть связи с другими таблицами-измерениями (Время, Номенклатура и т.д.)
То пользователь сможет строить по такому запросу свои отчеты.
Причем запрос, в принципе, может тягать данные и с другого сервера.

Disco будет генерить соответственно запрос, содержащий подзапрос с Union.

Alexander Stoulov Birkhoff
Ну в этом и вопрос, объясните как это работает (ZABO) когда он может работать и какие преимущества дает?


В линейку продуктов BO входит сервер WebIntelligence. Его задача организация работы пользователей в трехзвенной архитектуре.
Пользователь в трехзвенной архитектуре может работать через тонкий клиент или ZABO.
При работе через ZABO на пользовательскую машину при первом заходе на сервер закачивается и устанавливается полнофункциональный BO.
Плюсы
- вся мощь толстого BO по формированию отчетов
- минимум администрирования клиентских машин
- возможность аудита работы пользователей

По сравнению с двухзвенной архитектурой работа через ZABO производительности не добавляет - вся обработка все равно идет на сервере БД и клиенте BO

Спасибо!
То есть, если мы работаем через тонкий клиент, то вся нагрузка ложится на webIntelligence? А если через ZABO, то это просто легкий способ установки клиента BO на машины пользователей. В остальном это тоже самое, как если бы поставили с диска каждому клиенту персонально, только с трассировкой действий пользователей на сервере?

Кстати, а что будет интересного в BO XI? Кроме того, что он будет на Java и от этого у него будут бОльшие требования к ресурсам клиентов и серверов? :)