Сценарий занятия — Основной регламент (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: БД «Отдел кадров предприятия» (Сотрудники, Должности, Подразделения, Приказы о назначении).
- Вариант 2: БД «Аптечный склад» (Медикаменты, Производители, Партии, Расходные накладные).
- Вариант 3: БД «Учебный центр доп. образования» (Слушатели, Курсы, Группы, Платежи).
- Вариант 4: БД «Станция техобслуживания (СТО)» (Клиенты, Автомобили, Заказ-наряды, Выполненные работы).
Прямая речь преподавателя:
«Внимание по аудитории. Приступаем к индивидуальной практической работе.
В шапке рабочего листа обязательно введите ваши реальные ФИО и учебную группу — форма сохраняет все локально, но при печати эти поля пойдут в отчет.
Ваша задача в рамках варианта:
1. Спроектировать спецификацию отношений (не менее 3–4 таблиц) с полным обоснованием устранения транзитивных зависимостей.
2. Написать чистый DDL-скрипт создания таблиц с первичными и внешними ключами, ограничениями UNIQUE, NOT NULL, CHECK и политиками ссылочной целостности.
3. Написать блок тестовых данных: минимум 5 согласованных строк INSERT INTO.
4. Ответить на 3 контрольных вопроса самопроверки.
Я нахожусь в аудитории и провожу индивидуальные консультации. Если сомневаетесь в выборе между RESTRICT и CASCADE — поднимайте руку, разберем архитектурные риски».
Во время работы преподаватель обходит рабочие места, контролируя типичные затруднения:
- Студент Варианта 2: пытается поместить страну производителя прямо в таблицу медикаментов. Преподаватель указывает:
med_id → manufacturer_id → country — это транзитивная зависимость, выносим производителей в отдельную таблицу!
- Студент Варианта 4: написал тип
mileage VARCHAR(20). Преподаватель объясняет, что пробег — это физическая неотрицательная величина: тип строго INT с предикатом CHECK (mileage >= 0).
Этап 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 балл за тесты и самопроверку. Домашнее резервное задание выполняется только по индивидуальному назначению. Всем спасибо, занятие окончено!»