RELAČNÝ DATABÁZOVÝ MODEL: PRVKY, AKO NA TO, PRÍKLAD - TECHNOLÓGIE - 2026

Relačný databázový model je spôsob štruktúrovanie dát pomocou vzťahov, pomocou mriežky podobné štruktúry, skladajúci sa zo stĺpcov a riadkov. Je to koncepčný princíp relačných databáz. Navrhol ju Edgar F. Codd v roku 1969.

Odvtedy sa stal dominantným databázovým modelom pre podnikové aplikácie v porovnaní s inými databázovými modelmi, ako sú hierarchické, sieťové a objektové.

Zdroj: pixabay.com

Codd netušil, aké mimoriadne dôležité a vplyvné bude jeho pôsobenie ako platformy pre relačné databázy. Väčšina ľudí veľmi dobre pozná fyzické vyjadrenie vzťahu v databáze: tabuľka.

Relačný model je definovaný ako databáza, ktorá umožňuje zoskupovanie jeho dátových prvkov do jednej alebo viacerých nezávislých tabuliek, ktoré môžu byť navzájom prepojené pomocou polí spoločných pre každú súvisiacu tabuľku.

Správa databázy

Databázová tabuľka je podobná tabuľky. Vzťahy, ktoré je možné vytvoriť medzi tabuľkami, však umožňujú relačnej databáze efektívne ukladať veľké množstvo údajov, ktoré je možné efektívne získať.

Účelom relačného modelu je poskytnúť deklaratívnu metódu na špecifikovanie údajov a otázok: používatelia priamo deklarujú, aké informácie databáza obsahuje a aké informácie od nej požadujú.

Na druhej strane ponechávajú na softvér systému riadenia databáz, aby opísal dátové štruktúry na ukladanie a postup získavania odpovedí na otázky.

Väčšina relačných databáz používa jazyk SQL na vyhľadávanie a definovanie údajov. V súčasnosti existuje mnoho systémov na správu relačných databáz alebo RDBMS (Relational Data Base Management System), ako napríklad Oracle, IBM DB2 a Microsoft SQL Server.

Funkcie a prvky

- Všetky údaje sú koncepčne znázornené ako usporiadané usporiadanie údajov v riadkoch a stĺpcoch, ktoré sa nazýva vzťah alebo tabuľka.

- Každá tabuľka musí mať hlavičku a telo. Hlavička je jednoducho zoznam stĺpcov. Telo je množina údajov, ktorá vypĺňa tabuľku, usporiadaná do riadkov.

- Všetky hodnoty sú skalárne. To znamená, že na ľubovoľnom danom riadku / stĺpci v tabuľke je iba jedna hodnota.

-Elements

Nasledujúci obrázok zobrazuje tabuľku s názvami jej základných prvkov, ktoré tvoria úplnú štruktúru.

Násobný

Každý riadok údajov je n-tica, známa tiež ako záznam. Každý riadok je n-n-tica, ale "n-" je všeobecne zahodené.

stĺp

Každý stĺpec v n-tici sa nazýva atribút alebo pole. Stĺpec predstavuje množinu hodnôt, ktoré môže mať konkrétny atribút.

kľúč

Každý riadok má jeden alebo viac stĺpcov nazývaných tabuľkový kľúč. Táto kombinovaná hodnota je jedinečná pre všetky riadky v tabuľke. Pomocou tohto kľúča bude každý zväzok jednoznačne identifikovaný. To znamená, že kľúč nemožno duplikovať. Nazýva sa primárny kľúč.

Na druhej strane cudzí alebo sekundárny kľúč je pole v tabuľke, ktoré odkazuje na primárny kľúč niektorej inej tabuľky. Používa sa na označenie primárnej tabuľky.

- Pravidlá integrity

Pri navrhovaní relačného modelu definujete niektoré podmienky, ktoré musia byť v databáze splnené, nazývané pravidlá integrity.

Kľúčová integrita

Primárny kľúč musí byť jedinečný pre všetky n-tice a nesmie byť null (NULL). V opačnom prípade nebudete môcť jednoznačne identifikovať riadok.

V prípade kľúča s viacerými stĺpcami nesmie žiadny z týchto stĺpcov obsahovať NULL.

Referenčná integrita

Každá hodnota cudzieho kľúča sa musí zhodovať s hodnotou primárneho kľúča referenčnej alebo primárnej tabuľky.

Riadok s cudzím kľúčom možno vložiť do sekundárnej tabuľky iba vtedy, ak táto hodnota existuje v primárnej tabuľke.

Ak sa hodnota kľúča v primárnej tabuľke zmení v dôsledku aktualizácie alebo vymazania riadku, mali by sa podľa toho aktualizovať alebo vymazať všetky riadky v sekundárnych tabuľkách s týmto cudzím kľúčom.

Ako vytvoriť relačný model?

-Zbierať dáta

Na uloženie do databázy sa musia zhromaždiť potrebné údaje. Tieto údaje sú rozdelené do rôznych tabuliek.

Pre každý stĺpec sa musí zvoliť vhodný typ údajov. Napríklad: celé čísla, čísla s pohyblivou rádovou čiarkou, text, dátum atď.

- Definujte primárne kľúče

Pre každú tabuľku musí byť ako primárny kľúč vybraný stĺpec (alebo niekoľko stĺpcov), ktorý jedinečne identifikuje každý riadok v tabuľke. Primárny kľúč sa tiež používa na označenie iných tabuliek.

- Vytvorte vzťahy medzi tabuľkami

Databáza pozostávajúca z nezávislých nepríbuzných tabuliek slúži len málo účelu.

Najdôležitejším aspektom pri navrhovaní relačnej databázy je identifikácia vzťahov medzi tabuľkami. Typy vzťahov sú:

Jeden k mnohým

V databáze „Zoznam tried“ môže učiteľ vyučovať nula alebo viac tried, zatiaľ čo triedu vyučuje jeden učiteľ. Tento typ vzťahu je známy ako „one-to-many“.

Tento vzťah nemožno reprezentovať v jednej tabuľke. V databáze «Zoznam tried» môžete mať tabuľku Učitelia, v ktorej sú uložené informácie o učiteľoch.

Ak chcete uložiť triedy, ktoré učil každý učiteľ, môžete vytvoriť ďalšie stĺpce, ale mali by ste problém: koľko stĺpcov je potrebné vytvoriť.

Na druhej strane, ak máte tabuľku s názvom Triedy, ktorá uchováva informácie o triede, môžete vytvoriť ďalšie stĺpce na ukladanie informácií o učiteľovi.

Keďže však učiteľ môže vyučovať veľa tried, jeho údaje by sa duplikovali do mnohých riadkov v tabuľke tried.

Navrhnite dve tabuľky

Preto musíte navrhnúť dve tabuľky: tabuľku Triedy na ukladanie informácií o triedach, s Class_Id ako primárnym kľúčom, a tabuľku Učitelia na ukladanie informácií o učiteľoch, s Teacher_Id ako primárnym kľúčom.

Vzťah jedna k viacerým sa potom môže vytvoriť uložením primárneho kľúča z hlavnej tabuľky (Master_Id) do tabuľky tried, ako je to znázornené nižšie.

Stĺpec Master_Id v tabuľke Classes je známy ako cudzí kľúč alebo sekundárny kľúč.

Pre každú hodnotu Master_Id v hlavnej tabuľke môže byť v tabuľke Trieda nula alebo viac riadkov. Pre každú hodnotu Class_Id v tabuľke Classes je v tabuľke Teachers iba jeden riadok.

Veľa až veľa

V databáze „Predaj produktov“ môže zákazka odberateľa obsahovať viac produktov a produkt sa môže zobraziť vo viacerých objednávkach. Tento typ vzťahu je známy ako mnoho k mnohým.

Databázu „Predaj produktov“ môžete spustiť pomocou dvoch tabuliek: Produkty a Objednávky. Tabuľka Výrobky obsahuje informácie o produktoch s primárnym kľúčom productID.

Na druhej strane tabuľka Objednávky obsahuje objednávky zákazníka s primárnym kľúčom orderID.

Objednané produkty nemôžete uložiť v tabuľke Objednávky, pretože neviete, koľko stĺpcov je potrebné rezervovať pre produkty. Z toho istého dôvodu nie je možné ukladať objednávky v tabuľke Výrobky.

Na podporu vzťahu medzi mnohými je potrebné vytvoriť tretiu tabuľku známu ako tabuľka spojenia (OrderDetails), kde každý riadok predstavuje položku v konkrétnom poradí.

V tabuľke OrderDetails sa primárny kľúč skladá z dvoch stĺpcov: orderID a productID, ktoré jednoznačne identifikujú každý riadok.

Stĺpce orderID a productID v tabuľke OrderDetails sa používajú na odkazy na tabuľky Order and Products. Preto sú tiež cudzími kľúčmi v tabuľke OrderDetails.

Jeden za druhým

V databáze „Predaj výrobkov“ môže mať produkt voliteľné informácie, ako napríklad ďalší popis a jeho obrázok. Ak ju ponecháte vo vnútri tabuľky Produkty, vytvorí sa veľa prázdnych miest.

Preto je možné vytvoriť ďalšiu tabuľku (ProductExtras) na ukladanie voliteľných údajov. Pre produkty s voliteľnými údajmi sa vytvorí iba jeden záznam.

Tieto dve tabuľky, Products a ProductExtras, majú vzájomný vzťah. Pre každý riadok v tabuľke Výrobky je v tabuľke ProductExtras najviac jeden riadok. Rovnaký identifikátor produktu sa musí použiť ako primárny kľúč pre obe tabuľky.

výhoda

Štrukturálna nezávislosť

V modeli relačnej databázy nemajú zmeny v štruktúre databázy vplyv na prístup k údajom.

Ak je možné vykonať zmeny v štruktúre databázy bez toho, aby to ovplyvnilo schopnosť DBMS získať prístup k údajom, možno povedať, že sa dosiahla štrukturálna nezávislosť.

Koncepčná jednoduchosť

Relačný databázový model je ešte koncepčne jednoduchší ako hierarchický alebo sieťový databázový model.

Pretože model relačnej databázy uľahčuje návrhárovi podrobnosti fyzického ukladania údajov, môžu sa dizajnéri zamerať na logické zobrazenie databázy.

Jednoduchá konštrukcia, implementácia, údržba a používanie

Relačný databázový model dosahuje nezávislosť údajov aj nezávislosť štruktúry, čo značne uľahčuje navrhovanie, údržbu, správu a používanie databázy ako ostatné modely.

Kapacita dopytov ad-hoc

Prítomnosť veľmi výkonnej, flexibilnej a ľahko použiteľnej schopnosti dotazovania je jedným z hlavných dôvodov obrovskej popularity modelu relačnej databázy.

Jazyk dotazu modelu relačnej databázy nazývaný štruktúrovaný dopytovací jazyk alebo SQL robí ad-hoc dotazy realitou. SQL je jazyk štvrtej generácie (4GL).

4GL umožňuje užívateľovi určiť, čo by sa malo urobiť, bez toho, aby špecifikoval, ako by sa to malo urobiť. S SQL teda môžu užívatelia špecifikovať, aké informácie chcú, a podrobnosti o tom, ako získať informácie, môžu nechať v databáze.

nevýhody

Výdavky na hardvér

Model relačnej databázy skrýva zložitosti jeho implementácie a podrobnosti fyzického ukladania užívateľských údajov.

Na tento účel potrebujú systémy relačných databáz počítače s výkonnejším hardvérom a zariadeniami na ukladanie údajov.

Preto RDBMS potrebuje výkonné stroje na plynulý chod. Keďže však výkonnosť moderných počítačov exponenciálne rastie, potreba väčšieho množstva výpočtového výkonu v dnešnom scenári už nie je veľmi veľkým problémom.

Jednoduchá konštrukcia môže viesť k zlej konštrukcii

Relačnú databázu je možné ľahko navrhnúť a používať. Používatelia nemusia poznať zložité podrobnosti fyzického ukladania údajov. Na prístup k údajom nepotrebujú vedieť, ako sa údaje skutočne ukladajú.

Toto ľahké navrhovanie a používanie môže viesť k vývoju a implementácii zle navrhnutých systémov správy databáz. Pretože databáza je efektívna, tieto nedostatky návrhu sa neobjavia, keď je databáza navrhnutá a keď existuje iba malé množstvo údajov.

Ako sa databáza rozširuje, zle navrhnuté databázy spomalia systém a povedú k zhoršeniu výkonu a poškodeniu údajov.

Fenomén «informačných ostrovov»

Ako už bolo uvedené, systémy relačných databáz sa ľahko implementujú a používajú. Tým sa vytvorí situácia, keď si príliš veľa ľudí alebo oddelení vytvorí svoje vlastné databázy a aplikácie.

Tieto informačné ostrovy zabránia integrácii informácií, ktorá je nevyhnutná pre hladké a efektívne fungovanie organizácie.

Tieto jednotlivé databázy tiež spôsobia problémy, ako sú nekonzistencia údajov, duplikácia údajov, redundancia údajov atď.

príklad

Predpokladajme databázu skladajúcu sa z tabuliek dodávateľov, dielov a zásielok. Štruktúra tabuliek a niektoré vzorové záznamy sú nasledujúce:

Každý riadok v tabuľke Dodávatelia je identifikovaný jedinečným číslom dodávateľa (SNo), ktoré jednoznačne identifikuje každý riadok v tabuľke. Podobne má každá časť jedinečné číslo dielu (PNo).

Ďalej v tabuľke Zásielky nemôže byť viac ako jedna zásielka pre danú kombináciu Dodávateľ / Časť, pretože táto kombinácia je primárnym kľúčom Zásielok, ktorý slúži ako zjednocujúca tabuľka, pretože ide o vzťah medzi mnohými.

Vzťah medzi tabuľkami častí a zásielok je daný spoločným poľom PNo (číslo časti) a vzťah medzi dodávateľmi a zásielkami vzniká spoločným poľom SNo (číslo dodávateľa).

Na základe analýzy tabuľky Zásielky je možné získať ako informáciu, že od dodávateľov Suneetu a Ankitu je zaslaných celkom 500 orechov, z ktorých každý je 250.

Podobne bolo od troch rôznych dodávateľov dodaných 1100 skrutiek. Od dodávateľa Suneetu bolo dodaných 500 modrých skrutiek. Neexistujú žiadne zásielky červených skrutiek.

Referencie

1. Wikipedia, bezplatná encyklopédia (2019). Relačný model. Prevzaté z: en.wikipedia.org.
2. Techopedia (2019). Relačný model. Prevzaté z: stroppedia.com.
3. Dinesh Thakur (2019). Relačný model. Poznámky k počítaču. Prevzaté z: ecomputernotes.com.
4. Geeks for Geeks (2019). Relačný model. Prevzaté z: geeksforgeeks.org.
5. Technologická univerzita mesta Nanyang (2019). Stručný návod na navrhovanie relačných databáz. Prevzaté z: ntu.edu.sg.
6. Adrienne Watt (2019). Kapitola 7 Relačný dátový model. BC Otvoriť učebnice. Prevzaté z: opentextbc.ca.
7. Toppr (2019). Relačné databázy a schémy. Prevzaté z: toppr.com.