Еженедельные расчеты DAX — проблемы со временем в LuckyTemplates

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

Недавно я сделал учебник по получению значений предыдущей недели в LuckyTemplates. С тех пор у меня есть несколько вопросов, связанных с анализом времени и, в частности, с еженедельными значениями DAX. Это неудивительно, потому что недели — это действительно самая плохая степень детализации в сфере анализа времени.

В случае месяцев у вас всегда есть 12 месяцев в году. В случае с четвертями у вас всегда есть четыре четверти. Недели разные, потому что в неделе семь дней, а в году 52 недели — это 364 дня. Итак, у вас есть лишний день, чтобы торчать там. В високосный год у вас есть два дополнительных дня.

Таким образом, это на самом деле приводит к тому, что в некоторые годы, основываясь на схеме нумерации номера недели ISO, иногда бывает 52 недели, иногда 53 недели. 53-я неделя вызовет больше всего проблем.

Оглавление

• Вопросы аналитики времени в еженедельном расчете DAX
• Заключение

Вопросы аналитики времени в еженедельном расчете DAX

В этом примере я использую общую спотовую цену. С итогами легче визуализировать и говорить.

В этом случае для каждого года мы хотим показать строку для 53-й недели, независимо от того, была ли 53-я неделя в этом году или нет. Итак, вы можете видеть, что в 2018 и 2019 годах 53-й недели нет, а в 2020 году она есть. Мы хотим, чтобы это было последовательно, чтобы 53-я строка была в каждом году. Но тогда метрика будет пустой для тех лет, в которых не было 53-го года.

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

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

Одна из вещей, которую мы потенциально можем сделать, — это перейти к схеме снежинки, где мы фильтруем таблицу «Даты» по чему-то, что будет заставлять эту 53-ю неделю в нашем визуальном элементе каждый год. На ум приходит функция .

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

В этом случае CROSSJOIN берет два столбца и создает каждую комбинацию этих двух столбцов, независимо от того, существует ли она в наборе данных или нет. Это именно то, что мы хотим.

У нас есть для создания таблицы из столбца. CROSSJOIN берет две таблицы, а затем VALUES номер недели ISO, и мы просто сопоставляем их вместе. Это даст нам 53 недели в году.

Затем мы добавляем в таблицу третий столбец. Мы могли бы сделать это в Power Query, но проще показать вам логику в DAX. Что мы делаем здесь, так это то, что мы фактически берем и объединяем год с дефисом, а затем номер недели, так что у нас есть ключевое поле для присоединения его к таблице дат.

Однако здесь нам нужно проделать еще немного работы, потому что способ работы ключевого поля в таблице «Даты» состоит в том, что это четырехзначный дефис «Год», а затем двухзначный «неделя». Таким образом, в случаях, когда номер недели ISO состоит из двух цифр, мы можем просто выполнить простую конкатенацию. В случаях, когда это одна цифра, нам нужно взять номер года, а затем соединить его с дефисом, затем с начальным нулем, а затем с номером недели.

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

Если мы вернемся к визуальному, мы должны изменить ряды. Вместо номера года и недели мы хотим использовать номер года и недели из таблицы CROSSJOIN. И теперь у нас есть эта 53-я неделя в 2018 году с пробелом и 53-я неделя в 2019 году с пробелом. В 2020 году у нас есть фактическое число, поскольку у него 53-я неделя.

На этом можно было бы остановиться, за исключением того факта, что сейчас мы вышли из модели Star Schema. Каждый раз, когда вы отказываетесь от схемы «звезда» в LuckyTemplates, вы выходите за рамки того, что обычно считается передовой практикой.

Итак, для схемы Snowflake это не большое нарушение. Есть случаи, когда вы определенно захотите его использовать, но если вы можете избежать этого, попробуйте. Это уменьшает дублирование, но не обязательно размер. Это позволяет вам использовать показатели прямого подсчета, но есть проблемы с производительностью и потенциальные проблемы с удобством использования, и определенно увеличивается сложность DAX. Это мешает вам создавать иерархии между таблицами, и, вероятно, наиболее проблематичным является то, что это может действительно испортить вашу способность синхронизировать слайсеры по различным полям.

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

Но если мы посмотрим на DAX, то увидим, что это тот же самый DAX, который создал эту таблицу в другом отчете. Таким образом, вместо того, чтобы соединять его в физическом отношении, а затем нарушать схему «Звезда» и преобразовывать ее в схему «Снежинка», мы можем поддерживать схему «Звезда» и просто использовать виртуальные отношения.

Для этого мы будем использовать функцию под названием . Он создает эту связь между таблицами, но делает это виртуально. Мы делаем это, используя потому что мы собираемся изменить контекст. В этом случае контекст будет относиться к отношениям. Итак, у нас есть общая спотовая цена, а затем у нас есть TREATAS. У нас есть , чтобы превратить этот столбец в таблицу.

И затем у нас есть поле «Год и неделя», которое является ключом, который мы создали. У нас есть это виртуальное соединение с неделей и годом в таблице дат. Итак, теперь у нас есть таблица Crossjoint, фильтрующая таблицу Dates так же, как это делалось, когда у нас были физические отношения, но без нарушения звездной схемы.

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

Получение значений LuckyTemplates за предыдущую неделю с помощью DAX и Power Query
Расчет недельных продаж с помощью DAX в LuckyTemplates
Time Intelligence в DAX: как динамически выбирать начальный период

Заключение

В этом руководстве я показал вам несколько способов решения проблемы еженедельного расчета DAX в LuckyTemplates. Один из них — использование CROSSJOIN, но он имеет некоторые недостатки. Второй способ — использовать TREATAS, создавая виртуальные отношения и не нарушая подход Star Schema.

Это один из методов, который весьма полезен для решения проблемы 53-й недели. Надеюсь, вы нашли это полезным. Я хочу знать ваши мысли по этому поводу. Позвольте мне знать в комментариях ниже.

Всего наилучшего,