Реляционные базы данных: как устроены таблицы и связи

Реляционная база данных хранит данные в виде связанных таблиц. Это звучит просто — но именно эта простота сделала реляционные СУБД стандартом на 50 лет.

Почему «реляционная»

Термин от слова «relation» (отношение). В математике отношение — это таблица. Реляционная модель была предложена Эдгаром Коддом в 1970 году: данные хранятся в двумерных таблицах, связанных между собой.

Анатомия таблицы

Таблица: users
┌────┬──────────┬─────────────────┬───────────┐
│ id │ name     │ email           │ city      │
├────┼──────────┼─────────────────┼───────────┤
│  1 │ Анна     │ anna@mail.ru    │ Москва    │
│  2 │ Иван     │ ivan@gmail.com  │ СПб       │
│  3 │ Мария    │ maria@yandex.ru │ Москва    │
└────┴──────────┴─────────────────┴───────────┘

• Колонка (поле) — атрибут, у каждой есть тип данных
• Строка (запись) — один объект
• Ячейка — конкретное значение

Первичный ключ (Primary Key)

Уникальный идентификатор строки. Обычно id — автоинкрементное целое число или UUID.

Правила:

• Уникален для каждой строки
• Не может быть NULL
• Не меняется

CREATE TABLE users (
    id   SERIAL PRIMARY KEY,  -- автоинкремент
    name VARCHAR(100) NOT NULL,
    email VARCHAR(200) UNIQUE
);

Внешний ключ (Foreign Key)

Ссылка на первичный ключ другой таблицы. Создаёт связь между таблицами.

CREATE TABLE orders (
    id      SERIAL PRIMARY KEY,
    user_id INT REFERENCES users(id),  -- внешний ключ
    amount  DECIMAL(10,2),
    created_at TIMESTAMP DEFAULT NOW()
);

user_id в orders ссылается на id в users. Нельзя создать заказ для несуществующего пользователя — база защитит.

Типы связей

Один-ко-многим (1:N)

Один пользователь — много заказов. Самый частый тип.

users.id ←── orders.user_id
  (1)              (N)

Реализуется через внешний ключ в таблице «многих».

Многие-ко-многим (N:M)

Студент может записаться на много курсов, курс может иметь много студентов.

Реализуется через промежуточную таблицу:

CREATE TABLE student_courses (
    student_id INT REFERENCES students(id),
    course_id  INT REFERENCES courses(id),
    enrolled_at TIMESTAMP,
    PRIMARY KEY (student_id, course_id)
);

Один-к-одному (1:1)

Редко встречается. Пользователь — профиль. Используется чтобы разделить часто и редко используемые данные.

Нормализация

Нормализация — устранение избыточности данных.

Ненормализованная таблица (плохо):

Если Анна сменит email — нужно обновить все строки.

Нормализованные таблицы (хорошо):

users: id, name, email, city
orders: id, user_id, created_at
order_items: order_id, product_id, quantity, price
products: id, name, category

Каждый факт хранится один раз.

Индексы

Индекс — структура данных для быстрого поиска. Как содержание книги.

-- Без индекса: сканирует все 10 млн строк
SELECT * FROM orders WHERE user_id = 42;

-- С индексом: находит мгновенно
CREATE INDEX idx_orders_user_id ON orders(user_id);

Первичные ключи индексируются автоматически. Внешние ключи — нет (нужно добавлять явно).

Популярные СУБД

Для старта — PostgreSQL. Он наиболее полнофункциональный и часто встречается на собеседованиях.