Логическая модель и отображение связей
После построения диаграммы для наглядности выбран ортогональный
layout. На логическом уровне большинство связей понятны. Связи
«многие ко многим» (many-to-many) напрямую отображаются в логической модели, но на физическом уровне требуют введения промежуточной таблицы. Например, сущности «Фильм» и «Формат» связаны как «многие ко многим». На физическом уровне появляется
ассоциативная таблица «Фильм-Формат», связывающая их через внешние ключи.
Идентифицирующие и неидентифицирующие связи
В модели присутствуют оба типа связей. Когда
внешний ключ (foreign key, FK) родительской таблицы входит в
первичный ключ (primary key, PK) дочерней, связь является
идентифицирующей. Если FK попадает в неключевые атрибуты — связь
неидентифицирующая.
Проблемная область: таблица расписания
Таблица
Schedule содержит собственное поле
StartDate (входит в PK) и унаследованные FK: от таблицы «Зал» (
HallName,
CityName,
Address) и от ассоциативной таблицы «Фильм-Формат» (
LicenceFormatName — комбинация фильма и формата). Таким образом, расписание фиксирует, какой фильм в каком формате показывают в конкретном зале.
Отдельная таблица связывает залы и поддерживаемые ими форматы. Возникает потенциальная коллизия: в расписание можно назначить фильм в формате, который зал не поддерживает. Ссылочная целостность не предотвращает такое противоречие, так как связи приходят от разных таблиц.
Если бы мы попытались решить проблему на уровне модели, добавив связь от ассоциативной таблицы «Зал-Формат» напрямую в расписание, внутри одной записи могло бы оказаться два разных значения формата (от фильма и от зала). Это привело бы к противоречию и нарушению нормализации.
Проблемная область: таблица деталей заказа
Таблица
OrderDetail содержит поля, унаследованные от расписания (StartDate, LicenceFormatName, HallName, CityName, Address), а также от заказа (PersonalNumber, Item). Дополнительно по неидентифицирующей связи приходит FK от таблицы
SeatPlace (место в зале), которая сама ссылается на зал. Возникает вторая коллизия: в деталь заказа можно подставить место из зала, отличного от указанного в расписании. Ссылочная целостность вновь не гарантирует соответствия.
Компенсация на физическом уровне: триггеры и хранимые процедуры
Стопроцентно отразить все ограничения предметной области только логической моделью не удаётся. На физическом уровне эту задачу решают
триггеры (triggers) и
хранимые процедуры (stored procedures). При попытке вставить строку в расписание может автоматически выполняться код: он проверяет формат фильма, запрашивает поддерживаемые форматы зала из ассоциативной таблицы «Зал-Формат» и, если соответствие отсутствует, запрещает вставку с уведомлением пользователя. Так физический уровень «дотягивает» модель до реальных бизнес-правил.
Нормализация как средство предотвращения коллизий
Описанные коллизии напрямую связаны с
нормализацией — процессом преобразования схемы базы данных для снижения вероятности аномалий и противоречий. Каждая следующая
нормальная форма (normal form) уменьшает риск определённого типа аномалий.
Всего выделяют шесть номерных нормальных форм (от 1NF до 6NF) и две дополнительные:
нормальная форма Бойса–Кодда (Boyce–Codd normal form, BCNF), находящаяся между 3NF и 4NF, и
доменно-ключевая нормальная форма (Domain/Key normal form, DKNF). Итого восемь уровней.
Противоречие с форматом в расписании фактически нарушает третью нормальную форму (3NF). Коллизия в OrderDetail из-за неидентифицирующей связи места остаётся допустимой в рамках 3NF, но была бы критичной для BCNF. Это объясняет, почему нормальные формы разработаны для контроля подобных ситуаций.
Практический ориентир: третья нормальная форма
Полная нормализация (до 6NF) привела бы к огромному количеству таблиц и сделала бы схему необозримой. Поэтому на практике придерживаются компромисса: стремятся достичь
третьей нормальной формы (3NF). Этого обычно достаточно. Проблемы, неустранимые на уровне 3NF, решают на физическом уровне с помощью триггеров и процедур. Так достигается баланс между сложностью модели и вероятностью коллизий.
Заключение
Схему можно улучшать и дополнять, но в упрощённом виде она иллюстрирует ключевые аспекты моделирования. Далее предстоит изучить теоретические основы нормализации и перейти к физическому проектированию в среде SQL Server, где модель будет доведена до состояния, готового к внедрению.
Краткие итоги
Проектирование базы данных движется от логической модели к физической. Связи «многие ко многим» материализуются в ассоциативных таблицах, а тип миграции внешнего ключа определяет идентифицирующий или неидентифицирующий характер связи. Однако даже корректная по ссылочной целостности схема может скрывать коллизии. В модели кинотеатра две ключевые уязвимости: расписание способно принять формат фильма, не поддерживаемый залом; детали заказа могут сослаться на место из другого зала. Такие нарушения бизнес-логики не улавливаются одними внешними ключами. Устранение переносится на физический уровень, где триггеры и хранимые процедуры программно проверяют комплексные условия перед модификацией данных. Этот подход демонстрирует фундаментальный принцип: логическая модель приближает структуру к реальности, а полное соответствие достигается средствами СУБД.
Параллельно наука о проектировании предлагает нормализацию — последовательное приведение к нормальным формам, каждая из которых устраняет определённый класс аномалий. Всего насчитывается шесть номерных форм и две промежуточные — BCNF и DKNF. Противоречие форматов нарушает 3NF, тогда как коллизия с местом допустима в 3NF, но не в BCNF. Это раскрывает ценность нормальных форм как диагностического инструмента. Однако абсолютная нормализация ведёт к взрывному росту числа таблиц и усложнению восприятия, поэтому сообщество выработало прагматичный ориентир: достижение 3NF считается достаточным стандартом, а оставшиеся проблемы закрываются физическими механизмами. Такой баланс позволяет создавать сопровождаемые, надёжные и адекватные предметной области базы данных. Моделирование — итеративный процесс, требующий осознанной фиксации обнаруженных коллизий для последующей компенсации. Грамотное сочетание нормализации и процедурного контроля на стороне сервера даёт возможность построить целостную информационную систему даже в условиях ограничений реляционной модели.
Логическая модель отображает связи «многие ко многим» напрямую. На физическом уровне они преобразуются в ассоциативные таблицы (например, «Фильм-Формат»). Связь считается идентифицирующей, если внешний ключ (FK) родителя входит в первичный ключ (PK) потомка, и неидентифицирующей — если FK попадает в неключевые атрибуты.
В таблице Schedule собраны FK зала и пары «фильм-формат». Отдельная таблица связывает залы с поддерживаемыми форматами. Возникает коллизия: можно назначить фильм в формате, который зал не поддерживает. Попытка решить это на уровне модели, добавив прямую связь от ассоциативной таблицы «Зал-Формат», привела бы к появлению в одной строке двух противоречащих значений формата и нарушению нормализации.
В таблице OrderDetail унаследованы поля расписания и дополнительно привязано место, ссылающееся на зал. Можно указать место из другого зала — ещё одна скрытая коллизия, не ловящаяся стандартными внешними ключами.
Полностью отразить бизнес-правила только логической моделью невозможно. На физическом уровне ограничения компенсируются триггерами и хранимыми процедурами. При вставке в расписание программный код проверяет, поддерживает ли выбранный зал данный формат фильма, и при несоответствии блокирует операцию с уведомлением пользователя. Так физика «дотягивает» модель до реальности.
Обнаруженные противоречия напрямую связаны с нормализацией — процессом снижения риска аномалий. Существует шесть номерных нормальных форм (1NF–6NF) и две промежуточные: нормальная форма Бойса–Кодда (BCNF) и доменно-ключевая (DKNF), всего восемь. Противоречие формата нарушает третью нормальную форму (3NF). Коллизия с местом в OrderDetail не нарушает 3NF благодаря неидентифицирующей связи, но была бы критична для BCNF. Таким образом, нормальные формы служат инструментом выявления подобных уязвимостей.
Полная нормализация до 6NF резко увеличивает количество таблиц и делает схему необозримой. Практический стандарт — достичь 3NF, а оставшиеся проблемы решать на физическом уровне. Это даёт баланс между сложностью и надёжностью. Дальнейшие шаги включают изучение теории нормальных форм и физическое проектирование в SQL Server.
1. Связь «многие ко многим» на физическом уровне разрешается созданием ассоциативной таблицы с внешними ключами обеих сущностей.
2. Идентифицирующая связь переносит внешний ключ в первичный ключ дочерней таблицы, неидентифицирующая — в неключевые атрибуты.
3. Схема данных может содержать скрытые коллизии, не предотвращаемые стандартными ограничениями внешних ключей.
4. В таблице расписания потенциально можно назначить фильм в формате, не поддерживаемом выбранным залом.
5. В таблице деталей заказа возможно указать место из зала, не совпадающего с залом из расписания.
6. Триггеры и хранимые процедуры позволяют на физическом уровне реализовать сложные проверки соответствия бизнес-правилам.
7. Нормализация — это процесс последовательного преобразования схемы для снижения риска аномалий и противоречий.
8. Существует шесть номерных нормальных форм (1NF–6NF) и две промежуточные: нормальная форма Бойса–Кодда (BCNF) и доменно-ключевая (DKNF).
9. Противоречие формата в расписании нарушает третью нормальную форму (3NF).
10. Коллизия в OrderDetail не нарушает 3NF благодаря неидентифицирующей связи, но была бы недопустима в BCNF.
11. Общепринятый практический стандарт — достижение третьей нормальной формы; дальнейшие проблемы решаются на физическом уровне.
12. Проектирование требует постоянного поиска баланса между сложностью схемы и вероятностью возникновения коллизий.
1. Как физически реализуется связь «многие ко многим» из логической модели?
2. По какому признаку можно отличить идентифицирующую связь от неидентифицирующей?
3. Опишите потенциальную коллизию, связанную с форматом фильма и зала в таблице расписания.
4. Почему эту коллизию нельзя предотвратить только внешними ключами?
5. Какие средства физического уровня позволяют компенсировать недостаточность логической модели?
6. Что такое нормализация и какова её основная цель?
7. Перечислите все нормальные формы, упомянутые в лекции, включая промежуточные.
8. Какая нормальная форма нарушается при возникновении противоречия форматов в расписании?
9. Почему коллизия с местом в Order Detail не нарушает третью нормальную форму?
10. К чему привела бы полная нормализация до шестой нормальной формы?
11. Почему третья нормальная форма считается практическим стандартом?
12. Каким образом можно зафиксировать и впоследствии устранить обнаруженные в модели коллизии?
