Руководство по синтаксису ERD PlantUML

Что такое диаграмма сущность-связь (ERD)?

ЭтоДиаграмма сущность-связь (ERD) — это структурный чертеж, используемый для проектирования, документирования и анализа реляционных баз данных. Он визуализирует таблицы (сущности) в системе, конкретные столбцы (атрибуты), которые они содержат, и как эти таблицы связаны между собой. В PlantUML ERD создаются с использованиемнотации инженерии информации (IE), которая реализует стандартныенотации клювов птиц для представления реляционных ограничений.

Независимо от того, проектируете ли вы хранилище данных микросервиса, оптимизируете пути SQL-соединения или разрабатываете архитектуру корпоративной хранилища данных, текстовая UML-диаграмма ERD гарантирует, что ваши схемы баз данных будут полностью понятны. С помощьюVPasCode, вы можете определять свои таблицы баз данных, ключи индексов и логические связи с помощью чистого, декларативного синтаксиса. Двигатель автоматически управляет размерами блоков таблиц и маршрутизирует строки соединителей внешних ключей без наложения линий компоновки.

Руководство по основному синтаксису: элементы и конструкции

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

1. Объявление сущностей (таблиц баз данных)

Вы объявляете таблицу базы данных с помощью ключевого словаentityключевое слово, за которым следует имя таблицы и набор фигурных скобок. Внутри скобок перечисляются столбцы таблицы. Чтобы сделать схему чистой и читаемой, используйте горизонтальный разделитель (--), чтобы отделить первичные/внешние ключи от обычных атрибутов данных:

entity "users" as users_table {
    id : INT [PK]
    --
    email : VARCHAR(255)
    created_at : TIMESTAMP
}

2. Обозначение первичных и внешних ключей

Хотя текстовые обозначения, такие как [PK] или [FK], хорошо работают, движок IE PlantUML также поддерживает визуальные значки ключей. Помещение звездочки (*), перед атрибутом, обозначает его как **обязательный (не может быть пустым)** столбец, в то время как чистая текстовая строка или тег добавляет явный контекст индексирования:

сущность "orders" {
    * id : INT <<PK>>
    --
    * user_id : INT <<FK>>
    discount_code : VARCHAR(50)
}

3. Сопоставление кардинальности и отношений в виде клюва вороны

Для соединения таблиц и обеспечения ограничений целостности ссылок используйте комбинацию тире, квадратных скобок и символов вертикальной черты. В нотации IE эти символы образуют отдельные **головы вороны**, которые представляют отношения в базе данных:

  • ||--|| **Точно один к точно одному:** строгое, обязательное однозначное отображение.
  • ||--o| **Точно один к нулю или одному:** необязательное однозначное отображение.
  • ||--|{ **Точно один к одному или многим:** обязательная зависимость один ко многим.
  • ||--o{ **Точно один к нулю, одному или многим:** стандартное необязательное отношение один ко многим.

Лучшие практики для чистых схем баз данных

  • Соблюдайте правила написания регистра: Делайте объявления сущностей предсказуемыми. Используйте строчные символы в формате snake_case (например, order_items) для реальных таблиц, сопоставленных с SQL, или используйте заглавные символы в формате CamelCase для концептуальных моделей домена.
  • Всегда документируйте внешние ключи: При связывании двух таблиц всегда указывайте столбец внешнего ключа внутри блока дочерней таблицы. Это обеспечивает четкую контекстную информацию для инженерных команд во время миграций данных.
  • Управляйте расстоянием между головами вороны: Сложные схемы баз данных с десятками таблиц быстро становятся переполненными. Если линии отношений начинают пересекаться неестественно, замените двойные тире-соединители (--) на три или четыре тире (---) чтобы раздвинуть таблицы и дать движку компоновки больше места для организации сетки.

Примеры ERD PlantUML в реальных условиях

Пример 1: Основная модель реляционной базы данных электронной коммерции (ключи и сопоставления)

Этот функциональный чертеж моделирует основной цикл транзакций базы данных электронной коммерции, показывая, как пользователи, заказы и журналы платежей связаны друг с другом с использованием строгих отношений типа «клюв ворона».

@startuml
' Заморозить отображение блоков сущностей в острых современных квадратах
hide circle
skinparam LINETYPE ortho

entity "пользователи" as user {
    * id : INT <<PK>>
    --
    * email : VARCHAR(100)
    * хэш_пароля : VARCHAR(255)
    телефон : VARCHAR(20)
}

entity "заказы" as order {
    * id : INT <<PK>>
    --
    * id_пользователя : INT <<FK>>
    * общая_сумма : DECIMAL(10,2)
    статус : VARCHAR(50)
}

entity "журналы_платежей" as ledger {
    * id : INT <<PK>>
    --
    * id_заказа : INT <<FK>>
    * ссылка_на_транзакцию : VARCHAR(100)
    шлюз : VARCHAR(50)
}

' Определить связи реляционной схемы
user ||--o{ order : "размещает"
order ||--|| ledger : "генерирует"
@enduml

Разбор синтаксиса: Директива hide circle отключает стандартные круглые маркеры классов UML, в то время как skinparam LINETYPE ortho заставляет линии отношений принимать чистые прямые углы 90 градусов. Схема ясно показывает, что пользователь может разместить ноль или несколько заказов (||--o{), в то время как заказ должен иметь ровно одну связанную запись журнала платежей (||--||).

Пример 2: Схема расширенной системы управления контентом (пересечение многие-ко-многим)

Этот продвинутый корпоративный чертеж отображает полную топологию системы управления контентом (CMS). Он демонстрирует, как чисто обрабатывать архитектуры «многие-ко-многим», используя промежуточную таблицу сопоставления.

@startuml
hide circle
skinparam LINETYPE ortho

entity "посты" as post {
    * id : INT <<PK>>
    --
    * id_автора : INT <<FK>>
    * заголовок : VARCHAR(255)
    slug : VARCHAR(255)
    текст : TEXT
}

entity "категории" as category {
    * id : INT <<PK>>
    --
    * название : VARCHAR(100)
    описание : VARCHAR(255)
}

entity "сопоставления_постов_и_категорий" as mapping {
    * id_поста : INT <<PK>><<FK>>
    * id_категории : INT <<PK>><<FK>>
    --
    назначено_в : TIMESTAMP
}

entity "комментарии" as comment {
    * id : INT <<PK>>
    --
    * id_поста : INT <<FK>>
    имя_автора : VARCHAR(100)
    * содержание : TEXT
}

' Структуры связей
post ||--o{ mapping : "содержит"
category ||--o{ mapping : "категоризирует"
post ||--o{ comment : "привязывает"
@enduml

Разбор синтаксиса: Этот шаблон моделирует классическое отношение «многие-ко-многим» между постами и категориями. Вместо прямого соединения они используют промежуточную таблицу (post_category_mappings), где оба столбца выступают в качестве составного первичного ключа. Индикаторы типа «клюв ворона» явно отображают каскадные связи на уровень комментариев.

Прокрутить вверх