Развернутый сценарий занятия (Конспект)

Прямая речь преподавателя: «Здравствуйте, коллеги! Садитесь. Проверьте готовность компьютеров к работе.

Сегодня мы открываем ключевой раздел нашего курса: «Тема 3. Этапы проектирования баз данных», и тема нашего тринадцатого занятия звучит так: «Основные этапы проектирования БД».

Давайте начнем с парадоксального вопроса. Представьте, что опытной строительной бригаде поручили построить 16-этажный жилой комплекс. И прораб говорит рабочим: "Зачем нам проектное бюро, архитектурные чертежи и геологические изыскания грунта? Давайте сразу заливать бетон и класть кирпич под планировку, которую вчера набросал заказчик на салфетке!". Что произойдет с этим зданием?

Правильно: оно даст трещину при возведении третьего этажа и рухнет. Но удивительно то, что в IT-индустрии начинающие разработчики поступают ровно так же! Они открывают pgAdmin, пишут CREATE TABLE и начинают набивать поля, которые видят прямо сейчас на экране мобильного приложения. Через месяц бизнес меняется, данные двоятся, база виснет, а при удалении клиента исчезают все его оплаченные заказы.

Сегодня мы изучим системный инженерный маршрут — жизненный цикл базы данных (DBLC). Мы разберем, почему создание БД делится строго на 5 этапов, какие входные документы нужны для каждого шага, какие выходные артефакты рождаются и по каким строгим критериям инженер имеет право перейти к следующей фазе. Работать будем по 4-балльной критериальной шкале».

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

Вопрос группе: Назовите три уровня классической архитектуры ANSI/SPARC. Кто помнит?
[Студенты отвечают: внешний, концептуальный, внутренний/физический].

Прекрасно! А в чем суть принципа логической и физической независимости данных?
[Студенты: изменение способа хранения на диске не должно ломать логическую схему, а изменение схемы — не должно ломать пользовательские интерфейсы].

Именно так! Если администратор перенес таблицу с HDD на быстрый NVMe-накопитель или построил новый индекс B-Tree, прикладной SQL-запрос бухгалтера не должен измениться ни на один символ. Архитектура жизненного цикла БД как раз и воплощает эти принципы разделения ответственности».

Прямая речь преподавателя (Слайды 3–5): «Посмотрите на слайд 3. Полный жизненный цикл базы данных (DBLC) включает 5 основных стадий:
1. Системный анализ и сбор требований.
2. Концептуальное (инфологическое) проектирование.
3. Логическое (даталогическое) проектирование.
4. Физическое проектирование и реализация.
5. Эксплуатация, администрирование и сопровождение.

Разбираем Этап 1: Системный анализ.
Что является входом этого этапа? Инженер не придумывает данные из головы. Входом служат первичные документы организации: накладные поставщиков, кассовые чеки, амбулаторные карты пациентов, рецептурные бланки. Плюс регуляторные законы — например, Федеральный закон №152-ФЗ "О персональных данных".

Выходным артефактом первого этапа является Техническое задание (ТЗ) на проектирование БД и спецификация нефункциональных требований (SLA по времени отклика, прогнозируемый объем хранимых гигабайт). Критерий перехода (Quality Gate) здесь один — официальное согласование и подписание ТЗ обеими сторонами. Пока ТЗ не подписано, рисовать структуры бессмысленно».

Прямая речь преподавателя (Слайды 6–8): «Переходим к Этапу 2: Концептуальное проектирование.
Запомните важнейшее правило: концептуальная модель АБСОЛЮТНО независима от СУБД! На этом этапе нет никаких PostgreSQL, типов данных VARCHAR или INT, и уж тем более нет дисковых индексов.
Инструмент этого этапа — инфологическая ER-модель (диаграмма "Сущность-Связь"). Мы выделяем классы сущностей реального мира (например: Аптека, Лекарство, Врач, Рецепт) и определяем тип связей между ними: один-к-одному, один-ко-многим или многие-ко-многим.

Этап 3: Логическое проектирование.
Вот здесь мы уже выбираем семейство моделей — в нашем случае реляционную модель. Каждая сущность становится отношением (таблицей). Связи "многие-ко-многим" расщепляются созданием вспомогательной таблицы связи с составным ключом.
Здесь же мы проводим процедуру нормализации: 1НФ (атомарность полей), 2НФ (полная зависимость от первичного ключа), 3НФ (устранение транзитивных зависимостей).
Обратите внимание на слайд 8: в аналитических системах (OLAP / DWH) на логическом этапе мы, наоборот, идем на осознанную денормализацию (схемы "Звезда" и "Снежинка"). Почему? Потому что в аналитике нам нужно мгновенно читать и агрегировать миллионы строк кликстрима, а лишние JOIN замедляют систему в разы!».

Прямая речь преподавателя (Слайды 9–13): «Этап 4: Физическое проектирование.
Теперь мы привязываемся к конкретной выбранной СУБД — например, PostgreSQL 16. Мы формируем DDL-скрипты, подбираем оптимальные типы данных для экономии ОЗУ и диска, строим B-Tree индексы для поиска и GiST-индексы для координат каршеринга. Для огромных таблиц чеков или телеметрии мы проектируем горизонтальное партиционирование по диапазонам дат.
Для медицинских систем именно на физическом уровне настраивается шифрование дисков (TDE) и партиционированный журнал аудита обращений.

Этап 5: Эксплуатация и сопровождение.
База развернута в проде. Теперь главные задачи инженера — администрирование, обеспечение RPO (Recovery Point Objective — допустимая потеря данных во времени) и RTO (Recovery Time Objective — допустимое время восстановления сервиса) через настройку инкрементальных бэкапов, репликации и мониторинга медленных запросов».

Прямая речь преподавателя: «Коллеги, посмотрите на слайд 15. Это самый знаменитый мем в истории информационных технологий — комикс Рэндалла Манро xkcd №327 "Exploits of a Mom", известный как "Маленький Бобби Таблицы".

Школа звонит маме: "У вас действительно сына зовут Роберт'); DROP TABLE Students;-- ?".
Мама отвечает: "О да, мы зовем его Бобби Таблицы. Надеюсь, вы уже научились очищать входные данные?".
А директор в ужасе говорит: "Мы потеряли ведомости всех студентов за целый год!".

Вопрос на засыпку: На каких именно этапах DBLC была допущена ошибка, приведшая к этой катастрофе?
[Студенты рассуждают: на этапе логического проектирования не задали домен имени, а на физическом этапе склеивали SQL-запрос сырой строкой вместо параметризации].

Блестяще! На этапе анализа не определили ограничения домена, на логическом не предусмотрели валидацию, а на физическом программисты выполнили динамическую конкатенацию SQL. База честно выполнила команду DROP TABLE. Это наглядное доказательство того, что пренебрежение ограничениями целостности на этапах проектирования уничтожает бизнес-системы».

Прямая речь преподавателя: «Открываем файл zanyatie.html в браузере. Введите ваши реальные фамилию, имя и учебную группу.

Вам доступны 4 отраслевых варианта:
• Вариант 1: Сеть аптек со складом (учет рецептов, сроки годности партий лекарств).
• Вариант 2: Каршеринг (телеметрия, жесткий SLA отклика < 100 мс, GiST-индексы).
• Вариант 3: Маркетплейс (кликстрим, корзины, осознанная денормализация под OLAP/DWH).
• Вариант 4: Медицинская клиника (защита ПДн по 152-ФЗ, шифрование TDE, журнал аудита).

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

Прямая речь преподавателя: «Итак, подведем итоги. Сегодня мы усвоили, что база данных — это инженерное сооружение, требующее строгого прохождения жизненного цикла DBLC: от анализа первичных документов через концептуальные ER-диаграммы и нормализованные реляционные схемы к физическим DDL-скриптам, индексам и бэкапам.

Оценивание ваших практических карт этапов проводится по 4-балльной шкале рубрики: 2 балла за полноту декомпозиции этапов, 1 балл за входы/выходы, 1 балл за учет специфики и самопроверку.

Домашнее задание: Студенты, присутствовавшие на паре и успешно сохранившие результат в рабочем листе, закрепляют теорию по лекции. Файл domashnee_zadanie.html является резервным дистанционным материалом: его выполняют только те обучающиеся, которые пропустили сегодняшнее занятие по уважительной причине или получили индивидуальное назначение. Всем спасибо за продуктивную работу! Урок окончен».