Co je to relační schéma? Jak vytvořit efektivní databázi?
Neexistuje jediná struktura databáze, která by byla vždy efektivnější než jakákoli jiná. Je to proto, že typ a množství uložených dat mění optimální strukturu databáze.
Je však velký rozdíl mezi vytvořením databáze optimalizované pro výkon a databáze optimalizované pro objem dat.
Pomocí relačního schématu v MySQL můžete vytvořit databázi optimalizovanou pro objem dat. To je ideální v situacích, kdy jsou náklady na ukládání, zpracování a paměť neúměrně vysoké.
Ačkoli to již není případ standardní elektroniky, stále existuje spousta situací, kdy by programátoři a vývojáři chtěli použít relační schéma. Ačkoli úložiště, výpočetní výkon a paměť jsou pro uživatele běžných počítačů levné, ve světě kvantových počítačů jsou tyto věci masivně drahé.
Také relační schéma je důležité v databázích MySQL, které se při vytváření významu spoléhají na vztahy. Například záznamy o zaměstnancích a akademické záznamy lze snadno považovat za sítě vztahů, které jsou lépe popsány pomocí relačního schématu než například databáze klíč-hodnota nebo grafové databáze.
Relační schéma je primárním prvkem relační databáze. Tyto databáze se spravují pomocí jazyka a struktury, které jsou v souladu s logikou prvního řádu. To umožňuje správu databází na základě vztahů mezi entitami, což usnadňuje jejich uspořádání podle objemu.
Relační schéma označuje metadata, která popisují strukturu dat v určité oblasti. Je to plán databáze, který nastiňuje způsob, jakým její struktura organizuje data do tabulek.
Příklad pokud vaše databáze obsahuje záznamy o zaměstnancích velkého podniku, pak můžete mít vztahy entit popisující každého zaměstnance jako silnou entitu takto:
- Jméno zaměstnance
- ID číslo
- Adresa
- Soubor dovedností zaměstnance
- Datum nástupu
- Odpracované roky
V tomto příkladu byste měli dva atributy dat relačního schématu. Nejprve byste měli atribut Zaměstnanec, který je primárním klíčem tabulky (protože vše souvisí se zaměstnancem), a atribut Adresa, což je složený atribut složený z různých prvků.
Atribut Adresa by se skládal z následujících hodnot:
- City
- Street
- Address number
- Zip code
Pokud toto víte, jste připraveni mapovat diagram vztahů entit na relační schéma. Mělo by vypadat takto:
- Zaměstnanec (jméno, identifikační číslo, číslo adresy, ulice, město, PSČ, datum nástupu)
- Soubor dovedností zaměstnance (identifikační číslo, soubor dovedností)
Měli byste si všimnout, že z tohoto seznamu jsou vyloučeny roky praxe. To proto, že se jedná o odvozený atribut, který lze vypočítat odečtením Data nástupu od aktuálního data. Důvodem, proč má Employee Skillset vlastní schéma, je to, že se jedná o vícehodnotový atribut.
Pro relační schéma se každý typ entity stává vlastní tabulkou a každý jednohodnotový atribut je sloupcem v této tabulce. Odvozené atributy lze bezpečně ignorovat, zatímco vícehodnotové atributy se stávají samostatnými tabulkami.
Způsob převodu slabých typů entit na relační schéma je podobný výše popsanému postupu s tím rozdílem, že slabé typy entit se stávají vlastními tabulkami a primární klíč silné entity funguje v tabulce jako cizí klíč.
To znamená, že pro silnou entitu Zaměstnanec byste vytvořili složený primární klíč složený z cizího klíče Závislá a klíče samotné slabé entity. Schéma by tak vypadalo takto:
- Zaměstnanec (Jméno, ID číslo, Číslo adresy, Ulice, Město, PSČ, Datum nástupu)
- Závislá (Zaměstnanec, ID závislé entity, Jméno, Adresa)
Souvislost je zde mezi ID číslem v tabulce Zaměstnanec a prvkem Zaměstnanec v tabulce Závislá.
Po dokončení této práce můžete začít převádět vztahy. K tomu je třeba pochopit kardinalitu a stupeň každého vztahu.
- Existují tři možné kardinality – 1:1, 1:M, 1:N
- Existují tři možné stupně – unární, binární a ternární.
Pokračujeme-li ve výše uvedeném příkladu, lze tabulku Zaměstnanec zkombinovat s novou tabulkou Oddělení a vytvořit tak binární vztah 1:1.
Pokračujeme-li ve výše uvedeném příkladu, lze tabulku Zaměstnanec zkombinovat s novou tabulkou Oddělení a vytvořit tak binární vztah 1:1. Pokud zaměstnanec řídí konkrétní oddělení, pak může být popsán jako částečný účastník, zatímco oddělení by bylo popsáno jako celkový účastník.
Relační schéma by vypadalo takto:
- Zaměstnanec (jméno, číslo ID, číslo adresy, ulice, město, PSČ, datum nástupu)
- Oddělení (číslo ID vedoucího, ID oddělení, jméno, adresa)
V tomto případě se primární klíč částečného účastníka stane cizím klíčem celkového účastníka. Identifikační číslo manažera koreluje s příslušným identifikačním číslem zaměstnance.
Toto ukazuje důležitou část tvorby relačního schématu. Primární klíč jednoho z účastníků v binárním vztahu 1:1 se může stát cizím klíčem druhého. Jiným způsobem popisu výše uvedeného vztahu by bylo použití Manages jako cizího klíče v položce Employee, který by koreloval s primárním klíčem Department ID v položce Department.
Příkladem binárního vztahu 1:N by byl vztah mezi Učitelem vyučujícím předmět. V konkrétní třídě může učitel učit více než jeden Předmět pro různé studenty, přesto všechny Předměty sdílejí stejný vztah s učitelem.
Ve výše uvedeném binárním vztahu 1:1 měl každý odbor jedinečného vedoucího. U tohoto binárního vztahu 1:N může stejného učitele sdílet různý počet studentů. Primárním klíčem učitele by bylo ID učitele, které by korelovalo s cizím klíčem předmětu v položce Učitel.
Pro popis binárního vztahu M:N si představte studenta, který si zapisuje předmět. Vytvořte novou tabulku popisující Studenta a další popisující Předmět. Obě tyto tabulky spolu souvisejí prostřednictvím aktu zápisu a obě obsahují cizí klíče.
- Cizím klíčem pro Studenta je ID Studenta.
- Cizím klíčem pro Kurz je ID Kurzu.
Primární klíč nové tabulky je kombinací cizích klíčů jednotlivých entit. Popsali byste ji jako (ID studenta, ID kurzu). Jedná se o jedinečné binární relační schéma M:N, které spojuje jednotlivé studenty s kurzy.
Toto funguje, protože ID jsou ze své podstaty vytvořena pro účely cizích klíčů v relačních databázích.
Pro popis samoreferenčních vztahů můžete použít relační schéma. Například dva zaměstnanci, kteří jsou navzájem manželé, by mohli mít cizí klíč Spouse. Pro cizí klíče obou těchto zaměstnanců bude odkazem ID zaměstnance druhého zaměstnance, který je primárním klíčem příslušné tabulky každého zaměstnance.
Toto funguje i ve vztahovém schématu s kardinalitou 1:N. V případě, že se jedná o cizí klíč, je možné, že se jedná o cizí klíč. Samotné pole primárního klíče by se v tomto případě stalo cizím klíčem téže tabulky. To je stejné jako u unárního schématu 1:1.
Například zaměstnanec, který je vedoucím podřízeného, může mít jako cizí klíč vedoucího. V tomto případě by ID zaměstnance bylo primárním klíčem ve stejné tabulce.
Samostatné odkazování na vztah M:N vyžaduje dvě tabulky. Jedna musí reprezentovat danou entitu a druhá musí reprezentovat vztah M:N.
Představte si zaměstnance, který je zodpovědný za zajištění kvality určitého výrobku nebo služby. Tento vztah by musel obsahovat jak Garanta, tak Příjemce jako cizí klíče, které se kombinují, aby korelovaly s ID zaměstnance v tabulce Zaměstnanec. Jak Ručitel, tak Příjemce by fungovaly jako primární a cizí klíče v rámci nově vytvořené tabulky relačního schématu.
Zatímco binární a unární vztahy lze jednoduše popsat pomocí relačního schématu s jednou nebo dvěma tabulkami. Ternární tabulky vyžadují třetí, novou tabulku.
Primární klíč této nové tabulky se skládá ze součtu cizích klíčů každé zúčastněné entity. To znamená, že nová tabulka musí obsahovat tři cizí klíče, s nimiž bude korelovat.
Například vztah mezi lékařkou a jejím pacientem se ve skutečnosti skládá ze tří entit: Lékař, pacient a lék. Chcete-li tento vztah správně popsat jako relační schéma, musíte každé z těchto entit přiřadit cizí klíče a korelovat je do nové tabulky s názvem Předpis.
Toto je jednoduchý způsob, jak si představit fungování trojčlenné tabulky. Primární klíč nově vytvořené tabulky Předpis je (ID lékaře, ID pacienta, ID léku). Každé schéma, které neobsahuje tyto tři důležité údaje, postrádá důležitou část skládačky.
Tento přístup by umožnil správci databáze vytvořit uspořádaný archiv receptů, který by zohledňoval konkrétní typy léků, okamžitě koreloval se jmény pacientů, kteří je užívají, a nabízel jména lékařů, kteří je předepsali.
Pro úplnost můžete do tabulky Léky přidat datum expirace, aby byl tento údaj dostupný v rámci hlavní matice. Do tabulky Předpis můžete přidat Datum příští návštěvy nebo Datum doplnění. Do tabulky Pacient byste logicky chtěli přidat Datum narození, Adresu a další důležité relační údaje.
Všechny tyto nástroje dohromady umožňují vytváření relačně orientovaných databází v systému MySQL. Vytváření vlastních databází MySQL si můžete procvičit online v libovolném prohlížeči pomocí SQLDBM.