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

Но, если просто сравнивать абсолютные значения, то сделать какие-то выводы будет сложно, не зная контекста. Например, продажи трёх категорий различаются на 400-500 тысяч. Это много или мало?

Я специально сделал визуализацию, в которой немного значений, так что можно визуально увидеть и итоговое значение, и самое большое, и самое маленькое. Тем самым оценив значимость отклонений. Но на это всё тратится время и усилия, что отвлекает пользователя от конечной цели. Облегчить восприятие можно двумя способами. Представить данные графически:

Или изменить их представление, показав их относительную значимость в общем значении:

Чтобы получить процент от общего значения, можно воспользоваться неявными мерами, которые создаются с помощью интерфейса. Для этого достаточно добавить меру или столбец в поле значений, нажать правой клавишей мыши по ней и выбрать способ отображения "Общий процент":

И, хотя я всегда говорю: сначала вопрос - потом решение, - давайте сформулируем этот самый вопрос на основе полученной визуализации, чтобы затем самостоятельно написать меру, отвечающую на него.

Создадим визуализацию, где у нас будет три среза(фильтра) по году(Year), полу(Gender) покупателя и категории(Category)

Создадим первую меру, с помощью функции ALL:

Добавляем меру в визуализацию:

Значения написанной нами меры и неявной меры - идентичны.

Установим фильтр по году - 2018:

Условие вопроса "с учетом всех фильтров" выполняется. Значения по прежнему одинаковые, а доли рассчитаны от итоговых продаж за 2018-й год.

Добавим фильтр по полу:

Результат соответствует ожиданиям.

Но в вопросе ещё было "от продаж всех выбранных категорий". Давайте это и сделаем:

Значение написанной нами меры не соответствует ожиданиям. Это хорошо видно по строке итогов, где вместо 100% мы видим 58,91%. Это происходит потому, что функция ALL в соответствии со своим названием возвращает ВСЕ значения из указанного столбца, удалив ВСЕ фильтры, примененные к нему.

Попробуем воспользоваться функцией ALLEXCEPT:

Добавим новую меру в визуализацию:

Почему теперь везде 100%? Для этого обратимся к определению функции ALLEXCEPT:

То есть, мы наоборот сбросили ВСЕ фильтры с таблицы Products, кроме столбца Category, так как каждая строка визуализации имеет свой контекст вычисления (подробнее о работе контекстов можно почитать здесь).

Что ж, воспользуемся третьей функцией из семейства ALL - ALLSELECTED:

Сравним полученный результат:

Полученный результат идентичен значению неявной меры и полностью отвечает поставленному вопросу.

Но что если усложнить задачу и добавить ещё и месяцы в визуализацию?

Сначала визуализация с неявной мерой:

На примере января видно, что расчёт доли идёт от "общего значения", то есть за весь год.

А как считает мера написанная самостоятельно:

Итог по каждому месяцу равен 100%, то есть в такой визуализации именованная мера правильнее отвечает на поставленный вопрос, нежели неявная мера.

Ссылка на отчёт.

Создавая отчёты, мы стараемся помочь конечному пользователю, как можно скорее увидеть самое важное. Для этого используем различные индикаторы, подсказки. Так, одним из часто используемых маркеров является сравнение текущего значения с прочими. И, чтобы помочь пользователю быстрее увидеть текущее значение, его можно подсветить, выделив другим цветом.

Например, для диаграммы с типом Гистограмма это сделать достаточно просто с использованием условного форматирования:

Для определения текущей даты используется разметка в справочнике Календарь ( подробнее про это можно почитать в серии статей "Биг Дата")

Но, в диаграмме с типом График такой возможности нет. За то можно создать меру, которая будет возвращать ТОЛЬКО текущее значение:

Полученную меру добавляем на график и настраиваем соответствующее форматирование:

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

А что, если заказчик просит подсветить или выделить текущее значение именно на оси? Стандартно пока такой возможности нет, но можно пойти на небольшую хитрость и всё таки отформатировать значения на оси.

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

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

Добавляем созданный столбец в диаграмму и получаем:

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

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

Функция практически не отличается от предыдущей, которую использовали для дат. Главное не забыть задать сортировку по правильному столбцу.

Стало более читабельно, но хочется более ярко. Для этого можно воспользоваться функцией UNICHAR:

Вот так больше бросается в глаза:

Как видите, способов подсветить или выделить нужное значение достаточно, даже используя стандартные визуализации. Главное определить цель для чего это нужно и исходя их этого выбрать подходящее решение.

Файл пример по ссылке.

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

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

На этот раз я использую производственный календарь, который я загрузил с сайта Консультант и который учитывает не только выходные дни, но и праздничные, а также переносы выходных с ними связанные (спасибо Алексей (PooHkrd) Семилетов за создание календаря, а о том как создать календарь с помощью DAX читайте в другой моей статье).

Таблица фактов Orders содержит информацию о продажах по дням:

А вот планы разбиты по месяцам (месяц указан в формате даты первого числа месяца):

Так как и факты, и планы содержат столбец с датами, то свяжем их с календарем по дате:

Также нам понадобится несколько мер:

Перейдём к визуализации и посмотрим на меры, сначала по годам:

Затем по месяцам:

Столбец StartMonth в календаре отформатирован с помощью пользовательского формата, подробнее как это сделать можно прочитать здесь.

А теперь развернём один месяц до дней:

Факты бьются по дням, а вот месячный план весь записан на первое число месяца, так как таблица Plans связана с календарём по столбцу дат, а в самой таблице планов месяц указан в виде "01.ММ.ГГГГ".

Как показать значение плана на каждый день?

Одно из решений - это создать промежуточную таблицу уникальных значений "Год-месяц" или "StartMonth" и связать таблицу планов с календарём через неё.

Так как у меня планы БЕЗ какой-либо разбивки, кроме месяцев, то мне такая таблица не нужна и я просто могу связать столбцы Plans[Month Plan] и Calendar[StartMonth]:

А так как поле Calendar[StartMonth] содержит повторяющиеся значения, то необходимо будет установить двунаправленную связь, чтобы можно было передавать фильтр из календаря и в факты, и в планы:

Теперь план есть на каждую дату, но всё ещё является некорректным, так как это значение месячного плана, а не дневного. И здесь также есть несколько решений:

• разделить на количество дней в месяце ДО загрузки в модель
• разделить на количество дней в месяце в мере

Воспользуемся вторым способом, а за одно и откажемся от промежуточных таблиц, посчитав планы на каждую дату с помощью меры, при этом связь будет использоваться Calendar[Date]->Plans[Month Plan].

С помощью функции ALLEXCEPT оставим фильтр по таблице дат только по столбцу StartMonth.

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

Но, как всегда, есть нюансы - в строке итогов теперь план на день. Это можно обработать с помощью функции ISINSCOPE:

А можно добавить более универсальную обработку:

Теперь, если в фильтре будет выбран не полный месяц, то и в строке итогов будет считаться план на выбранное количество дней:

Я же просто создам новую меру:

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

Всего в ноябре 2022 года был 21 рабочий день и 9 выходных в том числе 4-е число пятница - День народного единства. Как видно на скриншоте, при распределении плана на все дни месяца и только рабочие дни - кардинально меняется результат.

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

Ссылка на скачивание файла с мерами.

Разобраться в работе контекста в языке #DAX бывает не просто. Иногда кажется, что вот - уловил уже суть, но вдруг получаешь результат, который не можешь объяснить.

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

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

За основу возьмём всю ту же модель данных:

Единственное, по какой-то причине в таблице фактов добавлен столбец Category, который соответственно содержит названия категорий товаров:

Хотя у нас есть информация о категориях товаров в связанной таблице Products:

Также в модели создана мера, которая считает количество единиц проданного товара:

На листе отчёта создадим визуальный элемент Таблица и добавим в него столбец Category из таблицы Sales:

Для того, чтобы отобразить визуальный элемент, движку PowerBI необходимо вычислить таблицу, которая получается в результате группировки. Чтобы посмотреть как это происходит, воспользуемся функционалом анализатора производительности (вкладка "Представление" - "Анализатор производительности" - "Таблица" - "Запрос DAX" - "Копировать запрос")

Далее скопируем запрос и вставим его в DAX Studio:

Я убрал лишние строки, где результат запроса ограничивается на 500 строк, т.к. это никак не влияет на результат

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

Но заказчик хочет видеть информацию только по категории Bikes, поэтому добавим в панель фильтров соответствующие условие:

Только вот в фильтр мы добавили столбец CategoryName из таблицы Products, но в визуализации отображается ожидаемый результат в виде одной категории.

Посмотрим на текст запроса:

Для отображения таблицы по прежнему используется функция DISTINCT, но на этот раз она обернута в функцию CALCULATETABLE, с помощью которой добавляется контекст вычисление с фильтром по таблице Products, который передаётся по связи между таблицами.

А теперь добавим в визуализацию меру:

И сразу посмотрим на код запроса:

Результат по прежнему тот, который мы ожидаем - в таблице отображены продажи по одной категории товаров. Но вот функция, которая формирует таблицу для отображения изменилась. Вместо DISTINCT теперь используется функция SUMMARIZECOLUMNS.

Но, прежде чем обратиться к описанию данной функции, создадим новую меру, практически идентичную текущей, за исключением того, что в неё добавлена константа в виде 0:

Такой приём используется довольно часто, чтобы вместо пустоты(BLANK) показывать 0.

Скопируем визуальный элемент и заменим в нём меру, чтобы было удобнее сравнивать:

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

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

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

Или по-русски: Фильтры в SUMMARIZECOLUMNS применяются ТОЛЬКО к столбцам группировки из ТОЙ ЖЕ таблицы и К МЕРАМ.

А у нас столбец группировки и столбец фильтра находятся в РАЗНЫХ таблицах, поэтому происходит следующее:

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

И в конце немного теории и дополнительное пояснение почему же оно так работает из книги "Подробное руководство по DAX":

Контекст строки осуществляет итерации по таблице, он не фильтрует. Речь идет о построчном сканировании таблицы и последовательном выполнении той или иной операции. Обычно в отчетах нам нужны какие-то агрегации вроде суммы или среднего значения. Во время прохода по таблице контекст строки перебирает строки конкретной таблицы, предоставляя доступ к информации по всем столбцам, но только из этой таблицы. В других таблицах – даже связанных с нашей – контекст строки в этот момент не создан. Иными словами, контекст строки сам по себе автоматически не взаимодействует с существующими в модели связями.

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

Ссылка на файл с моделью.

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

Если в правилах вы задаёте числовые границы, а не процентные, то, чтобы указать нижнюю и верхнюю границу, просто очистите числовое значение в соответствующих полях (выделены синим на скриншоте), вместо указания заведомо меньших/больших значений.

При использовании же третьего способа - "Значение поля", необходимо выбрать столбец или меру, которые возвращают текстовое обозначение цвета: название цвета на английском (Red, Green, Blue и так далее), шестнадцатеричный код или HEX (#000000, #FFFFFF), либо RGB-код (0,0,0; 255,255,255).

Как видите, всё достаточно просто, не зная HEX и RGB кодов с помощью обычных слов можно задать цвет при выполнении определённых условий (правил). Но использование кодировок позволяет сделать форматирование ещё более гибким:

В том числе можно "имитировать" градиент, хотя мера получится более сложная:

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

Матрица

• Нельзя с помощью функции форматировать заголовки строк и столбцов
• Для каждой меры необходимо задавать условное форматирование отдельно

Это ограничение можно "обойти", если создать единую меру с помощью вспомогательной таблицы и функции SWITCH, но такой способ имеет свои недостатки. Подробнее в статье "Переключение/включение мер в визуализации. Часть 1".

Таблица

• Чтобы отформатировать всю строку, надо задать условное форматирование для каждого столбца отдельно.

Диаграммы

• Цвет, например столбцов в гистограмме, можно задать с помощью условного форматирования, если используется ТОЛЬКО ОДНА мера и НЕТ условных обозначений:

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

А например для диаграммы с типом "График" в текущей версии

Нет возможности задать условное форматирование для маркеров, но если сначала задать его в гистограмме, то оно применится к маркерам:

Подводя итоги: условное форматирование очень мощный инструмент, который добавляет интерактивности и информативности в ваши отчёты. Условное форматирование можно применять в большинстве визуализаций, используя как стандартные настройки, так и создавая собственные функции, учитывая выше описанные ограничения, а также возможные изменения в поведении после обновления версии #PowerBI.

Ссылка на файл и пример визуализаций с условным форматированием.

Включение параметра

По состоянию на 13-10-2022 года функция "Параметры поля" находится в предварительном просмотре и доступна только для стандартной версии PowerBI - в PowerBI Report Server она ещё не добавлена.

Чтобы добавить эту функцию, необходимо в PowerBI Desktop перейти в Параметры - Предварительные версии возможностей и поставить соответствующую галочку:

Переключение мер

Работать будем всё с той же моделью данных:

В модели созданы четыре меры:

В визуализациях будут использоваться три меры: [Продажи шт], [Кол-во заказов], [% изменения продаж].

Цель - предоставить пользователю возможность выбора просмотра какого-либо одного показателя в визуализациях.

Для этого переходим на вкладку Моделирование - Создание параметра - Поля:

В мастере задаём имя таблицы параметров и выбираем нужные меры в том порядке, в котором хотим чтобы они были в срезе:

Если потребуется изменить набор мер - добавить/удалить меры, изменить порядок их отображения или задать новые отображаемые имена, то это возможно будет сделать пока ТОЛЬКО в строке формул:

Фигурные скобки {} - краткая запись создания таблицы. В круглых скобках через запятую указывается содержание строки каждого столбца.

То есть в данном случае создаётся таблица, состоящая из трёх столбцов и трёх строк:

Столбцы имеют осмысленные названия, так как таблица параметров создавалась с помощью мастера.

Если вы не сняли в мастере галочку "Добавить срез на страницу", то на странице появится соответствующий срез:

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

Создадим две визуализации: гистограмму и таблицу с разбивкой по месяцам, в которые вместо мер поместим столбец с показателями из таблицы параметров. А также добавим срез по годам:

Как видно, пока в срезе показателей не выбрали какое-то значение - в гистограмме и в таблице показываются все три меры. И если в таблице это приемлемо, то в диаграмме, из-за разности показателей - числа и проценты, значения искажаются. Поэтому изменим тип среза на "Единичный выбор":

Теперь всё работает как надо. В отличие от метода со SWITCH - нет проблем с форматами, так как передаётся мера и её форматирование. В отличии от SWITCH и Calculation group практически не требует использования DAX - основное можно сделать с помощью мастера. Тем не менее, есть небольшая ложечка дёгтя - параметр поля, который отвечает за переключение мер, НЕЛЬЗЯ поместить в строки или столбцы матрицы, чтобы изменить порядок группировки, как я это сделал в статье "Как показать меры в строках матрицы?"

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

Переключение измерений

Кроме переключения мер, Field Parametrs можно использовать и для переключения измерения, по которому построена визуализация. Принцип создания параметра идентичен созданию переключателя мер:

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

Как только пользователь выбирает интересующие его измерения, они добавляются в визуализацию в ПОРЯДКЕ ВЫБОРА. Например, я сначала выбрал CategoryName, а затем Year:

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

Но, срез, который представлен выше, имеет один "недостаток" - он содержит измерения, относящиеся к разным сущностям(иерархиям): даты и товары. И хотелось бы дать пользователю возможность переключаться между иерархиями одним нажатием, а не собирать каждый раз все уровни, которых может оказаться значительно больше.

Чтобы выполнить это условие, отредактируем таблицу переключения измерений, созданную с помощью мастера:

В строке функций я добавил для каждой строки таблицы ещё один столбец, который будет объединять измерения в нужные иерархии. За одно дал русские названия для измерений, которые отображаются в срезе:

То есть теперь пользователь может, как и прежде, выбирать нужные ему измерения в нужном ему порядке, либо включать целую иерархию одним нажатием. Либо мы можем оставить возможность менять только иерархии:

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

Файл можно скачать по ссылке.

Воспользуемся простой моделью из предыдущей части:

Как скрыть будущие месяцы/даты?

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

Добавим созданную меру в визуализации:

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

Но более гибкий и простой способ - это создать в календаре специальный столбец "завершённый период", то есть пометить все даты, которые уже прошли:

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

Как сравнить с предыдущей неделей?

В DAX много функций Time Intelligence, но все они работают с четырьмя стандартными измерениями: день, месяц, квартал, год. Для того чтобы работать с другими типами измерений, например - неделя, требуется написание собственных функций. Чтобы облегчить решение задачи сравнения с предыдущей неделей, добавим в календарь сквозную нумерацию недели:

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

Далее остаётся написать достаточно простую меру, которая будет считать продажи за предыдущую неделю:

Добавим полученную меру в визуализацию:

Мера отлично работает, кроме "пересекающихся" недель при смене года, когда для последней и первой недели года показывается одинаковое значение. Для решения этого вопроса прежде всего необходимо определить бизнес логику, как смотреть/сравнивать недели. Возможно, решением будет смотреть не на "год-неделя", а также на сквозные недели. Или работать с неделями ISO и относить "остаток" недели или к последней неделе, или к первой неделе года. Если же хочется сравнивать сопоставимые по количеству дней значения, то, выше указанную меру, можно ещё немного доработать:

Теперь последняя и первая неделя года вполне сопоставимы с предыдущей неделей, а дополнительно мы сможем сравнивать и неделю с неделей даже выбрав определенные дни недели.

Как сравнить 10 дней с предыдущими 10 днями?

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

Создаём меру:

Проверяем в визуализации:

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

Сформулируем его следующим образом: продажи за БЛИЖАЙШИЙ аналогичный период - с таким же набором дней недели.

Корректируем меру:

Проверяем работу меры:

Теперь у нас полностью сопоставимые периоды, которые начинаются с одного дня недели.

Как показать предыдущие N дней, недель месяцев...?

Ещё один довольно часто встречающийся сценарий, когда пользователь не хочет проставлять множество галочек выбирая нужный диапазон, а хочет указать начальную или конечную точку (дату, месяц), а в визуализации чтобы отобразилось N предыдущих/следующих значений.

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

Например: на странице установлен фильтр по текущему месяцу, но при этом в одной из диаграмм необходимо показать помесячную динамику с начала года:

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

Итак, создадим копию справочника "Календарь":

Заменим в диаграмме поле [Year-Month] из основного календаря на такое же поле из дубля:

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

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

Проверяем в визуализации:

Как видите, в зависимости от выбранного месяца меняется и динамика по году.

Как сравнить произвольные периоды?

Для решения данной задачи также необходимо наличие второго календаря.

Создадим два среза, в которых будут выбраны периоды для сравнения:

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

Результат:

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

Посмотреть отчёт можно ниже:

А также ссылка на скачивание файла.

PS Оставляйте комментарии с кейсами по работе с датами, которые кажутся вам интересными или у вас не получается решить. По возможности или дополню статью, или напишу новую ;-)

Я сознательно хочу упростить определение контекстов, не вдаваясь в витиеватые формулировки - всё это можно легко "нагуглить" или прочитать в книгах. Также я не буду разбирать тонкости построения моделей и связей, хотя они могут влиять на создание контекста вычисления - просто возьмём за аксиому, что модель имеет схему "звезда", все связи однонаправленные и один ко многим.

Возьмём простую модель о продажах:

Создадим простую меру и добавим её в визуализацию "Матрица":

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

Добавим на страницу срез по полу(Gender) покупателей (Customers) - отберём только женщин:

Это вычисление уже можно представить как отфильтрованную таблицу из двух столбцов:

Чтобы узнать: Сколько покупают женщины по понедельникам? - добавим в панель фильтров соответствующий фильтр:

Наша "виртуальная" таблица снова расширилась. В ней появился новый столбец - NameDayWeek, отфильтрованный по понедельнику:

А товары из каких категорий женщины покупают по понедельникам?

Названия категорий (CategoryName) мы добавили в строки матрицы - это НЕ является фильтром для ДАННОГО ВИЗУАЛЬНОГО элемента (если выбрать строку в этом визуальном элементе, то значение строки измерения будет фильтром для других визуальных элементов), НО является фильтром для меры.

Каждая ячейка визуального элемента вычисляется НЕЗАВИСИМО от других в СВОЁМ контексте вычисления.

В соответствии с выше описанным правилом для ячейки со значением 4271 фильтром является CategoryName="Accessories", а в "виртуальную" таблицу добавляется ещё один столбец:

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

Таким образом можно сформулировать, что перед вычислением меры, сначала вычисляются все внешние фильтры, которые складываются в единый фильтр, как логическое "И": И женщины, И понедельник, И Accessories, И 2017 - после чего происходит агрегирование оставшихся значений. Если все выше полученные фильтры интерпретировать в код, то мы получили бы следующую меру:

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

Создадим новую меру и поместим её в такую же матрицу:

В нижней матрице теперь отображаются продажи женщинам по понедельникам только товаров красного цвета. А код интерпретации выглядит следующим образом:

В интерпретации кода теперь присутствуют две функции CALCULATE. Это ещё одна аксиома: в мере ВСЕГДА по умолчанию есть функция CALCULATE. Также видно, что в нижней матрице исчезла категория Clothing, в которой не было продаж товаров красного цвета.

Добавим в обе матрицы в строки измерение ProductColor:

В матрице справа в строках с названиями цветов все значения одинаковые в рамках года, плюс добавились строки с цветами, по которым не было продаж. Это произошло потому, что в мере [SOQ Red] мы принудительно изменили контекст вычисления. Краткая запись ("синтаксический сахар") - 'Products'[ProductColor]="Red", на самом деле интерпретируется как FILTER(ALL('Products'[ProductColor]), 'Products'[ProductColor]="Red"). То есть, после того, как были вычислены все внешние фильтры, во внутреннем мы говорим: верни ВСЕ цвета - ALL('Products'[ProductColor]) и выбери из них красный - 'Products'[ProductColor]="Red". И как раз здесь многие начинающие запинаются, полагаясь на интуицию и применяя функцию FILTER следующим образом:

Забывая или не зная, что к внутренним аргументам фильтра также сначала применяются все внешние фильтры, а только потом внутренние. Например: к таблице Products применяются внешние фильтры по CategoryName="Accessories" и ProductColor="Black", а потом в полученной таблице мы просим найти красный цвет, но, естественно, нельзя найти красный там, где только чёрный. Если же применить функцию ALL ко всей таблице Products, то мы потеряем фильтр по CategoryName и также получим неверный результат.

Предлагаю вам в следующий раз, когда запутаетесь в контекстах вычисления, также, как и я, попробовать представить "виртуальную" таблицу, в которую вы по шагам добавляете по одному столбцу(фильтру), выбирая в них нужные значения, соблюдая порядок вычисления - от внешних к внутренним. Успехов!

P.S. Пока я писал эту статья Марко Руссо и Альберто Феррари выпустили отличное видео про контексты, со схожей, как мне кажется, концепцией объяснения:

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

Но начинающие аналитики и разработчики, особенно те, кто идёт из Excel, любят работать с одной таблицей, в которой "всё есть".

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

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

1. Как сравнить продажи текущего года с предыдущим?
2. Как посчитать долю продаж?

А в конце бонусом расскажу: как "спрятать" в фильтрах то, что не продавалось?

Как сравнить продажи текущего года с предыдущим

Для начала создадим две базовые меры для каждой модели:

Создадим одинаковые визуализации в виде таблиц по Subcategory

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

Добавляем созданные меры в визуализации и в таблице с данными из схемы "одна таблица" получаем ошибку:

Прочитаем подробности:

Для новичка такое сообщение мало что скажет, поэтому требуется пояснение:

Функции DATEADD необходимо сдвинуть каждую дату в текущем контексте (2016 год) на один год назад, но если в 2016 году для какой-то Subcategory не было продажи, хотя бы один день, то функция не будет знать откуда сдвигать данные.

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

Как посчитать долю продаж

Для расчёта доли продаж Subcategory в Category применим функцию ALLEXCEPT:

Визуализируем данные:

Как видно на скриншоте выше, результат для схемы "одна таблица" получился некорректным. Так как первый аргумент функции ALLEXCEPT это таблица, с которой удаляются все фильтры, кроме указанных после запятой. То есть в том числе был удалён и фильтр по году, таким образом мера показывает продажи категории за все года. Для схемы "звезда" всё считается верно, так как фильтр сбрасывается только с таблицы Products, а фильтр по году из таблицы Calendar по прежнему действует.

Исправим меру для схемы "одна таблица":

Проверяем:

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

Бонус: как "спрятать" в фильтрах то, что не продавалось

Одним из аргументов сторонников схемы "одна таблица" является: необходимо, чтобы срезы показывали только те значения, которые есть в данных в текущем контексте, а не весь справочник.

Слева на скриншоте срез из схемы "одна таблица" - он содержит только те Subcategory, по которым были продажи. Справа срез из схемы "звезда" - это полный справочник товаров, даже те, по которым не было продаж. Если вам не нужна такая информация, то эти товары лучше фильтровать ДО загрузки в модель. Но "лишние" Subcategory будут оставаться, если мы будем в отчёте схемы "звезда" фильтровать не только товары.

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

С одной стороны - это решает проблему:

А с другой, это приводит к усложнению действий контекста - из-за того, что теперь фильтры по связям распространяются на все таблицы, проходя через таблицу Sales. Например, перестала работать мера, которая считает сумму продаж за предыдущий год:

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

Далее помещаем меру в фильтры визуального элемента и выбираем: "не является пустым" - Применить фильтр

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

Надеюсь эти три небольших примера сравнения убедили вас, что схема "звезда" лучшее решение относительно схемы "одна таблица".

Если вы хотите более подробно изучить моделирование данных в #PowerBI, то рекомендую сайт(sqlbi.com) и книги Альберто Феррари и Марко Руссо. Кстати, почти все они переведены на русский язык замечательным переводчиком Александром Гинько.

Ссылка на файл-пример для скачивания.

А как показать те товары, которые покупают с выбранным и отобрать из них лучшие?

Чтобы ответить на этот вопрос, необходимо доработать файл из предыдущей статьи (ссылка на файл как всегда в конце статьи).

Сначала создадим дубликат таблицы продуктов, с помощью которой будем выбирать товар:

Полученную таблицу соединим НЕАКТИВНОЙ связью с таблицей продаж Sales:

Далее создаём меру:

С помощью функции REMOVEFILTERS удаляются ВСЕ фильтры, которые применяются к таблице Sales из таблицы Products. А с помощью функции USERELATIONSHIP активируется связь со вспомогательной таблицей. Таким образом с помощью VALUES мы получаем список заказов, в которых был выбранный товар. Этот список в свою очередь выступает дополнительным фильтром для меры [Sum Orders Qty].

А затем визуализируем:

В срез добавлен столбец с наименованием из дубликата таблицы товаров 'Products Double', а в таблице столбец с наименованием из основной таблицы Products.

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

С помощью функций KEEPFILTERS и NOT "исключаем" выбранный товар.

Напоминаю: каждый аргумент фильтра внутри CALCULATE оценивается отдельно, согласно контекста вычисления.

Для наглядности вывел обе меры рядом:

Чтобы ограничить выборку сопутствующих товаров, воспользуемся встроенным функционалом фильтрации визуальных элементов.

Про более гибкий способ отобразить TopN чего-либо можно прочитать здесь

В зависимости от задачи следует выбирать соответствующую меру. Я выбрал отобрать пять лучших по сумме заказов [Sum Orders Qty], но у меня в таблице осталось только четыре наименования. Почему? Всё просто - мера [Sum Orders Qty] считает ВСЕ заказы, а не только те, в которых есть выбранный товар. Таким образом можно сделать вывод, что один из популярных товаров НЕ продаётся вместе с выбранным товаром.

Давайте изменим визуализацию, заменив меру в фильтре:

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

Отчёт, чтобы пощелкать и ссылка на файл