Modely databázových systémov

Najrozšírenejšie modely databáz

Každý databázový systém vychádza z určitej teórie, z tzv. dátového modelu . Dátový (resp. databázový) model je v podstate architektúra, podľa ktorej databázový systém ukladá objekty do databázy a podľa ktorej ich vzájomne prepája . V nasledujúcej časti textu sa pozrieme na najrozšírenejšie modely databáz, a to v poradí podľa ich časového vývoja.

Otvorené súbory

Otvorené súbory sú „obyčajné“ súbory operačného systému. To znamená, že záznamy v nich obsiahnuté so sebou nenesú žiadne informácie, ktoré by do cieľovej aplikácie vnášali štruktúru súboru, alebo akékoľvek vzťahy medzi záznamami v nich uložených. Všetky informácie o štruktúre dát, ich význame a vzájomných vzťahoch musíme začleniť do príslušnej aplikácie, ktorá so súborom pracuje, alebo ich musí poznať človek, ako cieľový užívateľ dát.

Otvorené súbory v podstate nie sú databázami , ako takými, pretože nezodpovedajú žiadnym databázovým kritériám. Pri otvorených súboroch sú všetky údaje ukladané na disk sekvenčne do jedného veľkého súboru. Usporiadanie je možné znovuprepísaním súboru alebo použitím indexového súboru (podmnožina údajového súboru obsahujúca jednu alebo viac položiek). Napriek uvedenému je dôležité si o nich niečo povedať a to hneď z dvoch dôvodov:

(1) Do otvorených súborov sa často ukladajú i informácie z databáz. V takomto prípade operačný systém opäť nepozná obsah týchto súborov, ani ich štruktúru, ale databázový systém má metadáta o dátach , podľa ktorých môže realizovať prevody medzi otvorenými súbormi vo fyzickej vrstve, respektíve medzi databázovými štruktúrami v logickej vrstve. Pojem metadáta, doslova „dáta o dátach“, tu označuje informácie, ktoré sú v rámci databázy zapísané do katalógu a ktoré popisujú, aké dáta sú v databáze uložené a aké sú medzi nimi vzťahy . Súčasťou metadát zákazníka môže byť napríklad zoznam všetkých dátových položiek, ktoré v systéme o zákazníkovi zhromažďujeme, vrátane dĺžky, minimálnej a maximálnej dátovej hodnoty a stručného popisu každej z položiek.

(2) Otvorené súbory existovali dávno pred vznikom databáz a prvé databázové systémy sa vyvinuli práve z nich.

Príklad systému s otvorenými súbormi, v tomto prípade s podmnožinou dát z ukážkovej databázy vidíme na nasledujúcom obrázku. Nezabudnite, že nadpisy stĺpcov (Kód zákazníka, Firma, atď.) sú tu uvedené len z ilustračných dôvodov – v dátových súboroch budú uložené iba samotné vlastné dátové záznamy. Dáta o zákazníkoch budú uložené v súbore Zákazníci, v ktorom každého zákazníka reprezentuje jeden určitý záznam. Podobne každý zamestnanec firmy má záznam v súbore Zamestnanci a každý predávaný výrobok má záznam v súbore Výrobok. Do ďalších otvorených súborov sa ukladajú dáta s objednávkami zákazníkov: súbor Objednávky obsahuje záznam ku každej objednávke zákazníka a v ňom údaje o objednávke ako takej, napríklad identifikátor zákazníka, ktorý objednávku podal a meno zamestnanca, ktorý ju prijal. Súbor s riadkami objednávok, Rozpis objednávok, potom obsahuje rozpísané záznamy jednotlivých položiek z tabuľky Objednávky – k jednej objednávke môže byť takýchto detailných riadkov niekoľko a každý popisuje jeden objednaný výrobok, teda najmä jeho jednotkovú cenu a množstvo.

Obrázok 1.2 Systém objednávok s otvorenými súbormi

Aplikačný program je ucelená jednotka programovej logiky, ktorá na počítači v operačnom systéme vykonáva určitú funkciu. Jeden takýto aplikačný program napríklad vytlačí výpis všetkých objednávok. Táto aplikácia musí prečítať objednávku a zjednotiť dáta z uvedených 5-tich súborov:

1. Podľa ID zákazníka nájde v súbore Zákazníci meno zákazníka
2. Podľa ID zamestnanca nájde v súbore Zamestnanci aj meno zamestnanca
3. Podľa ID objednávky nájde zodpovedajúce riadky (rozpis) objednávky v súbore Rozpis objednávok
4. V každom riadku rozpísanej objednávky vyhľadá podľa ID výrobku v súbore Výrobky jeho názov

Tento postup je dosť komplikovaný, i napriek tomu, že sa pokúšame vypísať len zoznam všetkých objednávok. V systéme s otvorenými súbormi je to napriek tomu najlepší možný spôsob usporiadania dát .

Inou možnosťou návrhu dátovej štruktúry by bolo zlúčiť všetky informácie do jednotného dátového súboru. Tím by sa síce výrazne zjednodušilo načítanie dát, súčasne by sme ale museli všetky dáta o zákazníkovi na každom riadku z jeho objednávky opakovať, čo by malo pre činnosť aplikácie výrazne nepríjemné dôsledky. Do takejto databázy by sme napríklad nemohli zapísať nového zákazníka, pokiaľ by nepodal nejakú objednávku. Na viac, ako náhle niekto odstráni poslednú objednávku určitého zákazníka, stratíme o ňom všetky informácie. Najhoršie je ale realizovanie zmien akýchkoľvek informácií o zákazníkovi – musíme vyhľadať a aktualizovať všetky záznamy, v ktorých rovnaké údaje opakujú.

Ďalší možný postup, ktorý sa v systémoch s otvorenými súbormi často používa, je zlúčenie príbuzných informácií, napríklad súboru Objednávok a ich Rozpisov do jediného súboru . V tomto prípade by sme ku každej objednávke vytvorili záznam s jej záhlavím a potom záznamy rozpisov príslušnej objednávky. Medzi obidvomi typmi záznamov by sme v aplikácii rozlišovali pomocou zvláštnej dátovej položky, napríklad Typ záznamu. Aj keď si týmto spôsobom uľahčíme zviazanie dát jednej objednávky, súčasne tím ale celú databázu komplikujeme, pretože v jednom a v tom istom súbore zmiešavame 2 rôzne typy záznamov a konečným výsledkom nie je ani jednoduchšia aplikácia, ani jej rýchlejší vývoj.

Najhorším problémom štruktúry otvorených súborov ale je, že definíciu obsahu jednotlivých súborov a logiku potrebnú pre prepojenie akýchkoľvek dát umiestnených v rôznych súboroch musíme začleniť do každého aplikačného programu, ktorý s dátami pracuje. Výsledné aplikačné programy sú tím pádom zložitejšie a nákladnejšie.

Hierarchický model

Prvé databázy boli postavené na hierarchickom modeli. Ten sa vyvinul z pôvodných systémových súborov a záznamy v ňom boli usporiadané do hierarchie podobnej napríklad organizačnému diagramu. Každý zo súborov definovaných v systéme otvorených súborov je v tomto prípade nahradený typom záznamu alebo v hierarchickej terminológii – uzlom. Pre zjednodušenie budeme i naďalej používať záznam . Jednotlivé záznamy sú tu prepojené pomocou ukazovateľov, ktoré obsahujú adresu príslušného zviazaného záznamu. Ukazovateľ tak počítačovému systému hovorí, kde sa zviazaný záznam fyzicky nachádza, tak že sa trochu podobá bežnej poštovej adrese s ulicou a číslom domu v meste alebo adrese URL z prostredia Internetu. To znamená, že ukazovateľ definuje vzťah nadriadený - podriadený záznam ( rodič – potomok), ktorý označuje taktiež ako reláciu jedna k viacerým: jeden rodič môže mať viac potomkov, ale každý potomok má len jedného rodiča. Každý „synovský“ uzol môže obsahovať ukazovatele na ľubovoľný počet súrodencov, ale iba jediný ukazovateľ na „rodičovský uzol“.

Táto štruktúra sa hodne podobá klasickému usporiadaniu v podniku, v ktorom každý vedúci či riaditeľ môže mať viac priamo podriadených zamestnancov, ale každý zamestnanec má naopak len jedného bezprostredného nadriadeného. Zrejmým problémom hierarchického modelu je, že je príliš striktne definovaný a niektoré dáta do neho ťažko zapadajú – napríklad objednávka, ktorú musel do firmy podať nejaký zákazník (to by mohol byť jeden rodič záznamu), ale súčasne ju musel vybaviť určitý zamestnanec (čo by mal byť druhý rodič). Najrozšírenejšou hierarchickou databázou býval systém ISM (Information Management System) od firmy IBM.

Na nasledujúcom obrázku vidíme štruktúru (predchádzajúcej) databázy s otvorenými súbormi prevedenú do hierarchického modelu. Ako typy záznamov tu vidíme už známe položky Zákazník, Zamestnanec, Výrobok, Objednávka a Rozpis objednávok. Ak túto hierarchickú štruktúru porovnáme so systémom otvorených súborov z obrázku 1.2 vidíme, že záznamy Zamestnanec a Výrobok sú do hierarchickej štruktúry zapojené čiarkovanou čiarou, podľa ktorej nemôžu byť spojené s inými záznamami pomocou ukazovateľov. Z toho jasne vidíme najzávažnejšie obmedzenie hierarchického modelu, od ktorého bolo nakoniec upustené: Žiadny záznam nemôže mať viac ako jedného rodiča. To znamená, že záznam Zamestnanec nemôžeme prepojiť so záznamom Objednávka, pretože záznam Objednávka už rodiča má – a to záznam Zákazník. Podobne nemôžeme zviazať záznam Výrobok so záznamom Rozpis objednávok, pretože rodičom záznamu Rozpis objednávok je záznam Objednávka.

Obrázok 1.3: Štruktúra databázy v hierarchickom modeli

Databázový technici museli často problém obchádzať – buď príslušný rodičovský záznam, ten ktorý bol “na viac” zviazali až v aplikačnom programe, v podstate rovnako ako v systéme s otvorenými súbormi, alebo zopakovali všetky záznamy pod každým z rodičov a priradili tomu príslušnému rodičovskému záznamu čo bol „na viac“, čo pochopiteľne viedlo k plytvaniu diskovým priestorom, v tej dobe veľmi drahým. Žiadne z týchto riešení nebolo rozumne prijateľné, a preto nakoniec firma IBM systém IMS upravila do podoby, v ktorej mohol mať každý záznam niekoľko rodičov. Výsledný systém bol pomenovaný ako “rozšírený” hierarchický databázový model a svojou funkciou veľmi pripomínal sieťový databázový model.

Obrázok 1.4 ukazuje obsah vybraných záznamov v hierarchickom modeli. Niektoré dátové položky sme pre jednoduchosť vypustili, ale na celý obsah záznamov sa podľa potreby môžeme pozrieť na obrázku 1.2. Záznam zákazníka ALFKI obsahuje ukazovateľ na jeho prvú objednávku (číslo 10643) a táto prvá objednávka má ukazovateľ na ďalšiu objednávku (číslo 10692). Pretože objednávka číslo 10692 už ukazovateľ na ďalšiu objednávku neobsahuje, je to súčasne posledná objednávka tohto zákazníka. Podobne objednávka číslo 10643 obsahuje ukazovateľ na záznam s jej prvým riadkom (Rozpis objednávok, Výrobok 28), tento záznam obsahuje ukazovateľ na záznam ďalšieho riadku (Výrobok 39) tejto objednávky a tak ďalej.

Obrázok 1.4: Obsah záznamov v hierarchickom modeli

Medzi systémom s otvorenými súbormi a hierarchickým systémom je jeden ďalší dôležitý rozdiel – identifikátor ( kľúč ) rodičovského záznamu sa v hierarchickej databáze do potomkov nezapisuje, pretože vzťahy medzi záznamami sú sprostredkované pomocou ukazovateľov . Konkrétne teda zo záznamu Objednávky zmizlo číslo zákazníka a číslo zamestnanca a zo záznamu Rozpis objednávok bolo vypustené číslo výrobku. Ponechať tieto údaje v databáze nie je vhodné, pretože tím by v dátach mohli vznikať protichodné informácie – predstavte si napríklad objednávku, na ktorú ukazuje záznam jedného zákazníka, ale ktorá sama v sebe obsahuje číslo iného zákazníka.

Obrázok 1.5: Štruktúra databázy v hierarchickom modeli

Sieťový model

Sieťový model databáz vznikol zhruba v rovnakej dobe, ako hierarchický model. Najrozšírenejšou databázou postavenou na sieťovom modeli bol systém IDMS (Integrated Database Management System), ktorý pôvodne vyvinula spoločnosť Cullinane (neskôr Cullinet). Produkt bol ďalej zdokonaľovaný a doplnený o relačné rozšírenie, bol premenovaný na IDMS/R a nakoniec bol predaný spoločnosti Computer Associates.

To, čo v systéme s otvorenými súbormi ukladáme do samostatných súborov, definujeme v hierarchickom modeli ako typy záznamov (alebo jednoducho “záznamy”), pričom jednotlivé záznamy spájame reláciami jedna k viacerým, ktorým sa v terminológii sieťového modelu hovorí relácia vlastník - člen alebo množiny . My ale opäť pre jednoduchosť zostaneme pri klasickejších pojmoch rodič a potomok. Rovnako ako v hierarchickom modeli sa i tu podobné záznamy prepájajú pomocou ukazovateľov s fyzickými adresami. Taktiež identifikácia rodičovských záznamov je z potomkov vypustená, aby nedochádzalo k nekonzistenciám v dátach. Na rozdiel hierarchického modelu sú v tomto prípade vzťahy alebo relácie medzi dátami pomenované, tak že programátor môže v databáze prikázať prechod z jedného záznamu na iný prostredníctvom konkrétnej relácie a jeden typ záznamov sa tak fakticky môže na strane potomka zúčastniť na niekoľkých reláciách.

Ďalšia manipulácia s dátami : prechod na záznam s danou hodnotou pola, nastavenie na prvý členský záznam, na ďalší záznam, vytvorenie, zrušenie, modifikácia záznamov, zapojenie, vyradenia, prepojenie z väzby.

Sieťový model znamenal vyššiu flexibilitu, ale podobne, ako je tomu pri počítačových systémoch celkom často, bolo to za cenu vyššej zložitosti .

Obrázok 1.5: Štruktúra sieťového modelu databázy

Taktiež do sieťového modelu si teraz na ukážku prevedieme časť štruktúry databázy zo systému otvorených súbor. Ako vidíme z obrázku 1.5, sú tu rovnaké záznamy, ako v ekvivalentnej štruktúre hierarchického modelu z obrázku 1.3. Šípky na spojovacích čiarach vedú podľa konvencie z rodičovského záznamu k potomkovi. Všimnite si, že v tomto diagrame sú už záznamy Zákazník a Zamestnanec prepojené plnou čiarou, pretože príslušnú reláciu môžeme implementovať priamo.

Na obrázku 1.6 vidíme opäť obsah databázy podľa sieťového modelu. V tomto prípade je každý typ relácie rodič - potomok znázornený iným typom čiary a indikuje to iný názov relácie. Tento rozdiel je veľmi dôležitý, pretože z neho vidíme najväčšiu nevýhodu sieťového modelu – a tou je jeho zložitosť . Namiesto jednej cesty sa spracovanie záznamu sa môže riadiť podľa niekoľkých rôznych ciest. Ak napríklad začneme pri zázname zamestnanca číslo 4 (obchodný zástupca Klinček Peter) a vyhľadáme podľa neho prvú dohodnutú objednávku (číslo 10692), dostaneme sa naraz do stredu celého reťazca objednávok, ktoré patria zákazníkovi ALFKI. Aby sme teraz mohli nájsť všetky ostatné objednávky rovnakého zákazníka, musíme sa nejakým spôsobom prepracovať z aktuálneho miesta na koniec reťazca a potom preskočiť na začiatok a odtiaľ postupovať späť k aktuálnej objednávke. Popísané spracovanie sieťového modelu môže pracovať len za podmienky, že všetky reťazce ukazovateľov v databáze sú kruhové (cyklické). A ako si iste viete sami predstaviť, pokiaľ užívateľ databázy nebude tieto kruhové reťazce pozorne “strážiť”, môžu z nich veľmi ľahko vzniknúť nekonečné slučky (teda proces, ktorý nikdy neskončí). Veľmi voľnou paralelou k sieťovej štruktúre databáz je napríklad štruktúra stránok v sieti World Wide Web, preto že prakticky každá webová stránka obsahuje odkazy na iné, príbuzné webové stránky a nie sú vôbec neobvyklé kruhové reťazce odkazov.

Obrázok 1.6: Obsah záznamov v sieťovom modeli databázy

Proces navigácie v sieťovej databáze býval nazývaný “prechádzanie množinami”, pretože jeho súčasťou je výber ciest v databázovej štruktúre – a ten sa podobá napríklad chodeniu po lese, kde sa do rovnakého cieľa môžeme taktiež dostať po viacerých rôznych cestách. Bez aktuálnej “turistickej” mapy veľmi ľahko zablúdime, alebo ešte horšie, natrafíme napríklad na slepú uličku, z ktorej sa do cieľa, teda cieľového záznamu nedostaneme vôbec. Obrovská zložitosť a nutnosť nákladného udržovania databázy viedla k zániku tohto modelu.

Obrázok: Jednoduchý model sieťového databázového systému: Podnik XY, s.r.o.

Relačný model

Hierarchický a sieťový model sú nie len zložité , na viac majú spoločnú ešte jednu nepríjemnú vlastnosť – sú veľmi nepružné, t.j. málo flexibilné. Efektívne spracovanie údajov je možné iba pri ich prechode po dopredu definovanej ceste. Pri jednorázových dotazoch, akými sú napr. vyhľadanie všetkých objednávok dodaných v určitom mesiaci, je nutné prehľadať celú databázu. Počítačový vedci hľadali preto ešte lepšie riešenie. V histórii vývoja počítačov bolo len málo okamžikov, ktoré sa dajú označiť za revolučný zlom, a jedným z nich bola i výskumná práca Dr. E.F. Codda, na základe ktorej sa zrodil relačný model databáz.

Relačný model databáz je postavený na myšlienke, že mať v dátovej štruktúre len jednu dopredu definovanú cestu je príliš obmedzujúce riešenie , najmä vo svete neustále rastúcich požiadaviek na podporu náhodných či jednorázovo požadovaných informácií. Užívatelia proste nemôžu myslieť na všetky možné spôsoby využitia dát v databáze dopredu, teda ešte pred jej vytvorením. Preto, pokiaľ pre spracovanie dát v databáze vyžadujeme len dopredu definované cesty, vytvoríme tím iba akési „dátové väzenie“. V relačnom modely máme preto možnosť zviazať záznamy len podľa potreby a nie podľa väzieb definovaných dopredu pri prvotnom ukladaní záznamov do databázy. Relačný model je na viac postavený takým spôsobom, že dotazy pracujú vždy s určitou množinou dát (napríklad so všetkými zákazníkmi, u ktorých máme nezaplatené pohľadávky), a nie s jednotlivými záznamami (ako celku ) , ako tomu bolo u sieťového a hierarchického modelu.

V relačnom modeli sú údaje reprezentované pomocou dvojrozmerných tabuliek ( usporiadané n-tice - prvky takýchto množín sa znázorňujú ako riadky tabuľky ) podobne ako predstavuje list tabuľkového editoru MS Excel. Na rozdiel od tabuľkového listu nemusia byť ale dáta nutne uložené v tabuľkovej podobe a model na viac povoľuje zlučovanie (v relačnej terminológii spájanie, JOIN) tabuliek do pohľadov, ktoré majú taktiež podobu dvojrozmerných tabuliek .

Skrátka a dobre, tento model zodpovedá architektúre ANSI/SPARC, a obsahuje teda slušnú dávku fyzickej a logickej dátovej nezávislosti. Namiesto prepájania príbuzných záznamov pomocou ukazovateľov s fyzickou adresou, ako tomu bolo v hierarchickom a v sieťovom modeli, sa v tomto prípade do každej z tabuliek zapíše určitá spoločná dátová položka , podobne ako pri systéme s otvorenými súbormi. Spoločné stĺpce tabuliek vytvárajú relácie medzi jednotlivými tabuľkami , názvy nemusia byť rovnaké, ale musia mať rovnakú doménu, typ, veľkosť.

Relatívnou nevýhodou relačných databáz je skutočnosť, že informácie sú rozptýlené po tabuľkách a pri rozsiahlejších dotazoch je potrebné informácie z tabuliek spájať.

Ukážka návrhu databázy v relačnom modeli je znázornená na nasledujúcom obrázku.

Obrázok 1.7: Ukážka štruktúry relačného modelu databázy

Ak sa pozrieme teraz späť na obrázok s otvorenými súbormi, jasne vidíme, že v tomto prípade sa všetky jednotlivé súbory zo systému otvorených súborov zmenili do podoby tabuliek (takáto jednoznačná korešpondencia medzi otvorenými súbormi a relačnými tabuľkami nemusí platiť úplne vždy, ale je napriek tomu skutočne veľmi bežná). Čiary medzi tabuľkami vyjadrujú vzťahy, alebo relácie typu jedna k viacerým, pričom ich koniec s jednou čiarkou zodpovedá vždy strene “jedna” a druhý koniec v tvare vidličky definuje stranu “viacej”. Z čiar na obrázku je napríklad vidieť, že “jeden” zákazník je zviazaný s “viacerými” objednávkami, a že k “jednej” objednávke patrí “viac” riadkov s rozpísanými informáciami z Rozpisu objednávok. Toto schematické znázornenie je označované ako diagramy entin a vzťahov alebo diagramy ER (z anglického Entiny-Relationship Diagram).

Na nasledujúcom obrázku sme z 5 tabuliek relačného modelu z obrázku 1.7 zvolili celkom 3 a v nich sme vybrali istú vzorku údajov. Ak sa pozrieme na stĺpec s identifikáciou zákazníka (Kód zákazníka), ten je zapísaný v tabuľke Zákazníci aj v tabuľke Objednávky. V prípade, že sa číslo v poli Kód zákazníka v riadku tabuľky Objednávky zhoduje s číslom zákazníka zapísaným v tabuľke Zákazníci, znamená to, že sme našli zákazníka, ktorému patrí táto konkrétna objednávka. Podobne je na tom aj stĺpec Číslo zamestnanca v tabuľke Zamestnanci a Objednávky a popisuje tak zamestnanca, ktorý objednávku od zákazníka prijal a vybavil v systéme.

Obrázok 1.8: Obsah tabuliek v relačnom modely databázy

Veľkým prínosom relačného modelu je tiež fakt, že kladie dôraz na zachovanie integrity spracovávaných dát.

Najmä vďaka svojej elegantnej jednoduchosti a ľahkej zrozumiteľnosti bol relačný model nakoniec veľmi široko prijatý. Na tomto modeli je dnes založená drvivá väčšina komerčných databázových systémov (IBM DB2, Oracle - v súčasnosti majú oba zhruba tretinový podiel na databázovom trhu), MS SQL Server - v súčasnosti majú asi šestinu podielu na trhu, Sybase, Informix, PostgreSQL, Ingres, MySQL, MS Access, FoxPro, ....).

Objektovo orientovaný model

Objektovo orientovaný model vznikol fakticky už niekedy v 70-rokoch minulého storočia, ale významného komerčného využitia sa dočkal až v 90-tych rokoch. Dôvodom pre tento náhly nástup boli vtedajšie relačné databázové systémy (označované anglicky RDBMS Relation Databaze Management Systems), ktoré neboli schopné pracovať so zložitými dátovými typmi, ako sú obrázky, zložité výkresy a zvukové súbory a videosúbory. Taktiež búrlivý rozmach siete Internet a služby World Wide Web vyvolal požiadavku po vhodnej technológii, ktorá bude schopná doručovať zložité dáta.

Pod pojmom objekt rozumieme logické zoskupenie príbuzných dát a programovej logiky, ktoré spoločne reprezentujú nejakú vec či osobu z reálneho sveta , napríklad zákazníka, zamestnanca, objednávku alebo výrobok. Jednotlivé dátové položky , ako je identifikátor (ID), meno zákazníka, atď. sa v objektovo orientovanom modeli nazývajú premenné a sú uložené v každom objekte . Objektovo orientované názvoslovie pozná aj pojem metóda, čo je časť aplikačnej programovej logiky, ktorá pracuje nad určitým objektom a realizuje nad ním určitú funkciu , napríklad kontrolu úverového limitu zákazníka alebo aktualizáciu jeho adresy. Najdôležitejším rozdielom objektovo orientovaného modelu oproti ostatným uvedeným modelom je, že k premenným môžeme pristupovať iba prostredníctvom metód. Tejto vlastnosti nazývame zapúzdrenie objektov.

Popísaná striktná definícia objektu platí pritom len pre objektovo orientovaný model. Všeobecný výraz databázový objekt, označuje akúkoľvek pomenovanú položku uloženú do objektovo orientovanej databázy (napríklad tabuľka, index alebo pohľad). A rovnako ako sa do sveta relačných databáz dostali princípy objektovo orientovaného programovania, našla sem svoju cestu aj používaná terminológia, aj keď často s menej presnou definíciou.

Obrázok 1.9 “Anatómia” objektu

Objekt zákazníka implementovaný do objektovo orientovaného modelu je schematicky znázornený na obrázku 1.9. Okolo jadra s premennými sú jednotlivé metódy zakreslené do kruhu, ktorý naznačuje princíp zapúzdrenia. Prakticky si objekt môžeme predstaviť ako atóm, v jadre ktorého sa nachádzajú premenné a v jeho “elektrónovom obale” sú metódy. Každý zákazník bude mať samostatnú kópiu celej štruktúry objektu , ktorú nazývame inštancia objektu – podobne ako by v systéme s otvorenými súbormi mal svoju vlastnú dátovú štruktúru záznamu o zákazníkovi.

Na prvý pohľad by sa mohlo zdať, že objektovo orientovaný model je neefektívny, pretože metódy a definície premenných je nutné ukladať redundantne, zvlášť pri každej inštancii. Tak tomu ale v skutočnosti nie je. Objekty sú usporiadané do hierarchie tried a spoločné metódy a definície premenných stačí definovať len na jednom mieste, odkiaľ ich zdedia všetci členovia rovnakej triedy.

Princípy objektovo orientovaného programovania majú také výhody, že sa nakoniec istým spôsobom dostali takmer do všetkých aspektov moderných počítačových systémov. I v systémovom registri Microsoft Windows je napríklad definovaná hierarchia tried.

Objektovo relačný model

Aj keď objektovo orientovaný model prináša vďaka zapúzdreniu dát určité výhody a minimalizuje dopady modifikácií v systéme, na druhej strane v ňom chýba možnosť vytvárania jednorázových dotazov, a preto bol „odsúdený“ prežívať len v malom segmente trhu, kde je potreba spracovať zložité dáta a nie práca s jednorázovými dotazmi.

Výrazné výhody objektovo orientovaného modelu zaznamenali ale aj niektorý výrobcovia relačných databáz, ktorí doplnili objektové funkcie do bežných databázových produktov a pokúšali sa tak využiť to najlepšie z obidvoch modelov. Pôvodne sa tieto produkty nazývali univerzálne databázy , a napriek tomu, že marketingovo mal tento pojem veľkú nádej na úspech, v odborných kruhoch sa nikdy výrazne neujal a model začal byť označovaný ako objektovo relačný (OR). Za objektovo relačné databázové systémy je možné vďaka postupnému vývoju do istej miery označiť databázu Oracle, DB2 a Informix.

Z hľadiska spôsobu ukladania dát a väzieb medzi nimi, t.j. dátového modelu môžeme databázy rozdeliť do základných typov:

• Hierarchická databáza
• Sieťová databáza
• Relačná databáza
• Objektová databáza
• Objektová relačná databáza