Сценарий занятия: Основной регламент (80 минут)
Этап 1. Организационный момент и мотивация (5 минут)
Преподаватель:
«Здравствуйте, коллеги! Присаживайтесь. Сегодня мы переходим ко второму разделу нашей программы — реляционному подходу и концепции независимости данных. Представьте себе крупный банк: у него есть база данных с миллионами клиентов, а к ней подключены сотни банкоматов, мобильные приложения iOS и Android, веб-кабинет и старая бухгалтерская программа 2008 года.
Если отдел разработки решит разбить одну большую таблицу клиентов на две — для юридических и физических лиц, должны ли мы одновременно остановить работу всех банкоматов страны и срочно переписать прошивку каждого аппарата? Конечно нет! Почему? Потому что архитектура современных СУБД построена на принципе независимости данных. Сегодня мы разберем, как именно этот принцип устроен, и научимся его реализовывать.»
Этап 2. Актуализация опорных знаний (8 минут)
Преподаватель:
«Давайте вспомним: на прошлых парах мы анализировали сущности, атрибуты и связи. Скажите, когда вы в коде программы пишете
SELECT * FROM Students WHERE group_id = 101, знает ли ваша программа, на каком жестком диске лежит этот файл? Знает ли она, в каком порядке сектора на диске считываются контроллером?»
Обучающийся:
«Нет, программа знает только название таблицы и имена столбцов, а с диском работает операционная система и сама база данных.»
Преподаватель:
«Верно! Это и есть первое проявление абстракции. Но так было не всегда. В 1960-х годах программисты вручную вычисляли смещение байтов. Добавили 3 байта в запись — и весь софт компании ломался. Чтобы спасти индустрию от краха, в 1975 году был создан стандарт ANSI/SPARC.»
Этап 3. Изложение нового материала (32 минуты)
Преподаватель:
«Взгляните на экран (демонстрирует Слайд 3 презентации). Архитектура ANSI/SPARC делит СУБД на три уровня:
1.
Внешний уровень (External Level): то, как данные видят конкретные пользователи или программы. Бухгалтер видит баланс и ИНН, кассир видит только цену товара и чек.
2.
Концептуальный уровень (Conceptual Level): единая логическая модель всей организации. Здесь живут наши сущности, таблицы, первичные и внешние ключи, правила целостности.
3.
Внутренний или физический уровень (Internal Level): дисковые файлы, страницы по 8 килобайт, B-Tree деревья индексов, сжатие блоков и таблицы размещения.
Между этими уровнями проходят две спасительные границы независимости. Первая —
логическая независимость данных между внешним и концептуальным уровнями. Что это значит? Если мы изменим концептуальную схему — например, разобьем таблицу клиентов на
ЮрЛица и
ФизЛица, — то мы создаем виртуальное представление —
VIEW. Для старых приложений это представление выглядит ровно так же, как старая таблица! А если старое приложение хочет вставить запись, мы подключаем триггер
INSTEAD OF INSERT, который сам раскладывает поля по новым таблицам.
Вторая граница —
физическая независимость данных между концептуальным и внутренним уровнями (демонстрирует Слайды 7–10). Администратор базы видит, что запрос к таблице из 10 миллионов строк тормозит и выполняется 4 секунды. Он добавляет B-Tree индекс:
CREATE INDEX idx_user ON Orders(user_id);.
Обратите внимание на критический момент: в коде клиентского приложения запрос
SELECT * FROM Orders WHERE user_id = ? не изменился ни на один знак! Но теперь время отклика составляет 2 миллисекунды, потому что оптимизатор СУБД переключился на сканирование индекса. Точно так же работают партиционирование (Partitioning) и перенос архивных таблиц на медленные HDD-диски через Tablespaces.»
Этап 4. Разбор эталонных кейсов (12 минут)
Преподаватель:
«Давайте зафиксируем алгоритм доказательства независимости. Разберем сквозной пример:
Сценарий А: Мы добавили в таблицу покупателей поле
Статус_лояльности. Старые кассовые аппараты парсят ответ строго фиксированной длины и при появлении новой колонки выдают синтаксическую ошибку протокола. Какая это независимость? Логическая! Как мы ее обеспечиваем? Создаем для кассовых аппаратов VIEW, где перечисляем строго старый перечень колонок без нового поля.
Сценарий Б: Запросы к архиву за 2020 год стали выполняться редко. Мы переносим этот сегмент на дешевый внешний дисковый массив через команду
ALTER TABLE ... SET TABLESPACE hdd_archive. Какая это независимость? Физическая! Меняется место хранения на диске, но SQL-запросы бухгалтера остаются прежними.»
Этап 5. Практическое закрепление в zanyatie.html (15 минут)
Преподаватель:
«Теперь откройте на ваших компьютерах файл
zanyatie.html. Введите свои реальные ФИО и номер учебной группы. Перед вами 4 варианта производственных сценариев: декомпозиция клиентов, перенос архива на HDD с секционированием, ускорение поиска с помощью индексов B-Tree vs Hash и экранирование полей для кассовых терминалов.
Ваша задача — классифицировать вид независимости, выбрать инструмент реализации (VIEW/INSTEAD OF или Индексы/Партиции/Tablespaces) и сформулировать технический вывод. Работа оценивается в 4 балла по критериальной рубрике. Приступайте к выполнению!»
Этап 6. Итоги, рефлексия, ДЗ (8 минут)
Преподаватель:
«Время подошло к концу. Давайте разберем частую ошибку: некоторые записали добавление индекса B-Tree в логическую независимость. Помните: индекс не меняет логическую структуру данных, он не добавляет новых данных для пользователя — он лишь ускоряет доступ к ним на диске. Поэтому индексы — это физический уровень!
Сохраните ваши рабочие листы. Для тех, кто пропустил пару или нуждается в дистанционной отработке, подготовлен файл
domashnee_zadanie.html — выполнять его нужно только по индивидуальному назначению преподавателя. Всем спасибо за продуктивную работу!»
Сценарий занятия: Адаптивный сокращенный регламент (60 минут)
Этап 1. Оргмомент и постановка проблемы (6 минут)
Преподаватель:
«Здравствуйте! Сегодня работаем по сокращенному расписанию (60 минут). Наша тема — логическая и физическая независимость данных. Вопрос на миллион: что позволяет переносить терабайты базы на другой сервер или менять состав таблиц так, чтобы миллионы пользователей мобильного приложения даже не заметили обновления? Запишите тему, сегодня мы разберем два фундаментальных уровня изоляции.»
Этап 2. Концентрированное объяснение теории (24 минуты)
Преподаватель:
«Смотрим на схему ANSI/SPARC. Три уровня: Внешний (интерфейсы и представления), Концептуальный (полный набор таблиц и связей) и Внутренний (файлы, сектора, диски).
Если мы меняем состав таблиц (делим клиентов на юрлиц и физлиц), мы обязаны сохранить
логическую независимость. Для этого мы создаем
VIEW и триггер
INSTEAD OF. Внешнее приложение шлет запрос к старому имени и ничего не подозревает.
Если мы оптимизируем хранилище (строим индекс B-Tree, делим таблицу на секции по годам через Partitioning или выносим архив на HDD через Tablespaces) — мы реализуем
физическую независимость. SQL-запросы в коде приложений остаются неизменными, оптимизатор СУБД берет всю дисковую маршрутизацию на себя.»
Этап 3. Демонстрация эталона анализа (8 минут)
Преподаватель:
«Быстрый эталон: если задача формулируется как «ускорить запрос без изменения SQL-кода» — это физическая независимость, инструмент — B-Tree индекс. Если задача — «сохранить работоспособность старой программы при дроблении таблицы» — это логическая независимость, инструмент — VIEW с
UNION ALL и триггер
INSTEAD OF.»
Этап 4. Практическая работа обучающихся (14 минут)
Преподаватель:
«Открываем
zanyatie.html, выбираем назначенный вариант и заполняем поля анализа. Обратите внимание на обоснование: четко называйте уровень ANSI/SPARC и используемый механизм СУБД.»
Этап 5. Экспертный разбор и устранение неточностей (4 минуты)
Преподаватель:
«Сверяем типичные моменты: не путайте обычное VIEW с материализованным и помните, что партиционирование не требует изменения имени таблицы в секции
FROM.»
Этап 6. Итоги и рефлексия (4 минуты)
Преподаватель:
«Фиксируем результаты. Практические бланки сохранены в localStorage и экспортируются в PDF. Максимальная оценка — 4 балла. Занятие окончено!»