Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2676
ShIgor
sese,

тогда если это все сворачивается меньше чем в 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-го года...
15 май 18, 16:32    [21411116]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Andy_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-ами. Так что сейчас придется погружаться повторно с нуля =) Ладно, пасиб за подсказки!
15 май 18, 17:38    [21411316]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Andy_OLAP,


автор
Он еще мог слайс записать как [Дата].[Год].&[2018], а нужно было как [Дата].[Год-Месяц-День].&[2018], потому что...



А если я зайду с иерархии "год-неделя-день"? или вообще с "Месяц - месяц конкретного года - день"?
А так да, я ж в корневом посте признал, что именно так ([Дата].[Год].&[2018]) слайс и записан =)
15 май 18, 17:41    [21411326]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2676
sese
Andy_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.
15 май 18, 21:26    [21411790]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Andy_OLAP,

Прошу простить, но пока эксперименты с сетами застопорились вот на чем:

create dynamic set [Existing Дата День День] as existing [Дата].[День].[День];
create dynamic set [Existing Год Месяц День] as exists([Дата].[Год - Месяц - День].[День], [Existing Дата День День]);
create dynamic set [Year To Date] as  
{
    [Дата].[Год - Месяц - День].[День].&[20180101]
    :
    tail([Existing Год Месяц День]).Item(0)
};

create calculated member currentcube.measures.[Границы Year To Date] as 
CSTR(head([Year To Date]).item(0).properties('name')) + '-' + 
CSTR(tail([Year To Date]).item(0).properties('name'));

create calculated member currentcube.measures.[Границы Existing Год Месяц День] as 
CSTR(head([Existing Год Месяц День]).item(0).properties('name')) + '-' + 
CSTR(tail([Existing Год Месяц День]).item(0).properties('name'));


приводят к следующему результату:

Дата.Год - Неделя - ДеньWeek 3 2018
Границы Year To Date15.01.2018-21.01.2018
Границы Existing Год Месяц День15.01.2018-21.01.2018


Для простоты начало года в сете [Year To Date] задаю однозначно.
Вот почему сет [Year To Date] не подхватывает все дни с начала года?
18 май 18, 12:18    [21419885]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
И еще заметил интересный эффект: если вдруг имя сета совпадет с именем любого мембера любого атрибута любого измерения, то при попытке получить

tail([сет, чье имя совпадает с именем какого-то мембера]).Item(0).Properties('key') = <Key того мембера, с которым сет совпал по имени>
18 май 18, 12:56    [21420084]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2676
sese,
Вот так неправильно.
scope([Дата].[День].[День],Measures.[Value2]);
this =
-- вот здесь мы будем складывать только те дни, где они попадают в период с 1 января 2018
iif(
intersect(existing [Дата].[День].[День], StrToMember("[Дата].[День].&[20180101]"):null).count>0,
SUM(
 -- для каждого дня сложим, а для мультиселекта в общий итог пойдет вся сумма, что неправильно
{[Дата].[День].&[20180101]:[Дата].[День].CurrentMember},[measures].[Value]),
null);
end scope;

А вот так правильно.
create dynamic set [set1] as existing [Дата].[День].[День];

create calculated member currentcube.measures.[Value2] as
iif(
-- на каждом уровне свой хвост !!!, на общем итоге свой хвост
-- именно поэтому используем existing [set1]
intersect(existing [set1], StrToMember("[Дата].[День].&[20180101]"):null).count>0,
sum(
[Дата].[День].&[20180101]:
-- а вот здесь не используем set от сессии, а используем набор ключевых элементов измерения
tail(nonempty(existing [Дата].[День].[День], [Measures].[какой нибудь физический счетчик дней как мера суммировани])).Item(0),
[measures].[Value]),null),
VISIBLE = 1;
18 май 18, 14:09    [21420331]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2676
Andy_OLAP,
Для красоты поправим, взяв явно в фигурные скобки.

create dynamic set [set1] as existing [Дата].[День].[День];

create calculated member currentcube.measures.[Value2] as
iif(
-- на каждом уровне свой хвост !!!, на общем итоге свой хвост
-- именно поэтому используем existing [set1]
intersect(existing [set1], {StrToMember("[Дата].[День].&[20180101]"):null}).count>0,
sum(
[Дата].[День].&[20180101]:
-- а вот здесь не используем set от сессии, а используем набор ключевых элементов измерения
tail(nonempty(existing [Дата].[День].[День], [Measures].[какой нибудь физический счетчик дней как мера суммировани])).Item(0),
[measures].[Value]),null),
VISIBLE = 1;
18 май 18, 14:11    [21420339]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2676
sese
И еще заметил интересный эффект: если вдруг имя сета совпадет с именем любого

"вдруг" имя сета никак не может совпасть. Ведь его ВЫ пишете, а не дядя Вася, слесарь 6-го разряда.

Используйте уникальные кошерные имена, типа set1, set2, set3, всегда их описание в начало calculation для куба - и будет все хорошо!
18 май 18, 14:13    [21420345]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Andy_OLAP,

а StrToMember зачем? И почему не используется иерархия ГМД, которую было предложено писать в Slice?
18 май 18, 14:34    [21420427]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Andy_OLAP,

И почему все-таки сет [Year To Date] в моем примере не подхватывает дни с начала года?
18 май 18, 14:35    [21420431]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Andy_OLAP,

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

tail(nonempty(existing [Дата].[День].[День], [Measures].[какой нибудь физический счетчик дней как мера суммировани])).Item(0)


В чем отличие

existing [Дата].[День].[День]


от сета 1 ? Зачем нужен физический счетчик дней?
18 май 18, 14:49    [21420485]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2676
sese
Andy_OLAP,

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

tail(nonempty(existing [Дата].[День].[День], [Measures].[какой нибудь физический счетчик дней как мера суммировани])).Item(0)


В чем отличие

existing [Дата].[День].[День]


от сета 1 ? Зачем нужен физический счетчик дней?

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

Но это эстетика, кто как хочет.
18 май 18, 21:19    [21421576]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Andy_OLAP,


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



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

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

Могу я попросить раскрыть именно путь в пункте 3?
Я прописываю на партициях Slice ГМД, но не добиваюсь результата, чтение идет всей истории.
Я пытаюсь получить сет с набором дней от начального состояния до последней даты выбранного пользователем периода, но и тут не преуспеваю - см. выше.
И вот от этого впадаю в меланхолию и очень хочется, чтобы кто-то наставил на путь истинный =(
20 май 18, 03:08    [21423310]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 2676
sese
Andy_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() будет хорошо работать, и лишних чтений не будет.

Вам бы взять хороший пустой проект за основу и посмотреть...Но не у моих бойцов, а у каких-нибудь российских ритейлеров. Южакова Александра попросите, чтобы он к Вам тим-вьевером подцепился и посмотрел беглым взором, что не так с измерением дат.
21 май 18, 16:43    [21426560]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Andy_OLAP,


За контакт, к которому можно попробовать обратиться, спасибо.

В очередной раз резюмирую:

1. Оставил в измерении времени вообще одну иерархию: Год-Квартал - Месяц - День.
Все релейшены между арибутами проставлены и тип у всех отношений - rigid, все атрибуты имеют свой тип: Days, Months, ... - ничего делать не пришлось, все и так было.
2. На партиции прописал слайс вида [Дата].[Год-Квартал - Месяц - День].[Месяц].&[201805]
3. Ах да, каждый месяц независим: на первое число дано состояние всех скю и потом только изменения - так и было в боевой версии. С начальным состоянием на год в предыдущих примерах это я уже экспериментировал отдельно =)
4. Скоуп заменен на

create dynamic set currentcube.[Existing day pool] as existing [Дата].[Год - Квартал - Месяц -День].[День]; 

create calculated member currentcube.Measures.[Кол-во SKU 3] as 
SUM(
MTD(tail([Existing day pool]).Item(0)),
measures.[Value]
);


Результаты тестирования:
1. При выборе месяца, квартала и года - все зашибись, читает только нужное и делает это максимально быстро.
2. А вот при выборе конкретного дня - скан всей истории. Но в принципе я неоптимально искал первое число месяца (вот так:

{
StrToMember(
'[Дата].[День].&[' + Left(Cstr([Дата].[День].CurrentMember.properties('key')),6) + '01]'
,constrained)
:
[Дата].[День].CURRENTMEMBER
}


) и с заменой на MTD прирост производительности налицо. Хотя до идеала не добралось.
3. При попытке вставить сет в скоуп

scope(
--[Дата].[Год - Квартал - Месяц -День].[День],
[Existing day pool],
Measures.[Кол-во SKU]
);
this =
SUM(
MTD([Дата].[Год - Квартал - Месяц -День].CURRENTMEMBER),
measures.[Value]
);
this = iif( Measures.[Кол-во SKU] <> 0,Measures.[Кол-во SKU], null  );
end scope;


на этапе сохранения изменений в проекте появилось сообщение вида "невозможно вычислить сет в области запроса"


То есть подвижки в нужном направлении с вашими подсказками есть существенные, спасибо.
Буду копать дальше =)
22 май 18, 02:39    [21427503]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
sese
Member

Откуда: маськва
Сообщений: 78
Final Update:


Поскольку нетрудно увидеть, что мое предыдущее сообщение содержит ошибку, то оно-то шагом к решению не является.
Проблема не в измерении времени, не в отношении между атрибутами или типизации атрибутов. Проблема не в Slice, хотя все же спасибо за подсказки.
Ларчик открывается просто: для аддитивных мер достаточно ProcessData. А вот полуаддитивные без ProcessIndexes фурычить не хотят. Но как только - так сразу!

Фсё, всем спасибо, тема точно закрыта.
9 июн 18, 17:33    [21482505]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
И_Павел_С
Member

Откуда:
Сообщений: 39
Всем доброго времени!
Не знаю в правильную ли тему пишу, но у меня как раз проблема в фундаментальных знаниях. В общем, только-только начал изучать SSAS и работу в Visual Studio. И вот на видео у лектора на вкладке Browse есть как бы поля, куда мы перемещаем измерения, которые хотим видеть в столбцах или строках сводной таблицы (см. рисунок). А вот у меня такого нет ни в Visual Studio, ни в Managment Studio после развертывания куба. То есть у меня измерения и меры встают как бы в одну строку, и результатом получается обычная таблица, а не сводная.
В яндексе решения не нашел, хотя может просто потому, что не знаю как правильно задать запрос.
Надеюсь на вашу помощь.

К сообщению приложен файл. Размер - 144Kb
16 июн 18, 23:01    [21496896]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 30734
Блог
так было раньше
16 июн 18, 23:37    [21496964]     Ответить | Цитировать Сообщить модератору
 Re: Пробелы в фундаментальных знаниях? MDX Scope...  [new]
И_Павел_С
Member

Откуда:
Сообщений: 39
Критик,
хм... То есть раньше было нагляднее? Странно как-то... Ну да ладно. Спасибо.
16 июн 18, 23:58    [21496990]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / OLAP и DWH Ответить