Старт в Power BI Desktop. У меня открыт абсолютно пустой свежий Power BI, ничем не заполненный, без шаблонов и заготовок — хотя в целом они есть, и, возможно, где-то для сокращения времени я к ним прибегу. Мы видим стандартное окно программного продукта Power BI Desktop, в котором собирается вся аналитика изначально. Desktop — десктопное приложение, бесплатное: можно для себя, даже не имея подписок и лицензий, не нарушая абсолютно ничего, скачать с сайта Microsoft, установить и пользоваться для собственной аналитики, чтобы что-то настроить, посмотреть, проанализировать. Десктопной версии для Mac на текущий момент нет: чтобы работать с Mac, нужна либо виртуалка с Windows, либо какие-то обходные пути, но напрямую Power BI работает только на Windows.
В окне есть панель инструментов с различными разделами и командами — классическая для BI, и панель слева, которая даёт несколько разделов — разные представления одних и тех же загруженных данных:

• Представление отчёта — где рисуется сам дашборд, где видны визуализации, где можно с ними взаимодействовать и настраивать интерактивность; то, что будут видеть пользователи.
• Представление таблицы — сейчас здесь пусто, потому что данных пока нет, но они появятся буквально через несколько минут. Оно даёт возможность посмотреть, что в наших данных в модели на текущий момент есть, взаимодействовать с таблицами, фильтровать, сортировать и искать какие-то отклонения непосредственно в представленных моделях данных, чтобы понять, то у нас считается или не то.
• Представление модели — здесь данные будут связываться между собой.

Во всех трёх сегодня поработаем. Снизу есть ещё два представления — запросов и табличной модели, но в них сегодня не пойдём. Справа есть три плашки: плашка с данными (здесь будет структура всех загруженных данных: таблицы, поля, меры и так далее), визуализации (характерно для представления отчёта) и фильтры (тоже для представления отчёта); вкладка данных присутствует везде, у представления модели есть ещё свойства.
Специфика дашборда. Кратко о том, что мы собираем. Собираем простенький дашборд по образовательной сфере: некоторая компания на сайте продаёт курсы — почти как мы. Эти курсы кто-то оплачивает; курсы разные — есть семинары, вебинары, непосредственно курсы разной тематики с разными стоимостями. Есть таблица с заказами этих курсов: один заказ — один курс, зашёл, нажал кнопочку «купить» и отправился в покупку. Покупка может быть совершена либо нет, поэтому есть статусы оплаты: что-то завершили, что-то не завершили, за что-то денежки пришли, а где-то пользователь повис на середине — это нам тоже важно понимать. Есть информация о заказчиках: все данные искусственные, никто от персональных данных не пострадал, совпадения случайны — имя, фамилия, идентификатор. Есть информация о менеджерах, которые связываются с заказчиками по работе над заказом. Есть промокоды на скидку — на разные образовательные мероприятия часто есть свои промокоды. И есть товары — товарными мы называем наши образовательные мероприятия, у них есть категории: курсы, вебинары, семинары. Механика примерно такая, как у каждого, кто когда-нибудь покупал курс или небольшой образовательный продукт.
Подключение к базе данных. Первое, к чему подключимся, — база данных PostgreSQL. Для подключения есть кнопочка «Получить данные» на панели инструментов; её же можно найти в самом Power Query, когда провалимся, и в разных других местах — она рассеяна везде, мимо неё не пройдём. Здесь есть список некоторых часто используемых вариантов коннекторов и «Другие», откуда виден полный список, сгруппированный по категориям. Нам понадобится одна из баз данных — конкретно PostgreSQL. Чтобы подключиться к базе данных, необходимо знать про неё сервер, порт, саму базу данных и иметь логин, пароль с доступом как минимум на чтение нужных таблиц. Здесь у меня уже есть сервер, порт, база данных — подключаюсь. Есть возможность писать SQL-запросы; сегодня этого не коснёмся, но такая опция есть — этими запросами можно получать данные уже преобразованными, как нужно. Мы подключаемся без них. Если подключаюсь к базе данных впервые, он запрашивает логин и пароль; но так как база рабочая и я подключаюсь к ней достаточно часто, логин и пароль не запросил и в базу пустил — в рамках одной моей учётной записи ПК пароли внутри сохраняются, повторно их вводить не нужно.
Выбор таблиц. Намеренно не захватываю менеджеров и продукты — их заберём из файлов, чтобы рассмотреть вариативность подключения. Итак, берём заказы, заказчиков, статусы оплаты, промокоды и категории — пять таблиц. Я их выбрала в навигаторе; на каждую таблицу виден предпросмотр. Можно сразу нажать «Загрузить» — тогда они проскочат через Power Query, обогатятся какими-то минимальными автоматически добавленными преобразованиями и приедут в модель сразу, но это не входит в наши планы. Поэтому нажимаю «Преобразовать»: сделаем то же самое, но вникнем в процесс. Открывается второе окно Power Query; эти окна могут работать параллельно, друг друга не блокируют — я могу работать и там, и там. Единственное: все изменения, которые делаю в Power Query, нужно применить, чтобы они попали непосредственно в модель Power BI.
Знакомство с Power Query. Окно отчасти похожее: та же панель инструментов, те же вкладочки — типичная схема для всех продуктов Microsoft, загляните куда угодно и получите примерно такую же конструкцию. Слева находятся запросы: все запросы нашего файла Power BI будут храниться в одном Power Query — на каждый файл своя область; можно открыть пять разных окон и наблюдать, что происходит. Не все запросы могут прогружаться в модель: какие-то могут быть внутренними, исключительно промежуточными. У каждого запроса есть свои шаги преобразования. Если бы в навигаторе нажали сразу «Загрузить», те шаги, которые сейчас здесь прописаны, применились бы, и таблица загрузилась бы без нашего вмешательства.
На таблице с БД преобразований минимум, потому что они уже в том виде, в котором нужны BI. Самый простенький запрос — на категории товаров (курсы, вебинары, семинары), у него два шага; с двумя сильно не разгуляешься, но шаги кликабельные, и щелчок на каждый шаг показывает предпросмотр того, что на этом шаге сделано. Два шага соответствуют тому, что мы делали в самом Power BI: подключались к данным и потом выбирали в навигаторе таблицу. В строке формул показывается подключение к источнику — здесь подключение к БД по конкретному адресу; с другим подключением, другим источником будет написано что-то другое. Вторым шагом предпросматриваем и видим тот же список таблиц, которые видели в навигаторе; шаг навигации выбирает конкретную таблицу из этой БД. Аналогично у всех остальных — только в шаге навигации выбрана какая-то другая таблица. Эти таблицы пока оставляем как есть.
Подключение к файлам. Нам нужно подключить ещё две таблицы — с менеджерами и с продуктами; они хранятся в файлах. Можно это сделать из самого главного окна Power BI, а можно из Power Query создать источник — окно будет то же самое. Нам нужен файл текстовый или CSV и путь к этому файлу: это менеджеры. Здесь другое подключение и другой вариант навигатора — для каждого подключения свой вариант; автоматически определилось с кодировкой, с разделителем, и файл принял вполне приемлемый вид. Принимаем. Появляется новый запрос, и шаги у него уже свои: в источнике — путь к файлу; в повышенных заголовках первая строка CSV переехала в заголовки; третьим шагом Power Query автоматически типизировал все столбцы. Ещё один источник — тоже файл, тот же тип, та же папка, только там были менеджеры, а сейчас будут продукты. Несмотря на то, что там был CSV, а здесь XLSX, механизм очень похожий: оба файла обрабатываются по одному и тому же принципу, разве что в параметрах есть некоторые нюансы.
Итого семь таблиц — практически полная информация, которая нужна для дальнейших действий. Единственное, что сейчас сделаю, — приведу в порядок названия, чтобы в них ориентироваться и не было лишних слов: заказы, заказчики, статусы оплат, промокоды, категории продуктов, менеджеры и продукты. Чтобы эти семь таблиц попали в Power BI, нажимаю «Закрыть и применить» — произойдёт загрузка, все шаги, которые были прописаны у каждого запроса, применятся, и данные загрузятся непосредственно в модель и покажутся в «Данных» в виде этих семи таблиц. Визуализация пока пустая, но в табличном виде мы уже можем походить по таблицам и посмотреть, что там хранится. В модели теперь присутствуют схемы таблиц, но со связями будем разбираться чуть позже, на следующем этапе.
Преобразования. Данные загрузили, но практически никак не коснулись преобразований. Возвращаемся в Power Query и смотрим, какие преобразования нужны. Попасть в него можно несколькими способами: из любого запроса через «Изменить запрос» либо с панели инструментов «Преобразования данных» с любого раздела — так или иначе в Power Query попаду.
В заказах есть лишние столбцы. В БД я не все таблицы перечислила: там ещё есть информация о прохождении самих курсов, о том, как заказчики участвуют в занятиях, какие рейтинги получают, и так далее — нам эта информация сегодня не нужна. В таблице с заказами нажимаю на панели инструментов «Выбор столбцов» и снимаю галочки с ненужных, оставив, по сути, набор айдишников для связи со всеми остальными таблицами, дату заказа и идентификатор заказа. Столбцов стало меньше.
В таблице с промокодами процент скидки представлен вот таким числом: 11 процентов представлено как 11. По-хорошему, по правильному, 11 процентов должны быть представлены процентами. Дело даже не в том, что нарисуется значок с процентами, а в том, что это должно быть 0,11, а не 11: оперируя таким числом, нам придётся каждый раз помнить, что надо поделить на 100, а это не очень правильно. Поэтому делим на 100 сразу. Создаём дополнительный столбец — этот можно оставить, но можно удалить. Для создания дополнительного столбца отправляемся на панель «Добавление столбца» и добавляем настраиваемый столбец. Здесь как раз пригодится написание формул — не из серии «поделить на 100», как сейчас, но в целом для написания этих формул очень полезно знать, какие в принципе возможности у Power Query есть: порядка 700 различных функций, которые можно использовать очень по-разному; какие-то из них зашиты в кнопки, но очень многие — нет. Создаём столбец, называем его «Процент скидки»: он будет очень простой — берём из доступных столбцов наш процент и делим на 100. Если бы я делала аналитику по правильному, я бы ещё прошлась по всем столбцам, всё переименовала так, чтобы это билось и называлось идентично везде, но сейчас не буду тратить на это драгоценные минуты вебинара. Поэтому оставляем немного неконсистентное формирование названий.
Когда я добавляю столбец, он у меня по умолчанию не типизирован. Здесь я бы очень хотела рекомендовать следить за типами данных и присваивать их всем столбцам без ограничений и исключений. Тип данных можно прописать прямо в формуле добавления столбца либо поменять, просто нажав на пиктограмму типа данных у столбца. Итак, «Процент скидки» — и в принципе пока всё.
Был в планах ещё календарь, но календарь оставим на попозже. Чтобы эти изменения попали в модель, нужно нажать волшебную кнопочку «Закрыть и применить».
Вопрос из чата: если Power Query не определил тип данных и показывает ошибку, что делать? Power Query по умолчанию пытается определить тип данных у загруженных данных: если вы данные загружаете, он, как правило, их определяет; если определить не может, всё отправляет в текст. Текст — такой универсальный тип, в который можно засунуть всё что угодно. За этим надо следить, потому что он может отправить в текст то, что текстом не является, или как-то ещё определить автоматически некорректно. Поэтому контролируем это — первый момент. Если показывает ошибку, есть два варианта: либо он на самом деле определил тип и сам промахнулся, либо у вас в принципе ошибочный тип подъехал — надо смотреть, что у вас в исходных данных. Если появляется какая-то ошибка в ячейке, вы можете щёлкнуть в пустом месте — и там, где вывелось значение, выводится причина ошибки, и вы с ней работаете. С ошибками можно ещё по-разному работать: по-разному их выуживать, отслеживать и нейтрализовывать, есть такие инструменты.
Пока преобразовали немного, но преобразовали: в таблице с промокодами появился дополнительный столбец «Процент скидки», и он теперь представлен числом 0,11. На этом эту фазу завершим. Повторюсь, календарик мы не сделали, но если будет опция в конце — вернёмся. Он, конечно, очень нужен, но я рискую не вписаться в полтора часа, поэтому экономим на чём можем.

Возвращаемся в Power BI. У нас вот такой набор таблиц, и здесь достаточно классическая «снежинка», ну даже почти «звезда». У нас есть заказы — это таблица фактов, такая, скажем, неопоримая, и набор таблиц измерений, или справочников: заказчики, менеджеры, категории продуктов, продукты, промокоды, статусы оплат. Всё это относится к заказам по соотношению один ко многим: на одного заказчика может быть один или несколько заказов, на одного менеджера тоже; у заказа только один заказчик, только один менеджер, только один продукт, промокод и статус. Из такого принципа мы сейчас настраиваем связи.
Связи настраиваются достаточно просто технически — их не просто продумать, но настроить буквально минуты. У нас есть какое-то поле в одной таблице и какое-то поле в другой, и связь настраиваем, по сути, перетаскиванием поля над полем. Можно, конечно, открыть диалоговое окошко и там всё выбрать в списках, но здесь кому как удобней. Когда настраиваем связь, открывается окошко, где видим выбранный столбец с одной таблицей и выбранный столбец с другой; если промахнулись — корректируем, но глазками контролируем, что столбцы содержат одно и то же. Это важно. Во-первых, связывать таблицы можно только по одному столбцу: связь в принципе подразумевает только один столбец в одной и в другой таблице раз. Второй момент: тип данных должен быть одинаковый железобетонно. Если у нас в одной таблице Power Query интерпретировал столбец с ID как число, а в другой почему-то решил, что это текст, или мы так решили, то связь, конечно, свяжется, нарисуется, но работать не будет, и вы об этом узнаете, когда будете строить дашборд и не будете понимать, а что у нас и почему всё так.
Заказчики к заказам — один ко многим, оставляем направление перекрёстной фильтрации в обе стороны, связь будет активной. Есть ещё неактивные связи — тоже отдельная история. Сохраняем — рисуется стрелочка с двумя направлениями. По образу и подобию, уже не сильно поясняя, связываем менеджеров — один ко многим, оба сохранить; категории продуктов — они относятся к продуктам, продукты — к заказам, это вот та самая часть «снежинки»; промокоды — то же самое; статусы оплат — ID. Простое техническое действие. Но для того, чтобы собрать именно такую модель, нужно, чтобы таблицы к нам приехали вот в таком виде, чтобы мы такую модель собрать смогли. Потому что чаще всего, когда мы начинаем работать с таблицами, а не с проектирования модели, мы получаем набор таблиц и не понимаем вообще, как это связано. К этому надо подходить осмысленно. Вот она, наша модель — классическая «снежинка». Запомнили, идём дальше.

Пойдём на представление данных, представление таблиц, где непосредственно наши таблицы. Начнём с создания столбцов. Сейчас начну тихонько ускоряться и не буду писать формулы от руки — одну напишу, остальные по образу и подобию, потому что в полтора часа очевидно не впишемся.
Сумма заказа. Идём в заказы и обращаем внимание на следующую штуку: у нас в заказах нет денег. А где они есть? Деньги есть только в одном месте — в продуктах: у продуктов есть стоимость по прайсу, в соответствии с этой стоимостью курс выложен на сайте. Чтобы посчитать стоимость заказа, нужно учесть несколько вещей. Во-первых, каждая строчка заказа — это отсылка на какой-то продукт: я взяла рандомный, это 17-й продукт, то есть у него где-то в соседней таблице ценник есть. Но этот 17-й продукт продали с какой-то скидкой по промокоду — здесь промокода нет, окей, здесь нет скидки, но где-то там внизу они точно есть, а продали со скидкой. И более того, возможно, не дошли до нас деньги, потому что у нас есть три статуса оплаты, и только один из них успешный. Соответственно, чтобы посчитать итоговую сумму заказа, надо учесть стоимость по прайсу, учесть промокод на скидку, если он есть, и учесть статус оплаты: только в случае успешности статуса мы можем на какую-то сумму претендовать.
Создаю столбец «Сумма заказа». Начну с простого и буду наращивать вычисления по мере логики. Первое: вытащим ценник из продуктов, тот, который по прайсу. Так как продукты с заказами связаны, у нас есть функция, которая вытаскивает значения; их, на самом деле, две, они работают в разную сторону. Есть RELATED — вытаскивает значение из связанной таблицы в том случае, если оно единственное, то есть с той стороны, где связь один ко многим и стоит единичка: с той стороны мы можем вытащить значение, потому что оно априори должно быть единственным, если оно в принципе есть. RELATEDTABLE работает в обратную сторону, но обязательно с агрегацией. Я написала функцию RELATED, открыла скобочку — и у меня перечень всех полей, доступных мне в контексте этой функции; мне нужны продукты, мне нужна стоимость по прайсу. Скобочку не забываем закрывать. Я выбрала из списка, не писала ни кавычек, ни скобок. Из таблицы с продуктами колонка «Стоимость по прайсу» — для каждого продукта приедет значение. Нажимаю Enter и могу сходить в соседнюю таблицу и убедиться, что у 17-го продукта цена 37 500 — не больше, не меньше, это та сумма, которая пришла бы нам, если бы не было скидок и статусов оплаты. Но они есть.
Теперь учтём скидку. У нас есть промокоды, они тоже есть идентификаторы, не везде они есть, но по тому же принципу, что и стоимость продукта, мы можем вытащить скидку по промокоду и на неё умножить. Но умножим не на саму скидку — нам нужна единица минус скидка. Дальше — таблица с промокодами и наш процент скидки, который мы создавали в Power Query. Скобку закрыла, сейчас RELATED. Теперь что получилось: та цена по прайсу, которая была, умножается на единицу минус процент скидки — осталась та сумма, которая за вычетом скидки. В том случае, когда промокода нет, здесь просто будет пустота, и у нас останется единичка. Нажал Enter — выглядит так, как будто ничего не поменялось, но потому что промокода здесь нет. Если долистаем туда, где промокоды должны добавиться, — вот они, тут уже не такие ровные циферки, и мы понимаем, что скидка тут посчиталась.
Возвращаемся обратно. Мы учли два фактора, у нас ещё есть третий: статус оплаты. Мы должны посчитать сумму заказа только для ситуации, когда статус оплаты успешный. Сходим в таблицу со статусами оплаты и увидим, что у нас есть поле, отвечающее за успешность. Если для нашего заказа у статуса оплаты это поле true — то мы считаем, иначе не считаем. Здесь мы можем использовать функцию IF — она есть абсолютно, наверное, во всех языках программирования, где-то чуть различающихся вариантах синтаксиса; принимает все три аргумента: первое — утверждение, которое мы проверяем (статус оплаты истинен или не истинен), второй — то, что возвращается в случае, если проверенное утверждение истинно, и третий — если нет. Возвращаемся в заказы, в нашу формулу. Когда щёлкаем на столбец, высвечивается формула, мы можем её редактировать. Я сейчас эту штуку вырежу, то есть сохраню в буфере — главное не стереть, — и напишу следующее: IF, открываю скобку, у меня подсвечивается три аргумента — логическое выражение, результат если истинна и необязательный результат если ложь; если третий аргумент не указываем, получаем blank, пустое значение. Логическое выражение: опять же, та же функция RELATED — из статусов оплат вытаскиваем поле is_success. Если вот эта истина — то вставляем наше вычисление, и закрываем скобку, потому что ничего, кроме пустоты, нам на второй вариант возвращать не надо. Теперь у нас в строчках, где статус оплаты не успешный, такая веющая пустота, а мы посчитали сумму заказа.
Сумма заказа без учёта скидки. Скопирую, создам ещё один столбец — теперь чуть меньше пояснений — «Сумма заказа без учёта скидки». Она пригодится потом для визуализации. Это означает, что мы вот эту часть уберём — будет только стоимость по прайсу с учётом статуса.
Сама скидка. Создам столбец «Сама скидка». Копируем формулы (и не надо их копировать). Для успешных статусов — стоимость по прайсу, но без единички.
Упущенные заказы. Последняя формула, которую здесь добавлю, — «Упущенные заказы». Это как раз неуспешный статус оплаты: если статус оплаты не успешный, то берём стоимость по прайсу со всеми скидками, промокодами и прочим. Упущенные должны появиться там, где основной нету, где у нас сумма заказа пустая, — там у нас есть упущенная.
Заказчик (в таблице заказчиков). Одна колонка для заказчиков — она нам пригодится. У нас имя и фамилия в разных столбцах, мы сольём в одну строчку. Создаём также столбец в этой таблице — «Заказчик»: открываю квадратную скобку, пишу — и у меня подсказки столбцов из этой таблицы — Last Name, объединяем с пробечиком и объединяем с именем. Можно в обратной последовательности, дело вкуса.
Со столбцами закончили. Мы видим, что они физически появились, физически посчитались для каждой строчки наших таблиц, для которых мы их считали. А меры давайте создадим в момент, когда будем визуализировать, чтобы у нас сразу эта конструкция складывалась и её сразу можно было посмотреть.

Визуализация будет достаточно простой: набор срезов, пара карточек и буквально четыре графика.
Срезы. Начнём со срезов. Календаря у меня нет — я его не добавила; ладно, выкрутимся пока без него, но не всё я построю — сейчас мы уже в экономном режиме. Визуализация добавляется достаточно просто: щёлкаем, находясь в пустом месте дашборда, добавляется заготовка под график. Вынесем сюда единственную дату, которая есть в заказе: из даты вытащим год, вытащим месяц. График резко переобулся — сначала показывал диапазон, сейчас уже выпадающий список. У каждого графика, когда он выделен, доступны три вкладки: на первой настраивается состав данных, который будет в этом визуальном элементе; на второй — то, как он будет выглядеть визуально (там целое дерево вкладок); на третьей для некоторых визуальных элементов (для срезов недоступно, для гистограмм доступно) — разные статистические константы, линии, которые можно нарисовать отдельно, то есть пошла статистика. Зайдём во вторую вкладку и сделаем следующее: параметры среза поставим «раскрывающийся список». И ещё сокращу весь график-срез до нужных мне размеров и скопирую несколько раз. Дальше добавим сюда категории, наименование товаров. Я скопировала, чтобы не настраивать больше размер, удалю. Теперь отсюда поле с датами вытащу, из категории продуктов — название продукта и категории, из продуктов — сам продукт; когда мы вытаскиваем два поля, у нас получается иерархия. Из значений дальше копируем ещё раз, двигаем, ставим рядышком, вынесем туда промокод — промокод у нас в промокодах, сам код. Сделаю ещё четвёртую заготовку; тут исходя из размера — под 6, не под 6, под 5 нет, под 6, всё правильно. Здесь ещё два, но они появятся чуть позже, а здесь вместо промокода мы положим менеджеров. Вот такие у нас четыре среза.
Меры. Дальше идём в меры — те самые, которые пропустили на предыдущем этапе. Я добавлю таблицу: нажму «Введите данные», ничего вводить не буду — всех обхитрю, создам таблицу, и она будет пустой. Назову её «Меры», нажму «Загрузить», и она прокатится через Power Query, как ни странно. Появилась вот такая таблица «Меры», и теперь я в этой таблице создам меру. Мера создаётся в привязке к таблице: у неё таблица как контейнер, но смысла в этом никакого нет — без разницы, в какой таблице будет храниться мера, она из любой таблицы будет вести себя одинаково, она как бы сквозная через весь дашборд. Напишу очень простую меру: «Сумма продаж» — будет суммировать колонку в таблице с заказами, сумму заказа. Нажму Enter — добавилась мера, у неё такой специфический значок, не такой, как у столбцов. И теперь, когда у меня есть первая мера, я у этого столбца 1, который пустой, нажму «Скрыть» — и Power BI поймёт, что эта таблица создана под меры, присвоит ей определённую иконку и утащит её на самый верх, независимо от того, как она называется и как она по алфавиту должна быть. По образу и подобию добавлю ещё несколько мер: «Сумма продаж», «Сумма скидок» и аналогично «Упущенные продажи» — вот таким образом три меры.
Карточки. Добавим карточки, растянем их на три графика и эти три наши меры сюда вытащим: сумму продаж, сумму скидок и упущенные продажи. Появится вот такая конструкция. Чуть подтянем её по высоте — хватит ей сотни; можно поиграться с цифрами, настроить оформление, как это всё будет выглядеть.
Гистограмма с переключателем показателей. Дальше я хочу настроить гистограмму: на оси X будут месяцы — скажем, год и месяц, — а на оси Y один из трёх показателей; хочу, чтобы была переключалка этих показателей. Как это сделаю? Пойду на вкладку «Моделирование» → «Создание параметра». Создадим параметр, назовём его «Показатели», и вот сюда в окошечко накидаем наши примеры: сумму продаж, сумму скидок, упущенные продажи. Создаём. У меня добавляется вот такая таблица (она тоже выглядит немножко с другими значками), появляется срез и появляется вот такое интересное вычисление, которое показывает, что у меня будет фильтр на мои показатели и будет отсылка этого фильтра на разные меры. Я теперь этот срез привожу к виду — говорю, что это будет раскрывающийся список размером 80 на 320, — вот сюда он у нас падает. И теперь на этот график, где уже на оси X у меня живёт год и месяц, я вытаскиваю «Показатель». Получилась интересная конструкция — просто потому, что у нас тут куча лет; давайте возьмём какой-нибудь один год, поставим 24-й. Что я вижу: я вижу сумму продаж — маленькую плашечку, это сумма скидок; то есть если бы мы не давали скидок, мы бы заработали вот на эту синюю полосочку больше. И оранжевым я вижу упущенные продажи. Здесь сейчас расцветка по умолчанию, стандартная какая-то схема стоит — чуть позже поменяем. Я могу видеть все три, а могу какой-то один — то есть я могу переключать те показатели, которые у меня есть на визуализации. Очень классная штука, которую очень часто заказчики просят в дашбордах. Добавим сюда метку итога, например, чтобы у нас какая-то циферка здесь была.
Линейчатая диаграмма с детализацией. Дальше я, например, хочу сумму продаж, но теперь сумму продаж в разных разрезах — то есть теперь параметр не показателя, а детализации. Та же самая конструкция: «Моделирование» → параметр поля, только теперь это будет не «Показатель», а «Детализация». В эти детализации — в разрезе чего я хочу смотреть на продажи — хочу в разрезе промокодов, продуктов, менеджеров; давайте категории продуктов, добавим четыре поля. Создаю. У меня добавляется ещё один такой же срез; мы уже помним, что с ним надо сделать: раскрывающийся список 80 на 320 и утащить в правый угол. Но так как мы пропустили фазу переименования полей и приведения их к человеческому виду, у меня в списке они называются так же не очень красиво. Давайте мы их найдём — это наша таблица с детализациями: «Промо коды» — прямо так и напишем, мы можем редактировать то, как будет названа наша детализация в списке: «Промокод», «Наименование» — ну, можно просто «Продукт», «Продукт», «Менеджер» и «Категория», пускай будет просто «Категория». Закрыли. Теперь в детализации создаём ещё один график — теперь это будет линейчатая диаграмма. На ось Y мы вытаскиваем нашу детализацию (ось Y — это то, что будет у нас в категориях у линейчатой диаграммы), а на ось X вытаскиваем сумму продаж из мер — и получаем вот такую конструкцию. Сейчас это выглядит специфично, потому что детализации выбраны все; надо полагать, что мы не хотим сразу видеть в разрезе всех четырёх — и в принципе это не очень удобно. Пойдём в настройки детализации, скажем, что у нас здесь будет единичный выбор, и, соответственно, промокод, продукт, менеджер — то есть в разрезе того, что мы выбрали, мы получаем наш показатель, добавим метки, получим в деньгах историю того, как у нас разбивалась сумма продаж по нашим категориям.
Это минимальная визуализация. Можно было бы ещё, но я уже что-то отправлю на контент и буду опубликовать уже после нашего вебинара.
Вопрос из чата: что в этом случае лучше — переименовать колонки в BI или создать доп. шаги в Power Query по замене названия колонок? Лучше и правильнее — в Power Query переименовывать, чтобы у вас в модель приезжало всё чистое и уже понятное, потому что иначе вы будете переименовывать на каждом шаге в DAX, и это будет неудобно; вы сами будете путаться, потому что названия кривые. Правильнее это всё оставить на этап обработки данных.

В самом сервисе, по большому счёту, всё крутится вокруг рабочих областей: есть рабочие области (демо, дашборды, тесты) и моя рабочая область, которая по умолчанию есть у всех. Это те самые рабочие области, в которых мы что-то публикуем и в которых непосредственно работаем. Выберем, скажем, «Демо, дашборды», нажмём «Выбрать» — происходит публикация. После того как она пройдёт, перейдём в «Демо, дашборды» и увидим, что у нас добавилось, вот тут с такой пимпочкой, как будто что-то новенькое, свеженькое — лампочка горит. Добавилось наше демо, оно разделилось на две части: одна часть представляет собой семантическую модель — это наши связи, наши таблицы, наши вычисления; вторая — непосредственно отчёт. Если щёлкаем на отчёт, мы получаем ту нашу картинку, которую настроили, в том виде, в котором она есть. Отсюда мы можем предоставить доступ пользователям. Вот она, наша картинка, как она выглядит в вебе; сейчас он прогрузится, одумается и всё нам покажет. Она также кликабельная, интерактивная и позволяет пользователям работать с данными.
К слову, не так давно у Power BI появилась бесплатная однопользовательская веб-лицензия, которую в целом можно на себя получить. Если вы с персональными данными не работаете, для каких-то вот таких экспериментов — пожалуйста. Но она однопользовательская: вы с неё не сможете выдать доступ никому, кроме самого себя.