Entity-relationship diagram

Při návrhu tabulek vám pomůže si rozkreslit, jaká data potřebujete uložit a v jakém jsou vzájemném vztahu. K tomu se většinou používá tzv. ERD diagram.

ERD je velice jednoduchý a oblíbený nástroj pro popis objektů a jejich vztahů. Nemůžete tvrdit, že jste databázový specialista a přitom neumět nakreslit jednoduchý ERD diagram :-).

O ERD

ERD (Entity-relationship diagram) je konceptuální model. Konceptuální model popisuje data, která jsou potřeba pro váš byznis, pomáhá vám (a vašemu klientovi) popsat, jaká data a v jakém vztahu budete potřebovat. V ERD diagramu by měli být pouze ta data, která vás skutečně zajímají – data, která budete ukládat, měnit, zobrazovat a mazat.

Konceptuální model by měl být zcela nezávislý na tom, jak budou data fyzicky uložená. Jestli v PostgreSQL databázi, v MySQL databázi, v textovém souboru, nebo je budete tesat do kamene. Naproti tomu fyzický model už popisuje jak budou data uložena, například jaký použijete datový typ (například v PostgreSQL pro text použijete VARCHAR, v Oralce VARCHAR2 atd.).

Diagram tabulek

Diagram tabulek

ERD diagram vypadá podobně jako diagram na obrázku v pravo. V této kapitole se dozvíte, jak má vypadat opravdový ERD diagram (a proč obrázek v pravo není úplný ERD diagram).

Neexistuje žádný mezinárodně uznávaný standard, jak ERD diagrami kreslit, takže se můžete setkat s mnoha „dialekty“, tedy s různými grafickými prvky pro vyjádření stejné myšlenky (různými konvencemi, chcete-li). Já zde budu popisovat Oracle konvence pro zápis ERD. Nicméně, rozdíly mezi ERD diagrami jsou většinou zanedbatelné (někdo používá obdélníky s kulatými rohy, někdo se zaoblenýmy atp.). Nakonec si stejně budete čmárat ERD diagrami nejčastěji na papír podle svého, takže co :-).

Základní pojmy

Entita popisuje nějaký objekt z reálného světa. Popisuje, z čeho se objekt skládá (jaké jeho vlastnosti nás zajímají). Pokud umíte OO programování, můžete si entitu představit jako třídu. Z entity se stane ve fyzickém modelu tabulka.

Instance entity je už popis skutečného objektu popsaného entitou. Instance se stane ve fyzickém modelu řádkem tabulky. (V OO programování je instanci třídy objekt).

Atribut entity popisuje jednu vlasnost entity. Entita se obvykle zkládá z několika atributů. Ve fyzickém modelu se stane z atributu sloupec.

Identifikátor (UID) je atribut, nebo skupina atributů, které jednoznačně identifikují instanci entity (řádek v tabulce). Z identifikátorů se stane v databázi primární/unikátní klíč.

Optionality (volitelnost) je vlastnost atributu, která říká, zda je atribut povinný (musí mít hodnotu) nebo ne (může být NULL). Optionality se také týká relací. Musí se řádek odkazovat na jiný řádek v tabulce (musí existovat relace), nebo nemusí? (Například položka faktury se určitě musí odkazovat na fakturu.)

Kardinalita říká, v jakém mnosžví se něco vyskytuje. Jestli se vyskytuje právě jednou, nebo se může vyskytovat vícekrát. (Jestli se vyskytuje alespoň jednou se dozvíte z Optionality). Kardinalita se vztahuje na relace mezi entitami – můžete se (dává smysl) na řádek tabulky odkazovat jen jedním řádkem, nebo mnoha řádky?

Konvence pro kreslení ERD

Entity

Entity se kreslí do obdélníků se zakulacenými rohy. Jméno entity je v jednotném čísle a napsané velkými písmenami.

ED - Entity

ERD - Entity

Atributy

Atributy jsou vypsány pod názvem entity malými písmeny. Mezi atributy nepatří cizí klíč – ten se týká fyzického modelu a v některých implementacích ERD modelu (třeba v textovém souboru) se cizí klíč vůbec nemusí použít. Zato umělé klíče (id), které budete používat, do ERD diagramu patří.

Umělé klíče, pokud je použijete, bude váš business používat pro identifikaci instancí (řádek v tabulce). Cizí klíče bude využívat váš program, ale uživatelé programu o nich nebudou (v ideálním případě) nic vědět. Cizí klíč je jen technikálie.

ED - Atributy

ERD - Atributy

Optionality atirbutů a UID

Povinné atributy se označují hvězdičkou *, nepovinné kroužkem o. Atributy, ze kterých se skládá unikátní klíč (vzpomeťte si, že unikátní klíč se může skládat z více jak jednoho sloupečku) se označují hash tagem #.

Pokud má tabulka více jak jeden unikátní klíč, přidává se za # číslo, kterým se jednotlivé klíče odlišují. Takže můžete v entitě například 2x # (unikátní klíč zkládající se ze dvou atirbutů), nebo #1 a 2x #2 (dva unikátní klíče, druhý se skládá ze dvou atirbutů) atd.

ED - Optionality

ERD - Optionality

Z ERD diagramu nahoře vyčtete, že entita FIRMA má dva unikátní klíče (ale nevyčtete, který bude primárním klíčem – to vás v konceptuálním modelu nezajímá).

Zajímavá je taky entita TARIF. Tabulka tarif má jako primární klíč dvojici sloupců operator_id a nazev. Jenže cizý klíče se v konceptuálním modelu neuvádí. Evidentně nám tu chybí důležitá informace. O tom, jak se tato informace do ERD modelu zapíše, se dozvíte o pár odstavců dále.

Relace

Relace mezi entitami se zobrazují tak, že se entity spojí čárou. Čára může být plná, čárkovaná, nebo napůl plná a čárkovaná. Tím se vyjadřuje volitelnost (optionality) relace – zda relace musí nebo nemusí existovat.

Volitelnost relace si můžete představit tak, že v sloupečku cizýho klíče může být null.

ED - Optionality relací

ERD - Optionality relací

ED - Relace

ERD - Relace

Z diagramu teď můžete vyčíst například to, že nemůže existovat tarif bez odkazu na operátora.To se dá zařídit tím, že cizí klíč v tabulce tarif do tabulky operator bude povinný (NOT NULL). Operátor bez odkazu na tarif existovat může.

Dále ERD diagram vyjadřuje podmínku, že by neměla existovat adresa, na kterou se neodkazuje žádný kontakt (stejně tak firma nemůže existovat bez kontaktu). Databáze by taky neměla obsahovat poštu, ke které neexistuje adresa. To je trochu diskutabilní podmínka, ale já, jakožto zákazník, nechci mít v databázi „smetí“.
Všiměte si, že ne všechny z těchto podmínek je možné vynutit pomocí databázových omezení (constraints). Například, co se týče relace adresa - kontakt, tak ta bude implementována cizím klíčem v tabulce kontakt (který bude nepovinný). Na jednu adresu se může odkazovat více kontaktů, takže v tabulce adresa cizí klíč být nemůže – to by se adresa mohla odkazovat jen na jeden kontakt. (To, že se kontakt může odkazovat jen na jednu adresu, berte jako součást zadání klienta.) No a protože v tabulce adresa není cizí klíč, není možné k čemu dát omezení NOT NULL. A tak se může stát, že bude v databázi adresa, ke které nebude existovat kontakt.

Kardinalita

Kardinalita relace může nabývat jedné tří možností:

1:1
Jedné entitě A může odpovídat jen jedna entita B a naopak.
1:M
Jedné entitě A může odpovídat více jak jedna entita B, entita B odpovídá jen jedné entitě A.
M:M
Entitě A může odpovídat více jak jedna entita B, entitě B může odpovídat více jak jedna entita A.

Standardně se používají opravdu jen tyto vztahy. I když víte, že entitě A odpovídají právě 3 entity B, neoznčuje se kardinalita 1:3, ale stále 1:M. Ne že by existoval nějaký zákon, který by vám to zakazoval. Vztah 1:M se v databázi řeší tak, že tabulka pro entitu B má cizí klíč odkazující na entitu A. Neexistuje žádný standardní způsob jak zajistit, že budete mít v tabulce právě (nebo maximálně) 3 řádky odkazující se do tabulky entity A. Možná proto se používá 1:M (což je ale trochu zvláštní vysvětlení, když je ERD konceptuální model a o nějakou databázovou implementaci by se vůbec neměl starat, že :-).

Entita, která se může vyskytnout v relaci M-krát má na konci čáry vyznačující relaci „vydličku“.

ED - Kardinalita relací

ERD - Kardinalita relací

Aplikováno na příklad vypadá ERD diagram takto:

ED - Kardinalita

ERD - Kardinalita

Všechny vztahy v ERD diagramu mají kardinalitu 1:M.

Slabé entitní typy

Teď je ta správná chvíle vyrovnat se s entitou TARIF. Tarif by měl mít unikátní název, ale jen v rámci operátora. Proto by měl být součástí primárního klíče nejen název, ale i odkaz na operátora. To zatím z ERD diagramu není vidět.

Protože k určení jedinečné instance tarifu je zapotřebí znát operátora, ke kterému tarif patří, označuje se entita TARIF jako slabý entitní typ.

To, že je součástí unikátního identifikátoru odkaz na jinu entitu se označuje přeškrtnutím relace. Takto označená relace se anglický nazývá barred relationship (nevím jak to rozumě přeložit do češtiny).

Tarif ale není jediný slabý entitní typ v příkladu. Druhou takovou entitou je TELEFON. Když se na diagram podíváte, všimnete si, že součástí primárního klíče je odkaz na předvolbu. Protože se nejedná o umělý klíč, nemusí to být na první pohled zřejmé, ale předvolba je také odkaz, který by v ERD diagramu neměl být v seznamu atributů. Předvolba se teď zobrazuje v ERD diagramu duplicitně, což je nežádoucí. Řešením je odstranit atribut předvolba z entity TELEFON a z relace telefon - předvolba udělat „barred relationship“.

ED - Barred relationship

ERD - Barred relationship

Teď už to vypadá, že ERD diagram obsahuje všechny potřebné informace. Když si budete kreslit ERD sami pro sebe, většinou skončíte s takovýmto diagramem. Něco důležitého ale přeci jen chybí. A nejen o tom bude řeč v další kapitiole.

Komentář Hlášení chyby
Created: 9.3.2014
Last updated: 12.9.2015
Tato stánka používá ke svému běhu cookies, díky kterým je možné monitorovat, co tu provádíte (ne že bych to bez cookies nezvládl). Také vás tu bude špehovat google analytics. Jestli si myslíte, že je to problém, vypněte si cookies ve vašem prohlížeči, nebo odejděte a už se nevracejte :-). Prohlížením tohoto webu souhlasíte s používáním cookies. Dozvědět se více..