Дисциплина: ОП.08 Основы проектирования баз данных
Тема рабочей программы (§2.2 с.7): Тема 1. Основные понятия баз данных — Практическое занятие №1: ключи, объекты и проект БД, таблицы
Вид занятия: Практическое занятие (2 академических часа)
Основная дидактическая цель первого практического занятия дисциплины — перевести теоретические представления студентов об ER-моделировании (сущности, атрибуты, связи) в практическую плоскость проектирования физической структуры реляционных таблиц с применением механизмов реляционной целостности.
NOT NULL, UNIQUE, CHECK, DEFAULT).
Особое внимание уделяется предотвращению типовых заблуждений начинающих разработчиков: использованию избыточных строковых типов для дат и денег, слепому навешиванию ON DELETE CASCADE и пренебрежению альтернативными уникальными ключами при использовании суррогатных идентификаторов.
| Этап занятия | Основной регламент (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 минут | Оценка выполнения практических заданий по критериальной рубрике. Подведение итогов усвоения материала, разъяснение резервного домашнего задания. |
Первичный ключ отношения должен удовлетворять трем фундаментальным реляционным аксиомам: уникальность (отсутствие дубликатов), непустота (не допускает 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.
SMALLINT, INTEGER, BIGINT): используются для счетчиков, внешних ключей, натуральных величин. Выбор зависит от прогнозируемого объема: SMALLINT (до 32 тыс. — этажи, категории), INT (до 2,14 млрд — сущности-справочники), BIGINT (до $9 \times 10^{18}$ — транзакционные журналы, чеки, путевые листы).VARCHAR(n), CHAR(n), TEXT): CHAR(n) применяется строго для строк фиксированной длины (например, VIN-код автомобиля ровно 17 символов или код валюты ISO ровно 3 символа). Для изменяемых строк всегда указывается VARCHAR(n) с осмысленным ограничением длины (ФИО — 50–100, email — 100). Неограниченный TEXT используется только для описаний и комментариев.NUMERIC(precision, scale)): Категорически запрещено использовать типы с плавающей точкой (REAL, FLOAT, DOUBLE) для денежных сумм, цен, тарифов и остатков топлива из-за накапливающейся ошибки округления IEEE 754. Для цен применяется NUMERIC(10,2) (число до 99 999 999.99 с точностью до копейки).DATE, TIME, TIMESTAMP): Хранение дат в текстовом формате VARCHAR(10) является грубейшей ошибкой, ломающей хронологическую сортировку, сравнение интервалов и индексы. DATE — дата рождения, дата заезда; TIMESTAMP (или TIMESTAMPTZ) — точный момент совершения операции.BOOLEAN): Применяется для флагов состояния (активен/заблокирован, в штате/уволен) вместо устаревших представлений 0/1 в SMALLINT.Ограничения целостности гарантируют, что в базу данных физически невозможно записать логически некорректные или мусорные данные:
NOT NULL — запрещает отсутствие значения. Должно устанавливаться на все обязательные атрибуты сущности.UNIQUE — гарантирует уникальность значений в пределах колонки или кортежа колонок (альтернативные ключи).DEFAULT — автоматическое заполнение значения по умолчанию при вставке (например, CURRENT_TIMESTAMP или TRUE).CHECK (условие) — предикатное ограничение, валидирующее значение по логическому выражению на уровне строки. Примеры:
CHECK (data_vyezda > data_zaezda)
CHECK (kolichestvo_na_sklade >= 0)
CHECK (status_zakaza IN ('принят', 'в_работе', 'готов', 'выдан'))
CHECK (cena_prodazhi >= cena_zakupki)
Внешний ключ связывает дочернюю таблицу с родительской, гарантируя, что значение поля дочерней таблицы существует в первичном ключе родительской. Поведение при модификации или удалении родительской записи регламентируется секцией ON DELETE / ON UPDATE:
| Каскадное правило | Механизм действия | Область применения и ограничения |
|---|---|---|
ON DELETE RESTRICT / NO ACTION |
Блокирует удаление родительской строки при наличии хотя бы одной связанной записи в дочерней таблице (вызывает ошибку FK violation). | Правило по умолчанию в промышленной разработке! Обязательно для финансовых документов, договоров, путевых листов, каталогов номенклатуры. Предотвращает случайную потерю данных. |
ON DELETE CASCADE |
Автоматически физически удаляет все дочерние записи вслед за удалением родительской строки. | Допустимо строго для жестко подчиненных композиционных сущностей: строки чека в накладной, спецификация запчастей в квитанции ремонта. Опасно при ветвистых связях. |
ON DELETE SET NULL |
При удалении родительской строки внешнему ключу в дочерней таблице присваивается значение NULL (требует отсутствия NOT NULL). |
Используется для факультативных ассоциаций. Например: при удалении учетной записи мастера-приемщика заказ на ремонт сохраняется, а поле мастера зануляется. |
ON UPDATE CASCADE |
При изменении значения первичного ключа в родительской таблице новое значение автоматически каскадируется во все дочерние записи. | Рекомендуется включать для всех внешних ключей, чтобы гарантировать синхронизацию при технологических переносах данных. |
Для объяснения опасности ON DELETE CASCADE преподаватель моделирует ситуацию: «Представьте, что менеджер автосалона решил удалить из справочника неактивную модель автомобиля. Если на связи стоит CASCADE, что произойдет? Удалятся все 200 машин автопарка, все путевые листы водителей и бухгалтерия за 5 лет! Поэтому для критичных данных мы используем RESTRICT и логическое удаление (Soft Delete через флаг is_aktivnyy)».
Преподаватель запускает в консоли или демонстрирует на слайде сложение в типах с плавающей запятой: 0.1 + 0.2 = 0.30000000000000004. После чего задает вопрос: «Что скажет аудитор или налоговая, если на балансе компании из-за ошибки float потеряются или возникнут лишние копейки?». Это навсегда закрепляет применение типа NUMERIC(10,2) для финансов.
При проверке условий дат студенты часто пишут CHECK (data_vyezda > data_zaezda), забывая о возможности нулевых значений (NULL) для незавершенных процессов. Преподаватель обращает внимание на предикаты с IS NULL OR ..., объясняя трехзначную логику реляционных баз данных (TRUE, FALSE, UNKNOWN).
INTEGER, VARCHAR(n), NUMERIC, TIMESTAMP, BOOLEAN).ON DELETE RESTRICT/CASCADE/SET NULL).NOT NULL, UNIQUE, предикатных ограничений CHECK на предметную логику (диапазоны, даты, статусы), прохождение чек-листа самоконтроля.