seseUpdate:

а походу скоуп не при делах: убрал скоуп , чтобы посмотреть на поведение самого ласт чайлда. и вот он, зараза, плюет с высокой колокольни на указания на партициях и читает всю историю.
а что мы знаем про ласт чайлд? может пропертю какую установить?
Мы знаем про last-child, что он отрабатывает на уровни иерархии . Для 2018-го берется декабрь 2018, для декабря 2018 берется 31 декабря 2018 (или последняя реальная дата).
Поэтому [Дата].[День].[ День] last-child будет идти вверх сразу до [Дата].[День].[All], а вот для иерархии [Дата].[Год-Месяц-День].[День] уже все будет выходить вверх до месяца, а тот до нужного года.
Но и тут нельзя 2018 год засовывать в Scope, а нужно переопределять условие iif(год(Дата.Год-Месяц-День.CurrentMember) это 2018, тогда первое условие, иначе второе условие).

Не стал подробно расписывать, но общую мысль таки уловили, коллега?

ShIgorsese,

а сам запрос-то где? от него тоже многое зависит
Так он выбирает в Excel мультиселект набор по разным датам или месяцам. Для простого Value с типом SUM все идет корректно, какие выбрал - те секции и читаются.
А вот для общего итога при мультиселекте для value2 получается ерунда. Читаются все секции.

Вывод - не делать физическую measure, а писать составную формулу, которая учитывает то, что будет выбран не единый уровень по измерению Дата - год, месяц, квартал, неделя, день, а несколько вариантов галочками.
И в таком случае искать из выбранных последний день и для него определять Value2 как last-child из Value.

ShIgorAndy_OLAPпропущено...

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

seseAndy_OLAP,


авторВывод - не делать физическую measure, а писать составную формулу, которая учитывает то, что будет выбран не единый уровень по измерению Дата - год, месяц, квартал, неделя, день, а несколько вариантов галочками.
И в таком случае искать из выбранных последний день и для него определять Value2 как last-child из Value.



Я в свое время пошел было путем вычисляемой меры, но как раз не смог обработать мультиселект и потому на годы забросил, поскольку все решалось физической мерой =)
Таки да - вот Вы и пришли к варианту, когда не все решается физической мерой. И нужно обрабатывать мультиселект.

seseAndy_OLAP,

авторВывод - не делать физическую measure, а писать составную формулу, которая учитывает то, что будет выбран не единый уровень по измерению Дата - год, месяц, квартал, неделя, день, а несколько вариантов галочками.
И в таком случае искать из выбранных последний день и для него определять Value2 как last-child из Value.


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




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

Что касается перебора.
create dynamic set currentcube.[Set_of_Days_without_Hierarchy] AS existing [Дата].[День].[День];
create dynamic set currentcube.[Set_of_Days_with_Hierarchy] AS existing [Дата].[Год - Месяц - День].[День];
Вот с этого нужно начать.
Что касается нужного набора - то логично, что он будет {[Дата].[Год - Месяц - День].&[20180101]:{[Дата].[Год - Месяц - День].CurrentMember} при условии, что CDbl(tail(existing [Set_of_Days_with_Hierarchy]).item(0).Properties("Key")) > CDbl (20180101).

Почему ключ для ключевого атрибута День нужно конвертировать функцией CDbl и сравнивать с CDbl (20180101), а не просто 20180101 - подумайте на досуге, это таки интересно :)

ShIgorsese,

тогда если это все сворачивается меньше чем в 4096 строк, то посмотрите настройку IndexBuildThreshold в msmdsrv.ini

а вообще тема древняя и мало что изменилось с того времени ( тут )

Кстати, Моша в статье Get most out of partition slices в разделе Related attribites так и пишет: "FE (formula engine) does coordinate decoding lazily, only if it really needs to" и дальше объясняет, что если слайс = Год, но CurrentMember этого атрибута в запросе не используется, то и декодирования его не будет, а значит и слайс тоже не получит указание использовать только эту партицию.
А у Вас очень похожая ситуация - слайс - год, а в запросе иерархия ГМД с указанием члена только на уровне день.
Он еще мог слайс записать как [Дата].[Год].&[2018], а нужно было как [Дата].[Год-Месяц-День].&[2018], потому что первый вариант - это неключевой атрибут, а второй вариант - это уровень иерархии, под которым явно собраны все даты 2018-го года...

seseAndy_OLAP,


авторЧто касается перебора.
create dynamic set currentcube.[Set_of_Days_without_Hierarchy] AS existing [Дата].[День].[День];
create dynamic set currentcube.[Set_of_Days_with_Hierarchy] AS existing [Дата].[Год - Месяц - День].[День];
Вот с этого нужно начать.


В свое время я было пытался креативить named set-ы, но меня раздражало то, что при первом в сессии обращении к кубу всё приличненько так зависало на вычислении этих сетов. И как-то не пошло у меня с named set-ами. Так что сейчас придется погружаться повторно с нуля =) Ладно, пасиб за подсказки!
Потому что Вы делали named set как filter(крупное измерение, условие отбора по группе мер на лету), а тут достаточно как existing набор уровней иерархии или existing набор ключевых атрибутов измерения, без отбора по физической мере (который постоянно будет требовать сканирование всех секций такой группы мер), а или без условия, или по условию, которое можно не засовывать в named set, а каждый раз копи-пастить внутрь формулы для calculated measure.

sese,
Вот так неправильно.


А вот так правильно.

Andy_OLAP,
Для красоты поправим, взяв явно в фигурные скобки.

seseИ еще заметил интересный эффект: если вдруг имя сета совпадет с именем любого
"вдруг" имя сета никак не может совпасть. Ведь его ВЫ пишете, а не дядя Вася, слесарь 6-го разряда.

Используйте уникальные кошерные имена, типа set1, set2, set3, всегда их описание в начало calculation для куба - и будет все хорошо!

seseAndy_OLAP,

ну и вот это я пока не смог постичь:




В чем отличие




от сета 1 ? Зачем нужен физический счетчик дней?
Потому что для красоты. У Вас в измерении дней пользователи могут выбрать дни праздников, когда фактов быть не может, могут выбрать даты из будущего.
И тогда для скажем средней цены продаж Вы посчитаете продажи только в реальные дни продаж и поделите на календарный счетчик count(existing [Дата].[День].[День]). Это не оптимально. А когда есть физические меры типа количества дней, количества праздничных дней, количества будней и так далее, привязанных напрямую Regular к измерению дней в отдельной группе мер - решение получается гибким.

Но это эстетика, кто как хочет.

seseAndy_OLAP,


авторУ Вас в измерении дней пользователи могут выбрать дни праздников, когда фактов быть не может, могут выбрать даты из будущего.



Прошу простить, но, как мне кажется, это - шаг сильно в сторону от мучающей меня проблемы.

1. Я предлагаю говорить только о СОСТОЯНИИ. Не про аддитивные меры и не про среднее. Только о состоянии. При изменении состояния делаются две записи: старое состояние с минусом и новое с плюсом. Состояние на любой момент есть сумма или с начала времен (тогда моя проблема чтения всей истории перестает быть проблемой), или от некоего начального состояния (и вот тут - я позволю себе напомнить - я сталкиваюсь с ненужным чтением партиций, принадлежащих периодам ДО даты начального состояния).
В принципе все сказанное о состоянии полностью применимо и к остатку, когда остаток на любой момент времени есть опорный остаток плюс сумма всех движений. И совершенно без разницы, есть ли в выбранную пользователем дату какие-либо изменения состояния (или товарные движения, изменяющие остаток). А так же совершенно без разницы, праздничный то день или будний. Не вижу криминала в желании пользователя посмотреть в самый праздничный день, какой у него остаток на складе или сколько скю являются бестселлерами\дедстоками.
Что же до выбора пользователем будущих дней, то тут все просто: чтобы Last Child хорошо считал результат выше листевого уровня для незавершившегося периода и не нужно было отдельно приравнивать результат текущего месяца последнему дню (что чревато ошибками, кстати), я просто сделаю календарь, который будет заканчиваться днем последнего состояния\остатка. Если я в хранилище загружаю каждый день вчерашний день, то мое измерение времени каждый день будет заканчиваться вчерашним днем. И все, пользователь в принципе не выберет ненаступивший день. И LastChild всегда будет давать результат текущего незавершившегося месяца и незавершившегося года.
Но тема ненаступивших дней в общем-то тоже слабо относится к проблеме.
2. Задачу состояния (или остатка) на любой момент я решал с помощью двух физических мер (Sum & Last Child) и скоупа, связывающего одно с другим.
3. Мне вами было предложено использовать иерархию "Год-Месяц-День" и два именованных набора: [Дата].[День].[День] и [Дата].[Год-Месяц-День].[День]. И, насколько я понял, вы предлагаете отказаться от физической меры вообще и LastChild-a в частности.

Могу я попросить раскрыть именно путь в пункте 3?
Я прописываю на партициях Slice ГМД, но не добиваюсь результата, чтение идет всей истории.
Я пытаюсь получить сет с набором дней от начального состояния до последней даты выбранного пользователем периода, но и тут не преуспеваю - см. выше.
И вот от этого впадаю в меланхолию и очень хочется, чтобы кто-то наставил на путь истинный =(

"Состояние на любой момент есть сумма или с начала времен " - таки да. Поэтому Value - агрегация SUM, Value2 - агрегация Last-Child, мера из группы мер со счетчиком дней, которая связана только с измерением дат.
А далее scope value2,день this = sum(null:[Дата].[Год-Месяц-День].CurrentMember,Value) и так далее.

Но есть нюанс. Вот если агрегация last-non-empty - все хорошо. А для last-child нужно в каждом месяце в первом числе иметь кошерный входящий остаток и считать внутри месяца (или другого периода). И тогда не просто sum, а mtd() или ytd() и так далее.

И если периоды в секциях привязаны с учетом иерархии, в которой присутствуют нарезанные периоды, например, [Дата].[Год-Месяц-День].[Месяц].&[201711], то все будет хорошо. И никаких лишних чтений.

Что касается Вашего случая - видимо, между днем и месяцем как атрибутами, которые затем ложатся в одноименные уровни иерархии, нет rigid и не выбран тип атрибута - не Regular, а Days и Months. Тогда и mtd() будет хорошо работать, и лишних чтений не будет.

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