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