Пытаюсь сделать отчет по проценту наличия товара на складе.
Остатки считались как вычисляемое поле, операции использовались все.
В результате тормоза жуткие, что и не удивительно.

Путем нескольких ухищрений удалось сделать хранилище данных, где лежат ненулевые остатки.

Дальше все казалось просто: строим куб и получаем процент наличия.
Но тут оказалось что мера может суммироваться, считаться, вибираться минимум или максимум, а вот среднее не считается.

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

Теперь исходные данные:
1. Код товара
2. Склад
3. Год
4. Месяц
5. Процент наличия

Пункт 5 можно заменить Количество дней с ненулевым наличием.

Имеются измерения:
1. Время
1.1. Год
1.2 Месяц

2. Товары
2.1 Код ответственного
2.2 Товарная категория
2.3 ТОП продаж
2.4 Код товара

Возможны еще разные измерения построенные от кода товара.

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

Хотелось бы видеть процент наличия по ответственному и т.д.
Но как посчитать среднее я не чего то не могу понять.

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

Сначала я думал, что отсутствие AVG оправдано, поскольку серверу неочевидно по каким измерениям усреднять.
Но потом подумал и пришел к выводу что в моем случае усреднять нужно всегда по той же выборке что и суммирование.

Почему SUM для меры есть, а AVG нет?
Как с этим боротся?

Dmitry Biryukovподелите сумму на количество
Оно то конечно.
Вопрос количество чего?
И где его взять? Count работает по сету. А где этот сет?
Я же говорю, измерения которые будут подкладывать аналитики могут быть разные. Как охватить все варианты для любых возможных измерений.
Сумму то куб считает и сет не спрашивает.

Dmitry Biryukovкол-во - физ. мера
Количество чего физмера?

Если я посчитаю сумму дней с наличием и добавлю физмеру с количеством дней всего то зачем тогда ОЛАП вообще?


Вопрос в том, что как физмеру я могу получить либо:
1. Количество дней с наличием товара на складе за месяц.
Либо:
2. Процент наличия на складе в месяц.


Если кол-во - физ. мера, то я это уже сделал если использую как физмеру вариант 2.

Но дело в том, что при сворачивании измерения до года (наличие за год) нужно найти среднее за год.
Если добавляется измерение по категории товара то нужно найти среднее по категории. По топу - аналогично.
Вообще вариантов у аналитиков довольно много и все сразу им в голову не приходят.

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

Dmitry BiryukovLogrusAS, почему вы не хотите меня понимать? зачем вы сопротивляетесь правильным идеям?
Ещё раз: процент наличия это кол-во дней, когда товар присутствует, делить на общее кол-во дней.
делаете 2 физ меры. с какой именно у вас проблемы?
и СМ - частное этих мер

Да я как раз хочу.

Сделал, все равно не выходит каменный цветок...

Поскольку в каком то месяце может не быть товара, то количество дней в месяце отсутствует и не суммируется.
Скажем товар был в течение 15 дней в месяце с 30 днями.
В остальные месяцы товара небыло.
В этом месяце процент наличия 50%, а году 100*15/365.
При сворачивании до года процент наличия все равно показывает 50%.

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

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

Как вариант можно сделать таблицу фактов с 0 значениями когда товара нет.
Это может даже и правильнее, поскольку по условиям если товара не было вообще, то его процент не нужен. А если был когда то, но нет сейчас то нужно процент считать.

Но тогда таблица фактов взорвется. Другие идеи есть?

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

Dmitry Biryukovесли не будете молчать как партизан и говорить по-русски
Ну простите. У меня тут перезд, и вообще как то все сразу навалилось.

LogrusASВ этом месяце процент наличия 50%, а году 100*15/365.
При сворачивании до года процент наличия все равно показывает 50%. Dmitry Biryukovа нет ли у вас calc cells или custom rollups?
Где? В кубе? Тут нет. На сервере есть (Вы видимо имеете ввиду ентерпрайз ли у меня?)

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

Dmitry Biryukovэто правильно. а измерения в обоих кубах общие или приватные?
Общие, но в наличии измерений много, в днях одно Год-Месяц. Оно же есть и в наличии.


LogrusASЯ так и не нашел литературы по ОЛАП, поэтому тыкаюсь как слепой.
Скоро я схожу на курсы, там обещали литуратуру выдать.
Может чего и поможет.

Dmitry Biryukovлитературы вообще-то навалом. начните хотя бы с туториала, ссылка на который появляется при старте АМ
Туториал читал, какой то он не такой. Хелп и МСДН тоже не помогли.
Книг на базаре, в магазинах и в инете нет.
Может чего порекомендуете?

Dmitry Biryukov LogrusASМожет чего порекомендуете?курсы, только курсы. причём сначала английского, потом ОЛАП
Эээ... А английский то тут причем? С этим проблем нет.
Проблемы с методом изложения. Все что я видел по олапу к сожалению либо справочник по функциям, который больше напоминает Бронштейна и Семендяева. В смысле если все это знаешь, то он очень помогает.
Но выучить математику по этому справочнику невозможно.
Либо тот же туториал, где просто показано что у нас есть.

Dmitry Biryukovя имел в виду используются ли у вас в упомянутых кубах calc cells или custom rollups??
На оба вопроса нет.

LogrusASОбщие, но в наличии измерений много, в днях одно Год-Месяц. Оно же есть и в наличии.
Dmitry Biryukov????знаете в чём разница между private и shared измерениями?
Мне сложно судить себя знаю ли я правильно, литературы то кошерной я так и не прочел.

Если я скажу что shared это те что при создании через визард на последней закладке имеют птичку shared с другими кубами? И которые видны в менеджере в закладке shared dimension? Это будет правильно?
Тогда они shared.
Они оба показываются нормально. Но каждое отдельно от другого.

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

Как я уже писал полной информацией будут все данные по всем товарам и т.д.
Просто когда товара на складе не было, должен быть 0.

Тогда все заработает.
Но таблица содержащая факты сейчас 99 метров. Ради эксперимента я сгенерил с 0 значениями. Про время генерации я вообще не хочу говорить. Но
размер 12 Гигабайт. Поэтому и хочется решить вопрос в ОЛАПе.

Dmitry Biryukovвернёмся к LogrusASПопробовал сделать два куба, один с днями наличия, другой с днями в месяце.
Оба работают. На них создаю виртуальный куб в надежде поделить на количество дней в году, а не на количество дней в месяцах когда товар был.
измерение даты в кубах общее?
ValidMeasure обернули?
Измерение общее.

В ValidMeasure не обернул. Это как и где? И зачем?
Пока пошел смотреть справочник на тему ValidMeasure.

Dmitry Biryukovесли с английским всё в порядке, ответы найдёте сами.
Обернул, но это опять не то.
Ну с днями то решили, но точно так же нужно и с другими измерениями.
Причем даже с теми которые могут появиться в будущем.

Теперь имеем "количество дней с наличием" суммирутся по всем измерениям.
А делим мы теперь на количество дней в периоде.

Если какой товар у нас был на разных складах, то суммарное количество дней в месяце может быть много больше 31. Поскольку товары по бизнес процессу путешествуют между складами, то бензин оплаченый 10 дней висит на складе путь, потом 5 дней на складе приход, потом 20 дней на складе основной.
Разные партии в разное время на разных складах.
Это к примеру.
Измерение товарная категория например в товарной категории может иметь до нескольких тысяч товаров.

Поэтому если фильтр стоит "все склады", в колонках измерение товарная категория свернутая до верхнего уровня, то суммарное количество дней наличия за месяц по бензину у меня например 2147.
А вот ValidMeasure от дней в периоде 31.
Да, за год оно теперь показывает 365 дней.
Но суммирует то оно по всем измерениеям.
Ну и понятно что процент наличия 100*2147/31 не совсем корректный.

Ваше предложение видимо может быть доведено до ума, если я задам жесткий набор измерений. Но такого нет по определению ТЗ.

Поэтому я и задал самый первый вопрос, который повторяю.

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

Dmitry Biryukov LogrusASЕсли какой товар у нас был на разных складах, то суммарное количество дней в месяце может быть много больше 31неверно. сами подумайте почему.
К сожалению неверно для одного конкретного склада.
Или для случая наличия в выборке всех складов при условии 0 значений на складе товара в конкретный день. В случае отсутствия в выборке данных вообще при отсутствии товара все данные некорректны

Dmitry Biryukov
LogrusASПоэтому если фильтр стоит "все склады", в колонках измерение товарная категория свернутая до верхнего уровня, то суммарное количество дней наличия за месяц по бензину у меня например 2147.а теперь дайте определение числу "количество дней наличия за период по товару".

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

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

Есть измерение "Дата" Из двух уровней "Год" "Месяц".
Есть измерение "Товар" Из двух уровней "Категория" "Код товара".
Есть измерение "Склад" Из одного уровня "Склад".


Есть мера "Количество дней в месяце наличия товара на складе"
Таблица фактов содержит поля:
"Код товара", "Склад", "Год", "Месяц", "Дней с наличием товара".

В случае, если в "Код товара", "Склад", "Год", "Месяц" товара не было,
то в таблице фактов записи нет.
Печально, что нужно различать последний факт по двум вариантам:
"Товара не было и раньше" и "Товар был, но сейчас нет".


В "Категория" может быть скажем 500 разных товаров.
В "Склад" может быть 50 разных складов.

Мера "Дней с наличием товара" будучи агрегирована по таблице фактов
по существующим полям за счет CROSS JOIN с "Склад", "Год", "Месяц"
и с учетом отсуствия записей когда товара не было дает правильную сумму по
"Склад", "Год", "Месяц", "Код товара" в "Категория".
То есть количество дней когда товар был на "Склад" в "Год", "Месяц"
и с суммой по "Код товара" в "Категория" правильный.

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

Это в принципе возможно. Если четко привязаться к измерениям
"Дата" (сдесь нужно брать все данные);
"Товар" (сдесь нужно брать только выборку по "Категория");
"Склад" (сдесь нужно учесть только те склады, которые попали в суммирование).

В общем случае представим себе куб (не совсем в терминах олап, но думаю понятно)
Оси:
Месяц (пуст будет сквозная нумерация месяцев с начала времен)
Склад
Товар (сдесь собрано в группы по категориям).

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

Если просуммируем все ячейки (учитывая 0, хотя они суммы не увеличат)
и поделим на количество ячеек по которым проводилось суммирование то получим искомую величину.


Но если опять вернуться к первичной задаче, то привязываться к измерениям нельзя. За исключением "Дата" . Вариант с ValidMeasure решает вопрос с отсутствующими месяцами.

Но не решает вопрос с складами и категориями.

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

Вопрос, (возможно не совсем корректно заданый, простите) состоял в следующем:
Почему в SQL среди агрегирующих функций есть AVG, а в ОЛАП его нет?
Первое что пришло в голову неопределенность выборки для сервера.
Но тогда туда же попадает и SUM. А ведь она является дефолтной функцией агрегирования.

И именно поэтому я спрашиваю о литературе.
Справочник по функциям это хорошо, но тут явно я непонимаю чего то на уровне концепции.
Пойму концепцию, остальное будет намного легче.

Потому попробуйте все же ответить не на вопрос "Как выполнить это конкретное задание?". А на вопрос "Почему нельзя получить среднее по выборке?"

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