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.).
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.
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.
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.
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.
ERD - Optionality relací
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“.
ERD - Kardinalita relací
Aplikováno na příklad vypadá ERD diagram takto:
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“.
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.