На недавней конференции по BI было выступление представителя компании Диасофт насчет внедрений хранилищ данных и аналитических систем в банках. Он упоминал, что в качестве аналитического инструментария использовались разные продукты (Cognos, BusinessObjects, Microstrategy). Также он говорил, что размеры ХД доходят до сотни гигабайт, а структура ХД, насколько я помню, была больше похожа на снежинку, чем на звезду...

В этой связи вопрос: не знаком ли кто-либо с примерами внедрений Microstrategy на таких объемах данных? Принимая во внимание что это не MOLAP-сервер, а продукт класса ROLAP/Query & Reporting, удается ли проводить с помощью Microstrategy интерактивный многомерный анализ, с такой же высокой скоростью отклика как например в Cognos PowerPlay или в MS AS, или просто в Банках не нужен анализ, а нужна стандартная отчетность, время генерации которой не так принципиально?

Александр,

Пока что речь идет о отчетности (но не стандартной) в последствии запланирован и многомерный анализ .

Я знаю несколько примеров внедрения продуктов класса Query & Reporting в банках, и в основном везде одна и та же ситуация: сначала решим задачу создания системы отчетности (этот этап тянется годами...), а потом перейдем к анализу :)
Как думаете все таки, можно ли использовать Microstrategy для многомерного анализа больших объемов данных, или придется использовать для задач анализа MOLAP-сервер другого производителя (например Cognos или Microsoft)?

To subquery:

Работали мы с Cognos и работаем.

Вот почему мне так приятно пользоваться услугами Вашего банка... :)

Из Вашего сообщения складывается впечатление, что, в отличие от Microstrategy он может легко "крутить" объемы в сотни гигабайт в одном кубе. Это миф. Проблем выше крыши.

Мой опыт говорит о том, что Cognos может легко крутить огромные массивы данных. А проблемы обычно решаются с помощью экспертов по Cognos. Что касается сотен гигабайт - то это зачастую размер распухших реляционных ХД. В Cognos не закачиваются все поля всех таблиц. Обычно я оцениваю размер исходных данных по двум параметрам - количество записей и количество категорий. Если не секрет, сколько записей в самых больших таблицах фактов Вашего ХД? И сколько у Вас категорий?

Один мягкий знак в русских наименованиях чего стоит. И не обойдешь никак!

В каком продукте/версии это встретилось и в каком месте (при создании высичляемого поля, или при наложении фильтра)?

Друго "впечатление", которое как-то складывается из Вашего сообщения, о том, что Вы предлагаете собирать в куб и крутить весь объем хранилища

Нет, этого я не предлагаю. Я обычно создаю кубы именно на основе витрин данных, для каждой предметной области отдельно, а затем просто настраиваю навигацию между витринами с помощью DrillThrough, а также вывожу ключевые показатели из нескольких витрин в панель управления руководителя (продукт Cognos Visualizer).

Объем витрины - на порядок меньше хранилища получается.

Это так, но даже если витрина по размеру не такая большая - с ней все равно надо использовать технологию многомерного OLAP (ROLAP-продукты не позволят проводить анализ с высокой скоростью отклика).

To АлександрФ:

Я думаю, что можно справиться средствами Microstrategy для многомерного анализа больших объемов . Использовать другого производителя я считаю не целесообразно с экономической точки зрения.

В моем понимании многомерный анализ нужен для следующего: аналитик или руководитель исследует определенный вопрос, для этого ему надо последовательно получить ответы на 10-15 небольших вопросов. Если на каждый ответ требуются мгновения (что реально при использовании многомерного OLAP) - то время зря не тратится. А если надо ждать по несколько минут - будет потеряна куча времени. Так что надо оценить, сколько стоит время...

Самое интересное что я действительно убедился что большие объемы (Гигабайты) можно обрабатывать и время отклика системы от секунд до нескольких минут . Естественно это достигается прежде всего следующими факторами:

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

To subquery:

Работали с продуктами PowerPlay, Impromptu, . Мягкий знак не воспринимается в заголовках и фильтрах. Причем очень странно, "воспринимаенимость" зависит от количества букв в слове.

Как я понимаю, эта проблема встретилась в Impromptu... Это известный баг :) Но в моих проектах такой проблемы не возникает, поскольку есть способы обхода этой проблемы (либо использовать при фильтрации не знак равенства, а функцию "contains", либо пользователю при задании фильтра показывать название, типа "Московская область", а реально в фильтр будет вставляться код/числовой id, есть и другие способы).

Продукт Impromptu вне основных рынков (Америка, Западная Европа) не является у Cognos флагманским (как PowerPlay), а выполняет вспомогательные задачи. Основной его плюс - как у системы отчетности - превосходное соотношение цена/качество, так как минимальная цена поставки полного объема Windows-функциональности - в несколько раз ниже чем у BusinessObjects, Actuate, и думаю он также в несколько раз дешевле чем Microstrategy, Brio, Crystal... Но вот несколько месяцев назад у Cognos вышел ReportNet, и это уже более сильный продукт для создания традиционных отчетов, произвольных запросов и доставки данных массовым пользователям.

Количество записей - более 3 млн. количество категорий - около ста с "меньшей" стороны.

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

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

Достаточно легко. И это легко проверить - Вы, как и любой другой человек, может заказать через сайт http://cognos.narod.ru бесплатную демонстрацию Cognos PowerPlay , в ходе которой можно будет поиграться с Вашими реальными объемами данных.

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

Наш общий знакомый (активный участник этого форума и эксперт в своей области) не проходил элементарного курса обучения по продуктам Cognos. Поэтому у него и были проблемы при внедрении продуктов Cognos в Вашем банке... Он обратился к эксперту по Cognos, но лишь за удаленной небольшой консультацией, не предоставив доступа к моделям и источникам данных :( Поэтому эксперт не смог увидеть проблемы лично и помочь их устранить...

Но говорим, насколько я понимаю, о другом. Насколько эффективно использовать продукты от Cognos. Правильно я понимаю?

Мы понимаем друг друга. При наличии минимальной квалификации человек с помощью Cognos может довольно быстро решать задачи конечных пользователей. При использовании либо чисто ROLAP, либо чисто MOLAP-инструментария от других производителей будет просто много ручной работы, и эффективность будет ниже.

Похоже, что Вы заняли максималистскую позицию. Скорость - превыше всего! Да. Скорость. Но в успехе проекта это, увы, не главное.

Я имел в виду, что у Cognos выше скорость, а по другим параметрам - примерное равенство. Я считаю что скорость - это очень важный фактор, ведь время - это деньги!

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

При внедрении других продуктов тоже требуется обучить своих специалистов и периодически обращаться за консультациями к экспертам.

в настоящее время даже выбирая автомобиль, покупатель, на самом деле, может выбитать не скорость или проходимость, а перстиж или ближайшую станцию ТО. А колесами они крутят - одинаково ... не более 60 в городской зоне. Я понятно выражаюсь?

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

А в банках и коммерческих компаниях подождать могут.

Это понятно. Может тогда не тратить деньги на компьютеры, а все считать на калькуляторе? :) Реально многие банки тратят большие деньги на аналитические системы, и я лишь предлагаю немного времени потратить на сравнительный анализ и выбор оптимального решения, чтобы и не переплачивать, и получить эффективный инструмент.

В заключении хочу сказать, что меня, как частное лицо, мало интересует, какая у Вас аналитическая система - главное чтобы мне оказывались качественные банковские услуги, на которые я пока не жалуюсь :)
Однако, если бы я был на Вашем месте, я бы использовал Microstrategy для генерации стандартной отчетности, а Cognos PowerPlay - для интерактивного многомерного анализа.

To Subquery:

Новогодние праздники потихоньку подходят к концу, так что можно продолжить нашу дискуссию :)

Изложенные Вами способы - не корректны для заголовков :-) в которых это тоже не работет... Да и методы не совсем пригодные в некоторых случаях.

У меня почему-то все работает нормально... Это конечно не такой важный вопрос, но если у кого будет интерес - можно пообщаться на языке конкретных пунктов меню и опций Impromptu.

Кому нужна Россия, чтобы с мягким знаком "копаться"? Никто и не будет!

К счастью не только в России есть такие нелатинские символы. Например, бывает такое, что немецкие пользователи обнаружили ошибку, ее исправляют, и это решает проблемы российских пользователей :) Россию в корпорации Cognos уважают, считают растущим рынком, высокопоставленные представители компании Cognos частенько приезжают к нам и принимают участие в мероприятиях (семинары, круглые столы и т.п.). Ну и стоит упомянуть, что бизнес компании Cognos на территории всей Восточной Европы курирует наш соотечественник (по имени Юрий :)

Надо же! Надо бы с ним поговорить... в чем же он тогда "эксперт"?

Он эксперт по проектированию хранилищ данных (изначально предпочитает решения "без кубов" :) Если хотите - могу Вас с ним познакомить. Хотя думаю что Вы хорошо знакомы...

...Они не дороги, и производительны. Про экспертов Cognos, к сожалению, такого не скажешь. А стандартные SQL сервера - знают многие.

А вот дворников в России еще больше, чем специалистов по SQL :)
Число экспертов по Cognos не такое маленькое, стоимость услуг - разная (московские специалисты подороже, региональные - подешевле). И найти эксперта по Cognos очень просто - достаточно отправить запрос через сайт http://cognos.narod.ru/AskCognosGuru.html .

Но "последний", на "последнем" (в смысле неграмотный на MSTR) иногда может сделать то, что продается и используется (см. выше)

Существует обратная сторона медали:
Поскольку Microstrategy создает отчеты на основе прямых запросов к реляционной БД, то есть большой риск, что неопытный специалист завалит сложным запросом сервер РСУБД... При использовании Cognos такого риска нет, так как запросы идут к многомерному кубу.

выяснить, почему это два "умных" ;-) человека, смотря на одно и тоже, видят разное. Парадокс, не правда ли? Вероятно, смотрят с разных точек.

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

Я делаю проекты и общаюсь с заказчиком. Считаю, что с MSTR меньше проблем.

Если не секрет, Вы являетесь сотрудником Альфабанка, или Вы принимаете участие в проекте для Альфабанка, представляя другую компанию, и для удобства пользуетесь их почтовым сервером (alfabank.ru)?

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

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

В свете состоявшегося приезда вицепризедента (европейского) MSTR в Россию (о котором немного наслышан), могу доложить, что Россия им интересна и они готовы, не смотря на ее место в мировом сообществе ;-), с пониманием относиться к запросам представителей "грубого и сильного народа" (который, почему-то всегда все обижают).

Речь вицепрезидента MSTR лично для меня была очень интересной, он прекрасный оратор. Но вот только очень большая доля присутствующих на семинаре не знала достаточно хорошо английский язык... Выступление представителя Cognos было на русском языке. А насчет того что Россия для компании Cognos интересна - см. выше.

To Jimmy:

Самое большое измерение - 120000 записей
Самая большая таблица фактов - 11.5 млн записей (11500000) пока(!)
Ожидется рост до 35 млн
Отчеты - MicroStrategy 7i
Время отклика 1-10 мин.
Нормально?

Как эксперт по СУБД и SQL - Вы безусловно заслуживаете уважения. Но вот только будет не очень хорошо, если кто-нибудь из конечных пользователей Вашей компании через некоторое время узнает, что технология многомерного OLAP позволяет снизить отклик до 0.1 - 5 секунд. Тогда этот пользователь очень расстроится, что его своевременно не поставили об этом в известность... (это я привожу типичный пример реакции конечных пользователей разного ранга - от аналитиков до руководителей высокого уровня, после того, как они в первый раз видят демонстрацию многомерного анализа в Cognos PowerPlay).

To Константин:

Юрий, такой риск есть, скорее, при использовании Cognos Impromptu (который, всё-таки делает запросы не к многомерному кубу, а к реляционной СУБД).

Impromptu к реляционной СУБД обращается по минимуму, на разовой основе (обычно ночью), когда куб генерируется или обновляется, и далее работа идет только внутри куба. А в Microstrategy приходится те же самые записи обрабатывать при каждом новом запросе каждого пользователя (кэширование помогает, но общая картина от этого не сильно меняется).

Поделитесь, пожалуйста, как с этим обстоят дела в продуктах PowerPlay и Impromptu.

Что касается Impromptu (если например нам не хватает фунуциональности кубов), то в нем, как и в MSTR, можно указать ряд ограничений для каждой группы пользователей:
1) На сортировку по неиндексированным полям
2) На использование Outer Joins
3) На использование Select Distinct
4) На кортезианское произведение (выбор полей из несвязанных таблиц)
5) Максимальное количество символов для больших текстовых полей
6) Количество таблиц, из которых выбираются поля для отчета
7) Количество строк, которые возвращает запрос
8) Длительность выполнения запроса в минутах
9) Редактирование SQL-запроса, созданного визуальными средствами
и др.

в своё время возникали проблемы, когда пользователи пытались 10 тысяч листовых категорий затащить в отчёт PowerPlay

Иногда (к счастью не очень часто) встречаются задачи, для которых в кубе нет агрегированных значений, и приходится выполнять большое число вычислительных операций налету. В таком случае, в зависимости от архитектуры решения, можно нагружать либо центральный сервер, либо клиентские машины пользователей. Эта ситуация актуальна не только для PowerPlay, но и для MS AS, Oracle Express и т.п. В OLAP-клиенте Cognos PowerPlay есть опция, которая позволяет не делать запрос к кубу автоматически (а делать это только по требованию пользователя). То есть сначала мы перетаскиваем в область строк 10 тысяч листьев, потом определяем, что будет в колонках, накладываем нужные фильтры, настраиваем например параметры ранжирования, и только после этого запускаем обращение к кубу.
Мне встречались задачи, когда в измерении было порядка 1 миллиона листьев. В таких случаях я делал разбиение куба на партиции на основе этого измерения, и все работало быстро.

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

Это радует :) Хотя все же 1 день курса обучения у квалифицированного эксперта/преподавателя зачастую более ценен, чем 1 год самообучения ...

To Jimmy:

Знаете, демонстрация - вещь особая.
Я на демонтсрации MicroStrategy могу показать не меньшую производительность, а то и большую :0))

Я имею в виду такую демонстрацию, когда в течение пары часов происходит подключение к базе данных, создается небольшой каталог метаданных, на основе него создается запрос, проектируется аналитическая модель, генерируется куб и далее присутствующим показываются отчеты на как минимум нескольких миллионах записей. На таком объеме данных я сомневаюсь, что ROLAP покажет производительность, сопоставимую с многомерным OLAP...

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

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

если бы не количество показателей, около 3000 в нашем проекте

А вот это интересно... Слабо себе представляю 3000 показателей. Каждый из них вычисляется по отдельному алгоритму и имеет разную природу?

железо" у пользователей системы не самое крутое, т.е. на уровне PIII800/PIV1000, 128-256М. Проблема? Отнюдь.

Я тоже считаю, что такая конфигурация - вполне приемлема.

Просто используем тонкого клиента (читай MSIE) - и получаем функционал, сравнимый с толстым клиентом, который требует "железо" существенно мощнее, чем описано выше.

Для тонкого клиента можно и более слабые компы использовать. А для толстого клиента Cognos PowerPlaу тоже не требуется мощное железо, поскольку операция визуализации небольшого числа заранее просчитанных агрегатов достаточно проста.

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

А как насчет "железа" для многомерного OLAP (Cognos) с временем отклика 0.5 - 1 сек?
Ну и ЛВС - не 1G случайно?
И какой размер (Gb) будет иметь многомерная витрина (куб?), которая в РСУБД занимает около 10G (пока), с параметрами, указанными в моем предыдущем посте?

Существуют стереотипы, возникшие в результате использования таких продуктов как Oracle Express, что OLAP-куб по размеру больше, чем источник данных...
Для OLAP-сервера Cognos PowerPlay требования к железу минимальны, поскольку высоко качество OLAP-движка. Как то я для смеха на 486 компе с процессором DX2-80 и с 16 мегабайтами оперативки сгенерировал многомерный куб, и крутился он вполне быстро...
Приведу примеры из практики:
1) Схема - "созвездие";
Измерений - 14 (некоторые с иерархиями);
Показателей - 16;
Самое большое измерение - 800 тысяч записей;
Самая большая таблица фактов - 16 млн записей;
Размер куба - 900 мегабайт.
2) Схема - "созвездие";
Измерений - 10 (некоторые с несбалансированными иерархиями);
Показателей - 12;
Самое большое измерение - 40 тысяч записей;
Самая большая таблица фактов - 90 млн записей;
Размер куба - 1.1 Гигабайта (1100 мегабайт).
В обоих случаях ЛВС - 100-мегабитная, клиентские компьютеры - Pentium 2-3, 128-256 мегабайт оперативной памяти. OLAP-сервер - Pentium 3, 256-512 мегабайт оперативной памяти.
И в обоих случаях большинство запросов выполнялось со скоростью многомерного OLAP (0.1 -5 секунд на запрос). Был правда в первом примере один сложный показатель, не опирающийся на агрегаты, и при его отображении в некоторых отчетах требовалось время на разогрев 5-6 минут. Но после первого запроса следующие, благодаря кэшированию, доходили до среднеОЛАПовской скорости.

To Torin:

MSTR действительно интересный продукт, но в целом присуствующие не должны сравнивать его с Cognos.

Ну почему бы не сравнить, если продукты вместе фигурируют в известных рейтингах? У Cognos линейка продуктов охватывает более широкий спектр технологий/типов задач за счет сильного OLAP-решения, системы бюджетирования/финансового планирования и т.п. MSTR сильно в области репортинга, но у Cognos тоже есть репортинг...

Если расматривать проблему превентивности отчет или анализ, считаю, что нет смысла в первую очередь ставить на анализ - ни один нормальный менеджер не сможет целый день в темпе вальса требовать driilUp-drillDown с поворотом по оси и накладыванием срезов.

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

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

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

В этом смысле MSTR тоже не промах - имеет на борту кроме прочего MDX connector, который "притворяется" MS Olap сервером. !

В случае использования MSTR + MS AS, имеет место некоторый зоопарк, при котором сильные стороны MSTR по созданию SQL-запросов визуальными средствами не смогут быть использованы для проектирования кубов в MS AS. Поэтому аналогичную связку Impromptu + PowerPlay я считаю более удачной архитектурой.

Cognos, конечно, интригует со своим Report.NET, Но доступной версии для тест драйва нет

Так уж совпало, что когда Вы только познакомились с аналитическими системами и начали Выбирать среди них лучшую, компания Cognos проводила громкую рекламную кампанию ReportNet (или может тот партнер Cognos, с которым Вы в первый раз говорили на тему Cognos, считает, что ReportNet - это главный продукт компании Cognos...). Это продукт интересный, но я бы не забывал и о других продуктах, которые за много лет использования в разных компаниях бывшего СССР проверены временем...

Рекомендую при выборе аналитического продукта не забывать о следующих подводных камнях, с которыми Вы рискуете столкнуться, и учитывая которые многие компании выбрали для себя PowerPlay и другие продукты Cognos:
1) Далеко не все продукты поддерживают несбалансированные иерархии (это важно для поддержки Вашей номенклатуры товаров, классификация которой наверняка является несбалансированной иерархией);
2) Ваши учетные системы наверняка не хранят складские остатки на каждый день. Вычислять их в хранилище данных - малореально при Вашем количестве складов/филиалов, номенклатурных позиций и партионном учете, а вычислять их налету в продукте класса Query & Reporting - просто нереально, так как это будет слишком медленно;
3) Многие интересные показатели более удобно вычислять на основе многомерных запросов, а не на основе SQL-запросов, хотя бывают и обратные случаи...;
4) На стоимость проекта влияет не только стоимость лицензий на продукты, но и стоимость железа (например, центральный сервер) и стоимость разработки хранилища данных, которое требуется для продуктов класса Query & Reporting;
5) При получении отчетов на основе прямых SQL-запросов Вы привязываетесь к хранилищу данных (нужно иметь постоянный канал связи), и нельзя например проводить анализ/строить отчеты на локальном ноутбуке (компактный многомерный куб можно держать на ноутбуке, но хранилище данных - малореально).

To Birkhoff:

Что за внезапный наезд вбок? :) Вроде сравнивали MSTR и Cognos?
Такой стереотип может сложиться скорее у тех, кто с Express не работал.
Вообще, что за дурацкая постановка вопроса: "что больше, источник или куб"?

Это не наезд :) Вопрос был в том, насколько мощным должно быть железо для создания и работы с OLAP-кубами. Ответ на этот вопрос зависит от того, какой OLAP-продукт использовать. В интернете практически каждый из посетителей этого форума читал, что многомерный куб во много раз больше, чем источник, и я думаю, что автор этого заявления был знаком только с Oracle Express... Если источник данных имеет размер 10 гигабайт, и OLAP-куб будет терабайтным, то для куба потребуется очень дорогое железо. Я же привел примеры из жизни, которые показывают, что кубики у Cognos компактные и легко будут жить на слабеньком и недорогом офисном компьютере.
Если Вы считаете, что Express силен своей компактностью и низкой требовательностью к железу - тоже приведите примеры из жизни.

To Jimmy:

Так! А уважаемый г-н Jurii сам, своими руками, пробовал работать с MSTR?
И какой версии?
И какие задачи решал?

Безусловно мой опыт и знания в области Microstrategy - ограниченные. Мне немного показывали этот продукт несколько месяцев назад в компании, которая продвигает несколько BI-продуктов, рассказывали о некоторых слабостях MSTR, которые я по этическим соображениям не упоминаю. Я общался с несколькими экспертами по MSTR на тему того, появился ли реально в ее последней версии многомерный OLAP или нет, и общее мнение было таково, что MSTR - это все же ROLAP. Также я слежу за дискуссиями на этом форуме.
Имея практический опыт работы с BusinessObjects, Actuate, Brio (которые во многом похожи на MSTR), и используя скудные знания о MSTR, я могу делать выводы в отношении MSTR. Если Вы считаете, что я в чем-то заблуждаюсь - приводите аргументы. В подобных дискуссиях и рождается истина.

Возвращаясь к задаче, которая актуальна для г-на Torinа: Вы считаете, что MSTR может позволить легко крутить в разных разрезах 5 миллионов записей?