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

ОП.08 Основы проектирования баз данных | Тема 2. Взаимосвязи в моделях и реляционный подход к построению моделей — Типы моделей данных

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

Тема программы: §2.2 с.7

Объем: 2 академических часа (80 мин основной / 60 мин сокращенный)

Форма: Урок с объяснением теории

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

Занятие №06 посвящено изучению фундаментальной эволюции парадигм организации данных в информационных системах: от ранних навигационных моделей (иерархической и сетевой) к доминирующей математически строгой реляционной модели Э. Кодда, ее объектно-реляционному расширению и специализированным архитектурам семейства NoSQL (документным, графовым, колоночным, ключ-значение).

Главная методическая задача: преодолеть наивное убеждение студентов о том, что «SQL устарел, а NoSQL решает любые задачи» либо обратное заблуждение, что «реляционные СУБД универсальны для абсолютно любых нагрузок». Преподаватель формирует у будущих техников-программистов инженерное системное мышление: модель данных выбирается строго на основе характеристик предметной области, топологии связей, требований к транзакционной целостности (ACID) и ограничений распределенных систем (CAP-теорема).

Планируемые образовательные результаты

Знания: формальные определения и принципы построения иерархической (дерево, сегменты, дублирование), сетевой (произвольные графы, наборы CODASYL), реляционной (теория множеств, кортежи, домены, 12 правил Кодда), объектно-реляционной моделей; устройство и специфика NoSQL моделей: документных (BSON/JSON, вложенность), графовых (вершины, направленные ребра, безындексная смежность), колоночных (хранение по колонкам, сжатие, разряженность), ключ-значение (хеш-таблица, O(1), эфемерность); формулировка теоремы Брюэра (CAP) и компромисс PACELC; парадигмы ACID vs BASE.
Умения: анализировать требования предметной области (паттерны доступа, преобладание OLTP vs OLAP, глубина графа связей, вариативность атрибутов) и технически обоснованно подбирать оптимальную модель данных и СУБД; выявлять риски денормализации и потери согласованности данных.
Компетенции: ОК 01 (выбирать способы решения профессиональных задач), ОК 02 (использовать современные ИКТ), ОК 04 (эффективно взаимодействовать), ОК 09 (профессиональное развитие), ПК 1.1–ПК 1.5 (разработка и проектирование структур данных и модулей ПО).

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

В зависимости от академического расписания учебный процесс реализуется либо в полном 80-минутном формате, либо в сокращенном 60-минутном формате.

Этап занятия	Основной регламент (80 мин)	Сокращенный регламент (60 мин)	Методический акцент и перераспределение материала
1. Организационный момент и актуализация	5 мин (00–05 мин)	5 мин (00–05 мин)	Фронтальный опрос по ограничениям файловых систем. Постановка проблемного вопроса: «Почему нельзя хранить друзей пользователя соцсети в реляционной таблице так же эффективно, как остатки на банковском счете?».
2. Изложение теоретического материала	35 мин (05–40 мин)	25 мин (05–30 мин)	В 80-мин: полный разбор иерархической, сетевой моделей, 12 правил Кодда, объектных СУБД, CAP-теоремы и всех 4 семейств NoSQL. В 60-мин: краткий обзор ранних моделей, фокус на контрасте «Реляционная vs NoSQL (документная, графовая, колоночная, key-value)» и теореме CAP.
3. Демонстрация презентации и тренинг	25 мин (40–65 мин)	18 мин (30–48 мин)	Разбор интерактивных слайдов (prezentaciya.html) с блок-схемами структур данных, анализ популярного мема о миграции на NoSQL / Bobby Tables, самостоятельное заполнение рабочего листа (zanyatie.html) по 4 вариантам кейсов.
4. Подведение итогов, рефлексия, ДЗ	15 мин (65–80 мин)	12 мин (48–60 мин)	Критериальный аудит работ по 4-балльной закрытой рубрике (.rubrika.md), разбор типовых ошибок, экспорт рабочего листа, инструктаж по резервному заданию (domashnee_zadanie.html).

3. Содержательная эволюция моделей данных

3.1. Иерархическая модель данных (дерево, сегменты)

Появилась во второй половине 1960-х годов (флагманская система — IBM IMS, созданная в рамках лунной программы Apollo).

Математическая основа: ориентированное корневое дерево.
Элементы: корневой сегмент (Root), подчиненные сегменты (Child). У каждого дочернего сегмента есть строго один родительский сегмент (Parent). Связь типа «один-ко-многим» (1:N) реализуется естественным образом.
Критический недостаток: невозможность непосредственной реализации отношений «многие-ко-многим» (M:N) и наличие множественных родителей без искусственного дублирования поддеревьев либо сложных физических перекрестных указателей (Logical Child). При удалении родительского сегмента каскадно удаляются все его потомки (аномалия удаления).

3.2. Сетевая модель данных (графы, наборы CODASYL)

Стандартизирована ассоциацией CODASYL (Conference on Data Systems Languages, 1969–1971 гг., системы IDMS, IDS).

Математическая основа: произвольный ориентированный граф.
Элементы: записи-владельцы (Owner) и записи-члены (Member), объединяемые в именованные наборы (Sets). Один потомок может иметь несколько родителей разного типа.
Критический недостаток: жесткая «навигационная» модель доступа (Navigational Access). Программист был вынужден писать императивный код перемещения физических указателей (курсоров) по цепочкам (FIND FIRST RECORD OF SET, FIND NEXT). Изменение физической структуры диска полностью ломало прикладной код.

3.3. Реляционная модель данных (РМД, Э. Кодд)

Предложена Эдгаром Ф. Коддом в 1970 году в эпохальной статье «A Relational Model of Data for Large Shared Data Banks» (IBM Research).

Математическая основа: теория множеств и логика предикатов первого порядка.
Элементы: отношение (таблица), кортеж (строка), атрибут (столбец), домен (множество допустимых атомарных значений атрибута).
Принцип независимости данных: отделение логического уровня от физического представления (B-Tree, хэш, блоки диска). Доступ осуществляется не навигацией, а декларативным языком запросов (SQL), где программист указывает, какие данные нужны, а оптимизатор СУБД решает, как их извлечь.
12 правил Кодда (Правила 0–12):
1. Фундаментальное правило: Система должна управлять базой данных исключительно посредством своих реляционных возможностей.
2. Информационное правило: Вся информация представляется строго на логическом уровне в виде значений в таблицах.
3. Гарантированный доступ: Каждое атомарное значение логически доступно по комбинации (имя таблицы, первичный ключ, имя столбца).
4. Систематическая обработка NULL: Полная поддержка неопределенных значений, отличных от пробела или нуля, независимых от типа.
5. Динамический каталог (словарь данных): Метаданные хранятся в таких же реляционных таблицах и доступны через SQL.
6. Исчерпывающий подъязык данных: Наличие декларативного языка с поддержкой DDL, DML, ограничений целостности, транзакций и прав доступа.
7. Обновление представлений (View Updating): Все теоретически обновляемые представления должны обновляться системой.
8. Реляционный уровень операций: Операции вставки, обновления и удаления работают над целыми множествами записей, а не только поодиночно.
9. Физическая независимость данных: Изменение методов хранения и индексов не требует переписывания прикладных программ.
10. Логическая независимость данных: Изменение схемы таблиц, сохраняющее исходные данные, не ломает программы при правильном использовании представлений.
11. Независимость контроля целостности: Ограничения целостности (PRIMARY KEY, FOREIGN KEY, CHECK) хранятся в каталоге, а не зашиваются в прикладной код.
12. Распределенная независимость: Приложения работают одинаково независимо от того, распределены ли данные по сети.
13. Неподавление правил (Rule of Non-subversion): Если интерфейс низкого уровня предоставляет поштучный доступ, он не должен позволять обойти ограничения целостности реляционного ядра.

3.4. Объектно-реляционная модель (ORDBMS)

Эволюционный гибрид (PostgreSQL, Oracle DB), расширивший реляционную модель поддержкой сложных пользовательских типов (UDT), наследования таблиц, вложенных массивов и встроенных функций (PL/pgSQL), а также нативной обработкой формата JSON/JSONB. Позволяет нивелировать феномен «объектно-реляционного импеданса» (Object-Relational Impedance Mismatch).

3.5. Современное семейство NoSQL моделей

Возникло на рубеже 2000–2010 годов как ответ на взрывной рост объемов неструктурированных данных (Big Data), необходимость горизонтального масштабирования (Scale-Out) на недорогом оборудовании и сверхвысокой доступности.

Семейство NoSQL	Базовые структуры	Популярные СУБД	Оптимальные сценарии использования	Ограничения и риски
Документные (Document-oriented)	Иерархические документы (JSON, BSON, XML). Гибкая схема (Schema-on-read).	MongoDB, Couchbase, CouchDB	Каталоги товаров с динамическими свойствами, профили пользователей, CMS, блоги, мобильные бэкенды.	Дублирование данных при денормализации; отсутствие транзакций между не связанными коллекциями (до последних версий).
Графовые (Graph)	Вершины (Nodes), Направленные ребра (Edges/Relationships), Свойства (Properties). Безындексная смежность (Index-free adjacency).	Neo4j, Memgraph, Amazon Neptune	Социальные сети (графы друзей), рекомендательные движки, антифрод-мониторинг финансовых связей, логистические маршруты.	Сложность горизонтального шардирования графа на множество физических узлов без колоссальных накладных расходов.
Колоночные (Wide-column / Columnar)	Колоночные семейства (Column Families) или физическое хранение по столбцам вместо строк. Колоссальное сжатие данных (LZ4, ZSTD).	ClickHouse, Apache Cassandra, ScyllaDB, HBase	Аналитика больших данных (OLAP), кликстрим, сбор телеметрии IoT, агрегатные запросы (SUM, AVG) по миллиардам строк за секунды.	Крайне низкая эффективность точечных обновлений (UPDATE/DELETE) отдельных строк; не подходит для классических OLTP-транзакций.
Ключ-значение (Key-Value)	Ассоциативный массив (хэш-таблица). Доступ по строгому первичному ключу за $O(1)$.	Redis, KeyDB, Memcached, DynamoDB	Кэширование сессий, счетчики просмотров, лидерборды, корзины покупателей, брокеры сообщений (Pub/Sub).	Невозможность выполнения сложных запросов по значениям атрибутов (нет гибкого WHERE); риск потери данных при сбое оперативной памяти.

4. Архитектурные парадигмы: CAP-теорема, ACID vs BASE

4.1. CAP-теорема Эрика Брюэра

В любой распределенной системе хранения данных при возникновении сетевого разделения узлов (Network Partition, P) архитектор вынужден выбирать строго между:

Consistency (Согласованность данных): все узлы кластера в один и тот же момент времени возвращают абсолютно идентичные данные (система отвечает ошибкой, если свежая реплика недоступна). Примеры: реляционные кластеры с синхронной репликацией, Google Spanner.
Availability (Доступность): каждый запрос к работающему узлу гарантированно получает успешный непустой ответ, но без гарантии, что этот ответ содержит самую последнюю версию записи. Примеры: Cassandra, DynamoDB.

Методическое предостережение: Сетевые сбои (P) в распределенных системах неизбежны. Поэтому выбирать «CA» в распределенной сети в строгом смысле невозможно — выбор всегда идет между CP (согласованность в ущерб доступности) и AP (доступность в ущерб моментальной согласованности). В расширенной теореме PACELC также учитывается компромисс при штатной работе: Latency (задержка) vs Consistency (согласованность).

4.2. Сравнение парадигм ACID и BASE

Парадигма ACID (Реляционные СУБД)	Парадигма BASE (Распределенные NoSQL)
Atomicity (Атомарность): транзакция выполняется целиком либо не выполняется вовсе (Rollback). Consistency (Согласованность): транзакция переводит базу из одного валидного состояния в другое, соблюдая все ограничения. Isolation (Изоляция): параллельные транзакции не влияют на промежуточные результаты друг друга. Durability (Долговечность): зафиксированные изменения (Commit) сохраняются даже при внезапном отключении питания.	Basically Available (Базовая доступность): система сохраняет работоспособность при отказе большинства узлов, возвращая ответы (пусть и частично устаревшие). Soft state (Неустойчивое состояние): состояние данных может изменяться со временем даже без внешних запросов за счет фоновой репликации. Eventual consistency (Согласованность в конечном счете): через определенный промежуток времени при отсутствии новых обновлений все реплики кластера гарантированно придут к идентичному состоянию.

Парадигма ACID (Реляционные СУБД)

Парадигма BASE (Распределенные NoSQL)

Atomicity (Атомарность): транзакция выполняется целиком либо не выполняется вовсе (Rollback).

Consistency (Согласованность): транзакция переводит базу из одного валидного состояния в другое, соблюдая все ограничения.

Isolation (Изоляция): параллельные транзакции не влияют на промежуточные результаты друг друга.

Durability (Долговечность): зафиксированные изменения (Commit) сохраняются даже при внезапном отключении питания.

Basically Available (Базовая доступность): система сохраняет работоспособность при отказе большинства узлов, возвращая ответы (пусть и частично устаревшие).

Soft state (Неустойчивое состояние): состояние данных может изменяться со временем даже без внешних запросов за счет фоновой репликации.

Eventual consistency (Согласованность в конечном счете): через определенный промежуток времени при отсутствии новых обновлений все реплики кластера гарантированно придут к идентичному состоянию.

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

Типовые ошибки обучающихся

Уравнивание понятий «реляционная база данных» и «SQL»: студенты считают, что NoSQL буквально означает «отказ от языка SQL». Преподаватель разъясняет, что NoSQL расшифровывается как «Not Only SQL», и сегодня практически все NoSQL базы (ClickHouse, Cassandra CQL, Couchbase N1QL, MongoDB Atlas SQL) имеют SQL-подобные интерфейсы. Различие кроется в способе хранения и математической модели, а не в синтаксисе.
Попытка хранить глубокие сетевые структуры связей в плоских таблицах с каскадными JOIN: студенты пытаются построить рекомендательную ленту или граф «друзья друзей до 4-го рукопожатия» на MySQL, сталкиваясь с экспоненциальным падением производительности ($O(N^k)$). Преподаватель демонстрирует преимущество Neo4j, где переход по связям выполняется за константное время $O(1)$ благодаря физическим указателям ребер.
Использование NoSQL там, где требуется строгий финансовый баланс: стремление выбрать MongoDB для процессинга онлайн-платежей приводит к рискам рассогласованности остатков при сетевых сбоях.
Путаница между иерархической и реляционной моделями: студенты ошибочно называют иерархическую структуру «табличной с подтаблицами». Необходимо акцентировать внимание на топологии: строгое дерево с единым корнем и одним родителем у каждого узла.