SQL на пальцах для системного аналитика: какой базы хватит

SQL — язык работы с данными, который используют, в частности, в реляционных базах. Такие базы хранят данные в таблицах со строками и столбцами. Система управления базой данных, например PostgreSQL, выполняет запрос и возвращает результат.

SQL для аналитика помогает отвечать на конкретные вопросы:

• Какие заказы находятся в нужном статусе?
• С каким клиентом связан заказ?
• Есть ли клиенты, у которых ещё нет заказов?
• Совпадает ли сумма на экране с данными, которые мы проверяем?

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

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

Ниже — практический ориентир для начала обучения. Это не универсальный список требований всех работодателей.

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

Возьмём две небольшие таблицы. Все имена, суммы и статусы вымышлены. Суммы указаны в рублях; в этом примере у каждого заказа один покупатель.

В каждой таблице id — первичный ключ: он однозначно определяет запись. Поле orders.customer_id ссылается на customers.id. Например, заказ 102 связан с клиентом 1 — Анной. У Анны два заказа, у Веры пока ни одного.

Связь строится по идентификатору: имя может совпадать у разных людей и меняться. Поэтому для соединения этих таблиц мы будем использовать customer_id и id.

Примеры ниже написаны в синтаксисе, подходящем для PostgreSQL. Основные конструкции встречаются и в других СУБД, но детали — например, ограничение количества строк и функции дат — могут отличаться.

Задача: найти оплаченные заказы на сумму от 2000 ₽ включительно.

SELECT id, customer_id, total
FROM orders
WHERE status = 'paid'
  AND total >= 2000
ORDER BY id;

Прочитайте запрос по частям:

• SELECT id, customer_id, total — какие столбцы вернуть.
• FROM orders — из какой таблицы взять данные.
• WHERE — какие строки оставить: статус paid и сумма не меньше 2000.
• ORDER BY id — в каком порядке показать результат.

Получится одна строка:

Заказ 103 оплачен, но его сумма меньше порога. Заказ 101 ещё в статусе new. Здесь оба условия должны выполняться одновременно, поэтому нужен AND.

Это небольшой пример SELECT для аналитика: сначала вопрос к данным, затем запрос и объяснение результата. В документации PostgreSQL отдельно разобраны выборка, фильтрация и сортировка.

Теперь нужно получить номера оплаченных заказов, имена покупателей и суммы. Статус и сумма находятся в orders, а имя — в customers. JOIN позволяет сопоставить строки двух таблиц по условию.

SELECT o.id, c.name, o.total
FROM orders AS o
INNER JOIN customers AS c
  ON o.customer_id = c.id
WHERE o.status = 'paid'
ORDER BY o.id;

o и c — короткие имена таблиц, или псевдонимы. Запись o.id означает столбец id из orders. Условие после ON указывает, какие строки связать: номер покупателя в заказе должен совпасть с идентификатором клиента.

Результат:

INNER JOIN оставляет только совпавшие пары. В нашем наборе у каждого заказа есть клиент. Если подходящей строки справа не будет, такой заказ в результат этого соединения не попадёт. Эти правила описаны в учебном разделе PostgreSQL о соединениях.

Почему после JOIN может стать больше строк

Один клиент может соответствовать нескольким заказам. Если убрать из запроса условие WHERE, Анна появится дважды — для заказов 101 и 102. Это ожидаемый результат: одна строка нашей выборки описывает заказ вместе с данными покупателя.

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

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

SELECT c.id, c.name
FROM customers AS c
LEFT JOIN orders AS o
  ON o.customer_id = c.id
WHERE o.id IS NULL
ORDER BY c.id;

Результат — Вера:

У неё не нашлось ни одной строки в orders. Поскольку orders.id — первичный ключ и не бывает NULL в существующем заказе, проверка o.id IS NULL здесь выделяет именно отсутствие совпадения.

NULL обозначает отсутствие значения. Его нельзя проверять условием = NULL: для такой проверки используют IS NULL или IS NOT NULL. Подробнее — в документации PostgreSQL об операторах сравнения.

Обратите внимание: «нет заказов» и «нет оплаченных заказов» — разные условия. Во втором случае нужно учитывать статус уже при поиске совпадения. Перенос фильтра между ON и WHERE после LEFT JOIN может изменить результат; этот нюанс разобран в разделе о табличных выражениях.

Посчитаем, сколько оплаченных заказов у каждого покупателя и на какую сумму:

SELECT customer_id,
       COUNT(*) AS order_count,
       SUM(total) AS total_amount
FROM orders
WHERE status = 'paid'
GROUP BY customer_id
ORDER BY customer_id;

Результат:

WHERE оставляет оплаченные заказы, GROUP BY собирает строки по покупателю, COUNT(*) считает строки каждой группы, а SUM(total) складывает суммы. Эти конструкции позволяют проверить число записей и итоговую сумму без ручного подсчёта. Документация PostgreSQL об агрегатных функциях показывает тот же принцип на другом наборе данных.

Веры в результате нет: запрос начинается с таблицы заказов, а её заказов там нет. И ещё одна деталь для следующего шага: COUNT(*) считает строки, а COUNT(поле) — только строки, где значение этого поля отличается от NULL. Числовой ноль при этом считается обычным значением. После LEFT JOIN это различие особенно важно. (Описание COUNT)

Для разобранных задач не требуется начинать с настройки серверов БД, репликации или сложных хранимых процедур. Сначала закрепите простые выборки и соединения. Следующими темами могут стать подзапросы, CASE, HAVING, работа с датами, оконные функции и чтение плана выполнения — по мере появления задач.

Практикуйтесь на учебной базе. Доступ к рабочим данным, ограничения на запросы и допустимую нагрузку согласуют с командой. Даже запрос на чтение может оказаться тяжёлым. В PostgreSQL LIMIT ограничивает число возвращаемых строк, но сам по себе не гарантирует дешёвое выполнение всего запроса; без ORDER BY выбранный фрагмент также не имеет гарантированного порядка. (LIMIT и OFFSET, описание SELECT)

Если вы выбираете курс SQL для аналитиков, смотрите на практику: есть ли связанные таблицы, задания с проверкой результата, разбор NULL и объяснение повторов после JOIN. Для системного аналитика полезны упражнения, в которых запрос связан с правилом продукта: какие заказы показать, какие записи исключить и почему.

Отдельный SQL-курс закрывает работу с запросами. Для перехода в системный анализ нужна и остальная база: требования, модели данных, процессы и интеграции. В программе Prosystalent SQL изучается вместе с этими темами. Обучение рассчитано на 6 недель, после подготовки команда сопровождает поиск работы. Предоплата — 0 ₽; после официального выхода на работу предусмотрена оплата 20% от дохода в течение 12 месяцев по условиям договора. Изучите условия оплаты и оставьте заявку, если хотите обсудить программу и свой старт.