ERD

Введение: Рисуем картину данных

Представьте, что вам нужно объяснить кому-то, как устроена база данных вашего проекта. Можно перечислить таблицы: “Клиенты”, “Заказы”, “Товары”. Можно описать связи: “Один клиент может сделать много заказов”. Но текстом это получается длинно и запутанно.

А можно нарисовать схему. Прямоугольники – это таблицы. Линии между ними – это связи. Стрелочки показывают, кто с кем и как связан. Такую схему поймет и заказчик, и разработчик, и новый сотрудник, который только зашел в проект.

ERD (Entity-Relationship Diagram) – это диаграмма сущностей и связей. Она показывает, какие сущности есть в системе, какие у них атрибуты и как они связаны между собой.

ERD – это язык, на котором аналитик разговаривает с заказчиком о данных. Это мост между бизнес-пониманием “у нас есть клиенты и заказы” и технической реализацией “таблица Clients с полем id”.

Что такое ERD простыми словами

ERD расшифровывается как Entity-Relationship Diagram – диаграмма “сущность-связь”. Это визуальный способ описать структуру данных.

Три главных строительных блока ERD:

ERD бывает на разных уровнях детализации. На высоком уровне (концептуальном) вы показываете только сущности и связи. На низком (физическом) – добавляете поля, типы данных, первичные и внешние ключи.

Нотации ERD: Как договориться о языке

Проблема ERD в том, что нет одного единственного стандарта. Есть разные нотации – разные способы рисовать одни и те же вещи. Самые популярные – это нотация Чена (Chen) и нотация “воронья лапа” (Crow’s Foot).

Нотация Чена (Chen Notation)

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

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

Нотация “воронья лапа” (Crow’s Foot)

Самая популярная в практическом моделировании. Сущности – прямоугольники. Связи – линии. Тип связи показывается “лапками” на концах линий.

Плюсы: Компактно, понятно, не требует лишних фигур. Минусы: Нужно привыкнуть к символам.

Она де-факто стандарт в индустрии, и большинство инструментов (Draw.io, Lucidchart) используют именно ее.

Пример ERD

Вот как выглядит описание этого примера в сервисе dbdiagram.io:

Table follows {
  following_user_id integer
  followed_user_id integer
  created_at timestamp
}

Table users {
  id integer [primary key]
  username varchar
  role varchar
  created_at timestamp
}

Table posts {
  id integer [primary key]
  title varchar
  body text [note: 'Content of the post']
  user_id integer [not null]
  status varchar
  created_at timestamp
}

Ref user_posts: posts.user_id > users.id // many-to-one
Ref: users.id < follows.following_user_id
Ref: users.id < follows.followed_user_id

Уровни ERD: Концептуальная, логическая, физическая

ERD может быть нарисована с разной степенью детализации.

Концептуальная ERD (Conceptual)

Что показывает: Только сущности и связи. Никаких атрибутов, никаких ключей.

Для кого: Для заказчика, менеджмента, бизнес-пользователей.

Логическая ERD (Logical)

Что показывает: Сущности, атрибуты, первичные ключи, связи. Но без привязки к конкретной СУБД (без типов данных).

Для кого: Для аналитиков, архитекторов, разработчиков.

Описание в dbdiagram.io:

Table User {
  id PK
  username VARCHAR(50)
  email VARCHAR(100)
  role VARCHAR(20)
  created_at DATETIME
}

Table Post {
  id PK
  title VARCHAR(200)
  body TEXT
  user_id FK
  status VARCHAR(20)
  created_at DATETIME
} 

Table Comment {
  id PK
  content TEXT
  user_id FK
  post_id FK
  created_at DATETIME
} 

Table Like {
  id PK
  user_id FK
  target_type VARCHAR(20)
  target_id INTEGER
  created_at DATETIME
}

Table Follow {
  id PK
  following_user_id FK
  followed_user_id FK      
  created_at DATETIME
}

Ref: Post.user_id > User.id
Ref: Comment.user_id > User.id
Ref: Comment.post_id > Post.id
Ref: Like.user_id > User.id
Ref: Follow.following_user_id > User.id
Ref: Follow.followed_user_id > User.id

Физическая ERD (Physical)

Что показывает: Все, что в логической, плюс типы данных, индексы, конкретные имена таблиц и полей в базе данных.

Для кого: Для разработчиков, администраторов баз данных.

Описание в dbdiagram.io:

Table users {
  id integer [pk, increment]
  username varchar(50) [unique, not null]
  email varchar(100) [unique, not null]
  role varchar(20) [default: 'user', note: 'user|admin|moderator']
  created_at timestamp [default: `now()`]
  
  indexes {
    (email)
    (username)
  }
}
  
Table posts {
  id integer [pk, increment]
  title varchar(200) [not null]
  body text [not null]
  user_id integer [not null, ref: > users.id]
  status varchar(20) [default: 'draft', note: 'draft|published|archived']
  created_at timestamp [default: `now()`]
  
  indexes {
    (user_id)
    (status, created_at)
  }
}

Table comments {
  id integer [pk, increment]
  content text [not null]
  user_id integer [not null, ref: > users.id]
  post_id integer [not null, ref: > posts.id]
  created_at timestamp [default: `now()`]

  indexes {
    (post_id, created_at)
    (user_id)
  }
}

  

Table likes {
  id integer [pk, increment]
  user_id integer [not null, ref: > users.id]
  target_type varchar(20) [not null, note: 'post|comment']
  target_id integer [not null]
  created_at timestamp [default: `now()`]
  
  indexes {
    (user_id, target_type, target_id) [unique, name: 'unique_like']
    (target_type, target_id)
  }
}

Table follows {
  id integer [pk, increment]
  following_user_id integer [not null, ref: > users.id]
  followed_user_id integer [not null, ref: > users.id]
  created_at timestamp [default: `now()`]

  indexes {
    (following_user_id, followed_user_id) [unique, name: 'unique_follow']
    (followed_user_id)
  }
}

Зачем ERD системному аналитику

Для общения с заказчиком

ERD – это язык, который понимает бизнес. Вы показываете заказчику схему и спрашиваете: “У одного клиента может быть много заказов?” Заказчик кивает или поправляет. Это намного быстрее, чем текстовые описания.

Для выявления требований к данным

Рисуя ERD, вы начинаете задавать правильные вопросы:

• “Какие атрибуты есть у клиента?”
• “Может ли заказ существовать без клиента?”
• “Сколько товаров может быть в одном заказе?”

Для передачи разработчикам

Разработчикам не нужно читать 10 страниц текста о том, как связаны таблицы. Им достаточно посмотреть на ERD.

Для документации

ERD – это живая документация. Когда новый человек приходит в проект, он смотрит на ERD и за 5 минут понимает, как устроены данные.

Для поиска ошибок в логике

Нарисовав ERD, вы можете увидеть противоречия. Например, если у вас связь многие-ко-многим без промежуточной таблицы – это ошибка.

Инструменты для рисования ERD

Типичные ошибки в ERD

Ошибка 1: Путать типы связей

Рисовать связь один-ко-многим, когда на самом деле многие-ко-многим. Проверяйте: “Может ли один товар быть в нескольких заказах?” Если да – это многие-ко-многим.

Ошибка 2: Забывать про атрибуты

Рисуют только сущности и связи, но не показывают, какие поля у этих сущностей. Для логической ERD атрибуты обязательны.

Ошибка 3: Не указывать первичные ключи

Каждая сущность должна иметь первичный ключ. Иначе как вы будете идентифицировать записи?

Ошибка 4: Смешивать уровни детализации

На одной диаграмме показывать и концептуальный уровень (только сущности), и физический (типы данных). Получается каша.

Ошибка 5: Рисовать слишком много на одной схеме

Пытаться вместить все 50 таблиц проекта на одну диаграмму. Получается “спагетти”, которое никто не может прочитать. Делите на логические группы.

Ошибка 6: Игнорировать нотацию

Рисовать связи просто линиями без символов. Непонятно, это один-ко-многим или многие-ко-многим.