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

ОП.08 Основы проектирования баз данных — Занятие 13: Основные этапы проектирования БД

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

Формат: Урок с объяснением теории (2 академических часа)

Регламенты: Основной — 80 минут / Сокращенный — 60 минут

1. Дидактический паспорт занятия и методологическая концепция

Занятие №13 открывает фундаментальный раздел дисциплины «Тема 3. Этапы проектирования баз данных». Главная педагогическая цель — преодолеть типичную ошибку начинающих IT-специалистов («писать DDL и создавать таблицы наугад») и сформировать системное инженерное представление о полном жизненном цикле базы данных (Database Life Cycle — DBLC).

Обучающиеся должны усвоить четкую границу между уровнями абстракции ANSI/SPARC, понять назначение каждого из пяти этапов жизненного цикла, научиться идентифицировать входную первичную документацию и строго формализовать выходные артефакты каждого шага.

Ключевой методический принцип занятия: «Инженерная строгость каскада». Ни одна таблица не создается в СУБД, пока не завершена концептуальная модель предметной области и не формализована реляционная схема в 3-й нормальной форме.

2. Поминутный тайминг учебного занятия (80 и 60 минут)

Ниже приведено детальное сопоставление хронометража занятия для стандартного регламента (80 минут) и сокращенного режима (60 минут):

Структурный этап занятия	Регламент 80 мин	Регламент 60 мин	Методическое содержание и деятельность преподавателя
1. Организационный момент и мотивация	5 мин (00:00–00:05)	4 мин (00:00–00:04)	Приветствие, проверка готовности ПК и браузеров. Проблемный зачин: «Представьте, что бригада строителей начинает заливать фундамент многоэтажного здания без геологических изысканий и чертежей. Что произойдет со зданием? В IT-индустрии попытка сразу писать `CREATE TABLE` без DBLC приводит к аналогичному обрушению систем».
2. Актуализация опорных знаний	7 мин (00:05–00:12)	5 мин (00:04–00:09)	Фронтальный опрос по ранее изученным темам: сущности, атрибуты, связи (1:1, 1:N, M:N), нормальные формы (1НФ, 2НФ, 3НФ), логическая и физическая независимость данных. Подводка к понятию комплексного маршрута проектирования.
3. Изложение нового материала (DBLC)	38 мин (00:12–00:50)	28 мин (00:09–00:37)	Лекционная подача на базе слайдов 1–14 презентации: Концепция жизненного цикла базы данных (DBLC) и системный подход. Этап 1: Системный анализ и сбор требований (интервью, регламенты, ТЗ). Этап 2: Концептуальное проектирование (ER-диаграммы, независимость от СУБД). Этап 3: Логическое проектирование (трансляция в реляционную модель, 3НФ). Этап 4: Физическое проектирование (выбор СУБД, типы, B-Tree/GiST-индексы, партиции, RAID). Этап 5: Эксплуатация, администрирование, бэкапы (RPO/RTO) и мониторинг.
4. Первичное закрепление и разбор мема	10 мин (00:50–01:00)	8 мин (00:37–00:45)	Демонстрация слайда 15 с культовым комиксом xkcd №327 («Exploits of a Mom» / «Bobby Tables»). Дискуссия со студентами: на каком именно этапе проектирования должна закладываться защита от инъекций и проверка доменов (концептуальный/логический/физический)? Формулирование вывода о важности строгой типизации и параметризации.
5. Практическая работа с интерактивным листом	15 мин (01:00–01:15)	11 мин (00:45–00:56)	Обучающиеся открывают `zanyatie.html`, выбирают один из 4 отраслевых вариантов (аптечная сеть, каршеринг, маркетплейс, медицинская клиника), выполняют составление маршрутной карты проектирования, спецификацию входов/выходов и отвечают на проблемный вопрос. Преподаватель осуществляет индивидуальное тьюторское сопровождение.
6. Подведение итогов, рефлексия, ДЗ	5 мин (01:15–01:20)	4 мин (00:56–01:00)	Краткое резюме занятия. Самооценка студентов по 4-балльной шкале рубрики. Разъяснение регламента резервного домашнего задания (`domashnee_zadanie.html`) для пропустивших пару.

3. Фундаментальный разбор этапов жизненного цикла базы данных (DBLC)

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

Этап 1: Системный анализ и сбор требований

Цель этапа: Формализовать информационные потребности пользователей и функциональные границы будущей системы.
Входные данные: Первичные бумажные и электронные документы организации (накладные, рецепты, договоры, табели), нормативные акты (ГОСТ, 152-ФЗ, приказы министерств), регламенты бизнес-процессов, стенограммы интервью с ключевыми сотрудниками.
Выходные артефакты: Техническое задание (ТЗ) на разработку базы данных, словарь предметной области (глоссарий), матрица нефункциональных требований (SLA по времени отклика, прогнозируемый объем хранимых данных, требования к отказоустойчивости).
Критерий перехода (Gate): Согласование и утверждение ТЗ заказчиком (или ведущим аналитиком проекта).

Этап 2: Концептуальное (инфологическое) проектирование

Цель этапа: Построить независимое от программного обеспечения и СУБД семантическое представление предметной области.
Входные данные: Утвержденное ТЗ, функциональные требования, глоссарий терминов.
Выходные артефакты: Инфологическая ER-диаграмма (нотации Питера Чена, Мартина / «Воронья лапка» или UML Class Diagram), спецификация сущностей, атрибутов, типов связей (1:1, 1:N, M:N) и мощностей (кардинальностей).
Критерий перехода (Gate): Валидация модели с предметными экспертами (Domain Experts) — проверка отсутствия ложных связей и тупиковых сущностей.

Этап 3: Логическое (даталогическое) проектирование

Цель этапа: Преобразование инфологической модели в структуру конкретной модели данных (в контексте курса — реляционной) с устранением аномалий.
Входные данные: Концептуальная ER-диаграмма, правила трансляции сущностей и связей.
Выходные артефакты: Реляционная схема (набор отношений), первичные ключи (Primary Key), внешние ключи (Foreign Key), декларативные ограничения целостности (CHECK, NOT NULL, UNIQUE), доказательство нормализации отношений до уровня 3НФ / БКНФ (устранение транзитивных зависимостей). В аналитических системах (OLAP) — спецификация осознанной денормализации («Звезда», «Снежинка»).
Критерий перехода (Gate): Отсутствие аномалий модификации, удаления и вставки; формальное подтверждение достижения 3-й нормальной формы.

Этап 4: Физическое проектирование

Цель этапа: Привязка реляционной структуры к конкретной СУБД (PostgreSQL, MySQL, Oracle) и обеспечение максимальной производительности на целевом оборудовании.
Входные данные: Логическая схема отношений, профиль предполагаемой нагрузки (OLTP vs OLAP, соотношение Read/Write, пиковый TPS).
Выходные артефакты: Исполняемые DDL-скрипты на диалекте SQL целевой СУБД, стратегия индексирования (B-Tree, Hash, GiST/GIN, BRIN), схема горизонтального партиционирования (секционирования) больших таблиц, выделение дисковых табличных пространств (Tablespaces), настройки буферного пула и журналирования (WAL).
Критерий перехода (Gate): Успешное выполнение стресс-тестов и подтверждение соответствия SLA (например, отклик запроса < 100 мс).

Этап 5: Эксплуатация, администрирование и сопровождение

Цель этапа: Обеспечение непрерывной доступности, целостности, защиты и актуальности базы данных в производственной среде.
Входные данные: Развернутая база данных, поток эксплуатационных транзакций.
Выходные артефакты: Регламент и скрипты автоматического резервного копирования (полные, дифференциальные, инкрементальные) с гарантиями RPO (Recovery Point Objective) и RTO (Recovery Time Objective), схема репликации (Master-Slave / Multi-Master), журнал мониторинга медленных запросов (`pg_stat_statements`), регламент дефрагментации и сбора статистики (VACUUM ANALYZE).
Критерий перехода (Gate): Непрерывный цикл эксплуатации до планового вывода системы из эксплуатации (Decommissioning).

4. Педагогические приемы и разбор типичных ошибок обучающихся

Эффективные педагогические приемы занятия:

Прием «Разрыв цепочки»: Преподаватель намеренно предлагает студентам написать SQL-запрос к несуществующей базе без предварительного анализа требований («Создайте базу данных для автосалона прямо сейчас»). Студенты сразу сталкиваются с вопросами: «А нужны ли тест-драйвы?», «А как учитываются скидки?», «А что если у клиента два паспорта?». Этот прием мгновенно доказывает незаменимость этапа системного анализа.
Прием «Инженерный шлюз (Quality Gate)»: Приучение студентов к тому, что ни один артефакт следующего этапа не создается, пока не подписан выход предыдущего. Логическая схема не начинается без согласованного ERD; DDL не пишется без нормализации.
Прием «Культурный код IT»: Использование всемирно известного мема xkcd №327 для демонстрации того, что ошибки проектирования и пренебрежение ограничениями целостности разрушают информационные системы предприятий.

Типовые ошибки студентов и методы их нейтрализации:

Ошибка 1: Преждевременная физическая спецификация.
Студенты на этапе сбора требований или концептуальной схемы начинают указывать типы данных PostgreSQL: id SERIAL, name VARCHAR(255).
Методика исправления: Напомнить принцип абстракции ANSI/SPARC. Концептуальная модель должна быть понятна врачу, фармацевту или директору аптеки. Никаких «SERIAL» и «VARCHAR» в инфологической модели быть не может.

Ошибка 2: Смешение логического и физического уровней.
Студенты включают индексы, партиции и настройки серверов в логическую модель данных.
Методика исправления: Разграничить понятия: логический уровень отвечает на вопрос «ЧТО хранится и как логически связано?», а физический — «КАК это эффективно размещено на физических накопителях и обрабатывается ядром СУБД?».

Ошибка 3: Игнорирование регуляторных и бизнес-ограничений.
При проектировании базы клиники студенты забывают про 152-ФЗ, а при проектировании каршеринга — про SLA в 100 мс.
Методика исправления: Показать, что база данных создается не ради таблиц, а для обслуживания бизнес-процессов с жесткими внешними ограничениями.

5. Методика критериального оценивания

Оценивание индивидуальной работы студентов в интерактивном рабочем листе zanyatie.html осуществляется по 4-балльной шкале в соответствии с закрытой критериальной рубрикой (.rubrika.md):

2 балла — Безошибочная декомпозиция всех 5 этапов DBLC, указание целей, ролей и критериев перехода.
1 балл — Корректная спецификация входов, выходов и артефактов без смешения уровней абстракции.
1 балл — Глубокий учет отраслевой специфики выбранного варианта и аргументированный ответ на задачу самопроверки.

Итого максимальный результат занятия: 4 балла. Результат заносится в ведомость успеваемости обучающихся.