Теоретический конспект студента

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

Дисциплина: ОП.08 Основы проектирования баз данных | СИЭУиП

Тематический раздел: Тема 3. Этапы проектирования баз данных (§2.2 с.7 программы)

Ключевая тема: Концептуальное инфологическое моделирование, интеграция локальных представлений (User Views) и устранение конфликтов проектирования

1. Место концептуального проектирования в жизненном цикле БД

Проектирование базы данных — это многоэтапный инженерный процесс преобразования неформализованных требований заказчика в оптимизированные структуры хранения СУБД. В соответствии с классической трехуровневой архитектурой ANSI/SPARC проектирование делится на три базовые стадии:

┌─────────────────────────────────────────────────────────────────────────┐ │ ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ │ └─────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ 1. КОНЦЕПТУАЛЬНОЕ (ИНФОЛОГИЧЕСКОЕ) ПРОЕКТИРОВАНИЕ │ │ • Анализ предметной области и интервью пользователей │ │ • Сбор локальных представлений (User Views) │ │ • Интеграция представлений и разрешение конфликтов │ │ • Итог: Глобальная ER-диаграмма, не зависящая от типа СУБД │ └─────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ 2. ЛОГИЧЕСКОЕ (ДАТАЛОГИЧЕСКОЕ) ПРОЕКТИРОВАНИЕ │ │ • Отображение ER-схемы в реляционную модель таблиц │ │ • Нормализация отношений (1NF → 2NF → 3NF / BCNF) │ │ • Определение первичных и внешних ключей │ └─────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ 3. ФИЗИЧЕСКОЕ ПРОЕКТИРОВАНИЕ │ │ • Привязка к конкретной СУБД (PostgreSQL, Oracle, MySQL) │ │ • DDL-скрипты, типы данных, индексы (B-Tree, GIN), шардирование │ └─────────────────────────────────────────────────────────────────────────┘

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

2. Стратегии проектирования: от идеи к глобальной схеме

Как подойти к созданию концептуальной схемы, когда перед проектировщиком крупное предприятие с десятками отделов и сотнями регламентов? В инженерной практике применяются 4 фундаментальные стратегии:

Стратегия	Принцип работы	Сфера применения и риски
Нисходящая (Top-Down)	Движение «от общего к частному»: сначала определяются укрупненные концепции («Предприятие», «Клиент», «Договор»), затем они пошагово расщепляются на составные подсущности с детализацией атрибутов.	Идеальна на этапе предпроектного обследования для согласования видения с высшим руководством. Риск: можно упустить тонкие прикладные нюансы реального документооборота.
Восходящая (Bottom-Up)	Движение «от частного к общему»: сбор всех элементарных реквизитов первичных документов (счетов, накладных, ведомостей) и группировка их в сущности на основе семантической близости.	Применяется при жестко регламентированном учете. Риск: при сотнях атрибутов аналитик тонет в частностях и теряет целостность картины.
«Внутри-наружу» (Inside-Out)	Выбирается центральная, наиболее понятная сущность («Заказ» в интернет-магазине), после чего схема наращивается по радиусу смежными объектами («Товар», «Оплата», «Доставка»).	Хорошо для быстрого создания MVP ключевого бизнес-процесса.
Смешанная (Mixed Strategy)	Золотой стандарт индустрии: сочетание нисходящего каркаса на уровне топ-менеджмента и параллельного восходящего анализа локальных представлений (User Views) в функциональных подразделениях.	Позволяет масштабировать проектирование: разные аналитики обследуют разные отделы, после чего их модели объединяются (View Integration).

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

Каждое функциональное подразделение видит деятельность предприятия по-своему. Рассмотрим классический пример торговой компании:

Локальное представление №1: Бухгалтерия

Бухгалтерию волнуют финансовые проводки, взаиморасчеты и документы:

Сущность Товар: Код_товара, Наименование, Цена_закупки, Ставка_НДС.
Сущность Накладная: Номер_документа, Дата_выписки, Контрагент.
Сущность Оплата: Номер_платежки, Сумма, Статус_банка.

Локальное представление №2: Склад

Склад интересует логистика, физическое размещение и партии:

Сущность Номенклатура: Артикул, Название, Вес_брутто, Объем_м3.
Сущность Ячейка_хранения: Ряд, Стеллаж, Полка, Макс_нагрузка.
Сущность Партия: Номер_партии, Дата_приемки, Срок_годности.

Пошаговая блок-схема процесса интеграции локальных представлений

┌─────────────────────────────────────────────────────────────────────────┐ │ ЭТАП 1. ИДЕНТИФИКАЦИЯ СООТВЕТСТВИЙ │ │ Поиск общих семантических концепций между представлением А и Б │ │ Сравнение описаний, списков атрибутов и бизнес-контекста │ └─────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ ЭТАП 2. ВЫЯВЛЕНИЕ КОНФЛИКТОВ И РАСХОЖДЕНИЙ │ │ • Именные конфликты (Синонимы? Омонимы?) │ │ • Структурные коллизии (Сущность vs Атрибут? Кардинальность связей?) │ │ • Конфликты ограничений (Диапазоны значений, обязательность полей) │ └─────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ ЭТАП 3. ПРИНЯТИЕ РЕЗОЛЮЦИИ И ТРАНСФОРМАЦИЯ МОДЕЛЕЙ │ │ • Выбор единого канонического имени по корпоративному словарю │ │ • Повышение статуса атрибута до сущности (при несовпадении детализации) │ │ • Выбор наиболее общего правила мощности связей (1:N → M:N) │ └─────────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────────┐ │ ЭТАП 4. ФОРМИРОВАНИЕ ГЛОБАЛЬНОЙ КОНЦЕПТУАЛЬНОЙ СХЕМЫ │ │ Объединение непересекающихся сущностей, слияние согласованных сущностей │ │ Устранение транзитивной семантической избыточности │ └─────────────────────────────────────────────────────────────────────────┘

4. Разрешение конфликтов интеграции: наглядные примеры

4.1. Разрешение именных конфликтов

Пример 1: Конфликт синонимов (Synonym Conflict)

В Бухгалтерии объект назван Товар, а на Складе тот же физический объект называется Номенклатура.

Бухгалтерия: [Товар] (Код_товара, Название, Цена_закупки, Ставка_НДС) Склад: [Номенклатура] (Артикул, Наименование, Вес_брутто, Объем_м3) РАЗРЕШЕНИЕ: 1. Фиксируем синонимию: Товар == Номенклатура (один физический объект). 2. Выбираем каноническое наименование: Товар. 3. Объединяем наборы атрибутов: [Товар] (Товар_ID PK, Артикул UNIQUE, Наименование, Цена_закупки, Ставка_НДС, Вес_брутто, Объем_м3)

Пример 2: Конфликт омонимов (Homonym Conflict)

В Гостиничном комплексе в Службе бронирования есть термин Номер (жилая комната), а в Анкете гостя есть атрибут Номер (номер мобильного телефона).

Бронирование: [Номер] (Номер_ID, Категория, Этаж, Стоимость_суток) --> Сущность Клиенты: [Гость] (Гость_ID, ФИО, Номер) --> Атрибут РАЗРЕШЕНИЕ: Смысл разный! Механическое слияние недопустимо! Вводим контекстные квалификаторы: • Сущность комнаты переименовывается в [Номер_комнаты] (или [Гостиничный_номер]). • Атрибут гостя явно квалифицируется как Телефон_гостя.

4.2. Разрешение структурных конфликтов

Пример 3: Конфликт «Сущность vs Атрибут»

В представлении Бухгалтерии поставка описывается атрибутом Партия_товара (строка с номером партии). В представлении Склада Партия — это критически важная сущность со сроком годности, сертификатом качества и условиями хранения.

Бухгалтерия: [Накладная] ---> (Номер_партии как текстовый атрибут) Склад: [Партия] (Партия_ID, Дата_выпуска, Срок_годности, Сертификат_соответствия) РАЗРЕШЕНИЕ: Правило: «При конфликте сущность vs атрибут побеждает Сущность!». В глобальной схеме Партия сохраняется как полноценная Сущность [Партия]. В [Накладной] атрибут преобразуется в связь с сущностью [Партия].

Пример 4: Конфликт типов связей (кардинальностей)

В Диспетчерской автопарка считают, что Водитель закреплен строго за одним Автомобилем (1:1). В Ремонтной зоне механики знают, что один Водитель при поломке пересаживается на дежурные машины, а одну машину в разные смены водят разные шоферы (M:N).

Диспетчерская: [Водитель] ──(1:1)── [Автомобиль] Ремонтная зона: [Водитель] ──(M:N)── [Автомобиль] РАЗРЕШЕНИЕ: Правило: «В глобальной схеме принимается более общее (менее ограничительное) правило». Связь принимается как M:N. Для учета истории смен вводится ассоциативная сущность [Смена_водителя] или [Путевой_лист] с атрибутами (Дата_выезда, Время_смены, Показания_одометра).

5. Вопросы для самопроверки студентов

1. Почему концептуальное проектирование называют «инфологическим»?

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

2. Чем отличается конфликт синонимов от конфликта омонимов?

Синонимы — это разные названия одного и того же объекта (Товар и Номенклатура), их необходимо объединить под одним каноническим именем. Омонимы — это одинаковые названия совершенно разных объектов (Номер комнаты и Номер телефона), их необходимо строго разделить и переименовать с уточняющими префиксами.

3. Какое решение принимается, если один отдел считает объект атрибутом, а второй — сущностью?

Объект всегда повышается до статуса полноценной сущности, чтобы сохранить все детализированные свойства, необходимые второму отделу. В первой структуре создается связь со вновь выделенной сущностью.

4. В чем преимущество смешанной стратегии (Mixed Strategy) перед нисходящей?

Смешанная стратегия позволяет распараллелить работу аналитиков по отделам компании, собирать реальные требования из документов (User Views) и одновременно удерживать общую системную архитектуру предприятия.