УПРАВЛЕНИЕ ДАННЫМИ

Лабораторная работа №2. Таблицы и первый SELECT

Отчёт: скрипт lab02_FIO.sql (ФИО латиницей) + скриншоты результатов запросов.

Цель: в уже созданной на ЛР №1 пустой базе UniversityDB создать таблицы учебного эталона, загрузить данные и выполнить первые запросы SELECT.

0. Перед началом

1. Запустите SSMS и подключитесь к серверу (как на ЛР №1).
2. В Object Explorer откройте UniversityDB → Tables. Список пользовательских таблиц должен быть пуст (или только системные).
3. New Query, в списке баз выберите UniversityDB, выполните:

Если базы нет — вернитесь к ЛР №1 или выполните CREATE DATABASE UniversityDB;.

1. Где взять команды SQL

Готовые команды CREATE TABLE и INSERT — на странице Приложение: БД и скрипты, раздел «Сборка базы по шагам». Там же объяснено, что такое SQL-скрипт и зачем он разбит на блоки.

На этой лабораторной вы не скачиваете файл — копируете блоки в окно запроса и сохраняете свою версию как lab02_FIO.sql (ФИО латиницей).

* Если на прошлой попытке таблицы уже есть — выполните блок 2, затем блоки 3–6 заново.

2. Создание таблиц (блоки 3–5)

1. Откройте New Query, убедитесь, что выбрана UniversityDB.
2. Скопируйте из приложения блок 3 (UNIVERSITY и SUBJECT), выполните F5. Должно быть сообщение об успешном создании.
3. То же с блоком 4 (STUDENT, LECTURER) и блоком 5 (EXAM_MARKS, SUBJ_LECT, ORG_UNIT).
4. Обновите Object Explorer (F5). Под UniversityDB → Tables должны появиться семь таблиц.
5. Проверьте: правый клик на dbo.STUDENT → Design — видны столбцы STUDENT_ID, UNIVERSITY_ID, значок ключа у PK и FK.

3. Загрузка данных (блок 6)

Вставляйте блоки 6.1 → 6.7 по порядку из приложения (сначала вузы и предметы, в конце — подразделения). Можно выполнить весь блок 6 целиком или по частям — главное не нарушать порядок таблиц.

Контрольная проверка:

В ответе должно быть 19 студентов и 8 вузов. Сохраните скриншот результата для отчёта.

4. Первые запросы SELECT

SELECT читает данные из таблиц; он ничего не меняет. Выполните запросы ниже по очереди, результаты — в отчёт.

4.1. Все столбцы справочника вузов

Звёздочка * означает «все столбцы строки»:

В результате — 8 строк, столбцы UNIVERSITY_ID, UNIVERSITY_NAME, RATING, CITY.

4.2. Только название и город

Список столбцов через запятую — это проекция (выбор нужных полей):

4.3. Студенты одного вуза

Условие WHERE отбирает строки. Номер 10 — это ВГУ в эталонных данных:

В списке столбцов сначала NAME (имя), затем SURNAME (фамилия) — как требуется в задании.

4.4. Сколько строк в таблице

Агрегатная функция COUNT(*) считает строки. Для эталона ответ снова 19.

Окно New Query: сверху выбрана база UniversityDB, ниже — текст SQL.

Результат SELECT — на вкладке Results.

5. Файл отчёта

1. Сохраните в один файл lab02_FIO.sql (ФИО латиницей): команды USE, все CREATE TABLE, все INSERT и все SELECT из этой работы.
2. Добавьте в начало файла комментарий: -- ЛР №2, IvanovII, группа ВО-ИСИТ-31 (подставьте свои фамилию и инициалы латиницей).
3. К отчёту приложите скриншоты: список таблиц в Object Explorer, результат COUNT(*), один из запросов из §4.

6. Дополнительно

1. Найдите в блоках 3–5 ограничения CHECK (стипендия ≥ 0, курс 1–6, оценка 2–5). Выполните заведомо неверный INSERT, например студента с KURS = 9, и прочитайте текст ошибки.
2. Попробуйте вставить студента с UNIVERSITY_ID = 999. СУБД должна отклонить строку — нет такого вуза, сработал внешний ключ.
3. Откройте dbo.EXAM_MARKS и найдите студента без оценок (STUDENT_ID = 19). Эта строка специально нужна для заданий с IS NULL на следующих лабораторных.

Контрольные вопросы

1. Чем пустая UniversityDB после ЛР №1 отличается от той же базы после этой работы?
2. Почему таблицу UNIVERSITY создают раньше, чем STUDENT?
3. Что делает SELECT * FROM UNIVERSITY и чем он отличается от SELECT UNIVERSITY_NAME, CITY FROM UNIVERSITY?
4. Что произойдёт при INSERT студента с несуществующим UNIVERSITY_ID?
5. Зачем в отчёте хранить файл lab02_FIO.sql (ФИО латиницей), если база уже создана на сервере?

Лабораторная работа №3. DDL: CREATE, типы, ограничения

Отчёт: скрипт lab03_FIO.sql (ФИО латиницей) + скриншоты ошибок ограничений.

Цель: в той же UniversityDB, что и на ЛР №2, добавить нормализованные таблицы (группы и учебная библиотека вуза) с ограничениями PRIMARY KEY, UNIQUE, CHECK, FOREIGN KEY, загрузить данные и убедиться, что СУБД отклоняет неверные строки.

Связь с лекцией 3: декомпозиция «широкой» таблицы на сущности — как UNIVERSITY + STUDENT на ЛР №2 и как LIB_AUTHOR → LIB_BOOK → LIB_COPY сегодня. Отдельную базу данных на курсе не создаём.

0. Перед началом

1. Запустите SSMS и подключитесь к серверу.
2. Должна существовать UniversityDB после ЛР №2 (семь таблиц: UNIVERSITY, STUDENT, …).
3. Откройте New Query, выберите базу UniversityDB. Весь SQL ниже выполняйте только в ней.

1. Рабочая база курса

На ЛР №1 вы создавали контейнер базы; сегодня дополняем уже существующую схему — так устроен весь курс: одна UniversityDB от CREATE TABLE до курсовой.

В current_database должно быть UniversityDB. Число таблиц до работы — обычно 7 (после шага 2 станет 11).

2. Новые таблицы (лекция 3, пример Б + библиотека вуза)

Сначала справочник групп (староста хранится один раз — см. лекцию 3 §4.3), затем цепочка библиотеки: автор → книга → экземпляр. Создавайте таблицы в указанном порядке.

2.1. ACADEMIC_GROUP

2.2. LIB_AUTHOR

2.3. LIB_BOOK

PUB_YEAR — год издания; CHECK не допускает «1300» и будущие годы.

2.4. LIB_COPY

ON DELETE CASCADE: при удалении книги СУБД удалит все её экземпляры. STATUS: in — на полке, out — выдан читателю.

Object Explorer (F5): под UniversityDB → Tables — четыре новые таблицы рядом с STUDENT, EXAM_MARKS и др.

3. Загрузка данных

Сначала группы и авторы, затем книги, затем экземпляры — как при загрузке UniversityDB на ЛР №2.

Можете добавить свои строки (минимум 3–5 в каждой таблице). Проверка:

4. Проверка ограничений

Выполните команды ниже по одной. Каждая должна завершиться ошибкой — это ожидаемый результат. Сохраните текст ошибки или скриншот для отчёта.

4.1. Дубликат ISBN

Нарушение UNIQUE на ISBN.

4.2. Недопустимый год

Нарушение CHECK на PUB_YEAR.

4.3. Недопустимый статус

Нарушение CHECK на STATUS — допустимы только in и out.

4.4. Дополнительно (по желанию)

Нарушение внешнего ключа — автора с AUTHOR_ID = 999 нет.

5. Нормальные формы (письменный ответ в отчёте)

Кратко ответьте в комментарии в lab03_FIO.sql или в сопроводительном тексте:

1. Выполняется ли 1НФ? (атомарные ячейки, нет «списков авторов» в одной строке книги)
2. Выполняется ли 3НФ? (фамилия автора в LIB_AUTHOR, а не в каждой строке LIB_COPY; староста в ACADEMIC_GROUP, а не в каждой «широкой» строке с оценкой)
3. Что было бы плохого в одной таблице «всё сразу»: автор + ISBN + инвентарный номер + статус?

Ожидаемый вывод: схема в 1НФ и 3НФ; разделение убирает аномалии обновления (смена фамилии автора — одна строка в LIB_AUTHOR).

6. Файл отчёта

1. Сохраните в один файл lab03_FIO.sql (ФИО латиницей): USE UniversityDB, все CREATE TABLE, все успешные INSERT, контрольные SELECT COUNT.
2. Неверные INSERT из §4 можно оставить в файле закомментированными (-- в начале строки) с пометкой «ожидаемая ошибка».
3. В начале файла: -- ЛР №3, IvanovII, группа ВО-ИСИТ-31.
4. К отчёту приложите скриншоты: список таблиц в Object Explorer, одна успешная вставка, одна ошибка CHECK или UNIQUE.

Контрольные вопросы

1. Почему по курсу все лабораторные (включая эту) расширяют одну UniversityDB, а не создают новую базу на каждую тему?
2. Почему LIB_BOOK создают после LIB_AUTHOR, а LIB_COPY — после LIB_BOOK?
3. Чем PRIMARY KEY отличается от UNIQUE на примере ISBN и BOOK_ID?
4. Что делает ON DELETE CASCADE при удалении строки из LIB_BOOK?
5. Какая аномалия обновления исчезает, когда фамилия автора хранится только в LIB_AUTHOR?

Лабораторная работа №4. FK, ALTER TABLE, GO

Отчёт: скрипт lab04_FIO.sql (ФИО латиницей) + скриншоты из §1–5.

Цель: изменить существующую схему UniversityDB командами ALTER TABLE, добавить индексы, поработать с пакетами GO и убедиться, что ограничения FK и UNIQUE работают.

Связь с лекцией 4: схема живёт на общем сервере; ваш ALTER TABLE видят все сеансы. Внешние ключи с ЛР №2 защищают ссылки; сегодня добавляете столбец и индексы без пересоздания таблиц.

0. Перед началом

1. Запустите SSMS, подключитесь к учебному серверу (как на ЛР №1).
2. В Object Explorer откройте UniversityDB → Tables — как минимум семь таблиц после ЛР №2 (после ЛР №3 — ещё ACADEMIC_GROUP и LIB_*).
3. New Query, в списке баз выберите UniversityDB, выполните контроль:

Ожидается: 19 студентов и непустая таблица оценок. Если база пуста — повторите ЛР №2 (блоки приложения 3–6).

Object Explorer: под UniversityDB → Tables — STUDENT, UNIVERSITY, …

1. ALTER TABLE — новый столбец EMAIL

На ЛР №2 таблицы создавали через CREATE TABLE. В живой системе схему чаще дополняют — так деканат добавляет поле «email» без пересоздания таблицы и без потери 19 строк.

1. Выполните команду (F5). Сообщение: Commands completed successfully.
2. Обновите Object Explorer (F5). Правый клик dbo.STUDENT → Design — в списке столбцов появился EMAIL, тип varchar(100), Allow Nulls = да.
3. Заполните адреса по шаблону student<STUDENT_ID>@edu.local:

Конкретный запрос SELECT и ожидаемый фрагмент результата:

Фамилии возьмутся из вашего эталона; важны столбец EMAIL и шаблон адреса. Сделайте скриншот вкладки Results.

Окно New Query: сверху выбрана UniversityDB, ниже — ALTER и UPDATE.

Результат SELECT TOP 5 … EMAIL — приложите к отчёту.

2. Ограничение UNIQUE на EMAIL

UNIQUE запрещает два одинаковых значения в столбце (кроме NULL — в SQL Server несколько NULL в UNIQUE допустимы, но у вас все EMAIL заполнены).

Теперь намеренно нарушите правило — скопируйте адрес студента 1 студенту 2:

Ожидаемо: выполнение прервётся, на вкладке Messages текст вроде:

Сохраните скриншот вкладки Messages — это доказательство работы ограничения. Верните уникальные значения:

2.1. Напоминание про FK (с ЛР №2)

Если бы вы добавляли столбец UNIVERSITY_ID вместо EMAIL, FK не дал бы записать несуществующий вуз. Проверка (ожидается ошибка):

3. Индексы для ускорения поиска

Индекс — отдельная структура для быстрого поиска по столбцу. На ЛР №5–6 вы часто будете писать WHERE CITY = … и WHERE UNIVERSITY_ID = … AND KURS = … — под такие фильтры индексы уместны.

Clustered индекс один на таблицу (обычно PK); nonclustered — дополнительные «указатели» к строкам.

4. Просмотр индексов через sys.indexes

В результате должны быть как минимум:

Точное имя PK может отличаться — смотрите столбец index_name.

5. Пакеты GO

GO — не команда T-SQL, а разделитель пакетов в SSMS. Переменная, объявленная в одном пакете, не видна в следующем.

Ожидаемый результат второго пакета: students = 19.

Эксперимент: уберите оба GO и выполните скрипт целиком. Вторая строка DECLARE @cnt в том же пакете даст ошибку «имя переменной уже объявлено» или конфликт с первым пакетом — зафиксируйте текст ошибки в отчёте.

6. Файл отчёта

1. Сохраните в один файл lab04_FIO.sql (ФИО латиницей): USE, все ALTER, UPDATE, CREATE INDEX, SELECT из sys.indexes, скрипт с GO.
2. В начале: -- ЛР №4, IvanovII, группа ВО-ИСИТ-31 (подставьте свои фамилию и инициалы латиницей).
3. К отчёту приложите скриншоты: Object Explorer с таблицами; результат §1; ошибка UNIQUE §2; список индексов §4.
4. Согласуйте с преподавателем: оставить EMAIL и индексы для ЛР №5+ или удалить в конце скрипта:

Имя файла отчёта: lab04_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab04_IvanovII.sql.

7. Дополнительно (если осталось время)

1. Выполните EXEC sp_helpindex 'dbo.STUDENT'; — сравните вывод с sys.indexes.
2. Добавьте индекс только если его ещё нет — обсудите, зачем в production проверяют IF NOT EXISTS (на курсе достаточно комментария).
3. Объясните соседу, чем ALTER TABLE ADD безопаснее, чем «удалить STUDENT и создать заново».

Контрольные вопросы

1. Зачем на ЛР №2 создавали FK на родительские таблицы раньше дочерних?
2. Чем ALTER TABLE ADD отличается от повторного CREATE TABLE STUDENT?
3. Почему UNIQUE на EMAIL отклонил второй одинаковый адрес?
4. Зачем в одном скрипте несколько пакетов GO?
5. Как по sys.indexes отличить clustered и nonclustered индекс?

Лабораторная работа №5. INSERT, SELECT, WHERE

Отчёт: скрипт lab05_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: выполнить выборку с проекцией (список столбцов) и селекцией (WHERE): сравнение, AND/OR/NOT, IN, BETWEEN, LIKE, IS NULL на UniversityDB.

Связь с лекцией 2: вы уже делали простые SELECT на ЛР №2; здесь — систематическая работа с фильтрами. Справочник таблиц и эталонные данные — в приложении.

0. Перед началом

1. SSMS → подключение к учебному серверу → база UniversityDB.
2. Если на ЛР №4 добавляли столбец EMAIL — он не мешает; все запросы ниже работают и без него.
3. Контроль эталона:

Ожидается: 19 студентов, 24 строки в EXAM_MARKS, 8 предметов в SUBJECT (см. приложение).

Перед работой убедитесь, что в списке баз выбрана UniversityDB.

1. Проекция — выбор столбцов

Проекция — какие столбцы показать. Селекция — какие строки отобрать (WHERE, §2–4).

1.1. Все предметы

Ожидается 8 строк, столбцы SUBJ_ID, SUBJ_NAME, HOUR, SEMESTER.

1.2. Оценки по предмету «Информатика» (SUBJ_ID = 10)

В эталоне — несколько строк (оценки разных студентов). В комментарии к скрипту укажите -- rows: N.

1.3. Список студентов — только нужные поля

Ожидается 19 строк. Звёздочка * здесь не нужна — вы явно перечисляете столбцы отчёта.

2. Простые фильтры WHERE

Выполняйте запросы по одному. После каждого — запишите число строк (rows в углу Results или SELECT COUNT(*) … с тем же WHERE).

2.1. Предметы 4-го семестра

Ожидается 1 строка — «История» (SUBJ_ID = 56).

2.2. Студенты 3 курса и старше

2.3. Стипендия больше 140

2.4. Предметы длиннее 40 академических часов

Ожидается 4 строки (56, 72, 56, 56 часов в эталоне).

2.5. Вузы с рейтингом выше 400

Ожидается 6 вузов (рейтинг 410, 450, 470, 580, 650, 700).

Пример результата с фильтром — приложите один такой скриншот к отчёту.

3. Сложные условия — AND, OR, IN, BETWEEN

3.1. Студенты из Воронежа со стипендией

Буква N перед строкой — Unicode для кириллицы.

3.2. Преподаватели из Воронежа

3.3. Скобки и OR

Без скобок AND связывал бы только KURS = 2 со стипендией — логика изменилась бы.

3.4. IN и BETWEEN

4. LIKE и IS NULL

4.1. Фамилии на «С»

% — любое продолжение. Укажите в комментарии, сколько строк вернулось.

4.2. Студенты без города

Ожидается 1 строка — STUDENT_ID = 19 (специально для этой проверки).

4.3. Ошибка: = NULL

Сохраните скриншот: сравнение «0 строк» и «1 строка» — хороший фрагмент отчёта.

5. Частые ошибки

6. Файл отчёта

1. Сохраните все запросы из §1–4 в один файл lab05_FIO.sql (ФИО латиницей).
2. В начале файла: -- ЛР №5, IvanovII, группа ВО-ИСИТ-31 (подставьте свои фамилию и инициалы латиницей).
3. К каждому блоку §2–4 добавьте комментарий -- rows: N с числом строк результата.
4. К отчёту приложите скриншоты: контроль §0; один запрос из §2; сравнение = NULL и IS NULL из §4.3.

Имя файла отчёта: lab05_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab05_IvanovII.sql.

7. Дополнительно (если осталось время)

1. SELECT * FROM dbo.STUDENT WHERE NOT (KURS < 3); — сравните с KURS >= 3.
2. Запрос: студенты вуза ВГУ (UNIVERSITY_ID = 10) с стипендией выше средней по этому вузу (подсказка: подзапрос — ЛР №9).
3. Объясните, почему SELECT не меняет данные и не требует ROLLBACK (в отличие от ЛР №6).

Контрольные вопросы

1. Чем проекция отличается от селекции в одном SELECT?
2. Почему условие на SEMESTER относится к таблице SUBJECT, а не STUDENT?
3. Что вернёт LIKE N'С%' и зачем буква N?
4. Чем IS NULL отличается от = NULL?
5. Зачем в отчёте хранить файл lab05_FIO.sql (ФИО латиницей), если результат виден на экране?

Лабораторная работа №6. UPDATE, DELETE, ORDER BY

Отчёт: скрипт lab06_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: изменять данные (DML), сортировать выборку, использовать TOP и DISTINCT; безопасно экспериментировать в транзакции с ROLLBACK (лекция 5).

Связь с лекцией 5–6: на общем сервере незафиксированные UPDATE/DELETE видят другие сеансы — поэтому учебные изменения только с откатом.

0. Перед началом

Ожидается 19 студентов. Запишите число оценок — после всех ROLLBACK оно должно совпасть.

1. ORDER BY, TOP, DISTINCT

ORDER BY сортирует результат; TOP n ограничивает число строк (аналог LIMIT в других СУБД). DISTINCT убирает дубликаты в выборке.

1.1. Сортировка по стипендии

Вверху списка — студенты с наибольшей стипендией. Скриншот для отчёта.

1.2. TOP 5

Ровно 5 строк (если в таблице ≥ 5 студентов).

1.3. DISTINCT

В первом запросе — уникальные оценки (2–5); во втором — уникальные пары «курс + город».

Результат TOP 5 … ORDER BY STIPEND DESC — приложите к отчёту.

2. INSERT в транзакции

Сначала «пробные» строки — затем откат. Порядок: родитель UNIVERSITY, потом дочерний STUDENT (FK).

INSERT … SELECT вставляет строку, вычисленную запросом (здесь — рейтинг выше текущего максимума).

3. UPDATE в транзакции

Перед изменением — SELECT с тем же WHERE; после UPDATE — повторный SELECT; в конце — ROLLBACK.

После ROLLBACK у студента 15 снова должен быть исходный UNIVERSITY_ID из эталона.

4. DELETE с проверкой

После отката последний COUNT совпадает с первым — двойки (если были) на месте.

5. Удаление и внешний ключ

Нельзя удалить вуз, пока на него ссылаются студенты. Сначала проверьте ошибку:

Правильный порядок внутри транзакции: сначала DELETE студентов, потом вуза.

6. Частые ошибки

7. Файл отчёта

1. Сохраните все команды §1–5 в lab06_FIO.sql (ФИО латиницей).
2. В начале: -- ЛР №6, IvanovII, группа ВО-ИСИТ-31.
3. К каждому блоку с UPDATE/DELETE добавьте комментарий «до / после / после ROLLBACK».
4. Скриншоты: TOP 5; один UPDATE до ROLLBACK и после; ошибка FK при DELETE вуза.
5. Финальная проверка: SELECT COUNT(*) FROM dbo.STUDENT; = 19.

Имя файла отчёта: lab06_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab06_IvanovII.sql.

8. Дополнительно

1. SELECT TOP 5 PERCENT STIPEND, … ORDER BY STIPEND DESC; — чем отличается от TOP 5?
2. Попробуйте UPDATE с заведомо неверным CHECK (KURS = 9) внутри TRY/CATCH (ЛР №16).

Контрольные вопросы

1. Почему ORDER BY пишут после WHERE?
2. Зачем ROLLBACK после демонстрационного UPDATE на общем сервере?
3. Чем INSERT … SELECT отличается от INSERT … VALUES?
4. Почему DELETE вуза без удаления студентов вызывает ошибку FK?
5. Какая аномалия из лекции 6 связана с незафиксированными изменениями соседа?

Лабораторная работа №7. Агрегатные функции

Отчёт: скрипт lab07_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: использовать COUNT, SUM, AVG, MIN, MAX; понять, как NULL влияет на агрегаты; сверить ответы с эталоном из приложения.

Связь с курсом: на лекции 2 вы делали простые SELECT; здесь одна строка результата суммирует много строк таблицы. На ЛР №8 добавится GROUP BY — группы вместо «всей таблицы сразу».

Напоминание: все агрегаты, кроме COUNT(*), игнорируют строки, где аргумент равен NULL.

0. Перед началом

Ожидается: 19 студентов, 24 оценки, 8 предметов. Если числа другие — восстановите эталон (ЛР №2, блок 6 приложения).

1. COUNT — три варианта

COUNT(*) считает строки. COUNT(столбец) не учитывает NULL в этом столбце. COUNT(DISTINCT …) — число различных значений (NULL не входит).

1.1. Студенты и города

Ожидается: 19, 18, 8. У студента STUDENT_ID = 19 поле CITY специально NULL — поэтому COUNT(CITY) на 1 меньше, чем COUNT(*).

В комментарии к скрипту запишите: -- all_rows: 19; with_city: 18; distinct_cities: 8.

2. MIN, MAX, AVG по стипендии

Ожидается: min_st = 0, max_st = 250, avg_st ≈ 122.89 (среднее по всем 19, включая нулевые стипендии). Во втором запросе среднее только по студентам с STIPEND > 0 — ≈ 155.67 (15 строк).

Обратите внимание: нули в данных — не NULL; они участвуют в AVG первого запроса и занижают среднее.

3. Агрегаты по предметам, вузам и оценкам

Выполняйте запросы по одному; после каждого сверяйте результат с эталоном.

3.1. Часы и рейтинги

Ожидается: total_hours = 382 (сумма часов восьми предметов); min_rating = 320 (БГУ), max_rating = 700 (МГУ).

3.2. Оценки

Ожидается: avg_mark ≈ 4.08; 9 пятёрок; 1 двойка; первая дата 2026-01-15, последняя 2026-06-12.

CAST(MARK AS FLOAT) нужен, чтобы среднее было дробным, а не целым от деления типа INT.

Пример вкладки Results для блока §3 — одна строка с несколькими агрегатами. Сделайте скриншот для отчёта.

4. NULL в аргументе агрегата

В эталоне у всех 24 строк поле MARK заполнено — оба счётчика дают 24, разница 0. Это нормально: NULL в оценках зарезервирован для других заданий; здесь вы фиксируете, что COUNT(MARK) и COUNT(*) совпали.

Для строк с NULL смотрите §1: COUNT(CITY) vs COUNT(*) у STUDENT.

5. Файл отчёта

1. Сохраните все запросы §0–4 в lab07_FIO.sql (ФИО латиницей).
2. В начале: -- ЛР №7, IvanovII, группа ВО-ИСИТ-31.
3. К каждому блоку добавьте комментарий с ожидаемым значением (как в §1).
4. Скриншоты: результат §1 (три COUNT); результат §3.2 (оценки); один запрос с AVG и CAST.

Имя файла отчёта: lab07_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab07_IvanovII.sql.

6. Дополнительно

1. SELECT COUNT(*), COUNT(STIPEND) FROM dbo.STUDENT; — совпадут ли счётчики? Почему?
2. SELECT AVG(CAST(STIPEND AS FLOAT)) FROM dbo.STUDENT WHERE KURS = 1; — посчитайте вручную для первого курса (подготовка к GROUP BY на ЛР №8).
3. Чем опасно путать AVG(STIPEND) по всей таблице и среднее «только по получающим стипендию»?

Контрольные вопросы

1. Почему COUNT(CITY) меньше COUNT(*) у STUDENT?
2. Чем AVG(STIPEND) по всей таблице отличается от AVG при STIPEND > 0?
3. Зачем CAST(MARK AS FLOAT) перед AVG?
4. Что считает COUNT(MARK), если в столбце есть NULL?
5. Какие MIN/MAX по EXAM_DATE вы получили и что это означает для учебного семестра?

Лабораторная работа №8. GROUP BY, HAVING, ROLLUP

Отчёт: скрипт lab08_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: группировать строки (GROUP BY), отбирать группы через HAVING, строить итоги GROUP BY ROLLUP в SQL Server.

Связь с ЛР №7: там агрегаты считали по всей таблице; здесь — отдельно по каждому курсу, городу, предмету. Справочник эталона — в приложении.

Правило SQL: каждый столбец в SELECT должен быть либо в GROUP BY, либо внутри агрегатной функции (COUNT, AVG, …).

0. Перед началом

Ожидается 19 студентов. Если база пуста — повторите ЛР №2.

1. GROUP BY — одно измерение

GROUP BY делит строки на группы с одинаковым значением столбца; агрегат считается внутри каждой группы.

1.1. По курсу

Ожидается 5 строк (курсы 1–5). Пример значений: курс 1 — 6 студентов, средняя стипендия 135.00; курс 2 — 4 студента, 167.50; курс 3 — 4, 96.25; курс 4 — 3, 120.00; курс 5 — 2, 55.00.

1.2. По городу

Групп с заполненным городом — 8; отдельная группа с CITY IS NULL (студент 19) — 1 строка. Чаще всего встречаются Воронеж и Москва (по 4 студента).

1.3. По вузу

Ожидается 8 групп (вузы 10, 11, 12, 14, 15, 18, 22, 32). Например: UNIVERSITY_ID = 10 — 5 студентов, средняя стипендия ≈ 95.00; 22 (МГУ) — 4 студента, ≈ 102.50.

Результат GROUP BY KURS — несколько строк вместо одной сводки с ЛР №7.

2. GROUP BY по оценкам

Ожидается 7 предметов с оценками. Примеры: SUBJ_ID = 10 — 8 экзаменов, средний ≈ 4.00; 43 — 2 экзамена, средний 5.00; 22 — 4 экзамена, средний 3.50.

3. HAVING — фильтр групп

WHERE отбирает строки до группировки; HAVING — группы после агрегации (можно использовать условие на COUNT(*), AVG, …).

3.1. Курсы с более чем тремя студентами

Ожидается 3 строки: курсы 1 (6), 2 (4), 3 (4). Курсы 4 и 5 отсеялись — в группе ≤ 3 студента.

3.2. Предметы со средним баллом ≥ 4

Ожидается 6 предметов: 10, 18, 31, 43, 56, 94. Предмет 22 (средний 3.50) в список не попадает.

4. WHERE до GROUP BY

Сначала отбрасываются нулевые стипендии, затем считается среднее по оставшимся в группе. Пример: курс 1 — среднее ≈ 162.00 (5 студентов с ненулевой стипендией), курс 4 — 180.00 (студент 6 с нулём не участвует).

Если написать HAVING AVG(STIPEND) > 0 вместо WHERE STIPEND > 0, нули всё равно войдут в расчёт среднего внутри группы — результат будет другим. Это частая ошибка на защите.

5. ROLLUP

ROLLUP добавляет строку с KURS IS NULL — итог по всей таблице: cnt = 19, avg_st ≈ 122.89 (как на ЛР №7 без группировки). Строки с числом в KURS — группы по курсам из §1.1.

6. Файл отчёта

1. Сохраните запросы §0–5 в lab08_FIO.sql (ФИО латиницей).
2. В начале: -- ЛР №8, IvanovII, группа ВО-ИСИТ-31.
3. К каждому блоку — комментарий с числом строк результата и ключевыми значениями.
4. Скриншоты: GROUP BY KURS; HAVING COUNT(*) > 3; ROLLUP с итоговой строкой NULL.

Имя файла отчёта: lab08_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab08_IvanovII.sql.

7. Дополнительно

1. GROUP BY KURS, CITY — сколько групп получится? Сравните с группировкой только по KURS.
2. Почему SELECT KURS, SURNAME, COUNT(*) FROM STUDENT GROUP BY KURS вызывает ошибку?
3. Добавьте WITH ROLLUP к запросу §3.2 — что изменится в результате?

Контрольные вопросы

1. Почему столбцы в SELECT должны быть в GROUP BY или внутри агрегата?
2. Чем HAVING отличается от WHERE?
3. Зачем фильтровать STIPEND>0 до GROUP BY, а не в HAVING?
4. Что означает строка с NULL в ROLLUP?
5. Какие SUBJ_ID имеют средний балл ≥ 4 по вашим данным?

Лабораторная работа №9. Вложенные подзапросы

Отчёт: скрипт lab09_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: писать скалярные подзапросы, использовать IN и NOT IN; понять, почему NOT IN опасен при NULL в подзапросе.

Связь с ЛР №8: там вы считали агрегаты с GROUP BY; здесь тот же MAX/AVG спрятан внутри WHERE — подзапрос возвращает одно значение для сравнения с каждой строкой внешнего запроса.

0. Перед началом

Ожидается 19 студентов.

1. Скалярный подзапрос

Скалярный подзапрос возвращает одно значение (одну строку, один столбец). Его ставят в WHERE после =, >, < и т.д. Если вернётся больше одной строки — ошибка.

1.1. Максимальная стипендия

Ожидается 1 строка: Морозова, стипендия 250 (STUDENT_ID = 7).

1.2. Выше средней (только ненулевые стипендии)

Средняя по ненулевым ≈ 155.67. Ожидается 7 строк (Сидорова, Козлова, Морозова, Соколова, Зайцева, Лебедева, Крылова).

1.3. Вузы с рейтингом выше среднего

Средний рейтинг ≈ 496.25. Ожидается 3 вуза: НГУ (580), СПбГУ (650), МГУ (700).

Результат §1.1 — одна строка с максимальной стипендией.

2. Подзапрос с IN

IN (подзапрос) проверяет, входит ли значение во множество строк подзапроса. Эквивалентно нескольким OR, но короче и читабельнее.

2.1. Студенты московских вузов

В эталоне в Москве только МГУ (UNIVERSITY_ID = 22). Ожидается 4 студента (Сидорова, Сидоров, Кузнецов, Лебедева).

2.2. Оценки по «Информатике»

Предмет SUBJ_ID = 10 (Информатика). Ожидается 8 строк в EXAM_MARKS по этому предмету.

Тот же результат можно получить через JOIN — на ЛР №11 сравните оба стиля.

3. NOT IN

NOT IN исключает строки, попадающие в список подзапроса. Важно: если подзапрос вернёт хотя бы один NULL, результат внешнего запроса может стать пустым (логика трёхзначная). Поэтому в подзапросе часто пишут WHERE столбец IS NOT NULL.

3.1. Вузы без студентов

В эталоне студенты есть в каждом из 8 вузов — результат 0 строк. Это нормально: запишите в отчёте «пустой результат — все вузы представлены».

3.2. Студенты без оценок

Ожидается 1 строка: Медведев (STUDENT_ID = 19) — специально для заданий с NOT EXISTS на ЛР №10.

3.3. Предметы без экзаменов в ведомости

Ожидается 1 предмет: Физкультура (SUBJ_ID = 73).

4. Файл отчёта

1. Сохраните запросы §0–3 в lab09_FIO.sql (ФИО латиницей).
2. В начале: -- ЛР №9, IvanovII, группа ВО-ИСИТ-31.
3. К каждому блоку — комментарий -- rows: N и краткий вывод.
4. Скриншоты: §1.1 (одна строка); §1.2 (семь фамилий); §3.2 (Медведев).

Имя файла отчёта: lab09_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab09_IvanovII.sql.

5. Дополнительно

1. Перепишите §2.1 через JOIN с UNIVERSITY — совпали ли строки?
2. WHERE STIPEND > ALL (SELECT STIPEND FROM STUDENT WHERE STIPEND > 0 AND STUDENT_ID <> 7) — кого оставит?
3. Почему SELECT * FROM STUDENT WHERE STUDENT_ID NOT IN (SELECT STUDENT_ID FROM EXAM_MARKS) без фильтра NULL может вести себя странно, если в EXAM_MARKS появится NULL в STUDENT_ID?

Контрольные вопросы

1. Когда подзапрос в WHERE должен вернуть ровно одно значение?
2. Чем IN с подзапросом отличается от JOIN?
3. Почему NOT IN опасен, если в подзапросе есть NULL?
4. Как найти студентов без оценок через NOT IN?
5. Зачем DISTINCT в подзапросе для UNIVERSITY_ID?

Лабораторная работа №10. Коррелированные подзапросы и EXISTS

Отчёт: скрипт lab10_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: писать коррелированные подзапросы; использовать EXISTS, NOT EXISTS, операторы ANY/ALL.

Связь с ЛР №9: там подзапрос был «сам по себе»; здесь внутренний запрос ссылается на строку внешнего (s1.UNIVERSITY_ID) — выполняется заново для каждой строки снаружи.

0. Перед началом

1. Коррелированный подзапрос

Внутренний SELECT использует столбец внешней строки (s1.UNIVERSITY_ID, s1.KURS). Для каждого студента заново считается средняя стипендия в его вузе на его курсе.

Ожидается 3 строки: Иванов (ВГУ, 1 курс — выше среднего по группе), Орлов (ЮФУ, 1 курс), Белкин (ВГУ, 3 курс). Нули в знаменателе не мешают — они входят в среднее по группе.

2. EXISTS и NOT EXISTS

EXISTS (подзапрос) возвращает true, если подзапрос вернул хотя бы одну строку. Часто пишут SELECT 1 — важен факт наличия строк, а не их содержимое.

2.1. Вузы, где есть студенты 5-го курса

Ожидается 2 вуза: БГУ (студент 16) и МГУ (студент 10).

2.2. Вузы без студентов

В эталоне у каждого вуза есть студенты — результат 0 строк (как NOT IN в ЛР №9).

3. EXISTS по оценкам

Ожидается 8 студентов с хотя бы одной «5» (в эталоне — Иванов, Петров, Козлова, Волков, Кузнецов, Лебедева, Крылова и др.).

Ожидается 1 строка: Медведев (STUDENT_ID = 19) — тот же результат, что NOT IN на ЛР №9, но без ловушки NULL.

Результат §3 — один студент без оценок.

4. Оператор ALL

Строки, где оценка максимальна для своего предмета. Ожидается 12 строк (несколько «лучших» по предметам 10, 43, 56, 94 и т.д.). Если для предмета одна оценка — она тоже «максимальна».

Если подзапрос после ALL пуст (нет оценок по предмету), условие для внешней строки не выполняется — такие строки не попадут в результат.

5. Файл отчёта

1. Сохраните запросы §0–4 в lab10_FIO.sql (ФИО латиницей).
2. В начале: -- ЛР №10, IvanovII, группа ВО-ИСИТ-31.
3. К каждому блоку — -- rows: N и пояснение корреляции или EXISTS.
4. Скриншоты: §1 (3 строки); §3 NOT EXISTS (Медведев); §4 (несколько SUBJ_ID).

Имя файла отчёта: lab10_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab10_IvanovII.sql.

6. Дополнительно

1. Перепишите §3 NOT EXISTS через LEFT JOIN … WHERE em.STUDENT_ID IS NULL.
2. Сравните время выполнения (план запроса) IN vs EXISTS для §2.1 — кратко в комментарии.
3. WHERE STIPEND > ANY (SELECT …) — чем отличается от > ALL?

Контрольные вопросы

1. Почему коррелированный подзапрос ссылается на s1.UNIVERSITY_ID?
2. Чем EXISTS отличается от IN при проверке «есть строки»?
3. Когда NOT EXISTS предпочтительнее NOT IN?
4. Что вернёт ALL над пустым подзапросом?
5. Зачем в EXISTS пишут SELECT 1, а не SELECT *?

Лабораторная работа №11. INNER и OUTER JOIN

Отчёт: скрипт lab11_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: соединять таблицы через INNER JOIN и LEFT JOIN; строить отчёты по связям FK; считать агрегаты после JOIN.

Связь с ЛР №9–10: подзапрос с IN можно заменить JOIN — на этой работе учитесь читать и писать явные соединения. Схема FK — в приложении.

0. Перед началом

Нарисуйте цепочку: UNIVERSITY ← STUDENT → EXAM_MARKS → SUBJECT; отдельно SUBJ_LECT связывает SUBJECT и LECTURER. Условие соединения — равенство ключей FK.

1. INNER JOIN — студент и вуз

INNER JOIN оставляет только строки, для которых есть пара в обеих таблицах. У каждого студента в эталоне есть вуз — потерь строк не будет.

1.1. Список с городом вуза

Ожидается 19 строк — по числу студентов.

1.2. Студенты вузов не из Воронежа

Ожидается 13 строк (студенты вузов в Москве, СПб, Новосибирске и т.д.; вузы ВГУ и ВГМУ в Воронеже отсеяны).

2. Несколько INNER JOIN

2.1. Ведомость: студент, предмет, оценка

Ожидается 24 строки — все строки EXAM_MARKS с подставленными фамилиями и названиями предметов.

2.2. Кто какой предмет ведёт

Ожидается 12 строк — по таблице SUBJ_LECT в приложении.

К отчёту приложите свой скриншот вкладки Results для запроса §2.1 (ожидается 24 строки: фамилия, предмет, оценка, дата).

3. LEFT JOIN

LEFT JOIN сохраняет все строки левой таблицы; если справа нет пары — столбцы справа NULL.

3.1. Все вузы и их студенты

Ожидается 19 строк с фамилиями (у каждого вуза есть студенты; «пустых» вузов нет).

3.2. Вузы без студентов

В эталоне — 0 строк. Запишите в отчёте: «все 8 вузов представлены студентами».

3.3. Студенты без оценок

Ожидается 1 строка: Медведев (STUDENT_ID = 19) — тот же результат, что NOT EXISTS на ЛР №10.

4. Агрегаты с JOIN

Ожидается 8 строк. Используйте COUNT(s.STUDENT_ID), а не COUNT(*) — иначе вуз без студентов дал бы 1 вместо 0 (в эталоне все счётчики ≥ 1).

Только студенты с оценками; у Медведева строки не будет. Число строк — 18 (19 − 1 без ведомости).

5. Файл отчёта

1. Сохраните запросы §0–4 и схему связей (фото/скан) в lab11_FIO.sql или приложите схему отдельно в PDF.
2. В начале: -- ЛР №11, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: §1.2; §2.1; §3.3; §4 COUNT по вузам.

Имя файла отчёта: lab11_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab11_IvanovII.sql.

6. Дополнительно

1. Перепишите §1.2 через подзапрос IN (ЛР №9) — совпали ли строки?
2. Чем RIGHT JOIN отличается от LEFT JOIN (поменяли таблицы местами)?
3. Нарисуйте, что произойдёт при JOIN без условия ON (декартово произведение).

Контрольные вопросы

1. Чем INNER JOIN отличается от LEFT JOIN на примере вузов без студентов?
2. Почему COUNT(s.STUDENT_ID) и COUNT(*) могут различаться при LEFT JOIN?
3. Сколько таблиц участвует в ведомости §2.2?
4. Как найти студента без оценок через LEFT JOIN?
5. Зачем рисовать схему связей перед сложным JOIN?

Лабораторная работа №12. UNION, EXCEPT, INTERSECT

Отчёт: скрипт lab12_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: объединять результаты нескольких SELECT; понять разницу UNION и UNION ALL; применить множественные операции к эталону UniversityDB.

Связь с ЛР №11: JOIN соединяет таблицы в одном запросе; UNION складывает результаты двух запросов с одинаковым числом столбцов.

0. Перед началом

В эталоне: 19 студентов, 10 преподавателей, 24 строки EXAM_MARKS; у Медведева (STUDENT_ID=19) нет оценок.

1. Отчёт со JOIN

Средний балл по студенту с названием вуза — закрепление ЛР №11.

Ожидается 19 строк; у Медведева avg_mark = NULL.

2. UNION ALL — общий список фамилий

Ожидается 29 строк (19 студентов + 10 преподавателей).

3. INTERSECT и EXCEPT

INTERSECT — 7 городов (Воронеж, Москва, Новосибирск, Санкт-Петербург, Белгород, Томск, Ростов-на-Дону). EXCEPT — 1 строка: Курск (есть у студентов, нет среди городов вузов).

4. UNION vs UNION ALL

Повторите §2 с UNION вместо UNION ALL. В эталоне фамилии студентов и преподавателей не пересекаются — снова 29 строк. Запишите в отчёте: UNION удаляет дубликаты между двумя наборами; UNION ALL — нет.

5. Топ предметов

Только предметы с не менее двух оценок. Ожидается до 5 строк — зафиксируйте фактическое число и значения avg_mark в комментарии -- rows: N.

6. Файл отчёта

1. Сохраните запросы §0–5 в lab12_FIO.sql.
2. В начале: -- ЛР №12, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: §3 INTERSECT и EXCEPT; §5 TOP 5.

Имя файла отчёта: lab12_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab12_IvanovII.sql.

Контрольные вопросы

1. Почему в UNION число и типы столбцов должны совпадать?
2. Чем UNION ALL быстрее UNION?
3. Что вернёт INTERSECT городов студентов и вузов?
4. Зачем HAVING COUNT(*) >= 2 в топе предметов?
5. Когда EXCEPT полезнее NOT IN?

Лабораторная работа №13. Функции строк, чисел, дат

Отчёт: скрипт lab13_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: строковые и дата-функции T-SQL, ROUND, CAST на UniversityDB.

0. Перед началом

1. Строки

Первый запрос — 19 строк. LEN(SURNAME)=6 — 8 студентов: Петров, Козлова, Новиков, Сидоров, Волков, Павлов, Белкин, Крылова.

2. Даты и возраст

Ожидается 16 экзаменов в январе 2026 (все даты EXAM_MARKS в эталоне — 2026 год).

3. Числа

По каждому курсу — одна строка агрегата (курсы 1–4 в эталоне).

4. CAST

Ожидается 8 строк — по числу вузов.

5. Файл отчёта

1. Сохраните запросы §0–4 в lab13_FIO.sql.
2. В начале: -- ЛР №13, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: §1 LEN=6; §2 exams_in_jan; §4 rating_text.

Имя файла отчёта: lab13_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab13_IvanovII.sql.

Контрольные вопросы

1. Чем LEN отличается от DATALENGTH для NVARCHAR?
2. Почему DATEDIFF(YEAR,…) может «ошибаться» на день рождения?
3. Зачем ROUND при AVG стипендии?
4. Почему фильтр по YEAR(BIRTHDAY) хуже диапазона дат для индекса?
5. Зачем CAST рейтинга в NVARCHAR перед конкатенацией?

Лабораторная работа №14. CASE, ISNULL, COALESCE

Отчёт: скрипт lab14_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: условные выражения и обработка NULL в SELECT; студент STUDENT_ID=19 (Медведев) с CITY IS NULL.

0. Перед началом

Ожидается 1 строка: STUDENT_ID=19, Медведев, CITY = NULL.

1. CASE для оценок

Ожидается 24 строки — все записи ведомости.

2. Категории стипендии

Ожидается 19 строк — по каждому студенту.

3. COALESCE и ISNULL

У Медведева в обоих запросах — не указан вместо NULL.

4. IIF и сортировка NULL

Во втором запросе Медведев с NULL — в конце списка.

5. GROUP BY CASE

Ожидается 4 строки — по числу категорий стипендии.

6. Файл отчёта

1. Сохраните запросы §0–5 в lab14_FIO.sql.
2. В начале: -- ЛР №14, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: §0 NULL город; §3 COALESCE; §4 ORDER BY.

Имя файла отчёта: lab14_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab14_IvanovII.sql.

Контрольные вопросы

1. Чем простой CASE отличается от searched CASE?
2. Чем COALESCE отличается от ISNULL?
3. Зачем выводить «не указан» для NULL города?
4. Как ORDER BY CASE ставит NULL в конец?
5. Почему GROUP BY CASE повторяет выражение из SELECT?

Лабораторная работа №15. Переменные и IF

Отчёт: скрипт lab15_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: объявление переменных DECLARE/SET, ветвление IF/ELSE, проверка IF EXISTS в T-SQL.

0. Перед началом

1. Переменная курса

При @kurs = 3 ожидается 4 студента.

2. IF по средней стипендии

Результат PRINT — на вкладке Messages в SSMS.

3. IF EXISTS — студенты без оценок

Ожидается сообщение «Есть студенты без экзаменов» (Медведев, STUDENT_ID=19).

4. Файл отчёта

1. Сохраните запросы §0–3 в lab15_FIO.sql.
2. В начале: -- ЛР №15, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: §1 SELECT при @kurs=3; §2 и §3 — вкладка Messages.

Имя файла отчёта: lab15_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab15_IvanovII.sql.

Контрольные вопросы

1. Почему имя переменной начинается с @?
2. Чем IF EXISTS лучше COUNT(*) > 0?
3. Где увидеть результат PRINT в SSMS?
4. Можно ли DECLARE @kurs внутри каждого пакета GO отдельно?
5. Зачем фильтровать STIPEND>0 перед AVG?

Лабораторная работа №16. Циклы WHILE и TRY/CATCH

Отчёт: скрипт lab16_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: цикл WHILE, обработка ошибок TRY/CATCH, транзакция с откатом.

0. Перед началом

1. WHILE — числа 1..10

Ожидается 10 строк — числа от 1 до 10.

2. TRY/CATCH — неверный FK

Ожидается строка с err_num (нарушение FK) — без изменения данных.

3. CHECK на MARK

Оценка 6 вне диапазона CHECK — попадание в CATCH, строка не вставляется.

4. TRAN + TRY/CATCH

При успехе стипендии студентов 1 и 3 не меняются в сумме; при ошибке — ROLLBACK.

5. Файл отчёта

1. Сохраните запросы §0–4 в lab16_FIO.sql.
2. В начале: -- ЛР №16, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: §1 @nums; §2 и §3 — блок CATCH.

Имя файла отчёта: lab16_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab16_IvanovII.sql.

Контрольные вопросы

1. Чем табличная переменная @nums отличается от #temp?
2. Что вернёт ERROR_NUMBER() при нарушении FK?
3. Почему INSERT с MARK=6 попадает в CATCH?
4. Зачем проверять @@TRANCOUNT перед ROLLBACK?
5. Как связаны TRY/CATCH и лекция 5 про ACID?

Лабораторная работа №17. XML в SQL Server

Отчёт: скрипт lab17_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: тип XML, методы .value() и .query(); связь с лекциями 9–10.

0. Перед началом

1. Таблица с XML

2. Загрузка фрагмента ВГУ

Ожидается 1 строка в UnivXml для univ_id=10 (ВГУ).

3. value() — одно поле

Ожидается название ВГУ и город Воронеж.

4. query() — список студентов

Во втором запросе — 2 строки (Иванов, Петров из XML).

5. PRIMARY XML INDEX (обзорно)

Если права позволяют:

Иначе в отчёте опишите: индекс ускоряет XPath-запросы к большим документам.

6. Файл отчёта

1. Сохраните запросы §0–5 в lab17_FIO.sql.
2. В начале: -- ЛР №17, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: §3 value(); §4 nodes().

Имя файла отчёта: lab17_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab17_IvanovII.sql.

Контрольные вопросы

1. Чем XML-столбец отличается от NVARCHAR(MAX)?
2. Что делает .value() с XPath (/Univ/Name)[1]?
3. Зачем CROSS APPLY … nodes()?
4. Когда нужен PRIMARY XML INDEX?
5. Как XML в этой работе связан с лекцией 10?

Лабораторная работа №18. Иерархические данные

Отчёт: скрипт lab18_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: рекурсивный CTE по таблице ORG_UNIT в UniversityDB; сравнение adjacency list и nested sets.

0. Перед началом

В эталоне 10 строк в ORG_UNIT (иерархии ВГУ и МГУ).

1. Рекурсивный CTE — потомки ВГУ

От корня UNIT_ID=1 (ВГУ) ожидается 7 строк — всё поддерево вуза 10.

2. Отступ в отчёте

Столбец lvl — уровень вложенности (0 у ректората, 1 у факультетов и т.д.).

3. Теория в отчёте

Кратко сравните adjacency list (PARENT_ID, как в ORG_UNIT) и nested sets (left/right): плюсы и минусы каждой модели.

4. Файл отчёта

1. Сохраните запросы §0–2 в lab18_FIO.sql.
2. В начале: -- ЛР №18, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: §1 path/lvl; §2 tree_view.

Имя файла отчёта: lab18_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab18_IvanovII.sql.

Контрольные вопросы

1. Где в CTE задаётся якорь рекурсии?
2. Что будет, если в PARENT_ID появится цикл?
3. Зачем столбец lvl или path в результате?
4. Когда nested sets выигрывают у parent_id?
5. Как ORG_UNIT связана с иерархией подразделений вуза?

Лабораторная работа №19. MongoDB — нереляционная БД

Отчёт: скриншоты Compass + lab19_FIO.pdf (ФИО латиницей).

Цель: документная модель в MongoDB Compass; сравнение с реляционной строкой dbo.STUDENT.

Стенд: MongoDB Compass на учебном ПК (или MongoDB Atlas по указанию преподавателя). SQL Server для сравнения — UniversityDB.

0. Перед началом

1. Установите/откройте MongoDB Compass.
2. Создайте базу University и коллекцию students.
3. В SSMS выполните USE UniversityDB; — данные для документов возьмите из STUDENT + UNIVERSITY.

1. Пять документов

Вставьте минимум пять документов с полями _id, surname, name, kurs, вложенный объект university: { name, city }:

Данные можно взять из:

Ожидается 5 документов в коллекции students.

2. find, filter, projection

Зафиксируйте число документов при фильтре kurs: 3 — в эталоне SQL при KURS=3 четыре студента.

3. insert, update, delete

После deleteOne документ 99 отсутствует — приложите скриншот.

4. Отчёт PDF

1. Оформите lab19_FIO.pdf: скриншоты Compass, примеры запросов.
2. Ответьте: чем документ MongoDB отличается от строки STUDENT+JOIN UNIVERSITY.
3. Укажите, где в документе денормализация (город вуза внутри студента).

Имя файла отчёта: lab19_FIO.pdf (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab19_IvanovII.pdf.

Контрольные вопросы

1. Чем коллекция MongoDB отличается от таблицы SQL Server?
2. Зачем вложенный объект university вместо UNIVERSITY_ID?
3. Чем find с projection отличается от SELECT с списком столбцов?
4. Когда денормализация в MongoDB оправдана?
5. Какие аномалии обновления появляются при дублировании city в каждом документе?

Лабораторная работа №20. Представления VIEW

Отчёт: скрипт lab20_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: создать представления VIEW на UniversityDB, упростить доступ к JOIN и проверить чтение через представление.

Связь с лекцией 12: VIEW — сохранённый запрос с именем, а не копия таблицы.

0. Перед началом

1. VIEW студент + вуз

VIEW содержит 19 строк — по числу студентов.

2. VIEW успеваемости

Во VIEW — 24 строки; фильтр MARK=5 — 9 пятёрок в эталоне.

3. SCHEMABINDING (обзорно)

Объясните в комментарии к скрипту: WITH SCHEMABINDING защищает определение VIEW от изменения базовых столбцов.

4. Удаление VIEW

5. Файл отчёта

1. Сохраните запросы §0–4 в lab20_FIO.sql.
2. В начале: -- ЛР №20, IvanovII, группа ВО-ИСИТ-31.
3. Скриншот SELECT из v_StudentUniv и v_StudentMarks WHERE MARK=5.

Имя файла отчёта: lab20_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab20_IvanovII.sql.

Контрольные вопросы

1. Чем VIEW отличается от таблицы в Object Explorer?
2. Обновляются ли данные в VIEW при изменении STUDENT?
3. Зачем прятать JOIN за v_StudentUniv для пользователя отчётов?
4. Можно ли INSERT в простой VIEW — когда да?
5. Как VIEW связано с INSTEAD OF триггером (ЛР №22)?

Лабораторная работа №21. Хранимые процедуры

Отчёт: скрипт lab21_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: создать и вызвать хранимые процедуры на T-SQL, в том числе usp_StudentByKurs из лекции 12.

0. Перед началом

1. Процедура usp_StudentByKurs

При @kurs = 3 ожидается 4 студента.

2. Процедура со средней стипендией по вузу

3. OUTPUT-параметр (дополнительно)

4. Очистка

5. Файл отчёта

1. Сохраните запросы §0–4 в lab21_FIO.sql.
2. В начале: -- ЛР №21, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: EXEC @kurs=3; OUTPUT @result.

Имя файла отчёта: lab21_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab21_IvanovII.sql.

Контрольные вопросы

1. Чем EXEC процедуры отличается от ad-hoc SELECT?
2. Зачем SET NOCOUNT ON внутри процедуры?
3. Как передать OUTPUT-параметр при EXEC?
4. Почему логику usp_StudentByKurs удобно хранить на сервере?
5. Как GRANT EXECUTE связано с ЛР №23?

Лабораторная работа №22. Триггеры DML и INSTEAD OF

Отчёт: скрипт lab22_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: создать AFTER-триггер аудита на EXAM_MARKS и INSTEAD OF INSERT на представление v_StudentUniv.

0. Перед началом

1. Таблица аудита

2. AFTER INSERT, UPDATE, DELETE

Измените оценку в транзакции с ROLLBACK и проверьте SELECT * FROM dbo.AuditLog; — после ROLLBACK записей аудита не останется.

3. Запрет уменьшения оценки

4. INSTEAD OF INSERT на VIEW

Объясните в отчёте: VIEW с JOIN не всегда updatable — INSTEAD OF перенаправляет INSERT на базовые таблицы.

5. Очистка

6. Файл отчёта

1. Сохраните запросы §0–5 в lab22_FIO.sql.
2. В начале: -- ЛР №22, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: AuditLog; ошибка при уменьшении оценки.

Имя файла отчёта: lab22_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab22_IvanovII.sql.

Контрольные вопросы

1. Чем таблицы inserted и deleted отличаются в триггере?
2. Когда нужен AFTER, а когда INSTEAD OF?
3. Почему INSERT в v_StudentUniv без триггера может не работать?
4. Зачем ROLLBACK внутри триггера при RAISERROR?
5. Чем триггер отличается от CHECK constraint?

Лабораторная работа №23. GRANT, REVOKE, роли

Отчёт: скрипт lab23_FIO.sql (ФИО латиницей) + скриншоты результатов.

Цель: login, user, database role; выдать минимальные права на UniversityDB; связь с лекцией 14.

0. Перед началом

1. Логины и пользователи (на тестовом экземпляре)

2. Роли

3. Проверка отказа

Подключитесь вторым окном SSMS как reader_test и попробуйте:

Ожидается отказ — нет INSERT на STUDENT (только SELECT через role_read).

4. REVOKE и EXECUTE

После GRANT EXECUTE пользователь reader_test может вызвать процедуру без прямого SELECT на LECTURER.

5. Очистка

6. Файл отчёта

1. Сохраните скрипт §0–5 в lab23_FIO.sql.
2. В начале: -- ЛР №23, IvanovII, группа ВО-ИСИТ-31.
3. Скриншоты: ошибка INSERT под reader_test; успешный SELECT или EXEC.

Имя файла отчёта: lab23_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab23_IvanovII.sql.

Контрольные вопросы

1. Чем login отличается от user в базе?
2. Зачем принцип минимальных привилегий для ФИО студентов?
3. Почему reader не может INSERT в STUDENT после GRANT SELECT?
4. Зачем GRANT EXECUTE на процедуру вместо SELECT на таблицу?
5. Что произойдёт, если не DROP LOGIN после лабораторной?

Лабораторная работа №24. Восстановление данных и итоговый практикум

Отчёт: lab24_FIO.sql (ФИО латиницей) + защита.

Цель: резервное копирование и восстановление (лекции 13–14) + комплексный практикум по материалам семестра на UniversityDB.

0. Перед началом

1. Убедитесь, что UniversityDB в эталонном состоянии: 19 студентов, 24 оценки.
2. Согласуйте с преподавателем каталог для файлов .bak на учебном сервере.

Часть A. Резервное копирование и восстановление

A.1. Полная копия

A.2. Изменение данных

A.3. Восстановление на копию базы

Если нет прав — приложите скриншоты SSMS и текстовый план RESTORE.

A.4. Теория в отчёте

Опишите цепочку FULL / DIFF / LOG backup и когда нужен STOPAT.

Часть B. Итоговый практикум (8 из 10)

Выполните минимум восемь пунктов ниже; каждый — отдельный блок в lab24_FIO.sql с комментарием.

1. JOIN трёх таблиц + фильтр по городу или курсу.
2. GROUP BY + HAVING (средний балл по предметам).
3. Подзапрос или EXISTS (студенты без оценок — ожидается Медведев).
4. CREATE VIEW + SELECT из VIEW.
5. Процедура usp_StudentByKurs с @kurs=3 — 4 строки.
6. AFTER-триггер аудита (с DROP TRIGGER в конце скрипта).
7. План запроса: Index Seek vs Scan для фильтра по CITY.
8. Демонстрация GRANT/REVOKE или описание, если нет прав.
9. Рекурсивный CTE по ORG_UNIT от UNIT_ID=1 — 7 строк.
10. Фрагмент XML в dbo.UnivXml (если таблица ещё есть с ЛР №17).

Файл отчёта

1. Сохраните части A и B в lab24_FIO.sql.
2. В начале: -- ЛР №24, IvanovII, группа ВО-ИСИТ-31.
3. Подготовьтесь к защите на занятии.

Имя файла отчёта: lab24_FIO.sql (ФИО латиницей) — вместо FIO подставьте фамилию и инициалы латиницей, например lab24_IvanovII.sql.

Контрольные вопросы

1. Чем BACKUP DATABASE отличается от RESTORE DATABASE?
2. Зачем восстанавливать на UniversityDB_restore, а не поверх боевой базы?
3. Какие три темы SQL вы считаете сильными после семестра?
4. Что проверяет экзамен по дисциплине?
5. Как связаны лабораторные №1–24 с лекциями курса?