Power BI для аналитика: модель данных, отчёт и публикация

Коротко: из каких шагов состоит отчёт Power BI

В Power BI Desktop подключите источник через Get data, подготовьте поля в Power Query, создайте модель «звезда» и проверьте направление фильтрации. Затем задайте меры для суммы и числа броней, соберите одну страницу отчёта и протестируйте фильтры. Когда определения и права согласованы, опубликуйте отчёт и семантическую модель в рабочую область сервиса Power BI. После публикации отдельно настройте обновление и доступ к данным.

Наш вопрос тот же, что в хабе о дашборде: сколько стоят оформленные бронирования 3–9 августа 2026 года и какие группы внесли вклад? Проверка на исходной базе даёт 42 561 уникальную бронь и 3 377 874 800 ₽. Предыдущая полная неделя — 39 216 броней и 3 116 503 800 ₽, значит изменение суммы составляет +8,39%. Это учебная стоимость броней, не денежная выручка после возвратов.

Не называйте любой экран в Power BI «дашбордом». В Desktop вы создаёте многостраничный report; в сервисе есть также отдельный объект dashboard. Эти сущности имеют разные возможности и способы публикации. Для первого результата достаточно одного отчёта с четырьмя проверенными визуалами: две карточки, ряд по дням и сравнение групп.

Получение данных: не начинайте с графика

Microsoft описывает Get data как вход для файлов и разных баз. Для повторяемого отчёта возьмите таблицу или представление bookings и отдельно подготовленную таблицу с числом билетов на book_ref. В учебной базе даты сдвинуты и живут в московском времени; до расчёта дня убедитесь, что слой источника трактует время одинаково. Иначе бронь у полуночи может перейти в соседний день.

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

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

Зерно фактов: одна бронь должна остаться одной строкой

В таблице Bookings одна строка соответствует одному book_ref. В ней есть дата book_day, сумма total_amount и число билетов ticket_count, посчитанное заранее по таблице tickets. Группа ticket_bucket равна «1» для одиночной брони и «2+» для остальных. Подготовка может жить в SQL-витрине либо в Power Query, но финальный факт обязан иметь 42 561 строку за учебную неделю и столько же уникальных ключей.

Прямое соединение bookings с tickets по book_ref создаёт по одной строке на каждый билет. Если после этого суммировать bookings.total_amount, деньги у брони с двумя билетами попадут дважды. Сначала сгруппируйте билеты до одного ряда на book_ref, затем присоедините число к брони. Независимая проверка JOIN должна сравнить число строк и сумму до и после соединения.

В нашем выполненном SQL итог после безопасного JOIN остался 42 561 строка, 42 561 ключ и 3 377 874 800 ₽. Эти три числа нужны в модели как контрольный тест, а не как красивые KPI для заказчика. Если всё сошлось до публикации, при последующем расхождении можно сузить причину до обновления данных, модели или визуализации.

WITH ticket_counts AS (
  SELECT book_ref, COUNT(*) AS ticket_count
  FROM tickets GROUP BY book_ref
)
SELECT b.book_ref, CAST(b.book_date AS DATE) AS book_day,
       b.total_amount, t.ticket_count,
       CASE WHEN t.ticket_count = 1 THEN '1' ELSE '2+' END AS ticket_bucket
FROM bookings b JOIN ticket_counts t USING (book_ref)
WHERE b.book_date >= TIMESTAMP '2026-08-03'
  AND b.book_date < TIMESTAMP '2026-08-10'

Модель «звезда»: факты и измерения

Рекомендация Microsoft разделяет таблицы для суммирования и таблицы для фильтрации. В нашем случае Bookings — факт на уровне брони. Calendar содержит по одной записи на дату, а TicketBucket — две записи для групп. Стрелки от измерений к факту дают понятный путь фильтра: дата и группа выбирают строки броней, после чего меры считают агрегаты.

Календарь должен содержать все даты нужного диапазона, а не только даты с бронями. Для сравнения с прошлой неделей хватит конца июля и начала августа, но для анализа год к году нужен период прошлого года. В статье о DAX мы специально покажем, что прошлогодняя мера в нашем наборе пуста: отсутствие строк нельзя превращать в «падение на 100%».

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

Связи и направление фильтрации

В Model view проверьте связь Calendar[Date] → Bookings[book_day] и, если отдельная группа есть, TicketBucket[bucket] → Bookings[ticket_bucket]. На стороне измерения ключ должен быть уникальным, на стороне факта допустимы повторы. Неправильно назначенная кардинальность один к одному или дубли даты в календаре дадут неожиданный результат ещё до DAX.

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

После каждой связи выполните маленький тест: все даты дают 3 377 874 800 ₽, группа «2+» — 1 791 746 500 ₽, 3 августа — 452 158 300 ₽. Если выбрана группа и дата одновременно, значение должно относиться к их пересечению. Так проверяют модель, а не только её схему на рисунке.

Меры и вычисляемые столбцы решают разные задачи

Мера Amount = SUM(Bookings[total_amount]) считает сумму в текущем контексте фильтра: на всей неделе одну, после выбора группы — другую. Bookings Count = COUNTROWS(Bookings) считает строки на зерне брони. Вычисляемый столбец вроде Ticket Segment = IF(Bookings[ticket_count] = 1, "1", "2+") даёт стабильную категорию для каждой строки и пересчитывается при обновлении модели. Microsoft сравнивает эти варианты по моменту расчёта и хранению.

Не делайте недельную сумму вычисляемым столбцом факта: она повторится в каждой строке и затем ещё раз просуммируется визуалом. Не делайте группу «1 / 2+» мерой, если по ней нужен срез: срез работает с колонкой измерения, а мера реагирует на уже выбранные фильтры. Подробно эти различия разобраны в формулах DAX.

На нашей неделе Amount должен дать 3 377 874 800 ₽, а Bookings Count — 42 561. Значения сверены выполненным SQL SUM(total_amount) и COUNT(*) после проверки уникальности book_ref. Эти два числа — контроль для вашей модели: если карточка в Power BI показывает другое, ищите лишнюю связь, дубли ключа или фильтр, который пришёл со страницы.

Одна страница отчёта вместо коллекции случайных графиков

Начните с двух карточек: стоимость оформленных броней и число броней. Под ними разместите линию ежедневной суммы и столбцы для групп «1» и «2+». На первом экране читатель увидит масштаб, движение и состав. Нужна также подпись недели, московского времени и определения суммы. Без неё 3,38 млрд ₽ могут ошибочно назвать кассовой выручкой.

Линия за 3–9 августа идёт от 452,16 до 509,63 млн ₽. Это постепенный рост внутри семи дней, но из него нельзя вывести причину: день недели, изменение цен и доступность рейсов не исключены. При сравнении недель добавляйте прошлую полную неделю тем же правилом фильтрации; сравнение полной и текущей неполной недели создаст ложный сигнал.

В отчёте не смешивайте 42 561 бронь и 14 строк подготовленного агрегата. Если на визуале используете детальную таблицу Bookings, мера COUNTROWS верна; если используете 14-строчный CSV из статьи о DataLens, нужна сумма поля bookings. Подписывайте зерно источника в рабочей документации даже тогда, когда на самом экране оно кажется очевидным.

Отдельно проверьте число на первой и последней точках линии по SQL, а затем сумму всех семи точек. Первый день даёт 452 158 300 ₽, последний — 509 633 600 ₽; сумма ряда обязана вернуть общий недельный итог. Так можно обнаружить случайный фильтр, который исключил один день, даже если карточка и график выглядят убедительно. Если на одном дне нет записей, календарь должен оставить пустую дату видимой, иначе линия визуально перескочит через пробел.

Срезы и взаимодействия: тестируйте два состояния

Добавьте срез календарной даты и, если он нужен читателю, группы брони. Проверьте «все даты» и один день 3 августа: карточка суммы должна смениться с 3 377 874 800 на 452 158 300 ₽. Затем включите «2+» и проверьте групповой итог 1 791 746 500 ₽ за неделю. Если одна карточка осталась на прежнем значении, исследуйте взаимодействия визуалов и связи модели.

Срезы создают много состояний отчёта. Тест только первого экрана ничего не говорит о правильности после фильтра. Составьте маленькую матрицу: неделя целиком; один день; одна группа; день и группа вместе. Для каждого состояния сохраните ожидаемое число из SQL. Тогда новая страница или изменение связи не разрушит доверие к прежним метрикам.

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

Публикация из Desktop в сервис Power BI

Когда модель и страница проверены, используйте Publish из Desktop и выберите нужную рабочую область. Microsoft указывает, что вместе с отчётом публикуется семантическая модель. Это важное отличие от отправки картинки: в сервис попадают определения, данные модели и пути обновления, а получатель взаимодействует с ними в рамках выданных прав.

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

В сервисе можно создать отдельный dashboard из закреплённых элементов, но для нашего первого кейса достаточно report. Не делайте два объекта только ради названия. Если команда просит обзор из нескольких отчётов, тогда сервисный dashboard имеет смысл как самостоятельная верхняя страница с единым владельцем.

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

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

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

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

Альтернативы при выборе среды

Сравнивайте не лозунги, а требуемый процесс: источник, способ моделирования, обязанности по эксплуатации и права читателя. DataLens описывает цепочку подключение → датасет → чарт → дашборд. Superset строится вокруг SQL Lab, датасетов и чартов. Metabase начинает с вопросов в конструкторе или SQL. Каждая из этих систем всё равно требует согласованного определения «стоимости брони».

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

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

Типичные ошибки модели и отчёта

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

Шестая: сравнивают полную предыдущую неделю с неполной текущей. Седьмая: после публикации не проверяют обновление, поэтому сегодня показывают вчерашние данные. Восьмая: считают, что скрытие колонки или графика защищает чувствительную информацию; Microsoft отдельно различает оформление и безопасность модели. Для каждой ошибки найдите наблюдаемый тест: число строк, пересчёт SQL, фильтр одного дня, роль читателя.

Остановите выпуск, если нет владельца определения суммы. 3 377 874 800 ₽ в этой статье — стоимость оформленных броней. Финансовый отдел может использовать слово «выручка» для оплаченных или признанных сумм. Одинаковый формат валюты не делает метрики взаимозаменяемыми; расхождение нужно описывать смыслом, а не округлением.

Частые вопросы и следующий шаг

«Power BI Desktop и сервис — одно и то же?» Нет: в Desktop вы готовите модель и отчёт, сервис нужен для публикации, совместной работы и обновления. «Нужен ли DAX в первом отчёте?» Для суммы и числа достаточно простых мер, но без понимания контекста фильтра легко испортить долю или сравнение периодов. «Почему сумма выросла после JOIN?» Скорее всего, зерно стало «один билет», а метрика осталась на уровне брони.

«Можно ли держать всю логику в Power Query?» Преобразование строк и типов — да; показатель, который должен реагировать на срез, удобнее задать мерой. «Почему отчёт в сервисе старый?» Проверьте источник, учётные данные и последнее успешное обновление. «Можно ли раздать ссылку всем?» Сначала проверьте модель и права под ролью получателя; доступ к отчёту затрагивает и данные под ним.

Повторите один из контрольных SQL-расчётов в тренажёре SQL с нуля, затем прочитайте DAX на том же наборе. Если вы проектируете экран для команды, запишите входные данные, владельца и сценарии фильтрации в ТЗ на дашборд до публикации.