В таблицу Cities нужно добавить города
Vladivostok, Novosibirsk, Lesozavodsk.
Для города Vladivostok нужно указать население: 604901. Структура таблицы:
ID - идентификатор записи с автоинкрементном;
Town - название города;
Population - численность населения.
Решение следует представить в виде текстового файла, содержащего несколько SQL-запросов.
Запросы следует завершать символом ';'.
Ограничения
Полагается, что для работы с базой данных используется SQLite3.
Требуется на языке SQL реализовать запрос, который обращается к таблице
data и возвращает список ID пользователей,
совершивших 20 и более международных звонков.
В таблице data присутствуют следующие поля:
ID — идентификатор пользователя, целое уникальное число
Total day minutes — сумма минут дневных звонков, вещественное число
Total day calls — количество дневных звонков, целое число
Total night minutes — сумма минут ночных звонков, вещественное число
Total night calls — количество ночных звонков, целое число
Total intl minutes — сумма минут международных звонков, вещественное число
Total intl calls — количество международных звонков, целое число
Customer service calls — количество обращений в техническую поддержку, целое число
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
При отправке следует выбирать среду разработки Python.
База данных представлена одной таблицей Numbers, в
которой хранится набор целых чисел Value.
Требуется классифицировать числа на положительные "positive",
отрицательные "negative" и ноль "zero".
Ниже представлено детальное DDL-описание таблицы:
TABLE Numbers ( -- хранит список целых чисел
Value INTEGER NOT NULL -- целое число
DEFAULT (0)
);
Результатом выполнения запроса должен быть список кортежей
(Value, Classification).
Описание полей запроса:
Value - значение;
Classification - классификация на положительные, отрицательные и ноль.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
На известном автомобильном рынке `Синий угол` кипит жизнь. Плотный поток продаж и покупок делают
хороший поток прибыли. Однако нечестные продавцы иногда снижают пробег автомобилей,
чтобы набить цену! И некоторые наглеют настолько, что пробег после использования некоторым
владельцем становится меньше, чем до того, как автомобиль попал к владельцу.
Благо, записи о сделках хранят в себе информацию о пробеге авто в момент покупки.
Ваша задача выяснить, сколько пробега было гарантированно скручено с каждого автомобиля, занесённого в
базу.
Так как объём авто большой, то те автомобили, для которых доказать факт мошенничества не получается,
попасть в выборку не должны.
CREATE TABLE AUTO (
id INTEGER NOT NULL PRIMARY KEY,
model VARCHAR(255) NOT NULL,
year VARCHAR(255) NOT NULL,
registration_number VARCHAR(255)
);
CREATE UNIQUE INDEX auto_registration_number
ON auto(registration_number);
CREATE TABLE sellrecord (
id INTEGER NOT NULL PRIMARY KEY,
odometer INTEGER NOT NULL,
price INTEGER NOT NULL,
auto_id INTEGER NOT NULL REFERENCES auto(id),
"date" DATE NOT NULL
);
CREATE INDEX sellrecord_auto_id ON sellrecord(auto_id);
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(model, (количество скрученного пробега)),
отсортированных по убыванию пробега.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
В таблице Animals нужно изменить все значения поля Sex с
длинных вариантов: "male", "female" на короткие: "m", "w".
Для прочих значений поля Sex, нужно указать "unknown", если
они не "NULL".
Решение следует представить в виде текстового файла, содержащего несколько SQL-запросов.
Ограничения
Полагается, что для работы с базой данных используется SQLite3.
Требуется по UML-схеме создать базу данных при помощи DDL-скрипта на языке SQL.
При описании полей таблицы следует указывать только тип значений и связи.
Поле id следует сделать первичным ключом.
Схема БД в UML-нотации:
Решение следует представить в виде текстового файла, содержащего несколько SQL-запросов.
Ограничения
Полагается, что для работы с базой данных используется SQLite3.
4-е поколение игровых консолей ознаменовалось одной из самых ожесточённых консольных войн в истории: Sega Mega Drive (также Sega Genesis) против Super Nintendo (SNES). Оба консоледержателя не стеснялись самых грязных методов лишь бы доказать, что именно их система лучше.
После игрового кризиса 1983 года компания Nintendo смогла подняться с помощью своей консоли NES (Famicom в Японии, Dendy в России), захватив до 90% игрового рынка. Разработчики подписывали с Nintendo договор, который запрещал выпускать свои игры для других систем в течение нескольких лет, что фактически превращало Nintendo в монополиста.
Первым кто смог бросить вызов большой N оказалась компания Sega. Пусть Nintendo в итоге и вышла победителем, определённый удар по самолюбию нанесён был.
Во времена того поколения начала распространяться мультиплатформа, хоть и из-за ограничивающих договоров была распространена практика, когда под одним и тем же названием на обоих системах выпускались совершенно разные игры. Необходимо найти игры, выпущенные для обоих платформ и от одного разработчика.
CREATE TABLE Developer (
ID INTEGER PRIMARY KEY AUTOINCREMENT,
Name VARCHAR (50) NOT NULL
UNIQUE
);
CREATE TABLE SegaGenesis (
ID INTEGER PRIMARY KEY AUTOINCREMENT,
Name VARCHR (40) NOT NULL
UNIQUE,
Developer INTEGER,
Release INTEGER,
CHECK (Release >= 1988),
FOREIGN KEY(Developer) REFERENCES Developer (ID)
);
CREATE TABLE SNES (
ID INTEGER PRIMARY KEY AUTOINCREMENT,
Name VARCHR (40) NOT NULL
UNIQUE,
Developer INTEGER,
Release INTEGER,
CHECK (Release >= 1990),
FOREIGN KEY(Developer) REFERENCES Developer (ID)
);
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(название игры, разработчик)
, содержащий все удовлетворяющие условиям задачи игры с указанными разработчиками.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
На автостоянке эксплуатируется БД, в которой содержится информация о том, какому автомобилю из Cars принадлежит
то или иное паковочное место из ParkingPlaces. Для реализации связи "многие ко многим", была заведена
таблица CarsParkings, где автомобилю сопоставляется конкретное пронумерованное место на стоянке. Каждый автомобиль
может иметь несколько парковочных мест.
Ниже представлено детальное DDL-описание таблиц:
TABLE Cars ( -- машины
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
CarNumber TEXT NOT NULL -- номер автомобиля
UNIQUE
);
TABLE ParkingPlaces ( -- парковочные места
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
ParkingNumber TEXT NOT NULL -- номер парковочного места
UNIQUE
);
TABLE CarsParkings ( -- принадлежность парковочного места автомобилю
CarID INTEGER REFERENCES Cars (ID) -- идентификатор автомобиля
NOT NULL,
ParkingID INTEGER REFERENCES ParkingPlaces (ID) -- идентификатор парковочного места
NOT NULL,
UNIQUE (
CarID,
ParkingID
)
);
Требуется вывести все автомобили, у которых есть парковочные места. Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(CarNumber, ParkingNumber).
Описание полей запроса:
CarNumber - номер автомобиля;
ParkingNumber - номер парковочного места.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
В глубинах галактики, где переплетаются судьбы джедаев и ситхов, зародилось древнее пророчество. Говорят, что те, кто обучался у мастеров-ситхов, нередко искушались Темной стороной Силы.
Совет джедаев поручил вам важную миссию — вычислить всех потенциально падших учеников, чтобы предотвратить катастрофу.
Ваша задача — выбрать всех Джедаев (Jedi), у которых хотя бы один из наставников (прямой мастер или грандмастер) относится к фракции «Sith».
При этом число медиахлорианов у такого ученика должно быть выше среднего значения среди всех джедаев.
Обратите внимание, что данные о количестве медиахлорианов могут быть неизвестны (NULL).
Такие ситуации происходят по разным причинам, иногда это число действительно неизвестно, а иногда оно намеренно удаляется из базы.
В этом случае замените NULL на значение «Unknown».
Результаты необходимо отсортировать так, чтобы в начале шли записи с неизвестным количеством медиахлорианов, а затем — по убыванию числового значения.
1096 год стал переломным в истории рыцарства. Король объявил, что рыцари, которые смогут выиграть хотя бы по одному турниру в каждом
месяце этого года, получат особую медаль за отвагу. Эта медаль дает рыцарю право на землю, место в совете и гарантирует высокое положение в обществе.
Многие смельчаки со всего королевства бросились участвовать в турнирах, чтобы доказать свое мастерство и получить эту награду.
Однако далеко не все смогли выдержать такой напряженный график. Ваша задача — выяснить, кто из рыцарей смог выполнить условие короля и навсегда вписать
свое имя в историю. Для каждого такого рыцаря нужно вывести список всех турниров, которые он выиграл в 1096 году с указанием накопленной суммы
очков славы после каждого турнира, чтобы летописцы могли внести их имена в список избранных.
В базе данных хранятся записи о рыцарях и турнирах. Каждый турнир имеет название, дату проведения и количество очков славы, которое получит победитель.
Гарантируется, что не существует турниров, у которых победитель еще не определен.
CREATE TABLE IF NOT EXISTS Knights (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS Tournaments (
id INTEGER PRIMARY KEY,
name TEXT NOT NULL,
date DATE NOT NULL,
glory INTEGER NOT NULL
);
CREATE TABLE IF NOT EXISTS TournamentWinners (
id INTEGER PRIMARY KEY,
tournament_id INTEGER NOT NULL UNIQUE,
knight_id INTEGER NOT NULL,
FOREIGN KEY (knight_id) REFERENCES Knights(id),
FOREIGN KEY (tournament_id) REFERENCES Tournaments(id)
);
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(KnightName, TournamentName, TournamentDate, GloryPoints, TotalGlory),
отсортированных по убыванию общей суммы очков славы рыцаря и возрастанию даты проведения турнира.
Описание полей запроса:
KnightName - Имя рыцаря.
TournamentName - Название турнира.
TournamentDate - Дата проведения турнира.
GloryPoints - Очки славы, полученные за победу в турнире.
TotalGlory - Накопленная сумма очков славы рыцарем после данного турнира.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Как известно, на гоночный турнир «Формула 1» постоянно собирается множество желающих насладиться гонками на высокой скорости, но, к сожалению Российские команды в этом турнире учавствовать не могут, как, впрочем, и смотреть. По этому в России было решено заместить турнир и дать ему новое название «Бэтрайдер 1».
К вам обратилась команда «Ессеньтуки» за помощью в анализе разнообразных марок машин, чтобы на их основе сделать свою, лучшую машину. Для этого у них есть трасса, размеченная специальными регистраторами - участками, находящимися на всех перекрестках и поворотах дорог. Каждый регистратор способен только расспознать, какая марка машины проехала сквозь него и записать марку и время в таблицу Timestamps. Раз регистраторы стоят на всех перекрестках, организаторами было решено посчитать длину трассы между ними и добавить результаты в таблицу Road. Таким образом таблица Timestamps свидетельствует о моменте преодолевания машины определенного регистратора, а Road содержит в себе структуру трассы и расстояние между участками.
По данным из таблиц вам необходимо понять, на какой средней скорости двигались машины, отсортировать их в порядке убывания по ней и вывести упорядоченные марки и соответствующую среднюю скорость в метрах в секунду. Важно помнить, что машина может проехать один участок как несколько раз, так и ни разу.
CREATE TABLE IF NOT EXISTS Registers (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS Cars (
id INTEGER PRIMARY KEY AUTOINCREMENT,
name TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS Road (
reg_1_id INTEGER NOT NULL,
reg_2_id INTEGER NOT NULL,
distance INTEGER NOT NULL,
FOREIGN KEY (reg_1_id) REFERENCES Registers (id),
FOREIGN KEY (reg_2_id) REFERENCES Registers (id)
);
CREATE TABLE IF NOT EXISTS Timestamps (
reg_id INTEGER NOT NULL,
car_id INTEGER NOT NULL,
timestamp DATETIME NOT NULL,
FOREIGN KEY (reg_id) REFERENCES Registers (id),
FOREIGN KEY (car_id) REFERENCES Cars (id)
);
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(name, avg_speed),
отсортированных по убыванию средней скорости, с округлением до целого числа.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
База данных представлена одной таблицей Numbers, в
которой хранится набор целых чисел Value.
Требуется вычислить минимальное и максимальное значения,
сумму и количество чисел в таблице,
среднее значение среди всех чисел.
Ниже представлено детальное DDL-описание таблицы:
TABLE Numbers ( -- хранит список целых чисел
Value INTEGER NOT NULL -- целое число
DEFAULT (0)
);
Результатом выполнения запроса должен быть единственный кортеж
(MinValue, MaxValue, SumValue, CountValue, AvgValue).
Описание полей запроса:
MinValue - минимальное значение;
MaxValue - максимальное значение;
SumValue - сумма чисел;
CountValue - количество чисел;
AvgValue - среднее значение.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Руководитель магазина решил наградить 10 самых продуктивных сотрудников. Для этого
ему нужен запрос, который посчитает суммарную выручку каждого сотрудника магазина,
отсортирует по убыванию суммарной выручки и возьмёт первые 10 кортежей. Выводить
следует только продающих сотрудников.
Требуется по фрагменту схемы реляционной БД составить данный запрос на языке SQL.
Описание таблиц на схеме:
Sellers - сотрудники магазина (продавцы);
Products - продаваемые товары;
Sales - продажи;
SalesItems - позиции продаж.
Результатом выполнения запроса должен быть список кортежей (SellerFullName,
TotalRevenue, CountOfSales) отсортированный по убыванию значений поля TotalRevenue
и содержащий максимум 10 записей. Описание полей запроса:
SellerFullName - полное имя продавца (Фамилия и Имя через пробел);
TotalRevenue - суммарная выручка продавца, полученная от продажи товаров;
CountOfSales - совокупное количество продаж.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Товарооборот магазина одежды фиксируется в базе данных этой компании.
БД хранит список товаров Products, список категорий товаров
Categories, список купленных у поставщиков товаров PurchaseItems
и список проданных клиентам товаров SalesItems.
У товара поле CategoryID может быть NULL,
если товар не подходи ни под одну из существующих категорий.
Если товар ни разу не закупался и не продавался, то его следует игнорировать.
Ниже представлено детальное DDL-описание таблиц:
TABLE Categories ( -- хранит список категорий товаров
ID INTEGER NOT NULL -- уникальный идентификатор
PRIMARY KEY AUTOINCREMENT,
Name TEXT UNIQUE -- наименование категории
NOT NULL
);
TABLE Products ( -- хранит список товаров
ID INTEGER NOT NULL -- уникальный идентификатор
PRIMARY KEY AUTOINCREMENT,
Title TEXT UNIQUE -- название товара
NOT NULL,
CategoryID INTEGER, -- идентификатор категории
SellingPrice REAL CHECK (SellingPrice > 0) -- розничная цена продажи товара
NOT NULL,
FOREIGN KEY (
CategoryID
)
REFERENCES Categories (ID) ON DELETE CASCADE
);
TABLE PurchaseItems ( -- хранит список товаров, купленных у поставщиков
ID INTEGER NOT NULL -- уникальный идентификатор
PRIMARY KEY AUTOINCREMENT,
ProductID INTEGER NOT NULL, -- идентификатор товара
QuantityBought INTEGER NOT NULL -- количество купленного товара (штук)
CHECK (QuantityBought > 0)
DEFAULT (1),
FOREIGN KEY (
ProductID
)
REFERENCES Products (ID) ON DELETE CASCADE
);
TABLE SalesItems ( -- хранит список проданных клиентам товаров
ID INTEGER NOT NULL -- уникальный идентификатор
PRIMARY KEY AUTOINCREMENT,
ProductID INTEGER NOT NULL, -- идентификатор товара
QuantitySold INTEGER NOT NULL -- количество проданного товара (штук)
CHECK (QuantitySold > 0)
DEFAULT (1),
FOREIGN KEY (
ProductID
)
REFERENCES Products (ID) ON DELETE CASCADE
);
Требуется вывести список закончившихся товаров.
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(Title, CategoryName, SellingPrice) для товаров с
нулевым остатком, отсортированный по убыванию розничных цен продажи.
Описание полей запроса:
Title - название товара;
CategoryName - наименование категории;
SellingPrice - розничная цена продажи товара.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
В базе данных торговой компании хранится список сотрудников Employees и список
департаментов Departments. Каждый сотрудник может числиться только в одном департаменте или
не числиться ни в одном из них. Также, существуют новые департаменты без сотрудников.
Ниже представлено детальное DDL-описание таблиц:
TABLE Employees ( -- хранит список сотрудников
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
FullName TEXT NOT NULL, -- ФИО сотрудника
Age INTEGER CHECK (Age >= 0), -- возраст сотрудника
DepartmentID INTEGER REFERENCES Departments (ID) -- идентификатор департамента
);
TABLE Departments ( -- хранит список департаментов
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
Name TEXT NOT NULL -- название департамента
UNIQUE
);
Требуется из таблицы Departments выбрать все департаменты и
указать какое количество сотрудников числится в каждом из них. Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(DepartmentName, TotalPeople).
Описание полей запроса:
Department - название департамента;
TotalPeople - количество сотрудников в департаменте.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Менеджеру по персоналу поручили определить сотрудников, которые могут уволиться из-за низкой заработной платы.
Он считает зарплату низкой, если она строго меньше средней. БД содержит список сотрудников Employee,
список должностей Positions и список зарплат Salaries. Работник компании может занимать несколько
должностей и получать зарплату, состоящую из размера полной ставки Salary умноженную на долю от ставки
SalaryPercentage.
Ниже представлено детальное DDL-описание таблиц:
TABLE Employees ( -- хранит список сотрудников
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
FullName TEXT NOT NULL -- ФИО сотрудника
);
TABLE Positions ( -- хранит список должностей
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
Title TEXT NOT NULL -- название должности
UNIQUE,
Salary INTEGER NOT NULL -- полная ставка заработной платы (в руб.)
CHECK (Salary > 0)
);
TABLE Salaries ( -- хранит список зарплат
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
EmployeeID INTEGER NOT NULL -- идентификатор сотрудника
REFERENCES Employees (ID),
PositionID INTEGER NOT NULL -- идентификатор должности
REFERENCES Positions (ID),
SalaryPercentage REAL NOT NULL -- получаемая доля от полной ставки з. п.
CHECK (SalaryPercentage BETWEEN 0 AND 1)
DEFAULT (1),
UNIQUE (
EmployeeID,
PositionID
)
);
Требуется вывести список сотрудников, получающих низкую (ниже средней по организации) зарплату.
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(EmployeeFullNames, SumSalary), отсортированный по возрастанию поля SumSalary.
Описание полей запроса:
EmployeeFullNames - ФИО сотрудника;
SumSalary - зарплата сотрудника по всем занимаемым должностям.
Значения поля SumSalary должны быть округлены до ближайших целых чисел.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
В сервисных центрах ИТ-компаний активно используется система управления инцидентами.
Клиенты СЦ создают задачи task, где описывают возникшие проблемы и отправляют их
сотрудникам СЦ. Задача имеет статус, который отражает степень её выполнения.
Только что поступившая задача от клиента помечается как "new", когда задача
полностью выполнена, сотрудники СЦ переводят её в статус "completed".
Задача может находиться в любом статусе несколько раз, количество статусов не ограничено.
Аналитик СЦ хочет оценить эффективность других сотрудников СЦ. Для это необходим
SQL-запрос который возвращает совокупное количество задач в статусах "new" и "completed"
для каждого дня за последние 30 дней (считать от времени создания последней задачи)
в порядке следования дат в календаре. Требуется составить данный запрос.
Результатом выполнения запроса должен быть список кортежей (date,
number_of_new, number_of_completed)
отсортированный по возрастанию значений поля
date
и содержащий количество задач в статусах "new" и "completed", построенных
за каждый день функционирования системы в течении 30 дней с даты самой актуальной
задачи. Если одна и та же задача перешла в два разных статуса
в один момент времени, то учитывается переход с максимальным id записи.
Описание полей запроса:
date
- дата формирования сводной статистики в формате YYYY-MM-DD;
number_of_new
- количество заявок в статусе "new" на 23:59:59 дня date;
number_of_completed
- количество заявок в статусе "completed" на 23:59:59 дня date.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Ньют Саламандер путешествует по миру, собирая информацию о редких видах магических животных.
Результаты своих исследований он хранит в БД, состоящей из следующих таблиц:
Требуется составить запрос, возвращающий выборку существ, встречающихся сразу на нескольких различных континентах, отсортированную по их названиям.
Результирующая таблица должна состоять из двух столбцов:
название животного (BEASTS.NAME) и количество континентов, на которых встречаются представители данного вида.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Одной спортивной организации понадобилось сформировать отчет обо всех когда-либо проведенных ею соревнованиях.
Все данные о прошедших соревнованиях и их результатах хранятся в базе данных, состоящей из следующих таблиц:
CONTESTS (соревнования)
ROWI INTEGER PRIMARY KEY AUTOINCREMENT, -- ID соревнования
...
TEAMS (команды)
ROWI INTEGER PRIMARY KEY AUTOINCREMENT, -- ID команды
KIND INTEGER NOT NULL, -- ID дисциплины
...
POINTS (оценки)
CONTEST INTEGER REFERENCES CONTESTS(ROWI),
TEAM INTEGER REFERENCES TEAMS(ROWI),
MARK INTEGER NOT NULL,
...
Однако уже в процессе оказалось, что основная таблица, содержащая всю сводную информацию, была утеряна.
В связи с этим возникла необходимость восстановить ее на основе существующих в БД записей.
В качестве ответа необходимо вывести таблицу, состоящую из следующих столбцов:
ID соревнования,
ID дисциплины,
номер места среди участников текущей дисциплины (начиная с единицы),
ID команды.
Сортировка производится по всем имеющимся столбцам в порядке их следования.
При этом у команд, набравших равное число баллов, места должны совпадать.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Кот-Летун, известный своими амбициозными планами по захвату всех сырных запасов мира, решил отправиться в путешествие по
городам, где производят самые вкусные сорта сыра. У него есть карта, на которой отмечены города, соединенные дорогами. Каждый город
славится своим уникальным сыром, и Кот-Летун хочет попробовать их все, но с одним условием: он должен обязательно заглянуть в город "Камамбер"
(город К), где производят его любимый сыр.
Кот-Летун - кот занятой, поэтому он хочет найти все самые короткие маршруты от города "Альпийский" (город А) до города "Моцарелла" (город М),
обязательно проходящие через "Камамбер". При этом он не хочет посещать один и тот же город дважды, чтобы не переедать сыра
(ведь у него еще много планов на день).
Помогите Коту-Летуну найти все кратчайшие маршруты, удовлетворяющие его условиям, чтобы он смог насладиться сыром и продолжить свои приключения!
Кот-Летун предупреждает, что если вы не поможете ему с маршрутами, он может случайно съесть ваш обед. Будьте осторожны!
CREATE TABLE Roads (
from_city TEXT NOT NULL,
to_city TEXT NOT NULL,
PRIMARY KEY (from_city, to_city)
);
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(маршрут, длина)
, содержащий все удовлетворяющие условиям задачи кратчайшие маршруты и их длину.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Молодой программист Вася прибыл на международную IT-конференцию и почти сразу же озаботился следующей проблемой.
График мероприятий конференции хранится в БД.
Основу такой БД составляет таблица EVENTS, имеющая следующий вид:
ROWI INTEGER PRIMARY KEY AUTOINCREMENT,
HEAD DATE NOT NULL CHECK (HEAD < TAIL), -- начало мероприятия
TAIL DATE NOT NULL -- конец мероприятия
и таблица KWORDS, в которой каждому мероприятию ставится в соответствие набор ключевых слов.
EVENT INTEGER REFERENCES EVENTS(ROWI),
WORD INTEGER NOT NULL,
PRIMARY KEY (EVENT, WORD)
Вася хочет посетить как можно большее число мероприятий, которые не перекрываются по времени.
При этом его интересуют только те мероприятия, в описании которых встречаются ключевые слова из заданного списка.
Напишите SQL-запрос с параметром, выполняющий выборку таких мероприятий.
В качестве ответа нужно вывести таблицу, состоящую из одного столбца,
который будет содержать номера выбранных мероприятий, отсортированных по времени их начала.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Вместо списка ключевых слов в тексте запроса должен присутствовать символ (:words).
