1. Инфологическое моделирование: от реальности к схеме
Любая база данных создается не сама по себе, а для обслуживания процессов в некоторой предметной области (Domain Area). Предметная область — это часть реального мира, подлежащая изучению и автоматизации (например: автопарк логистической компании, библиотека колледжа, регистратура клиники или складской комплекс).
Процесс создания базы данных начинается с инфологического (концептуального) анализа. На этом этапе проектировщик взаимодействует с экспертами предметной области, изучает документооборот, регламенты и вербальные описания бизнес-процессов, абстрагируясь от технических деталей СУБД (PostgreSQL, MySQL или Oracle).
Сущность (Entity) и её Экземпляр (Instance)
Центральным понятием инфологической модели является сущность.
- Сущность (Entity Type) — это абстрактный класс однотипных объектов, процессов или явлений реального мира, сведения о которых необходимо накапливать и хранить. В ER-диаграммах сущность обозначается прямоугольником. Примеры сущностей: Сотрудник, Автомобиль, Договор.
- Экземпляр сущности (Instance) — конкретный элемент данного класса, обладающий индивидуальными значениями характеристик. В реляционной таблице сущности соответствует вся таблица, а экземпляру — конкретная строка (кортеж).
Выписать из технического задания все ключевые существительные (клиент, заказ, деталь, мастер, оплата, чек).
Существует ли данный объект независимо? Имеет ли он множество однотипных представителей в системе?
Обладает ли объект собственным набором атрибутов (свойств), или это просто единичное значение (цвет, статус)?
Если объект имеет свойства и независимый жизненный цикл → фиксируем как СУЩНОСТЬ. Если это единичное значение → делаем АТРИБУТОМ.
2. Классификация атрибутов сущности
Атрибут (Attribute) — поименованное свойство сущности, отражающее качественную или количественную характеристику её экземпляров. Для грамотного реляционного проектирования атрибуты классифицируются по трем независимым осям:
| Ось классификации | Категория атрибута | Характеристика и семантика | Проектное решение в БД |
|---|---|---|---|
| По структуре | Простые (атомарные) | Не содержат составных частей (Возраст, Оклад). | Хранятся в одном неделимом столбце. |
| Составные (декомпозируемые) | Состоят из смысловых компонентов (ФИО, Адрес). | Декомпозируются на атомарные столбцы (Фамилия, Имя, Город). | |
| По кардинальности | Однозначные | Имеют ровно одно значение для одного экземпляра (Дата_рождения). | Стандартный столбец таблицы. |
| Многозначные | Могут содержать список значений (Авторы, Телефоны). | Запрещено хранить через запятую! Выносятся в дочернюю связанную таблицу. | |
| По источнику | Базовые (хранимые) | Вводятся пользователем и сохраняются физически (Цена, Количество). | Физическое поле на диске. |
| Производные (вычисляемые) | Рассчитываются на основе других атрибутов (Сумма = Цена * Кол-во). | Не хранятся (или вычисляются в VIEW / GENERATED COLUMN) во избежание рассинхронизации. |
Можно ли вычислить этот атрибут математически по другим полям (например, Сумма = Кол-во * Цена)? Да → ПРОИЗВОДНЫЙ (не хранить). Нет → перейти к Шагу 2.
Может ли у одного объекта быть несколько таких значений (несколько телефонов, соавторов)? Да → МНОГОЗНАЧНЫЙ (вынести в отдельную таблицу). Нет → перейти к Шагу 3.
Требуется ли отдельный поиск или сортировка по компонентам (например, сортировка по фамилии)? Да → СОСТАВНОЙ (разбить на части). Нет → ПРОСТОЙ АТОМАРНЫЙ.
3. Теория доменов и ограничения целостности
Домен (Domain) — это множество всех потенциально допустимых значений атрибута. Понятие домена значительно шире, чем просто тип переменной в языке программирования или тип столбца в СУБД.
Элементы спецификации домена
- Тип данных: строковый, целочисленный, вещественный, дата/время, булев.
- Смысловой диапазон: CHECK (Скидка >= 0 AND Скидка <= 100).
- Формат и маска: шаблон для ИНН, СНИЛС, VIN, email-адреса.
- Перечисление допустимых констант: статус заказа ENUM('Новый', 'В сборке', 'Отправлен').
- Определенность значения: обязательность ввода NOT NULL или допустимость неизвестного значения NULL.
4. Идентификация сущностей: Ключи и их природа
Каждый экземпляр сущности должен быть однозначно различим среди всех остальных. Для этого используется аппарат ключей.
Потенциальные ключи (Candidate Keys)
Потенциальный ключ — это минимальный набор атрибутов, однозначно идентифицирующий экземпляр сущности. Минимальность означает, что если мы исключим из ключа хотя бы один атрибут, оставшаяся часть потеряет свойство уникальности.
У сущности может быть несколько потенциальных ключей. Например, у сущности Студент потенциальными ключами являются:
- Номер студенческого билета (уникален).
- Номер паспорта (серия + номер).
- СНИЛС.
Выбор Первичного ключа (Primary Key)
Один из потенциальных ключей назначается первичным ключом (PK). Остальные потенциальные ключи становятся альтернативными ключами (AK) и контролируются уникальными индексами.
Естественные против Суррогатных ключей
Естественный ключ (Natural Key) берется из реального мира (VIN автомобиля, паспортные данные, ISBN). Он понятен человеку, но обладает серьезными недостатками: длинный строковый формат замедляет индексы, а при изменении документа в реальном мире требуется сложное обновление внешних ключей по всей базе.
Суррогатный ключ (Surrogate Key) — это искусственно добавленный системный идентификатор (например, целое число ID INT AUTO_INCREMENT). Он абсолютно стабилен, не несет бизнес-логики и обеспечивает максимальную производительность связей.