Power BI и база данных: прямое подключение к источникам

Многие компании в Ташкенте ведут собственные системы: интернет-магазин, учёт заказов доставки, внутренний портал. Данные таких систем часто лежат в PostgreSQL, MySQL или Microsoft SQL Server. Пока отчёты строятся через ручные выгрузки, кто-то каждую неделю экспортирует таблицы, чистит их и пересылает руководителю. Прямое подключение Power BI к базе убирает это звено: отчёт берёт данные из источника и обновляется по расписанию.

Что нужно подготовить заранее

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

Последний пункт часто недооценивают. В базе собственной системы поле status может хранить коды 1, 2, 7, и без разработчика никто не скажет, что 7 — это возврат после частичной оплаты.

Импорт или DirectQuery

Power BI умеет работать с базой двумя основными способами.

Импорт. Данные загружаются в модель Power BI и хранятся там в сжатом виде. Отчёты работают быстро, доступны все возможности расчётов. Минус — данные свежие на момент последнего обновления.

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

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

Порядок подключения

1. В Power BI Desktop выберите получение данных и найдите коннектор нужной СУБД
2. Укажите сервер и базу, выберите режим подключения
3. Введите учётные данные отчётного пользователя
4. В навигаторе отметьте нужные таблицы или представления
5. Перейдите в Power Query и приведите типы данных: даты, числа, текст
6. Настройте связи между таблицами в модели
7. После публикации в облачный сервис настройте учётные данные источника и расписание обновления

Если база находится во внутренней сети и недоступна из интернета, облачному сервису нужен шлюз данных — небольшая служба Microsoft, которую ставят на компьютер или сервер внутри сети. Шлюз забирает данные из базы и передаёт их в облако. Компьютер со шлюзом должен быть включён во время обновлений.

Представления вместо сырых таблиц

Хорошая практика — не подключать отчёт к рабочим таблицам напрямую, а попросить разработчика создать в базе представления (view) или отдельную схему для отчётности. В представлении уже расшифрованы коды статусов, отфильтрованы тестовые записи, переименованы поля понятными словами. Это даёт три выигрыша:

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

Как не нагрузить рабочую базу

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

• Обновлять данные в нерабочие часы или в периоды низкой нагрузки
• Использовать реплику базы только для чтения, если она есть
• Загружать не всю историю каждый раз, а только новые и изменённые строки (инкрементальное обновление)
• Не тянуть в модель поля, которые не используются в отчётах: описания, служебные JSON, вложения

Безопасность подключения

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

Типичные ошибки

• Подключение под пользователем с правами записи «чтобы точно всё работало»
• Выбор DirectQuery по умолчанию, а потом жалобы на медленные отчёты
• Загрузка десятков таблиц, из которых используются три
• Отсутствие договорённости с разработчиками: они меняют структуру, отчёт перестаёт обновляться, и об этом узнают от руководителя

Итог

Прямое подключение — нормальный путь для компании, у которой своя система на PostgreSQL или другой СУБД. Ключевые решения — режим работы, отдельная учётная запись, слой представлений и расписание обновлений, которое не мешает основной работе. Если нужна помощь с настройкой подключения и модели данных, опишите ваши источники в заявке.