Как описывал связь объектов?

Описание связей между объектами: методы и best practices

Введение

Описание связей между объектами (entities) — это ключевая часть требований в аналитической работе. За 10+ лет я использовал разные подходы и выработал систематический метод, который работает для всех types of relationships.

Основные типы связей и их обозначение

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

Определение: Один объект может связан с многими объектами другого типа.

Пример:

• Один компании имеет много сотрудников
• Один заказ содержит много позиций товаров
• Один клиент может иметь много транзакций

Как я это описываю в документации:

### Entity Relationship: Company → Employee

**Relationship Type:** One-to-Many
**Direction:** Company (parent) → Employee (child)
**Cardinality:** 1:N

**Business Logic:**
- A company must have at least 1 employee
- An employee belongs to exactly 1 company
- When company is deleted, what happens to employees? (CASCADE or RESTRICT)

**Attributes:**
- Company.id → Employee.company_id (foreign key)

**In SQL:**
CREATE TABLE company (
  id UUID PRIMARY KEY,
  name VARCHAR(255) NOT NULL
);

CREATE TABLE employee (
  id UUID PRIMARY KEY,
  name VARCHAR(255),
  company_id UUID NOT NULL,
  FOREIGN KEY (company_id) REFERENCES company(id) ON DELETE CASCADE
);

**In Data Model Diagram (Entity-Relationship):**
┌──────────────┐         ┌────────────────┐
│   Company    │─────1───N──→│   Employee   │
│              │    has       │              │
│ id (PK)      │              │ id (PK)      │
│ name         │              │ name         │
└──────────────┘              │ company_id   │
                              └────────────────┘

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

Определение: Многие объекты одного типа связаны со многими объектами другого типа.

Примеры:

• Студент может посещать много курсов, курс может посещать много студентов
• Товар может быть в много заказах, заказ может содержать много товаров
• User может иметь много roles, role может быть у много users

Как я это описываю:

### Entity Relationship: Student ↔ Course

**Relationship Type:** Many-to-Many
**Direction:** Bidirectional
**Cardinality:** N:M

**Business Logic:**
- A student can enroll in 0 or more courses
- A course can have 0 or more students
- When student is deleted, enrollments are deleted (but course remains)

**Implementation:**
Требуется junction table (таблица связи):

┌──────────────┐         ┌──────────────────┐         ┌────────────────┐
│   Student    │─────────│  Enrollment      │─────────│    Course      │
│              │ 1:N     │  (junction table)│ N:1     │                │
│ id (PK)      │         │                  │         │ id (PK)        │
│ name         │         │ student_id (FK)  │         │ name           │
│ email        │         │ course_id (FK)   │         │ credits        │
└──────────────┘         │ enrolled_date    │         └────────────────┘
                         │ grade            │
                         └──────────────────┘

**In SQL:**
CREATE TABLE enrollment (
  id UUID PRIMARY KEY,
  student_id UUID NOT NULL,
  course_id UUID NOT NULL,
  enrolled_date TIMESTAMP,
  grade VARCHAR(2),
  FOREIGN KEY (student_id) REFERENCES student(id) ON DELETE CASCADE,
  FOREIGN KEY (course_id) REFERENCES course(id),
  UNIQUE(student_id, course_id)
);

Почему junction table нужна:

• Без неё нельзя хранить дополнительные данные связи (grade, enrolled_date)
• Одна таблица не может хранить "many" значений в одной ячейке

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

Определение: Один объект связан ровно с одним объектом другого типа.

Примеры:

• Один passport имеет одного владельца
• Один user имеет один profile
• Один invoice имеет один payment

Как я это описываю:

### Entity Relationship: User ↔ UserProfile

**Relationship Type:** One-to-One
**Direction:** Unidirectional (User → UserProfile) или Bidirectional
**Cardinality:** 1:1

**Implementation (Option 1: Foreign Key in child table):**
┌──────────────┐         ┌──────────────────┐
│   User       │─────1───1──→│  UserProfile    │
│              │              │                │
│ id (PK)      │              │ id (PK)        │
│ email        │              │ user_id (FK)   │
│ password     │              │ bio            │
└──────────────┘              │ avatar         │
                              └──────────────────┘

**Implementation (Option 2: Shared Primary Key):**
Both tables share same id:

┌──────────────┐         ┌──────────────────┐
│   User       │         │  UserProfile     │
│              │ 1───1   │                  │
│ id (PK)      │────────→│ id (PK/FK)       │
│ email        │         │ bio              │
└──────────────┘         │ avatar           │
                         └──────────────────┘

**When to use:**
- Option 1: Если profile опциональный (user может не иметь profile)
- Option 2: Если profile обязательный (каждый user всегда имеет profile)

4. Self-Referential (Саморефернциальные)

Определение: Объект связан с объектом того же типа.

Примеры:

• Сотрудник имеет руководителя (который тоже сотрудник)
• Kategория может иметь parent категорию
• Комментарий может иметь parent комментарий (nested comments)

Как я это описываю:

### Entity Relationship: Employee (Self-Referential)

**Relationship Type:** Self-Referential (One-to-Many)
**Business Logic:**
- An employee can have 0 or 1 manager (who is also an employee)
- An employee can manage 0 or more employees

**Diagram:**
┌──────────────────────────┐
│   Employee               │
│                          │
│ id (PK)                  │
│ name                     │
│ manager_id (FK to id)    │
│ department               │
└──────────────────────────┘
        ↑                ↓
     manages        reports to

**In SQL:**
CREATE TABLE employee (
  id UUID PRIMARY KEY,
  name VARCHAR(255),
  manager_id UUID,
  FOREIGN KEY (manager_id) REFERENCES employee(id) ON DELETE SET NULL
);

**Example data:**
| id  | name  | manager_id |
|-----|-------|------------|
| E1  | John  | NULL       | (CEO, no manager)
| E2  | Alice | E1         | (John's direct report)
| E3  | Bob   | E1         | (John's direct report)
| E4  | Carol | E2         | (Alice's direct report)

**Business Implications:**
- Org chart structure defined
- Can query hierarchy: "Who reports to John?" or "Who is Carol's manager?"
- Circular references must be prevented (person can't be their own manager)

5. Polymorphic (Полиморфные)

Определение: One entity может быть связана с несколькими типами entities.

Примеры:

• Comment может быть на Post, Video, или Article
• Activity log может логировать действия на разных entity types
• Attachment может быть на Order, Invoice, или Shipment

Как я это описываю:

### Entity Relationship: Comment (Polymorphic)

**Challenge:** Comment может быть на разных типах контента (Post, Video, Article)

**Solution 1: Separate foreign keys (не рекомендую)**
┌──────────────┐
│   Comment    │
│              │
│ id (PK)      │
│ text         │
│ post_id (FK) │ ← Only if comment is on post
│ video_id(FK) │ ← Only if comment is on video
│ article_id(FK) │ ← Only if comment is on article
└──────────────┘

Problem: Много NULL values, hard to query

**Solution 2: Polymorphic (recommended)**
Use a type field + single foreign key:

┌──────────────────┐
│   Comment        │
│                  │
│ id (PK)          │
│ text             │
│ commentable_type │ ← "Post", "Video", "Article"
│ commentable_id   │ ← ID of the referenced object
│ created_at       │
└──────────────────┘

SELECT * FROM comment WHERE commentable_type = 'Post' AND commentable_id = 5;

**In ORM (e.g., Rails):**
class Comment < ApplicationRecord
  belongs_to :commentable, polymorphic: true
end

class Post < ApplicationRecord
  has_many :comments, as: :commentable
end

class Video < ApplicationRecord
  has_many :comments, as: :commentable
end

Как я описываю связи в требованиях

Я создаю документ "Entity Relationship Documentation" с четкой структурой:

## Entity Relationships

### 1. Company ← → Employee

**Type:** One-to-Many
**Direction:** Company (1) → Employee (N)

**Attributes:**
- Company.id → Employee.company_id (FK)

**Rules:**
- Employee must have a company_id (required)
- When company is deleted → employees are moved to archive or deleted (specify!)
- One employee reports to one company
- One company can have many employees

**Queries:** 
- "Get all employees of company X"
- "Get company of employee Y"

---

### 2. Student ↔ Course

**Type:** Many-to-Many
**Direction:** Bidirectional

**Attributes:**
- Enrollment.student_id (FK)
- Enrollment.course_id (FK)
- Enrollment.enrolled_date
- Enrollment.grade

**Rules:**
- A student can be enrolled in multiple courses
- A course can have multiple students
- Grade is nullable until course finishes
- Duplicate enrollments not allowed (UNIQUE constraint)

**Cascading:**
- Delete student → delete enrollments (but keep course)
- Delete course → delete enrollments (but keep student)
- Cannot delete company if has enrolled students

---

### 3. Order → OrderItem

**Type:** One-to-Many (Line Items)

**Attributes:**
- Order.id → OrderItem.order_id
- OrderItem.product_id
- OrderItem.quantity
- OrderItem.unit_price
- OrderItem.subtotal

**Rules:**
- Order must have at least 1 item (MIN cardinality = 1)
- Item must belong to exactly 1 order
- Items deleted when order cancelled
- Cannot add item after order status is 'completed'

**Derived Data:**
- Order.total_price = SUM(OrderItem.subtotal)

Как я это представляю визуально

Entity-Relationship Diagram (ERD):

┌─────────────────────────────────────────────────────────────┐
│                       E-COMMERCE SCHEMA                     │
├─────────────────────────────────────────────────────────────┤

      ┌──────────────┐
      │    User      │
      │              │
      │ id (PK)      │
      │ email        │
      │ created_at   │
      └──────────────┘
         ↑      ↓
      1:1    1:N
         ↑      ↓
      ┌──────────────────┐         ┌──────────────┐
      │  UserProfile     │         │    Order     │
      │                  │         │              │
      │ id (PK/FK)       │         │ id (PK)      │
      │ bio              │         │ user_id (FK) │
      │ avatar           │         │ created_at   │
      └──────────────────┘         └──────────────┘
                                        ↓ 1:N
                                   ┌─────────────────┐
                                   │  OrderItem      │
                                   │                 │
                                   │ id (PK)         │
                                   │ order_id (FK)   │
                                   │ product_id (FK) │
                                   │ quantity        │
                                   └─────────────────┘
                                        ↑ N:1
                                   ┌──────────────┐
                                   │   Product    │
                                   │              │
                                   │ id (PK)      │
                                   │ name         │
                                   │ price        │
                                   └──────────────┘

Легенда:

• ─1─ = One
• ─N─ = Many
• ─── = Optional (0 or more)
• ─|─ = Required (1 or more)

Как я документирую contraints

### Database Constraints & Rules

**Foreign Key Constraints:**
- order_id in OrderItem MUST exist in Order
  - ON DELETE CASCADE (delete items if order deleted)
  - ON UPDATE CASCADE (update items if order ID changes)

**Unique Constraints:**
- Email must be unique per user
- (student_id, course_id) must be unique in Enrollment

**Check Constraints:**
- Order.quantity > 0 (can't order 0 items)
- Order.created_at <= Order.shipped_at (can't ship before creating)

**NOT NULL Constraints:**
- Order.user_id NOT NULL (every order must have a user)
- Product.name NOT NULL (every product must have a name)

**Default Values:**
- Order.created_at = CURRENT_TIMESTAMP
- Order.status = 'pending'
- UserProfile.avatar = NULL (optional)

Как я это обсуждаю с разработчиками

На встречи я говорю:

"У нас есть User и Order. Как они связаны?

• One user может иметь many orders (1:N)
• Когда user удалится, что с его orders? (CASCADE? SOFT DELETE? Archive?)
• Может ли order существовать без user? (NO — always required)
• Какие данные нам нужны в связи? (just user_id or also created_date?)

Вот диаграмма как я это вижу. Согласны ли вы?"

Типичные ошибки, которых я избегаю

1. Неправильная cardinality

   • ❌ Thinking "One order has one item" (wrong if order can have multiple items)
   • ✅ Understanding "Order has many OrderItems"

2. Missing junction table

   • ❌ Many-to-many связь с foreign key в одной таблице (redundant data)
   • ✅ Junction table для N:M

3. Circular references не обработаны

   • ❌ Employee A reports to Employee B, who reports to A
   • ✅ Add business logic: "Employee cannot be their own manager"

4. Cascading not specified

   • ❌ "Order has items" but don't specify what happens when order is deleted
   • ✅ Document ON DELETE behavior explicitly

5. Missing constraints

   • ❌ Foreign key without NOT NULL (person can have NULL company)
   • ✅ Specify whether relationship is optional or required

Tools я использую для диаграмм

• Lucidchart / Draw.io — quick ERDs
• Miro — collaborative mapping
• DbDiagram.io — specialized for database schema
• PlantUML — text-based ERDs (version control friendly)

@startuml
entity User {
  id : uuid <<PK>>
  email : string <<unique>>
}

entity Order {
  id : uuid <<PK>>
  user_id : uuid <<FK>>
  created_at : timestamp
}

entity OrderItem {
  id : uuid <<PK>>
  order_id : uuid <<FK>>
  product_id : uuid <<FK>>
  quantity : int
}

entity Product {
  id : uuid <<PK>>
  name : string
  price : decimal
}

User ||--o{ Order
Order ||--|{ OrderItem
Product ||--o{ OrderItem
@enduml

Заключение

Описание связей между объектами — это:

• Четкость — все stakeholders понимают structure
• Правильность — нет redundancy, NULL issues
• Scalability — structure готов к расширению
• Compliance — constraints обеспечивают data integrity

Когда вы правильно описали связи, остальная разработка становится намного проще.