Руководство по синтаксису ERD Mermaid.js

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

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

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

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

Создание действительной, полностью рабочей схемы базы данных в Mermaid зависит от структурных блоков сущностей, сопоставлений типов данных, тегов индексов и операторов кардинальности.

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

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

erDiagram
    USERS {
        int id
        string email
        timestamp created_at
    }

2. Отметка первичных ключей, внешних ключей и комментариев

Двигатель ERD Mermaid позволяет назначать структурные теги индексации непосредственно после имени столбца и определения типа данных. Вы также можете добавить необязательный текстовый комментарий к столбцу, обернув его двойными кавычками:

• PK — явно помечает столбец как первичный ключ таблицы.
• FK — помечает столбец как внешний ключ, связанный с родительской таблицей.

erDiagram
    ORDERS {
        int id PK
        int user_id FK "Ссылается на USERS.id"
        string coupon_code
    }

3. Освоение модификаторов кардинальности клювовидной формы

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

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

erDiagram
    USERS ||--o{ ORDERS : "размещает" 

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

• Соблюдайте единообразный регистр имён таблиц: Держите имена сущностей предсказуемыми. Используйте строки в верхнем регистре (например, USER_ACCOUNTS) или строгий нижний регистр snake_case (например, user_accounts) чтобы соответствовать коду вашей реальной инфраструктуры SQL.
• Всегда включайте типы данных: Избегайте объявления необработанного текста столбцов без типов. Явно указывайте определения, такие как int, varchar, или boolean обеспечивает точное соответствие ваших диаграмм архитектуры технической справочной информации.
• Сохраняйте метки отношений в форме глаголов: При соединении элементов укажите краткую строку из строчных активных глаголов в определении отношения (например, ||--o{ : "содержит") для документирования отображения бизнес-логики.

Примеры ERD Mermaid.js из реального мира

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

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

erDiagram
    CUSTOMERS {
        int id PK
        string email
        string password_hash
    }

    ORDERS {
        int id PK
        int customer_id FK
        decimal total_amount
        string status
    }

    TRANSACTION_LEDGERS {
        int id PK
        int order_id FK
        string reference_token
        string gateway
    }

    CUSTOMERS ||--o{ ORDERS : "размещает"
    ORDERS ||--|| TRANSACTION_LEDGERS : "генерирует" 

Разбор синтаксиса: Эта схема четко отображает границы транзакций. Правила сопоставления определяют, что клиент может размещать ноль или несколько заказов с течением времени (||--o{), в то время как отдельная запись заказа должна генерировать ровно одну соответствующую запись в журнале транзакций (||--||).

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

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

erDiagram
    POSTS {
        int id PK
        string title
        string slug
        text body_content
    }

    CATEGORIES {
        int id PK
        string name
        string description
    }

    POST_CATEGORY_MAPPINGS {
        int post_id PK, FK
        int category_id PK, FK
        timestamp assigned_at
    }

    COMMENTS {
        int id PK
        int post_id FK
        string author_name
        text comment_body
    }

    POSTS ||--o{ POST_CATEGORY_MAPPINGS : "содержит"
    CATEGORIES ||--o{ POST_CATEGORY_MAPPINGS : "классифицирует"
    POSTS ||--o{ COMMENTS : "привязывает" 

Разбор синтаксиса: Для обработки отношения «многие-ко-многим» между `POSTS` и `CATEGORIES` скрипт вводит таблицу пересечения (`POST_CATEGORY_MAPPINGS`). Эта сущность использует составные ключи, одновременно выступающие в роли первичных и внешних ключей (PK FK), соединяя внешние узлы с помощью стандартных связей «один ко многим» в виде клювов ворона.