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