Базовые операции SQL. Часть 3

Проблема в исходной схеме

Перед завершением заполнения базы данных её необходимо привести к третьей нормальной форме (3НФ).
В текущей структуре присутствуют таблицы:
• Film_Format — связь фильмов и форматов, в которых они закуплены;
• Hall_Format — связь залов и форматов, которые они способны показывать;
• Schedule (расписание) — пересекает фильм, формат и зал, добавляя время начала сеанса.

Конфликт возникает именно в расписании. Его структура допускает назначение фильма в формате, который выбранный зал не поддерживает. Например, можно указать, что фильм показывается в 3D, и одновременно привязать зал без поддержки 3D. Это нарушает третью нормальную форму, так как присутствует транзитивная зависимость: формат фильма косвенно зависит от зала через расписание.

Удаление проблемных таблиц

Одно из возможных, но отклонённых решений — оставить схему как есть, добавив хранимую процедуру (stored procedure) проверки совместимости формата и зала при каждом добавлении строки в расписание. Такой подход сохранил бы схему во второй нормальной форме (2НФ), однако требовал бы написания дополнительного кода, а главное — не устранял нарушение 3НФ.

Выбран другой путь. Таблицы Film_Format и Hall_Format удаляются, поскольку они больше не будут нужны. Также удаляются связи от этих таблиц к расписанию.

Создание единой таблицы Film_Hall_Format

Вместо двух промежуточных таблиц создаётся одна — Film_Hall_Format (Фильм-Зал-Формат). Она пересекает сразу три сущности:
• ID_Film (фильм),
• ID_Hall (зал),
• ID_Format (формат).

Все три поля объявляются составным первичным ключом (primary key). Тип каждого поля — целочисленный (int). Устанавливаются внешние ключи к соответствующим таблицам-справочникам.

Избыточность как осознанный компромисс

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

Однако появляется управляемая избыточность. Если кинотеатр имеет пять залов с поддержкой 3D и два фильма в 3D-формате, в таблицу Film_Hall_Format нужно внести все 5 × 1 = 5 комбинаций для каждого фильма (итого 10 строк), даже если реально каждый фильм будет демонстрироваться лишь в одном-двух залах. Фактически перечисляются все потенциально возможные варианты показа.

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

Выгода от устранения логических противоречий значительно перевешивает неудобства избыточного перечисления комбинаций.

Итоговая схема

Таким образом, схема приведена к третьей нормальной форме. Расписание остаётся связанным с заказом (Order) и деталями заказа (Order_Detail) для продажи конкретных мест. Дальнейшая работа будет заключаться в полном наполнении базы данными, создании резервной копии и последующем использовании SQL для написания сложных запросов, триггеров и хранимых процедур.

Краткие итоги

Процесс нормализации схемы базы данных кинотеатра наглядно демонстрирует, как выбор между строгим соблюдением теоретических требований и прагматичными компромиссами определяет качество информационной системы. В центре анализа — противоречие, порождённое раздельным хранением связей «фильм–формат» и «зал–формат» при наличии расписания, которое должно объединять все три сущности. Разнесение допустимых комбинаций по двум таблицам создаёт транзитивную зависимость и открывает возможность для внесения некорректных данных, когда фильм в конкретном формате назначается в зал без поддержки этого формата.

Предложенное решение отказывается от полумер вроде хранимых процедур проверки на уровне приложения и устраняет причину аномалии структурно — через реорганизацию модели данных. Создание единой связующей таблицы, которая одномоментно фиксирует тройку «фильм–зал–формат», превращает потенциально опасное сочетание в допустимое. Такой шаг переводит схему в третью нормальную форму, полностью исключая конфликты на уровне ограничений целостности.

Ценой этого становится детерминированная избыточность: для каждого фильма в конкретном формате приходится явно перечислять все залы, технически способные его показать, даже если на практике задействована лишь малая их часть. Анализ этого компромисса показывает, что издержки хранения нескольких целочисленных идентификаторов пренебрежимо малы в сравнении с рисками, которые несёт нарушение нормализации. Кроме того, такой подход упрощает логику приложения — контроль корректности перекладывается на декларативные ограничения базы данных, а не на императивный код проверок.

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