Моделирование предметной области. Часть 2

Введение

Мы продолжаем знакомство с моделированием баз данных. Сегодняшнее занятие посвящено проектированию конкретной предметной области — построению модели данных для сети кинотеатров. Поскольку механизм продажи билетов и организации сеансов всем хорошо знаком, мы пропустим формальное описание технического задания и сразу перейдём к моделированию. Работать мы будем в приложении ERwin Data Modeler (или аналоге), используя гибридную модель, сочетающую логический и физический уровни.

Базовые справочники: города и кинотеатры

Сущность «Город»
Предположим, что все кинотеатры сети находятся в одной стране, и города с одинаковыми названиями в ней отсутствуют. Это позволяет создать сущность Город (City) с единственным атрибутом Название города (CityName). Поскольку название уникально, оно может выступать в роли первичного ключа (Primary Key).

Здесь возникает важный методический момент. Часто для ускорения поиска вводят суррогатный ключ — числовой идентификатор, а естественный уникальный атрибут переносят в список вторичных. Однако на этапе даталогического проектирования мы осознанно отказываемся от суррогатных ключей. Это позволяет сохранить истинную логику: когда первичный ключ родительской таблицы мигрирует в дочернюю как часть её первичного ключа, мы получаем идентифицирующую связь. При использовании суррогатов все внешние ключи попадают в список вторичных атрибутов, и связь формально становится неидентифицирующей, что искажает реальную логику предметной области.

Сущность «Кинотеатр»
Переходим к сущности Кинотеатр (Cinema). В одном городе может находиться несколько кинотеатров. Адрес здания уникален в пределах города, но может повториться в разных городах. Поэтому первичный ключ должен быть составным: он включает Адрес (Address) и мигрировавший внешний ключ CityName.

Создаём идентифицирующую связь от сущности «Город» к сущности «Кинотеатр». Внешний ключ CityName становится частью первичного ключа кинотеатра. Комбинация (CityName, Address) однозначно идентифицирует каждый зал сети. В качестве вторичного атрибута добавим Название кинотеатра (CinemaName) — для удобства различения филиалов в речи.

 Справочники персонала и должностей

Сущность «Должность»
Создаём справочник Должность (JobTitle) с очевидным первичным ключом Наименование должности (TitleName). Добавим вторичный атрибут Описание (Description) для хранения должностных обязанностей.

Сущность «Персонал»
Для хранения данных о сотрудниках создаётся сущность Персонал (Personnel). Чтобы гарантировать уникальность, вводим Персональный номер (PersonnelNumber) как первичный ключ, несмотря на общий отказ от суррогатов (в реальной жизни это внутренний номер карточки сотрудника). Другие атрибуты: Имя (FirstName), Фамилия (LastName), Дата рождения (BirthDate) и Номер паспорта (PassportNumber).

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

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

Моделирование фильмов: карточка фильма и связи «многие ко многим»

Выбор интерпретации сущности
Переходим к самой тонкой части проектирования. Фильм может демонстрироваться в нескольких форматах: 2D, 3D, IMAX. Ключевой вопрос: считать ли один и тот же фильм в разных форматах разными сущностями (как разные физические плёнки) или одной (как информационную карточку)?

С точки зрения чистоты предметной области фильм для кинотеатра — это конкретная бобина с плёнкой, которая имеет формат. Однако мы выбираем интерпретацию в пользу будущей физической реализации и внешних приложений (по аналогии с карточкой фильма на IMDb). Мы рассматриваем фильм как информационный объект, без привязки к формату. Это упростит написание клиентского кода и работу фронтальных приложений, пусть даже ценой некоторого отхода от «идеальной» логики.

Сущность «Фильм»
Создаём сущность Фильм (Film). Попытка сделать первичный ключ на основе атрибутов Название (FilmName), Год выпуска (ReleaseYear) и Режиссёр наталкивается на проблему: у одного фильма может быть несколько режиссёров, а значит, режиссёр не может быть частью уникального идентификатора фильма. Кроме того, фильм может одновременно принадлежать к нескольким жанрам.

Решение находится элегантное: в реальной жизни каждый фильм получает прокатную лицензию с уникальным номером. Поэтому вводим атрибут Номер лицензии (LicenseNumber) и делаем его первичным ключом сущности «Фильм». Название и год выпуска становятся вторичными атрибутами, добавляется также Синопсис (Synopsis).

Связи «многие ко многим»
Для отражения того факта, что фильм может относиться к нескольким жанрам, сниматься несколькими режиссёрами и иметь множество актёров, мы сталкиваемся с отношениями «многие ко многим» (Many-to-Many). Для их разрешения необходимы дополнительные ассоциативные таблицы.

Предварительно создаются три справочные сущности:
• Жанр (Genre) с первичным ключом Название жанра (GenreName).
• Режиссёр (Director) с составным первичным ключом: Имя (FirstName), Фамилия (LastName), Дата рождения (BirthDate).
• Актёр (Actor) с идентичным набором ключевых полей.

Далее потребуется установить связи «многие ко многим» между «Фильмом» и каждым из этих справочников. Сами ассоциативные таблицы и тонкие настройки связей будут рассмотрены далее, но фундаментальный принцип уже зафиксирован: как только атрибут, претендовавший на роль части первичного ключа, оказывается множественным, требуется пересмотр ключа и введение отношений «многие ко многим».

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

Процесс проектирования начинается с вычленения базовых справочников, выступающих фундаментом всей модели. На примере городов и кинотеатров сразу проявляется дилемма: использовать естественные ключи или суррогатные идентификаторы. Осознанный отказ от суррогатов на этапе даталогического анализа позволяет сохранить истинную природу связей — идентифицирующую миграцию ключа в дочернюю сущность, что напрямую влияет на понимание зависимости объектов. Составной ключ кинотеатра, объединяющий город и адрес, демонстрирует, как контекст родительской сущности формирует уникальность зависимой.

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

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