Инфологический (концептуальный) анализ предметной области
Инфологический анализ — фундамент создания надежной базы данных. Задача разработчика — перевести слабоструктурированное описание реального мира в формальную математическую модель.
Сбор требований
Интервьюирование предметных экспертов, аудит бланков, отчетов и бизнес-правил предприятия.
Семантическая модель
Выделение независимых сущностей, их качественных и количественных характеристик (атрибутов).
Независимость от СУБД
Инфологическая схема инвариантна к конкретной СУБД (PostgreSQL, Oracle, MySQL, SQLite).
Понятие сущности (Entity Type)
Сущность (Entity) — абстрактная категория или класс однотипных объектов реального мира, информация о которых представляет интерес для предметной области.
Материальные сущности
Физически осязаемые объекты реального мира:
- Автомобиль (тягач, прицеп, легковой фургон);
- Сотрудник (водитель, менеджер, инженер);
- Запчасть (тормозные колодки, фильтр).
Нематериальные и процессные сущности
События, договоры, факты взаимодействия:
- Путевой лист (факт выполнения рейса);
- Бронирование (резервирование номера отеля);
- Заказ на ремонт (договор на оказание услуг).
Экземпляр сущности (Entity Instance / Tuple)
Разграничение сущности и экземпляра — базовое правило инфологического анализа.
Сущность (Чертеж / Метаданные)
Определяет схему и набор допустимых характеристик.
В реляционной СУБД сущности соответствует таблица (Relation).
Экземпляр (Конкретный объект)
Конкретное индивидуальное воплощение сущности с реальными значениями.
В реляционной СУБД экземпляру соответствует строка таблицы (Кортеж / Tuple).
Система классификации атрибутов
Атрибут — поименованное элементарное свойство сущности. Атрибуты классифицируются по трем независимым ортогональным осям:
Структура
Простые (атомарные) vs Составные (декомпозируемые).
Делимо ли свойство на независимые смысловые части?
Кардинальность
Однозначные vs Многозначные.
Сколько значений может принимать свойство у одного экземпляра?
Происхождение
Базовые (хранимые) vs Производные (вычисляемые).
Вводится ли значение извне или рассчитывается по формуле?
Простые (атомарные) и составные атрибуты
Простой атрибут
Не содержит составных частей, атомарен в контексте решаемой задачи:
- Оклад (число 75000.00);
- Объем_двигателя (2.4 л);
- Дата_рождения.
Составной атрибут
Может быть декомпозирован на независимые компоненты:
- ФИО → Фамилия, Имя, Отчество;
- Адрес → Индекс, Город, Улица, Номер дома;
- Паспорт → Серия, Номер, Кем выдан, Дата.
Однозначные и многозначные атрибуты
Однозначный атрибут
Имеет строго одно значение для конкретного экземпляра:
- ИНН организации;
- VIN-код автомобиля;
- Дата фактической выдачи заказа.
Многозначный атрибут
Может содержать список/набор значений:
- Авторы у книги (от 1 до 10 соавторов);
- Контактные телефоны у клиента;
- Категории водительских прав (B, C, CE).
Базовые (хранимые) и производные атрибуты
Базовый атрибут
Физически записывается на накопитель:
- Дата_заезда и Дата_выезда;
- Суточный_тариф отеля;
- Показания_одометра при выезде и возврате.
Производный атрибут
Вычисляется по формуле на лету:
- Количество_дней = Дата_выезда - Дата_заезда;
- Итого = Дней * Суточный_тариф;
- Пробег_за_рейс = Одометр_возврат - Одометр_выезд.
Понятие домена атрибута (Attribute Domain)
Домен — математически строгое множество всех допустимых значений атрибута в предметной области.
Технический тип данных SQL
Определяет только машинное представление битов:
Машина примет число -500 как корректный возраст.
Смысловой домен предметной области
Ограничивает значения законами реального мира:
Защищает базу от абсурдных и некорректных данных.
Спецификация ограничений домена
При концептуальном проектировании для каждого атрибута фиксируется 5 параметров домена:
1. Тип и длина
Символьный (VARCHAR), точный числовой (DECIMAL), дата (DATE).
2. Диапазон (Range)
CHECK (Оценка BETWEEN 2 AND 5)
3. Шаблон и маска
Регулярные выражения: телефон, e-mail, VIN, госномер.
4. Перечисление (ENUM)
Статусы заказа: 'Принят', 'В работе', 'Готов', 'Выдан'.
5. Определенность
NOT NULL (обязательно) или NULL (неизвестно).
Бизнес-правило
Проверка дат: Дата_выезда > Дата_заезда.
Потенциальные ключи (Candidate Keys)
Потенциальный ключ — минимальный набор атрибутов, однозначно идентифицирующий каждый экземпляр сущности.
Свойство 1: Уникальность
В любой момент времени в таблице не может существовать двух строк с одинаковым значением ключа.
Свойство 2: Неизбыточность (Минимальность)
Если из ключа убрать хотя бы одно поле, он потеряет свойство уникальности.
Пара (Паспорт + Фамилия) уникальна, но избыточна, так как Паспорт уже уникален сам по себе.
Выбор первичного ключа (Primary Key)
Из множества потенциальных ключей проектировщик выбирает один в качестве первичного (PK). Остальные становятся альтернативными (AK).
1. Краткость
Предпочтение отдается компактным числовым типам данных (4-8 байт) для ускорения B-Tree индексов.
2. Неизменяемость
Значение первичного ключа не должно изменяться на протяжении всей жизни объекта.
3. Простота связей
Первичный ключ мигрирует в дочерние таблицы как внешний ключ (Foreign Key).
Естественные vs Суррогатные ключи
Естественный ключ (Natural Key)
Идентификатор из реального мира (VIN авто, паспорт, ISBN книги):
- Понятен человеку без обращений к таблицам;
- Минус: Длинные строки замедляют JOIN и индексы;
- Риск: Замена паспорта или ошибка оператора требует каскадного обновления всей БД.
Суррогатный ключ (Surrogate Key)
Искусственный системный код (ID INT AUTO_INCREMENT):
- Компактен (4-8 байт), идеален для внешних ключей;
- Абсолютно стабилен во времени;
- Не зависит от смены регламентов и документов.
Карта типовых ошибок начинающего разработчика
1. Смешение класса и объекта
Создание отдельных сущностей «КамАЗ» и «Газель» вместо единой сущности «Автомобиль» со свойством «Модель».
2. Превращение свойства в таблицу
Создание отдельной пустой таблицы ради единственного поля «Цвет» без собственных характеристик.
3. Дублирование производных данных
Физическое хранение «Суммы» рядом с «Ценой» и «Количеством», приводящее к расхождению расчетов.
4. Составной ключ из ПДн
Использование паспортных данных в качестве первичного ключа во внешних связях.
Главное правило: строго валидируйте домены атрибутов!
