To Jimmy:

Существуют разные типы проектов по созданию ХД (когда есть один осточник данных, или несколько одинаковых источников данных, или несколько источников данных с рассинхронизированными справочниками). Также проекты по созданию ХД различаются в зависимости от выбранного аналитического инструментария (если ROLAP - то ХД спроектировать сложнее, чем при наличии MOLAP).

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

Приведите лучше описания Ваших проектов и поточнее сформулируйте, для чего Вам подобная статистика по проектам ХД?

Александр,

Объясните мне, чем проектирование многомерной модели для MOLAP отличается от проектирования многомерной модели для ROLAP.

Я имел в виду различие в проектировании реляционного ХД в зависимости от использования MOLAP или ROLAP как аналитической надстройки.
Если ХД делать ради ХД - то разницы разумеется нет. Но если мы хотим, чтобы пользователи могли получать отчеты и проводить анализ, для успешного функционирования ROLAP потребуется дополнительная работа (которую не надо делать для MOLAP) - создание и подкачка вспомогательных таблиц с агрегированными значениями, индексирование полей ХД, по которым будут строиться отчеты в ROLAP или накладываться фильтры и т.п.

Александр,

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

Вам приходилось решать эту задачу с помощью ROLAP?

To Александр, backfire:

думать как реализовать задачу получения остатков на каждый день
Вам приходилось решать эту задачу с помощью ROLAP?
А что тут такого удивительного?

Для примера рассмотрим остатки по товарам.
В целом все просто, но сложности начинаются тогда, когда велико произведение количества товаров на количество мест хранения на количество дней (или часов, если интересует динамика остатков с точностью до часа). Например, 30 тысяч товаров, 30 мест хранения и 1000 дней. Если перемножить эти три числа, получим 900 миллионов записей. Хранить эти записи в БД - малореально из-за большого объема, да и каждый документ по товародвижению, введенный задним числом, приведет к необходимости огромного пересчета остатков, что увеличивает нагрузку на реляционный сервер. Если не хранить заранее просчитанные остатки в БД - надо вычислять их налету. ROLAP конечно позволит это сделать, но работать это будет медленно.
Сталкивались ли вы с подобными ситуациями? Как я понимаю, оптимальный вариант для ROLAP - хранить остатки на начало каждого месяца, чтобы меньше вычислять налету, но это тоже вроде не должно быстро работать...

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