Методическое руководство для преподавателя

Дисциплина: ОП.08 Основы проектирования баз данных
Тема рабочей программы (§2.2 с.7): Тема 1. Основные понятия баз данных — Практическое занятие №1: ключи, объекты и проект БД, таблицы
Вид занятия: Практическое занятие (2 академических часа)

1. Цели занятия и дидактический фокус

Основная дидактическая цель первого практического занятия дисциплины — перевести теоретические представления студентов об ER-моделировании (сущности, атрибуты, связи) в практическую плоскость проектирования физической структуры реляционных таблиц с применением механизмов реляционной целостности.

Ключевой профессиональный навык: Обучающийся должен уметь обоснованно выбирать первичные ключи (естественные vs суррогатные), назначать типы данных с учетом диапазона значений и производительности индексов, проектировать внешние ключи с правильной каскадной политикой и реализовывать декларативные ограничения бизнес-правил (NOT NULL, UNIQUE, CHECK, DEFAULT).

Особое внимание уделяется предотвращению типовых заблуждений начинающих разработчиков: использованию избыточных строковых типов для дат и денег, слепому навешиванию ON DELETE CASCADE и пренебрежению альтернативными уникальными ключами при использовании суррогатных идентификаторов.

2. Детальный хронометраж учебного занятия

Этап занятия Основной регламент (80 мин) Сокращенный регламент (60 мин) Содержание педагогической деятельности
1. Организационный момент и постановка задачи 7 минут 5 минут Приветствие, проверка готовности рабочих мест. Демонстрация проблемы: «Что будет, если в таблице заказов удалить клиента, не проверив внешние ключи?». Формулирование цели занятия и критериев оценивания (4 балла).
2. Вводный инструктаж и разбор архитектурного эталона 23 минуты 15 минут Фронтальный разбор физического проектирования: анатомия оператора CREATE TABLE, специфика типов данных (INTEGER vs BIGINT, NUMERIC vs FLOAT, TIMESTAMP), первичные ключи (SERIAL, IDENTITY, UUID), ограничения ссылочной целостности и каскадные опции.
3. Практическая работа: проектирование по вариантам 35 минут 28 минут Индивидуальная самостоятельная работа студентов в интерактивном листе (zanyatie.html). Проектирование реляционных таблиц, выбор типов, спецификация ключей и условий CHECK для одной из 4 предметных областей.
4. Экспертная экспресс-проверка и разбор коллизий 10 минут 8 минут Разбор типичных ошибок у доски: конфликт каскадного удаления в финансовых журналах, некорректная валидация временных интервалов в CHECK, отсутствие UNIQUE на естественных идентификаторах.
5. Подведение итогов, рефлексия, фиксация результатов 5 минут 4 минут Оценка выполнения практических заданий по критериальной рубрике. Подведение итогов усвоения материала, разъяснение резервного домашнего задания.

3. Фундаментальные аспекты проектирования таблиц

3.1. Первичные ключи (Primary Key): Естественные vs Суррогатные

Первичный ключ отношения должен удовлетворять трем фундаментальным реляционным аксиомам: уникальность (отсутствие дубликатов), непустота (не допускает NULL) и неизменяемость (значение ключа не должно меняться на протяжении всего жизненного цикла кортежа).

Тип ключа Характеристика и примеры Преимущества Недостатки и риски
Естественный ключ (Natural Key) Формируется из реальных реквизитов объекта: ИНН, СНИЛС, VIN-код ТС, номер паспорта, ISBN книги. Не требует создания искусственных колонок; бизнес-данные сразу видны без объединения (JOIN). Бизнес-правила меняются: форматы документов могут измениться; строковые ключи медленнее индексируются и расходуют больше дискового пространства во внешних ключах.
Суррогатный целочисленный (SERIAL / IDENTITY) Искусственное поле целочисленного типа (INT 4 байта, BIGINT 8 байт), генерируемое СУБД автоматически через последовательность (SEQUENCE). Максимальная скорость соединений таблиц; фиксированный компактный размер в B-Tree индексах; абсолютная неизменяемость. Требует обязательного создания вторичного ограничения UNIQUE на естественные атрибуты (иначе возникнут полные дубликаты записей).
Суррогатный UUID (UUIDv4 / UUIDv7) 128-битный глобально уникальный идентификатор (16 байт), генерируемый алгоритмически без централизованной последовательности. Позволяет безопасно генерировать ID на клиентах до записи в БД; идеален для распределенных и микросервисных систем. UUIDv4 фрагментирует B-Tree индексы из-за случайного распределения; размер 16 байт против 4/8 байт у целых чисел.
Методическое правило СИЭУиП: Если в таблице используется суррогатный первичный ключ (например, id_avto INT PRIMARY KEY), естественные бизнес-идентификаторы объекта (номер кузова, госномер, email, номер паспорта) ОБЯЗАНЫ иметь ограничение UNIQUE NOT NULL. В противном случае СУБД допустит регистрацию двух идентичных реальных объектов с разными искусственными ID.

3.2. Стратегия выбора типов данных

3.3. Ограничения целостности (Integrity Constraints)

Ограничения целостности гарантируют, что в базу данных физически невозможно записать логически некорректные или мусорные данные:

  1. NOT NULL — запрещает отсутствие значения. Должно устанавливаться на все обязательные атрибуты сущности.
  2. UNIQUE — гарантирует уникальность значений в пределах колонки или кортежа колонок (альтернативные ключи).
  3. DEFAULT — автоматическое заполнение значения по умолчанию при вставке (например, CURRENT_TIMESTAMP или TRUE).
  4. CHECK (условие) — предикатное ограничение, валидирующее значение по логическому выражению на уровне строки. Примеры:
    CHECK (data_vyezda > data_zaezda)
    CHECK (kolichestvo_na_sklade >= 0)
    CHECK (status_zakaza IN ('принят', 'в_работе', 'готов', 'выдан'))
    CHECK (cena_prodazhi >= cena_zakupki)

3.4. Внешние ключи (Foreign Key) и ссылочная целостность

Внешний ключ связывает дочернюю таблицу с родительской, гарантируя, что значение поля дочерней таблицы существует в первичном ключе родительской. Поведение при модификации или удалении родительской записи регламентируется секцией ON DELETE / ON UPDATE:

Каскадное правило Механизм действия Область применения и ограничения
ON DELETE RESTRICT / NO ACTION Блокирует удаление родительской строки при наличии хотя бы одной связанной записи в дочерней таблице (вызывает ошибку FK violation). Правило по умолчанию в промышленной разработке! Обязательно для финансовых документов, договоров, путевых листов, каталогов номенклатуры. Предотвращает случайную потерю данных.
ON DELETE CASCADE Автоматически физически удаляет все дочерние записи вслед за удалением родительской строки. Допустимо строго для жестко подчиненных композиционных сущностей: строки чека в накладной, спецификация запчастей в квитанции ремонта. Опасно при ветвистых связях.
ON DELETE SET NULL При удалении родительской строки внешнему ключу в дочерней таблице присваивается значение NULL (требует отсутствия NOT NULL). Используется для факультативных ассоциаций. Например: при удалении учетной записи мастера-приемщика заказ на ремонт сохраняется, а поле мастера зануляется.
ON UPDATE CASCADE При изменении значения первичного ключа в родительской таблице новое значение автоматически каскадируется во все дочерние записи. Рекомендуется включать для всех внешних ключей, чтобы гарантировать синхронизацию при технологических переносах данных.

4. Педагогические приемы и разбор типичных ошибок

Прием 1: «Провокационный вопрос о деструктивном каскаде»

Для объяснения опасности ON DELETE CASCADE преподаватель моделирует ситуацию: «Представьте, что менеджер автосалона решил удалить из справочника неактивную модель автомобиля. Если на связи стоит CASCADE, что произойдет? Удалятся все 200 машин автопарка, все путевые листы водителей и бухгалтерия за 5 лет! Поэтому для критичных данных мы используем RESTRICT и логическое удаление (Soft Delete через флаг is_aktivnyy)».

Прием 2: «Разбор коварства IEEE 754»

Преподаватель запускает в консоли или демонстрирует на слайде сложение в типах с плавающей запятой: 0.1 + 0.2 = 0.30000000000000004. После чего задает вопрос: «Что скажет аудитор или налоговая, если на балансе компании из-за ошибки float потеряются или возникнут лишние копейки?». Это навсегда закрепляет применение типа NUMERIC(10,2) для финансов.

Прием 3: «Логика временной стрелы в CHECK»

При проверке условий дат студенты часто пишут CHECK (data_vyezda > data_zaezda), забывая о возможности нулевых значений (NULL) для незавершенных процессов. Преподаватель обращает внимание на предикаты с IS NULL OR ..., объясняя трехзначную логику реляционных баз данных (TRUE, FALSE, UNKNOWN).

5. Критерии оценивания практической работы (4 балла)