Концептуальное проектирование БД

1. Место инфологического уровня в модели ANSI/SPARC

        Концептуальное (инфологическое) проектирование — стадия формализации предметной области, не зависящая от целевой СУБД, аппаратной платформы и физических структур хранения.
      

1. Внешний уровень (User Views)

Индивидуальные представления подразделений (Бухгалтерия, Склад, Отдел продаж, Диспетчерская).

2. Концептуальный уровень

Единая глобальная семантическая модель всей организации (сущности, атрибуты, связи, бизнес-правила).

3. Внутренний уровень

Физическое хранилище СУБД (таблицы, индексы, B-Tree, партиции, файлы ОС).

2. Главные цели концептуального моделирования

Адекватность: Точное и полное отражение информационных потребностей всех категорий пользователей без потерь бизнес-логики.
Независимость от СУБД: Схема строится в терминах сущностей и связей, а не таблиц SQL, что позволяет сменить СУБД без перепроектирования логики.
Непротиворечивость: Устранение дублирования фактов, согласование терминологии между отделами компании.
Масштабируемость: Возможность безболезненного добавления новых функциональных модулей без ломки базового ядра.

        Принцип: Ошибка в концептуальной модели на этапе кодинга стоит в 50–100 раз дороже, чем во время предпроектного анализа!
      

3. Стратегии концептуального проектирования

Нисходящая (Top-Down)

От обобщенных сущностей («Компания», «Договор») к их декомпозиции и атрибутам. Идеальна для стратегического планирования.

Восходящая (Bottom-Up)

От первичных реквизитов накладных и бланков к группировке в сущности. Гарантирует покрытие текущих печатных форм.

«Внутри-наружу» (Inside-Out)

От центральной стержневой сущности («Заказ») к радиальному наращиванию периферии.

Смешанная (Mixed Strategy)

Корпоративный стандарт: глобальный нисходящий каркас + восходящая интеграция локальных представлений (User Views).

4. Вербализация требований пользователей

Перевод слабоструктурированной речи заказчика в строгие концептуальные конструкции:

Лингвистические маркеры

Существительные (Студент, Заказ, Комната) → Сущности.
Характеристики существительных (Оклад, Дата, Номер) → Атрибуты.
Глаголы (оплачивает, проживает, ремонтирует) → Связи.
Количественные наречия (строго один, много) → Кардинальность связей.

Пример вербализации

«Каждый студент проживает ровно в одной комнате, при этом в одной комнате могут размещаться от 1 до 4 студентов».

[Студент] (1,1) ──проживает── (1,4) [Комната]

5. Локальные концептуальные представления (User Views)

В реальной компании один аналитик не может опросить всех сотрудников одновременно. Анализ декомпозируется по функциональным отделам:

Представление Бухгалтерии

Фокус на проводках, взаиморасчетах и счетах-фактурах. Товар рассматривается через призму себестоимости и ставки НДС.

Представление Склада

Фокус на физических ячейках, стеллажах, габаритах, весогабаритных характеристиках и сроках годности партий.

Представление Отдела продаж

Фокус на клиентах, воронке сделок, скидках, менеджерах и контактных персонах.

        Каждое подразделение формирует автономную локальную схему (User View). Итог — необходимость процедуры View Integration.
      

6. Алгоритм слияния представлений (View Integration)

Идентификация общих концепций: Сопоставление словарей сущностей и атрибутов из различных подразделений.
Классификация конфликтов: Поиск именных, структурных противоречий и расхождений ограничений.
Разрешение коллизий: Гармонизация имен, повышение статуса атрибутов до сущностей, обобщение кардинальностей.
Синтез глобальной концептуальной модели: Объединение графов сущностей в единую схему.
Очистка избыточности: Устранение дублирующих связей и транзитивных путей.

7. Именные конфликты: Проблема синонимов

        Синонимы: Разные названия одной и той же сущности или атрибута в разных подразделениях.
      

Примеры в жизни

Бухгалтерия: Товар vs Склад: Номенклатура
Деканат: Студент vs Общежитие: Жилец
Диспетчерская: Машина vs Ремзона: Транспортное_средство

Методология устранения

Утвердить каноническое имя в глобальной схеме.
Составить матрицу атрибутов и объединить непересекающиеся свойства в одну сущность.
Сохранить локальные имена как псевдонимы (алиасы) для пользовательских интерфейсов.

8. Именные конфликты: Проблема омонимов

        Омонимы: Одно и то же словесное наименование обозначает принципиально разные объекты предметной области!
      

Опасные коллизии

В отеле термин Номер обозначает:

В Бронировании: жилая комната (апартаменты) со свойствами «категория», «этаж», «цена».
В Анкете клиента: телефонный номер (строка для связи).

Инженерное решение

Механическое слияние запрещено!

Вводятся явные семантические квалификаторы:

• Комната_номер (Сущность)
• Телефон_гостя (Атрибут)
• Табельный_номер_водителя
• Гос_номер_автомобиля

9. Структурный конфликт: Сущность vs Атрибут

Один отдел считает свойство тривиальным текстовым полем, а другой ведет по нему детальный учет:

Отдел продаж: [Клиент] ──(атрибут: Город_проживания VARCHAR) Отдел логистики: [Город] (Город_ID, Название, Тарифная_зона, Индекс_хаба, Срок_доставки_дней)

        Золотое правило: «При конфликте "Сущность vs Атрибут" побеждает Сущность!». В глобальной схеме создается независимая сущность, а простой атрибут заменяется связью 1:N.
      

10. Структурный конфликт: Сущность vs Связь

Бинарная связь M:N

Простое сопоставление сущностей без сохранения исторического контекста:

[Врач] ──лечит── [Пациент]

Ассоциативная сущность

Факт взаимодействия сам обладает богатым набором атрибутов:

[Прием_врача] (Дата, Жалобы, Назначение, Стоимость)

Резолюция: Процедура объектификации связи (Reification). Связь наделяется собственным идентификатором и атрибутами времени/состояния.

11. Конфликты мощности (кардинальности) связей

        При несовпадении предположений отделов о кратности связей в глобальной модели всегда принимается наименее жесткое (более общее) правило!
      

Локальный вид А	Локальный вид Б	Глобальное решение
Связь 1:1 (Сотрудник-Проект)	Связь 1:N (Сотрудник-Проекты)	Принимается 1:N (один сотрудник может вести несколько проектов)
Связь 1:N (Водитель-Машина)	Связь M:N (Сменные графики)	Принимается M:N через путевой лист с указанием смены

12. Конфликты ограничений целостности

Расхождения в допустимых бизнес-правилах между подразделениями:

Разрешение конфликта диапазонов

Бухгалтерия допускает нулевую стоимость образцов (Цена >= 0), а Отдел продаж требует Цена > 0.

Решение: Введение классификатора типа операции («Продажа» vs «Маркетинговая раздача»).

Разрешение конфликта обязательности

Отдел кадров требует обязательный СНИЛС при приеме на работу, а Служба безопасности заводит временный пропуск без СНИЛС.

Решение: Ослабление обязательности на базовом уровне с контролем в кадровом бизнес-процессе.

13. Чек-лист проверки концептуальной модели

Проверен ли корпоративный глоссарий? Выявлены ли все скрытые синонимы и устранены ли омонимы?
Нет ли потерянных атрибутов? При объединении сущностей все специфические поля подразделений включены в схему?
Устранены ли конфликты детализации? Все атрибуты с внутренней структурой преобразованы в сущности?
Проверены ли кардинальности? Заложены ли связи с запасом на расширение бизнес-процессов компании?
Очищена ли модель от транзитивных связей? Устранены ли треугольные циклические зависимости?

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