Ну если совсем просто, на пальцах, очень грубо, то тогда так:

в web - варианте отчеты строятся с помощью web - дизайнера, с помощью которого создается нечто в виде шаблона с вызовами процедур чтения данных и форматирования результатов. Все это записывается в Хранилище в виде некоего документа. В результате после построения при вызове отчета ( url на этот самый "шаблон" ) на сервере производится генерация html - документа, который собственно вы видите в своем браузере.

ну вот грубо говоря так.

Если необхдоимо что то сделать такое, что нельзя сдедлать с помощью web - дизайнера, то дописывается необходимое как на html - тегах, так и на java и abap - все зависит от задачи.

Спасибо. Понял. BW-Excell - это просто "BW-Light")

И в общем-то, хранилище мало чем отличается от обычной SAP-системы, кроме своеорбазного способа хранения данных

Гость явно или хочет спровацировать флейм или одно из двух, хе-хе ))

Обычная R/3 - транзакционная(OLTP) и BW(OLAP) системы отличаются очень многим в принципе, по многим позициям, по своей сути и предназначнению.

Принцип как раз неважен. Важна конечная функциональность. BW имхо пришло на смену EIS?

Так и функциональность разная, если предназначение разное...

нельзя же сказать например что автомобильный завод почти тоже самое что НИИ автомобильной промышленности... ну да - там и там люди работают, здания квадратной формы из стекла и бетона, оба с транспортом связаны, но что-то всеравно не то %)

хорошо..тогда так. Как соотносятся BW и EIS? Имеет ли смысл внедрения последней при наличии первой? При том, что стандартный набор (FI/CO/MM/SD) уже в работе. Или это "подлежит конкретному обсуждению"?

Никогда не сталкивался с EIS, поэтому не скажу...

Точно так же как и BW и R3.

Аналогично. Имеет ли смысл внедрение BW при наличии R/3? Если ответите на этот вопрос, то все остальное станет понятным


Всегда надо смотреть конкретные задачи. Для чего внедряем BW, какие задачи оно должно решать, какой функционал и т.д.

Выше коллеги уже говорили, что BW - это принципиально другая система, нежели R/3. OLTP и OLAP построены на разных принципах и служат различным целям.

Если отвлечься от BW и R/3 , то необходимо ответить на 2 вопроса - чем меня не устраивает существующая OLTP система и что из этого мы хотим решить внедрением OLAP - системы и Хранилища данных. А до этого бессмыслено о чем либо рассуждать - надо/не надо, стоит/не стоит и т.д.

Ну на этот то вопрос ответить-то можно - BW позволит серъёзно разгрузить R/3, особенно - в перспективе. А с другой стороны - а будет ли востребована эта "перспектива"? Вот в чём вопрос . Необходимы критерии целесообразности. В общем-то, повторно, - спасибо - прояснилось кое-что. Да и почитал "в фоновом режиме" пока Осталось рассказать что "за офигенные деньги вы получаете офигенный аналитический инструмент, о котором можно было только мечтать 5 лет назад" ))

Видимо, многие из участвующих в обсуждении людей не видели EIS...
Я достаточно долго поработал и c EIS, и с BW, и вот что я хочу сказать (все IMHO, но готов отстаивать свою точку зрения конкретными доводами):
1. Ноги у BW действительно растут из EIS
2. Да, у BW, конечно, возможностей побольше, но: многие задачи по
сбору, обработке и анализу информации из различных источников прекрасно решаются средствами EIS без использования BW. Кое-что в EIS даже гораздо удобнее (например, гибкая загрузка из CSV и TXT-файлов).

Еще раз. Хранилище данных и OLTP - система - два разных продукта для различных целей. Никто не спорит о том, что в R/3 есть схожий с BW инструментарий для решения схожих задач. Можно еще и LIS припомнить, а так же и спецрегистры... То же в принципе похожи...
В принципе можно все сделать и на abap ...

Только что то мне подсказывает, что при больших объемах данных EIS быстренько загибается и говорит всем прощай

Давайте все же не будем смешивать различные технологии. R/3, не смотря на наличие инструментария, все же OLTP система. Ну как не крути. А BW - все же OLAP + Хранилище данных. И нельзя сравнивать их - а вот R/3 круче или BW круче. Давайте все же плясать от задач, которые надо решать.

Вы же не возьмете микроскоп чтобы заколотить гвоздь? Хотя теоретически им можно и не только гвозди забивать...

Ну тогда для начала нужно определиться, что мы понимаем под хранилищем данных и под технологией OLAP

Основные требования к хранилищам данных (Ральф Кимбалл):
- поддержка высокой скорости получения данных из хранилища;
- поддержка внутренней непротиворечивости данных;
- возможность получения и сравнения так называемых срезов данных (slice and dice);
- наличие удобных утилит просмотра данных в хранилище;
- полнота и достоверность хранимых данных;
- поддержка качественного процесса пополнения данных.

Основные требования к технологии OLAP (Эдгар Кодд):
- предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа;
- возможность осуществления любого логического и статистического анализа, характерного для данного приложения, и его сохранения в доступном для конечного пользователя виде;
- многопользовательский доступ к данным с поддержкой соответствующих механизмов блокировок и средств авторизованного доступа;
- многомерное концептуальное представление данных, включая полную поддержку для иерархий и множественных иерархий (это — ключевое требование OLAP);
- возможность обращаться к любой нужной информации независимо от ее объема и места хранения.

Теперь вопросы:

1. Отсутствие выполнения каких требований не позволяет Вам считать, что EC-EIS равно ХД + OLAP ?
2. Что именно Вам подсказывает, что "при больших объемах данных EIS быстренько загибается и говорит всем прощай"?

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

Ну честно слово, ну неужели не понятно, что скрещивание двух продуктов в одной системе не позволит осщуствить " предоставление пользователю результатов анализа за приемлемое время (обычно не более 5 с), пусть даже ценой менее детального анализа", так как при этом лопатиться огрмноый объем информации, а в это время тетя маня запустила офигенный расчет по закрытию периода с многоуровневым распределением затрат, а в параллель из АСУТП началось загрузка миллиона записей о движении каждой молекулы нефти по трубе... И вот эот самый разнесчастный аналитик будет тупо смотреть на экран и ждать, когда же выскочат на него заветные 3 цифры...

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

а EIS загнется именно потому, что во время анализа большого объема данных тети вали, мани и другие будут долбить новые данные и заводить документы, запускать отчеты и т.д. Да вам никаких мощностей не хватит. К тому же все таки применение EIS достаточно ограниченно, не так ли?

Я еще раз говорю - надо отталкиваться от задач, которые необходимо решать. И если это можно решить средствами r/3 без ущерба для других - слава богу (не забывая при этом дальнейшее развитие и масштабирование). Меньше геммороя всем - и заказчику и подрядчику. А вот если находятся умники, которые говорят, что я все в r\3 сделаю на абапе и нафиг мне нужно ваше апо/бв/срм и т.д. в любом случае - вот тогда становиться тоскливо. Надеюсь, что вы не относитесь к последним

О написал целый опус а в итоге повторил, то, что вы сказали в конце ) Значит консенсус достигнут? Пляшем от задач, которые надо решать? если надо забить маленький и средний гвоздь - причем вполне опредленной формы - то берем r\3 . Ну а если большие, хитровыгнутые, сложной конфигурации, да еще и с нарезочкой, да еще и целую серию за раз и при этом не отбить себе пальцы - то это BW