3 Návrh

Je realizovaný rôznymi modelmi systému na základe skôr definovaných požiadaviek. Počas návrhu sú vytvárané modely nielen na konceptuálnej a logickej úrovni, ale aj fyzický návrh ako príprava na implementáciu.

Cieľom kvalitného návrhu je, že databáza musí uchovávať údaje potrebné na plnenie informačných požiadaviek známych v čase návrhu databázy, ale aj budúcich požiadaviek. Údaje musia poskytovať platné a presné informácie, ktoré majú význam pre účel vyhotovenia. Takisto nemôžeme zabúdať, že databáza musí byť v budúcnosti do určitej miery rozšíriteľná [1].

Samotný návrh uskutočňujeme vtedy, keď sú nám známe finálne požiadavky, identifikované v predchádzajúcej fáze. Tie budú použité ako základ vývoja nového systému. Všeobecne nastáva prevod rámcového (všeobecného sémantického) porozumenia údajových štruktúr na ich technickú reprezentáciu (podľa ich technického chápania) [1].

Otázky typu: Aký/aká/aké? nahradíme otázkami typu: Ako? 
Aké údaje sú požadované? → Ako budú údaje organizované? 
Aké problémy sa budú riešiť? → Ako bude zaistený prístup k údajom? [1]

Táto fáza zahŕňa údajovú a funkčnú analýzu, keď sa v údajovej analýze vytvárajú modely na troch úrovniach štruktúry údajov a teda na troch úrovniach návrhu modelu DBS. Tým myslíme konceptuálnu, technologickú a implementačnú úroveň. Vytvorí sa konceptuálny model (napríklad E‑R diagram), potom sa tento model prevedie na technologický model (napríklad relačná schéma) a v konečnej fázy sa zvolí SRBD v závislosti od požiadaviek a komplexnosti štruktúry údajov [1].

3.1 Entitno­‑relačný diagram (E‑R diagram)

Entitno­‑relačný diagram (E‑R diagram) je grafický nástroj, ktorý sa používa pri návrhu databázových systémov na vyjadrenie modelu údajov, pričom charakterizuje pohľad na statickú časť systému. V rámci E‑R diagramu sú definované jednotlivé údajové objekty sveta (entity) a vzájomné vzťahy medzi nimi (relácie). E‑R diagramy pozostávajú z nasledujúcich prvkov:

Postup pri tvorbe E‑R diagramu

  1. Definícia entít.
  2. Pridelenie atribútov jednotlivým entitám.
  3. Definícia relácií (vzťahov) medzi entitami.
  4. Definícia kardinality relácií.
  5. Reprezentácia navrhnutej údajovej štruktúry s pomocou grafických notácií [8].

Po konceptuálnom návrhu databázy (vytvorenie E‑R modelu) nasleduje logický návrh databázy.

3.2 Údajový model databázy

Po tom ako sme vytvorili E‑R diagram, je potrebné určiť spôsob reprezentácie tohto diagramu v báze údajov. Organizáciu údajov navrhujeme s pomocou údajového modelu.

Údajový model:

Typy údajových modelov

Poznáme tri základné údajové modely založené na záznamoch: hierarchický údajový model, sieťový údajový model a relačný údajový model.

3.2.1 Hierarchický údajový model

Je špeciálnym prípadom sieťového modelu, na ktorom boli postavené prvé databázové systémy. Tento model je založený na hierarchickej (stromovej) štruktúre údajov vychádzajúcej z koreňa, pri ktorej sa využíva vzťah nadradenosti a podradenosti (rodič a potomok) na opis vzájomných vzťahov. Údajovým štruktúram na jednotlivých úrovniach sa hovorí uzly. Keď z uzla nevychádza ďalšia vetva, nazývame ho list. Aj keď tento model často vhodne vystihuje hierarchiu vzťahov v realite (napríklad štát → kraj → okres → obec) a v minulosti si našiel v praxi široké uplatnenie, v súčasnosti sa v databázových systémoch využíva len zriedkavo.

Hierarchický model sa priamo neopiera o matematickú teóriu, avšak čiastočne používa terminológiu teórie grafov (graf, uzol, hrana). Napríklad záznam zodpovedá uzlu v grafe [14].

Pre hierarchickú štruktúru platí, že:

Hierarchické modelovanie zodpovedá vzťahom typu 1 : N a 1 : 1. Základnou výhodou hierarchického systému je rýchle vyhľadávanie entít, ktoré sú podriadené určitej entite. Naopak vyhľadávanie entity, ktorá je nadriadená znamená sekvenčné prehľadávanie celého stromu (v súčasnosti neefektívne). Pri vyhľadávaní údajov sa postupuje vždy od koreňového uzla (záznamu) cez stromovú štruktúru k požadovanému uzlu, pričom ku každému záznamu existuje len jediná cesta [8].

Nevýhody hierarchického modelu:

obrázok

Obrázok 3. Hierarchický údajový model [8].

3.2.2 Sieťový údajový model

Sieťový model vznikol približne v rovnakom časovom období ako hierarchický model. Využíva sieťovú štruktúru údajov, v ktorej (na rozdiel od hierarchického modelu) môže byť každý prvok v sieti zviazaný s ktorýmkoľvek iným prvkom (každý prvok môže mať aj viac rodičov) [12].

Tvoríme ho s pomocou orientovaného grafu, v ktorom sú entity zobrazené s pomocou uzlov a vzťahy s pomocou odkazov (prepojovacích čiar). Tento model teda údaje predstavuje ako množinu záznamov (entít) a párových vzťahov medzi nimi, ktoré môžu mať vzťahy typu 1 : 1, 1 : N alebo M : N [15].

Tým rozširuje možnosti hierarchického modelu a umožňuje vernejšiu reprezentáciu vzťahov, avšak na úkor jednoduchosti modelu.

Atribúty záznamov v sieťových modeloch môžu byť jednoduché, opakujúce sa, zložené alebo zložené opakujúce sa. Na rozdiel od predchádzajúceho hierarchického údajového modelu, sieťový model môže obsahovať aj cykly a slučky [15].

Sieťový graf má odstrániť hlavné nevýhody hierarchického modelu. Model zaručuje minimálnu redundanciu (výskyt rovnakých údajov), pretože každá entita sa nachádza v báze údajov iba raz. Keď sa nachádza táto entita vo viacerých vzťahoch, vedie k nej viac odkazov v rôznych vzťahových súboroch. Z toho vyplýva aj základná nevýhoda sieťových modelov, ktorou je veľmi náročná modifikovateľnosť. Napríklad so zmenou počtu entít (najmä pri odstraňovaní entít) je potrebné prechádzať všetky vzťahové súbory a opravovať (rušiť) odkazy. Sieťový model bol z dôvodu svojej implementačnej náročnosti a zložitosti používaný pomerne málo [13].

obrázok

Obrázok 4. Sieťový údajový model.

3.2.3 Relačný údajový model (RDM)

Relačný údajový model vychádza z teórie množín. Vznikol v roku 1970, kedy ho prvý raz publikoval Dr. E. F. Codd. Väčšina dnešných databázových systémov je založená práve na relačnom údajovom modeli. Ide o logické vyjadrenie väzieb medzi jednotlivými údajmi. Manipulácia s údajmi je založená na operáciách relačnej algebry. Tieto operácie zahŕňajú množinové operácie ako zjednotenie, prienik, rozdielkarteziánsky súčin. Medzi špeciálne relačné operácie patria selekcia, spojenie, delenieprojekcia [10].

Medzi základné pojmy relačného údajového modelu patrí:

Tabuľka 1. Analógia pojmov: relačný údajový model – systémy súborov [10].

Relačný pojem Reprezentácia Súborová analógia
Relácia Tabuľka Súbor
N­‑tica Riadok Záznam
Atribút Stĺpec Položka
Hodnota atribútu Hodnota bunky Hodnota položky

Základné vlastnosti každej relácie (tabuľky):

obrázok

Obrázok 5. Príklad relácie (tabuľky s M riadkami a N stĺpcami) [8].

Relačný údajový model podľa pôvodnej definície vychádzal z nasledujúcich požiadaviek:

obrázok

Obrázok 6. Relačný údajový model [8].

Relačný údajový model je najčastejšie používaný model v dnešných databázových systémoch. Tento model však obmedzuje štruktúru a vzťahy uchovávaných údajov na množinu tabuliek nad preddefinovanou množinou základných údajových typov. Významnou výhodou tohto modelu je jednoduchosť a v dôsledku toho aj jednoduchá štandardizácia a prenositeľnosť. Nevýhodou však je rozdielnosť reálnych údajov od vnútorného tabuľkového modelu databázy. Vzťahy medzi údajmi je možné reprezentovať iba tabuľkami, čo v aplikáciách s komplikovanejším údajovým modelom vedie k množstvu tabuliek vzájomne previazaných s pomocou kľúčov [22].

Dochádza tým k strate prehľadnosti, databáza sa stáva horšie spravovateľnou a budúce zmeny v údajovom modeli aplikácie nútia programátorov k citeľným zásahom do jeho tabuľkovej reprezentácie. Rad aplikácií, napríklad z oblasti dizajnu, multimédií, geografických systémov a podobne, však potrebuje taký údajový model, ktorý umožní lepšiu korešpondenciu medzi zložitými reálnymi údajmi a ich reprezentáciou v databázovom systéme. Týmto modelom je objektový údajový model [22].

Okrem vyššie uvedených údajových modelov, s ktorými sa môžeme stretnúť v súvislosti s DBS v súčasnosti poznáme aj: objektovo orientovaný modelobjektovo­‑relačný model.

3.2.4 Objektový údajový model

Objektový údajový model v DBS vychádza zo známych princípov objektovo orientovaného modelovania a programovania. Je však ďalej obohatený o techniky reprezentácie vzťahov, dopytovania, transakčného prístupu a podobne [22].

3.2.4.1 Dôvody použitia objektových údajových modelov

Pri nových databázových aplikáciách dáva väčšina vývojárov prednosť objektovej technológii, pretože vývoj zložitých aplikácií je omnoho rýchlejší a neskoršie úpravy sú jednoduchšie. Objektová technológia poskytuje niekoľko výhod, akými sú napríklad:

3.2.4.2 Objektovo orientované systémy (object database management system – ODBMS)

ODBMS priniesli oproti relačným databázam kvalitnejšie údajové a procedurálne modelovanie. Prejavuje sa predovšetkým nasledujúcimi charakteristikami:

  1. Spájanie príbuzných údajov – ODBMS umožňujú prirodzenejšiu reprezentáciu zložitejších údajových štruktúr. Údaje, ktoré navzájom súvisia v realite sa spolu uchovávajú aj v externých pamätiach.
  2. Spájanie údajov s funkciami – ODBMS poskytujú tradičné objektovo orientované črty ako: spájanie údajov s funkciami, ukrývanie údajov, používateľsky definovateľné typy, typové dedenie, polymorfizmus a podobne.
  3. Spájanie databázového a programovacieho jazyka – ODBMS, na rozdiel od SQL relačných DBMS, ponúkajú výpočtovo úplný jazyk. Snažia sa tiež integrovať databázové prostredie s programovacím prostredím [17].

Základné pojmy objektovo orientovaného modelu:

Údajový model ODBMS:

V porovnaní s relačnými systémami sa však znížila jednoduchosť a matematická precíznosť.

3.2.4.3 Objektovo­‑relačné systémy (ORSRBD)

ORSRBD sa snažia využiť dobré vlastnosti z relačných aj z objektových systémov. Je tu zachovaná jednoduchosť z relačného modelu a navyše získavajú výhody z objektového modelu.

Údajový model ORSRBD:

3.2.5 Porovnanie relačných DBS, ODBMSORSRBD

Ako sme už spomínali, v súčasnosti sa najviac využívajú práve tieto tri typy DBS. Keď si vývojár vyberá, aký typ DBS použije, mal by podrobne poznať všetky výhody a nevýhody týchto troch modelov. Medzi najhlavnejšie patria:

Pri návrhu databázy nemôžeme zabudnúť na normalizáciu údajov, čo je požadovaný krok k správnemu návrhu databázy. Tento proces pomáha zabrániť nadbytočnosti údajov a zlepšuje ich integritu.

3.3 Normalizácia

Normalizácia relačnej databázovej schémy je postupný proces, v rámci ktorého sa pôvodné relácie nahrádzajú novými s jednoduchšou štruktúrou. Normalizácia databázovej schémy predstavuje úpravu vzájomných vzťahov v databáze. Na začiatku návrhu je štruktúra relácií nenormalizovaná, to znamená taká, ako si ju predstavuje používateľ. Externé predstavy používateľa o obsahu databázy je nevyhnutné upraviť do stavu použiteľného v relačnom systéme, čo je práve súčasť normalizácie. Proces normalizácie znamená postupné rozloženie pôvodných „nenormalizovaných“ tabuliek do sústavy viacerých menších tabuliek tak, aby sa údaje obsiahnuté v pôvodných tabuľkách nestratili [17].

Výsledkom normalizácie je rozumné rozloženie atribútov do tabuliek. Žiadanou vlastnosťou databázy, ktorú možno dostať s pomocou normalizácie je, že všetky atribúty medzi ktorými je funkčná závislosť, sú v jednej relačnej tabuľke. Normalizáciu možno charakterizovať ako proces, ktorý je možné použiť v ľubovoľnom okamihu pri navrhovaní databázy. Výhodou databázy ktorá obsahuje normalizované relačné tabuľky, sú hlavne jednoduchší prístup používateľov k údajom v databáze, lepšie udržiavanie údajov a nižšie pamäťové nároky [15].

Príklad nežiadanej duplicity údajov:

Predstavme si tabuľku „Spoločnosť“ s atribútmi: názov spoločnosti, adresa spoločnosti, kontakt, výrobok. Táto spoločnosť by dodávala tisíc rôznych výrobkov. Z toho vyplýva, že tabuľka by obsahovala tisíckrát (tisíc inštancií) rovnaký údaj o názve spoločnosti, rovnakú adresu, rovnaký kontakt na spoločnosť, ale každá z týchto tisícich inštancií (každý riadok tabuľky) by obsahovala inú hodnotu v atribúte „Výrobok.“ Toto, samozrejme, nechceme. Okrem zvýšenej náročnosti na úložisko pamäte databázy, nám vznikajú takisto aj problémy s anomáliami.

Úprava databázy do príslušnej normálnej formy umožňuje eliminovať jej anomálie. Odstránenie anomálií v databáze zabezpečí jej konzistentnosť, efektívnosť vyhľadávania, a tiež minimalizáciu redundancie údajov [17].

Medzi základné anomálie databázy patria:

Uvažujeme o situácii, keby v školskom systéme neexistovala entita „Predmet,“ v ktorej uchovávame informácie o všetkých predmetoch. Jednotlivé predmety by sme vkladali do tabuľky „Študent,“ kde by sme vytvorili atribúty: Predmet 1, Predmet 2 … Predmet N.

Teraz si predstavme situáciu, keby sme chceli aktualizovať názov predmetu „databázové systémy 1“ napríklad na názov: „tvorba databázových systémov.“ V tomto príklade by sme museli každému študentovi v systéme prepísať tento nový názov predmetu, čo je samozrejme veľmi nepraktické, zdĺhavé a najmä vedúce k vzniku chybných údajov.

V situácii keď máme vytvorené entity „Študent“ aj „Predmet,“ tento nový názov predmetu aktualizujeme iba v entite (tabuľke) „Predmet,“ v ktorej sa informácie o predmete „databázové systémy 1“ nachádzajú iba raz. Tento spôsob nám uľahčí prácu a nevedie k tvorbe chybných údajov v databáze.

Uvažujeme o príklade keď máme tabuľku „Dodávateľ,“ ktorá má atribúty: ID dodávateľa, Názov dodávateľa, Adresa dodávateľa, Kontakt dodávateľa, Výrobok. V databáze by sa nachádzal konkrétny dodávateľ, ktorý by do našej spoločnosti dodával nejaké výrobky. Naša spoločnosť by sa rozhodla, že výrobky od tohto dodávateľa ďalej nebude potrebovať. Preto by sme z databázy vymazali všetky výrobky, ktoré nám tento dodávateľ dodáva. S týmito výrobkami by sme ale vymazali aj údaje o: názve tohto dodávateľa, adresu a kontakt na tohto dodávateľa. V našej databáze by sa teda viacej tento dodávateľ nenachádzal. Predstavme si situáciu, že by sme sa po nejakom čase rozhodli znova osloviť tohto dodávateľa so žiadosťou o spoluprácu. V databáze už ale nemáme žiadny údaj o tejto spoločnosti, pretože o tieto údaje sme prišli pri mazaní výrobkov, ktoré tento dodávateľ dodával.

Riešením je dekompozícia tejto tabuľky do dvoch tabuliek:

Existuje niekoľko spôsobov, ktoré vedú k lepšiemu návrhu:

  1. Nepotrebné údaje by mali byť v oddelených tabuľkách.
  2. Údaje, ktoré je možné vypočítať, nie je nevyhnutné ukladať (napríklad máme čísla A a B, ktoré sú uložené a zaujíma nás ich súčin A × B, potom tento súčin nie je potrebné ukladať).
  3. Návrh musí odpovedať všetkým podmienkam, ktoré boli definované pri analýze. Je jednoduché pri návrhu si nevšimnúť nejakú podmienku. Používateľ ľahko objaví pri konzultácii v E‑R diagrame chybnú podmienku, ale nie vždy objaví nejakú chýbajúcu.
  4. Pri voľbe atribútov je dôležité dbať na ich jasné názvy. Je vhodné sa vyhýbať aj rovnakým názvom pre odlišné pole, napríklad pole primárneho kľúča nazvané ID je vhodné doplniť o konkrétny predmet tabuľky (ID zamestnanca, ID zákazníka…).
  5. Nie je vhodné vytvárať príliš veľa vzťahov – napríklad študent patrí do nejakej študijnej skupiny, tá patrí k nejakej katedre a tá je priradená na určitú fakultu. Naopak je potrebné pokryť vzťahy tak, aby bolo možné dohľadať všetky spojitosti.
  6. Je nevyhnutné rozdeliť vzťahy kardinality M : N na dva vzťahy 1 : N a N : 1 s pomocou fiktívnej novovytvorenej tabuľky práve k tomuto vzťahu.
  7. Je vhodné zamyslieť sa nad obmedzením a teda nad tvorbou limitov, ktoré vyplývajú z použitia aplikácie, napríklad keď vek študenta na strednej škole nemôže presiahnuť 25 rokov, že pohlavie je len mužské alebo ženské alebo, že e‑mailová adresa musí obsahovať zavináč. Zabránime tým neskorším problémom pri implementácii.
  8. Nie je vhodné ukladať príliš veľa údajov, ktoré nesúvisia s cieľom a účelom aplikácie, pretože to môže v konečnom dôsledku viesť k obťažovaniu používateľa aj osoby, ktorá údaje poskytuje. Napríklad zhromažďovaním informácií o osobách s cieľom registrácie na odber elektronických správ, potom nie je dôležité poznať a ukladať farbu očí alebo obľúbené jedlo (ak nejde o informačný portál určený na varenie). Je vhodné zvážiť aj náročnosť a čas potrebný na spracovanie všetkých takých údajov a to aj v závislosti od následnej rýchlosti databázy.
  9. Je potrebné dodržať prvé tri normálové formy tak, že v každom poli (atribútu) sú uložené iba atomické hodnoty, z ktorých tie nekľúčové budú vždy úplne závislé od celého primárneho kľúča a v najlepšom prípade nebudú vznikať tranzitívne závislosti.
  10. Na tvorbu primárneho kľúča je vhodné vytvoriť nové pole, ako ho vytvárať z kombinácie existujúcich polí. Nie vždy bude platiť, že táto kombinácia musí byť jedinečná počas celého obdobia životnosti databázy.
  11. Pri zaisťovaní referenčnej integrity je potrebné dbať na to, aby cudzí kľúč nemal vzťah k primárnemu kľúču z inej tabuľky, ktorá už neexistuje.
  12. Je vhodné mať na pamäti dostatočné zabezpečenie databázy a obmedzenie prístupových práv pre jednotlivých používateľov. Nie je možné sprístupniť prehliadanie údajov nepovolaným používateľom aj v prípadoch, keď ich nemôžu zmeniť [1].

obrázok

Obrázok 7. Postup normalizácie [16].

obrázok

Obrázok 8. Návrh databázového systému.

Zhrnutie 3. kapitoly

Cieľom kvalitného návrhu je, že databáza musí uchovávať údaje potrebné na plnenie informačných požiadaviek známych v čase návrhu databázy, ale aj budúcich požiadaviek.

E‑R diagram – je grafický nástroj, ktorý sa používa pri návrhu databázových systémov na vyjadrenie modelu údajov. V rámci neho sú definované jednotlivé údajové objekty sveta (entity) a vzájomné vzťahy medzi nimi.

Entita – je údajový objekt, o ktorom chceme uchovávať údaje.

Atribúty entity – vyjadrujú jej bližšiu charakteristiku/vlastnosti.

Doména atribútu – je obor hodnôt, ktorý môže atribút nadobúdať.

Relácia – definuje vzťah, spojenie medzi jednotlivými entitami.

Primárny kľúč – jednoznačne identifikuje každú inštanciu (každý záznam) v entite.

Údajový model – je množina pravidiel, podľa ktorých sú organizované logické vzťahy medzi údajmi v databáze.

Typy údajových modelov:

Definícia relácie v relačnom údajovom modeli:

Objektový údajový modelDBS vychádza zo známych princípov objektovo orientovaného modelovania a programovania. Je však ďalej obohatený o techniky reprezentácie vzťahov, dopytovania, transakčného prístupu a podobne.

ODBMS priniesli oproti relačným databázam kvalitnejšie údajové a procedurálne modelovanie. Prejavuje sa predovšetkým nasledujúcimi charakteristikami:

  1. Spájanie príbuzných údajov.
  2. Spájanie údajov s funkciami.
  3. Spájanie databázového a programovacieho jazyka [17].

ORSRBD sa snažia využiť prednosti z relačných aj z objektových systémov. Je tu zachovaná jednoduchosť z relačného modelu a navyše získavajú výhody z objektového modelu.

Normalizácia je proces, pomocou ktorého rozkladáme relácie s cieľom jednoduchšej manipulácie s údajmi, zabránenia redundancie údajov a lepšej konzistencie. Celý proces prebieha aplikovaním jednotlivých pravidiel, ktoré nazývame normálové formy.

Úprava DB do prislúchajúcej normálnej formy umožňuje eliminovať jej anomálie. Odstránenie anomálií v databáze zabezpečí jej konzistentnosť, efektívnosť vyhľadávania, a tiež minimalizáciu redundancie údajov. Medzi základné anomálie databázy patria:

Otázky na zopakovanie

  1. Čo je E‑R diagram a z akých prvkov sa skladá?
  2. Z akých prvkov sa skladá entitno­‑relačný diagram?
  3. Charakterizujte údajový model.
  4. Aké typy údajových modelov poznáme?
  5. Opíšte jednotlivé údajové modely.
  6. Vymenujte a opíšte základné zložky relačného údajového modelu.
  7. Vymenujte hlavné dôvody na použitie objektových údajových modelov.
  8. Opíšte OO databázové systémy.
  9. Vymenujte a opíšte základné pojmy objektovo orientovaného modelu.
  10. Vysvetlite pojem objektovo­‑relačné systémy.
  11. Vysvetlite, čo je úlohou normalizácie?
  12. Aké anomálie dokážeme správnou normalizáciou odstrániť? Uveďte príklady.

Doplňujúce materiály ku štúdiu

Normalizácia databáz: