🗄️ Mermaid

Diagram związków encji

Projektuj schematy baz danych, które mają sens

Czym jest Diagram związków encji?

Diagram ER pokazuje encje bazy danych, ich atrybuty oraz liczność relacji między nimi (jeden-do-wielu, wiele-do-wielu). To plan każdej relacyjnej bazy danych.

Diagram związków encji należy do pull requesta dodającego migrację oraz do pierwszej godziny onboardingu, bo najszybszym sposobem wyjaśnienia produktu bywa jego model danych. Uwidacznia liczność: jeden adres na klienta czy kilka to reguła biznesowa, a nie szczegół. Nie niesie natomiast projektu fizycznego — żadnych indeksów, partycjonowania ani wzorców zapytań. Źródłem prawdy pozostaje plik migracji.

Żywy przykład

Kod Mermaid
erDiagram
    CUSTOMER ||--o{ ORDER : places
    ORDER ||--|{ ORDER_LINE : contains
    PRODUCT ||--o{ ORDER_LINE : "ordered in"
    CUSTOMER {
      string id PK
      string email UK
    }
    ORDER {
      string id PK
      date created_at
    }
Żywy przykład

places

contains

ordered in

CUSTOMER

string

id

PK

string

email

UK

ORDER

string

id

PK

date

created_at

ORDER_LINE

PRODUCT

Kiedy go używać

Projektowanie nowego schematu bazy danych przed pierwszą migracją
Dokumentowanie istniejącego schematu dla nowych członków zespołu
Omawianie modeli danych z osobami nietechnicznymi

Częste błędy

Liczność czytana od złej strony

W CUSTOMER ||--o{ ORDER : places znak || przy CUSTOMER oznacza jednego klienta na zamówienie, a o{ przy ORDER — zero lub więcej zamówień na klienta. Każdy znacznik liczy własną encję, widzianą z drugiego końca.

Relacja bez etykiety

Sam zapis CUSTOMER ||--o{ ORDER to błąd parsowania: Mermaid oczekuje dwukropka. Napisz : places albo : "", gdy relacja jest oczywista. To zdecydowanie najczęstsza przyczyna niepowodzenia w erDiagram.

Nazwy encji ze spacjami

ORDER LINE ||--o{ PRODUCT nie tworzy encji o nazwie ORDER LINE — nazwa zostaje rozcięta na spacji. Ujmij ją w cudzysłów jako "ORDER LINE" albo użyj podkreślenia, zgodnie z konwencją reszty schematu.

Podstawowa składnia

.mmd
erDiagram
    USER ||--o{ POST : writes
    USER {
      string id PK
      string email
    }
  • CUSTOMER ||--o{ ORDER : places

    Każda relacja potrzebuje etykiety po dwukropku; gdy nie ma nic sensownego do dopisania, napisz : "". Etykiety ze spacjami ujmij w cudzysłów, jak w : "ordered in".

  • ORDER { string id PK decimal total "in cents" }

    Atrybut to typ, potem nazwa, następnie opcjonalne znaczniki kluczy (PK, FK, UK, po przecinku) i komentarz w cudzysłowie. Typy są dowolnym tekstem i nic nie jest walidowane.

  • ORDER ||--|{ LINE : contains CUSTOMER }o..o{ PROMO : uses

    Linia ciągła to relacja identyfikująca — dziecko nie istnieje samodzielnie. Kropki oznaczają relację nieidentyfikującą, w której klucz obcy jest opcjonalny.

  • erDiagram direction LR

    Domyślny kierunek biegnie z góry na dół. Zapis direction LR rozkłada szeroki schemat na boki, co zwykle pasuje do strony dokumentacji lepiej niż wysoka kolumna encji.

Pytania o ten diagram

Jak czytać symbole liczności, takie jak ||--o{ ?

|| oznacza dokładnie jeden, o| zero lub jeden, }| jeden lub więcej, }o zero lub więcej. Zatem CUSTOMER ||--o{ ORDER czyta się „jeden klient składa zero lub więcej zamówień”.

Czy mogę wygenerować diagram ER z SQL?

Tak — wklej swoje instrukcje CREATE TABLE lub opisz dane, a AI wygeneruje odpowiadający im diagram ER z kluczami i relacjami.

Czy mogę trzymać diagram ER w repozytorium razem z migracjami?

Tak i to główny powód, by pisać go tekstem. Diagram leży obok migracji, w przeglądzie różni się linia po linii, a zmiana schematu, której nikt w nim nie odzwierciedlił, ujawnia się jako brakująca edycja.

Czy diagram ER w Mermaid pokazuje indeksy i ograniczenia?

Nie. Pokazuje encje, typy atrybutów oraz znaczniki PK, FK i UK — i nic poza tym: żadnych indeksów, wartości domyślnych, ograniczeń check ani wyzwalaczy. Traktuj go jak mapę schematu, nie jak specyfikację, z której da się wygenerować bazę.

Jak zamodelować relację wiele-do-wielu?

Albo narysuj ją wprost przez }o--o{, albo wprowadź encję łączącą: STUDENT ||--o{ ENROLMENT i COURSE ||--o{ ENROLMENT. Drugiej formy użyj wtedy, gdy złączenie niesie własne kolumny, na przykład datę zapisu.

Czym różnią się PK, FK i UK?

PK oznacza klucz główny, FK klucz obcy wskazujący inną encję, a UK ograniczenie unikalności. Mermaid renderuje je wyłącznie jako etykiety — nigdy nie sprawdza, czy FK odpowiada kluczowi głównemu gdzieś indziej na diagramie.

Diagram związków encji czy inny typ diagramu?

Diagram związków encji czy diagram klas?

Wybieraj według tego, co czytelnik zaraz zrobi. Jeśli pisze SQL albo migrację, daj mu encje, klucze i liczności. Jeśli pisze kod aplikacji, bliższy temu, co faktycznie wystuka, będzie diagram klas z metodami i dziedziczeniem.

Diagram związków encji czy schemat blokowy?

Diagram związków encji odpowiada na pytanie „co jest przechowywane i jak się ze sobą wiąże”; schemat blokowy — „co się dzieje i w jakiej kolejności”. Prostokąty będące rzeczownikami z atrybutami należą do pierwszego, prostokąty będące czasownikami — do drugiego.

Stwórz swój Diagram związków encji już teraz

Opisz go naturalnym językiem — AI napisze kod Mermaid za Ciebie.

Otwórz Mermaid Studio