Какие знаешь виды связей в БД?

Виды связей в базах данных

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

Основные виды связей

1. One-to-One (Один-к-одному)

Каждая запись в первой таблице соответствует максимум одной записи во второй таблице, и наоборот.

Пример: Пользователь и его профиль

Таблица Users:
┌────┬─────────┬──────────┐
│ id │  name   │  email   │
├────┼─────────┼──────────┤
│ 1  │ Alice   │ a@ex.com │
│ 2  │ Bob     │ b@ex.com │
└────┴─────────┴──────────┘

Таблица Profiles:
┌────┬─────────┬────────┬──────────────┐
│ id │ user_id │ avatar │ bio          │
├────┼─────────┼────────┼──────────────┤
│ 1  │ 1       │ alice  │ Developer    │
│ 2  │ 2       │ bob    │ Designer     │
└────┴─────────┴────────┴──────────────┘

Связь: user_id (FK) в Profiles ссылается на id в Users
Шпора: каждый User имеет РОВНО один Profile

Особенности:

• Редкая в практике (обычно информацию объединяют в одну таблицу)
• Используется для разделения данных по причинам производительности или безопасности
• Foreign Key может быть и в первой, и во второй таблице
• Гарантируется UNIQUE constraint на FK

2. One-to-Many (Один-ко-многим)

Одна запись в первой таблице может соответствовать нескольким записям во второй таблице.

Пример: Пользователь и его заказы

Таблица Users:
┌────┬─────────┐
│ id │  name   │
├────┼─────────┤
│ 1  │ Alice   │
│ 2  │ Bob     │
└────┴─────────┘

Таблица Orders:
┌────┬─────────┬──────────┐
│ id │ user_id │  amount  │
├────┼─────────┼──────────┤
│ 101│ 1       │ $100     │
│ 102│ 1       │ $250     │
│ 103│ 2       │ $75      │
│ 104│ 1       │ $50      │
└────┴─────────┴──────────┘

Связь: user_id (FK) в Orders ссылается на id в Users
Шпора: один User может иметь МНОГО Orders

Особенности:

• Наиболее распространенная связь в реальных БД
• Foreign Key находится на стороне "многих"
• Нет UNIQUE constraint на FK
• Позволяет структурировать иерархические данные

Пример: Department и Employees

Departments:
- IT (dept_id = 1)
- Sales (dept_id = 2)
- HR (dept_id = 3)

Employees:
- Alice, dept_id = 1
- Bob, dept_id = 1
- Charlie, dept_id = 2
- Diana, dept_id = 1

Один Department имеет МНОГО Employees

3. Many-to-Many (Много-ко-многим)

Много записей в первой таблице могут соответствовать многим записям во второй таблице.

Пример: Студенты и курсы

Таблица Students:
┌────┬──────────┐
│ id │  name    │
├────┼──────────┤
│ 1  │ Alice    │
│ 2  │ Bob      │
│ 3  │ Charlie  │
└────┴──────────┘

Таблица Courses:
┌────┬────────────────┐
│ id │ title          │
├────┼────────────────┤
│ 101│ Python Basics  │
│ 102│ Web Dev        │
│ 103│ Data Science   │
└────┴────────────────┘

Таблица Enrollments (связующая таблица):
┌────┬─────────┬───────────┐
│ id │ stud_id │ course_id │
├────┼─────────┼───────────┤
│ 1  │ 1       │ 101       │
│ 2  │ 1       │ 102       │
│ 3  │ 2       │ 101       │
│ 4  │ 3       │ 103       │
│ 5  │ 3       │ 102       │
└────┴─────────┴───────────┘

Да:
- Alice записана на Python и Web Dev
- Python Basics посещают Alice и Bob

Особенности:

• Требует связующую (junction/pivot) таблицу
• Связующая таблица содержит FK для обеих таблиц
• Первичный ключ связующей таблицы обычно составной (stud_id, course_id)
• Можно добавить дополнительные поля в связующую таблицу

Пример с доп. полями:

Enrollments:
┌────┬─────────┬───────────┬──────────┬────────┐
│ id │ stud_id │ course_id │ grade    │ status │
├────┼─────────┼───────────┼──────────┼────────┤
│ 1  │ 1       │ 101       │ A        │ active │
│ 2  │ 1       │ 102       │ B        │ passed │
│ 3  │ 2       │ 101       │ C        │ active │
│ 4  │ 3       │ 103       │ NULL     │ active │
│ 5  │ 3       │ 102       │ A        │ passed │
└────┴─────────┴───────────┴──────────┴────────┘

Дополнительные виды связей

4. Self-Referencing (Самоссылающаяся связь)

Таблица содержит ссылку на саму себя (обычно через parent_id).

Пример: Иерархия сотрудников (employee -> manager)

Таблица Employees:
┌────┬─────────┬──────────────┐
│ id │  name   │ manager_id   │
├────┼─────────┼──────────────┤
│ 1  │ CEO     │ NULL         │
│ 2  │ VP Eng  │ 1            │
│ 3  │ VP Sales│ 1            │
│ 4  │ Alice   │ 2            │
│ 5  │ Bob     │ 2            │
│ 6  │ Charlie │ 3            │
└────┴─────────┴──────────────┘

Структура:
CEO (1)
├─ VP Eng (2)
│  ├─ Alice (4)
│  └─ Bob (5)
└─ VP Sales (3)
   └─ Charlie (6)

Особенности:

• FK ссылается на тот же первичный ключ в той же таблице
• Используется для древовидных и графовых структур
• Может привести к проблемам с производительностью для глубоких деревьев

Пример: Категории товаров

Categories:
- Electronics (id=1, parent=NULL)
  - Computers (id=2, parent=1)
    - Laptops (id=3, parent=2)
    - Desktops (id=4, parent=2)
  - Phones (id=5, parent=1)

5. Через промежуточную таблицу (Indirect relations)

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

Пример: Клиент → Заказ → Товар

Customers ----1-to-Many---- Orders ----Many-to-Many---- Products
  (id)                       (customer_id, id)          (id)
                                                    |
                                            Order Items (junction)
                                      (order_id, product_id, qty)

Кардинальность связей

Нотация ER диаграмм (Entity-Relationship diagrams):

1:1   One-to-One
1:N   One-to-Many (или One-to-Many)
M:N   Many-to-Many
0..1  Optional (может быть NULL)
1..1  Mandatory (не может быть NULL)

Примеры нотации:

User 1------N Orders
(один пользователь имеет много заказов)

Student M------N Courses
(много студентов для много курсов)

Person 1------1 Passport
(каждый человек имеет один паспорт)

Cascade Actions (Каскадные операции)

Определяют, что происходит при удалении или обновлении связанной записи:

ON DELETE CASCADE

CREATE TABLE Orders (
  id INT PRIMARY KEY,
  customer_id INT,
  FOREIGN KEY (customer_id) REFERENCES Customers(id)
    ON DELETE CASCADE
);

-- Если удалить customer_id=5, удалятся и все его заказы

ON DELETE SET NULL

CREATE TABLE Comments (
  id INT PRIMARY KEY,
  post_id INT,
  FOREIGN KEY (post_id) REFERENCES Posts(id)
    ON DELETE SET NULL
);

-- Если удалить post, комментарии останутся, но post_id=NULL

ON DELETE RESTRICT (или NO ACTION)

CREATE TABLE OrderItems (
  id INT PRIMARY KEY,
  product_id INT,
  FOREIGN KEY (product_id) REFERENCES Products(id)
    ON DELETE RESTRICT
);

-- Нельзя удалить product, если на него есть ссылки

Таблица сравнения типов связей

Практические рекомендации

1. Выбор типа связи

• Анализируй бизнес-логику: сколько "А" может быть для одного "Б"?
• Помни о нормализации БД (обычно до 3NF)
• Денормализируй только если есть веская причина (производительность)

2. Foreign Keys

• Всегда добавляй FK constraints для целостности
• Используй meaningful имена (user_id, not uid)
• Помни о cascade rules

3. Индексы

• Индексируй FK для быстрых joins
• Рассмотри индексы на часто используемых связях

4. Избегай проблем

• Circular references (A→B→C→A) обычно плохо
• Слишком много уровней self-reference = медленно
• M:N таблицы могут стать узким местом при масштабировании

Понимание видов связей в БД позволяет проектировать эффективные и надежные схемы, которые правильно отражают бизнес-логику и обеспечивают целостность данных.