Какие знаешь виды связей между сущностями?

Виды связей между сущностями

Понимание связей между сущностями — это фундаментальная часть проектирования баз данных. В моей практике я разрабатывал множество различных схем данных, и правильное моделирование связей критически важно для качества системы.

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

1. Связь "Один к одному" (One-to-One / 1:1)

Определение: Одна запись в таблице A связана с максимум одной записью в таблице B, и наоборот.

Реализация:

-- Таблица пользователей
CREATE TABLE users (
    id UUID PRIMARY KEY,
    name VARCHAR(255),
    email VARCHAR(255)
);

-- Таблица профилей (один профиль на одного пользователя)
CREATE TABLE profiles (
    id UUID PRIMARY KEY,
    user_id UUID UNIQUE NOT NULL,
    bio TEXT,
    avatar_url VARCHAR(255),
    FOREIGN KEY (user_id) REFERENCES users(id)
);

Примеры из практики:

• Пользователь — Профиль
• Сотрудник — Трудовая книжка
• Компания — Реквизиты банковского счета
• Паспорт — Граждане (в упрощенной модели)

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

• Логическое разделение данных (часто используемые vs редко используемые)
• Разделение информации по уровню доступа
• Связь между таблицами в разных системах

2. Связь "Один ко многим" (One-to-Many / 1:N)

Определение: Одна запись в таблице A может быть связана со многими записями в таблице B, но каждая запись в B связана только с одной записью в A.

Реализация:

-- Таблица постов
CREATE TABLE posts (
    id UUID PRIMARY KEY,
    author_id UUID NOT NULL,
    title VARCHAR(255),
    content TEXT,
    FOREIGN KEY (author_id) REFERENCES users(id)
);

-- Таблица комментариев
CREATE TABLE comments (
    id UUID PRIMARY KEY,
    post_id UUID NOT NULL,
    author_id UUID NOT NULL,
    content TEXT,
    FOREIGN KEY (post_id) REFERENCES posts(id),
    FOREIGN KEY (author_id) REFERENCES users(id)
);

Примеры из практики:

• Один клиент — много заказов
• Один заказ — много товаров (через промежуточную таблицу)
• Один магазин — много продавцов
• Одна компания — много сотрудников

Реализация в SQL:

• Внешний ключ на стороне "многих" (comments.post_id ссылается на posts.id)

3. Связь "Много к многим" (Many-to-Many / N:M)

Определение: Одна запись в таблице A может быть связана со многими записями в таблице B, и наоборот.

Реализация:

-- Таблица студентов
CREATE TABLE students (
    id UUID PRIMARY KEY,
    name VARCHAR(255)
);

-- Таблица курсов
CREATE TABLE courses (
    id UUID PRIMARY KEY,
    name VARCHAR(255)
);

-- Промежуточная таблица (junction table)
CREATE TABLE student_courses (
    student_id UUID NOT NULL,
    course_id UUID NOT NULL,
    enrollment_date TIMESTAMP,
    grade VARCHAR(5),
    PRIMARY KEY (student_id, course_id),
    FOREIGN KEY (student_id) REFERENCES students(id),
    FOREIGN KEY (course_id) REFERENCES courses(id)
);

Примеры из практики:

• Студенты — Курсы (один студент на много курсов, один курс для много студентов)
• Авторы — Книги (один автор может написать много книг, одна книга может иметь много авторов)
• Товары — Категории (один товар может быть в много категориях)
• Пользователи — Группы (один пользователь в много групп)
• Теги — Посты (один тег на много постов)

Реализация:

• Создается промежуточная (junction) таблица с внешними ключами на обе таблицы
• Составной первичный ключ из обоих внешних ключей

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

4. Иерархическая связь (Hierarchical / Self-Referencing)

Определение: Сущность связана сама с собой.

Реализация:

-- Таблица сотрудников с руководителем
CREATE TABLE employees (
    id UUID PRIMARY KEY,
    name VARCHAR(255),
    manager_id UUID,
    FOREIGN KEY (manager_id) REFERENCES employees(id)
);

-- Таблица категорий товаров (древовидная структура)
CREATE TABLE categories (
    id UUID PRIMARY KEY,
    name VARCHAR(255),
    parent_category_id UUID,
    FOREIGN KEY (parent_category_id) REFERENCES categories(id)
);

Примеры:

• Сотрудник — Начальник (тот же человек)
• Категория товара — Родительская категория
• Комментарий — Ответ на комментарий
• Задача — Подзадача

5. Полиморфная связь (Polymorphic Relationship)

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

Реализация (вариант 1 — с типом):

CREATE TABLE comments (
    id UUID PRIMARY KEY,
    content TEXT,
    commentable_type VARCHAR(50), -- 'post' или 'image'
    commentable_id UUID,
    created_at TIMESTAMP
);

Примеры:

• Комментарий может быть на пост, на изображение, на видео
• Уведомление может быть о разных типах событий
• Привязка документов к разным типам объектов

6. Связь через ассоциативный объект

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

Реализация:

-- Заказ содержит товары
CREATE TABLE order_items (
    id UUID PRIMARY KEY,
    order_id UUID NOT NULL,
    product_id UUID NOT NULL,
    quantity INTEGER,
    price DECIMAL(10,2),
    discount DECIMAL(10,2),
    FOREIGN KEY (order_id) REFERENCES orders(id),
    FOREIGN KEY (product_id) REFERENCES products(id)
);

Это расширенная версия связи "много к многим", где промежуточная таблица содержит дополнительные данные.

Специальные свойства связей

Обязательность (Optionality)

Обязательная связь (Mandatory):

CREATE TABLE posts (
    id UUID PRIMARY KEY,
    author_id UUID NOT NULL, -- всегда должен быть автор
    FOREIGN KEY (author_id) REFERENCES users(id)
);

Опциональная связь (Optional):

CREATE TABLE users (
    id UUID PRIMARY KEY,
    manager_id UUID, -- может быть NULL
    FOREIGN KEY (manager_id) REFERENCES users(id)
);

Каскадные операции

CREATE TABLE posts (
    id UUID PRIMARY KEY,
    author_id UUID NOT NULL,
    FOREIGN KEY (author_id) REFERENCES users(id)
        ON DELETE CASCADE       -- удаление пользователя удалит все его посты
        ON UPDATE CASCADE       -- изменение ID пользователя обновит ссылки
);

CREATE TABLE comments (
    id UUID PRIMARY KEY,
    post_id UUID NOT NULL,
    FOREIGN KEY (post_id) REFERENCES posts(id)
        ON DELETE RESTRICT      -- запретить удаление поста, если есть комментарии
);

Типы каскадных операций:

• CASCADE — применить операцию автоматически
• RESTRICT — запретить операцию
• SET NULL — установить NULL
• SET DEFAULT — установить значение по умолчанию
• NO ACTION — то же, что RESTRICT

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

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

• Все значения атомарные (неделимые)
• Нет повторяющихся групп

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

• Соответствует 1NF
• Все неключевые атрибуты полностью зависят от первичного ключа

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

• Соответствует 2NF
• Нет транзитивных зависимостей
• Неключевые атрибуты зависят только от первичного ключа

Денормализация: когда нарушать правила

Иногда я намеренно нарушаю правила нормализации ради производительности:

-- Денормализованное хранилище счетчика
CREATE TABLE posts_stats (
    post_id UUID PRIMARY KEY,
    comments_count INT,      -- может быть вычислено, но хранится для скорости
    likes_count INT,
    views_count INT,
    FOREIGN KEY (post_id) REFERENCES posts(id)
);

Когда денормализировать:

• Если часто нужны агрегирующие значения
• Если производительность критична
• Если можно гарантировать синхронизацию
• Если читаем чаще, чем пишем

Матрица выбора связей

Практические советы

1. Начните с нормализации — избегайте дублирования данных
2. Явно определяйте типы связей — это упрощает поддержку
3. Используйте каскадные операции — для поддержания целостности
4. Документируйте модель — ER диаграммы, комментарии в SQL
5. Тестируйте связи — убедитесь, что целостность поддерживается
6. Не бойтесь денормализировать — если есть обоснованные причины

Правильное моделирование связей между сущностями — это основа качественной архитектуры данных. От этого зависит как производительность, так и надежность системы.