Из каких ключевых компонентов состоит архитектура реляционной СУБД?

«Из каких ключевых компонентов состоит архитектура реляционной СУБД?» — вопрос из категории Базы данных и SQL, который задают на 10% собеседований QA Тестировщик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Архитектура типичной реляционной СУБД включает следующие логические и физические компоненты:

  1. Ядро СУБД (Database Engine)

    • SQL-парсер и оптимизатор запросов: Преобразует SQL-запрос в оптимальный план выполнения.
    • Диспетчер транзакций: Обеспечивает соблюдение принципов ACID (Atomicity, Consistency, Isolation, Durability).
    • Диспетчер блокировок (Lock Manager): Управляет параллельным доступом к данным, предотвращая конфликты.
  2. Логическая структура данных

    • Схема (Schema): Метаданные, описывающие структуру БД.
    • Таблицы (Tables/Relations): Основные единицы хранения данных в виде строк и столбцов.
    • Индексы (Indexes): Структуры для ускорения поиска (B-деревья, хэш-индексы).
    • Представления (Views): Виртуальные таблицы, определённые запросом.
    • Ограничения целостности (Constraints): PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK.
  3. Физическое хранилище (Storage Engine)

    • Управляет записью данных на диск: страницы (pages), файлы данных, журналы транзакций (WAL - Write-Ahead Logging).
  4. Вспомогательные компоненты

    • Журнал транзакций (Transaction Log): Гарантирует долговечность (Durability) и позволяет выполнять откат (rollback) и восстановление (recovery).
    • Буферный кэш (Buffer Pool): Кэширует часто используемые страницы данных в оперативной памяти.
    • Хранимые процедуры и триггеры (Stored Procedures / Triggers): Логика, выполняемая на стороне БД.

Пример создания связанных таблиц:

-- Создание таблицы Users
CREATE TABLE Users (
    id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    username VARCHAR(50) UNIQUE NOT NULL,
    email VARCHAR(100) UNIQUE NOT NULL
);

-- Создание таблицы Orders со ссылкой на Users
CREATE TABLE Orders (
    order_id INT PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
    user_id INT NOT NULL,
    amount DECIMAL(10,2),
    order_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    CONSTRAINT fk_user
        FOREIGN KEY(user_id)
        REFERENCES Users(id)
        ON DELETE CASCADE
);