To Вжик:

Что, все деятели по 1С не хотят выдавать секреты ???

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

Чем Вас не устраивает классический подход - когда остатки вычисляются на основе приходов и расходов с помощью функции нарастающего итога?

To Вжик:

Вот было бы круто создать куб из 200 миллионов записей. Может для прикола попробуете это сделать? Получится российский аналог теста T^3 :)

Хотя в реальной жизни это вряд ли будет нормально работать. Дело даже не в количестве записей - для продвинутых OLAP-серверов это приемлемый объем. Самая большая проблема - хранить и обновлять эту большую таблицу в РСУБД. Представьте, сколько записей нужно будет проапдейтить при каждом изменении задним числом - ведь изменятся же остатки на все последующие дни...

Поэтому лично мне нравится вычислять остатки на основе приходов/расходов.

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

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

Лично я привык пользоваться другим OLAP-сервером (Cognos PowerPlay), в котором заложены стандартные варианты решения классических задач, и поэтому там тяжело создать неоптимальную структуру куба, которая будет тормозить.

To Roxer:

Не расскажите по секрету во сколько это Вам обошлось(Cognos PowerPlay+все для него необходимое)?

Cognos PowerPlay - это пожалуй самый дешевый OLAP-сервер (дешевле чем MS AS), несмотря на то, что по функциональности и удобству внедрения/пользования с ним мало кто может сравниться. Минимальная конфигурация - PowerPlay User - стоит менее 1000$ и включает как серверную часть, так и 1 клиентское место для работы с готовым кубом (проведение анализа, создание отчетов). С помощью PPU можно создавать очень приличные по размеру кубы на скромном железе. Декларируется, что в куб можно закачать до 1 миллиарда записей и до 2 миллионов категорий (members).

Теперь о том, что необходимо для использования PPU:
Источниками данных для создания кубов являются запросы к реляционным БД формата MS Access или Cognos Impromptu, и/или плоские файлы разных форматов (в т.ч. CSV, ASC, XLS - списки или кросстаблицы, DBF, Paradox и нек. др.). Таким образом, если структура БД Вашей учетной системы не сложная, то самый дешевый вариант - использовать связку PPU + MS Access. Если же структура БД сложная - рекомендуется использовать модуль Impromptu, стоимость которого около 1000$. С помощью Impromptu создаются SQL-запросы (виртуальные вьюшки) к источникам данных визуальными средствами, и на основании полей этих запросов в PPU создаются измерения/уровни иерархии и показатели многомерных кубов.

Если захотите посмотреть внешний вид клиентского интерфейса PPU или заказать ознакомительную версию - заходите на мой сайт http://cognos.narod.ru

Я хочу заказать ознакомительную версию.
Как ???

Очень просто - отправьте запрос на адрес cognos@narod.ru .
Рекомендую вкратце рассказать о Ваших источниках данных (тип СУБД, объемы данных), а также указать, в каком городе Вы находитесь.

To Вжик:

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

Механизм заключается в использовании хранящихся в кубе агрегатов. Заранее просчитано, что в 2001-2002-2003 году/в 1-2-квартале/в январе-феврале... разница между приходами и расходами по группе-подгруппе... составляет N руб./шт.
Таким образом, количество арифметических операций по подсчету остатков сводится к минимуму: для группы надо сложить значения за январь, февраль, ... июнь, 1 июля, 2 июля, ... 16 июля. В этом и заключается операция определения нарастающего итога.

А агрегаты для calculated member храняться ???

Думаю на такие вопросы ответить могут только представители компании Cognos (это их коммерческая тайна). Я лишь могу сделать предположение на основе своего опыта: поскольку в моей практике я ни разу не встречал случая, когда вычисляемые категории (calculated members) в PowerPlay вычислялись медленно, видимо агрегаты для них хранятся. Единственный известный мне пример торможения в PowerPlay - это расчет типа Distinct Count в больших кубах на не очень сильных машинах с малым объемом оперативной памяти.

Вот у меня подозрения что в MS AS они не храняться

Если Ваше подозрение подкрепляется фактами, когда имеют место замедления при 100% загрузке процессора - то видимо такие агрегаты действительно не хранятся.

Не забывайте, что MS AS - это довольно молодой OLAP-сервер, и в нем еще многое не реализовано.

To Дядя Федор:

Другое дело, что MDX такой написать - подумать надо, но это час делов, имхо. Ну, полдня в худшем случае.

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

Задача не настолько сложна, чтобы менять из-за нее инструмент, при всем уважении к Юрию и Когносу :)

Безусловно, ради одной локальной и несложной задачи принимать такое стратегическое решение, как смена инструментария, не имеет смысла. Однако, когда Вы почувствуете, что простой OLAP для Вас недостаточен, и захотите перейти на следующую ступень - к технологии Business Intelligence - тогда Вы и перейдете с MS AS на Cognos :)