RELAČNÍ DATABÁZOVÝ MODEL: PRVKY, JAK NA TO, PŘÍKLAD - TECHNOLOGIE - 2025

Relační databázový model je způsob strukturování dat pomocí vztahů, pomocí mřížky podobné struktury, skládající se ze sloupců a řádků. Je to koncepční princip relačních databází. Navrhl jej Edgar F. Codd v roce 1969.

Od té doby se stal dominantním databázovým modelem pro obchodní aplikace ve srovnání s jinými databázovými modely, jako jsou hierarchické, síťové a objektové.

Zdroj: pixabay.com

Codd netušil, jak extrémně životně důležitý a vlivný bude jeho práce jako platformy pro relační databáze. Většina lidí je velmi dobře obeznámena s fyzickým vyjádřením vztahu v databázi: v tabulce.

Relační model je definován jako databáze, která umožňuje seskupení jeho datových prvků do jedné nebo více nezávislých tabulek, které mohou být vzájemně propojeny pomocí polí společných pro každou související tabulku.

Správa databáze

Tabulka databáze je podobná tabulce. Vztahy, které lze vytvořit mezi tabulkami, však umožňují relační databázi účinně ukládat velké množství dat, které lze efektivně načíst.

Účelem relačního modelu je poskytnout deklarativní metodu pro specifikaci dat a dotazů: uživatelé přímo deklarují, jaké informace databáze obsahuje a jaké informace z ní chtějí.

Na druhou stranu ponechávají software softwaru pro správu databází, aby popsal datové struktury pro ukládání a postup načítání odpovědí na dotazy.

Většina relačních databází používá jazyk SQL pro dotazování a definování dat. V současné době existuje mnoho systémů správy relačních databází nebo RDBMS (systém správy relačních dat), jako je Oracle, IBM DB2 a Microsoft SQL Server.

Funkce a prvky

- Všechna data jsou koncepčně reprezentována jako uspořádané uspořádání dat v řádcích a sloupcích, nazývané relace nebo tabulka.

- Každá tabulka musí mít záhlaví a tělo. Záhlaví je jednoduše seznam sloupců. Tělo je sada dat, která vyplňují tabulku, uspořádaná do řádků.

- Všechny hodnoty jsou skalární. To znamená, že na kterékoli dané pozici řádku / sloupce v tabulce je pouze jedna hodnota.

-Elementy

Následující obrázek ukazuje tabulku se jmény jejích základních prvků, které tvoří kompletní strukturu.

Tuple

Každý řádek dat je n-tice, známá také jako záznam. Každý řádek je n-n-tice, ale "n-" je obecně vyřazeno.

Sloupec

Každý sloupec v n-tice se nazývá atribut nebo pole. Sloupec představuje sadu hodnot, které může mít určitý atribut.

Klíč

Každý řádek má jeden nebo více sloupců nazývaných klíč tabulky. Tato kombinovaná hodnota je jedinečná pro všechny řádky v tabulce. Pomocí tohoto klíče bude každý tuple jednoznačně identifikován. To znamená, že klíč nelze duplikovat. Nazývá se primární klíč.

Na druhé straně, cizí nebo sekundární klíč je pole v tabulce, které odkazuje na primární klíč jiné tabulky. Používá se k odkazu na primární tabulku.

- Pravidla integrity

Při navrhování relačního modelu definujete některé podmínky, které musí být v databázi splněny, tzv. Pravidla integrity.

Integrita klíče

Primární klíč musí být jedinečný pro všechny n-tice a nesmí být nulový (NULL). V opačném případě nebudete moci řádek jednoznačně identifikovat.

U klíče s více sloupci nesmí žádný z těchto sloupců obsahovat NULL.

Referenční integrita

Každá hodnota cizího klíče se musí shodovat s hodnotou primárního klíče odkazované nebo primární tabulky.

Řádek s cizím klíčem lze vložit do sekundární tabulky pouze tehdy, pokud tato hodnota existuje v primární tabulce.

Pokud se hodnota klíče v primární tabulce změní z důvodu aktualizace nebo odstranění řádku, měly by být odpovídajícím způsobem aktualizovány nebo odstraněny všechny řádky v sekundárních tabulkách s tímto cizím klíčem.

Jak vytvořit relační model?

-Sbírat data

Pro uložení do databáze je nutné shromáždit potřebná data. Tato data jsou rozdělena do různých tabulek.

Pro každý sloupec musí být vybrán vhodný datový typ. Například: celá čísla, čísla s pohyblivou řádovou čárkou, text, datum atd.

-Definujte primární klíče

Pro každou tabulku musí být jako primární klíč vybrán sloupec (nebo několik sloupců), který jedinečně identifikuje každý řádek v tabulce. Primární klíč se také používá k odkazu na jiné tabulky.

-Vytvářejte vztahy mezi tabulkami

Databáze sestávající z nezávislých nesouvisejících tabulek slouží jen málo účelu.

Nejdůležitějším aspektem při vytváření relační databáze je identifikace vztahů mezi tabulkami. Typy vztahů jsou:

Jeden k mnoha

V databázi „Class Listing“ může učitel učit nula nebo více tříd, zatímco třídu vyučuje jeden učitel. Tento typ vztahu je známý jako jeden-k-mnoho.

Tento vztah nelze reprezentovat v jedné tabulce. V databázi «Seznam tříd» můžete mít tabulku s názvem Učitelé, která ukládá informace o učitelích.

Chcete-li uložit třídy učené každým učitelem, můžete vytvořit další sloupce, ale měli byste problém: kolik sloupců vytvořit.

Na druhé straně, pokud máte tabulku nazvanou Třídy, která ukládá informace o třídě, můžete vytvořit další sloupce pro ukládání informací o učiteli.

Protože však učitel může vyučovat mnoho tříd, jeho data by byla duplikována v mnoha řádcích v tabulce tříd.

Navrhněte dvě tabulky

Proto je třeba navrhnout dvě tabulky: tabulku Classes pro ukládání informací o třídách, s Class_Id jako primárním klíčem, a tabulku Teachers pro ukládání informací o učitelích, s Teacher_Id jako primárním klíčem.

Vztah jednoho k mnoha pak lze vytvořit uložením primárního klíče z hlavní tabulky (Master_Id) do tabulky Classes, jak je znázorněno níže.

Sloupec Master_Id v tabulce Classes je známý jako cizí klíč nebo sekundární klíč.

Pro každou hodnotu Master_Id v hlavní tabulce může být v tabulce tříd 0 nebo více řádků. Pro každou hodnotu Class_Id v tabulce Classes je v tabulce Teachers pouze jeden řádek.

Mnoho až mnoho

V databázi „Prodej produktu“ může zákaznická objednávka obsahovat více produktů a produkt se může objevit ve více objednávkách. Tento typ vztahu je známý jako mnoho k mnoha.

Databázi „Prodej produktů“ můžete spustit se dvěma tabulkami: Produkty a objednávky. Tabulka Výrobky obsahuje informace o produktech, s primárním klíčem productID.

Na druhé straně tabulka Objednávky obsahuje objednávky zákazníka, s primárním klíčem orderID.

Objednané produkty nemůžete uložit v tabulce Objednávky, protože nevíte, kolik sloupců je pro produkty vyhrazeno. Ze stejného důvodu nelze objednávky ukládat do tabulky Výrobky.

Chcete-li podpořit vztah mezi mnoha, je třeba vytvořit třetí tabulku známou jako spojovací tabulka (OrderDetails), kde každý řádek představuje položku v určitém pořadí.

V tabulce OrderDetails se primární klíč skládá ze dvou sloupců: orderID a productID, které jednoznačně identifikují každý řádek.

Sloupce orderID a productID v tabulce OrderDetails slouží k odkazu na tabulky Order and Products. Proto jsou také cizími klíči v tabulce OrderDetails.

Jeden za druhým

V databázi „Prodej produktů“ může mít produkt volitelné informace, jako je další popis a jeho obrázek. Pokud ji ponecháte uvnitř tabulky Produkty, vytvoří se mnoho prázdných míst.

Proto lze pro uložení volitelných dat vytvořit další tabulku (ProductExtras). Pro produkty s volitelnými údaji bude vytvořen pouze jeden záznam.

Obě tabulky, Products a ProductExtras, mají vzájemný vztah. Pro každý řádek v tabulce Produkty je maximálně jeden řádek v tabulce ProductExtras. Stejný identifikátor produktu musí být použit jako primární klíč pro obě tabulky.

Výhoda

Strukturální nezávislost

V modelu relační databáze změny struktury databáze neovlivňují přístup k datům.

Když je možné provést změny ve struktuře databáze, aniž by to ovlivnilo schopnost DBMS získat přístup k datům, lze říci, že byla dosažena strukturální nezávislost.

Konceptuální jednoduchost

Relační databázový model je ještě koncepčně jednodušší než hierarchický nebo síťový databázový model.

Protože model relační databáze osvobodí návrháře od podrobností fyzického ukládání dat, mohou se návrháři zaměřit na logické zobrazení databáze.

Snadný design, implementace, údržba a použití

Relační databázový model dosahuje nezávislosti na datech i nezávislosti na struktuře, čímž je návrh, údržba, správa a používání databáze mnohem snazší než u ostatních modelů.

Kapacita dotazů ad hoc

Přítomnost velmi výkonné, flexibilní a snadno použitelné schopnosti dotazování je jedním z hlavních důvodů obrovské popularity modelu relační databáze.

Dotazovací jazyk modelu relační databáze, nazývaný strukturovaný dotazovací jazyk nebo SQL, činí ad-hoc dotazy realitou. SQL je jazyk čtvrté generace (4GL).

4GL umožňuje uživateli specifikovat, co má být provedeno, aniž by bylo stanoveno, jak by mělo být provedeno. S SQL tedy mohou uživatelé specifikovat, jaké informace chtějí, a nechat podrobnosti o tom, jak informace získat, do databáze.

Nevýhody

Výdaje na hardware

Model relační databáze skrývá složitosti jeho implementace a podrobnosti o fyzickém ukládání uživatelských dat.

K tomu potřebují relační databázové systémy počítače s výkonnějšími zařízeními pro ukládání hardwaru a dat.

Proto RDBMS potřebuje výkonné stroje pro hladký chod. Protože však výkonnost moderních počítačů roste exponenciálně, není potřeba většího výkonu zpracování v dnešním scénáři velkým problémem.

Snadný design může vést ke špatnému designu

Relační databáze se snadno navrhuje a používá. Uživatelé nemusí znát složité podrobnosti fyzického ukládání dat. Pro přístup k nim nemusí vědět, jak jsou data skutečně uložena.

Toto snadné navrhování a používání může vést k vývoji a implementaci špatně navržených systémů správy databází. Protože je databáze efektivní, tyto konstrukční neefektivnosti se neobjeví, když je databáze navržena a existuje pouze malé množství dat.

Jak databáze roste, špatně navržené databáze zpomalí systém a povedou ke snížení výkonu a poškození dat.

Fenomén «informačních ostrovů»

Jak bylo uvedeno výše, systémy relačních databází se snadno implementují a používají. To vytvoří situaci, kdy si příliš mnoho lidí nebo oddělení vytvoří vlastní databáze a aplikace.

Tyto ostrovy informací zabrání integraci informací, která je nezbytná pro hladké a efektivní fungování organizace.

Tyto jednotlivé databáze také způsobí problémy, jako je nekonzistence dat, duplikace dat, redundance dat atd.

Příklad

Předpokládejme, že bude databáze obsahovat tabulky dodavatelů, dílů a zásilek. Struktura tabulek a některé ukázkové záznamy jsou následující:

Každý řádek v tabulce Dodavatelé je identifikován jedinečným dodavatelským číslem (SNo), které jednoznačně identifikuje každý řádek v tabulce. Stejně tak má každá součást jedinečné číslo dílu (PNo).

Kromě toho v tabulce Zásilky nemůže být více než jedna zásilka pro danou kombinaci Dodavatel / Část, protože tato kombinace je primárním klíčem Zásilek, který slouží jako unijní tabulka, protože se jedná o vztah mnoho k mnoha.

Vztah mezi tabulkami dílů a zásilek je dán společným polem PNo (číslo dílu) a vztah mezi dodavateli a zásilkami vzniká společným polem SNo (číslo dodavatele).

Při analýze tabulky Zásilky lze získat jako informaci, že od dodavatelů Suneetu a Ankitu je zasláno celkem 500 ořechů, z nichž každý je 250.

Podobně bylo dodáno celkem 1 100 šroubů od tří různých dodavatelů. Od dodavatele Suneetu bylo dodáno 500 modrých šroubů. Nejsou žádné zásilky červených šroubů.

Reference

1. Wikipedia, encyklopedie zdarma (2019). Relační model. Převzato z: en.wikipedia.org.
2. Techopedia (2019). Relační model. Převzato z: stroppedia.com.
3. Dinesh Thakur (2019). Relační model. Poznámky k počítači. Převzato z: ecomputernotes.com.
4. Geeks for Geeks (2019). Relační model. Převzato z: geeksforgeeks.org.
5. Technologická univerzita v Nanyangu (2019). Stručný návod pro návrh relačních databází. Převzato z: ntu.edu.sg.
6. Adrienne Watt (2019). Kapitola 7 Relační datový model. BC Otevřené učebnice. Převzato z: opentextbc.ca.
7. Toppr (2019). Relační databáze a schémata. Převzato z: toppr.com.