Краткий ответ

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

Исторический контекст

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

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

Постановка проблемы

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

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

Подробное решение

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

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

Минимальная диагностика может выглядеть так:

SELECT
    o.order_id,
    COUNT(*) AS joined_rows,
    COUNT(DISTINCT p.product_id) AS products
FROM orders AS o
JOIN order_products AS p
  ON p.order_id = o.order_id
GROUP BY o.order_id
HAVING COUNT(*) > 1;

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

Если дубли появились из-за ошибки данных, следует исправить источник или выбрать правило дедупликации, основанное на бизнес-смысле. Простое использование DISTINCT может скрыть проблему и удалить действительно разные записи.

Нужно также учитывать соединение по неполному ключу. Например, соединение только по идентификатору клиента вместо пары «клиент — период» может сопоставить строку с несколькими периодами. Поэтому проверяют не только синтаксис условия, но и уникальность фактического ключа в каждой таблице.

Ситуация из практики

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

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

Выбрали третий вариант: сначала свели события промокодов к одной строке на заказ по согласованному бизнес-правилу, затем выполнили соединение с заказами. После этого общая выручка совпала с контрольным источником, а показатели промокодов остались доступны для анализа.

Что кандидаты часто упускают

1. Достаточно ли проверить, что количество строк после соединения не увеличилось?

Нет. Количество строк может остаться прежним из-за последующей группировки, хотя суммы уже были завышены на промежуточном этапе. Нужно проверять также количество уникальных сущностей и контрольные агрегаты на том уровне, на котором измеряется показатель.

2. Всегда ли несколько строк после соединения означают ошибку?

Нет. Если анализируется детализация по позициям заказа, несколько строк на заказ являются ожидаемым результатом. Ошибка возникает тогда, когда показатель с уровнем «заказ» агрегируется после размножения строк без корректировки уровня данных.

3. Почему DISTINCT не является универсальным исправлением?

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