Привет!
Я постараюсь дать свою версию ответов :)
Вообще разбираться в OLAP в 3.40 ночи по Москве (даже если в Германии было 1.40) - это круто :)

Сергей.deРедко встречал такую запутанную архитектуру, такую несовместимость отдельных компонент внутри одной тематической оболочки _одного_ производителя и всё это окутанно таким густым маркетинговым белым дымом что бы разобраться практически невозможно :-(
Я бы сказал, редко встретишь такое большое количество продуктов в одной области у одного производителя. Насчет их несовместимости между собой можно говорить долго, но я, например, не думаю, что от того что Data Mining опция мало совместима с Oracle Express кто-то от этого страдает.

Сергей.de1) С чем связани эти дебри в архитектуре продуктов? С тем что Экспресс по-прежнему только чуть-чуть интегрирован в Оракл 10г? Но почему тогда только Дискаверов штук 5 в разнах обличиях?Я не совсем понял вопрос. Какие именно дебри? Express и Discoverer никак не связаны. Существует Discoverer for OLAP, который работает с OLAP опцией, которая построена на основе движка Express. А то, что Discoverer-ов много, так это потому что они различаются
а) по технологии реализации (клиент-сервер (Desktop), толстый веб клиент (Plus), тонкий веб клиент(Viewer)) и
б) по доступу к данным (Discoverer реляционный и Discoverer for OLAP)
Есть еще компонент для публикации отчетов Discoverer на Portal
В конкретном проекте вы выбираете, что именно вам нужно и на мой взгляд это не путаница, а возможности. Нужен клиент-сервер - берете клиент сервер, нужен веб-клиент - берете веб клиент. Отчеты все равно совместимы. То, что создно в клиент-сервере будет работать и в веб-клиенте и наоборот.

Сергей.de2) Я правильно понял, что CREATE DIMENSION в SQL-окне не имеет никакого отношения к ОЛАП каталогам ROLAPа или AW? Да. Эта конструкция придумывалась еще в 8 версии когда никакой OLAP опции не было и в помине. Она нужна для обработки запросов по Mat View.

Сергей.deПравда ли, что эти 2 каталога не имеет ничего общего между собой? ROLAP каталог реляционален, МОЛАП лежит внутри AW куба?Не совсем. Тут надо не смешивать две технологии. У Oracle довольно давно существует технология Discoverer, которую в некотором смысле можно назвать ROLAP, но это не совсем так. Репозиторий Discoverer называется End User Layer. И на текущий момент он не имеет непосредственного отношения к OLAP каталогу, который является частью OLAP опции. Поэтому давайте разделять OLAP каталог и EUL.
OLAP каталог один. Через него видны все олап объекты (измерения, кубы и т.п) независимо от схемы их хранения (ROLAP или MOLAP) Но если в случае ROLAP все маппинги (где лежит таблица с измерением, какие у нее иерархии и в каких колонках и т.п) лежат в самом OLAP каталоге (схема OLAPSYS), то для MOLAP кубов на лету происходит подчитывание их метаструктуры непосредственно из кубов. Но конечный пользователь этого всего не видит. В этом и идея, чтобы не зависимо от типа хранения пользователь мог работать используя одни и те же методы и инструменты.

Сергей.de Верно ли утверждение, что ROLAP dimensions более гибки и мощны, что для рид-онли и простых калькуляций РОЛАП предпочтителен?
Я бы так не сказал. Где это написано? На мой взгляд, основное преимущество ROLAP в том, что данные никуда не перекачиваются, и доступны как только попадают в таблицу.

Сергей.de3) Как выглядит архитектура РОЛАПа после звезды, в смысле со стороны рипортинга? Особенно интересует есть ли там какой-нить метадата лэер отображающой куб и чем его можно заполнить?Если говорить именно о ROLAP, а не о Discoverer, то этот метарепозиторий называется OLAP каталог.

Сергей.de End User Layer - это он? И с его помощью можно в (реляционном?) Диско представить star schema как куб? С drill-down и drill-thru в OLTP?EUL - репозиторий реляционного Discoverer, а не OLAP. Но если вы хотите строить отчеты в стиле ROLAP над данными в таблицах, то Discoverer вам подойдет.

Сергей.de И с его помощью можно в (реляционном?) Диско представить star schema как куб? С drill-down и drill-thru в OLTP?
Можно.

Сергей.deМожно ли его (EUL) заполнить OWBом или только в админе дискавера?Можно. Через Export Wizard.

Сергей.deКакими рипортинг компонентами можно работать с ROLAP кубом - кроме (relational) Discoverer?С EUL можно работать только через Discoverer.
C OLAP каталогом (и соответсвенно с данными, на которые он ссылается) можно работать либо при помощи Discoverer for OLAP либо написав или использовав приложение написанное на BI Beans, либо использовать либое средство понимающее OLAP API, например Business Objects. Да хоть из SQL.


Сергей.de4) Если я правильно понял, то основной изъян РОЛАПа - плохой перформанс - амортизируется Ораклом за счёт MViews и QUERY REWRITE. Какую роль в этой конструкции играет EUL?OLAP к EUL имеет мало отношения, поэтому можно сказать никакого. Но если говорить про Discoverer, то он содерджит wizard, который на основе статистики запросов может предложить построить Mat View.

Сергей.deЗашита ли в нём какя-та информация о том когда можно и нужно переписать запрос? Работа по переписыванию запросов (QUERY REWRITE) целиком выполняется сервером Oracle, вне зависимости от того использется ли Discoverer, ROLAP или еще что-то.

Сергей.de5) Правда ли что физически AW _всегда_ запоминается в качерстве BLOBa в обычной таблице? Т.е. его нельзя хранить как "обычный" файл? Вы можете экспортировать AW в файл :-), но использовать не сможете. Так что да, AW хранятся в блобах. Но там используется технология партиционирования, так что одно AW может лежать в нескольких блобах.

Alex_D Сергей.de5) Правда ли что физически AW _всегда_ запоминается в качерстве BLOBa в обычной таблице? Т.е. его нельзя хранить как "обычный" файл? Да хранится в обычной таблице. Хранить в виде файла изменив параметры хранения таблицы, конечно можно, но кроме гемороя Вам это ничего не даст.Это что-то новенькое. Это как изменить параметры хранения таблицы?

ГликогенМаст дай полнейший :)

Для юзера вообще все должно быть через один интерфейс, независимо от платформ.
А так же сбито позиционирование с фокусом :)
Если учесть то, что для оракловских кубов ни у MS, ни у Cognos клиентов нет - маст дай!Вы о чем? Юзер и так работает через один интерфейс. А Excel в качестве клиента - не клиент? Как вариант.
Ну а еще я написал, что можно работать через SQL, так что любым средством можно доставать данные. Business Objects - тому пример.
А про то, что Cognos чего-то не может вы еще услышите :)

Сергей.deВсем спасибо за ответы, продолжаем :-)...

1) EUL. Хорошо, репозиторий Дискаверера. Вы не находите, что это по крайней мере странно размещать описание структур данных в компоненте просмотра и анализа, а не в бэкенде, где собственно и хранятся данные?Не совсем понял. EUL находится в базе данных и представляет из себя набор оракловых таблиц с метаданными.

Сергей.deЯ понимаю, что универсум в BusinessObjects - по сути тоже самое, но у БО нет своего бэкенд продукта, их можно понять, им кушать тоже хочется :-) Но зачем этом заниматься Ораклу? Продолжаю не понимать.
Может разгадка в том что, линейка Discoverer существует уже наверное более 10 лет и создавалась в тот момент когда ни о каких единых репозиториях не было и идей. Поэтому это был (да и есть) независимый продукт. OLAP каталог появился в тот момент когда у Discoverer уже была огромная история. Взять хотя бы E-Business Suite - там половина отчетов сделаны на Discoverer. Так что может быть в будущем репозитории OLAP и Discoverer и сольются, но как мне кажется у них разные и задачи и клиенты и необходимости делать это прямо сейчас нет. Не говоря уж о том, чтобы быть прописанными в OLAP каталоге данные должны иметь определенную структуру (например звезду) а для Discoverer это не обязательно. Discoverer это средство построения ad-hoc запросов а не ROLAP инструмент. Поэтому разные цели и разная имплементация. Кажется что репозитории описывают одно и то-же, но на самом деле это не так. Вы же не хотите сказать что средство печатных отчетов должно иметь одинаковый репозиторий со средством OLAP? Потому что задачи хоть и похожи, но все же различаются.
Хотя, конечно архитектурно красивее было бы их слить вместе, но наверное это не так просто да и не так нужно.

Сергей.de Вы можете возразить, что в бэкенде есть свой "прозрачный" ОЛАП каталог. Но согласитесь, речь мы уже ведём речь о _двух_ каталогах, один в Frontend и один в Backend. И оба описывают тоже самое!Я ничего такого не собираюсь говорить. Наоборот я бы четко разносил Discoverer EUL и OLAP каталог. Как оно собственно и есть.

Давайте еще раз четко договоримся
Есть линейка реляционного Discoverer, которая никакого отношения к OLAP не имеет. И есть линейка OLAP-ROLAP, которая никакого отношения не имеет к реляционному Discoverer. Можно для простоты считать что, Discoverer к OLAP опции имеет столько же отношения, сколько и Business Objects. Это архитектурно. Но если брать конечного пользователя, то для него конечно возникает путаница, посколько вроде как и там и там строятся отчеты. Рисовалка отчетов для OLAP называется Discoverer for OLAP, и выдержана в том же Look And Feel что и реляционный Discoverer. Как раз для того чтобы пользователю было не важно к какому репозиторию он коннектится - OLAP или EUL. Когда-нибудь, возможно, это будет единый репозиторий, но сейчас это не так.

Сергей.deПо крайней мере частично. Существует ли между ними автоматическая синхронизация? Хотя бы в одном направлении? Идея проста как мир: кубы создаются допустим в OWB или AWM или OLAP Worksheet или программно. Факт - они создаются в бэкенде. При создании кубов ручками набивается структура куба и эта информация, если я правильно понял, не попадает автоматом в ЕУЛ? Oracle Discoverer End User LayerTM Gateway о котором писал Алекс - это что-то автоматическое или "пальцевый интерфейс"?Для прописывания метаданных в EUL есть Discoverer Administrator. Есть возможность, как уже сказали, делать экспорт в EUL на основе описания, созданного в OWB. Это фича OWB. Говоришь какое описание куба нужно создать в OWB и он на его основе генерит XML. Не знаю пальцевое это или нет.
В следующей версии OWB т.н. Paris это будет сделано без промежуточного визарда, а как-бы напрямик. По крайней мере так пишут.

Сергей.de 2) В официальной доке Оракла на странице посвящённой Диско фэмили, я увидел картинку с 8! компонентами со словом Discoverer в имени. Попытаюсь подытожить:Я бы сказал что это несколько дурацкая маркетинговая картинка :)

Сергей.de D. Administrator - ok, админ тул, папа, Для всех детишек?Это средство проектирования и заполнения EUL. Типа BO Unversal Builder или как он там называется.
Сергей.de D. Desktop - толстый клиент, не-вебовый, скорее всего аппликуха на яве. Он писался на C во времена когда Ява только первые шаги делала, а может и раньше.
Сергей.de D. Viewer - тонкий, хтмл-овый, Ява нужна или pure-HTML? В принципе понимает только заготовленные отчёты, но вроде как может паблишить в портал? Навигирует в кубе? Pure HTML. В этом и идея чтобы никаких аплетов не грузить. Понимает только заготовленные. Навигирует.
Сергей.de D. Portlets - чё-то для AS Portal, не совсем понял. Это значит что отчеты Disco можно публиковать в качестве портлетов на портале.

Сергей.de D. Portlets provider - тоже провайдер для AS Portal, паблишит worksheets в AS Portal. Чем создаются Worksheets? Создаются в Desktop или Plus.
Сергей.de D. Catalog - судя по всему также зовётся Active Catalog. Ещё один, welcome in club! Т.е. Диско не понимает OLAP Catalog, по крайней мере native, ему ещё нужен доп. лэер - Active Catalog. И это не тоже самое, что EUL :-))) Disco for OLAP понимает, Disco реляционный - нет. Discoverer Catalog это репозиторий в котором хранятся отчеты (структура) для OLAP.
В EUL хранится и то и другое, а в случае OLAP - метаданные описания кубов лежат в OLAP каталоге, а структуры OLAP отчетов - в Discoverer Catalog. Согласен, запутаться можно легко. Active Catalog это другое.

Сергей.de D. Plus (Rel. & OLAP) - толстый веб клиент, наверняка напичкан явой, нужен для (М/Р)ОЛАПа, т.к понимает OLAP Catalog. Java Applet. Вернее их два. реляционный и OLAP. Репозитории для реляционного EUL, для OLAP - OLAP каталог и Discoverer Catalog.
Сергей.de D. EUL - Метадата лэеров лишних не бывает! :-) Что такое EUL я уже наверое раза три написал.

Сергей.de3) Дискаверер через EUL на ROLAP кубик: было замечено, что с ними мощно строить реляционные отчёты. Как я понял статические. Discoverer это средство динамических отчетов. Для статических есть другоесредство - Oracle Reports.

Сергей.deМеня больше интересует возможность динамической навигации в кубе, со всеми мыслимыми дриллами и слайсами-дайсами. Реально ли это - без программирования? Вопрос был уже отвечен, но как мне показалось, не совсем однозначно и непонятно для какого Диско (плюс, минус, десктоп)?Для всего. Для Desktop и Plus без огранчений, дла Viewer с ограничениями типа невозможно на лету перестроить структуру (добавить новое "измерение")
А всякие drill-ы - это сколько угодно.

Сергей.de 4) Что ROLAP в мире Оракла в принципе лучше и гибше будет я читал в презентации то-ли Риттмана то-ли Vlamis. MOLAP по большому счёту хорош в случае особенно продвинутых измерений и если нужно писать в куб. За что купил, за то и продаю :-)...Я сомневаюсь что Rittman так и сказал, так как нельзя сказать что какая то архитектура однозначно лучше на основе двух входных параметров.

Сергей.de 5) По поводу движка МОЛАП: верно ли утверждение, что внутренности у него старые, экспрессовские, изменили только форму хранения (за счёт этого параллелизация и партиционирование), интерфейсы доступа (OLAP_TABLE, OLAP Catalog )? Ну может ещё оптимировали под MP-системы, всё остальное без изменений. Он основан на Express, но переработан. Например добавлен совершенно новый тип композитов - compressed который в некоторых случаях на порядки уменьшает время загрузки и ускоряет отклик.
Ну и другие фичи тоже есть.

Сергей.de 6) Ещё раз по поводу CREATE DIMENSION. Можно ли подытожить, что эта конструкция мертва и единственное её применение - оптимизация запросов через QUERY REWRITE - осиливается движком оракла в новых версиях и без dimensions? Нет, Dimension как раз используется. Это "подсказка" оптимизатору, что вот в этой таблице существует иерархия, поэтому если я прошу срез по иерархии - он может по другому построить запрос к MVIEW вместо того чтобы полностью сканировать - агрегировать.

Сергей.de 7) OLAP Option и Oracle BI - это четыре разных человека, в смысле 2 отдельных пакета? OLAP Option - ОЛАП бэкенд, БИ - фронтэнд? OLAP опция это MOLAP сервер, OLAP каталог, API разные. Oracle BI это пакет продуктов, в который входят и Discoverer-ы во всех ипостасях и много чего еще. Тут было на эту тему. http://www.sql.ru/forum/actualthread.aspx?tid=148254#1207369

Сергей.deСколько стоит примерно BI?Минимальная возможная цена Oracle Business Intelligence - $4880 с техподдержкой но без налогов.
Могут быть скидки. OLAP опция сюда не входит.
Сергей.deРеально ли построить ROLAP-решение, не покупая ни опшн ни БИ? Имеется в виду законченное решение, с авто-подкачкой куба и простым репортингом (включая навигацию в кубе) и не привлекая при этом полк программистов? Максимум что программируется, это скрипты для авто-подкачки, всё остальное более-менее автоматом, чё-то вроде out-of-the-box как у MSAS?Реляционный Discoverer вам поможет. Подкачка смотря какая. Иногда можно построить репортинг и поверх OLTP, но конечно это не рекомендуется.
Если вам нужен OLAP - это сразу OLAP опция.

Сергей.de@Birkhoff
Я конечно понимаю, что тебе профессия и деловой интерес не позволяют вещать здесь открытм текстом, но согласись, что эта архитектура адназначна мастдай. Куча репозиториев, тулов всяких мало совместимых друг с другом, свежие, неопробованные компоненты и это в 2006 году :-/...Я не считаю что это мастдай. У Oracle есть куча продуктов. И OWB и Reports и Designer и Discoverer и OLAP и Mining и еще другие, которые меньше отношения имеют к BI, но вполне могут использоваться совместно (BAM, BPEL, TimesTen и т.д.). Хочешь сказать что было бы правильно все эти репозитории слить в один? Вопрос зачем? Кроме изящества картинки нет ни технологических, ни бизнес причин. Ок, я согласен с тобой, что репозитории Discoverer и OLAP было бы логично слить вместе, так как это почти про одно и тоже. Вполне возможно так когда нибудь и будет. Не зря же инструменты сейчас под одним зонтиком - Discoverer. Но если подумать, то это объединение мнимое. Если брать единый репозиторий для MOLAP и ROLAP - мы имеем единый API сверху, а внутри разные обработчики одних и тех же запросов к разным архитектурам и обработчики используют свои подрепозитарии. Только ты этого не видишь. Почему это не вызывает отторжения?

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

Вот, кстати, интересно как объединили Business Objects свой репозиторий с Crystal? И объединили ли? Я не знаю, поэтому и спрашиваю.

Сергей.de Не хочу спорить дальше, это моё мнение - после краткого знакомства с концептом. Можешь форварднуть этот тред в маркетинговый отдел, а лучше в отдел разработки, в качестве "гласа народа". Может они придумают что-нибудь стоящее, по крайней мере в будущем. Иначе мелкомягкие заберут у них и этот рынок :-(Не уверен, что этот тред прочитал до конца кто-то, кроме тебя и меня. :) А о побудительных мотивах Oracle делать что-то и как-то я знаю не более твоего. Могу только высказывать свое IMHO.
Ты попытался охватить снаскоку как единое целое гору продуктов, это не получилось, но сразу возникло отторжение. Концептуальная картинка у MS или BO скорее всего проще, наверное потому что и продуктов у них поменьше, чем у Oracle. (Говорю о BI)
И еще мне кажется, что ты никогда не занимался проектированием и поддержкой многокомпонентных систем. Хотя может я и ошибаюсь. Без обид.

Если хочешь обсудить что-то еще на тему архитектуры и проч. - можешь написать на мыло в профиле. Может и картинку найдем.

Сергей.deВызывает, но не такое, как куча лэеров между кубом и репорт тулом. По идее репозиторий должен быть один для М и Р ОЛАПа. Этот пересчёт на лету, как ты писал, метаданных из AW, не есть гут, это создёт некий оверхэд и на практике часто не работает. Скорее всего у Оракла снова не хватило времени, а скорее денег для _настоящей_ интеграции Экспресса.Репозиторий и так один. Но так как репозиторий находится в СУБД Oracle, а AW архитектурно другое, то что странного в том, что данные в единый репозиторий зачитываются из AW? Для ROLAP они там и хранятся, а для MOLAP читаются из AW, но для пользователя это по барабану. Да и даже для разработчика это не важно. Может расскажешь, что значит _настоящая_ интеграция в товем понимании? Layer-ы есть у всех, и если ты их не замечаешь, то это не значит что их нет. Ты весь топик задаешь вопросы о том в каком репозтории что лежит, и это же тебя пугает.

Сергей.deАльтернатива - это оставить всё как есть, несросшимся, несовместимым и предложить пользователям за свой счёт доработать решение. В каждом отдельном проэкте. Тысячекратно. В качестве компенсации можно купить акции Оракла, они-то деньги экономят, балансы нестыдно показать, shareholder value тысыть :-) Не поймал мысль.

Сергей.deНу у БО и мелкософта всё достаточно просто и более чем конкурнтноспособно.А я разве утверждал обратное? Я высказался только в том смысле, что у Оракла продуктов на эту тему скорее всего больше, чем у MS и BO вместе взятых.

Сергей.de ИМХО надо аркитектить с мозгами, с прицелом в будущее и стараться не покупать фирмы, чьи продукты явно не получится сделать родными. Золотые слова. Осталось только понять, что значит _явно_. И вообще какое отношение имеет к теме.


Сергей.de Сам с БО работал 5 лет назад последний раз. Правда чисто реляционально, без всяких ОЛАП провайдеров. Запомнилась простота архитектуры, разумное количество фрондэндов (2 - фэт и веб ака WebIntelligence, ещё Дизайнер и Админ), хорошо структурированный репозиторий (вроде как для обоих клиентов). Результат: на рынке рипортинга оракл со своими Диско отдыхает - ИМХО. Хотя у них такая фора была... Если отвлечься от ROLAP-MOLAP OWB и проч. Discoverer - это на 90% тоже самое что и BO. На 90 потому что навернякак в нем нет чего-то что есть в BO и наоборот. Поэтому пересечение не 100% Ты бы его поставил - посмотрел для начала.
Ну и чтобы быть точным - Disco это не рынок рипортинга . Рипортинг это Oracle Reports. К нему есть замечания, кроме наличия собственного репозитория?

Давай проясним еще вот что. Discoverer (реляционный) это не OLAP-ROLAP средство. И не для этого он проектировался. Discoverer это генератор SQL запросов. Наверное не надо объяснять, что SQL<>ROLAP?
В некотором подмножестве задач (если таблицы организованы в звезду, можно выделить измерения, факты и иерархии) Discoverer может функционировать как ROLAP-подобное средство. Но это только небольшая часть задач. Сказать что Discoverer это OLAP и поэтому у них должен быть общий репозиторий - это непонимание того, что это за продукты.

И второй момент. Я не понимаю откуда у тебя эта "репозиторофобия" Какая разница сколько у какого продукта репозиториев, если ты все равно с ними работаешь либо через API либо через инструменты. Какая тебе принципиальная разница куда лезет этот API и что там внутри происходит? Тебя ведь не раздражает, что внутри самой базы тоже можно выделить десятки репозиториев. Ну и что с того?


Сергей.deДа боже упаси. Ты действительно считаешь что многокомпонентность это крутая и необходимая фича? Я не об этом. А о том что разные компоненты нужно синхронизировать в процессе разработки и в процессе развития. (Кстати на эту тему высказался и Mosha в интервью, ссылка на которое есть в соседнем треде) И отдельные репозитории для малосвязаннх между собой компонентов позволяют систему развивать. Если у тебя 3 продукта, то единый репозиторий поддерживать легче. Если их 30, то это нереально. И незачем. Да и что такое единый репозиторий? Единая схема в которой свалены все таблицы от всех продуктов? А какая разница свалены ли они в одной схеме или в нескольких?

Сергей.deДа брось. Важно решение. Если оставаться в мире ОЛАПа, то здесь должно быть 3 звена: ETL, движок и фронтэнд. Которые (в идеале) слепо понимают друг друга. Всё остальное маркетинговый мусор для прикрытия изъянов Оракла, связанных с историей продуктов и тратой шальных денег. И вообще, Keep it simple... :-)
Вот о чем я тебе говорю весь топик, так это о том, что мы не в "мире ОЛАПа". OLAP это только часть этой всей линейки, и заострять какое то особое внимание на OLAP не вижу причин.

Sintetikа собственно что мешает использовать BI-тулзы от других производителей?
и все довольны, хранилище под ораклом (я не слышал чтобы MS бодро ворочал терабайтами) а просмотрщик например от микростретеджи/БОЯ думаю, что это нельзя сделать потому что у разных производителей по определению разные репозитории, а это по дефолту плохо :)

олапистРасскажите, пожалуйста, подробнее, в чем все-таки разница SQL<>ROLAP и какие задачи решаемые Discoverer нельзя решить в ROLAP-продуктах?
Заодно хочется узнать в чем существенное отличие этих двух от "рипортинга"

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

То есть если возьмете какую нибудь анкету, например на загранпаспорт - то это репортинг. В репортинге запрос и результаты его могут занимать не центральное место.

Конечно все тулзы современные сочетают в себе возможности просто выдать результаты запросов и чуть-чуть их причесать с точки зрения того, как это будет выглядеть на печати. Но обычно, эти возможности весьма умеренны. Поэтому существуют специализированные решения. Не зря же BO купил Crystal?

А что касается что нельзя сделать в ROLAP - если вы строите запрос над OLTP системой, и работаете по сути просто с набором связанных как-то таблиц, из которых нужна выборка типа: "выдать _список_ звонков в Аргентину за последний час" (никаких агрегаций), или "вывести номенклатуру товаров", то это никакого отношения к ROLAP не имеет, так как в ROLAP и вообще в OLAP обязательно должны быть определены измерения и показатели.

Sintetik Я думаю, что это нельзя сделать потому что у разных производителей по определению разные репозитории

если просто хранилище, то там вообще нет никаких репозиториев :-)Как это? А схема SYS? :)