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

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

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

История

Реляционная модель была предложена Эдгаром Коддом в 1970 году. Основная идея: вместо иерархических или сетевых структур использовать простые таблицы с чёткими связями.

1960s: Иерархические БД (сложно, медленно)
       ↓
1970s: Реляционная модель (Codd) ← Революция!
       ↓
1980s: SQL стандартизирован
       ↓
1990s+: Oracle, PostgreSQL, MySQL доминируют

Основные понятия

1. Таблица (Relation)

Таблица — это набор строк (записей) и столбцов (атрибутов).

Таблица "users":
┌────┬────────┬─────────────────┬───────────────────┐
│ id │ name   │ email           │ created_at        │
├────┼────────┼─────────────────┼───────────────────┤
│ 1  │ John   │ john@example.com│ 2025-01-15 10:30  │
│ 2  │ Jane   │ jane@example.com│ 2025-01-16 14:20  │
│ 3  │ Bob    │ bob@example.com │ 2025-01-17 09:45  │
└────┴────────┴─────────────────┴───────────────────┘

Таблица = Сущность (Entity)
Строка = Запись (Record)
Столбец = Атрибут (Field)

2. Ключи

Primary Key (Первичный ключ) — однозначно идентифицирует каждую строку

CREATE TABLE users (
  id INT PRIMARY KEY,  -- PK
  name VARCHAR(100),
  email VARCHAR(100) UNIQUE  -- Уникален, но не PK
);

Foreign Key (Внешний ключ) — связывает таблицы

CREATE TABLE orders (
  id INT PRIMARY KEY,
  user_id INT FOREIGN KEY REFERENCES users(id),  -- FK
  amount DECIMAL(10, 2)
);

-- Связь: order.user_id → user.id

3. Связи между таблицами

One-to-Many (1:N)

USERS                    ORDERS
┌────┐                   ┌────┬────────┐
│ id │                   │ id │user_id │
├────┤                   ├────┼────────┤
│ 1  │←──────one→        │ 1  │ 1      │  ← один user может иметь
│ 2  │  │                │ 2  │ 1      │    несколько orders
│ 3  │  many             │ 3  │ 2      │
└────┘                   └────┴────────┘

SQL:
SELECT u.name, o.id
FROM users u
JOIN orders o ON u.id = o.user_id

Many-to-Many (M:N)

STUDENTS                 STUDENT_COURSES     COURSES
┌────┐                   ┌─────┬──────────┐   ┌────┐
│ id │                   │stud │ course   │   │ id │
├────┤                   ├─────┼──────────┤   ├────┤
│ 1  │←──many──junction──┤ 1   │ 101      │   │ 101│
│ 2  │    table  many───→│ 1   │ 102      │   │ 102│
│ 3  │                   │ 2   │ 101      │   │ 103│
└────┘                   └─────┴──────────┘   └────┘

SQL (find students in course 101):
SELECT s.name
FROM students s
JOIN student_courses sc ON s.id = sc.student_id
WHERE sc.course_id = 101

One-to-One (1:1) (редко)

USERS              USER_PROFILES
┌────┐             ┌────┬────────┐
│ id │             │ id │user_id │
├────┤             ├────┼────────┤
│ 1  │←────1→1────→│ 1  │ 1      │
│ 2  │             │ 2  │ 2      │
└────┘             └────┴────────┘

Когда нужно разделить большую таблицу
на часто используемые + редко используемые поля

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

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

Первая нормальная форма (1NF)

Все значения атомарны (не содержат списки).

❌ Не нормализовано (1NF violation):
CREATE TABLE students (
  id INT,
  name VARCHAR(100),
  courses VARCHAR(255)  -- '101, 102, 103' — список!
);

✅ Нормализовано (1NF):
CREATE TABLE students (id INT, name VARCHAR(100));
CREATE TABLE student_courses (student_id INT, course_id INT);

Вторая нормальная форма (2NF)

Нет частичных зависимостей от PK (только составной PK).

❌ 2NF violation:
CREATE TABLE orders (
  order_id INT,
  product_id INT,
  product_name VARCHAR(100),  -- зависит только от product_id, не от order_id
  PRIMARY KEY (order_id, product_id)
);

✅ 2NF:
CREATE TABLE orders (order_id INT, product_id INT);
CREATE TABLE products (id INT PRIMARY KEY, name VARCHAR(100));

Третья нормальная форма (3NF)

Нет транзитивных зависимостей (не-ключевые атрибуты не зависят от других не-ключевых атрибутов).

❌ 3NF violation:
CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(100),
  department_id INT,
  department_name VARCHAR(100)  -- зависит от department_id, не от user_id
);

✅ 3NF:
CREATE TABLE users (id INT, name VARCHAR(100), department_id INT);
CREATE TABLE departments (id INT, name VARCHAR(100));

SQL (Structured Query Language)

Реляционные БД используют SQL — стандартный язык для запросов.

Основные операции (CRUD)

-- CREATE (вставка)
INSERT INTO users (name, email) VALUES ('John', 'john@example.com');

-- READ (чтение)
SELECT name, email FROM users WHERE id = 1;

-- UPDATE (обновление)
UPDATE users SET email = 'newemail@example.com' WHERE id = 1;

-- DELETE (удаление)
DELETE FROM users WHERE id = 1;

Сложные запросы (JOIN, GROUP BY)

-- Join: объединение таблиц
SELECT u.name, COUNT(o.id) as order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id
HAVING COUNT(o.id) > 5
ORDER BY order_count DESC;

-- Результат:
name  │ order_count
──────┼─────────────
John  │ 12
Jane  │ 8
Bob   │ 6

ACID гарантии

Основное отличие реляционных БД — они гарантируют ACID свойства для транзакций.

Atomicity (Атомарность) Транзакция либо полностью выполняется, либо полностью откатывается.

BEGIN TRANSACTION
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;  -- Счёт A
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;  -- Счёт B
COMMIT;

-- Если строка 2 не найдена → вся транзакция откатывается
-- Деньги не зависнут в "никуда"

Consistency (Согласованность) Данные всегда в правильном состоянии (constraints соблюдаются).

-- Правило: сумма всех счётов = const
INSERT INTO accounts VALUES (3, -100);  -- ❌ ERROR (нарушает constraint)

Isolation (Изоляция) Одновременные транзакции не влияют друг на друга.

TransactionA: читает счёт A = 100
TransactionB: переводит 50 со счёта A
TransactionA: всё ещё видит 100 (не видит незафиксированные изменения)

Durability (Долговечность) Когда транзакция committed, данные сохранены на диск и не потеряются.

Babank server crashes → PostgreSQL восстанавливается → данные целы

Архитектура RDBMS

Application Layer
    ↓
SQL Parser & Optimizer
    ↓
Query Executor
    ↓
Buffer Manager (кэш)
    ↓
Storage Engine
    ↓
Disk (Hard Drive / SSD)

Пример:
SELECT * FROM users WHERE id = 1
    ↓ Parser: корректный SQL?
    ↓ Optimizer: какой план запроса самый быстрый?
    ↓ Executor: выполнить план
    ↓ Buffer: проверить кэш, не там ли результат?
    ↓ Storage: если нет, прочитать с диска
    ↓ Return результат

Популярные RDBMS

Преимущества реляционных БД

✅ ACID гарантии — надежность ✅ Нормализация — без дублирования ✅ SQL — мощный и стандартизированный язык ✅ Referential integrity — консистентность через FK ✅ Индексы — быстрые запросы ✅ Транзакции — многоуровневые операции

Ограничения

❌ Горизонтальное масштабирование сложное — sharding трудно ❌ Гибкость схемы — изменение структуры требует миграции ❌ Big data — медленные на петабайт-scale ❌ Несоответствие объектам — нужно сворачивать объекты в таблицы

Когда использовать

✅ Финансовые системы — нужны ACID ✅ ERP/CRM — структурированные данные ✅ Многих, пересекающихся запросов — SQL мощный ✅ Compliance-heavy системы — аудит и constraints

❌ Не подходит для:

• Петабайт-scale data (BigTable, HBase лучше)
• Неструктурированные данные (NoSQL лучше)
• Real-time analytics (Data warehouse лучше)

Заключение

Реляционная база данных — это основной выбор для корпоративных приложений. Она обеспечивает:

• Надежность через ACID
• Организованность через нормализацию
• Мощность через SQL
• Целостность через constraints

Для 90% бизнес-приложений реляционная БД — это правильный выбор.