BirkhoffПринципиально что угодно может использовать что угодно. Вопрос как.
Тут есть несколько моментов.
Конечно можно написать произвольный SQL, который будет засылаться на сервер и там исполняться. Но это не стандартная фича. Обычный пользователь не сможет написать такой запрос, а сам он не сгенерится.

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

Можно. Делается точно так же, как и при определении любого другого объекта BO
Birkhoff
Вот какую проблему я видел и не смог обойти. (Хотя возможно кривые руки)
Результат запроса, посланного BO на сервер находится в памяти клиента и все вращения кубов происходят тоже там же. Если же объем выборки велик, то компьютер клиента при этом практически умирает.

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

Все аналитические функции Oracle типа CUBE, ROLLUP и т.д. поддерживаются BO и, естесственно, считаются на сервере. Хотя, есть возможность считать их и в самом BO
Birkhoff
Потом, когда делаешь Drill Down, такое впечатление что BO достает все данные по всем уровням, а потом в памяти их объединяет, что вызывает жуткие тормоза при глубоких иерархиях.

При Drill Down BO достает данные следующего уровня. Если в опциях не указано применять фильтры детализации, то тащится весь следующий уровень, если указаны, то в SQL вставляются условия where ограничивающие результат по конкретной ячейке, которая детализируется.
Т.е. в Вашем случае можно сделать, чтобы детализация-обобщение работала по быстрее, но это все равно будет хуже, нежели у MOLAP сервера.
IMHO, хотя в BO и есть этот функционал, но это не то, ради чего стоит его приобретать, все-таки в первую очередь это Ad Hoc & Reporting
Birkhoff
Alexander Stoulov
Теперь по возможности объединять в ВО данные из разных источников. В 90 % случаев эта возможность используется для создания отчетности по одному источнику (DWH и оно чистое). Просто в отчете необходимо объединить результаты различных SQL выражений (разных таблиц фактов).
Какой SQL генерит в этом случае DISCO? Например, сравнить фактические продажи по дням с тремя видами планов. Все это сгруппировать по неделям и месяцам, плюс в группировке по месяцам добавить отдельной строкой данные за прошлый год.
Если между этими таблицами определены связи, то и будет генериться SQL выражение, объединяющее три таблицы.
Еще один вариант - создается custom folder, который содержит UNION, объединяющий три таблицы, но а дальше работаем как с одной таблицей
Что значит, если связи определены между таблицами? Есть четыре таблицы фактов (фактически продажи, производственный план, внутренний план продаж, внешний план продаж). Для простоты, примем, что они опираются на одни измерения.
Что такое custom folder и как он может содержать UNION. К стыду своему, я пока вообще не представляю, что такле DISCO. Во что это трансформируется для сервера БД?

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


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

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

Почему не можете, может через подзапрос.
Но подзапрос это не конструкция select ... from (select ... from ...)