Всем доброго времени суток!

В процессе проектирования модели данных у меня возникли следующие вопросы.

Повлияет ли на производительность получения данных из SAP BW детализация данных в SAP BW?(т.е. детализация, с которой я буду размещать данные в BW).
Например, если я буду загружать данные в SAP BW на уровне позиций в документе не агрегируя их в SAP BW, то это повлияет на производительность получения этих данных из SAP BW?
Или производительность получения данных из SAP BW не зависит от детализации данных в SAP BW, а зависит от спроектированной модели данных, в которую данные загружаются?

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

На уровне позиций в документе данные у Вас уже есть в R/3. Зачем столько затрат, чтобы получить то же самое в BW?
Modeling - курс BW330
Performance & Administration - BW360

Дело в том, что на стороне R/3 проблематично выполнять хронологический анализ за большие периоды времени. В лучшем случае отчёт выполнится, в противном случае будит сгенерирована ошибка выполнения, т.е. времени выполнения не хватит. Поэтому анализировать данные за большие периоды следует выполнять на стороне BW.

Т.е. Вы видете, что R/3 не может адекватно сходу прочитать и обработать десятки-сотни миллионов записей в таблицах. Но уверены, что с этим за минуты справится BW исключительно за счет своей волшебной модели данных. Здравый смысл не протестует?

В BW у меня нет большого опыта работы, поэтому я и обратился с этим вопросом на форум за рекомендациями. Хотя знаю, что данные хранятся по разному в R/3 и в BW(многомерная модель данных). Знаю, что Инструмент SAP BW заточен для работы с большими массивами данных в отличии от R/3. Но на практики не знаю насколько это реально будит.

Вы хотите сказать, что загрузка не агрегированных данных в BW(т.е. на уровне позиций) приведёт к той же низкой производительности в получении данных из BW что и в R/3?

Не знаю, что хотел сказать своим постом господин Kubus, но он фигню какую-то написал. Да, BW заточена на анализ больших объемов данных. Да, выборки будут быстрее в BW.
Для ответа на ваш вопрос Вам следует изучить курсы, а перед этим вообще что такое есть OLAP и чем он отличается от OLTP. Например, на сайте olap.ru есть статьи по теоретической части. В саповских курсах вы найдете практическую часть - а вот почитать теорию надо по другим источникам.

Нет, загрузка будет на уровне позиций, и хранить их тоже можно и нужно (если отчеты потребуют) на уровне позиций. Но только этого недостаточно. Чудес не бывает: выигрыш в производительности отчетов отчетов Вы получите за счет агрегации (на стороне BW). Т.е. хитрость в том, что значительную часть укрупненных данных для отчетов Вы подготавливаете в BW заблаговременно. Это позволяет в момент формирования отчета уже не читать все эти миллионы записей, а читать гораздо меньше. Если пользователь все же захочет посмотреть детализацию до документа, то уже за конкретный небольшой отрезок времени, по конкретным БЕ, КЕ и т.п.

Я хотел сказать, что "анализ больших объемов данных" происходит не в момент формирования отчета, и BW без агрегации все равно что пельмени без мяса.

Вы написали



Что есть не совсем корректно, вследствие OLAP сущности BW. Так что да, с чем не справится R/3, с тем справится BW за считанные секунды-минуты при условии правильного моделирования данных.

Что касается одной и той же информации. В исходных системах и в BW присутствует абсолютно одна и та же информация. И что, теперь не строить хранилища? Нет, смысл в том, что одна-то она одна, но в BW она "разложена по полочкам" и аггрегирована.

Вот такой ответ был бы корректнее

Я думаю, что анализ имеющегося массива данных в BW(в инфопровайдере) происходит именно в момент выполнения отчёта согласно указанным входным критериям.

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

Имхо, корректно было бы не терять контекста. Автор четко очертил свою ситуацию: его интресовала производительность при том, что
.
Что Вы имеете сказать об этой предполагаемой BW-производительности в сравнении с R/3?

BW по любому будет жевать эти данные быстрее . а если еще применить чуток умения при проектировании, то вообще будет все зашибись

Детализацию нельзя рассматривать отдельно от модели, это один из важнейших ее параметров. Производительность при выполнении отчета сильно зависит от детализации исходных данных на момент построения отчета. Другое дело, что можно произвести частичную агрегацию предварительно:
1, на этапе загрузки в BW;
2, с помощью механизма т.н. агрегатов - периодическая подготовка агрегированных до нужного уровня данных.

Что касается сравнения производительности BW и R/3. Я правильно понимаю, в случае R/3 речь идет о написании ABAP-отчета? Считаю, что, зная структуру данных (тем более, имея возможность предварительной загрузки в свою структуру - как для BW), грамотный программист может написать отчет, который будет работать как минимум не медленнее, чем BW. Хотя бы из тех соображений, что BW не суть волшебная палочка, а написан на том же ABAPе. Все это при условии одинаковой степени агрегации исходных данных на момент построения отчета.

Если у вас в R/3 проблема только в том, что отчет не успевает сформироваться и пользователь отваливается по таймауту, можно как вариант сделать генерацию отчета и сохранение его в виде экстракта в фоновом режиме. А готовые экстракты уже выводить на экран.

Только из личного опыта по оборотно-сальдовым ведомостям:
MB5B в R/3 по Заводу за период 1 год - ни разу не удлось дождаться.
В BW оборотно-сальдовая ведомость за такой же период, с расшифровкой по группам видов движений (с использованием виртуальных показателей) ~ 5-10 минут (при этом львиная часть времени - это формирование отчета в Excel)...

Нет смысла даже спорить. Различие OLTP и OLAP начинается на уровне физической БД. В первом случае критично время выполнения одной транзакции, во втором выборки/обработки сотен тысяч записей. Это разные инструменты и для разных целей.