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

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

Например:
Точка 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, а это улитка по сравнению с запросом к предаггрегированным данным.

АналитикАу

Мы, поди, не в лесу будем.

Вы поняли какие дельты (приращениях) я имел ввиду?

Если да, то является ли вашей текущей проблемой заполнение таблицы дельтами?

p.s. Если есть желание то ICQ 61-168-970

Юрий, ваше сообщение, как неэтичное, удалено

АналитикНа сколько я понял, конкретный ответ получить я не смогу

Что конкретно вам не ясно тут

Юра, вы можете писать в "просто треп" и отпускать там шуточки, пока пальцы в кровь не сотрутся. Здесь же люди общаются по делу. А ваши примеры явно не в тему.

Jurii2 backfire:

Здесь же люди общаются по делу. А ваши примеры явно не в тему.

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

P.S. Если у Вас есть возможность отправить мне по почте мое сообщение, которое Вы удалили - сделайте это, чтобы я не тратил лишнее время на его переписывание.

Юра, вы прекрасно понимаете, ваше сообщение было расценено мною как не этичное не за цифры и математические действия а за пример на котором вы эти цифры строили.

Дальнейшие на тему удаленного постинга считаю пустой тратой времени и ресурса клавиатуры.

А Вам Юра стоит поучится этикету письменного общения, в том числе, когда вы обращаетесь к кому то с просьбой. Или ваш P.S. ошибочно расценен мною как просьба, а на самом деле вы даете мне указание что то сделать?

у меня нет опыта в создании дельт

Прежде всего я вам посоветую хороший учебник по вычмату.
Затем и творения Кимбала о DWH.
А если чуствуете слабину в SQL, то Джой Целко то что надо.

проблема в том что пересчитать суммы на узлах занимает очень много времени. Узлами в моей задаче являются уровни: Город, Регион, Страна.

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

Одним словом. Физическая мера должна быть суммируемой по любой координате. А Ваша мера "остаток" таковой не является. Вот вы и спускаетесь до вычислений на листовых уровнях, что пагубно сказывается на производительности.

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

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

что то в этом роде Sum(PeriodsToDate(Time.[(All)], Time.CuttentMember)).

Советую вам почитать эту статейку Ричарда Ткачука (кстати одного из авторов AS)
Inventory Management Calculations in SQL Server Analysis Services 2005

Не пугайтесь, что в заголовке стоит 2005. Львиная доля излоденного применима к AS2K.

АналитикУ меня есть таблица в SQL с полями Точка, Дата, Остаток, каким образом мне написать запрос, что бы получить дельты ?

форуме по SQL вам наверняка напишут что-то более оптимальное, но как первое приближение.

Dmitry Biryukovещё как вариант можно в таблицу фактов добавить записей для каждого дня
тогда надо написать Custom Rollup формулу для измерения время Time.CurrentMember.LastChild и всё будет ОК

м что же покажет Time.CurrentMember.LastChild для 2005.04, если остатки занесены только до 2005.04.20, а для 2005.04.30 в таблице фактов остатков пусто? А хочется видеть текущие остатки.

Позвольте вопрос. А вы храните остаки на каждый день?

Все горазло проще, ни надо никаких искусивенных записей, "левых" измерений и т.п. просто надо брать не просто последнего child, а последнего непустого child (без NECJ и бубна конечно не обойтись)