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

Дисциплина: ОП.08 Основы проектирования баз данных | Занятие 01
Тема программы: Тема 1. Основные понятия баз данных — Основные понятия теории БД (§2.2, с.7)
Тип занятия: Урок усвоения новых знаний (теоретический урок)
Академические часы: 2 часа (80 мин основной регламент / 60 мин сокращенный)
Оцениваемый продукт: Аналитическая карта архитектуры хранения данных (4 балла)

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

Первое занятие по курсу «Основы проектирования баз данных» закладывает фундамент системного инженерного мышления обучающихся специальности 09.02.07 «Информационные системы и программирование». Главная педагогическая задача — вывести студентов из бытового представления о базе данных как о «таблице Excel» или «файле на диске» в плоскость промышленной архитектуры данных.

Ключевая триада понятий:
  • Данные (Data): Зарегистрированные сигналы, факты или значения предметной области, зафиксированные на материальном носителе вне контекста их применения.
  • Информация (Information): Данные, воспринятые потребителем в контексте решаемой прикладной задачи, снимающие имеющуюся неопределенность и пригодные для принятия решений.
  • База данных (Database): Поименованная, структурированная и целостная совокупность взаимосвязанных данных, отображающая состояние объектов предметной области и связей между ними.
  • СУБД (DBMS): Специализированный комплекс программных и языковых средств, обеспечивающий централизованное создание, ведение, модификацию, защиту и параллельный доступ к базам данных со стороны пользователей и приложений.

Цели занятия:

2. Детальный поминутный регламент занятия

Основной регламент: 80 минут

  1. 00–05 мин (5 мин): Организационный момент, актуализация темы, постановка проблемного вопроса («Почему крупный банк не может вести учет клиентов в Excel?»).
  2. 05–30 мин (25 мин): Теоретический блок:
    • 05–12 мин: Данные vs Информация, ограничения файловых систем.
    • 12–20 мин: Определение БД и СУБД, функции СУБД, классификация (SQL vs NoSQL).
    • 20–30 мин: Архитектура ANSI/SPARC, независимость данных, роль DBA.
  3. 30–45 мин (15 мин): Интерактивная демонстрация слайдов презентации, разбор кейсов (аномалия Lost Update, мем xkcd Bobby Tables как иллюстрация важности валидации и разделения уровней).
  4. 45–70 мин (25 мин): Самостоятельная работа студентов в интерактивном рабочем листе по 4 вариантам архитектурного анализа.
  5. 70–80 мин (10 мин): Рефлексия, сопоставление с эталонами рубрики, самооценка (4 балла), инструктаж по резервному домашнему заданию.

Сокращенный регламент: 60 минут

  1. 00–05 мин (5 мин): Организационный момент, формулировка проблемы надежности хранения.
  2. 05–23 мин (18 мин): Сжатый теоретический экспресс-блок:
    • 05–10 мин: Понятия Данные/БД/СУБД, крах файлового подхода.
    • 10–18 мин: Модели СУБД (таблица vs документ) и схема ANSI/SPARC.
  3. 23–33 мин (10 мин): Демонстрация презентации: ключевые схемы архитектуры и разбор аномалии одновременного доступа.
  4. 33–53 мин (20 мин): Интенсивная самостоятельная работа с рабочим листом: выбор варианта, заполнение карты и формулировка контрпримера.
  5. 53–60 мин (7 мин): Экспресс-подведение итогов, самооценка, сохранение результатов в PDF/печать.
Методическое указание при 60-минутном сценарии: Глубокий сравнительный анализ графовых и key-value хранилищ выносится на самостоятельное ознакомление по конспекту лекции (`lekciya.html`), а на очном занятии фокус концентрируется на дихотомии «Файлы vs СУБД» и «Реляционные vs Документные СУБД».

3. Содержательный базис темы

3.1. Данные, информация и ограничения файловых систем

Преподавателю важно продемонстрировать исторический переход от файловых систем к СУБД (1960–1970-е годы). Файловая организация порождает неустранимые проблемы:

3.2. Классификация современных СУБД

Класс СУБД Модель данных Примеры систем Оптимальная сфера применения
Реляционные (RDBMS / SQL) Таблицы (отношения), строки (кортежи), столбцы (атрибуты), первичные и внешние ключи. PostgreSQL, MySQL, Oracle DB, MS SQL Server, SQLite Финансовые транзакции, учетные системы, ERP, биллинг — везде, где требуется строгая консистентность (ACID).
Документные (Document NoSQL) Иерархические полуструктурированные документы (JSON, BSON, XML) с динамической схемой. MongoDB, CouchDB, RavenDB Каталоги интернет-магазинов со сложными атрибутами, контент-менеджмент (CMS), профили пользователей, аналитика событий.
Ключ-значение (Key-Value) Простейшая хеш-таблица: уникальный строковый ключ и произвольный массив байт. Redis, Memcached, Amazon DynamoDB Кэширование сессий пользователей, корзины покупок, очереди сообщений, счетчики реального времени.
Графовые (Graph DBMS) Вершины (узлы), ребра (направленные связи) и свойства элементов. Neo4j, Memgraph, Amazon Neptune Социальные сети, рекомендательные движки, системы противодействия мошенничеству (Fraud Detection), анализ цепочек поставок.

3.3. Архитектура ANSI/SPARC и независимость данных

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

  1. Внешний уровень (External Level / Views): Индивидуальные представления данных для конкретных пользователей или ролей. Бухгалтер видит зарплату, но не видит медицинские данные; диспетчер видит расписание, но не видит персональные телефоны. Реализуется через механизмы представлений (SQL Views) и ролей.
  2. Концептуальный уровень (Conceptual Level): Единое общее логическое описание всей базы данных без привязки к дискам. Определяет сущности, их свойства, типы данных и бизнес-ограничения целостности (UNIQUE, FOREIGN KEY, CHECK).
  3. Внутренний уровень (Internal / Physical Level): Физическая структура хранения данных в постоянной памяти: разметка страниц на диске, алгоритмы сжатия, B-Tree или GiST индексы, управление памятью buffer pool.

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

3.4. Функции администратора базы данных (DBA)

Администратор БД (Database Administrator) отвечает за непрерывность, производительность и безопасность:

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

Ошибка 1: «БД и СУБД — это слова-синонимы»

Суть ошибки: Студенты называют программу PostgreSQL или Access «базой данных», а таблицу с записями — «СУБД».

Педагогический прием: Метафора «Библиотека и Библиотекарь» или «Склад и Кладовщик». База данных — это книги на полках (хранилище информации). СУБД — это библиотекарь, который принимает читательские требования (запросы), находит нужные книги в картотеке (индексах), выдает копии и следит, чтобы читатели не испортили оригиналы.

Ошибка 2: «В Excel можно хранить любую БД»

Суть ошибки: Непонимание проблемы многопользовательской конкуренции и транзакционной целостности.

Педагогический прием: Разыгрывание кейса «Покупка последнего авиабилета». Преподаватель вызывает двух студентов и моделирует покупку билета через Excel без блокировок. Оба видят свободное место №14, оба одновременно подтверждают бронь. Кто улетит? Демонстрация того, как СУБД решает проблему через блокировку строки или транзакционную сериализацию.

Ошибка 3: «NoSQL появился, потому что реляционные базы устарели»

Суть ошибки: Ошибочное восприятие NoSQL как полной замены SQL.

Педагогический прием: Теорема CAP и компромисс между строгой консистентностью и масштабируемостью. Разбор банковского перевода: в банке недопустима модель eventual consistency (согласованность в конечном счете), где деньги со счета списались, а на второй счет упадут «через пару минут». Каждая технология выбирается под конкретный тип нагрузки.

5. Инструкция по оцениванию индивидуального продукта

На этапе закрепления знаний каждый студент заполняет аналитическую карту в файле zanyatie.html по одному из 4 вариантов. Оценивание производится строго по 4-балльной шкале, зафиксированной в .rubrika.md:

По завершении работы студент нажимает кнопку «Печать / Экспорт в PDF» и сдает готовый отчет преподавателю. При отсутствии очной явки студент выполняет резервное дистанционное задание из файла domashnee_zadanie.html.