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

Основы баз данных и классификация архитектур СУБД

Представьте себе крупную библиотеку, в которой книги свалены в одну огромную кучу посреди зала. Технически — это собрание данных. Однако найти в этой куче конкретный томик стихов или отследить, кто из читателей взял книгу домой, практически невозможно. База данных превращает эту «кучу» в упорядоченный стеллаж, где каждая ячейка имеет свой адрес, а специальный «библиотекарь» (программное обеспечение) следит за тем, чтобы данные не терялись, не дублировались и были доступны по первому требованию. В академической среде понимание того, как именно устроены эти «стеллажи» и как работает «библиотекарь», является фундаментом для изучения любой информационной системы.

Фундаментальные понятия: Данные, Базы данных и СУБД

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

Данные — это совокупность сведений, зафиксированных на материальном носителе в форме, пригодной для постоянного хранения, передачи и обработки. Сами по себе данные могут быть разрозненными фактами: число 42, слово «Иванов», дата 12.05.2023. Они обретают смысл только в определенном контексте.

База данных (БД) — это не просто набор файлов, а именованная совокупность данных, отражающая состояние объектов и их отношений в определенной предметной области. Важнейшим свойством БД является её структурированность. Если мы записываем фамилии студентов в текстовый файл в свободном порядке — это набор данных. Если же мы создаем таблицу, где четко определено, что в первом столбце всегда фамилия, во втором — номер зачетки, а в третьем — код группы, мы создаем простейшую базу данных.

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

> СУБД — это программная прослойка между физическими данными на диске и пользователем (или прикладной программой).

Без СУБД программисту пришлось бы каждый раз заново писать код для открытия файла, поиска нужной строки, обработки ошибок записи и контроля доступа. СУБД берет эти рутинные задачи на себя, предоставляя стандартный интерфейс взаимодействия.

Трехуровневая архитектура ANSI/SPARC

Одной из самых важных теоретических концепций в проектировании СУБД является трехуровневая модель архитектуры, предложенная комитетом ANSI/X3/SPARC. Она была создана для решения проблемы зависимости программ от данных. В старых системах изменение структуры файла (например, добавление нового поля) требовало переписывания всех программ, которые этот файл читали. Архитектура ANSI/SPARC разделяет представление данных на три уровня:

Внешний уровень (External Level): Это то, как данные видят конечные пользователи или отдельные приложения. Для каждого пользователя может существовать свое «представление» (View). Например, бухгалтер видит только зарплаты и налоги, а кадровик — стаж и анкетные данные, хотя все это хранится в одной базе.

Концептуальный уровень (Conceptual Level): Это логическое описание всей базы данных в целом, очищенное от подробностей хранения. Здесь описываются сущности, их свойства и связи между ними. Это «единый взгляд» на структуру данных предприятия, который не зависит от того, как данные будут лежать на диске.

Внутренний уровень (Internal Level): Это физическое представление данных в памяти компьютера. Здесь определяются форматы записей, методы сжатия, способы индексации и размещения данных в блоках памяти.

Ключевое преимущество такой схемы — независимость данных. Мы можем изменить физический способ хранения (внутренний уровень), например, перенести данные с жесткого диска на SSD или сменить алгоритм индексации, и при этом концептуальная схема останется прежней. Аналогично, мы можем изменить концептуальную схему (добавить новую таблицу), не ломая внешние представления пользователей, которые эту таблицу не используют.

Классификация СУБД по модели данных

Модель данных — это совокупность структур данных и операций их обработки. Именно по используемой модели чаще всего классифицируют СУБД. Исторически развитие шло от жестких иерархий к гибким сетевым структурам, а затем к доминирующей сегодня реляционной модели.

Иерархическая модель

Представьте дерево. У каждой «ветки» (записи) есть только один «предок» (родительская запись), но может быть много «потомков». Это жесткая структура, идеально подходящая для описания систем типа «начальник — подчиненный» или «папка — подпапка». Плюс:* Высокая скорость доступа к данным при движении вниз по дереву. Минус:* Невозможность адекватно отразить связи типа «многие-ко-многим». Например, если один студент учится у многих преподавателей, в иерархической модели придется либо дублировать данные, либо строить очень сложные обходные пути.

Сетевая модель

Это расширение иерархической модели, где у «потомка» может быть несколько «предков». Структура превращается из дерева в граф. Плюс:* Можно моделировать любые сложные связи. Минус:* Чрезвычайная сложность в управлении. Чтобы найти данные, программист должен буквально «навигировать» по указателям в памяти. Если структура базы меняется, логика навигации в коде программы часто рушится.

Реляционная модель

Основана на математическом понятии «отношение» (relation). Данные представляются в виде плоских таблиц. Это самая распространенная модель на сегодняшний день, которую мы будем подробно изучать в следующих главах. Её главная сила в простоте и математической строгости. Взаимосвязи между таблицами устанавливаются не через физические указатели (как в сетевой модели), а через совпадение значений данных.

Объектно-ориентированные и NoSQL модели

Современные системы часто используют объектный подход (где данные хранятся как объекты в программировании) или NoSQL-подходы (документоориентированные, графовые, «ключ-значение»). Они незаменимы при работе с огромными объемами неструктурированных данных (Big Data), но часто жертвуют строгой согласованностью ради скорости и масштабируемости.

Архитектуры распределения данных

СУБД также классифицируются по тому, как они размещаются в сети и как взаимодействуют с пользователями.

Локальные (настольные) СУБД

Все части системы (данные и программа для работы с ними) находятся на одном компьютере. Примеры из прошлого — Microsoft Access или FoxPro в их простейшем варианте. Такие системы плохо подходят для одновременной работы многих людей, так как возникают конфликты при попытке двух пользователей одновременно изменить один и тот же файл.

Архитектура «Клиент-Сервер»

Это стандарт для профессиональных систем. Она разделяет функции на две части:

Сервер БД: Мощный компьютер, на котором установлена СУБД. Он хранит данные, выполняет сложные запросы, обеспечивает безопасность и целостность.

Клиент: Приложение на компьютере пользователя, которое отправляет запросы (обычно на языке SQL) серверу и получает от него только результат.

В этой архитектуре по сети передается не весь файл базы данных, а только конкретный запрос и ответ на него. Это радикально снижает нагрузку на сеть и повышает безопасность, так как пользователь не имеет прямого доступа к файлам данных — только через «посредника» в лице сервера.

Существует две разновидности клиент-серверной архитектуры: * Двухзвенная: Клиент напрямую общается с сервером БД. * Трехзвенная (Многозвенная): Между клиентом и сервером БД появляется «Сервер приложений». Клиент (например, браузер) обращается к серверу приложений, тот обрабатывает бизнес-логику и сам делает запросы к базе данных. Это наиболее масштабируемая схема, используемая во всех современных веб-сервисах.

Распределенные СУБД

В этом случае единая логическая база данных физически размещается на нескольких узлах сети (серверах), которые могут находиться в разных городах или странах. СУБД должна обеспечивать такую работу, чтобы пользователь даже не подозревал, что часть его таблицы лежит в Москве, а часть — в Новосибирске. Главная сложность здесь — синхронизация данных и обеспечение их непротиворечивости при сбоях связи.

Функции СУБД и понятие транзакции

Чтобы СУБД считалась полноценной, она должна выполнять ряд критических функций, которые часто объединяются понятием «управление данными».

Управление данными во внешней памяти: СУБД решает, как эффективно разместить данные на дисках, чтобы минимизировать время доступа.

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

Управление транзакциями: Это, пожалуй, важнейшая концепция для понимания надежности.

Транзакция — это логическая единица работы с базой данных, которая либо выполняется целиком и полностью, либо не выполняется вовсе. Классический пример — перевод денег с одного банковского счета на другой. Этот процесс состоит из двух шагов: вычесть сумму со счета А и прибавить её к счету Б. Если после первого шага произойдет сбой (выключится свет), деньги исчезнут в никуда. СУБД гарантирует, что если транзакция не завершена до конца, система вернется в исходное состояние (откат), как будто ничего не происходило.

Для описания свойств транзакций используется аббревиатура ACID: * Atomicity (Атомарность): Все или ничего. * Consistency (Согласованность): Транзакция переводит базу из одного корректного состояния в другое. * Isolation (Изоляция): Параллельные транзакции не должны мешать друг другу. * Durability (Долговечность): Если транзакция подтверждена, её результат не должен быть потерян даже при системном сбое.

Языковые средства СУБД

Взаимодействие с СУБД происходит не на языке программирования общего назначения (как Python или C++), а с помощью специальных декларативных языков. Декларативность означает, что вы описываете, что хотите получить («дай мне список всех студентов 3-го курса»), а не как это сделать (не нужно писать циклы и условия перебора файлов).

Традиционно эти языковые средства делят на две группы:

DDL (Data Definition Language): Язык определения данных. Используется для создания таблиц, изменения их структуры, удаления индексов. Это команды «архитектора».

DML (Data Manipulation Language): Язык манипулирования данными. Используется для вставки новых записей, их удаления, обновления и, самое главное, для выборки (поиска) информации.

В современных реляционных СУБД обе эти группы команд объединены в единый язык SQL (Structured Query Language). Несмотря на то что SQL имеет множество диалектов (у каждой СУБД — Oracle, PostgreSQL, MySQL — свои особенности), его базовая структура стандартизирована, что делает знания о реляционных системах универсальными.

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