RecoilmeНе подскажете с какого боку подойти к решению такой задачи:
есть Год/Месяц/День, товар, кол(Qty) (+ и -)
Надо расчитать процент наличия товара на полке за месяц....

Т.е. типа расчитать остатки на каждый день в заданном измерении, например, месяц, выбрать количество записей когда рассчитанный Qty > 0 и соотнести с количеством дней в месяце...

Как бы так извратиться???? Очень не хочется на SQL|Axapta кодить.... точнее на аксапта уже закодена такая хрень, но работает очень долго хочется в кубике/рубике....

1. А что такое % наличия товара на полке? Как это можно интерпретировать? [Количество Дней когда остаток > 0]/[Количество Дней]*100?

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

Recoilme
Меня совсем прёт, или г-н backfire сейчас черкнет длинный непонятный текст который можно впендюрить в куб и поиметь счастье??? :)

Я не шаман, шаман сидит на другом берегу Большого Пруда.

Вы про кубик то подробнее расскажите. Что в таблице фактов? Голые движения? Начальные остатки тоже как движения? Или есть отдельно остатки на начала месяцев (дней, кварталов, лет - нужное подчеркнуть)

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

max_spbtiМона и так, только при выборе нескольких элементов измерения [Дата] неработает

IIf(ISLeaf([Номенклатура]) and IsLeaf([Склад]),IIF(isleaf([Дата]),
IIF([Measures].[Остаток]>0,1,null),Sum([Дата].Children)),null)

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

1. Должны ли выбранные периоды быть смежными или нет
2. Что такое начальный и конечный остаток.
3. Насколько просядет перформанс по сравнению с широкоупотребимыми формулами, если все таки такую формулку сможем создать.

Dmitry Biryukovдля смежных периодов, вроде бы уже придумали формулу
http://spaces.msn.com/members/cwebbbi/Blog/cns!1pi7ETChsJ1un_2s41jm9Iyg!113.entry

начальный остаток (если мы говорим о днях) это остаток на начало первого дня периода = остаток на конец дня, который идёт перед первым днём в периоде
аналогично конечный остаток это остаток на конец последнего дня периода = остаток на начало дня, который идёт первым после последнего дня в периоде

или на языке MDX (если выбран один элемент измерения Date)

начальный -

конечный

как в оборотке - начальный+приход-расход=конечный

третий вопрос - таки да. имхо, надо из приложения генерить MDX, в зависимости от multiselect или singleselect измерения data.

тогда при singleselect получим не меньшую производительность, а при multiselect, как говорится, сами же просили...

Дмитрий, простите за наивеый вопрос, правильно ли я понял, что
под Date.Levels(THE_LOWEST_LEVEL_NUMBER) вы имелли ввиду

Date.Levels.Item(Date.Levels.Count - 1) или THE_LOWEST_LEVEL_NUMBER недокументированная фича в MDX? (В чем я глубоко сомневаюсь)

з.ы. Позвольте полюбопытствовать. В свободное от МДХ время вы пишете на Басике какой то масти?

Кстати о птичках (PrevMember). Тут намедни в форуме был разговор в котором Моша признался о существовании бага в PrevMember, NextMember etc. Так что поосторожней с ними.

RecoilmeЗадача:
Расчитать возможные продажи товара при условии постоянного наличия товара

В рамках задачи предлагается решить следующие подзадачи:
1. Расчет количества дней, когда товар был в наличии (остаток на конец каждого дня > 0) в заданном периоде
2. Расчет общего количества дней в периоде
3. Расчет отношения "1" к "2" (коэффициент наличия товара)
4. Расчет произведения реально проданного количества на "3"

Допущения и ограничения:
1. Периоды могут быть только смежными если это необходимо
2. См. выше
3. Желательно чтоб перфоманс сел не более чем на 200% по сравнению с сажанием перфоманса при использовании функции периодс2дате :)
4. Инструменты MS AS + Excel 2002/2003

Бюджет проекта: 0 руб 00 коп.

Сроки: безумные

А в какой прикладной области вы решаете задачу?
Опт, Розница?
Характер товаров?
Какова конечная цель?
Просто посмотреть на возможные продажи и облизнуться или использовать эти данные для управления закупками во избежание OOS (Out-of-Stock)?

Я в свое время решал эту задачу для оптового торговца продуктами питания (во времена когда MS AS еще не существовал и все решеник было построено в MS SQL тогда 6.5). И по началу считал именно так как и вы (коэффициент наличия товара). Но практика показала, что п.4 выдает завышенные результаты ибо не учитывает того эффекта, что в первые дни появления товара после нескольких дней OOS, дневные продажи существенно выше, чем если бы товар был все время на складе (эффект "выбросили дефицит"). Если доля постоянных клиентов высока и они знают, когда будет товар и покупают его тогда когда он есть, ибо знают когда он появится, то ваша теория "возможных продаж" валится как карточный домик. Ваша теория хороша для розницы (noname customer or relationless customer), но и то в известных пределах.

Если же абстрагироваться от вопросов применительности вашего метода и спуститься к постным MDX проблемам, то перформанс видится слабым и болезненным, особенно если в качестве FrontEnd выступает Excel с его "высокоинтеллектуалтным" генератором MDX запросов.
Я бы взял уж како нибудь FrontEnd, где можно custom mdx отрабытывать. Тот же Reporting Services может вам очень помочь (конечным юзерам MDX Sample Applicatioin ведь не дашь)

А что там на pivotview.com?

А то у меня

Forbidden
You don't have permission to access / on this server.


--------------------------------------------------------------------------------

Apache/1.3.23 Server at www.pivotview.com Port 80

Dmitry Biryukov RecoilmeЖалко что чудесная формула Дмитрия возвращает ноль, а не нулл...Это можно настроить с помщью non empty behaviour или через банальный IIF

RecoilmeМожно ещё вопрос?? Как половчей посчитать количество дней в выбраном периоде (если несколько элементов выбрано)?


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

1. с помщью non empty behaviour вы вряд ли добъетесь чего либо толкового ибо non empty behaviour ведет себя как хочет.

2. Ваша формула вернет количество дней когда были факты в кубе, а не количество дней. Для этого NECJ гораздо скорострельнее. А вот количество дней под членом измерения я бы считал просто как


Но при multiple select не катит. Там надо в MDX иметь set из выбранных членов измерения, а не СM от них. Из CM сет не выудишь. И если CM делается во FrontEnd, то сушите весла.

Dmitry Biryukovвот именно, что моя формула считает правильно даже при мультиселекте - проверено.

" формула вернет количество дней когда были факты в кубе, а не количество дней " вот это конечно верно.

Если Вас не затруднит, пожалуйста приведите пример запроса желательно на FoodMart, где она считает правильно на MultiSelect

ShIgor backfireНо при multiple select не катит
Катит - проверено на всех своих базах - использую где только возможно и во всяких срезах и мултиселектах... и вообще все вычисления у меня вокруг да около этого подсчета - на "неправильность" за 2 года пока никто не жаловался, разве что на скорость и то иногда...

приведите пожалуйста простейший запрос, в котором участвует и "MultiSelect" и эта формула для count.

Dmitry Biryukov

Это не то что я имел ввиду. У вас count идет по продуктам, а multiselect по [Store Type]. А вот если и то и другое по одному измерению.

На Where она не катит.

Вот вы и попались.

SUM да еще SOLVE_ORDER = 2.

А если у вас СM типа
Measures.[Profit %] = ([Measures].[Sales] - [Measures].[Costs])/Sales
, т.е. явно не summable.

SUM с SOLVE_ORDER = 2 тупо сложит проценты :-)

Уважаемый Shlgor, я не собираюсь проверять ваше знание MDX, и не хочу увести в сторону, просто я пытаюсь средсвами AS 2000 решить проблемы Multiselect member, буди то на осях, будь то в WHERE. Как я и предполагал, универсального подхода в построении CM для multiselect нет, всегда надо подыгрывать с SOLVE_ORDER в зависимости от наличия и характера других CM.

А огород то в вашем утверждении о универсальности и правильности

ShlgorКатит - проверено на всех своих базах - использую где только возможно и во всяких срезах и мултиселектах... и вообще все вычисления у меня вокруг да около этого подсчета - на "неправильность" за 2 года пока никто не жаловался, разве что на скорость и то иногда...

JuriiЯ думаю в MS AS универсальное решение по созданию вычисляемых мемберов при мультиселекте рано или поздно появится

Почему появится? Есть уже в AS2005.

MoshaУниверсального решения для мултиселекта под произвольный calculated member не может существовать в принципе, причем неважно используется MS AS или любой другой продукт. Это потому что можно построить примеры, где семантика просто не определена. Например, допустим у нас есть CM который считает нарастающий итог по годам. В MDX это будет записано так:


А теперь пользователь сделал мултиселект по Year.[1998] и Year.[2003]. Что будет являться правильным результатом ? Правильный результат не определен. Конечно, для данного конкретного случая можно определить что именно должно произойти и даже подправить формулу чтобы она это делала, но идея в том что не существует общего решения.

Моша
----------------------------------------------------
This posting is provided "AS IS" with no warranties, and confers no rights

C одной стороны я с вами согласен. Но меня мучает вопрос, а чем же так принципиально семантически отличатся ad-hoc multiselect n-меберов от уже имеющегося в структуре иерархии родительского члена n-меберов? (предчествую, что объяснения для 2k и 2k5 будуь сильно отличаться)

To Schlgor

Хорошо, закончим наш теологический диспут. Я действительно немного переиграл, ведт изначально речь шла только о count СM.


Моше

Попытаюсь еще раз изложить мою мысль.

Есть измерение A , уровень N , на нем выбраны n членов и для них построен CM m по какойто формуле [AGGREGATE|SUM|...].
Предположим, что на уровне N-1 существует член M , и M.children = {n выбранных членов }
Теперь собственно мой вопрос. В каких случаях значания мер в том числе и calculated могут и должны быть равны или не равны для M и m