Сценарий занятия: Основной регламент (80 минут)
Этап 1. Организационный момент и мотивационная проблема (7 минут)
Преподаватель приветствует обучающихся, отмечает присутствующих в журнале, проверяет запуск рабочих станций и проецирует слайд 1 презентации.
«Здравствуйте, коллеги! Сегодня мы переходим от теоретического моделирования "на салфетках" к настоящей инженерной практике. Тема нашего первого практического занятия — "Ключи, объекты и проект БД, таблицы". До сих пор вы рисовали концептуальные сущности и атрибуты. Сегодня мы превращаем их в реальные реляционные структуры, которые понимает ядро СУБД.
Представьте реальный кейс из коммерческой разработки: интернет-магазин автозапчастей. Пользователь решил удалить свой профиль и нажал кнопку "Удалить аккаунт". Если разработчик схемы БД по неопытности повесил на внешний ключ правило ON DELETE CASCADE, что произойдет с базой данных? Кто готов ответить?»
«Вместе с пользователем сотрутся все его заказы, накладные и платежи! А бухгалтерская отчетность сломается, потому что в налоговой отчетности пропадут строки реализации за прошлые периоды.»
«Именно так! Вы физически уничтожите историю финансово-хозяйственной деятельности предприятия, за что компанию оштрафуют, а разработчика уволят. Целостность данных — это фундаментальная линия обороны программной системы. Сегодня мы научимся проектировать таблицы так, чтобы физический уровень СУБД делал невозможным случайное уничтожение информации или запись невалидных данных.
Оценивание сегодня проводится по закрытой 4-балльной шкале: структура таблиц и типы данных — до 2 баллов, ключи и ссылочная целостность — 1 балл, предикаты CHECK и самопроверка — 1 балл. Итого максимум 4 балла, что соответствует отличной оценке. Приступаем!»
Этап 2. Вводный инструктаж и разбор эталонной DDL-архитектуры (23 минуты)
Преподаватель переключает слайды презентации (слайды 2–13), разбирает типы данных, анатомию первичных ключей и ограничения целостности у маркерной доски.
«Обратите внимание на слайд 4 и 5: "Первичный ключ: Естественный vs Суррогатный". Почему профессиональные архитекторы не используют паспорт, VIN-код или номер телефона в качестве Primary Key, даже если они уникальны в реальном мире?
Во-первых, естественные данные имеют свойство меняться. Человек меняет паспорт в 20 и 45 лет, автомобиль получает новый госномер при перерегистрации, телефон блокируется и продается другому абоненту. Если первичный ключ изменился, вам придется каскадно обновлять миллионы строк во всех дочерних таблицах!
Во-вторых, производительность. Строковый VIN — это 17 символов. 4-байтовый INTEGER занимает 4 байта. B-Tree индексы на целочисленных полях работают в разы быстрее, а соединения JOIN выполняются на уровне одной процессорной машинной инструкции.
Но запомните железное правило: если вы ввели суррогатный id_avto INT PRIMARY KEY, вы обязаны повесить на поле vin ограничение UNIQUE NOT NULL! Иначе СУБД с радостью зарегистрирует один и тот же автомобиль пять раз с разными ID.
Второй критический узел — деньги. Посмотрите на слайд 7. Забудьте про тип FLOAT и DOUBLE для цен, балансов и тарифов. Ошибка IEEE 754 дает 0.1 + 0.2 = 0.30000000000000004. В бухгалтерии за такую "копейку" вас вызовет служба безопасности. Только точный NUMERIC(10,2) или DECIMAL!
А теперь посмотрим на ограничения CHECK. Это ваши бизнес-правила, записанные на языке математической логики прямо в таблице. Например, дата выезда из отеля обязана быть строго больше даты заезда: CHECK (data_vyezda > data_zaezda). Если приложение попытается заселить человека назад во времени, СУБД прервет транзакцию с ошибкой Check Violation.»
«А как правильно настроить внешний ключ для архива документов? Что писать в ON DELETE?»
«В 90% учетных задач мы пишем ON DELETE RESTRICT (или NO ACTION). Это означает: "СУБД, запрети удаление клиента, автомобиля или категории номеров, если на них ссылается хотя бы один документ в архиве!". А чтобы скрыть объект из пользовательского интерфейса, мы добавляем булево поле is_aktivnyy BOOLEAN NOT NULL DEFAULT TRUE и делаем логическое удаление (Soft Delete).»
Этап 3. Самостоятельная работа в интерактивном листе (35 минут)
Преподаватель просит студентов открыть файл zanyatie.html на компьютерах, ввести ФИО и группу, выбрать вариант согласно распределению и приступить к проектированию.
«Открываем файл zanyatie.html. Перед вами 4 предметных варианта:
- Вариант 1: Автопарк логистической компании (Автомобили, Водители, Путевые листы).
- Вариант 2: Гостиничный комплекс (Номера, Гости, Бронирования).
- Вариант 3: Электронная библиотека (Книги, Экземпляры, Читатели, Выдачи).
- Вариант 4: Сервисный центр (Клиенты, Заказы, Мастера, Комплектующие).
Ваша задача: для каждой таблицы указать перечень атрибутов с точными физическими типами данных, обосновать выбор первичных ключей, настроить внешние ключи с каскадными опциями и написать строгие ограничения CHECK. Обратите внимание: все ваши ответы автоматически сохраняются в localStorage браузера, так что случайное закрытие вкладки не уничтожит результат. На самостоятельное проектирование — 35 минут. Я буду подходить и консультировать индивидуально.»
Преподаватель осуществляет непрерывный обход аудитории, контролирует ход проектирования, указывает студентам на смысловые нестыковки в предикатах CHECK и размерностях полей.
Этап 4. Экспертный разбор типичных коллизий (10 минут)
Преподаватель привлекает внимание аудитории к экрану проектора, демонстрирует мем на слайде 15 и разбирает 3 характерные ошибки.
«Коллеги, внимание на экран! Слайд 15: культовый веб-комикс Рэндалла Манро xkcd про "Little Bobby Tables". Мама назвала сына именем: Robert'); DROP TABLE Students;--. Когда школьная база попыталась внести ученика без должной валидации и параметризации, строковая вставка уничтожила таблицу школьников.
А теперь посмотрим на типичные ошибки, которые я заметил в ваших бланках во время обхода:
1. В Варианте 3 (Библиотека) некоторые указали ISBN в качестве первичного ключа таблицы выдачи книг. Но ведь если у нас в библиотеке 10 одинаковых книг "Война и мир", у них один и тот же ISBN! Какую именно книгу взял читатель? Для этого существует таблица "Экземпляры" с уникальным инвентарным номером тома.
2. В Варианте 1 (Автопарк) в условии CHECK на топливо забыли про заправку. Если в путевом листе указан расход топлива, то остаток при возвращении не может быть больше, чем было при выезде плюс заправлено в рейсе: CHECK (toplivo_pri_vyezde + toplivo_zapravleno >= toplivo_pri_vozvrashchenii).
3. Не забывайте указывать NOT NULL на полях внешних ключей обязательных связей. Путевой лист не может существовать без машины, а бронирование — без номера отеля!»
Этап 5. Подведение итогов, рефлексия, домашнее задание (5 минут)
Преподаватель подводит итоги выполнения работы, выставляет баллы в журнал и дает разъяснения по резервному заданию.
«Подведем итоги занятия. Сегодня каждый из вас спроектировал целостную физическую схему реляционных таблиц. Вы научились отличать суррогатные ключи от естественных, защищать базу от финансовых ошибок округления и настраивать каскадные политики.
Нажмите кнопку "Сохранить и подготовить к печати" в нижней панели рабочего листа. Сохраните PDF или распечатайте бланк для отчетности.
Что касается домашнего задания: в комплекте материалов есть файл domashnee_zadanie.html. Обратите внимание на плашку: это резервное дистанционное задание. Вы выполняете его только в том случае, если вам назначена индивидуальная отработка или дистанционный формат. Срок сдачи — до начала следующей пары.
Спасибо за отличную инженерную работу! Занятие окончено.»
Сценарий занятия: Сокращенный регламент (60 минут)
Этап 1. Организационный момент (5 минут)
«Здравствуйте! Сегодня работаем в сжатом 60-минутном тайминге. Тема — Практическое занятие №1: ключи, объекты и проект БД, таблицы. Наша цель — спроектировать надежную структуру таблиц с первичными и внешними ключами и ограничениями CHECK. Помните: правильная схема БД предотвращает 90% логических ошибок еще до написания программного кода. Шкала оценивания — 4 балла.»
Этап 2. Вводный экспресс-инструктаж (15 минут)
«Кратко фиксируем ключевые правила:
1. Первичный ключ — суррогатный INT или BIGINT (GENERATED ALWAYS AS IDENTITY). На естественные документы (VIN, паспорт, ISBN) обязательно вешаем UNIQUE NOT NULL.
2. Деньги и цены — только NUMERIC(10,2), никакого FLOAT.
3. Даты — DATE и TIMESTAMP, никаких текстовых VARCHAR.
4. Внешние ключи — строго того же типа, что и родительский PK. В секции удаления используем ON DELETE RESTRICT для защиты архивов.
5. Бизнес-правила валидируем через предикаты CHECK. Смотрим на слайд 13 с образцом DDL.»
Этап 3. Практическая работа обучающихся (28 минут)
«Открываем zanyatie.html, вводим данные и выбираем свой вариант. Время на индивидуальное проектирование таблиц — 28 минут. Фокусируйтесь на типах полей, ссылочной целостности и не забудьте заполнить чек-лист самопроверки.»
Этап 4. Экспресс-разбор и демонстрация мема (8 минут)
«Остановитесь на минуту и посмотрите на экран (слайд 15). Веб-комикс xkcd напоминает нам, что бывает, когда в базе данных нет ограничений целостности и проверок типов — одна запись стирает всю таблицу учеников. Проверьте в своих работах: не забыли ли вы UNIQUE на альтернативных ключах и не поставили ли CASCADE на таблицы клиентов и автомобилей!»
Этап 5. Фиксация результатов и итог (4 минуты)
«Сохраняем данные в zanyatie.html. Результаты практической работы зафиксированы. Резервное домашнее задание в файле domashnee_zadanie.html выполняют только те, кто пропустил пару или направлен на отработку. Всем спасибо за работу, занятие завершено!»