Можно, конечно использовать реляционную базу только для хранения данных (этот подход, насколько я понял использует Владимир Иванов).
В этом случае арихтиектура хранилища будет называться по теории hub-and-spoke или централизованное хранилище, основанное на зависимымых витринах данных. Несомненно, при этом Вы получите преимущества, которые даёт хранилище данных - консолидация из разных источников, поддержка историчности, возможность очистить данные во время их загрузки в хранилище, отсутствие дублирования и избыточности данных.
Понятно, что кубы, построенные на данных хранилища будут давать более корректные результаты (как с точки зрания качества данных, так и с точки зрения корректной обработки истории изменений).
В этом плане такую архитектуру можно рассматривать как первый шаг к нормальной аналитике.
Дальше можно будет добавить к аналитическим инструментам статистические пакеты, тулзы типа data mining. Дальше идёт closed-loop BI, active data warehousing. Но это далеко не сразу и далеко не у всех.


За всё это надо платить. Во-первых, Вам надо понимать, как правильно орагинизовать данные в хранилище с точки хрения состава таблиц, как организовать поддержку истории изменений, как генерировать суррогатные ключи. Надо также понимать кое-что в приёмах очистки данных (это отдельная очень сложная область), есть ещё управление метаданными.
Помимо этого построение хранилища данных - это не затея для одного человека, поскольку требует наличия знаний и опыта в нескольких областях. Соответственно, работать должна команда. Если есть команда, то нужно уметь ей управлять - возникает project management. Дальше, поскольку последовательность задач, которые нужно выполнить, чтобы построить и поддерживать хранилище, не является тривиальной, должна быть хорошая методология построения хранилища данных (набор документов, регламентирующих то, кто когда у куда должен идти, что и как делать, что должно быть на выходе и т.д.). Методологии на дороге не валяются. Чтение, например, Кимбала (The Data Warehouse Toolkit) может приблизить к пониманию того, что методология нужна. Однако сама книга не является методологией. Такие методологии являются ноу-хау компаний, которые специализируются на построении хранилищ данных. Есть ещё Red Book от компании IBM, которая тоже делает намёк на методологию построения ХД, советую почитать, если есть серьёзный интерес.
Если таковая методология отсутвтует у команды, которая строит хранилище данных, то вероятность построить неправильно довольно высока.
Естественно, надо правильно выбрать инструменты для решения всех задач построения хранилища - СУБД (самая критичная часть), средства ETL, CASE-средства, средства OLAP/Reporting, средства управления метаданными и т.д.
В общем, получается не за угол пописать сходить :)

Вот вам и подводные камни. Сорри, что так сумбурно.

По поводу построения хранилищ на платформе MOLAP, мне кажется, можно забыть. Проблема в масштабируемости, поддержке историчности, открытости. Многомерные базы масштабируются гораздо хуже реляционных (может быть, пока, но это факт), язык запросов SQL стандартизован, многомерные базы сами себе на уме. Все уже давно строят хранилища на реляционных БД.

Надеюсь, это поможет.

С уважением,
Константин Лисянский
http://lissianski.narod.ru

Юрий,

естественно, с большими хранилищами данных может справиться не каждая платформа. Я могу сказать за СУБД Teradata. На данный момент самое большое хранилище данных на Терадате работает на системе из порядка 300 узлов - это компания SBC (WalMart имеет второе по размеру хранилище после SBC). На данный момент можно собрать сервер из 512 узлов (узлы - это двух- или четырёхпроцессорные серверы). Масштабироваться ещё есть куда.

Вот краткая характеристика системы SBC:
Хранилище данных поддерживает более 140 приложений, обслуживающее более 10 000 пользователей в более, чем 16 компаниях группы SBC (Southwestern Bell Telephone Company, Pacific Bell, SBC Services, Inc., SBC Management Services, Inc. и др.)
Ежедневно выполняется 100 000 SQL-запросов.

Вот состояние в WalMart на весну 2002 года:
Общее дисковое пространство - свыше 270 ТБ
Более 45 000 пользователей
Более 1 500 одновременно работающих пользователей
Есть таблица, содержащая более, чем 70 миллиардов строк
Всего в хранилище более 5 000 таблиц
Более 100 000 запросов в день
В день грузится более 1,5 миллиарда записей в режиме непрерывной загрузки
Хранилище обслуживает более 40 приложений
Среднее время отклика на запрос менее 3 минут
Обслуживают это хозяйство 3 администратора


Сколько всё это стоит не знаю. Но, думаю, много - система огромная.
Но люди её содержат и развивают (начали давно - раньше 1990 года) - значит
приносит немаленькие деньги.


Надеюсь, сомнения в возможностях масштабирования сняты.


С уважением,
Константин Лисянский
http://lissianski.narod.ru