Введение в Business Intelligence: данные, модели и расчёты в BI

Обновлено 3 сентября 2026 года.

Business Intelligence (BI) — работа с данными для регулярного анализа бизнеса: подготовка данных, согласование показателей, построение отчётов и использование результатов в решениях. BI-платформа помогает выполнять эту работу, но сама по себе не определяет, какие данные верны и какие действия принесут результат.

Например, руководителю продаж нужен ответ на вопрос: «Почему выросла сумма заказов, а поступления денег снизились?» Для ответа нужны заказы, оплаты, возвраты, даты и условия расчёта. Одного красивого графика суммы сделок недостаточно.

Из чего состоит BI-решение

1. Источники. CRM, учётная система, рекламные кабинеты, веб-аналитика, базы данных и файлы.
2. Получение и подготовка данных. Выгрузка нужных записей, обработка изменений, проверка полноты, приведение типов и согласование справочников.
3. Хранение. При необходимости — отдельная аналитическая база, хранилище данных или витрины.
4. Модель и показатели. Связи между таблицами, правила фильтрации и формулы с понятным бизнес-смыслом.
5. Отчёт. Диаграммы, таблицы, пояснения, фильтры и доступ для нужных пользователей.
6. Эксплуатация. Обновление, наблюдение за сбоями, контроль прав, документация и проверка того, что отчётом пользуются.

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

При ETL данные извлекают, преобразуют, затем загружают в целевое хранилище. При ELT извлечённые данные сначала загружают, а затем преобразуют в целевой среде. Оба подхода требуют проверки качества; порядок букв не даёт автоматической гарантии скорости или точности.

Источники: база данных, файл и API

Базы данных

Для подключения указывают сервер, базу и способ аутентификации. Конкретный драйвер, поддержка режима запросов и настройки TLS зависят от СУБД и BI-продукта. Проверяйте сертификат сервера и сетевой доступ, а не подтверждайте любое предупреждение о незашифрованном соединении.

У Power BI режим Import загружает данные в модель; актуальность зависит от обновления. В DirectQuery отчёт выполняет запросы к источнику, но задержки, кэширование и нагрузка всё равно существуют. Прямое подключение не означает «мгновенно и без ограничений». Есть и другие режимы, включая Direct Lake и подключение к существующей семантической модели. Источник: описание режимов Power BI.

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

CSV и Excel

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

В DataLens у подключения к файлам действуют ограничения: до 10 файлов, до 200 МБ на файл и до 300 столбцов. Каждый лист Excel считается отдельным файлом, а предварительный просмотр показывает первые 30 строк. Это не означает, что в итоговый датасет загружаются только 30 строк. Источник: подключение файлов в DataLens.

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

API

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

В Power Query для HTTP-источников используют веб-коннектор или подходящий специализированный коннектор. Возможности авторизации и обновления нужно проверять отдельно для Desktop и сервиса: не любой OAuth-процесс получится реализовать одним вводом URL. Источник: веб-коннектор Power Query.

В DataLens API Connector предназначен для использования в Editor. Он не подключается как обычный источник к QL-чартам или чартам на основе датасета. Для длительной истории и повторного анализа API-данных можно организовать загрузку в аналитическую базу.

Superset прежде всего работает с SQL-источниками. Его REST API управляет объектами самой платформы; наличие этого API не превращает произвольный JSON-сервис в готовый табличный источник для графиков. Обычно внешние API-данные предварительно загружают в совместимую базу. Поддержку конкретной СУБД проверяют по списку интеграций Superset.

Таблица фактов, измерения и уровень детализации

Таблица фактов описывает события или состояния: строки продаж, оплаты, остатки на дату. Измерения задают контекст: товар, клиент, календарь, подразделение. Измерение может содержать и числа — например, площадь магазина. Различие определяется ролью таблицы в модели, а не правилом «числа против текста».

Сначала определите уровень детализации: что означает одна строка. У строк заказа это «один товар в одном заказе», у рекламных расходов — например, «кампания за день», у оплат — «одно денежное движение». Смешивание этих уровней в одной плоской таблице часто приводит к завышенным суммам.

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

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

Microsoft рекомендует звёздную схему как основу понятных и эффективных семантических моделей Power BI. Конкретные таблицы, ключи и историю атрибутов всё равно нужно проектировать под задачу. Источник: руководство Microsoft по звёздной схеме.

Транзакционные гарантии определяются СУБД и способом записи данных, а не названием схемы. Нельзя утверждать, что снежинка по определению «менее транзакционная», чем операционная база.

На стороне «один» связи ключ должен быть уникален в рамках используемой модели. Суррогатный ключ — технический идентификатор, для которого нужно поддерживать устойчивое соответствие сущности. Индекс, заново присвоенный строкам после сортировки при каждом обновлении, без сохранённого сопоставления может поменять смысл связей.

Меры и вычисляемые столбцы: различия зависят от системы

Таблица не означает, что DataLens и Superset материализуют каждое вычисляемое поле в своей памяти подобно столбцу импортированной модели Power BI. Для SQL-источников расчёт связан с запросом к базе, а результат может кэшироваться. Мера Power BI тоже использует вычислительные ресурсы и память при выполнении; верно лишь то, что её результаты не хранятся как дополнительный столбец Import-модели.

Основания для сравнения: варианты вычислений Power BI, вычисляемые поля DataLens и семантический слой Superset.

Не всякая мера обязательно содержит SUM или AVERAGE: она возвращает значение выражения в текущем контексте. Построчная итерация внутри DAX-меры возможна, например с SUMX. Для DirectQuery действуют собственные ограничения вычислений; свойства Import нельзя без оговорок переносить на все режимы.

Один показатель в DAX, DataLens и SQL

Используем учебную таблицу Sales. Revenue — выручка, Cost — соответствующие ей затраты в одной валюте, без пропусков. Для этого примера прибыль определена как Revenue − Cost. В рабочем проекте состав затрат и учёт возвратов нужно согласовать отдельно.

Общая маржа равна 150 / 1 000 = 15%. Среднее двух процентов, (60% + 10%) / 2 = 35%, отвечает другому вопросу: это невзвешенная средняя маржа категорий. Для маржи общей выручки нужно делить суммы.

Power BI: меры DAX

Каждую из следующих формул создайте как отдельную меру. Margin отформатируйте как процент.

Revenue = SUM(Sales[Revenue])

Profit = SUM(Sales[Revenue]) - SUM(Sales[Cost])

Margin = DIVIDE([Profit], [Revenue])

Если знаменатель равен нулю, DIVIDE без третьего аргумента возвращает BLANK. Это лучше передаёт отсутствие определённого отношения, чем автоматически подставленный ноль. Источник: функция DIVIDE.

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

ProfitRow = Sales[Revenue] - Sales[Cost]

Не используйте SUM(Sales): SUM ожидает столбец, например Sales[Revenue], а не имя таблицы. Вычисляемый столбец ProfitRow и мера Profit решают разные задачи и могут существовать одновременно.

DataLens: вычисляемый показатель

FDIV_SAFE(
    SUM([Revenue]) - SUM([Cost]),
    SUM([Revenue])
)

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

SQL: пример для PostgreSQL

Запрос содержит собственные учебные строки в VALUES и не требует таблиц CRM. Итоговая строка с пустой категорией создаётся GROUPING SETS; в этом примере исходные категории непустые.

WITH sales(category,revenue,cost) AS (
  VALUES ('A',100.00::numeric,40.00::numeric),
         ('B',900.00::numeric,810.00::numeric)
)
SELECT category,
       SUM(revenue) AS revenue,
       SUM(revenue - cost) AS profit,
       SUM(revenue - cost) / NULLIF(SUM(revenue),0) AS margin
FROM sales
GROUP BY GROUPING SETS ((category), ())
ORDER BY category NULLS LAST;

Результат: для A — 0,6, для B — 0,1, для общего итога — 0,15. Для метрики Superset над подготовленной таблицей с такими полями можно использовать выражение SUM(revenue - cost) / NULLIF(SUM(revenue), 0). В примере тип numeric обеспечивает дробное деление. Для целочисленных исходных колонок потребуется приведение к дробному типу; синтаксис зависит от СУБД.

Если в реальных данных Cost неизвестна, сначала задайте правило обработки пропусков. В SQL SUM(revenue - cost) пропустит строку с NULL в одном из операндов, тогда как SUM(revenue) может её учесть. Это способно завысить или занизить показатель без ошибки выполнения.

Как выбирать диаграммы

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

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

Воронку строят с учётом состава одной группы объектов и последовательности событий. Количество сделок, находящихся сейчас на разных стадиях, — распределение текущего состояния; оно не равно конверсии прохождения этапов одной когортой.

Актуальность, скорость и права доступа

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

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

Перенос расчёта в базу может уменьшить работу BI-инструмента, но увеличить нагрузку на источник. Выбирайте место расчёта по измерениям и требованиям к повторному использованию, а не по правилу «всё всегда считать в SQL».

Доступ только на чтение защищает от части случайных изменений, но не ограничивает автоматически перечень видимых клиентских данных. Проверяйте права на строки и столбцы, экспорт и доступ к исходным объектам от имени обычного пользователя. При общей технической учётной записи права CRM сами собой не переносятся в BI.

Как принять первый BI-отчёт

1. Зафиксируйте бизнес-вопрос, владельца показателя и определение каждой метрики.
2. Сверьте число записей и суммы за один период с источником. Отдельно проверьте дубли, возвраты, валюту и пропуски.
3. Проверьте связи на примере объекта с несколькими дочерними строками: итог не должен расти из-за JOIN.
4. Проверьте фильтры на странице, общий итог, пустую выборку и деление на ноль.
5. Проверьте работу обновления и понятное отображение сбоя.
6. Откройте отчёт с правами читателя и проверьте ограничения просмотра и выгрузки.
7. Попросите будущего пользователя решить исходную задачу по отчёту и объяснить результат.

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

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