Кардинальность JOIN в SQL: как не умножить строки и выручку

Коротко

Кардинальность описывает, сколько строк одной таблицы соответствует строке другой. До JOIN нужно знать ожидаемую связь и решить, где агрегировать правую сторону.

Материал относится к полке «SQL и аналитика» и построен вокруг рабочего решения: сначала определить объект и границы расчёта, затем проверить пример и только после этого выбирать инструмент или метрику.

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

Какой вопрос решает материал

Почему после добавления таблицы событий сумма выручки стала в три раза больше?

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

Если orders содержит одну строку на заказ, а order_items — несколько позиций, сначала агрегируй items до order_id. Только потом присоединяй сумму к orders и считай выручку.

Определение и зерно расчёта

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

Проверь уникальность ключей обеих сторон, посчитай строки до и после соединения и добавь контрольную сумму. Для сложного запроса выдели каждый JOIN в отдельный CTE.

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

Рабочий пример

Если orders содержит одну строку на заказ, а order_items — несколько позиций, сначала агрегируй items до order_id. Только потом присоединяй сумму к orders и считай выручку.

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

WITH item_totals AS (\n  SELECT order_id, SUM(amount) AS item_revenue\n  FROM order_items\n  GROUP BY order_id\n)\nSELECT o.order_id, o.revenue, COALESCE(i.item_revenue, 0) AS item_revenue\nFROM orders AS o\nLEFT JOIN item_totals AS i USING (order_id);

Как читать результат

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

Результат полезен только в контексте baseline, размера объекта и действия после сигнала. Одна цифра без периода и сравнения выглядит убедительно, но не отвечает на вопрос, стало ли решение лучше.

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

Где расчёт ломается

Опасны LEFT JOIN с фильтром правой таблицы в WHERE, соединение по неполному ключу и повторное присоединение уже размноженного CTE. Все три ошибки могут давать правдоподобные цифры.

Отдельно протестируй пустой результат, NULL, дубль, граничную дату и объект без связанной записи. Эти случаи не являются редкими исключениями: именно они чаще всего превращают рабочий показатель в красивую, но неверную цифру.

• Не смешивай зрелые и незрелые периоды без отдельной подписи.
• Не заменяй проверку качества тем, что запрос просто выполнился.
• Не делай причинный вывод из одного разреза.

Визуальная проверка

График здесь нужен не для украшения статьи. Он помогает увидеть форму сигнала: тренд, разрыв между сегментами, хвост распределения или этап, на котором теряется объект. Сначала прочитай оси и единицы, затем сравни с таблицей и только после этого формулируй вывод.

На визуализации «Как меняется число строк после JOIN» сравнивай не только максимальное значение. Проверь, одинаковы ли базы, не скрыта ли неполная дата и не меняется ли знаменатель от категории к категории.

Мини-практика

Возьми пять заказов с разным числом позиций и вручную посчитай ожидаемую сумму. Сравни наивный JOIN и вариант с предварительной агрегацией.

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

• Собери контрольный пример из пяти-десяти строк.
• Сверь итог с независимым способом расчёта.
• Проверь хотя бы один крайний случай.
• Зафиксируй дату, версию схемы и ограничение.

Контрольные сценарии

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

Если материал связан с пользователями, отдельно проверь повторное действие одного человека. Если он связан с деньгами, добавь возврат, скидку и нулевую сумму. Если он связан со временем, протестируй полночь, timezone и запоздалую запись. Эти тесты не занимают много времени, но ловят ошибки, которые обычная строка почти никогда не показывает.

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

Когда выбрать другой подход

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

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

Как передать результат

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

Если результат требует действия, назови owner и момент пересмотра. «Проверить mobile checkout до пятницы» полезнее, чем «обратить внимание на конверсию». Если данных пока недостаточно, сформулируй следующий сбор: какое событие, какой период или какой эксперимент закроет неопределённость.

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

Как довести расчёт до рабочего процесса

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

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

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

• Один контрольный пример с известным ответом.
• Владелец определения и владелец данных.
• Порог свежести и допустимый диапазон.
• Лог изменений, SQL или notebook в одном месте.

Чеклист перед публикацией

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

• Понятно ли, что является строкой результата?
• Названы ли период, timezone, фильтры и знаменатель?
• Есть ли проверка на дубли, NULL и пустые группы?
• Сравнивается ли результат с baseline или сегментом?
• Понятно ли, какое решение поддерживает показатель?
• Есть ли следующий шаг, если сигнал подтвердится?

Вывод

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

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