Entitně-Relační model nebo také ER model databáze je model, kterým se budeme v tomto školním roce zabývat. Pro práci s ER modelem je třeba znát základní terminologii:
Je jsoucno, tedy cokoliv co je - existuje. Takové jsoucno jsme schopni popsat pomocí vlastností - atributy. A rovněž atributy mají své konkrétní podoby, tj. záznamy v případě databází.
Entitou může být např. Nábytek.
Vlastností nábytku bude např. název a materiál.
Konkrétní podobou (záznam) vlastnosti název je: židle a vlastnosti materiál: dřevo.
Nábytek má vlastnost název a tím je židle.
Nábytek má vlastnost materiál a tím je dřevo.
Relace je vztah mezi entitami. I tento vztah má nějaké vlastnosti a tím jsou Kardinalita (Mocnost) a Mandatornost (Povinnost). Relace nám určuje, zda mezi entitami je nějaká vazba či nikoliv.
Mandatornost neboli povinnost vztahu, nám určuje u relace zda jde o vztah povinný či nepovinný. Tzn., že jedná-li se o vztah povinný, musíme v dané entitě vyplnil vzájemnou vazbu mezi entitami (záleží na kardinalitě) a nelze bez doplnění tohoto vztahu záznam do entity vložit.
Např.:
Vztah mezi entitou žák a třída bude povinný, protože nelze zapsat do databáze žáka aniž by nebyl přiřazen k jakékoliv třídě. Vztah je tedy mandatorní.
V případě, že máme firmu, ve které zaměstnanci mohou pracovat pouze pro jedno konkrétní oddělení, pak můžeme tento vztah označit i jako NE-mandatorní, neboť můžeme do databáze zapsat i zaměstnance (ředitel), který nemusí být zařazen do žádného oddělení. V případě, že by tento vztah byl mandatorní, pak musíme u každého zaměstnance vyplnit i název oddělení, jinak bychom zaměstnance nemohli do databáze zapsat.
Kandidátními klíči jsou takové atributy, které jsou v celém sloupci dané entity unikátní pro každý jeden řádek záznamu. Tzn. máme-li ID zaměstnance, rodné číslo, aj. Oba atributy můžeme označit za kandidátní klíče, ale pouze jeden z nich vybereme jako primární klíč.
Primární klíč je pak takový klíč, který je vlastní v dané entitě pro daný řádek záznamu. Použiji-li tento klíč v jiné entitě, pak se jedná o klíč cizí, neboť není pro danou entitu vlastní, ale pouze odkazuje do primární entity. Kandidátní klíče jsou jednoznačným identifikátorem konkrétního řádku záznamu a nelze je zaměnit.
Normální formy jsou soupis několika pravidel, které se dodržují proto, aby při návrhu, resp. modelování databáze nedošlo k chybám, které následně půjde těžko odstranit. Jsou to pravidla, která nám umožňují modelovat databáze dle normy, která je v praxi běžná.
Celkem máme 7. normálních forem s tím, že existuje i 0tá forma, která je brána jako samozřejmost. V praxi se modeluje minimálně až do 3. normální formy. Další jsou dle posouzení.
0. NF - Žádný atribut nesmí být nulový.
1. NF - Každý atribut musí obsahovat pouze atomární hodnoty.
2. NF - Všechny neklíčové atributy jsou závislé na kandidátním klíči.
3. NF - Neklíčové atributy jsou na sobě vzájemně nezávislé.
Atributem v Entitně-Relačních databází je ve fyzické podobě sloupec v tabulce. Jestliže bude v celé databázi celý sloupec (atribut) nulový, pak nemá význam takový sloupec v databázi navrhovat.
Např. máte-li tabulku s docházkou zaměstnanců a navrhnete-li atribut "nálada", který nikdo při příchodu ani odchodu vyplňovat nebude, pak nemá smysl takový atribut při modelování vkládat do databáze.
Při zápisu dat do jednotlivých atributů, musíme dbát na to, aby byla data v co atomární podobě. Máme-li např. atribut adresa, mohou zapsaná data v buňce vypadat takto: Ulice 23/454, 14569 Praha 14 - Křižíkov.
Na první pohled je jasné, že pokud bychom chtěli vyhledávat např. všechny uživatele dle města, nelze s takto zapsanými daty dotaz provést, neboť textový řetězec obsahuje více, než pouhé město uživatele. proto musíme data rozdělit na atomární hodnoty a tj.
Ulice | ČP | PSČ | Město | Městská část |
Ulice | 23/454 | 14569 | Praha 14 | Křižíkov |
Abychom mohli identifikovat neklíčové atributy jako např. adresa, je třeba, aby tyto atributy měli vzájemnou vazbu na kandidátní klíče, ať už primární nebo cizí klíč. Např. ve výše uvedeném příkladu s adresou. Jestliže budeme chtít znát adresu Josefa Vomáčky, vyhledáme si všechny atributy adresy pomocí primárního klíče s názvem ID 123.
Typickým příkladem, kdy je tato normální forma porušena je v případě, že chceme např. identifikovat plat Josefa Vomáčky. Dotazujeme se na atribut jméno + příjmení a hledáme atribut plat. Tedy Josef Vomáčka 24.000 Kč. Ale atribut jméno i příjmení jsou neklíčové atributy, proto nelze pomocí těchto atributů vyhledávat další neklíčový atribut tj. plat. Správné řešení:
Modelování databáze má celkem 4. fáze, kterými je dobré si projít, aby výsledná práce byla hodnotná a nic jsme během modelování nezapomněli. Každá z fází nám přináší nové výzvy a přesněji specifikuje jak bude náš výsledný databázový systém i s daty fungovat.
Definice požadavků
Konceptuální model
Logický model
Fyzický model
Před vlastním modelováním databáze, je třeba si nejprve definovat co by navrhovaný systém jako takový měl umět, jaké bude mít funkcionality. Od těchto požadavků se pak může odvíjet rozsah a složitost návrhu databáze, která bude použita pro tento systém.
Definicí požadavků si můžeme představit jako např.:
Přihlašování uživatele k administraci
Obnova hesla přes email
Zasílání SMS notifikace
Možnost recenzí produktu aj.
Po definování požadavků na systém, pro který modelujeme databázi, přejdeme ke konceptuálnímu modelování. Konceptuální model, jak už název napovídá představuje koncept datové struktury databáze. Stejně jako je vhodné vytvořit si koncept slohové práce a až poté čistopis, tvoříme stejně tak i koncept samotné databáze. Navrhujeme tak jaké entity a vlastnosti vzájemně budeme propojovat a definujeme jaký vztah mezi sebou entity budou tvořit.
Neexistuje žádný specificky definovaný postup, jak tvořit konceptuální model, proto následující postup je doporučení vycházející z dobré praxe.
V první fázi konceptuálního modelování doporučuji vypsat si entitu po entitě, které vyplývají ze zadání. A zároveň ke každé entitě vymýšlet i její vlastnosti. Entity si pište na plátno vlevo a vlastnosti entit na plátno vpravo. Např.:
Jak je z obrázku patrné, při sepisování vlastností a entit, nám vyplývá, že mnohé entity budou mít společné vlastnosti, např. ID nebo Název. Proto je vhodné si rozepsat vlastnosti entitu po entitě a v závěru projít celý seznam vlastností, zda jsme u nějaké entity nezapomněli na vlastnost, která nás nemusela zprvu napadnout.
Dále je ze seznamu patrné, že některé vlastnosti by bylo vhodné pojmout spíše jako entity, protože se u nich mohou záznamy duplikovat, např. Odesílatel, Příjemce, způsob doručení, aj.
V druhé fázi konceptuálního modelu navrhujeme vazbu mezi entitami a popisujeme vztahy pomocí vlastností (Kardinalita + Mandatornost) a u entit popisujeme jejich vlastnosti.
Entity označujeme pomocí pravidelného obdélníku.
Vlastnosti u entit označujeme jako tykadlo vystupující z entity.
Relaci, tedy vztah popisujeme spojením čar ke kosodélníku, ve kterém vypisujeme otázku, která vyjadřuje kardinalitu vztahu.
Logický model se tvoří v MySQL Workbench, při exportu scriptu pro tvorbu databáze je z něho potřeba odstranit "VISIBLE"
## Datové typy
- Číselné
- Řetězcové
- Časové
# Číselné
- tinyint
- smallint
- int
- bigint
- float(n,m)
- double(n,m)
float(10,4)
012345,6789
float(20,10)
0123456789,0123456789
# Řetězcové
char(10);
varchar(10);
HelloWorld = 10 byte
Ahoj = CHAR = 10B, VAR= 4B
tinytext = 255;
+420 123 456 789
# Časové
DATE = YYYY-MM-DD = "2021-01-13"
YEAR = (2) "21" / (4) "2021"
TIME = HH:mm:ss = "13:22:10"
DATETIME = YYYY-MM-DD HH:mm:ss = "2021-01-13 13:22:10"
TIMESTAMP = YYYYMMDDHHmmss = "20210113132415"
20210114202000 - 20210113132710 = 0000 00 01:06:07 00