SQL

БЛОК 1. Основы реляционных БД — 1. Что такое реляционная база данных

📚 24 вопросовПройти тест →
Лекция

БЛОК 1. Основы реляционных БД — 1. Что такое реляционная база данных

SQL

1. Что такое реляционная база данных

🧭 Введение: почему «просто хранить в файлах» быстро перестаёт работать

На старте проекта кажется, что можно хранить данные в JSON/CSV-файлах: просто, быстро и без «лишней инфраструктуры».
Проблема начинается, когда данные начинают менять несколько пользователей одновременно, появляются связи между сущностями и требования к надёжности.
Реляционная база данных (RDBMS) решает эти задачи за счёт чёткой структуры, ограничений и транзакций.
Вместо хаотичного хранения мы получаем управляемую модель данных, которую можно масштабировать и безопасно развивать.
💡 Совет: Смотрите на БД не как на «место хранения», а как на механизм защиты целостности бизнес-данных.
✅ Вывод: Реляционная БД нужна не только для хранения, но и для контроля качества данных, связей и совместной работы с ними.

⚠️ Проблема -> решение

Когда данные хранятся в файлах, обычно возникают одни и те же боли: дубли, конфликтующие версии, отсутствие единого стандарта и ошибки при обновлениях.
Например, email пользователя может быть разным в двух файлах, а заказ может ссылаться на несуществующего пользователя.
Реляционная модель решает это через:
  • таблицы с понятной структурой;
  • ключи и ограничения;
  • связи между таблицами;
  • единые правила чтения и изменения данных.
🟢 Если совсем просто: Файлы хранят данные, а СУБД ещё и следит, чтобы данные не ломались.
🎯 Как понять, что этап прошёл успешно: У вас есть схема данных, где невозможно сохранить «битые» связи и явные противоречия.

🛠️ Чем помогает и как работает

Реляционная БД помогает сделать данные предсказуемыми: каждая сущность хранится в своей таблице, а связи между сущностями формализованы.
Это снижает количество ошибок в логике приложения и упрощает поддержку.
Как это работает:
  • Шаг 1: проектируются сущности и их атрибуты (users, orders, products).
  • Шаг 2: для каждой таблицы выбирается первичный ключ (PRIMARY KEY).
  • Шаг 3: связи между таблицами задаются через внешние ключи (FOREIGN KEY).
  • Шаг 4: ограничения (NOT NULL, UNIQUE, CHECK) защищают бизнес-правила.
  • Шаг 5: SQL-запросы читают и меняют данные единообразно.
  • Шаг 6: транзакции гарантируют, что связанные изменения применяются целиком или откатываются.
✅ Вывод: Реляционная БД это система, где структура, связи и ограничения работают вместе и предотвращают хаос в данных.

📚 Ключевые термины (простыми словами)

  • Таблица (table) — структура хранения одного типа сущностей.
  • Строка (row) — одна запись в таблице.
  • Столбец (column) — конкретное поле данных.
  • Первичный ключ (primary key) — уникальный идентификатор записи.
  • Внешний ключ (foreign key) — ссылка на запись в другой таблице.
  • Целостность данных (data integrity) — корректность и непротиворечивость данных.
  • СУБД (DBMS/RDBMS) — система управления базой данных.

🧱 1. Таблица, строка, столбец: базовая модель данных

Таблица описывает один тип данных, например пользователей.
Строка хранит конкретный экземпляр (одного пользователя), а столбцы описывают свойства (email, дата регистрации, статус).
🟢 Если совсем просто: Таблица — как таблица в Excel, но с чёткими правилами и контролем качества данных.
🎯 Как понять, что этап прошёл успешно: По структуре таблицы можно без догадок понять, какие данные и в каком формате она хранит.
Назначение: Организовать данные в предсказуемую структуру для чтения, обновления и анализа.
Простыми словами: Таблица отвечает на вопрос «что храним», строка — «какой именно объект», столбец — «какое свойство объекта».
Для новичка: Если видите строку в users, это один пользователь; если видите столбец email, это поле, где у каждого пользователя будет его email.
Аналогия: Классный журнал: каждая строка — ученик, столбцы — предметы/оценки.
Пример:
CREATE TABLE users (  id BIGSERIAL PRIMARY KEY,  email VARCHAR(255) NOT NULL,  full_name VARCHAR(255) NOT NULL,  created_at TIMESTAMP NOT NULL DEFAULT NOW());
🔎 Как это происходит на практике: Сначала команда фиксирует поля, которые нужны бизнесу, затем определяет обязательность каждого поля и только после этого создаёт таблицу.
Характеристики:
  • ✅ одна таблица описывает одну логическую сущность;
  • ✅ каждая строка соответствует одному объекту;
  • ✅ каждый столбец хранит один тип значения.
Когда использовать: Всегда, когда данные нужно хранить долго, безопасно и с возможностью развития схемы.
✅ Вывод: Без модели «таблица-строка-столбец» невозможно построить понятную и масштабируемую систему данных.

🆔 2. Первичный ключ: как отличать записи друг от друга

Если в таблице нет уникального идентификатора, быстро появляется путаница: невозможно надёжно сослаться на конкретную запись.
PRIMARY KEY решает это: каждая строка получает уникальный и стабильный идентификатор.
🟢 Если совсем просто: Первичный ключ — «паспортный номер» строки.
🎯 Как понять, что этап прошёл успешно: Любую запись можно однозначно найти по одному ключу, без неоднозначности.
Назначение: Гарантировать уникальность записи и быть точкой привязки для связей.
Простыми словами: PRIMARY KEY не повторяется и не бывает NULL, поэтому запись всегда можно однозначно идентифицировать.
Для новичка: Даже если два пользователя с одинаковым именем, id у них всегда разный.
Аналогия: Номер заказа в магазине: название товара может повторяться, номер заказа — нет.
Пример:
CREATE TABLE products (  id BIGSERIAL PRIMARY KEY,  sku VARCHAR(64) UNIQUE NOT NULL,  name VARCHAR(255) NOT NULL);
🔎 Как это происходит на практике: Команда выбирает ключ (обычно id) и использует его в API, связях и логах, чтобы исключить «угадывание» по имени или текстовым полям.
Характеристики:
  • ✅ уникальный;
  • ✅ NOT NULL;
  • ✅ стабильный для ссылок и интеграций.
Когда использовать: Для каждой таблицы без исключений.
✅ Вывод: PRIMARY KEY это основа адресуемости данных и корректных связей между таблицами.

🔗 3. Связи между таблицами: 1-1, 1-N, N-N

Реальные данные почти всегда связаны: пользователь делает заказы, заказ содержит товары.
Реляционная модель позволяет описать эти связи явно, а не хранить всё в одной таблице.
🟢 Если совсем просто: Связи показывают, как одни записи «соединяются» с другими.
🎯 Как понять, что этап прошёл успешно: Схема отвечает на вопрос «кто с кем связан» без дублирования и ручных «ID в тексте».
Назначение: Связать сущности между собой через FOREIGN KEY и сохранить целостность.
Простыми словами: FOREIGN KEY указывает, что значение в одной таблице должно существовать в другой.
Для новичка: Если заказ хранит user_id, то этот пользователь обязан реально существовать в таблице users.
Аналогия: Билет в кино: билет ссылается на конкретный сеанс. Нельзя продать билет на сеанс, которого нет.
Пример:
CREATE TABLE orders (  id BIGSERIAL PRIMARY KEY,  user_id BIGINT NOT NULL REFERENCES users(id),  total_amount NUMERIC(12,2) NOT NULL);
🔎 Как это происходит на практике: Сначала проектируют связи 1-N (например, один пользователь -> много заказов), затем добавляют таблицу-связку для N-N (orders_products).
Характеристики:
  • ✅ 1-1: одна запись связана с одной;
  • ✅ 1-N: одна запись связана с многими;
  • ✅ N-N: многие с многими через таблицу-связку.
Когда использовать: Когда сущности логически зависят друг от друга и нужны join-запросы.
✅ Вывод: Правильно заданные связи делают данные связными, а аналитику и бизнес-операции — надёжными.

🛡️ 4. Целостность данных: как БД защищает систему от «битых» записей

Целостность данных это гарантия, что в БД нет противоречивых или невозможных состояний.
Эта защита работает автоматически через ограничения, а не «только на совести разработчика».
🟢 Если совсем просто: Ограничения в БД — это автоматический контроль качества данных.
🎯 Как понять, что этап прошёл успешно: Попытка записать некорректные данные завершается ошибкой, а не «тихим» сохранением.
Назначение: Защитить данные от дублей, пустых критичных полей и неверных связей.
Простыми словами: БД отклоняет записи, которые нарушают правила: NULL там, где нельзя, дубли там, где нужна уникальность, несуществующие ссылки.
Для новичка: Если поле email помечено как UNIQUE, два одинаковых email не сохранятся.
Аналогия: Турникет на входе: без действительного пропуска пройти нельзя.
Пример:
CREATE TABLE users (  id BIGSERIAL PRIMARY KEY,  email VARCHAR(255) UNIQUE NOT NULL,  age INT CHECK (age >= 0));
🔎 Как это происходит на практике: Бизнес-правила переводятся в ограничения БД, чтобы ошибки не попадали в прод через баги в приложении.
Характеристики:
  • ✅ UNIQUE предотвращает дубли;
  • ✅ NOT NULL требует обязательные значения;
  • ✅ CHECK валидирует диапазоны/условия;
  • ✅ FOREIGN KEY контролирует существование связанной записи.
Когда использовать: Всегда для критичных полей и связей, где ошибка приводит к потере денег/доверия/данных.
✅ Вывод: Целостность данных должна быть встроена в БД, а не только в код приложения.

📦 5. СУБД vs хранение в файлах: практическая разница

Файлы подходят для простых, локальных или временных данных, где нет жёстких требований к конкурентному доступу и целостности.
СУБД нужна, когда данные используются несколькими процессами, требуют гарантии консистентности и масштабируемого доступа.
🟢 Если совсем просто: Файл — «просто лежит», СУБД — «управляет, защищает и обслуживает данные».
🎯 Как понять, что этап прошёл успешно: Вы можете объяснить, почему для вашего кейса нужен именно уровень СУБД (а не просто JSON-файл).
Назначение: Показать границу, где файлы перестают быть безопасным решением.
Простыми словами: СУБД даёт транзакции, индексы, блокировки, SQL и контроль целостности — у файлов этого нет «из коробки».
Для новичка: Если одновременно работают веб-приложение, админка и отчёты, файл легко «сломать», а СУБД рассчитана на такую нагрузку.
Аналогия: Файл — блокнот у одного человека. СУБД — офисная система с правилами, версиями и контролем доступа.
Пример сравнения:
КритерийСУБДФайлы
Конкурентная записьУправляется транзакциями/блокировкамиКонфликты и перезаписи
ЦелостностьОграничения и связиНа уровне самописной логики
Поиск/аналитикаSQL, индексы, JOINРучной парсинг
МасштабированиеРепликация, backup, мониторингОграничено
🔎 Как это происходит на практике: Команда стартует с простой модели, но при росте функциональности переносит критичные данные в СУБД, чтобы исключить операционные риски.
Характеристики:
  • ✅ предсказуемость в многопользовательской среде;
  • ✅ управляемость изменений;
  • ✅ высокая проверяемость и аудит.
Когда использовать: Когда данные становятся частью бизнес-процесса, а не временным кэшем.
✅ Вывод: Файлы хороши для простых задач, но бизнес-критичные данные должны жить в СУБД.

📌 Must-know факты

  • PRIMARY KEY всегда уникален и не может быть NULL.
  • FOREIGN KEY защищает от ссылок на несуществующие записи.
  • Целостность данных должна проверяться на уровне БД, а не только в приложении.
  • Разделяйте сущности по таблицам: users, orders, products, а не «одна универсальная таблица».
  • Рост проекта почти всегда приводит к потребности в СУБД даже при «файловом старте».

🧨 Частые мифы

❌ Миф: «Если данных мало, структура не важна». ✅ Как правильно: Даже маленькая система должна иметь корректную схему, иначе при росте вы получите дорогостоящий рефакторинг. 📎 Почему это важно: Ошибки структуры на старте масштабируются вместе с продуктом.
❌ Миф: «PRIMARY KEY нужен только для больших таблиц». ✅ Как правильно: PRIMARY KEY нужен в каждой таблице, независимо от объёма данных. 📎 Почему это важно: Без ключа сложно строить связи, API и безопасные обновления.
❌ Миф: «Целостность можно полностью оставить на backend-код». ✅ Как правильно: Критичные проверки должны быть и в коде, и в БД. 📎 Почему это важно: БД — последний барьер от некорректных данных.
❌ Миф: «JSON-файл всегда проще и поэтому лучше». ✅ Как правильно: Файлы проще только до момента, когда появляются связи, конкуренция и отчётность. 📎 Почему это важно: Отсутствие транзакций и ограничений приводит к нестабильным данным.

❓ Часто спрашивают на собеседованиях

❓ Вопрос: Что такое реляционная база данных и в чём её главное отличие от файлового хранения? ✅ Ответ: Это система хранения данных в связанных таблицах с чёткой схемой, ключами и ограничениями. В отличие от файлового хранения, СУБД обеспечивает целостность, транзакции и безопасную конкурентную работу.
❓ Вопрос: Зачем нужен PRIMARY KEY? ✅ Ответ: PRIMARY KEY однозначно идентифицирует каждую запись, предотвращает дубли и служит точкой для построения внешних связей.
❓ Вопрос: Что такое FOREIGN KEY на практике? ✅ Ответ: FOREIGN KEY гарантирует, что ссылка на связанную запись валидна, например заказ нельзя привязать к несуществующему пользователю.
❓ Вопрос: Почему целостность нельзя оставлять только на приложение? ✅ Ответ: Потому что данные могут попадать в БД разными путями, и без ограничений БД некорректные значения всё равно будут сохранены.
❓ Вопрос: Когда файлы перестают быть подходящим хранилищем? ✅ Ответ: Когда появляются связи между сущностями, параллельные изменения, требования к отчётности и необходимость гарантированной консистентности.

🚫 Типичные ошибки

Ошибка 1: хранить разные сущности в одной «универсальной» таблице

❌ Неправильно: Смешивать пользователей, заказы и товары в одной структуре.
✅ Правильно: Разделять сущности на отдельные таблицы и связывать их ключами.
Почему: Иначе растут дубли, сложность запросов и риск логических конфликтов.

Ошибка 2: использовать бизнес-поля как единственный идентификатор

❌ Неправильно: Считать email или имя устойчивым ключом для всех связей.
✅ Правильно: Использовать отдельный технический PRIMARY KEY (id), а бизнес-поля валидировать отдельными ограничениями.
Почему: Бизнес-значения могут меняться, а связи должны оставаться стабильными.

Ошибка 3: не задавать ограничения в БД

❌ Неправильно: Оставлять таблицы без NOT NULL, UNIQUE, CHECK.
✅ Правильно: Формализовать ключевые правила на уровне схемы.
Почему: Это снижает число дефектов и упрощает диагностику.

Ошибка 4: игнорировать связи до появления багов

❌ Неправильно: Сначала писать «быстро», а потом пытаться задним числом восстанавливать связи.
✅ Правильно: Проектировать связи в момент проектирования таблиц.
Почему: Исправление структуры после запуска дороже и рискованнее.

Ошибка 5: выбирать типы данных «на глаз»

❌ Неправильно: Хранить всё в TEXT «на всякий случай».
✅ Правильно: Подбирать тип по смыслу поля и будущим запросам.
Почему: Корректный тип упрощает валидацию, индексацию и производительность.

✅ Best Practices

  • Сначала проектируйте сущности и связи, потом пишите CRUD.
  • Для каждой таблицы задавайте PRIMARY KEY.
  • Переносите бизнес-правила в ограничения БД, а не только в код.
  • Документируйте связи 1-1 / 1-N / N-N на уровне схемы.
  • Проверяйте схему на примере реальных сценариев (создание заказа, отмена, отчёты).

🧾 Заключение

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

Ключевые мысли

  • Таблица, строка и столбец — базовый строительный блок модели.
  • PRIMARY KEY и FOREIGN KEY — основа идентичности и связности.
  • Целостность должна быть встроена в БД через ограничения.
  • СУБД выигрывает у файлов в надёжности, масштабировании и управляемости.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 1. Основы реляционных БД — 1. Что такое реляционная база данных»

Пройти тест →