Развернутый педагогический сценарий учебного занятия

ОП.08 Основы проектирования баз данных — Занятие 12: Практическое занятие №4: проектирование реляционной БД

Вводные методические указания

Сценарий представляет собой подробную режиссуру практического занятия с прямой речью преподавателя, реакциями студентов, методическими комментариями и акцентами. Материал структурирован для двух регламентов: основного (80 минут) и сокращенного (60 минут).

Педагогическая сверхзадача занятия: преодолеть поверхностное восприятие реляционных таблиц как «просто листов Excel» и сформировать у обучающихся строгую культуру проектирования с точки зрения математической целостности, защиты данных на уровне ядра СУБД и предотвращения разрушительных аномалий модификации.

Сценарий занятия — Основной регламент (80 минут)

Этап 1. Организационный и мотивационный момент (00:00–00:05, 5 мин)

Преподаватель входит в аудиторию, организует внимание студентов, фиксирует присутствующих в журнале, проверяет готовность автоматизированных рабочих мест. На интерактивной доске/экране открыт слайд 1 презентации.

Прямая речь преподавателя:
«Здравствуйте, коллеги! Садитесь. Прошу включить мониторы, открыть наш интерактивный рабочий лист zanyatie.html и подготовиться к интенсивной инженерной работе. Сегодня у нас ключевое занятие второго модуля — Практическое занятие №4: проектирование реляционной базы данных.

Представьте типичную производственную ситуацию. На крупном заводе трудится 800 специалистов. Архитектор базы данных решил сэкономить время и спроектировал одну общую таблицу: табельный номер, ФИО, название должности, подразделение и установленный оклад. Все лежит в одной строке. Руководство издает приказ: проиндексировать оклад ведущего инженера с 75 000 до 85 000 рублей.

Что происходит дальше в такой системе, если на 350-й строке моргнет сетевой свитч или перезагрузится сервер? Кто готов ответить?»
Ответ студента (проблемная гипотеза):
«Произойдет аномалия обновления: у первых трехсот человек оклад станет 85 тысяч, а у остальных останется 75 тысяч. В одной и той же должности на одном заводе люди будут получать разные деньги, а бухгалтерия не сможет свести баланс».
Прямая речь преподавателя:
«Абсолютно верно! Это классическая аномалия обновления (Update Anomaly), вызванная нарушением Третьей нормальной формы. Сегодня наша цель — научиться строго выявлять подобные зависимости, декомпозировать отношения до 3NF и BCNF, транслировать их в чистый ANSI SQL DDL с непробиваемыми ограничениями целостности и верифицировать результат тестовыми данными».
Этап 2. Теоретический экспресс-инструктаж (00:05–00:20, 15 мин)

Преподаватель переключает слайды презентации (слайды 2–9), последовательно разбирая математический аппарат нормализации и правила синтаксиса DDL.

Прямая речь преподавателя:
«Давайте освежим математику. Что такое Третья нормальная форма? Отношение находится в 3NF, если оно во 2NF и в нем нет транзитивных зависимостей неключевых полей от первичного ключа.

Вспомним классическую формулу Кодда: X → Y → Z. Здесь X — первичный ключ (табельный номер), Y — промежуточный неключевой атрибут (должность), а Z — оклад. Оклад на самом деле зависит не от конкретного Иванова или Петровой, а от их служебной позиции! Присутствие Z в таблице сотрудников является паразитным.

Обратите внимание на формулировку теоремы Заньоло: функциональная зависимость X → A допустима в 3NF, если либо X является суперключом, либо A является первичным атрибутом (то есть частью какого-либо составного ключа).

А теперь вопрос на опережение: кто помнит, чем отличается форма Бойса-Кодда (BCNF) от 3NF? В чем ее строгость?»
Ответ студента:
«В BCNF исключено второе послабление: детерминант X обязан быть суперключом всегда, без всяких исключений для первичных атрибутов».
Прямая речь преподавателя:
«Именно так! В BCNF каждый детерминант обязан быть суперключом. Нарушение BCNF при сохранении 3NF возможно только тогда, когда в таблице есть перекрывающиеся составные ключи — как в нашем примере со студентами, предметами и преподавателями со слайда 8.

Теперь перейдем к физическому уровню. База данных в СУБД строится через язык DDL (Data Definition Language). Здесь действует железное правило топологической сортировки:
1. Сначала мы обязаны создать независимые справочники: например, таблицу подразделений departments и должностей positions.
2. Затем — операционную таблицу сотрудников employees, внешний ключ которой ссылается на справочники.
3. И только потом — таблицу приказов о назначениях appointment_orders.

Если вы попытаетесь объявить FOREIGN KEY на таблицу, которая еще не создана строчкой выше, ядро PostgreSQL или SQLite вернет фатальную ошибку компиляции: relation does not exist. Запомните это: зависимости определяют порядок!»
Этап 3. Демонстрация сквозного эталонного кейса (00:20–00:30, 10 мин)

Преподаватель открывает терминал/веб-консоль и в режиме реального времени демонстрирует нормализацию и написание DDL-скрипта.

Прямая речь преподавателя:
«Посмотрите на экран. Вот исходная плоская таблица, нарушающая 3NF:
-- Плохая таблица с транзитивной зависимостью:
-- emp_id -> pos_id -> base_salary
CREATE TABLE bad_employees (
    emp_id INT PRIMARY KEY,
    full_name VARCHAR(150) NOT NULL,
    pos_title VARCHAR(100) NOT NULL,
    base_salary NUMERIC(10,2) NOT NULL
);
Выполняем декомпозицию без потерь. По теореме Хита мы выносим зависимость pos_id → base_salary в новую сущность positions:
CREATE TABLE positions (
    pos_id INT PRIMARY KEY,
    title VARCHAR(100) NOT NULL UNIQUE,
    base_salary NUMERIC(10,2) NOT NULL CHECK (base_salary >= 19242.00)
);

CREATE TABLE employees (
    emp_id INT PRIMARY KEY,
    full_name VARCHAR(150) NOT NULL,
    pos_id INT NOT NULL REFERENCES positions(pos_id) ON DELETE RESTRICT
);
Взгляните на правило ON DELETE RESTRICT. Почему мы использовали именно его, а не CASCADE? Потому что, если директор решит убрать из штатного расписания должность инженера, СУБД обязана заблокировать удаление, пока на этой должности числятся живые люди! Иначе каскад молча сотрет данные сотрудников.

А теперь проверим защиту. Вставляем тестовую запись:
INSERT INTO positions VALUES (1, 'Системный администратор', 65000.00);
INSERT INTO employees VALUES (101, 'Петров Василий Сергеевич', 1);
Все работает. А теперь попробуем нарушить ограничение CHECK и ввести оклад 5 000 рублей:
INSERT INTO positions VALUES (2, 'Младший техник', 5000.00);
Смотрите: ядро базы данных возвращает ошибку: violates check constraint. Транзакция откатана. Никакие некорректные данные в память не попали. Именно такого качества реализации я жду сегодня от каждого из вас».
Этап 4. Самостоятельная практическая работа студентов (00:30–01:05, 35 мин)

Студенты открывают интерактивный рабочий лист zanyatie.html. Преподаватель распределяет варианты или студенты выбирают вариант согласно номеру в журнале:

Прямая речь преподавателя:
«Внимание по аудитории. Приступаем к индивидуальной практической работе. В шапке рабочего листа обязательно введите ваши реальные ФИО и учебную группу — форма сохраняет все локально, но при печати эти поля пойдут в отчет.

Ваша задача в рамках варианта: 1. Спроектировать спецификацию отношений (не менее 3–4 таблиц) с полным обоснованием устранения транзитивных зависимостей. 2. Написать чистый DDL-скрипт создания таблиц с первичными и внешними ключами, ограничениями UNIQUE, NOT NULL, CHECK и политиками ссылочной целостности. 3. Написать блок тестовых данных: минимум 5 согласованных строк INSERT INTO. 4. Ответить на 3 контрольных вопроса самопроверки.

Я нахожусь в аудитории и провожу индивидуальные консультации. Если сомневаетесь в выборе между RESTRICT и CASCADE — поднимайте руку, разберем архитектурные риски».

Во время работы преподаватель обходит рабочие места, контролируя типичные затруднения:

Этап 5. Экспертная верификация и разбор типовых ошибок (01:05–01:15, 10 мин)

Преподаватель привлекает внимание группы к общему экрану и выводит слайд 14 и слайд 15 презентации.

Прямая речь преподавателя:
«Коллеги, время практической части подходит к концу, переключите внимание на проектор. В ходе проверки ваших экранов я зафиксировал три характерные неточности:

Первая ошибка: Забытое ограничение UNIQUE на естественный идентификатор. Студент Варианта 4 создал суррогатный ключ vehicle_id SERIAL PRIMARY KEY, но забыл наложить UNIQUE на поле vin. В результате в такую базу можно 10 раз внести одну и ту же машину с одинаковым VIN-номером! Суррогатный ключ защищает строку, но бизнес-сущность защищает именно UNIQUE.

Вторая ошибка: «Слепой CASCADE». Несколько человек указали каскадное удаление на справочнике клиентов. Помните: удалили клиента — и база молча уничтожила все заказ-наряды за 5 лет.

И наконец, посмотрите на слайд 15. Это знаменитый комикс Рэндалла Манро про «Little Bobby Tables» (Роберта Таблицу). Мама назвала сына Robert'); DROP TABLE Students;--. Когда школа выполнила невалидированный запрос на вставку, база данных стерла таблицу всех учеников. Это вечное напоминание инженеру: строгие типы данных, ограничения целостности и нормализация — это фундамент информационной безопасности!»
Этап 6. Подведение итогов, рефлексия, выдача ДЗ (01:15–01:20, 5 мин)
Прямая речь преподавателя:
«Подведем итоги занятия. Сегодня каждый из вас прошел полный инженерный цикл: от сырых требований предметной области до математически выверенной физической схемы реляционной базы данных.

Нажмите кнопку «Сохранить данные» в вашем рабочем листе. Все введенные структуры зафиксированы в локальном хранилище. Затем нажмите «Версия для печати / PDF» и сформируйте файл отчета для проверки.

Оценивание проводится по нашей закрытой критериальной рубрике (максимум 4 балла: 2 балла за 3NF нормализацию, 1 балл за DDL и ключи, 1 балл за тестовые данные и самопроверку).

Для тех, кто пропустил пару или нуждается в дополнительной отработке по индивидуальному назначению, подготовлен файл резервного задания domashnee_zadanie.html. Срок сдачи — до следующей пары.

Спасибо за отличную инженерную работу! Занятие окончено».

Сценарий занятия — Сокращенный регламент (60 минут)

В условиях 60-минутного регламента акцент смещается на максимальную концентрацию практической работы студентов. Теоретический блок редуцируется до опорных тезисов, а демонстрация эталона интегрируется непосредственно в инструктаж.

Этап 1. Оргмомент и постановка проблемы (00:00–00:03, 3 мин)
Прямая речь преподавателя:
«Здравствуйте, коллеги! Время сжато, поэтому сразу включаемся в работу. Открываем рабочий лист zanyatie.html. Тема — проектирование реляционной БД в Третьей нормальной форме. Наша задача сегодня: устранить транзитивные зависимости $X \to Y \to Z$ и написать чистый DDL-скрипт с ограничениями целостности. Работать будем по 4 отраслевым вариантам».
Этап 2. Компактный инструктаж по 3NF и DDL (00:03–00:15, 12 мин)
Прямая речь преподавателя:
«Внимание на экран (слайды 4, 6 и 9). Главный принцип 3NF: неключевые поля не должны зависеть друг от друга. Если в сотрудниках оклад зависит от должности — мы немедленно выносим должность и оклад в таблицу-справочник positions.

Порядок действий в коде DDL: 1. Сначала пишем CREATE TABLE для родительских справочников. 2. Затем создаем зависимые таблицы, объявляя FOREIGN KEY ... REFERENCES ... ON DELETE RESTRICT. 3. Обязательно защищаем диапазоны через CHECK (цены, оклады, пробег $> 0$). 4. Вставляем 5 строк через INSERT INTO строго в топологическом порядке. Приступаем к работе в рабочих листах!»
Этап 3. Самостоятельная практическая работа (00:15–00:47, 32 мин)
Прямая речь преподавателя:
«Работаем индивидуально по вариантам. Вариант 1 — Кадры, Вариант 2 — Аптека, Вариант 3 — Учебный центр, Вариант 4 — СТО. Контролируйте типы данных: для денег используем строго NUMERIC, не FLOAT. Не забывайте про UNIQUE для паспортных данных и VIN-кодов».
Этап 4. Экспресс-разбор ошибок (00:47–00:55, 8 мин)
Прямая речь преподавателя:
«Остановитесь на минуту и посмотрите на экран (слайд 15 с комиксом Bobby Tables). Запомните: если вы пренебрегли типами данных и ограничениями целостности, база беззащитна перед некорректным вводом и инъекциями. Проверьте в своих скриптах: все ли внешние ключи ссылаются на реальные таблицы и нет ли у вас каскадного удаления на справочниках».
Этап 5. Фиксация результатов и завершение (00:55–01:00, 5 мин)
Прямая речь преподавателя:
«Нажимаем «Сохранить данные» и отправляем сформированные отчеты на проверку. Критерии рубрики: 2 балла за 3NF декомпозицию, 1 балл за DDL, 1 балл за тесты и самопроверку. Домашнее резервное задание выполняется только по индивидуальному назначению. Всем спасибо, занятие окончено!»