В таблицу 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-запрос.
В таблице Animals нужно изменить все значения поля Sex с
длинных вариантов: "male", "female" на короткие: "m", "w".
Для прочих значений поля Sex, нужно указать "unknown", если
они не "NULL".
Решение следует представить в виде текстового файла, содержащего несколько SQL-запросов.
Ограничения
Полагается, что для работы с базой данных используется SQLite3.
Требуется по UML-схеме создать базу данных при помощи DDL-скрипта на языке SQL.
При описании полей таблицы следует указывать только тип значений и связи.
Поле id следует сделать первичным ключом.
Схема БД в UML-нотации:
Решение следует представить в виде текстового файла, содержащего несколько SQL-запросов.
Ограничения
Полагается, что для работы с базой данных используется SQLite3.
На автостоянке эксплуатируется БД, в которой содержится информация о том, какому автомобилю из 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-запрос.
Братья Паша и Миша получили пятёрки на экзамене
по базам данных и коротают время в ожидании друзей,
играя в морской бой.
Паша играет за пиратов и
назначил каждой палубе своих кораблей по одному из головорезов.
Как большой специалист в области эксплуатации и проектирования
баз данных, Паша, разумеется, всю информацию хранит
в специально созданной базе данных (DDL-схема которой приведена ниже).
Испанские торговые корабли Миши то и дело
грабит Пашин четырёхпалубный флагман.
Миша придумал план — назначить награду за головы тех четырёх отморозков,
которые им командуют.
Честь мундира не позволяет Мише воспользоваться sqlite-браузером и
посмотреть требуемую информацию.
Помогите Мише составить запрос к базе данных,
который бы вывел имена четырёх пиратов в алфавитном порядке,
хозяйничающих на пиратском четырёхпалубном корабле.
Известно, что корабли пиратов расположены по правилам классического морского боя.
CREATE TABLE Sector (
id INTEGER not null primary key,
latitude INTEGER not null,
longitude INTEGER not null,
is_ship INTEGER not null,
pirate_name VARCHAR(255)
);
Решение следует представить в виде текстового файла,
содержащего единственный 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-запрос.
В психоневрологическом диспансере "Брусничка" каждый пациент считает себя какой-либо исторической личностью.
Информация о каждом пациенте занесена в базу данных. Для каждого отделения в этом диспансере требуется выяснить, какая личность наиболее популярная.
Если таких личностей несколько, вывести их все.
CREATE TABLE IF NOT EXISTS "Alterego" (
"Id" INTEGER UNIQUE,
"Name" TEXT NOT NULL,
PRIMARY KEY("Id")
);
CREATE TABLE IF NOT EXISTS "Department" (
"Id" INTEGER UNIQUE,
"Head" TEXT,
PRIMARY KEY("Id")
);
CREATE TABLE IF NOT EXISTS "Patient" (
"Id" INTEGER UNIQUE,
"Name" TEXT NOT NULL,
"Age" INTEGER NOT NULL,
"Alterego" INTEGER NOT NULL,
"Department" INTEGER NOT NULL,
FOREIGN KEY("Department") REFERENCES "Department"("Id"),
FOREIGN KEY("Alterego") REFERENCES "Alterego"("Id"),
PRIMARY KEY("Id")
);
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей, отсортированный по номеру отделения и имени альтер-эго.
(Department.Id, Alterego.Name, (количество пациентов с этим альтер-эго))
Решение следует представить в виде текстового файла, содержащего единственный 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-запрос.
Главврачу необходимо знать актуальную информацию о наличии страховых медицинских полисов
у мед. работников и пациентов.
В БД больницы хранится список врачей Doctors, список пациентов Patients, список
личной информации о физ. лицах PersonalData и список полисов ОМС MedicalInsurance.
При этом, заболевший врач может быть одновременно и пациентом больницы.
В таблице PersonalData хранится информация обо всех
работавших в больнице врачах и обо всех обращавшихся за мед. помощью пациентах.
В таблицах Doctors и Patients содержится только актуальная информация о врачах
и пациентах, но без личных сведений.
В таблице MedicalInsurance у актуальных полисов значение поля Status равно
"active", в противном случае - "deactivated";
у врачей и пациентов может и вовсе не быть полисов ОМС.
Ниже представлено детальное DDL-описание таблиц:
TABLE Doctors ( -- хранит список работающих врачей
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
PersonalDataID INTEGER NOT NULL -- идентификатор персональной информации
REFERENCES PersonalData (ID)
);
TABLE Patients ( -- хранит список лечащихся пациентов
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
PersonalDataID INTEGER NOT NULL -- идентификатор персональной информации
REFERENCES PersonalData (ID)
);
TABLE PersonalData ( -- хранит персональную информацию по врачам и пациентам
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
FullName TEXT NOT NULL, -- ФИО лица
MedicalInsuranceID INTEGER REFERENCES MedicalInsurance (ID) -- идентификатор полиса ОМС
UNIQUE
);
TABLE MedicalInsurance (
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
Status TEXT NOT NULL -- статус полиса ОМС
DEFAULT ('active')
CHECK (Status IN ('active', 'deactivated') ),
Number VARCHAR (16) NOT NULL -- номер полиса ОМС
UNIQUE
);
Требуется подсчитать количество постояльцев (врачей и пациентов) больницы, у которых есть актуальные полисы ОМС.
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть один кортеж
(TotalPeopleWithMI), где TotalPeopleWithMI - количество постояльцев больницы
с актуальными полисами ОМС.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Российский видеоблогер Илья Мэддисон решил выпустить обзор новой компьютерной игры.
Но, при установки её на компьютер, его Windows 10 не выдержала нагрузки и "слетела",
так как недавно получила новый накопительный пакет обновлений.
Помогите Илье восстановить данные с диска, написав
SQL-запрос к таблице файловой системы.
Файловая системы содержит три типа записей:
"root" - корень диска, "dir" - директория, "file" - файл; имеет следующую структуру:
id - уникальный идентификатор записи;
object_name - название объекта (буквы диска, директории, файла);
object_type - указывает какого типа объект хранится в ФС: "root", "dir", "file";
parent_id - указывает вложенность файла или директории в корень диска или директорию;
extension - если присутствует, то указывает расширение файла.
Результатом выполнения запроса должна быть список полных имен full_name файлов, директорий и
букв диска. Чтобы отличить типы объектов, нужно выводить символ ":" в конце буквы диска,
"\" в конце названия директории, значение поля extension через "." в конце имени файла.
В качестве разделителя между объектами используется символ "\", список имен должен быть отсортирован
по возрастанию id.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Студент ДВФУ проходил производственную практику в ИТ-отделе предприятия.
Должность руководителя отдела называется PC Principal.
По окончании практики студенту требуется составить отчет, частью которого
является описание организационной структуры ИТ-отдела предприятия.
Он решил воспользоваться локальной БД предприятия, которая хранит
в одной таблице Employees список всех сотрудников вместе
с иерархией подчиненности (для каждого
сотрудника указывается его непосредственный начальник).
Для учредителя компании поле ChiefID равно NULL.
Название занимаемых должностей вынесено в отдельную таблицу Positions.
У линейного персонала может быть не указана должность.
Ниже представлено детальное DDL-описание таблиц:
TABLE Employees ( -- хранит список сотрудников
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
FullName TEXT NOT NULL, -- ФИО сотрудника
PositionID INTEGER REFERENCES Positions (ID), -- должность сотрудника
ChiefID INTEGER REFERENCES Employees (ID) -- непосредственный начальник
);
TABLE Positions ( -- хранит список должностей
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
Title TEXT UNIQUE -- название должности
NOT NULL
);
Требуется создать представление ShowITEmployees, вызов которого вернут список
всех сотрудников ИТ-отдела во главе с PC Principal. Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(ID, FullName, Position, ChiefID).
Описание полей запроса:
ID - идентификатор сотрудника;
FullName - ФИО сотрудника;
Position - должность сотрудника;
ChiefID - идентификатор руководителя сотрудника.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
В БД хранится список специалистов тех. поддержки Specialists,
список инцидентов Incidents и список назначений специалиста тех.
поддержки на инцидент Assignment для дальнейшего устранения последствий инцидента.
За устранение последствий каждого инцидента отвечает единственный
специалист тех. поддержки. Все инциденты обрабатываются специалистами
в порядке регистрации инцидентов в БД. Устраненные инциденты никак не помечаются, вместо
этого у каждого специалиста есть поле Resolved,
которое хранит количество устраненных инцидентов.
Ниже представлено детальное DDL-описание таблиц:
TABLE Specialists ( -- хранит список специалистов тех. поддержки
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
FullName TEXT NOT NULL, -- ФИО специалиста
Resolved INTEGER NOT NULL -- количество обработанных инцидентов
CHECK (Resolved >= 0)
DEFAULT (0)
);
TABLE Incidents ( -- список всех инцидентов
ID INTEGER PRIMARY KEY AUTOINCREMENT -- уникальный идентификатор
NOT NULL,
Title TEXT NOT NULL, -- заголовок инцидента
CreatedAt DATETIME NOT NULL,
Description TEXT -- описание инцидента
);
TABLE Assignment ( -- список назначений инцидентов специалистам
SpeсialistID INTEGER NOT NULL -- идентификатор специалиста
REFERENCES Specialists (ID),
IncidentID INTEGER NOT NULL -- идентификатор инцидента
REFERENCES Incidents (ID),
UNIQUE (
SpeсialistID,
IncidentID
)
);
Требуется для каждого специалиста тех. поддержки вывести 5 ближайших к устранению инцидентов.
Результат отсортировать по SpeсialistID, затем по порядку обработки.
Если специалист устранил все инциденты, то его следует игнорировать.
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(FullName, IncidentTitle).
Описание полей запроса:
FullName - ФИО специалиста;
IncidentTitle - название инцидента.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
В момент нападения врага на наш пункт контроля, командир Женя обратил внимание,
что на самом пункте не было достаточного количества вооружения.
На что Женя воскликнул «Где боеприпасы?».
Похоже, большое количество оружия находится на других точках.
Жене необходимо провести запрос, чтобы узнать точное количество оружия, а также определить, какое оружие наиболее распространено на всех военных точках.
Как менеджер небольшого гостиничного комплекса, вы столкнулись с
интригующей дилеммой управления финансами клиентов, которая стала подлинным
лабиринтом финансовых непоняток.
Недавно, в ходе масштабного анализа, вы
выявили весьма запутанный сценарий: у некоторых ваших ценных гостей появились
долги. Каждый клиент задолжал за свой номер и потребленные им
услуги. И хотя, конечно, эти задолженности, в какой-то степени, погашаются.
Необходимо предпринять сложные и деликатные шаги, такие как звонки и напоминания,
чтобы ввести гостей в курс дела относительно оставшихся N рублей долга.
CREATE TABLE IF NOT EXISTS client
(
client_id INTEGER PRIMARY KEY,
first_name TEXT,
last_name TEXT,
email TEXT,
phone_number TEXT
);
CREATE TABLE IF NOT EXISTS payment
(
payment_id INTEGER PRIMARY KEY,
reservation_id INTEGER,
payment_method TEXT,
amount DECIMAL(10, 2),
payment_date DATETIME,
FOREIGN KEY (reservation_id) REFERENCES reservation (reservation_id)
);
CREATE TABLE IF NOT EXISTS reservation_service
(
reservation_service_id INTEGER PRIMARY KEY,
reservation_id INTEGER,
service_id INTEGER,
FOREIGN KEY (reservation_id) REFERENCES reservation (reservation_id),
FOREIGN KEY (service_id) REFERENCES service (service_id)
);
CREATE TABLE IF NOT EXISTS reservation
(
reservation_id INTEGER PRIMARY KEY,
room_id INTEGER,
client_id INTEGER,
check_in_date DATE,
check_out_date DATE,
staff_id INTEGER,
FOREIGN KEY (room_id) REFERENCES room (room_id),
FOREIGN KEY (client_id) REFERENCES client (client_id),
FOREIGN KEY (staff_id) REFERENCES staff (staff_id)
);
CREATE TABLE IF NOT EXISTS rooms
(
room_id INTEGER PRIMARY KEY,
room_number TEXT,
room_type TEXT,
rate DECIMAL(10, 2)
);
CREATE TABLE IF NOT EXISTS service
(
service_id INTEGER PRIMARY KEY,
service_name TEXT,
price DECIMAL(10, 2)
);
CREATE TABLE IF NOT EXISTS staff
(
staff_id INTEGER PRIMARY KEY,
first_name TEXT,
last_name TEXT,
position TEXT
);
Схема БД в UML-нотации:
Результатом выполнения запроса должен быть список кортежей
(client_name, remaining_amount),
отсортированный по убыванию значений поля remaining_amount.
• client_name – ФИО клиентов;
• remaining_amount – Сумма которую осталось заплатить;
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Правительство Демократического Государства (ДГ) начало специальную военную операцию против некоторого Тоталитарного Ближне-восточного Государства (ТБГ). В рамках этой операции предусмотрено освобождение ТБГ от пагубного нефтяного ресурса.
У ДГ есть информация о нахождении нефтяных месторождений, которая получена от двойного агента. Информация хранится в базе данных.
Таблица Locations хранит информацию о нефтяных объектах: расположение (координаты) в километрах, силы противника (численность войск).
Таблица Pumps связана с таблицей Locations и хранит информацию о нефтяных насосах (добыча баррелей в неделю).
Десантный отряд армии ДГ высаживается в точке с координатами x = 0, y = 0. Командир отряда приказал найти ближайшие месторождения (не более 300км по прямой), где войск противника будет меньше 500, а объем добычи более 800 баррелей/неделю.
CREATE TABLE Locations(
id INTEGER PRIMARY KEY AUTOINCREMENT,
x INTEGER NOT NULL,
y INTEGER NOT NULL,
forces INTEGER NOT NULL,
pump_id INTEGER,
FOREIGN KEY (pump_id) REFERENCES Pumps(id)
);
CREATE TABLE Pumps(
id INTEGER PRIMARY KEY AUTOINCREMENT,
amount INTEGER NOT NULL
);
Схема БД в UML-нотации:
Запрос должен вернуть дистанцию до месторождения, кол-во войск и объем добычи. Отсортировать по возрастанию дистанции. Дистанцию округлить до целых по правилам математического округления.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
