Известная всем страна Камнепадия славится своей добычей драгоценных камней,
чем привлекает многих туристов. Основными добываемыми драгоценностями являются рубины,
изумруды и сапфиры. Три крупных компании: "Рубинусы", "Изумрудсы" и "Сапфирсы" - поделили рынок между собой,
и каждая компания занимается добычей только одного камня. Каждая компания имеет по одному фирменному магазину
с камнями в каждом городе.
Один очень хитрый господин по имени Дроп Датабейсович узнал, что в фирменных магазинах повсеместно используют язык SQL,
а еще он разузнал, что компании в Камнепадии не обладают тайным знанием защиты от SQL-инъекций. Дроп Датабейсович решил
разжиться драгоценностями, воспользовавшись своим громким именем, у которого есть одно интересное свойство.
Каждый раз, когда Дроп Датабейсович каким-то образом взаимодействует с непродвинутыми компаниями,
которые не знают, что такое SQL-инъекция, их база данных магическим образом падает, и он может извлечь из этого выгоду.
Дроп Датабейсович начал планировать свою поездку по Камнепадии. Свой путь он думает начать в городе "Tarataika",
а закончить в городе "Agapovka". В каждом городе Дроп Датабейсович может выбрать, в каких магазинах уронить базу данных
и забрать все камни себе. Он может ограбить любое число магазинов в городе, в том числе ни одного.
Ему нужно найти все пути между начальным и конечным городами с максимальной суммой всех полученных драгоценностей,
и выбрать из них самые короткие. Однако всё не так просто. Как только Дроп Датабейсович провернёт махинацию
в одном фирменном магазине, все остальные магазины этой компании поймут, в чём дело, и поставят защиту от SQL-инъекций,
из-за чего он не сможет больше ничего получить из их магазинов. Также, с каждым пройденным городом количество камней в
каждом магазине страны будет уменьшаться на единицу, из-за того, что драгоценности будут скупать другие люди, а так как
камешки невероятно дорогие, то, чтобы купить хотя бы 1 камень, жители скидываются на него всем городом.
Господин Дроп Датабейсович раздобыл базу данных городов с текущим количеством камней в магазинах,
а также карту всех дорог между городами в Камнепадии.
CREATE TABLE IF NOT EXISTS Cities (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
rubies INTEGER NOT NULL, -- число рубинов в магазине
emeralds INTEGER NOT NULL, -- число изумрудов в магазине
sapphires INTEGER NOT NULL -- число сапфиров в магазине
);
CREATE TABLE IF NOT EXISTS Roads (
from_city_id INTEGER REFERENCES Cities(id),
to_city_id INTEGER REFERENCES Cities(id),
PRIMARY KEY (from_city_id, to_city_id)
);
Дроп Датабейсовичу нужно составить SQL запрос, который покажет все самые выгодные варианты с наибольшим числом собранных камней
и наименьшей длиной пути. Результатом запроса должен быть список кортежей (path, total_jewelry, ruby_city, emerald_city,
sapphire_city), отсортированных по возрастанию по всем полям кортежа слева направо, где path: путь в формате
"Tarataika -> ... -> Agapovka", total_jewelry: сумма всех драгоценных камней полученная в пути, ruby_city, emerald_city,
sapphire_city: названия городов, в которых нужно забрать рубины, изумруды и сапфиры соответственно. Также нужно учитывать,
что в пределах одного пути Дроп Датабейсович может получить максимальное число камней разными способами в зависимости от того,
из каких городов берёт камни.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
В рамках программы развития интеллектуальных транспортных систем г. Владивостока
проводится аудит безопасности дорожной сети в зимний период.
Аналитикам поставлена задача выявить опасные участки инфраструктуры
и определить виновность водителей, попавших в инцидент.
Необходимо написать SQL-запрос, который сформирует выборку записей,
удовлетворяющих одновременно двум критериям:
1. Доказанная вина: водитель официально признан виновником ДТП
(is_guilty = 1).
2. Опасный участок: инцидент зафиксирован на локации, где за весь
анализируемый период произошло строго более 2-х ДТП.
Итоговая таблица должна содержать следующие колонки:
driver_name — ФИО водителя; accident_location — адрес, по которому произошло ДТП; accident_date — дата происшествия (YYYY-MM-DD); days_since_prev — количество дней, прошедших с предыдущего ДТП на том же месте.
Для первого зафиксированного инцидента на участке выводится NULL.
(NULL возвращается оконной функцией LAG для первой строки раздела.)
Для вычисления количества дней между датами использовать функцию JULIANDAY.
Результат отсортировать по адресу ДТП (по алфавиту),
внутри одного адреса — по дате происшествия (по возрастанию).
Для тестовой базы корректный запрос вернёт следующее:
Edmund McMillen|Lugovaya Sq., interchange|2025-12-20|
Anna Smirnova|Lugovaya Sq., interchange|2025-12-21|1
Matt Jolly|Lugovaya Sq., interchange|2026-01-25|35
Semyon Seryoznov|Lugovaya Sq., interchange|2026-02-14|20
Goro Majima|Verkhneportovaya St., 40|2025-12-10|
Leon Scott Kennedy|Verkhneportovaya St., 40|2025-12-11|1
Ivan Ivanov|Verkhneportovaya St., 40|2026-01-15|35
Kazuma Kiryu|Verkhneportovaya St., 40|2026-02-05|21
Ограничения
Предполагается, что для работы с базой данных используется SQLite3.
В базе данных хранится информация об игроках в Dungeons & Dragons и их персонажах.
Таблица players содержит информацию об игроках:
CREATE TABLE players (
id INTEGER NOT NULL PRIMARY KEY,
nickname VARCHAR(255) NOT NULL UNIQUE,
age INTEGER NOT NULL
);
Таблица characters содержит информацию о персонажах:
CREATE TABLE characters (
id INTEGER NOT NULL PRIMARY KEY,
player_id INTEGER NOT NULL,
race VARCHAR(255) NOT NULL,
class VARCHAR(255) NOT NULL,
FOREIGN KEY (player_id) REFERENCES players(id)
);
Схема БД в UML-нотации:
Каждый игрок может иметь любое количество персонажей.
Нужно составить запрос, который для каждой из 3 самых популярных комбинаций выдаст:
расу (race)
класс (class)
количество уникальных игроков выбравших эту комбинацию (players_count)
Минимальный возраст игрока с такой комбинацией (min_age)
Комбинация считается популярной по количеству уникальных игроков,
которые создали хотя бы одного персонажа с такой комбинацией.
Результат отсортируйте по убыванию количества игроков,
при равенстве - по названию расы, затем по названию класса.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Для защиты особо важного объекта используется автоматическая система поиска кодов.
Система знает, что правильный код находится в некотором диапазоне целых чисел.
Чтобы определить его, она последовательно сокращает область поиска:
на каждом шаге выбирает одно число из текущего диапазона,
и используя информацию о положении правильного кода относительно выбранного значения,
исключает часть возможных вариантов.
В базе данных хранятся:
левая граница диапазона поиска,
правая граница диапазона поиска,
правильный код доступа.
Необходимо определить, сколько шагов потребуется системе для нахождения правильного кода,
если она всегда действует наиболее эффективно.
CREATE TABLE SearchTask (
left_bound INTEGER not null,
right_bound INTEGER not null,
secret INTEGER not null
);
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Студенты Кирилл и Даша успешно закрыли сессию и решили отметить это событие походом в кино на долгожданную премьеру фантастического боевика «Звёздные рубежи: Возрождение». Кирилл, как будущий администратор баз данных, подрабатывает в этом кинотеатре и имеет прямой доступ к системе бронирования билетов.
Даша заметила в приложении, что зал практически полностью раскуплен, но где-то в зале есть ровно одна компания из трёх человек, которые успели забронировать три соседних кресла в одном ряду. Даше стало жутко интересно, кто эти счастливчики.
Должностные инструкции не позволяют Кириллу отправить Даше полный дамп базы зрителей. Помогите Кириллу составить SQL-запрос к базе данных, который бы вычислил эту троицу (три занятых места подряд в одном ряду) и вывел их имена в алфавитном порядке. Гарантируется, что в зале есть только одна такая группа из ровно трёх человек, сидящих рядом.
CREATE TABLE Ticket (
id INTEGER not null primary key,
row_num INTEGER not null,
seat_num INTEGER not null,
is_occupied INTEGER not null,
viewer_name VARCHAR(255)
);
Схема БД в UML-нотации:
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Магос Доминус проводит аудит техножрецов Фордж-мира Марс. Каждый техножрец отвечает за обслуживание и контроль группы сервиторов. Для оптимизации распределения ресурсов и расчёта бонусов необходимо получить аналитическую информацию по каждому техножрецу.
В базе данных имеются две таблицы:
CREATE TABLE tech_priests (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
rank TEXT,
forge_world TEXT,
ordination_year INTEGER
);
CREATE TABLE servitors (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL,
tech_priest_id INTEGER,
model TEXT,
operating_hours INTEGER,
efficiency INTEGER,
status TEXT,
FOREIGN KEY (tech_priest_id) REFERENCES tech_priests(id)
);
Для каждого техножреца необходимо рассчитать:
Количество закреплённых сервиторов
Среднюю эффективность сервиторов (округлить до 1 знака)
Суммарное время работы всех сервиторов (operating_hours)
Школьнику Стёпе на лето задали большой список литературы. Первые два месяца каникул он полностью посвятил отдыху, и теперь у него остался только один месяц (30 дней), чтобы успеть прочитать как можно больше произведений из списка. При этом ученик готов тратить на чтение не более 5 часов в день.
Так как главная цель — максимизировать количество прочитанных книг, Стёпа решает использовать жадную стратегию: он всегда выбирает следующей ту книгу, в которой меньше всего страниц. Если количество страниц совпадает, книги читаются в порядке возрастания их идентификатора.
Изначально школьник читает со скоростью 30 страниц в час. Однако, как только суммарное количество прочитанных за этот месяц страниц достигает отметки в 1000 страниц, его навык скорочтения улучшается, и скорость увеличивается до 40 страниц в час.
Примечание: Если переключение скорости происходит прямо в процессе чтения какой-то книги, время на ее чтение рассчитывается пропорционально.
Пример: Допустим, Стёпа уже прочитал суммарно 650 страниц. Следующая по списку книга содержит 400 страниц. В этом случае первые 350 страниц этой книги (до достижения порога в 1000) он будет читать со старой скоростью (30 страниц/час), а оставшиеся 50 страниц — с новой скоростью (40 страниц/час).
Чтение списка литературы должно автоматически прекратиться, если добавление следующей по порядку книги приведет к превышению общего лимита времени. Книги, прочитанные лишь частично (на которые не хватило времени до конца), в итоговый список не попадают.
Структура БД:
CREATE TABLE books (
id INTEGER PRIMARY KEY AUTOINCREMENT,
title TEXT NOT NULL,
pages INTEGER NOT NULL CHECK (pages > 0)
);
Схема БД в UML-нотации:
Напишите SQL-запрос, который смоделирует процесс чтения и выведет список книг в том порядке, в котором их прочитает школьник.
Результирующая таблица должна содержать следующие столбцы:
Порядок — порядковый номер прочитанной книги (начиная с 1).
Название книги — столбец title.
Количество страниц — столбец pages.
Всего страниц — накопительная сумма прочитанных страниц на момент окончания чтения текущей книги.
Затрачено часов (всего) — суммарное затраченное время в часах на момент окончания чтения текущей книги. Значение необходимо округлить до двух знаков после запятой с помощью функции ROUND().
Ограничения
Полагается, что для работы с базой данных используется SQLite3.
До запуска нового грандиозного шоу Мистера Биста «Остров на выживание» осталось совсем немного времени.
Сценаристы и продюсеры уже отобрали идеальныx кандидатов, прошедших серию предварительных испытаний.
Однако в результате технического сбоя на главном сервере таблица с финальным списком участников была безвозвратно удалена.
К счастью, данные о претендентах и логи прохождения испытаний в таблицах candidates и activity_logs полностью уцелели.
Вам, как главному дата-аналитику команды, поручено срочно восстановить точный список участников.
Мистер Бист лично утвердил жесткий алгоритм отбора:
1. Критерий прогресса: В шоу могут попасть только те кандидаты, которые успешно завершили все 3 этапа испытаний,
причем их результаты строго росли от этапа к этапу (балл за 2-й этап должен быть строго выше, чем за 1-й, а балл за 3-й — строго выше, чем за 2-й).
2. Ограничение количества участников: Шоу международное, поэтому от одной страны может поехать не более 3 человек.
В квоту попадают участники с наибольшим суммарным количеством баллов за все 3 этапа.
3. Разрешение ничьих: Если у кандидатов из одной страны совпадает общая сумма баллов,
приоритет отдается тому, кто потратил суммарно меньше времени duration_seconds на прохождение всех испытаний.
Если совпадает и время, выбор делается в пользу кандидата с меньшим candidate_id.
CREATE TABLE candidates (
candidate_id INTEGER PRIMARY KEY AUTOINCREMENT,
full_name TEXT NOT NULL,
country TEXT NOT NULL,
age INTEGER NOT NULL
);
CREATE TABLE activity_logs (
log_id INTEGER PRIMARY KEY AUTOINCREMENT,
candidate_id INTEGER NOT NULL,
stage_number INTEGER NOT NULL CHECK (stage_number BETWEEN 1 AND 3),
score INTEGER NOT NULL CHECK (score BETWEEN 0 AND 100),
duration_seconds INTEGER NOT NULL CHECK (duration_seconds > 0),
FOREIGN KEY (candidate_id) REFERENCES candidates(candidate_id)
);
Схема БД в UML-нотации:
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Результат должен быть отсортирован по названию страны в алфавитном порядке, а внутри страны - по возрастанию локального порядкового номера (от 1 до 3).
Ограничения
Предполагается, что для работы с базой данных используется SQLite3.
"Возлюби ближнего твоего, как самого себя" - вычитали из одной очень популярной книги жители деревни. Они
решили следовать мудрой заповеди, но долго не могли понять кого конкретно из "ближних" им любить.
Расположение халуп в деревне задано координатами x, y в таблице Houses. Необходимо сделать SQL запрос,
который для каждого дома выведет x_nearest, y_nearest ближайшего соседа. При наличии одинаковых
расстояний между домами, выбираются координаты того дома, что имеет меньшее id.
CREATE TABLE Houses ( id INTEGER NOT NULL PRIMARY KEY, x INTEGER NOT NULL, y
INTEGER NOT NULL );
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Результатом выполнения запроса должен быть список кортежей (x, y, nearest_x, nearest_y) для каждого
дома, отсортированный по возрастанию x, при равных x — по возрастанию y.
Описание полей запроса:
x — координата дома по оси X;
y — координата дома по оси Y;
nearest_x — координата X ближайшего соседа;
nearest_y — координата Y ближайшего соседа.
Ограничения
Предполагается, что для работы с базой данных используется SQLite3.
Нэнси Дрю - знаменитая девушка-детектив, приехала в старинное поместье Блэкмур, где во время ночной экскурсии начали происходить странные происшествия:
в комнатах появлялись маски, тайные знаки, погасшие свечи и другие подозрительные предметы.
У Нэнси есть журнал перемещений гостей по комнатам, список вещей, которые были у каждого подозреваемого,
и список зафиксированных происшествий.
Нэнси считает, что подозреваемый мог устроить происшествие, если одновременно выполняются два условия:
у подозреваемого был предмет, необходимый для данного происшествия;
подозреваемый находился в нужной комнате хотя бы в один момент времени в промежутке от 15 минут до происшествия включительно до момента происшествия включительно.
Если один и тот же подозреваемый попадает под одно происшествие несколькими записями журнала, это происшествие всё равно считается только один раз.
База данных имеет следующую структуру:
CREATE TABLE IF NOT EXISTS Suspects (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS SuspectItems (
suspect_id INTEGER REFERENCES Suspects(id),
item TEXT NOT NULL,
PRIMARY KEY (suspect_id, item)
);
CREATE TABLE IF NOT EXISTS Incidents (
id INTEGER PRIMARY KEY,
room TEXT NOT NULL,
incident_time TEXT NOT NULL,
required_item TEXT NOT NULL,
importance INTEGER NOT NULL
);
CREATE TABLE IF NOT EXISTS RoomLog (
suspect_id INTEGER REFERENCES Suspects(id),
room TEXT NOT NULL,
entered_at TEXT NOT NULL,
left_at TEXT NOT NULL
);
Требуется составить SQL-запрос, который найдёт наиболее подозрительных людей.
Для каждого подозреваемого нужно посчитать:
covered_incidents — сколько разных происшествий он мог устроить;
suspicion_score — сумму значений importance по этим происшествиям.
В ответ нужно вывести только тех подозреваемых, у кого значение covered_incidents максимально.
Если таких подозреваемых несколько, среди них нужно оставить только тех, у кого максимально значение suspicion_score.
Результатом выполнения запроса должен быть список кортежей
(suspect_name, covered_incidents, suspicion_score),
отсортированный по возрастанию suspect_name.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
В Долине Фей начинается подготовка к празднику весеннего равноденствия. До рассвета нужно зажечь фонарики,
раскрыть первые бутоны, наполнить ручьи талой водой, разбудить лесных зверят и украсить главную поляну.
У каждой феи есть свой дар: свет, цветы, вода, животные, мастерство или другой дар. Каждое праздничное задание
можно выполнить только с помощью определённого дара. Фея может выполнить задание, если её дар совпадает со значением
поля required_gift у этого задания.
Королева Клэрион хочет выбрать ведущих фей для праздничного маршрута. Ей нужны только те феи, чей дар понадобится
не просто несколько раз, а в разных уголках Долины. Поэтому фея подходит, если она может выполнить задания как минимум
в двух различных местах праздника.
База данных имеет следующую структуру:
CREATE TABLE IF NOT EXISTS Fairies (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
gift TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS FestivalTasks (
id INTEGER PRIMARY KEY,
task_name TEXT NOT NULL,
area TEXT NOT NULL,
required_gift TEXT NOT NULL,
magic_points INTEGER NOT NULL
);
Требуется составить SQL-запрос, который для каждой подходящей феи выведет:
fairy_name — имя феи;
gift — её волшебный дар;
area_count — количество различных мест, где есть задания для её дара;
task_count — общее количество заданий, которые фея может выполнить;
total_magic — суммарное количество волшебных очков magic_points за эти задания.
Результатом выполнения запроса должен быть список кортежей
(fairy_name, gift, area_count, task_count, total_magic).
Выводить нужно только тех фей, для которых area_count не меньше 2.
Список нужно отсортировать по убыванию area_count, затем по убыванию total_magic,
а при равенстве — по возрастанию fairy_name.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Вы оказались в Backrooms — бесконечных комнатах, заполненных
опасными сущностями. Вам нужно найти кратчайший путь к выходу,
используя поиск в ширину (BFS).
База данных содержит информацию о комнатах и связях между ними.
В таблице room хранятся:
id — уникальный идентификатор комнаты
level — уровень Backrooms (1, 2, 3...)
x, y — координаты комнаты на уровне
room_type — тип комнаты ('safe' - безопасная, 'hazard' - опасная)
is_exit — является ли комната выходом (1 - да, 0 - нет)
is_entity — есть ли в комнате сущность (1 - да, 0 - нет)
entity_name — имя сущности (если есть)
В таблице connection хранятся связи между комнатами:
from_room_id — ID комнаты, из которой идёт переход
to_room_id — ID комнаты, в которую идёт переход
direction — направление ('up', 'down', 'left', 'right')
is_blocked — заблокирован ли проход (1 - да, 0 - нет)
Ваша задача — написать SQL-запрос, который для каждого уровня
найдёт комнату, с которой нужно начать путь, чтобы добраться
до выхода за наименьшее количество шагов, и выведет:
Номер уровня (level)
ID стартовой комнаты (start_room_id)
Координаты стартовой комнаты (start_x, start_y)
Кратчайшее расстояние до выхода (steps) в количестве переходов
Количество опасных комнат (hazard_count) на найденном пути
Критерии выбора стартовой комнаты (в порядке приоритета):
Минимальное количество шагов до выхода
Минимальное количество опасных комнат на пути
Минимальный ID комнаты (при равенстве первых двух критериев)
Важно:
Путь не должен проходить через комнаты с сущностями (is_entity = 1),
включая стартовую комнату
Путь не должен проходить через заблокированные проходы (is_blocked = 1)
Выходом считается комната с is_exit = 1
Стартовая комната не должна быть выходом
Стартовая комната не должна содержать сущность
В подсчет hazard_count включаются все опасные комнаты на пути,
включая стартовую (если она опасна), но исключая выход
Если на уровне нет пути к выходу, такие уровни не включать в результат
Отсортировать результат по номеру уровня.
Подсказка: В SQLite есть рекурсивные CTE (WITH RECURSIVE),
которые позволяют реализовать BFS.
CREATE TABLE Room (
id INTEGER not null primary key,
level INTEGER not null,
x INTEGER not null,
y INTEGER not null,
room_type VARCHAR(50) not null,
is_exit INTEGER not null default 0,
is_entity INTEGER not null default 0,
entity_name VARCHAR(100)
);
CREATE TABLE Connection (
from_room_id INTEGER not null,
to_room_id INTEGER not null,
direction VARCHAR(10) not null,
is_blocked INTEGER not null default 0,
primary key (from_room_id, to_room_id),
foreign key (from_room_id) references Room(id),
foreign key (to_room_id) references Room(id)
);
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
