Третья часть серии. Первые две были про интеграции, архитектуру и базы данных. Сегодня — практический блок: SQL запросы, которые пишут прямо на собеседовании, и нотации для описания процессов.
На собеседовании системного аналитика SQL пишут руками. Не объясняют теорию — пишут конкретный запрос. К этому нужно быть готовым.
────────────────────────────────────────
▶ SQL: от простого к сложному
Уровень Junior — базовый синтаксис:
Простой запрос — это первое что спросят:
SELECT * FROM users WHERE active = true ORDER BY name LIMIT 10
Нужно понимать каждую часть: SELECT — что выбираем, FROM — откуда, WHERE — условие фильтрации, ORDER BY — сортировка, LIMIT — ограничение количества строк.
Уровень Middle — сложные конструкции:
Типы JOIN — самая частая тема на собеседованиях по SQL:
• INNER JOIN — только совпадающие строки из обеих таблиц. Пользователь без заказов не попадёт в результат.
• LEFT JOIN — все строки из левой таблицы, и совпадающие из правой. Пользователь без заказов попадёт, у него будут NULL в полях заказа.
• RIGHT JOIN — все строки из правой таблицы, и совпадающие из левой. Симметрично LEFT JOIN.
• FULL OUTER JOIN — все строки из обеих таблиц. Где нет совпадения — NULL с соответствующей стороны.
Практическое правило: если нужны все записи из основной таблицы независимо от наличия связанных данных — используй LEFT JOIN. Это самый частый случай на практике.
GROUP BY и HAVING:
GROUP BY группирует строки по значению поля. HAVING фильтрует уже сгруппированные результаты. Разница с WHERE: WHERE фильтрует до группировки, HAVING — после.
Пример: найти пользователей с более чем 5 заказами.
SELECT user_id, COUNT(*) as order_count FROM orders GROUP BY user_id HAVING COUNT(*) > 5
UNION и DISTINCT:
UNION объединяет результаты двух SELECT и удаляет дубликаты. UNION ALL — объединяет без удаления дубликатов, работает быстрее.
DISTINCT убирает дублирующиеся строки в результате запроса.
Пагинация — важная тема на мидл-уровне:
Простая пагинация через LIMIT/OFFSET:
SELECT * FROM articles ORDER BY created_at DESC LIMIT 10 OFFSET 20
Проблема: при большом OFFSET база просматривает все предыдущие строки. На миллионах записей это медленно.
Cursor-based пагинация — более производительная альтернатива:
SELECT * FROM articles WHERE id > :last_id ORDER BY id LIMIT 10
Здесь last_id — это ID последней записи с предыдущей страницы. База сразу ищет по индексу, не сканирует ненужные строки. Знание этого отличия отделяет мидла от джуниора.
Уровень Senior — DDL, DML, транзакции, подзапросы:
DDL (Data Definition Language) — операции со структурой:
• CREATE TABLE — создать таблицу
• ALTER TABLE — изменить структуру
• DROP TABLE — удалить таблицу
DML (Data Manipulation Language) — операции с данными:
• INSERT INTO — вставить записи
• UPDATE SET — обновить записи
• DELETE FROM — удалить записи
Транзакции в SQL:
BEGIN; — начало транзакции
/* несколько SQL операций */
COMMIT; — зафиксировать изменения
Если что-то пошло не так:
ROLLBACK; — откатить все изменения транзакции
Это прямая реализация принципа Atomicity из ACID, который разобрали в предыдущем посте.
Подзапросы — запросы внутри запросов. Позволяют делать сложную фильтрацию в одном выражении без нескольких шагов.
────────────────────────────────────────
▶ UML Sequence diagram
Sequence diagram — диаграмма последовательности — описывает порядок взаимодействия между компонентами во времени. Это один из главных инструментов аналитика при описании интеграций.
Элементы диаграммы:
Lifeline (жизненная линия): вертикальная линия, представляет участника — систему, сервис, актора. Сверху — название.
Стрелки между lifelines:
• Синхронный вызов — сплошная стрелка с закрытым наконечником. Отправитель ждёт ответа.
• Асинхронное сообщение — сплошная стрелка с открытым наконечником. Отправитель не ждёт.
• Ответ — пунктирная стрелка.
Фреймы управления (combined fragments):
• alt — альтернатива. Аналог if/else. Разные сценарии в зависимости от условия.
• loop — цикл. Повторяет последовательность пока выполняется условие.
• par — параллельное выполнение. Несколько операций одновременно.
• opt — опциональный блок. Выполняется только если выполнено условие.
Для создания sequence диаграмм удобно использовать PlantUML — текстовый формат, из которого автоматически генерируется изображение. По моим наблюдениям, кандидаты часто путают синхронный и асинхронный вызов прямо на доске — рисуют одну стрелку на всё. Это сразу сигнал интервьюеру: человек знает нотацию поверхностно. Разница в наконечнике стрелки — не формальность, а смысловое различие в поведении системы.
────────────────────────────────────────
▶ BPMN нотация
BPMN (Business Process Model and Notation) — стандарт для описания бизнес-процессов. Аналитик использует BPMN чтобы описать как работает процесс до и после автоматизации. Типичная ошибка на собеседовании — нарисовать плоский список шагов без шлюзов и дорожек. Это не BPMN, это блок-схема. Интервьюер сразу видит разницу: настоящая BPMN-диаграмма показывает кто отвечает за каждый шаг и что происходит при ветвлении.
Уровень Junior — базовые элементы:
• Событие — круг. Старт, конец и промежуточные события.
• Задача — прямоугольник с закруглёнными углами. Конкретное действие.
• Шлюз — ромб. Точка ветвления или схождения потоков.
Уровень Middle — структура диаграммы:
Пул (Pool): представляет участника процесса — организацию или систему. Содержит в себе весь процесс этого участника.
Дорожка (Lane): разделение внутри пула по ролям. Один пул — компания, дорожки — менеджер, бухгалтер, система.
Типы шлюзов — важно знать три основных:
• X (эксклюзивный, XOR): только один путь. Аналог if/else — выбирается одно из условий.
• + (параллельный, AND): все пути одновременно. Процесс разделяется и потом сходится.
• O (инклюзивный, OR): один или несколько путей. Более гибкий вариант.
Уровень Senior — промежуточные события:
Промежуточные события на потоке или прикреплённые к задаче:
• Таймер: ждать до определённого времени или заданный период
• Сигнал: ждать внешнего сигнала от другого процесса или пула
• Ошибка: обработать исключительную ситуацию
Знание промежуточных событий позволяет описывать нестандартные сценарии: таймаут, эскалацию, компенсацию.
────────────────────────────────────────
Следующий — четвёртый и финальный пост: требования, Scrum, QA, аутентификация и авторизация. Там же — краткий итог всей серии.
#системныйаналитик #собеседование #ITкарьера #аналитик #подготовка