Методическое руководство для преподавателя

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

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

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

Регламент времени: 2 академических часа (80 минут основной / 60 минут сокращенный)

Вид занятия: Урок с объяснением теории

1. Методическая концепция и целеполагание

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

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

Дидактические задачи занятия:

Обучающие:
- Изучить место концептуального этапа в жизненном цикле реляционных баз данных (по ГОСТ 34.601-90 и методологии ANSI/SPARC).
- Освоить классификацию стратегий проектирования: нисходящая (top-down), восходящая (bottom-up), анализ «внутри-наружу» (inside-out) и смешанная гибридная стратегия.
- Изучить методы вербализации пользовательских спецификаций: трансформацию интервью, регламентов и документации в семантические высказывания (сущности, атрибуты, кардинальности связей).
- Освоить архитектуру локальных представлений (User Views / subschemas) функциональных подразделений организации.
- Освоить систематическую классификацию конфликтов интеграции представлений: именные (синонимы, омонимы), структурные (сущность vs атрибут vs связь, несовпадение кардинальностей), конфликты ограничений целостности.
- Изучить пошаговый алгоритм разрешения каждого типа конфликта с сохранением семантической непротиворечивости глобальной схемы.
Развивающие:
- Развивать системное аналитическое мышление при интеграции нестыкующихся требований различных отделов компании.
- Формировать инженерную культуру абстрагирования от деталей реализации (не подменять концептуальную сущность SQL-таблицей на этапе инфологического анализа).
- Вырабатывать навыки строгого доказательства эквивалентности и полноты объединения схем.
Воспитательные:
- Воспитывать профессиональную коммуникативную этику при работе с пользователями-заказчиками.
- Формировать ответственность за предотвращение рисков системного кризиса при внедрении корпоративных информационных систем.

2. Детальный хронометраж и сценарии занятия (80 и 60 минут)

В зависимости от расписания учебной части СИЭУиП занятие реализуется в одном из двух регламентов. Сокращение времени в 60-минутном сценарии достигается за счет уплотнения разбора вводных опросов и переноса части аналитических упражнений в экспресс-формат фронтальной дискуссии без ущерба для сквозной отработки интеграции представлений.

Этап занятия	Основной (80 мин)	Сокращенный (60 мин)	Содержание и дидактические акценты
1. Оргмомент и мотивация	5 мин	3 мин	Приветствие, проверка готовности. Проблемный производственный кейс: «Два отдела — Бухгалтерия и Склад — заказали независимые базы. Бухгалтерия оперирует сущностью "Товар" с ценой закупки, а Склад — "Номенклатурой" с габаритами ячейки. При попытке слить системы ERP-проект завис на 9 месяцев. Почему?». Формулирование темы и цели.
2. Актуализация опорных знаний	8 мин	5 мин	Фронтальный блиц-опрос: концептуальный vs логический vs физический уровни архитектуры ANSI/SPARC; базовые семантические конструкции ER: сущность, экземпляр сущности, атрибут, кардинальность связей (1:1, 1:N, M:N). Границы применимости инфологической модели.
3. Изложение теоретического ядра	32 мин	27 мин	Фундаментальная лекция с интерактивным сопровождением: • Стратегии концептуального проектирования (Top-down, Bottom-up, Mixed). • Сбор требований, вербализация предметной области, правила бизнес-логики. • Концепция User Views (локальных представлений) и мотивы их изоляции. • Классификация конфликтов: именные (синонимия, омонимия), структурные (сущность-атрибут, сущность-связь, расхождение кардинальностей), конфликты ограничений. • Пошаговый алгоритм слияния представлений в глобальную схему.
4. Демонстрация сквозного кейса интеграции	12 мин	10 мин	Преподаватель на доске/слайде демонстрирует объединение локальной схемы Отдела сбыта и Складского учета: обнаружение синонима (`Товар` = `Номенклатурная_единица`), разрешение омонима `Код`, устранение избыточной связи M:N через сущность `Строка_накладной`.
5. Первичное закрепление и экспресс-практикум	15 мин	11 мин	Работа студентов с интерактивным рабочим листом `zanyatie.html` по 4 вариантам. Анализ локальных представлений предметных областей, построение матрицы соответствия атрибутов, формулировка резолюций устранения конфликтов.
6. Экспертный разбор ошибок и рефлексия	5 мин	3 мин	Разбор типичных ошибочных решений студентов. Демонстрация тематического слайда 15 с мемом (Little Bobby Tables) как напоминание о значении строгости моделирования. Подведение итогов, критерии оценивания, инструктаж по резервному ДЗ.
ИТОГО	80 мин	60 мин	Задачи занятия решены в полном объеме

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

3.1. Стратегии проектирования баз данных

В теории проектирования информационных систем выделяют четыре классические стратегии построения концептуальных схем:

1. Нисходящая стратегия (Top-Down)

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

Преимущества: Глобальный системный охват, исключение дублирования концепций на ранних этапах.

Ограничения: Риск упустить критически важные прикладные детали первичных документов.

2. Восходящая стратегия (Bottom-Up)

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

Преимущества: Полная гарантия соответствия существующему документообороту предприятия.

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

3. Стратегия «внутри-наружу» (Inside-Out)

Разновидность восходящей стратегии: проектировщик сначала выделяет несколько центральных базовых сущностей предприятия (например, «Заказ», «Деталь»), а затем постепенно расширяет схему «кругами», присоединяя смежные периферийные концепции.

Преимущества: Быстрый запуск прототипа для ключевого бизнес-процесса.

4. Смешанная стратегия (Mixed Strategy) — Промышленный стандарт

Сочетает нисходящий и восходящий подходы: на верхнем уровне руководство компании и архитекторы формулируют укрупненную системную модель (Top-Down), а на уровне подразделений параллельно строятся локальные представления пользователей (User Views) на основе детальных форм и регламентов (Bottom-Up). Далее выполняется их гармонизация и слияние (View Integration).

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

Вербализация требований — это трансформация слабоструктурированных словесных описаний бизнес-процессов в структурированные семантические предикаты. Преподаватель должен подчеркнуть правила лингвистического анализа технического задания:

Имена существительные в единственном числе чаще всего инкапсулируют кандидаты в Сущности (Студент, Преподаватель, Аудитория, Накладная) либо Атрибуты (Фамилия, Стоимость, Номер_телефона).
Глаголы и глагольные обороты отображаются в Связи между сущностями (Студент сдает Экзамен, Преподаватель ведет Дисциплину, Склад отгружает Партию).
Количественные числительные и наречия кратности («строго один», «не более одного», «любое количество», «хотя бы один») определяют минимальную и максимальную кардинальность (мощность) связей.
Прилагательные и причастия выражают состояния и статусы сущностей (активный, архивный, оплаченный) либо классификационные категории.

3.3. Архитектура локальных представлений (User Views)

В крупной корпоративной системе невозможно создать единую концептуальную схему одномоментно одним аналитиком. Различные департаменты видят предметную область через призму собственных бизнес-задач:

Отдел кадров: сотрудник — это штатная единица с табельным номером, окладом, паспортом и трудовым стажем. Заказы клиентов кадры не интересуют.
Отдел продаж: сотрудник — это менеджер сделки с планом продаж и процентом бонуса. Паспортные данные кадрового учета менеджеру продаж недоступны и избыточны.
Бухгалтерия: сотрудник — это субъект начисления зарплаты, удержания НДФЛ и перечисления страховых взносов.

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

3.4. Классификация и методы разрешения конфликтов интеграции

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

1. Именные конфликты (Naming Conflicts)

Тип конфликта	Пример в предметной области	Методология разрешения
Синонимы (Synonyms) Разные имена обозначают один и тот же концепт	В Бухгалтерии сущность называется `Товар`, а на Складе — `Номенклатурная_единица`. В Деканате — `Студент`, в Общежитии — `Жилец`.	Создание корпоративного словаря данных (Data Dictionary / Business Glossary). Согласование единого канонического имени сущности на уровне всей организации (например, `Товар`), при этом в локальных интерфейсах сохраняются синонимичные алиасы.
Омонимы (Homonyms) Одно и то же имя обозначает разные концепты	В Службе бронирования отеля `Номер` означает комнату/апартамент (сущность), а в Службе ресепшен `Номер` — это номер телефона гостя (атрибут). В Автопарке `Номер` — гос. рег. знак автомобиля vs табельный номер шофера.	Переименование с введением явного контекстного префикса или семантического квалификатора: `Комната_номер` vs `Телефон_гостя`, `Гос_номер_ТС` vs `Табельный_номер_водителя`.

2. Структурные конфликты (Structural Conflicts)

Конфликт «Сущность vs Атрибут»: Один отдел рассматривает объект как простой атрибут (например, Отдел продаж указывает у Клиента атрибут Город текстовой строкой), а Отдел логистики считает Город полноценной сущностью со свойствами Тарифная_зона, Почтовый_индекс, Удаленность_км.
Решение: Выбор более богатого семантического представления — объект возводится в статус независимой Сущности, а исходный атрибут преобразуется во внешний идентификатор (связь).
Конфликт «Сущность vs Связь»: В локальной схеме А связь между Врачом и Пациентом смоделирована как бинарная связь M:N «лечит». В локальной схеме Б тот же факт оформлен как сущность История_болезни с собственными атрибутами (Дата_открытия, Диагноз, Палата).
Решение: Трансформация бинарной связи в слабую/ассоциативную сущность (Reification / объектификация связи).
Конфликт кардинальностей (мощности связей): Для отдела кадров связь «Сотрудник — Отдел» является строго 1:N (сотрудник числится ровно в одном отделе), а для Отдела проектного менеджмента — M:N (специалист может привлекаться к нескольким проектам/отделам одновременно).
Решение: Принятие более общего (менее строгого) правила кардинальности (M:N) в глобальной схеме, либо введение механизма основного и совмещаемого подразделений.

3. Конфликты ограничений (Constraint Conflicts)

Возникают при несовпадении бизнес-правил и диапазонов допустимых значений атрибутов в разных отделах. Например, Бухгалтерия допускает нулевую стоимость для промо-образцов продукции (CHECK (Цена >= 0)), а Отдел ценообразования требует строгой положительности (CHECK (Цена > 0)). Решается гармонизацией регламентов предприятия на уровне совместного протокола согласования.

4. Типовые ошибки студентов и педагогические приемы

Типовая ошибка студента	В чем проявляется дефект	Педагогический прием преподавателя
«Преждевременный SQL» (Physical Bias)	Студент вместо выделения сущностей и смысловых связей сразу начинает писать типы `INT`, `VARCHAR(50)` и объявлять `FOREIGN KEY` на концептуальной схеме.	«Метод отчуждения СУБД»: спросить студента, как изменится его схема, если заказчик решит хранить данные в графовой базе Neo4j или документах JSON? Подчеркнуть, что концептуальная модель отражает объективную реальность предприятия, а не байты на диске.
Слияние синонимов без анализа состава атрибутов	Студент видит синонимы `Товар` и `Номенклатура`, механически удаляет одну сущность и теряет специфические атрибуты складского учета (габариты ячейки, температурный режим).	Прием «Матрица соответствия свойств»: обязать студента перед объединением составить таблицу сопоставления всех атрибутов двух сущностей и явно решить судьбу каждого непересекающегося поля.
Игнорирование омонимии («Ложная дружба слов»)	Студент объединяет номер телефона клиента и номер гостиничной комнаты в единый атрибут `Номер`, полагая, что раз слова одинаковые, это одна сущность.	Контрпример «Парадокс выборки»: предложить написать гипотетический запрос: «Найти всех жильцов в Номере 105». Будут получены люди с номером телефона 105? Показать абсурдность слияния омонимов.
Разрушение кардинальности 1:N в M:N	Студент бездумно связывает все сущности связями «многие-ко-многим», избегая анализа строгих регламентов предприятия.	Вопрос на проверку крайних случаев: «Может ли один паспорт принадлежать двум гражданам? Может ли автомобиль одновременно находиться в двух независимых рейсах в разных городах?».