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

Эти темы вроде как довольно часто обсуждаются на форумах...
Вас интересует, как именно спроектировать реляционное хранение?

В любом случае по переписке в форуме довольно сложно рисовать ER диаграмки ;-)

ER-диаграмки надо рисовать тем, кто пользуется ROLAP-продуктами, поскольку в учетных системах остатки и дебиторка на каждый день не хранятся, а налету эти показатели вычислять с помощью SQL-запросов очень медленно.

У Вас к счастью есть MOLAP-сервер. В основном все дискуссии на форумах сводились к тому, что самое оптимальное - это считать остатки и дебиторку как нарастающий итог от разности между приходами и расходами/платежами и отгрузками.

В MS AS правда, в отличие от того же известного Вам Cognos PowerPlay, реализовать это не очень просто, если объемы данных приличные - надо будет писать MDX и долго его оптимизировать параллельно с оптимизированием структуры куба... Но в любом случае Вам стоит копать в области проектирования OLAP-кубов, а не в области проектирования реляционной витрины данных (если делать предрасчет остатков и дебиторки в реляционной базе, то получится очень много записей в таблице фактов, и все это будет жутко медленно работать и обновляться).

To Torin:

Некогда теолигией заниматься.

До того, о чем я говорил 28 фев 04, в 11:03, я дошел эмпирическим путем, и сейчас эти подходы работают на объемах данных, которые у Вас будут через 5-7 лет.

Мне нужны конкретные примеры при реализации подобного на MS платформе (и витрины и кубы). Кто-то же это делал, раз пишут ? Хоть в картинках, хоть в скриптах, хоть в чем нибудь

Не знаю, какие методы решения Вашей задачи описаны в книжке Data Warehouse Toolkit (возможно там описан тот же самый подход с нарастающим итогом, о котором я упомянул выше, не думаю что можно придумать что-либо другое), но на всякий случай посоветую следующее:
Самый простой подход к расчету остатков с гарантированно высокой производительностью:
В таблице фактов для куба по остаткам должны быть следующие поля:
Дата документа
Идентификатор места хранения
Тип документа (приход/расход)
Идентификатор товара
Сумма и количество по документу
Вычисляемая колонка для суммы (если Тип документа = Приход тогда Сумма в противном случае Сумма * (-1))
Вычисляемая колонка для количества (если Тип документа = Приход тогда Количество в противном случае Количество * (-1))

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

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

Данный подход используют некоторые мои знакомые, у которых OLAP-сервер MS AS, а OLAP-клиент - Cognos PowerPlay.