| Автор: | А. Баранов | Ограничение времени: | 1 сек | |
| Входной файл: | test.db | Ограничение памяти: | 256 Мб | |
| Выходной файл: | test.log |
Ньют Саламандер путешествует по миру, собирая информацию о редких видах магических животных. Результаты своих исследований он хранит в БД, состоящей из следующих таблиц:
ENCOUNTERS (встречи)
BEAST INTEGER REFERENCES BEASTS(ROWI),
PLACE INTEGER REFERENCES PLACES(ROWI),
CONSTRAINT UNIQ UNIQUE (BEAST, PLACE)
PLACES (места)
ROWI INTEGER PRIMARY KEY,
NAME VARCHAR,
CONT INTEGER REFERENCES CONTINENTS(ROWI),
CONSTRAINT UNIQ UNIQUE (NAME, CONT)
CONTINENTS (континенты)
ROWI INTEGER PRIMARY KEY,
NAME VARCHAR UNIQUE
BEASTS (животные)
ROWI INTEGER PRIMARY KEY,
NAME VARCHAR UNIQUE
Требуется составить запрос, возвращающий выборку существ, встречающихся сразу на нескольких различных континентах, отсортированную по их названиям.
Результирующая таблица должна состоять из двух столбцов:
название животного (BEASTS.NAME) и количество континентов, на которых встречаются представители данного вида.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Полагается, что для работы с базой данных используется SQLite3.
| Автор: | А. Баранов | Ограничение времени: | 1 сек | |
| Входной файл: | test.db | Ограничение памяти: | 256 Мб | |
| Выходной файл: | test.log |
Одной спортивной организации понадобилось сформировать отчет обо всех когда-либо проведенных ею соревнованиях.
Все данные о прошедших соревнованиях и их результатах хранятся в базе данных, состоящей из следующих таблиц:
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,
...
Однако уже в процессе оказалось, что основная таблица, содержащая всю сводную информацию, была утеряна.
В связи с этим возникла необходимость восстановить ее на основе существующих в БД записей.
В качестве ответа необходимо вывести таблицу, состоящую из следующих столбцов:
Сортировка производится по всем имеющимся столбцам в порядке их следования.
При этом у команд, набравших равное число баллов, места должны совпадать.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Полагается, что для работы с базой данных используется SQLite3.
| Автор: | А. Баранов | Ограничение времени: | 1 сек | |
| Входной файл: | test.db | Ограничение памяти: | 256 Мб | |
| Выходной файл: | test.log |
После того как Вася устроился сисадмином в одну крупную научную библиотеку, он пришел в ужас от того, насколько небрежно была сформирована библиографическая база, с которой ему на тот момент предстояло работать.
Ранее все данные об имеющихся в наличии научных статьях собирались в одну большую таблицу ARTICLES:
| AUTHOR_NAME VARCHAR NOT NULL, TITLE VARCHAR NOT NULL, YEAR INTEGER NOT NULL; |
У записей в такой таблице для авторов, имеющих более одной статьи, первый атрибут будет повторяться. Последние два атрибута также могут совпасть, если в таблице имеются статьи, написанные группой авторов.
В дальнейшем была добавлена еще одна таблица, содержащая биографические данные авторов AUTHORS:
| NAME VARCHAR NOT NULL, BIRTH DATE NOT NULL, DEATH DATE DEFAULT NULL, |
| ID INTEGER PRIMARY KEY; |
Во избежание путаницы и дублирования отдельных полей следует привести указанные таблицы к одной из нормальных форм.
После недолгих раздумий, Вася принял решение реорганизовать таблицу ARTICLES:
| TITLE VARCHAR NOT NULL, YEAR INTEGER NOT NULL, |
| ID INTEGER PRIMARY KEY; |
В свою очередь, связи между авторами и их публикациями он намеревается вынести в отдельную таблицу, содержащую привязку к AUTHORS.ID и ARTICLES.ID.
Проблемы возникли после того, как он обнаружил, что поле NAME у разных авторов может совпадать.
Чтобы разобраться в данной ситуации Вася тщательно изучил имеющийся свод правил и обнаружил следующие утверждения:
- авторы могут публиковать свои работы только по наступлении 18-летия;
- в некоторых случаях также возможна посмертная публикация статьи, но не позднее 100 дней со дня смерти автора.
Однако этого также может оказаться недостаточно, т.к. годы жизни одноименных авторов могут перекрываться.
В этом случае следует определить всех возможных авторов для каждой отдельной работы.
Для того, чтобы помочь Васе, от Вас требуется написать SQL-запрос.
Результат запроса должен представлять собой объединение (JOIN) таблиц AUTHORS и ARTICLES,
где первый столбец будет содержать AUTHORS.ID,
второй и третий столбцы — ARTICLES.TITLE и ARTICLES.YEAR, соответственно;
а последний столбец принимает одно из двух значений:
'?' — если авторство находится под вопросом;
'+' — если оно достоверно установлено.
Статьи, не принадлежащие конкретному автору, а также авторы, не имеющие ни одной статьи, в выборку не добавляются.
Сортировка производится по всем имеющимся столбцам в порядке их следования.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Полагается, что для работы с базой данных используется SQLite3.
Значения типа DATE задаются в виде строк, имеющих следующий формат: YYYY-MM-DD
| Автор: | А. Баранов | Ограничение времени: | 1 сек | |
| Входной файл: | test.db | Ограничение памяти: | 256 Мб | |
| Выходной файл: | test.log |
База данных предприятия состоит из двух основных таблиц, содержащих информацию о сотрудниках и связанных с ними событиях.
EMPLOYEES (сотрудники):
| ROWI INTEGER PRIMARY KEY, ... ; |
EVENTS (события):
| ROWI INTEGER PRIMARY KEY, WHOI INTEGER REFERENCES EMPLOYEES(ROWI), WHAT INTEGER, TIME DATE, |
| CONSTRAINT UNIQ UNIQUE (WHOI, TIME); |
Здесь тип события (WHAT) может принимать одно из следующих значений:
0 — принят на работу,
1 — ушел в отпуск,
2 — вышел из отпуска,
3 — уволен.
Требуется выполнить проверку содержащихся в БД записей на предмет соответствия указанным ниже правилам:
- сотрудники, информация о которых содержится в таблице EMPLOYEES, хотя бы раз должны быть приняты на работу;
- сотрудник не может быть принят на работу, если в данный момент он уже числится на ней;
- сотрудник не может уйти в отпуск, если на данный момент он не числится на работе;
- сотрудник не может уйти в новый отпуск, пока не закончится предыдущий;
- сотрудник не может выйти из отпуска, если на данный момент у него нет открытых отпусков;
- в таблице не должно быть сотрудников с не закрытыми отпусками;
- продолжительность отпуска не должна превышать 30 дней;
- сотрудник не может быть уволен во время своего отпуска;
- сотрудник не может быть уволен в течение 14 календарных дней со дня выхода из отпуска;
- сотрудник не может быть уволен, если на данный момент он не числится на работе.
В качестве ответа нужно вывести таблицу из двух столбцов, в которой каждому сотруднику (EMPLOYEES.ROWI),
ставится в соответствие значение:
1 — если все записи о нем корректны;
0 — в противном случае.
Результат выборки должен быть отсортирован по первому столбцу.
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Полагается, что для работы с базой данных используется SQLite3.
Значения типа DATE задаются в виде строк, имеющих следующий формат: YYYY-MM-DD
| Автор: | А. Баранов | Ограничение времени: | 1 сек | |
| Входной файл: | test.db | Ограничение памяти: | 256 Мб | |
| Выходной файл: | test.log |
Для поддержания структуры файловой системы с иерархической организацией каталогов используется база данных специального вида.
Информация об имеющихся в наличии файлах и каталогах содержится в таблице ITEMS:
| ROWI INTEGER PRIMARY KEY, NAME CHAR(255) NOT NULL, TYPE BOOLEAN NOT NULL, ... ; |
Здесь поле TYPE может принимать одно из следующих значений: 0 — регулярный файл; 1 — каталог.
В свою очередь, информация о связях между элементами хранится в таблице LINKS:
| ROWI INTEGER PRIMARY KEY, | |
| ROOT INTEGER REFERENCES ITEMS(ROWI), | — ссылка на родительский каталог; |
| ITEM INTEGER REFERENCES ITEMS(ROWI); | — ссылка на внутренний элемент. |
Для доступа к файлам и подкаталогам используются символьные пути, включающие имена всех промежуточных каталогов.
Процедура слияния двух каталогов заключается в добавлении тех элементов,
которые отсутствуют в одном, но имеются в другом каталоге.
В процессе слияния возможны коллизии, связанные с наличием в обоих каталогах файлов (либо файла с подкаталогом),
доступных по одним и тем же символьным путям.
При этом существование двух таких подкаталогов коллизией не считается.
Каталоги, не привязанные к какому либо родителю, считаются корневыми.
Необходимо сравнить все имеющиеся пары корневых каталогов,
оценив число коллизий между ними.
В качестве ответа нужно вывести таблицу из трех столбцов:
ROWI первого каталога,
ROWI второго каталога,
число коллизий.
Результат выборки должен быть отсортирован в порядке возрастания по первым двум столбцам.
При этом значения в 1-м столбце должны быть строго меньше, чем во втором.
Записи с нулевым числом коллизий в выборку не добавляются!
Решение следует представить в виде текстового файла, содержащего единственный SQL-запрос.
Полагается, что для работы с базой данных используется SQLite3.
Имена файлов и каталогов состоят из цифр и букв латинского алфавита,
при этом заглавные и строчные символы неразличимы между собой.
Гарантируется, что в БД отсутствуют циклические зависимости,
а каждый элемент имеет не более одного предка.
| Автор: | А. Баранов | Ограничение времени: | 1 сек | |
| Входной файл: | test.db | Ограничение памяти: | 256 Мб | |
| Выходной файл: | test.log |
Молодой программист Вася прибыл на международную 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).
Полагается, что для работы с базой данных используется SQLite3.
Значения типа DATE задаются в виде строк, имеющих следующий формат: YYYY-MM-DD HH:MM