Сценарий учебного занятия (Конспект)

Преподаватель: «Здравствуйте, коллеги! Садитесь. Сегодня мы переходим к третьему фундаментальному разделу нашего курса — «Этапы проектирования баз данных». Тема нашего четырнадцатого занятия: «Концептуальное проектирование БД».

Давайте начнем с реальной производственной драмы. Представьте крупную дистрибьюторскую компанию. Два ключевых отдела — Бухгалтерия и Склад — решили автоматизировать учет. Бухгалтерия наняла программистов, которые создали базу с центральной сущностью Товар. Для бухгалтеров важны закупочная цена, ставка НДС и балансовый счет. В это же самое время Склад заказал собственную систему, где учет ведется по сущности Номенклатурная_единица с указанием габаритов коробки, веса и номера стеллажа. Спустя год руководство решает объединить обе базы в корпоративную ERP-систему. И тут проект останавливается на 9 месяцев, а компания теряет миллионы рублей. Разработчики не могут состыковать данные: накладные не сходятся со складскими остатками, отчеты выдают хаос.

В чем фундаментальная причина этого краха? Не в коде SQL и не в быстродействии серверов. Причина в том, что был полностью провален концептуальный этап проектирования: требования отделов собирались изолированно, а конфликты имен и структур не были выявлены и устранены до создания таблиц.

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

Преподаватель: «Вспомним классическую трехуровневую архитектуру ANSI/SPARC. Назовите три уровня абстракции данных и ответьте: чем концептуальный уровень принципиально отличается от физического? Даниил, пожалуйста».

Преподаватель: «Абсолютно верно! Концептуальная схема — это отражение объективной реальности бизнеса. Если мы заменим PostgreSQL на другую систему, концептуальная диаграмма сущностей и связей не изменится ни на йоту. А вот если бизнес изменит правила — например, разрешит одному клиенту иметь несколько договоров одновременно — изменится именно концептуальная модель».

Преподаватель: «В инженерной практике применяются четыре стратегии концептуального проектирования. Посмотрите на слайд 4.
1. Нисходящая стратегия (Top-Down): мы движемся от общего к частному. Сначала руководство описывает систему крупными мазками: "Предприятие", "Клиент", "Сделка". Затем каждая сущность расщепляется на подсущности. Плюс — системный охват. Минус — риск упустить мелкие детали первичной документации.
2. Восходящая стратегия (Bottom-Up): движение снизу вверх. Аналитик собирает бланки накладных, актов и группирует поля в сущности. Плюс — точное соответствие бумажным документам. Минус — в огромном количестве полей легко потерять общую архитектуру.
3. Стратегия "Внутри-наружу" (Inside-Out): выбирается главная стержневая сущность — например, "Заказ" в маркетплейсе, и схема прирастает смежными сущностями по радиусу.
4. Смешанная стратегия (Mixed): промышленный золотой стандарт. Сверху архитекторы задают общий каркас, а аналитики на местах собирают локальные модели отделов — так называемые User Views (локальные представления пользователей).

Почему нельзя опросить всех сразу одной анкетой? Потому что бухгалтера, кладовщика и логиста интересуют совершенно разные аспекты одного и того же физического процесса. Кладовщика не волнует ставка НДС, а бухгалтера не волнует высота паллеты. Поэтому строятся изолированные локальные схемы, которые затем подвергаются процедуре View Integration (интеграция представлений).

И вот здесь проектировщик неизбежно сталкивается с конфликтами интеграции. Запишите в конспекты три основные группы коллизий:
Первая группа — Именные конфликты:
• Синонимы: разные названия одного и того же объекта (например, Товар в бухгалтерии и Номенклатура на складе). Решение: согласование канонического имени в корпоративном глоссарии и слияние атрибутов без потерь.
• Омонимы: одинаковое название совершенно разных сущностей! Например, в гостинице слово Номер для службы бронирования — это комната (сущность с ценой и этажом), а для службы регистрации Номер — это номер телефона гостя (атрибут). Если их слить — система рухнет! Решение: строгая контекстная квалификация (Номер_комнаты и Телефон_гостя).
Вторая группа — Структурные конфликты:
• Сущность vs Атрибут: один отдел считает свойство простой строкой (например, Город клиента), а транспортный отдел учитывает тарифные зоны и почтовые индексы города. Правило: побеждает Сущность! Мы создаем сущность Город, а у клиента делаем связь.
• Конфликт кардинальностей связей: диспетчер считает, что машина закреплена за водителем 1:1, а механики знают, что водители подменяют друг друга на разных машинах (M:N). Правило: в глобальной схеме принимается более общее (менее строгое) правило — связь M:N через путевой лист.
Третья группа — Конфликты ограничений: несовпадение правил валидации, например, допустимость нулевой цены или обязательность поля СНИЛС».

Преподаватель: «Посмотрим, как это работает на практике. У нас есть представление Отдела продаж: сущности Заказ, Клиент, Продукция. И представление Склада: сущности Накладная_приемки, Номенклатура, Ячейка.

Шаг 1: Ищем соответствия. Продукция в продажах и Номенклатура на складе имеют одинаковый артикул производителя. Это явный синоним. Принимаем каноническое имя: Товар. Объединяем атрибуты: цену продажи берем из отдела сбыта, а весогабаритные характеристики — со склада.
Шаг 2: Анализируем связь между Заказом и Товаром. Один заказ может содержать много товаров, один товар входит во множество заказов — это связь M:N. Мы преобразуем ее в ассоциативную сущность Строка_заказа с собственным количеством и фактической ценой продажи.
В результате мы получаем единую непротиворечивую концептуальную модель, удовлетворяющую регламентам обоих департаментов».

Преподаватель: «Теперь каждый из вас выполнит интеграцию локальных представлений в интерактивном рабочем листе zanyatie.html. Введите свои реальные фамилию, имя и номер группы.
• 1-я парта — Вариант 1: Торговое предприятие (Бухгалтерия + Склад, синоним Товар/Номенклатура, партия как сущность);
• 2-я парта — Вариант 2: Гостиничный комплекс (Бронирование + Клининг, омоним Номер как комната vs Номер телефона);
• 3-я парта — Вариант 3: Университет (Учебный отдел + Общежитие, синонимы Студент/Жилец, комната);
• 4-я парта — Вариант 4: Автопредприятие (Диспетчерская + Ремонтная зона, конфликт типов связей 1:1 vs M:N).

Обратите внимание: данные сохраняются локально в вашем браузере. Вы должны выявить конфликты, описать резолюцию и построить глобальную концептуальную схему. Приступайте, я на связи по всем сложным вопросам».

Преподаватель: «Завершаем заполнение ответов. Взгляните на экран — слайд 15. Это культовый комикс Рэндалла Манро про «Маленького Бобби Таблицу» (Little Bobby Tables). Мама назвала сына именем Robert'); DROP TABLE Students;--, и когда школа внесла его в свою непродуманную базу, стерлись данные всех учеников за год.

Этот мем напоминает нам: фундамент безопасности и надежности закладывается на этапе концептуального проектирования. Если вы не определили границы сущности, не установили правила кардинальности и типы ограничений — никакие внешние фаерволы не спасут вашу базу от архитектурного коллапса.

Оценивание ваших решений сегодня проводится по 4-балльной рубрике: 2 балла за корректность глобальной схемы, 1 балл за правильное разрешение всех конфликтов интеграции и 1 балл за блок самопроверки.
Для тех, кто пропустил занятие или кому назначена индивидуальная отработка: на платформе выложен файл domashnee_zadanie.html. Это резервное задание: слияние двух локальных моделей транспортной компании. Напоминаю: резервное домашнее задание выполняют только те, кому оно назначено преподавателем. Срок сдачи — до следующей пары.
Спасибо за продуктивную инженерную работу, занятие окончено!».