To Jimmy:

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

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

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

Александр,

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

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

Александр,

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

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

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

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

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

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

Александр,

Кстати BusinessObjects позволяет просто предать отчетную дату в запрос через пользовательский ввод.

Online-доступ - это одно из преимуществ ROLAP над MOLAP, и то о чем Вы говорите касательно BusinessObjects можно сделать в аналогичном продукте Cognos Impromptu/ReportNet.

Юрий, подумайте над описанной выше задачей и предложите решение, тогда честь Вам и хвала.
Анализируем дебиторскую/кредиторскую задолженность - фактически это остаток денег на счету. Есть измерение, характеризующее просроченность задолженности, например менее 3 дней, <30, 30-60, 60-90, > 90. Можно ли корректно связать остаток с этим измерением?

Я бы хотел уточнить формулировку этой задачи. Правильно ли я понимаю, что исходные данные могут быть такими:
ДатаДоговора,НомерДоговора,Клиент,Сумма,ТекущаяДата,Просрочка
12.05.2004,1,Иванов,100,26.05.2004,14
27.05.2004,2,Иванов,120,26.05.2004,-1
20.04.2004,15,Петров,70,26.05.2004,36
И в итоге первая строка попадет в группу <30, вторая - никуда не попадет, а третья - в группу 30-60 ?

Если так, то могу предложить такой вариант - продублировать этот массив данных N раз, например для каждого из 30 следующих дней, например:
12.05.2004,1,Иванов,100,27.05.2004,15
27.05.2004,2,Иванов,120,27.05.2004,0
20.04.2004,15,Петров,70,27.05.2004,37
и т.д.
То есть если у нас сейчас 100 тысяч таких открытых договоров, мы получим 3 миллиона записей (думаю не надо оьбъяснять как написать для этого вьюшку или создать виртуальную вьюшку в Impromptu).
После этого закачаем эти записи в куб (в нем будут измерения Клиент->Договор, Текущая дата, Возраст задолженности), и у нас будет возможность выбрать дату, на которую мы строим отчет. Каждый день в куб будем подкачивать данные (это отдельный вопрос, как обновлять куб - зависит от структуры хранения и правил изменения-добавления данных в учетную систему).

А на Ваше сообщение, разрешите не отвечать. Все это мусолилось уже не раз.

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

To backfire:

27.05.2004,2,Иванов,120,26.05.2004,-1
И в итоге первая строка попадет в группу <30, вторая - никуда не попадет
Jurii, u vas s matematikoi vse normalno?
Vtoraya popadet tozhe v pervuyu gruppu

Круглым отличником я был только в первом классе, а в таком возрасте отрицательные числа еще не проходят... :)
Я имел в виду, что если число отрицательное - это значит, что просрочки еще нет, и нам это для анализа не интересно (то есть имел в виду что первая группа - от 0 до 30).

To Александр:

/topic/83214&hl=%ee%f1%f2%e0%f2%ea%e8+ROLAP

Эта дискуссия не дала однозначного ответа на вопрос с расчетом остатков в ROLAP...

Простое перемножение - это слишком в лоб, думаю работать вряд ли будет. Считать-то в общем случае надо не за месяц, а так, чтобы динамику отследить по каждому дебитору/кредитору.

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

А курс высшей математики у вас наверное тоже не более 2 семестров был :-)

Я учился на экономическом факультете, у нас было 4 семестра вышки, будь она неладна :) Но была в математике одна супер интересная для меня тема, которая меня побудила плотно познакомиться с такими крутыми продуктами как VBA и Excel...

И какая же это была тема?

Это даже скорее была не тема, а задача - нахождение корней полиномиальных уравнений высоких степеней (например X^215 + X^212 + 100 = 0). Я 2 недели решал эту задачу, нашел решение. Потом оказалось, что г-н Лобачевский решил ее 100 лет назад, но как оказалось - совершенно другим, суперзапутанным способом ;)