Przewodnik po składni ERD w Mermaid.js

Czym jest diagram relacji encji (ERD)?

Diagram relacji encji (ERD) to strukturalny szkic używany do projektowania, dokumentowania i analizy schematów baz danych relacyjnych. Wskazuje konkretne tabele danych (encje) w aplikacji, kolumny (atrybuty) zagnieżdżone w tych tabelach oraz zasady integralności referencyjnej łączące je ze sobą. Napisany przy użyciu standardowej notacji notacji Inżynierii Informacji (IE), która implementuje jasne notację kłykci kruka głowy, aby pokazywać ograniczenia danych i zależności między wieloma tabelami.

Za pomocą Mermaid.js, możesz zdefiniować indeksy tabel produkcyjnych, typy danych oraz połączenia kluczy obcych przy użyciu czystego, deklaratywnego bloku tekstu. Silnik automatycznie obsługuje rozmiary kontenerów układu wielokolumnowego i kieruje linie połączeń bez przesłaniania etykiet tekstowych.

Podstawowy przewodnik składniowy: elementy i konstrukcje

Tworzenie poprawnego, pełni działającego schematu bazy danych w Mermaid opiera się na blokach encji strukturalnych, mapowaniach typów danych, znacznikach indeksów oraz operatorach liczności.

1. Deklarowanie encji i kolumn tabel

Zainicjuj płótno ERD w pierwszym wierszu za pomocą słowa kluczowego erDiagram . Aby zdefiniować tabelę, napisz nazwę encji, a następnie otwarty klamrą, wypisując konfiguracje kolumn kolejno w osobnych wierszach:

erDiagram
    USERS {
        int id
        string email
        timestamp created_at
    }

2. Oznaczanie kluczy głównych, kluczy obcych i komentarzy

Silnik ERD w Mermaid pozwala przypisać znaczniki indeksowania strukturalnego bezpośrednio po nazwie kolumny i definicji typu danych. Możesz również dodać opcjonalny komentarz do kolumny, otaczając go podwójnymi cudzysłowami:

• PK — Jawnie oznacza kolumnę jako klucz główny tabeli.
• FK — Oznacza kolumnę jako klucz obcy powiązany z tabelą nadrzędna.

erDiagram
    ORDERS {
        int id PK
        int user_id FK "Łączy się z USERS.id"
        string coupon_code
    }

3. Opanowanie modyfikatorów liczności Crow’s Foot

Aby połączyć tabele i zapewnić zasady integralności referencyjnej, zmapuj ich relacje przy użyciu specjalistycznych operatorów linii. Główki znaków tworzą wizualne kształty podobne do łap kruka, które określają ograniczenia wielokrotności danych:

• ||--|| **Dokładnie jeden do dokładnie jednego:** Ścisłe, wymagane odwzorowanie 1:1.
• ||--o| **Dokładnie jeden do zera lub jednego:** Opcjonalna zależność 1:1.
• ||--|{ **Dokładnie jeden do jednego lub wielu:** Wymagane połączenie rodzicielskie 1:N.
• ||--o{ **Dokładnie jeden do zera, jednego lub wielu:** Standardowa, opcjonalna relacja 1:N.

erDiagram
    USERS ||--o{ ORDERS : "umieszcza" 

Najlepsze praktyki dla schematów danych relacyjnych

• Utrzymuj spójny styl nazywania tabel: Zachowaj przewidywalne nazwy encji. Używaj dużych liter (np. USER_ACCOUNTS) lub ściśle małą literę w formacie snake_case (np. user_accounts) aby dopasować do kodu infrastruktury SQL w rzeczywistym świecie.
• Zawsze uwzględniaj typy danych: Unikaj deklarowania surowego tekstu kolumn bez typów. Jawne wypisanie definicji takich jak int, varchar, lub boolean zapewnia, że wykresy architektury stanowią dokładną odniesienie techniczne.
• Utrzymuj etykiety relacji jako czasowniki: Podczas łączenia elementów podaj krótki, małymi literami ciąg czasownika aktywnego w przypisaniu relacji (np. ||--o{ : "zawiera") w celu zapisania mapowania logiki biznesowej.

Przykłady ERD Mermaid.js z rzeczywistego świata

Przykład 1: Podstawowy model transakcyjny e-commerce (klucze i mapowania)

Ten funkcjonalny szablon modeluje podstawowy cykl transakcji bazy danych e-commerce, pokazując, jak użytkownicy, zamówienia i systemy śledzenia płatności są ze sobą powiązane przy użyciu ściśle określonych ograniczeń typu „kłoda kruka”.

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 : "umieszcza"
    ORDERS ||--|| TRANSACTION_LEDGERS : "generuje" 

Analiza składni: Ten schemat wyczyścić mapuje granice transakcji. Zasady mapowania określają, że klient może umieszczać zero lub wiele zamówień w czasie (||--o{), podczas gdy pojedynczy rekord zamówienia musi wygenerować dokładnie jedną pasującą pozycję w dzienniku transakcji (||--||).

Przykład 2: Schemat systemu zarządzania treścią w przedsiębiorstwie (przecięcie wiele do wielu)

Ten zaawansowany szablon bazy danych opisuje architekturę platformy zarządzania treścią. Szczegółowo wyjaśnia, jak rozwiązać skomplikowane konfiguracje wiele do wielu, wprowadzając jawny element mapowania mostu.

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 : "zawiera"
    CATEGORIES ||--o{ POST_CATEGORY_MAPPINGS : "klasyfikuje"
    POSTS ||--o{ COMMENTS : "przypisuje" 

Analiza składni: Aby obsłużyć relację wiele do wielu między `POSTS` i `CATEGORIES`, skrypt wprowadza tabelę przecięcia (`POST_CATEGORY_MAPPINGS`). Ten blok mapowania używa kluczy złożonych działających jednocześnie jako klucze główne i obce (PK FK), łącząc węzły zewnętrzne za pomocą standardowych połączeń typu jeden do wielu w stylu „kłoda kruka”.