АналитикПомогите пожалуйста с проблемой:

У меня есть измерение Регион-Город-Точка.
Каждая точка посещается ежедневно, в ней отмечается наличие товара.
Мне нужно получить информацию по наличию товара в точке за месяц, год для города причем считать наличие только по последнему посещению точки.

Например:
Точка 1 посещалась 05.04.05 в ней было наличие 2
Точка 1 также посещалась 07.04.05 в ней было наличие 5
Точка 2 посещалась 08.04.05 в ней было наличие 6
Точка 3 посещалась 06.04.05 в ней было наличие 1
Точка 3 посещалась 08.04.05 в ней было наличие 5

Я хочу посмотреть информацию для Города 1, в который входят эти точки за месяц апрель:

Соответственно для города наличие считаем только по последним посещениям этой точки:
Точка 1 также посещалась 07.04.05 в ней было наличие 5
+
Точка 2 посещалась 08.04.05 в ней было наличие 6
+
Точка 3 посещалась 08.04.05 в ней было наличие 5
= 16

Для одного города считать не проблема, но когда к-во точек превышает 20000, тормоза ужасные.

Здоровеньки були!

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

в общем виде вы зотите получить ответ на вопрос как

остаток = F(время, точка).
где время - любой из членов иерархии Year.Quartal.Month.Tag;
точка - любой из членов иерархии Регион.Город.Точка;

Я бы вам посоветовал на уровне SQL базы (т.е. в хранилища данных завести 2 доп таблички.
а) остатки на начало какого либо периода (месяца, года, квартала).
в) движения остатков как делту до и после пересчета.

И задача отображения результатов в кубе сводится к "кубу остатков". Которому на этом форуме достаточно много дискуссий посвящено - не поленитесь вызвать поиск.

АналитикЯ согласен, что можно добавить пару табличек в SQL, но данные по остаткам в SQL у меня уже есть, зачем мне еще раз их дублировать в другие таблички, при этом увеличивая размер базы, а также время процессирования куба.

Но все таки если Вам не сложно обьясните что имеется ввиду - "в) движения остатков как делту до и после пересчета".

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

А под дельтой я понимаю следующее

Исходные данные:
Точка 1 посещалась 05.04.05 в ней было наличие 2
Точка 1 также посещалась 07.04.05 в ней было наличие 5
Точка 2 посещалась 08.04.05 в ней было наличие 6
Точка 3 посещалась 06.04.05 в ней было наличие 1
Точка 3 посещалась 08.04.05 в ней было наличие 5

Из нее получаем
Точка 1 посещалась 05.04.05 дельта 2
Точка 1 посещалась 07.04.05 дельта 3
Точка 2 посещалась 08.04.05 дельта 6
Точка 3 посещалась 06.04.05 дельта 1
Точка 3 посещалась 08.04.05 дельта 4

На SQL это можно оформить одним
INSERT ...
SELECT ...

АналитикРазмер таблицы фактов = 2000000 записей, которая с каждым днем увеличиваются на 300000 записей.

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

Я согласен, как вариант, такое решение проблемы исключать нельзя, но создав такую таблицу я тем самым потеряю информацию по всем остальным дням, а она мне тоже очень нужна. Может Вы еще что-нибудь сможете посоветовать?

вы наверное меня неправильно поняли.

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

Это вам понятно?

АналитикЧто Вы подразумеваете под словом приращение?

Разницу между текущим остатком и предыдущим остатком.

То как вы считаете, без сомнения, правильно, но вы не сможете получит "летающего" куба, ибо ваш алгоритм можно реализовать только в Cell Calculation, а это улитка по сравнению с запросом к предаггрегированным данным.