Road Runner - место Вам уважаемый только в руководителях предприятия лично контролируещему внедрение на MS AS. Суперзубр по BW никогда не получиться, брасайте это гнилое занятие

Лично я бы наверное, так не реализовывал.

Но пример есть. )).

Хранится сальдо на каждый день по всем счетам.

И можно вертеть датами как угодно.

Ответить на вопрос про то как сделать в MS 2005 могут на форуме www.sql.ru в разделе OLAP
что нового дает 2005 в отличии от 2000 изложено в статье:
http://www.realcoding.net/article/view/ ... 5252c9aebb

Книга на русском языке только что вышла
http://bhv.ru/books/full_contents.php?id=179239
стоит на books.ru 419 р. Английский вариант на озоне 3800р.

Спасибо, нашел в принципе что искал про Inventory Management.
В общем: средствами MDX все написать можно, только в SAP BW уже давно есть встроенные механизмы, реализовывающие то же самое. +1 уровень гемороя для разработчиков (зато ему можно будет неслабо потешить свое самолюбие потом)

Вывод: плясать уже можно, но только с большим бубном.

Да нет никакого геморроя, sap использует mdx в sem , например, для чтения значения показателей из запросов и т.п. Вы легко можете использовать mdx в своих аналитических приложениях

NW 2004s

Интересно было бы посмотреть на работу этого процессора при необходимости проанализировать пару миллионов строк реальных данных из плоского файла. Все же не все так могут.



Может я не совсем еще глубоко в теме, но мне казалось, что хитрое форматирование, без применения vba, недоступно и в BEx Analyzer. А формаировать с помощью VBA стандартную сводную таблицу, как мне кажется, не должно быть сложнее, но даже наоборот.


А здесь, извините, вообще внедрение ОЛАП выглядит не очень обоснованным. Потому что, если отчетов пара-трока десятков, то гораздо проще и быстрее сделать их на ABAP в R3. И форматирование - сколь угодно хитрое. На мой взгляд особые плюсы от внедрения ОЛАП системы заключаются именно в том, что пользователь может почти произвольно (насколько предусмотрено хранилищем) составлять для себя отчеты. Причем отрабатывать они должны бытро.


Ну так оно и должно быть, имхо - ОЛАП внедряется ради одного - трех людей, которые и будут заниматься реальной аналитикой плюс, "до кучи", "если уж есть хранилище", достраиваются отчеты для тех, кому надо только "кнопку нажать". Если же паур юзеров нет вообще, то проще сделать набор плоских отчетов установленной формы.


На данный момент, мне кажется, не получится ничего особо мощного. Главным образом потому, что MDX - штука напрочь клиентская и потому к ней подходить надо очень осторожно. Мойша вроде бы обещал в 2005 сервере перенести большую его часть все же на сервер, не знаю, что из этого получилось.


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


А можно и не разыскать. А уж если вндрение "на з"...



Ну я не думаю, что в 2005 стало все хуже, чем в 2000.


Сначала я хотел было поставить у себя AS и проверить\вспомнить как это там делается, но понял, что времени у меня на это категорически не хватает. Тем не менее - даже если нельзя это сделать в одном кубе, то можно сделать в разных и объединить их в мультикубе. Тогда, конечно, погружение до фактов несколько косячило, но по последним новостям, вроде бы как пофиксили это.


Да все такие штуки вообще могут реализовываться как угодно - через MDX. Вообще вплоть до написания (чего я лично не делал, не было необходимости) пользовательских roll-up-ов (если правильно помню - пользователь может определить как именно будет расчитываться результат для следующего\предыдущего уровня иерархии).

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

Тот, кто так жарко отстаивает MS SQL и говорит о превосходстве его над BW по всем параметрам, да еще при этом признавая отсутствие квалификации по BW, не станет хорошим специалистом, только время свое потратит впустую и фирме прибыли принесет меньше, чем стажер-недаучка, но энтузиаст.
Кто знает, может посты Ваши регулярно читает руководство и думает "пора искать нового специалиста"

Не по всем - только по скорости, гибкости и удобству клиента(ов). Да и не так уж жарко.


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


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


Ах Вы в "этом" смысле. Остается только надеяться, что мое руководство о моей квалификации осведомлено, и она (квалификация) не является для него чем-то мутным и темным и не станет для него сюрпризом.

Тем не менее, когда я спрашивал про причины Вашего поста, то имел ввиду вовсе не основания или доказательства. Интересны просто Ваши мотивы, т.е. для чего, в рамках темы этой ветки, какую цель преследует Ваш пост? Идет ведь разговор не о моей проф. пригодности, а о том, какая OLAP система будет лучше для автора темы, Ваша же позиция, хотя и угадываема, но как-то неаргументированна. Можете развить ее описание, именно вот в конструктивном направлении. Ваш сарказм в отношении моей квалификации заставляет предположить, что уж Вы-то наверняка сможете написать аргументированные плюсы SAP BW в целом и BEx в частности.