Анализ предметной области: связи и правила

1. Что такое связь между сущностями?

        Связь (Relationship) — это поименованная логическая или функциональная ассоциация между двумя или несколькими сущностями предметной области.
      

Если сущность — это имя существительное («Кто?», «Что?»), то связь — это глагол:

Врач принимает Пациента.
Студент состоит в Учебной группе.
Клиент оформляет Кредитный договор.
Самолет выполняет Рейс.

Связи моделируют реальные бизнес-процессы и определяют маршруты извлечения данных.

2. Графические нотации: Chen vs Crow's Foot

Нотация Питера Чена (1976)

Классическая академическая нотация.
Связь изображается в виде ромба.
Кардинальность подписывается символами: 1, M, N.
Фокус на концептуальном понимании предметной области.

Нотация Crow's Foot («Лапка»)

Индустриальный стандарт проектирования РБД.
Прямая соединительная линия без ромбов.
Мощность кодируется маркерами на концах линии: «вилка», черточки, кружок.
Наглядно совмещает кардинальность и обязательность участия.

3. Кардинальность связей: фундаментальные типы

Кардинальность (Cardinality) определяет максимальное число экземпляров одной сущности, ассоциированных с экземпляром другой сущности:

1:1 (Один к одному): Одному объекту А соответствует максимум один объект Б, и наоборот.
1:M (Один ко многим): Одному объекту А соответствует множество объектов Б, но каждому Б — строго один объект А.
M:N (Многие ко многим): Множеству объектов А соответствует множество объектов Б в обоих направлениях.

        Кардинальность диктует способ преобразования концептуальной схемы в реляционные таблицы!
      

4. Связь «Один к одному» (1:1)

        Каждому экземпляру первой сущности соответствует не более одного экземпляра второй.
      

Примеры из предметных областей:

Гражданин — Паспорт РФ (в конкретный период времени).
Пассажир — Посадочное место на конкретном авиарейсе.
Автомобиль — VIN-номер кузова.

Реализация в реляционной базе данных:

Внешний ключ в зависимой таблице с ограничением уникальности UNIQUE NOT NULL.
Если жизненные циклы сущностей совпадают на 100%, их часто объединяют в одну общую таблицу для экономии ресурсов.

5. Связь «Один ко многим» (1:M)

        Основной строительный блок реляционных баз данных. Вся реляционная модель держится на связях 1:M.
      

Примеры:

Учебная группа (1) — Студенты (M).
Врач (1) — Приемы (M).
Кредитный договор (1) — Платежи погашения (M).

Правило миграции ключа:

        Первичный ключ из таблицы на стороне «Один» мигрирует в качестве внешнего ключа (FK) в таблицу на стороне «Многие»! Никогда наоборот!
      

6. Связь «Многие ко многим» (M:N)

Примеры: Студенты и Дисциплины; Врачи и Пациенты; Товары и Заказы.

        Критический закон РБД: Реляционные СУБД физически НЕ ПОДДЕРЖИВАЮТ связь M:N напрямую!
      

Механизм декомпозиции:

Связь M:N разбивается на две связи 1:M.
Создается промежуточная связующая таблица (Junction Table / Associative Entity).
Таблица содержит внешние ключи обеих родительских таблиц и собственные атрибуты события (например, дату, оценку, количество).

7. Класс принадлежности сущностей

Определяет, обязан ли экземпляр сущности участвовать в связи:

Обязательное участие (Mandatory)

Экземпляр не может существовать без связанной записи.

Прием невозможен без Врача.
Студент обязан числиться в Группе.
В SQL: внешний ключ объявляется как NOT NULL.

Факультативное участие (Optional)

Экземпляр может существовать автономно.

Новый Врач может пока не иметь приемов.
Новая Группа на этапе набора не имеет студентов.
В SQL: внешний ключ может содержать значение NULL.

8. Рекурсивные (самоссылающиеся) связи

        Рекурсивная связь — это связь, в которой сущность ассоциируется с самой собой в различных ролях.
      

Типовые сценарии в реальных базах:

Иерархия подчинения сотрудников: Таблица Сотрудник. Поле Руководитель_ID ссылается на Сотрудник_ID этой же таблицы. Генеральный директор имеет NULL.
Древовидные каталоги: Категории товаров (подкатегория ссылается на родительскую категорию).
Состав изделия (BOM): Деталь состоит из других деталей.

9. Бизнес-правила (Business Rules)

        Бизнес-правило — это строгое словесное утверждение, определяющее политику организации, порядок работы или структуру данных.
      

Бизнес-правила получают от заказчика при предпроектном обследовании:

«Пациент может отменить запись не позднее чем за 2 часа до приема.»
«Студент не допускается к сессии при наличии хвостов по лабораторным.»
«Сумма списания по кредиту не может превышать остаток задолженности.»
«Количество проданных билетов не должно превышать емкость борта.»

Задача проектировщика БД — перевести бизнес-правила на язык ограничений базы данных!

10. Семантические ограничения целостности

В отличие от стандартной целостности (PK и FK), семантическая целостность отражает логику предметной области:

Темпоральные ограничения: запрет на пересечение интервалов времени (один врач не может вести два приема одновременно).
Балансовые ограничения: сумма операций не может превышать лимит счета.
Ограничения взаимной непротиворечивости: аэропорт вылета не может совпадать с аэропортом прилета.

        Реализуются в СУБД через ограничения CHECK, триггеры, хранимые процедуры и составные уникальные индексы.
      

11. Эталонный кейс: Библиотечная система

Сущности: Читатель, Книга, Выдача.

Связи и кардинальность

Читатель — Выдача: 1:M (факультативное со стороны Читателя).
Книга — Выдача: 1:M (факультативное со стороны Книги).
Читатель — Книга: концептуально M:N, декомпозировано через Выдачу.

Бизнес-правила и ограничения

Один экземпляр книги не может быть одновременно выдан двум читателям.
Читателю блокируется выдача новых книг при наличии книги со сроком просрочки более 14 дней.

12. Топ-3 ошибок студентов при моделировании

«Ошибка мгновенного среза»: утверждение, что связь «Врач — Пациент» является 1:1, потому что в данный момент в кабинете один человек. (Нужно смотреть на весь период работы системы!).
«Взаимный тупик обязательности»: попытка сделать участие обязательным с обеих сторон (нельзя внести врача без приема, а прием без врача).
«Подмена бизнес-правил типами данных»: путаница между правилом предметной области и ограничением поля VARCHAR(50).

13. Инженерное резюме проектировщика

Связь 1:M формируется передачей внешнего ключа в дочернюю таблицу.
Связь M:N требует отдельной таблицы-ассоциации.
Обязательность участия транслируется в ограничение NOT NULL.
Бизнес-правила защищают данные от логического искажения на уровне СУБД.

        Грамотно спроектированные связи и ограничения предотвращают программные сбои и аномалии данных еще до написания первого SQL-запроса!
      

Тематический интернет-мем: «Exploits of a Mom» (культовый веб-комикс про «Little Bobby Tables», xkcd #327).
Автор: Randall Munroe. Первоисточник: https://xkcd.com/327/.
Лицензия: Creative Commons Attribution-NonCommercial 2.5 Generic (CC BY-NC 2.5).
Смысл мема: Когда правила валидации данных, семантические ограничения и экранирование ввода игнорируются, имя ребенка Robert'); DROP TABLE Students;-- уничтожает всю базу данных учебного заведения за один учебный год.