Diagram związków encji

Graficzny model przedstawiający encje, ich atrybuty oraz relacje między nimi. Używany do projektowania struktury bazy danych.

Diagram związków encji (ERD, od Entity-Relationship Diagram) to graficzny model, który pokazuje, z czego składa się Twoja baza danych: jakie ma encje (rzeczy, o których przechowujesz dane — np. Użytkownik, Zamówienie, Produkt), jakie te encje mają atrybuty (pola, np. imię, cena, data) oraz jak są ze sobą powiązane (relacje). To plan architektoniczny bazy, rysowany zanim cokolwiek wklepiesz w CREATE TABLE.

Do czego to służy

ERD pomaga ogarnąć strukturę danych na poziomie pojęć, zanim wejdziesz w detale techniczne. Zamiast od razu spierać się o typy kolumn, patrzysz na obrazek i widzisz: użytkownik składa wiele zamówień, zamówienie zawiera wiele produktów, produkt może być w wielu zamówieniach. To świetne narzędzie komunikacji — pokazujesz diagram koledze albo klientowi i on rozumie model bez czytania SQL-a.

Kluczowa rzecz to liczność relacji (kardynalność): jeden-do-jednego, jeden-do-wielu, wiele-do-wielu. Na diagramie zapisuje się ją notacją — najpopularniejsza to crow’s foot (kurza stopka), gdzie rozwidlenie linii oznacza „wiele”. Relacja wiele-do-wielu w praktyce zawsze rozbija się na tabelę pośredniczącą (junction table), bo relacyjna baza inaczej tego nie udźwignie.

Przykład z praktyki

Projektujesz sklep. Odpalasz dbdiagram.io albo Mermaid i piszesz model tekstem zamiast klikać prostokąty. W Mermaidzie wygląda to tak:

erDiagram USER ||--o{ ORDER : "składa" ORDER }o--o{ PRODUCT : "zawiera"

Z takiego opisu generujesz schemat, a narzędzia typu dbdiagram potrafią od razu wypluć gotowy CREATE TABLE z kluczami obcymi. Działa to też w drugą stronę: z istniejącej bazy (np. przez \d w psql albo reverse engineering w DBeaverze) odtworzysz diagram, żeby zrozumieć cudzy projekt.

Na co uważać

Najczęstszy błąd to mylenie ERD z diagramem klas UML — wyglądają podobnie, ale ERD opisuje dane, a nie metody i zachowanie obiektów. Drugi grzech: pomijanie tabel łączących przy relacjach wiele-do-wielu i udawanie, że „jakoś to będzie”. Trzeci: traktowanie diagramu jako świętości — gdy schemat bazy się zmienia, a ERD zostaje w wersji sprzed pół roku, masz ładny obrazek, który kłamie.

Pojęcia powiązane: normalizacja, klucz główny (primary key), klucz obcy (foreign key), kardynalność, schemat bazy danych, model relacyjny, notacja crow’s foot, UML.