Databázy a relačný model
Čo majú spoločné žiacka kniha a Access? Obe veci sú vo svojej podstate databázy. To je spôsobené ľudským jazykom. Ak my chceme pracovať s pojmom databáza, musíme si vyhradiť tento pojem...
V druhej časti sme vytvárali akúsi analýzu nášho problému z reálneho života. Tento problém teraz musíme porozdeľovať na nejakú množinu objektov vzájomne prepojených určitými vzťahmi. Takto zavedieme do chaosu poriadok a o tomto procese budeme hovoriť ako o dátovom modeli, čo je teda myšlienkový popis problému.
Reprezentácia modelu v počítači – prepísanie do reči, s ktorou vieme „komunikovať“ so strojom, potom budeme nazývať databázová schéma. Táto reč je logicky závislá na konkrétnom databázovom systéme – je to podobné, ako programátor dokáže viesť „dialóg“ s počítačom v jazyku Pascal, C a pod.
Databázové systémy sú si ale veľmi podobné. Dalo by sa povedať, že jazyk je normovaný a nie je zložité „presedlať“ na iný systém. Zatiaľ nám bude stačiť takýto pohľad, pretože hovorím o ich väčšine. Táto norma je SQL. V čom sa potom tieto programy líšia? Rýchlosťou, stabilitou a veľkosťou dát, s ktorými môžu pracovať.
Čo ale je ten databázový systém? Je to obyčajný program, ktorý dokáže efektívne ukladať a narábať s dátami. Spomínali sme nejaký v úvode dátový model. Ľudská reč je kvetnatá a dokážeme rôzne veci popísať rôznymi slovami. Matematika nie je o nič konkrétnejšia. Dátový model je v podstate postup riešenia, nie výsledok. Existuje mnoho matematických metód, techník a spôsobov, ako sa dopracovať k exaktnému záveru... Preto je aj viacero možností popisov problému zo života do databázy. Vtedy rozprávame o dátovom prístupe.
Najrozšírenejší prístup je relačný, teda popis problému pomocou množiny vzťahov. V sedemdesiatych rokoch minulého storočia dr. E. F. Codd, pracovník IBM, prišiel s úžasným nápadom. Modernému človeku a hlavne programátorovi sa táto myšlienka nebude zdať nijako geniálna, ale určite je! Aby sme nemuseli zachádzať do nejakej teórie množín, či predikčnej logiky, pod pojmom relácia si môžeme predstaviť jednoduchý vzťah medzi nejakými objektmi.
Pozn.: Chcem však podotknúť, že relačný model nie je jediný. Existuje hierarchický, hviezdicový a mnoho iných, ktoré majú svoje výhody aj nevýhody. Niektoré sú stavané na špecifické situácie, pričom iným prístupom nie je možne ich definovať. Napríklad databázový systém Caché, nie je relačnou databázou a dokáže dokonale pracovať so stromovou štruktúrou typu XML, pričom s reláciami ani neviem, či je možné takúto schému popísať.
Relácie
Tak, ako si vytvoriť dátový model v relačnom ponímaní? Každý začiatočník, určite ukladal dáta do súborov. Musel si preto vytvoriť nejakú štruktúru. Tento súbor, je naša entita a v podstate sa jedná o jednu tabuľku. Informácie tak ukladáme do tabuliek. Ak ich vhodne prepojím, získavam medzi nimi vzťah. Databázový systém má tú výhodu, že rokmi vývoja a matematickými algoritmami, dokáže veľmi rýchlo pristupovať ku dátam a preto sa nemusíme báť, že vytiahnutie informácie z viacerých tabuliek by bolo pomalé, ak by sme to analogicky „ťahali“ z jednotlivých súborov.Ale stále nevieme, aký je ten vzťah! Predstavme si, že potrebujeme viesť evidenciu o zamestnancoch. Tak chceme vedieť meno, priezvisko a miesto kde býva. Tabuľka teda vyzerá takto:
Obrázok 1 Tabuľka evidencie zamestnancov
Teraz potrebujeme evidovať napríklad aj našich zákazníkov. Analogicky vytvoríme ďalšiu tabuľku:
Obrázok 2 Tabuľka evidencie zákazníkov
Keď sa pozrieme na tieto tabuľky, nesú spoločné informácie – meno, priezvisko, ulicu, mesto, a štát. Potrebujeme tieto údaje nejako odbúrať a tak si vytvoríme novú tabuľku osoba, ktorá bude niesť práve tieto informácie a tabuľky zákazník a zamestnanec, budú odkazovať na túto tabuľku.
Ale prichádzame ku problému. Záznamy uložené v takýchto tabuľkách sú reprezentované v riadkoch. Ak teda, tabuľka zamestnanec, obsahuje informácie o Jožkovi Fľakovi a Ivanovi Kukovi, obsah v databázovom systéme si musíme predstaviť takto:
Ale prichádzame ku problému. Záznamy uložené v takýchto tabuľkách sú reprezentované v riadkoch. Ak teda, tabuľka zamestnanec, obsahuje informácie o Jožkovi Fľakovi a Ivanovi Kukovi, obsah v databázovom systéme si musíme predstaviť takto:
|
Meno |
Priezvisko |
Ulica |
Mesto |
Štát |
|
Jozef |
Fľak |
Under oak 4 |
New York |
USA |
|
Ivan |
Kuko |
Kuková 44 |
Kukolárovo |
Kukoland |
Tabuľka 1 Reprezentácie údajov v tabuľke zamestnanec
A nech dáta v tabuľke zákazník sú takéto:
|
Firma |
Meno |
Priezvisko |
Ulica |
Mesto |
Štát |
|
Microsoft |
Bill |
Fľak |
Wallstreet 3 |
New York |
USA |
|
Cisco |
Ivan |
Gates |
Kremeľ 5 |
Moskva |
Rusko |
Tabuľka 2 Reprezentácia údajov v tabuľke zákazník
Tak by nás napadlo, vytvoriť napríklad ďalší stĺpec v osobe, ktorý by niesol hodnotu, či sa jedná o zamestnanca alebo zákazníka. Napríklad číslo 1 je zamestnanec, číslo 2 je zákazník. Ani o tom nevieme, ale už sa začíname zamotávať do veľkej špiny... Tak určite nás napadne, že aj iný zamestnanec (či zákazník) môže mať rovnaké meno (teda by vznikli dva záznamy s rovnakými menami a aj popisom, či sa jedná zákazníka / zamestnanca, čím by sme nemohli jednoznačne určiť konkrétnu osobu). Tento model teda odpadáva. Taktiež v budúcnosti, by sme mali mnoho problémov, čo keby sme chceli s tabuľkou osoba, pracovať aj v iných tabuľkách? Pridávali by sme nové a nové čísla. Takto by sme si robotu neuľahčili, ale skomplikovali.
Tak aký jedinečný ukazovateľ majú tieto tabuľky? Žiaden... Obdobný problém by bol aj pri priezvisku a informácii z adries. Preto si ho vytvorme! Napríklad si očíslujme riadky... Takto budeme odkazovať len na číslo riadku. Ak sa riadok vymaže, nezaplníme ho iným riadkom alebo neposunieme bunky, proste ostane prázdny (pre uľahčenie). Takýto spôsob nazývame autoinkrementácia, pričom číslo je v podstate index, „ID“ a nazývame ho aj primárny kľúč. Teda je jedinečný pre každý riadok a nutne povinný. Každá tabuľka by mala obsahovať nejaký primárny kľúč (nikdy nevieme, kedy budeme odkazovať na ňu) a podľa neho, dokážeme tabuľky prepájať. Tak sa pozrime, čo za model sme vytvorili:
Obrázok 3 Príklad referenčného prepojenia
Šípky reprezentujú reláciu. Názov stĺpca, ktorý je pomenovaný ako tabuľka, je náš index a názov stĺpca pomenovaný ako tabuľka na ktorú odkazuje referencia nesie číslo na konkrétny riadok. Najlepšie na pochopenie je, keď si znova vypíšeme obsahy tabuliek:
|
Osoba |
Meno |
Priezvisko |
Ulica |
Mesto |
Štát |
|
1 |
Bill |
Fľak |
Wallstreet 3 |
New York |
USA |
|
2 |
Ivan |
Gates |
Kremeľ 5 |
Moskva |
Rusko |
|
3 |
Jozef |
Fľak |
Under oak 4 |
New York |
USA |
|
4 |
Ivan |
Kuko |
Kuková 44 |
Kukolárovo |
Kukoland |
Tabuľka 3 Obsah tabuľky osoba
|
Zamestnanec |
Osoba |
|
1 |
3 |
|
2 |
4 |
Tabuľka 4 Obsah tabuľky zamestnanec pomocou referenčného odkazu
|
Zákazník |
Firma |
Osoba |
|
1 |
Microsoft |
1 |
|
2 |
Cisco |
2 |
Tabuľka 5 Obsah tabuľky zákazník pomocou referenčného odkazu
Teraz si predstavme, že chceme vypísať všetkých zákazníkov, ktorí pochádzajú z Európskej Únie. Ako nato? Proste by sme si dali vypísať tabuľku zamestnanec. Podľa ID stĺpca osoba by sme ju prepojili s tabuľkou osoba a pridali ešte podmienku, že štát sa rovná Británia, Francúzsko, ... Hm, takáto „tvrdá“ podmienka zaváňa za konštantou a tie nie sú to pravé orechové. Takýto model by v prípade zmeny usporiadania únie bol k ničomu a program by nevykazoval relevantné výsledky. Na to znova dáva odpoveď správny návrh dátového modelu. Môžeme si pomôcť ďalšou tabuľkou, tzv. číselníkom, v ktorej budeme definovať štáty. Pridáme tam stĺpec EU, ktorý bude obsahovať boolovskú formu, teda áno je štátom EÚ, nie, štátom EÚ nieje.
Taktiež je vhodné vytvoriť aj číselník firiem. Veď mať napríklad tisíc zákazníkov, ktorí sú z opakujúcich sa firiem (záleží na konkrétnom probléme), nebudeme vypisovať n rovnakých reťazcov. Keď už budeme osobitne evidovať firmy, rovno si vytvorme naň kontakty. Firma taktiež má adresu a tak z tabuľky osoba extrahujeme polia adresy do novej entity, ktorá bude spoločne s tabuľkou firiem zdieľaná (analogicky, ako tabuľka osoba je spoločne zdieľaná s tabuľkami zákazník a zamestnanec).
Model preto znova upravíme a môže vyzerať, už pomerne komplikovane, hoci ako vidíme, nič strašné to nie je. Treba len tieto vzťahy „cítiť“:
Obrázok 4 Komplexnejší príklad dátového modelu
S novou štruktúrou, sa zmenili aj hodnoty v jednotlivých tabuľkách. Keď pole firma v tabuľke zákazník bola v starom príklade text, teraz je číslo, ktoré odkazuje na riadok v číselníku firiem – tabuľky firma...
Nabudúce už začneme tieto veci „programovať“ do MySQL, ktorý sme si nainštalovali v predchádzajúcej časti.
Príloha ku článku.
