Czym jest diagram relacji encji (ERD)?
Diagram relacji encji (ERD) to strukturalny szkic używany do projektowania, dokumentowania i analizy baz danych relacyjnych. Wizualizuje tabele (encje) w systemie, konkretne kolumny (atrybuty), które zawierają, oraz sposób, w jaki te tabele są ze sobą powiązane. W PlantUML diagramy ERD tworzy się przy użyciu notacji Inżynierii Informacji (IE), która implementuje standardowe notację kłykci kruka w celu przedstawienia ograniczeń relacyjnych.
Niezależnie od tego, czy projektujesz magazyn danych mikroserwisu, optymalizujesz ścieżki połączeń SQL, czy mapujesz architekturę magazynu danych na skalę całej organizacji, diagram ERD oparty na tekście zapewnia, że schematy baz danych są idealnie czytelne. Dzięki VPasCode, możesz definiować tabele bazy danych, klucze indeksów i relacje logiczne przy użyciu czystego, deklaratywnego składnia. Silnik automatycznie obsługuje dopasowanie rozmiarów pól tabel i kieruje ciągi połączeń kluczy obcych bez nakładania się linii układu.
Podstawowy przewodnik składniowy: elementy i konstrukcje
Tworzenie solidnego diagramu ERD w stylu IE w PlantUML opiera się na zorganizowanych blokach encji, jasnych oznaczeniach kluczy oraz modyfikatorach liczności kłykci kruka.
1. Deklarowanie encji (tabel bazy danych)
Deklarujesz tabelę bazy danych przy użyciu słowa kluczowego entitya następnie nazwę tabeli i zestaw klamr. Wewnątrz klamr wymieniasz kolumny tabeli. Aby schemat był czysty i czytelny, użyj poziomej linii separatora (--) w celu oddzielenia kluczy głównych/obcych od standardowych atrybutów danych:
entity "users" as users_table {
id : INT [PK]
--
email : VARCHAR(255)
created_at : TIMESTAMP
}
2. Oznaczanie kluczy głównych i obcych
Choć wskaźniki tekstowe takie jak `[PK]` lub `[FK]` działają dobrze, silnik IE w PlantUML obsługuje również wizualne ikony kluczy. Umieszczając gwiazdkę (*) przed atrybutem oznacza go jako kolumnę **obowiązkową (nie może być pusta)**, podczas gdy czysty ciąg tekstowy lub znacznik dodaje jawne konteksty indeksowania:
encja "orders" {
* id : INT <<PK>>
--
* user_id : INT <<FK>>
kod_zniżkowy : VARCHAR(50)
}
3. Mapowanie kardynalności i relacji w stylu Crow’s Foot
Aby połączyć tabele i zapewnić ograniczenia integralności referencyjnej, użyj kombinacji myślników, nawiasów i znaków pionowej kreski. W notacji IE te symbole tworzą wyraźne **głowy koguta** reprezentujące relacje w bazie danych:
||--||**Dokładnie jeden do dokładnie jednego:** ściśle określone, wymagane odwzorowanie jeden do jednego.||--o|**Dokładnie jeden do zera lub jednego:** opcjonalne odwzorowanie jeden do jednego.||--|{**Dokładnie jeden do jednego lub wielu:** wymagana zależność jeden do wielu.||--o{**Dokładnie jeden do zera, jednego lub wielu:** standardowa, opcjonalna relacja jeden do wielu.
Najlepsze praktyki dla czystych schematów baz danych
- Utrzymuj zasady nazywania: Zachowaj przewidywalność deklaracji encji. Używaj małych liter w formacie snake_case (np.
order_items) dla rzeczywistych tabel zmapowanych na SQL, lub używaj wielkich liter w formacie CamelCase dla modeli koncepcyjnych domeny. - Zawsze dokumentuj klucze obce: Gdy łączy się dwie tabele, zawsze określ kolumnę klucza obcego w bloku tabeli potomnej. Dzięki temu zespoły inżynieryjne mają jasne konteksty odniesienia podczas migracji danych.
- Kontroluj odstępy w stylu Crow’s Foot: Złożone schematy baz danych z dziesiątkami tabel mogą szybko stać się zatłoczone. Jeśli linie relacji zaczynają się nieprzyjemnie przecinać, zastąp dwukrotnie myślniki (
--) trzema lub czterema myślnikami (---) aby oddzielić tabele i dać silnikowi układania więcej miejsca do organizacji siatki.
Przykłady ERD PlantUML z rzeczywistych zastosowań
Przykład 1: Podstawowy model relacyjny e-commerce (klucze i mapowania)
Ten szablon funkcjonalny modeluje podstawowy cykl transakcji bazy danych e-commerce, pokazując, jak użytkownicy, zamówienia i księgi płatności są ze sobą powiązane za pomocą ściśle określonych relacji typu „kłoda kruka”.
@startuml
' Zablokuj renderowanie pól encji w postaci ostrej nowoczesnej kwadratowej formy
ukryj okrąg
skinparam LINETYPE ortho
entity "użytkownicy" as user {
* id : INT <<PK>>
--
* email : VARCHAR(100)
* hasz_hasła : VARCHAR(255)
telefon : VARCHAR(20)
}
entity "zamówienia" as order {
* id : INT <<PK>>
--
* id_użytkownika : INT <<FK>>
* całkowita_kwota : DECIMAL(10,2)
status : VARCHAR(50)
}
entity "księgi_płatności" as ledger {
* id : INT <<PK>>
--
* id_zamówienia : INT <<FK>>
* referencja_transakcji : VARCHAR(100)
brama : VARCHAR(50)
}
' Zdefiniuj powiązania schematu relacyjnego
user ||--o{ order : "umieszcza"
order ||--|| ledger : "generuje"
@enduml
Analiza składni: Dyrektywa ukryj okrąg wyłącza domyślne okręgi tokenów klasy UML, podczas gdy skinparam LINETYPE ortho wymusza ścieżki relacji na czyste kąty proste 90 stopni. Schemat jasno pokazuje, że użytkownik może umieścić zero lub wiele zamówień (||--o{), podczas gdy zamówienie musi mieć dokładnie jedną powiązaną rekord księgi płatności (||--||).
Przykład 2: Zaawansowany schemat systemu zarządzania treścią (przecięcie wiele do wielu)
Ten zaawansowany szablon przedsiębiorstwa modeluje kompletną topologię systemu zarządzania treścią (CMS). Pokazuje, jak sprawnie obsługiwać architektury wiele do wielu, wykorzystując tabelę pośrednią do mapowania.
@startuml
ukryj okrąg
skinparam LINETYPE ortho
entity "posty" as post {
* id : INT <<PK>>
--
* id_autora : INT <<FK>>
* tytuł : VARCHAR(255)
slug : VARCHAR(255)
treść : TEXT
}
entity "kategorie" as category {
* id : INT <<PK>>
--
* nazwa : VARCHAR(100)
opis : VARCHAR(255)
}
entity "mapowania_postów_i_kategorii" as mapping {
* id_posta : INT <<PK>><<FK>>
* id_kategorii : INT <<PK>><<FK>>
--
przypisano_w : TIMESTAMP
}
entity "komentarze" as comment {
* id : INT <<PK>>
--
* id_posta : INT <<FK>>
nazwa_autora : VARCHAR(100)
* treść : TEXT
}
' Struktury połączeń relacyjnych
post ||--o{ mapping : "zawiera"
category ||--o{ mapping : "kategoryzuje"
post ||--o{ comment : "przypisuje"
@enduml
Analiza składni: Ten szablon modeluje klasyczną relację wiele do wielu między postami a kategoriami. Zamiast łączyć je bezpośrednio, wprowadza pośrednią tabelę (mapowania_postów_i_kategorii), w której obie kolumny pełnią rolę klucza głównego złożonego. Wskaźniki typu „kłoda kruka” jasno pokazują relacje cascading na poziomie komentarzy.