Зачем нужны базы данных и СУБД

Разбираемся, почему хранить данные в файлах быстро становится больно и какой класс проблем берёт на себя система управления базами данных.

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

Зачем вообще выделять данные в отдельный ресурс

Любая нетривиальная программа что-то запоминает: список товаров, заказы клиентов, выданные книги. Пока данных мало, кажется, что достаточно текстового файла или таблицы в формате CSV. Но как только приложением начинают пользоваться несколько человек одновременно, а объём растёт до миллионов записей, наивное хранение разваливается. Именно повторяющаяся боль с файлами в 1960-х годах привела к появлению отдельного класса систем — СУБД. Идея проста и революционна одновременно: данные — это самостоятельный ресурс предприятия, который живёт дольше, чем любая отдельная программа, и должен управляться централизованно, а не быть приложением к коду.

Что не так с хранением в файлах

Представим интернет-магазин, который хранит каждую сущность в своём файле: clients.txt, orders.txt, products.txt. Очень быстро всплывают системные проблемы, и они не случайны — это родовые болезни файлового подхода.

• Избыточность и несогласованность. Имя клиента дублируется в каждом его заказе. Клиент сменил фамилию — и теперь в базе он одновременно «Иванова» и «Петрова», смотря какой файл читать. Согласованность данных никто не гарантирует.
• Зависимость программ от формата хранения. Каждая программа знает физическую раскладку файла: где начинается поле, какой разделитель. Добавили колонку — и десяток программ нужно переписать. Это называется зависимостью данных, и реляционная модель родилась во многом ради борьбы с ней.
• Проблемы одновременного доступа. Два менеджера оформляют заказ одновременно — и один перезаписывает изменения другого. Без специального механизма параллельный доступ ведёт к потере данных.
• Целостность и проверки. Кто гарантирует, что в заказе указан существующий товар, а цена не отрицательна? В файловом подходе — только дисциплина программиста, то есть, по сути, никто.
• Восстановление после сбоя. Питание пропало посреди записи в файл — и он испорчен. Вернуть данные в осмысленное состояние нечем.
• Безопасность и разграничение доступа. Бухгалтеру нужны суммы, но не пароли клиентов. На уровне файлов тонко разграничить права почти невозможно.

Что СУБД берёт на себя

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

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

Маленький пример: те же данные в реляционной форме

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

CREATE TABLE clients (
  id   INTEGER PRIMARY KEY,
  name TEXT NOT NULL
);
CREATE TABLE orders (
  id        INTEGER PRIMARY KEY,
  client_id INTEGER NOT NULL,
  summa     INTEGER NOT NULL
);

INSERT INTO clients VALUES (1, 'Анна'), (2, 'Борис');
INSERT INTO orders  VALUES (10, 1, 1500), (11, 1, 800), (12, 2, 2300);

SELECT o.id AS zakaz, c.name AS klient, o.summa
FROM orders o
JOIN clients c ON c.id = o.client_id
ORDER BY o.id;

Имя клиента хранится один раз — в таблице clients. Сменится фамилия — правим в одном месте, и все заказы автоматически «увидят» новое имя. Это и есть устранение избыточности, ради которого всё затевалось.

Немного истории: откуда всё пошло

Полезно понимать контекст. В 1960-е годы данные хранили в плоских файлах, и каждое приложение тащило за собой собственный код доступа к ним. Прорыв случился в 1970 году, когда математик Эдгар Кодд, работавший в IBM, опубликовал статью «A Relational Model of Data for Large Shared Data Banks». Он предложил отделить логическое представление данных от физического и описывать данные строго, на языке теории множеств. Это была не просто новая технология, а смена парадигмы: данные стали независимым, формально описанным ресурсом. На этой идее выросли все современные реляционные СУБД, а сам Кодд позже сформулировал набор правил (известных как «12 правил Кодда»), которым должна удовлетворять система, чтобы по праву называться реляционной. Мы будем опираться на его модель весь курс.

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

Данные, СУБД и база данных — не путаем термины

Эти три понятия часто смешивают, но различать их важно. Данные — сами факты (имя клиента, сумма заказа). База данных — конкретный организованный набор таких данных для предметной области. СУБД — универсальная программа (PostgreSQL, MySQL, SQLite, Oracle), которая умеет создавать и обслуживать любые базы данных. PostgreSQL — это СУБД; база интернет-магазина, развёрнутая в PostgreSQL, — это база данных; «Анна, 1500 рублей» — это данные.

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

Когда СУБД избыточна

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

Ограничение целостности в действии

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

CREATE TABLE products (
  id   INTEGER PRIMARY KEY,
  name TEXT NOT NULL,
  cena INTEGER NOT NULL CHECK (cena >= 0)   -- цена не может быть отрицательной
);

INSERT INTO products VALUES (1, 'Книга', 500), (2, 'Кружка', 300);
SELECT name, cena FROM products ORDER BY cena;

Вывод: «Кружка — 300», «Книга — 500». Обе строки прошли проверку. А вот попытка вставить товар с cena = -100 была бы отвергнута ограничением CHECK — СУБД не позволит данным стать некорректными. В файловом подходе такую проверку пришлось бы дублировать в каждой программе, которая пишет в файл, и одна забытая проверка испортила бы данные.

Типичные заблуждения

• «База данных и СУБД — одно и то же». Нет: СУБД — это движок, база данных — это контент в этом движке.
• «Раз есть SQL, значит, есть база данных». SQL — язык; данные можно хранить и без него (NoSQL), а сам SQL без хранилища бессмыслен.
• «Excel — это база данных». Таблица в Excel не даёт ни транзакций, ни целостности, ни параллельного доступа сотен пользователей — ключевых функций СУБД там нет.
• «Файлы всегда проще и быстрее». Для простых случаев — да; но при росте данных, пользователей и требований к целостности «простота» файлов оборачивается ручным переизобретением функций СУБД.

Итог

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