Почему после объединения таблиц увеличилась сумма продаж

Представим условный магазин. В одной таблице хранится заказ стоимостью 1 200 рублей. В другой — три товара этого заказа. Аналитик соединяет таблицы, чтобы добавить названия товаров к продажам, а затем складывает стоимость заказа. В отчёте появляется 3 600 рублей, хотя покупатель заплатил только 1 200.

Такое расхождение возможно даже при правильных исходных данных. После соединения одна строка заказа оказалась представлена трижды — по одному разу для каждого товара. Повторилось не событие продажи, а значение, которое относилось к заказу целиком.

Детализация — это уровень, на котором записаны данные. Одна строка может означать заказ, товар внутри заказа, платёж или отдельную доставку. Эти сущности связаны, но не взаимозаменяемы. В нашем примере первая таблица описывает заказы, вторая — товарные позиции.

В документации PostgreSQL о соединении таблиц объясняется: для строки одной стороны результат включает каждую подходящую строку другой. Поэтому несколько совпадений закономерно дают несколько строк. Само соединение не обязано сохранять исходное количество заказов или сумму их стоимости.

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

Ситуация усложняется, если к товарам добавляют ещё и платежи. В условном заказе с тремя товарами и двумя платежами соединение только по номеру заказа способно дать шесть сочетаний. Это не шесть покупок. Именно поэтому при объединении наборов нужно заранее назвать ожидаемый смысл каждой результирующей строки.

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

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

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

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

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

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

• Что такое SQL и кому он нужен
• Первичный и внешний ключ: как связать клиентов и заказы

Если хотите разобраться в работе с данными системно, посмотрите программу «SQL инженер» в NovaData. Сравните темы и требования к подготовке со своими задачами: этот пример помогает сформулировать вопросы, с которыми можно прийти на обучение.

• PostgreSQL: соединение таблиц
• Microsoft: связи многие ко многим