У товара может быть несколько категорий в таблице product_categories(product_id, category_id), а продажи лежат в sales_lines(product_id, revenue) (много строк на товар). Вы посчитали выручку по категориям после соединения. Что будет, если потом сложить выручку всех категорий в одну цифру?
AСумма будет равна общей выручке, потому что
SUM автоматически убирает повторы по составному ключу строкBСумма будет меньше общей выручки, потому что категории фильтруют часть строк по условиям соединения таблиц
CСумма может стать больше общей выручки, потому что связь «многие-ко-многим» дублирует выручку для товаров с несколькими категориями
DСумма станет равна числу товаров из-за
COUNT(*) и потеряет смысл денежной величины полностьюПравильный ответ. При связи «многие-ко-многим» один факт попадает в несколько групп, и суммарные
SUM по группам перестают сходиться с общим итогом.Разбор
Если товар принадлежит двум категориям, его строка из sales_lines после JOIN попадёт в обе группы и будет учтена дважды. Это не всегда «ошибка», но тогда нельзя ожидать, что сумма по категориям совпадёт с общей выручкой. Чтобы контролировать это, нужно заранее определить правило распределения (например, разделить выручку поровну между категориями или выбрать одну основную). Иначе будет задвоение, и сводные SUM по группам перестанут сходиться с итогом.
Проверь себя · 1/3разбор после ответа
Хотите посчитать конверсию «пользователь посмотрел товар → пользователь купил» по
user_id. Данные: таблица событий (много просмотров на пользователя) и таблица заказов (много заказов на пользователя). Что корректнее всего сделать, чтобы избежать искажения «многие-ко-многим»?Ещё вопросы по теме «JOIN и кардинальность»
- В таблице `users` 100 000 строк, в таблице `user_profiles` — ровно одна строка на каждого `user_id`. Вы делаете `INNER JOIN` по `user_id`. Что верно про число строк результата?
- Вы соединяете таблицы пользователей и заказов по `user_id`, где у одного пользователя может быть много заказов (связь «один ко многим»). Как посчитать число пользователей, которые сделали хотя бы один заказ, и не получить дубли?
- Для одного `order_id` в `order_items` есть 3 строки, а в `payments` — 2 строки. Вы соединили обе таблицы по `order_id` без предварительной агрегации. Сколько строк получится для этого заказа и почему?
- Нужен набор данных на уровне `user_id`: выручка из `orders` и число сессий из `sessions`. В обеих таблицах по пользователю много строк (один-ко-многим). Какой подход минимизирует риск размножения строк в соединении?
- Вы хотели посчитать средний чек по заказам как `AVG(order_total)`. Но перед этим соединили `orders` с `order_items` по `order_id` (связь один-ко-многим). Почему `AVG()` может измениться по сравнению с расчётом на таблице `orders`?
- Все вопросы по «JOIN и кардинальность» →