Какие паттерны проектирования знаешь и когда применяешь в Node.js?

Как называются атрибуты выстраивания связи в таблицах?

В реляционных базах данных существует стандартная терминология для описания связей между таблицами. Это фундаментальные концепции, которые должен знать любой System Analyst.

Основные термины

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

Primary Key — уникальный идентификатор каждой записи в таблице.

Характеристики:

• Уникальность — каждое значение встречается только один раз
• Не null — всегда имеет значение
• Неизменяемость — не должен меняться после создания
• Один на таблицу — обычно один PK (может быть составной)

Пример:

CREATE TABLE users (
  id INT PRIMARY KEY,  -- Primary Key
  name VARCHAR(100)
);

2. Внешний ключ (Foreign Key, FK)

Foreign Key — ссылка на Primary Key другой таблицы, устанавливающая связь между таблицами.

Характеристики:

• Ссылка — указывает на PK другой таблицы
• Проверка referential integrity — БД не позволяет удалить родительскую запись, если на неё есть ссылки
• Может быть null — если связь необязательна
• Несколько FK — в одной таблице может быть много

Пример:

CREATE TABLE orders (
  id INT PRIMARY KEY,
  user_id INT,
  FOREIGN KEY (user_id) REFERENCES users(id)
    ON DELETE CASCADE  -- Удалить заказ если удалён пользователь
    ON UPDATE CASCADE  -- Обновить если обновлён user_id
);

Типы связей (Relationships)

1. One-to-Many (1:N)

Один-к-многим — одна запись в таблице A связана с несколькими записями в таблице B.

Пример: Один пользователь (User) имеет много заказов (Orders).

users (PK: id)
  |
  | 1
  |
  +----< orders (FK: user_id references users.id)
       N

Реализация:

CREATE TABLE users (
  id INT PRIMARY KEY
);

CREATE TABLE orders (
  id INT PRIMARY KEY,
  user_id INT,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

Характеристики:

• Самая частая связь
• Foreign Key находится в таблице "многих" (orders)

2. Many-to-Many (N:N)

Многие-к-многим — много записей в таблице A связаны с много записями в таблице B.

Пример: Студенты (Students) посещают много курсов (Courses), и каждый курс имеет много студентов.

students     courses
   |           |
   N           N
   |--------<->|
  enrollment  enrollment
     (junction table)

Реализация:

CREATE TABLE students (
  id INT PRIMARY KEY
);

CREATE TABLE courses (
  id INT PRIMARY KEY
);

CREATE TABLE enrollments (
  student_id INT,
  course_id INT,
  PRIMARY KEY (student_id, course_id),
  FOREIGN KEY (student_id) REFERENCES students(id),
  FOREIGN KEY (course_id) REFERENCES courses(id)
);

Характеристики:

• Требует junction table (или bridge table, join table)
• На junction table два Foreign Key
• Primary Key junction table часто составной (обе FK)

3. One-to-One (1:1)

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

Пример: Один пользователь (User) имеет один профиль (Profile).

users (PK: id)  <----1:1----> user_profiles (FK: user_id UNIQUE)

Реализация (вариант 1 — FK с UNIQUE):

CREATE TABLE users (
  id INT PRIMARY KEY
);

CREATE TABLE user_profiles (
  id INT PRIMARY KEY,
  user_id INT UNIQUE,  -- UNIQUE делает это 1:1
  bio TEXT,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

Реализация (вариант 2 — общий PK):

CREATE TABLE user_profiles (
  user_id INT PRIMARY KEY,  -- одновременно PK и FK
  bio TEXT,
  FOREIGN KEY (user_id) REFERENCES users(id)
);

Характеристики:

• Редко используется
• Обычно можно объединить в одну таблицу
• Применяется если разные части данных имеют разный lifecycle

Атрибуты связей (Cardinality & Optionality)

Cardinality (Мощность связи)

Cardinality — описывает, сколько записей может быть связано.

• 1:1 — One-to-One
• 1:N — One-to-Many
• N:N — Many-to-Many

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

Optionality — описывает, обязательна ли связь.

• Mandatory (обязательная) — запись ДОЛЖНА быть связана (FK NOT NULL)
• Optional (необязательная) — запись может быть не связана (FK NULL)

Нотация Chen (ER diagram):

User --1:N--> Order
(1)  (N)

(1) = каждый User имеет 1 или более Order
(N) = каждый Order имеет ровно 1 User

optionality:
User --(0,1):(1,N)-- Order
(0,1) = User может иметь 0 или 1 Orders (необязательно)
(1,N) = Order должен иметь 1 или N Users

Действия при изменении (Referential Integrity Actions)

ON DELETE:

• RESTRICT — запретить удаление, если есть ссылки
• CASCADE — удалить все связанные записи
• SET NULL — установить FK в NULL
• SET DEFAULT — установить FK в значение по умолчанию

ON UPDATE:

• RESTRICT — запретить изменение
• CASCADE — обновить все связанные записи
• SET NULL — установить в NULL
• SET DEFAULT — установить в значение по умолчанию

Пример:

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

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

Normal Forms связаны с правильностью устройства FK:

• 1NF (First Normal Form) — атомарные значения
• 2NF (Second Normal Form) — все атрибуты зависят от ВСЕГО PK
• 3NF (Third Normal Form) — нет транзитивных зависимостей
• BCNF (Boyce-Codd Normal Form) — строгая версия 3NF

Проблема без правильных FK (денормализация):

-- ПЛОХО: нарушает 1NF и 2NF
CREATE TABLE orders (
  id INT,
  user_name VARCHAR(100),  -- зависит от user, не от order
  user_email VARCHAR(100), -- зависит от user, не от order
  product_name VARCHAR(100) -- может быть нормализовано
);

-- ХОРОШО: нормализовано
CREATE TABLE orders (
  id INT PRIMARY KEY,
  user_id INT,
  product_id INT,
  FOREIGN KEY (user_id) REFERENCES users(id),
  FOREIGN KEY (product_id) REFERENCES products(id)
);

Диаграмма ER (Entity-Relationship)

Типичная диаграмма ER:

┌─────────────┐
│   Users     │
├─────────────┤
│ PK id       │────1:N──→ ┌────────────────┐
│ name        │           │   Orders       │
│ email       │           ├────────────────┤
└─────────────┘           │ PK id          │
                          │ FK user_id     │
                          │ amount         │────1:N──→ ┌──────────────────┐
                          └────────────────┘           │  OrderItems      │
                                                       ├──────────────────┤
                                                       │ PK (order_id,    │
                                                       │    product_id)   │
                                                       │ FK product_id    │
                                                       └──────────────────┘

Совет System Analyst

1. PK и FK — основа БД — правильно выбранные ключи = качественная архитектура
2. FOREIGN KEY constraints всегда включай — это гарантирует консистентность данных
3. Нормализуй до 3NF — избегай дублирования, упрощай обновления
4. Карточный формат N:N требует junction table — это стандарт
5. Продумай referential integrity actions — CASCADE не всегда безопасен
6. Рисуй ER диаграмму перед кодированием — понимание связей сразу выявит проблемы

Правильно спроектированные связи между таблицами — это 80% качественной БД.