Entitně Relační Diagram

Co je ERD?

Pomocí entitně relačního diagramu vyjadřujeme data, která chceme v systému mít a vztahy mezi nimi.

Abychom takový model byli schopni vytvořit, musíme se seznámit se základními pojmy. Úplným základem je entita, která znázorňuje unikátní objekt reálného světa a v diagramu je pojmenováváme podstatným jménem.

Každá entita má vlastnosti, kterým se říká atributy. Podle struktury se bavíme o jednoduchých atributech, které jasně nesou jednu informaci a nelze je dál dělit. Patří sem například rodné číslo nebo věk. Pokud se vlastnost dá rozdělit na více logických kousků, mluvíme o složeném atributu. Častým příkladem je adresa, kterou můžeme dále rozepsat na město, ulici a PSČ.

Abychom dokázali jednotlivé záznamy v rámci entity jednoznačně odlišit, slouží nám speciální atribut zvaný primární klíč (zkráceně PK). Jeho hodnota musí být vždy unikátní – představ si ho například jako vygenerované ID uživatele nebo rodné číslo. V diagramu se tento atribut označuje zkratkou PK přímo u jeho názvu. Pokud pak chceme dvě entity propojit, primární klíč jedné z nich vložíme do té druhé jako takzvaný cizí klíč (FK z anglického Foreign Key). Vznikne tak pomyslný odkaz, díky kterému databáze přesně ví, který záznam ke kterému patří.

Jakmile máme nadefinované entity s patřičnými atributy, musíme určit vazby mezi nimi. Tyto vztahy se nazývají relace a obvykle se popisují slovesy. Například student má skříňku nám přiblíží, jak relace mezi entitami přesně vypadá. Rozlišujeme tři základní typy relací: jedna ku jedné (1:1), jedna ku mnoha (1:N) a mnoha ku mnoha (M:N).

Kreslení diagramu jako prevence před chybami

I když se může kreslení diagramů zdát jako zbytečná ztráta času, jedná se o krok, který nám pomůže předejít chybám a komplikovaným úpravám v databázi. Vizuální návrh nás nutí se nad našimi daty zamyslet ještě dřív, než začneme psát kód. Zároveň funguje jako skvělý podklad pro brainstorming – nakreslené struktuře každý hned porozumí, takže se nad ní může sejít více lidí a společně debatovat o tom, zda dává smysl.

Snáz se tak odhalí logické nedostatky, jako jsou chybějící atributy nebo nesmyslné relace. V tento moment znamenají jakékoliv úpravy jen překreslení pár spojnic či upravení textu u entit. Jakmile se ale taková chyba najde v situaci, kdy už je databáze napojena na aplikaci, úpravy se dělají velmi těžko a může to vést k přepisování velké části kódu.

Notace

Aby diagramy byly jednotné a mohl jim porozumět jakýkoliv vývojář, vznikla pravidla. Těmto zavedeným sadám značek a jak je používat se říká notace. Pojďme se podívat na tři nejpoužívanější notace, se kterými se můžeš setkat.

Chenova notace - Původní způsob notace, kde se entity kreslí jako obdélníky, atributy jako ovály připojené čarou a relace tvoří kosočtverce umístěné na spojnicích. Je vizuálně velmi názorná, ale u velkých databází může zabírat hodně místa.
Crow's Foot (Vraní noha) - Nejpoužívanější notace v profesionálním návrhu databází. Diagram je kompaktnější, jelikož entita tvoří tabulku, do které se atributy přímo vepisují. Svůj název dostala podle specifického rozvětveného značení na koncích spojnic (připomínající ptačí pařát), které jasně definuje typy vztahů (1:N, M:N).
UML (Unified Modeling Language) - Ačkoliv UML není primárně určeno na tvorbu ER diagramu, jeho zde skvěle zastupuje takzvaný diagram tříd (Class diagram). Ten vizualizuje data velmi podobně jako Crow's foot, ale umožňuje přidat i další programátorské detaily.

Unified Modeling Language

Už bylo nakousnuto, že UML neslouží primárně pro kreslení ER diagramů. Umožňuje nám pomocí různých diagramů popsat, jak se celý systém chová, kdo ho používá a jaké procesy v něm probíhají.

Use Case diagram (Diagram užití) - Ukazuje, kdo systém používá a co v něm může dělat (např. zákazník vytváří objednávku, administrátor přidává produkt).
Sequence diagram (Sekvenční diagram) - Krok za krokem popisuje, jak si mezi sebou části aplikace v čase předávají informace (např. proces ověření platby).
Activity diagram (Diagram aktivit) - Funguje jako přehledný vývojový diagram, který znázorňuje posloupnost kroků v nějakém procesu.
State diagram (Stavový diagram) - Zobrazuje, jakými životními fázemi může konkrétní objekt projít (např. objednávka mění stav z Nová na Zaplacená a Odeslaná).

Více informací o použití těchto a dalších diagramů se dočteš: GeeksforGeeks – Unified Modeling Language (UML) Introduction nebo Visual Paradigm – What is UML? (Unified Modeling Language Guide)

Jak na vlastní diagram

Než si ukážeme jednoduchý diagram, je potřeba se seznámit se samotným zápisem jednotlivých vztahů. Pro názornou ukázku využijeme Crow's Foot notaci. Z obrázku můžeme jasně vyčíst, jak pomocí tří symbolů na konci spojnice můžeme popsat početní vztah.

Čtení relací a kardinalit

V diagramu máme čtyři entity, které jsou propojené relacemi. Ke správnému chápání diagramu patří i vlastnost umět diagram správně přečíst:

CLASS a STUDENT - Každý student musí patřit do právě jedné třídy. Jedna třída pak může obsahovat jednoho nebo více studentů.
STUDENT a LOCKER - Každá skříňka je přiřazena právě jednomu konkrétnímu studentovi. Student však může mít nanejvýš jednu skříňku, přičemž ji mít nemusí vůbec.
STUDENT a CLUB - Student může navštěvovat libovolné množství kroužků, ale nemusí se zapsat na žádný. Podobně i kroužek může mít zapsáno mnoho studentů, nebo zatím žádného.

U entity LOCKER se použil takzvaný složený primární klíč. Jednotlivé atributy, které ho tvoří (číslo a patro), se samy o sobě mohou opakovat, ale kombinace obou musí být unikátní.

Mezi STUDENT a CLUB neexistuje cizí klíč, jelikož M:N vztah v databázích neexistuje a bude muset dojít k úpravě v dalších krocích.

Jak pokračovat s diagramem

Hotový diagram zachycuje logickou představu o datech, než podle něj začneme psát SQL kód, je potřeba udělat ještě pár kroků.

V diagramu se vyskytují složené atributy, a než se s nimi bude jakkoliv dál pracovat, je potřeba je rozdělit. To je prvním krokem procesu zvaného normalizace, což je čištění dat a odstraňování zbytečných duplicit i nevhodných závislostí. O tom, jak správně normalizovat, se můžeš dozvědět v článku: What is Normalization in DBMS? na GeeksforGeeks.

Po této úpravě se ER diagram převede do relačního modelu, kde se přidají datové typy a odstraní se M:N vazby. Ty v databázi nelze vytvořit a je potřeba je rozdělit na dva 1:N vztahy, pomocí takzvané propojovací tabulky. V relačním modelu k našemu ER diagramu by vznikla tabulka STUDENT_CLUB, kde bude složený PK (ID_student a ID_club), který bude zároveň i FK. Jak udělat převod se dozvíš v tomto průvodci: Map ER to Relational Model.

Dále už stačí zvolit jakýkoliv databázový systém (MySQL, PostgreSQL,...) a začít tvořit tabulky.

V čem diagramy tvořit?

Nástroje na kreslení diagramů:

draw.io: Bezplatný online nástroj pro kreslení jakýchkoliv schémat. Obsahuje celou knihovnu tvarů pro ERD i s Crow's Foot notací. Vznikl v něm i náš ukázkový diagram a na jejich blogu najdeš spoustu přehledných návodů. Jak pracovat s programem představuje i tohle video: Creating Entity Relationship Diagrams using Draw.io

dbdiagram.io: Webový nástroj, kde diagram nekreslíš myší, ale píšeš pomocí jednoduchého textového kódu. Výsledný nákres ti navíc umí rovnou vygenerovat jako SQL kód pro vytvoření tabulek.

Programy pro práci s databází:

MySQL Workbench: Oficiální nástroj pro správu MySQL databází. Umožňuje diagram naklikat a přímo z něj vytvořit reálnou databázi. Funguje to i naopak – z již existující databáze ti sám vytáhne a vykreslí přehledný ERD.
DBeaver: Univerzální bezplatný správce databází, který podporuje prakticky jakoukoliv SQL databázi. Z připojených tabulek ti dokáže na jedno kliknutí automaticky vygenerovat a zobrazit jejich ER diagram.