Владимир, ваши доводы и восторги напоминают человека, который привык забивать молотком гвозди, а недавно обнаружил, что при определенных условиях, молоток новой модели может колоть и дрова. Криво, но иногда работает.
Это круто конечно, но, наверное не стоит забывать, что молоток, все-таки не заточен под рубку дров. Но, если у вас под рукой нет топора, то конечно, можно доказывать, что и молотка вполне хватит.
Отсюда ваши сомнения насчет Write-Back-ов, которые, к слову, в том же Oracle Express существовали наверное всегда и время отклика было равно времени записи в ячейку.
Что касается Real-Time warehousing-а, то я тут уже как-то распространялся о том, что нынче это модная тема везде, но для нормального некомпромиссного решения существуют специальные СУБД реального времени и специальные же системы отображения изменений в системе типа Business Activity Monitoring.
И слой пересылки и обработки сообщений, как верно заметил Гликоген, там действительно занимает важное место.

Владимир Иванов авторВладимир, ваши доводы и восторги напоминают человека, который привык забивать молотком гвозди, а недавно обнаружил, что при определенных условиях, молоток новой модели может колоть и дрова. Криво, но иногда работает.
Это круто конечно, но, наверное не стоит забывать, что молоток, все-таки не заточен под рубку дров. Но, если у вас под рукой нет топора, то конечно, можно доказывать, что и молотка вполне хватит.

Замечание достойное эксперта.
У меня правда другие представления об системе доказательств в экспертных оценках.Это называется не доказательство. Это называется аллегория.
Я поясню свою мысль. Дело в том, если вам нужно получить информацию о прохождении какого то события важного события, скажем проходждения какой-то большой проводки в 1С, вам не нужен для этого OLAP сервер. Достаточно поставить триггер, и обновить по событию табличку (ну или сделать Mat View в случае Oracle) Затем, с помощью любой реляционной смотрелки вы можете увидеть обновление этой таблички. Можно поставить рефреш каждые 5 секунд например.
Поскольку большинство пользователей MS AS работают с ним через Excel, то смотреть на табличку в базе может быть организационно сложно. А если вы используете какой нибудь BO или Discoverer - то это делается элементарно.
MS AS - замечательный сервер, и такие люди как Mosha работают над тем, чтобы добавить еще больше интересных фич в этот продукт. И это здорово. Пользователи от этого только выигрывают. И в данном случае эта фича позволяет в некоторых случаях получить все в одном флаконе. И OLAP и Real Time.
Но заголовок-то топика "Изменение концепции BI-решений с приходом MS AS 2005". Концепция это сильное слово. Концепция не меняется из-за появления какой то фичи, пускай и интересной. OLAP сервер останется OLAP сервером.

Вот вы говорите, что у вас время отклика составляет несколько секунд. Окей, это замечательно, но что это за данные, как часто они изменяются и т.д. и т.п.
Этой информации вы не приводите... Если происходит событие в 1С раз в минуту, и 1С является одним источником, то сделать такой Real-Time можно на чем угодно, без использования OLAP.

Владимир Иванов авторОтсюда ваши сомнения насчет Write-Back-ов, которые, к слову, в том же Oracle Express существовали наверное всегда и время отклика было равно времени записи в ячейку.

Могу только порадоваться за Oracle, но рассматривать его как инструмент при фактическом уходе с рынка я не могу.
Вопрос к Моше почему в MS AS такие проблемы сделать как в Oracle с отказом от переагрегирования всего и вся.Уход с рынка оставим на вашей совести, да я вас и не призываю использовать Oracle OLAP или еще что-то. Дело ваше. Разговор не об этом.
А насчет write-back в MS AS могу предположить, что ситуация аналогична ситуации, когда у вас есть ZIP файл с огромным текстовым файлом, а вам нужно в этом файле изменить один символ или вставить предложение. Для того чтобы это сделать - документ надо распаковать, изменить символ, а потом запаковать обратно. Очевидно, что это накладно. А то, что MS AS хорошо упаковывает данные - всем известно.

Владимир Иванов авторЧто касается Real-Time warehousing-а, то я тут уже как-то распространялся о том, что нынче это модная тема везде, но для нормального некомпромиссного решения существуют специальные СУБД реального времени и специальные же системы отображения изменений в системе типа Business Activity Monitoring.

Вам не кажется что это просто слова? Вы работали с этими СУБД "реального времени". For example?Если вы видели маршрутизатор CISCO, то с большой долей вероятности в нем стоит СУБД реального времени TimesTen.
Так что, скорее всего и вы с этими системами работали. А в чем проблемы? Что значит "просто слова"?

Владимир ИвановЯ несколько лет назад делал интеграцию БД Alcatel на Lotus Domino с MS SQL средствами интегратора DECS (часть LEI). Решения с 1С 7.7/8.0 вообще не проблема и т.д.
Пример DECS показывает, что интеграторы реального времени можно создать где угодно и для чего угодно. Вопрос в наличи технологий на создание интеграторов. И вероятно рынок таких интеграторов будет расти.Ну опять вы никаких цифр не приводите, ни что за объем данных, ни что за объем транзакций. Насчет того, что создать можно на чем угодно - опять же без цифр... Мне кажется у нас разное восприятие "реальности времени". Я согласен, что в случае проходждении скажем нескольких десятков транзакций в минуту в одной системе - подобный реал-тайм можно реализовать на коленке. А что делать если транзакций тысячи? И источников много? Какой тут OLAP в Real-Time? SQL сервер сам может не успеть вставить эти записи в базу, не то, что переслать в OLAP и проагрегировать.

Владимир Иванов авторИ слой пересылки и обработки сообщений, как верно заметил Гликоген, там действительно занимает важное место.

Это небольшая, но важная компонента RT-решения. Но я не вижу в чем абсолютизация смысла этой компоненты. Тем более что пользователь ее обычно не видит, он видит отчет, ну KPI.
Туда ли смотрите, товарищи? Или действительно просто слово модное зацепилось?Ну кому как. Разница в масштабах. См. опять мое высказываение насчет разного восприятия "реальности времени"

P.S. Извините, если первое сообщение прозвучало резковато.