Objektově-relační databáze

Zpoždění objektových databází za relačními a skutečnost, že množství současných aplikací je založeno na relač...


Zpoždění objektových databází za relačními a skutečnost, že množství současných
aplikací je založeno na relační technologii, probudily u řady výrobců SŘBD
snahy integrovat objek-ty a relace do jednoho systému a vytvořit novou,
objektově-relační (OR) technologii. Řešení tohoto problému má řadu variant. V
90. letech se objevují minimálně 3 přístupy:
Objektově-relační datové manažery mapují objekty přímo do relačních tabulek a
řídí provoz těchto objektů. Např. Odapter firmy HP může prohlížet tabulky
vytvořené v SQL a konstruovat korespondující definice objektů v C++.
Relační obálky jde o knihovny které se přilinkují k relační databázi. Relační
obálka detekuje změny objektů a automaticky je promítá pomocí SQL do relační
databáze, podobně detekuje změny v relační databází a promítá je do logických
objektů. Tato zobrazení jsou pro uživatele transparentní (např. Smalltalkové
nástroje VisualWorks a VisualAge).
Objektově-relační databáze (ORDB) ukládají data pomocí relací i přímo jako
objekty (viz univerzální servery databázových výrobců jako Oracle, Informix,
IBM, Sybase apod.).
Implementace založené na prvních dvou řešeních jsou obvykle mnohem levnější než
třetí, i když některá z nich jsou v provozu velmi pomalá. Je jistě atraktivní
vidět "objektově", nicméně strukturálně složitý objekt je obsažen ve více
tabulkách, což znesnadňuje jeho manipulaci. E. Dysonová (Edventure Holdings)
trefně připomíná, že použít tabulky pro uložení objektu je podobné, jako když
řídíte auto a pak ho před uložením do garáže celé rozmontujete. Auto může být
ráno zase smontováno, je však otázkou, je-li toto ten nejefektivnější způsob
parkování. Problém proto vyžaduje obecnější přístup, který v extrémním případě
vede až k objektově--orientovaným databázím.
Z hlediska relačního uživatele je nanejvýš uspokojivé, aby získal prostředky,
se kterými poběží staré (rozuměj relační) aplikace, a dostal k dispozici nové,
rozšiřující možnosti. Důvody vzniku OR technologie tedy byly velmi pragmatické.
Objevila se potřeba rozšířit možnosti aplikace relačních databází do oblastí
požadujících integraci klasických tabulkových dat a složitých objektů, jako
např. časové řady, prostorová data, binární objekty jako audio, video, obrázky,
či applety. Zapouzdřením metod a datových struktur může objektově-relační
server vyvolat složité operace pro prohledávání a transformaci takovýchto
složitých multidimenzionálních dat. Databázové zpracování vyžadují i speciální
aplikace, jako je medicína (EKG, rentgenové snímky) či výzkum Země (seismická
data, snímky ze satelitů). Výsledkem těchto snah jsou tzv. univerzální servery,
které podporují jak složité objekty, tak relační datové struktury.
Jiným důvodem opodstatňujícím vznik OR technologie je objektová analýza a
následný objektový klientský pohled na aplikaci. Není příliš pružné navrhovat
objekty a pak je mapovat do relačních tabulek. Navíc, to bývá efektivní pouze v
těch případech, jsou--li objekty stejné jako řádky normalizované tabulky.
Uživatelské definované typy a funkce
V rozšíření směrem k objektům se výrobci databází zaměřili hlavně na data,
reprezentovaná jako velké objekty (texty, obrázky). Umístění těchto objektů do
databáze bylo sice umožněno již dříve, nicméně bez jakékoliv další podpory. Pro
relační SŘBD byla vnitřní struktura takového objektu neznámá a tedy ji nebylo
možné zahrnout do vyhledávání podle obsahu, jak je obvyklé v SQL. V praxi jde o
úlohy nalézt v textu klíčová slova, v mapě odlišit řeky od silnic apod. Řešení
bylo takové, že po získání nějakého objektu musel být použit další, speciální
software.
Protože je nemožné, aby kaž-dý výrobce SŘBD byl schopen implementovat širokou
škálu různých typů dat a odpovídajících přístupových metod, objevila se idea
rozšiřitelných relačních SŘBD. Rozšiřitelnost zde znamená dát možnost přidávání
nových datových typů, ale i také potřebné programy (funkce) pro efektivní
vyhledávání odpovídajících uložených dat v souladu s jejich vnitřní strukturou.
Infrastruktura objektů tedy může být dána možností definovat uživatelsky
definované datové typy (UDT) a uživatelsky definované funkce (UDF). Softwarově
jde ovšem o mnohem složitější úkol. Dané možnosti lze pro jistou třídu typů a
funkcí "zabalit" do modulu, který je připojitelný k relačnímu SŘBD. To
zdůvodňuje termín univerzálního serveru. Nejde vůbec o jednoduchý princip,
protože to znamená, že nové datové typy a funkce musí být použitelné spolu s
ostatními daty v databázi (data nových typů se objevují jako sloupce tabulek),
SQL musí "rozumět" nejen novým typům, ale i aplikacím nových operátorů a
funkcí. Navíc, optimalizátor takového (rozšířeného) SŘBD musí zahrnout do
optimalizace i nové typy dat, což obecně znamená nasadit nové optimalizační,
ale i vyhledávací strategie.
ORSŘBD zahrnuje začlenění infrastruktury objektů a odpovídající moduly,
rozšiřující typový aparát. Této technologii se někdy také říká "plug-in", i
když její realizace může být různá. Zmíněné moduly jsou používány známými
výrobci relačních SŘBD a nazývají se např. relační extendery (DB/2), DataBlades
(INFORMIX) představující jakési vyměnitelné "čepele" do rukojeti nože, které
tam nasazujeme podle potřeby, či cartridges (ORACLE), tj. náboje, kterými
nabíjíme podle potřeby zařízení databázový stroj. Podle údajů z roku 1997, pro
INFORMIX se vyvíjí 140 Datablades, pro ORACLE 200 cartridges. IBM disponuje ve
svém ORSŘBD DB/2 v r. 1997 pěti extendery: obrazovým (ukládá a vybírá obrázky
formátů GIF, JPEG, BMP, vyhledává obrázky podle obsahu na základě podobnosti),
video (ukládá a vybírá videosekvence s možností detekce změn ve scéně apod.),
audio (rozlišuje např. klipy ve formátu MIDI), otisků prstů (rozlišuje otisky
prstů, porovnává je na podobnost) a textovým.
Zastavme se na chvíli u textového extenderu, který je nám zřejmě nejbližší.
Prvkem řádku tabulky v textové databázi může být dokument zapsaný v jednom z
mnoha editorů, v jednom z 18 jazyků. Formulace dotazu na dokument je založena
na Boolském výrazu, který se konstruuje pomocí spojek "" (AND), "|", (OR) a
NOT. Funkce pro výběr se zahrnují do SQL příkazů tak, jak to dovoluje syntaxe
SQL. Jednou z nejdůležitějších je CONTAINS, která vrací hodnotu 1, jestliže
dokument vyhovuje dotazu, tj. je na něm splněn zadaný Boolský výraz. V
následujícím příkladě je formulován dotaz na články z časopisu obsahující slova
"transakce" a buď "SQL3", nebo "SQL92", v jakémkoliv pořadí, neobsahující však
"replikace".
SELECT časopis, datum, titul
FROM ČLÁNKY
WHERE CONTAINS(text_ članku, ("transakce" ("SQL3" | "SQL92") AND NOT
"replikace")) = 1;
V textovém extenderu existují ještě další užitečné funkce jako NO_OD MATCHES
(kolikrát se zadaný vzorek vyskytoval v textu dokumentu) nebo RANK (udává
hodnotu pořadí v kolekci vybraných dokumentů na základě nějaké míry).
Výhodou rozšiřujících modulů je, že funkce jsou specifikovány a výběr algoritmu
či jeho implementace může být předmětem změny. To umožňuje "ušít" uživateli
potřebný extender na míru. Jednotlivé firmy řeší implementaci i koncepci
rozšiřitelnosti různě, neexistují zatím žádné poku-sy o standardizaci. Např.
zatímco DataBlades mají přímý přístup k databázovému jádru (podobně jako
UniSQL), ORACLE považuje tuto techniku za příliš riskantní a razí spíše
architekturu více serverů. V prvním přístupu se ovšem snadněji dosáhne
efektivnějšího zpracování dotazů.
Složité objekty
Rozšiřitelnost databáze popsaným způsobem se někdy považuje za hlavní rys,
který charakterizuje OOSŘBD. Na druhé straně již před technikou rozšiřitelných
relačních databází se objevily postupy, jak integrovat tabulky a objekty. Éra
OR začala již v r. 1992, kdy byl uveden systém UniSQL/ /X, HP brzy následoval s
objektovou vrstvou nad relačním SŘBD (OpenODB, později Odapter). Po další
vývojové linii se vyvíjel Postgres, který se přes firmy Montage Systems a
Illustra nakonec našel vůdčí uplatnění v technologii DataBlades v INFORMIXu.
Won Kim, považovaný za zakladatele OR technologie, považuje rozšiřitelnost
nabízenou dnešními hlavními producenty ORSŘBD, pouze za druhotný, i když
užitečný rys. V článku Bringing O/R Down to Earth (DBPD, July 1997) podotýká,
že rozšiřitelnost je jen logickým důsledkem OO přístupu. Podobně kriticky se k
problému staví Stonebraker, kde poukazuje na rozšiřitelnost typu "plug-in"
nabízenou např. ORACLE jako sice vhodnou pro konektivitu aplikace-aplikace,
nicméně však nemající nic do činění s databázovou "plug-in". Jde o pouhý
middleware, který nezakládá OR technologii. V jiné podobě slouží v 4GL jazycích
různé objektové knihovny apod.
Použití "plug in" technologie v uvedeném smyslu je pouze jedna z možností.
Rozlišují se další architektury:
lPřidání zvláštního aplikačního rozhraní a speciálních serverů (také ORACLE 7.3
viz např. CONTEXT, Media Server, OLAP).
lSimulace OR na úrovni middleware (také ORACLE 7.3 viz např. část Spatial Data
Option).
lÚplné přepracování databázového stroje (např. Illustra Information Technology).
lPřidání OO vrstvy k relačnímu stroji (např. INFORMIX Universal Server, IBM
D2/6000 Common Server).
Nevýhodou prvních dvou přístupů je obvykle špatný výkon, problémy s
optimalizací a správou systému. Další 2 přístupy představují současné
propagované alternativy.
Jazyky nad relacemi a objekty
"Objektovost" by měla u OR technologie zahrnovat z datového modelu minimálně
hlavní rysy standardu ODMG-93. Další nutností je odpovídající objektový jazyk
vyšší úrovně. ODMG-93 nabízí OQL, podobný v lecčems SQL92. Vývoj standardu SQL
však vede k vlastnímu řešení objektového rozšíření v návrhu SQL3. Zdá se, že
hlavní výrobci RSŘBD a ORSŘBD vidí budoucnost právě zde.
Ze standardu SQL3 toho hodně nabízí Oracle8, Universal Dynamic Server v
konfiguraci s Universal Data Option INFORMIXu, Universal Database IBM a od r.
1997 i Sybase v Adaptive Server (prostřednictvím jazyku Java). Používá se
bohatý aparát typů objektů. Objekty mohou např. modelovat složené atributy
(např. ADRESA) nebo entity známé z E--R modelování (např. Osoba). Spolu s daty
se pomocí CREATE TYPE definují i jména a parametry funkcí. Objekty lze umístit
ve sloupcích tabulek, nebo v tabulkách, kde každý řádek má OID (je objektem).
Byl-li definován typ objektů Osoba, je možné vytvořit tabulku objektů pomocí
CREATE TABLE OSOBY OF Osoba.
Jakékoliv objekty jsou přístupné (pomocí SELECT) výhradně pomocí tabulek.
Objekty umístěné přímo ve sloupci však nemají OID. Např. adresy lze mít jako
řádkové objekty v tabulce ADRESY, ale konkrétní adresa bez OID, např.
<Malostranské 25, Praha 1, 118 00>, může být hodnotou atributu Bydliště typu
Adresa.
Pro kolekce objektů existují v Oracle8 např. konstrukty Varray (uspořádaný,
délkou omezený seznam) a hnízděná tabulka (neuspořádaná, neohraničená kolekce
prvků). Definujme např. CREATE TYPE Auta AS TABLE OF Auto, kde Auto je jinde
definovaný typ objektu (dvojice-značka, SPZ). Typ atributu Vozový_park (u
definice tabulky FIRMA) může být typu Auta (tj. jde o množinu aut danou
tabulkou). Na obr. 1 je pro firmu A dán vozový park obsahující dvě auta.
Dokonce lze zadat NESTED TABLE Vozový_park STORE AS T_VOZY, kde T_VOZY je
tabulka, ve které budou uloženy dílčí tabulky hodnoty atributu Vozový_park, a
to od všech firem. Tabulka T_VOZY tedy bude obsahovat popisy všech aut (typu
Auto).
V Oracle8 je též možné realizovat pohledy (views) na relační data, které vrací
tato data jako objekty s OID).
Některé firmy nabízejí ještě další speciálnější rysy OO technologie. Patří sem
např. Illustra a UniSQL poskytující ve svých ORSŘBD polymorfismus (stejná
funkce může operovat odlišně v závislosti na typu objektu) a dědění. UniSQL
Server také nabízí zapouzdření, použití ukazatelů a kolekcí v kombinaci s
relačním modelováním za použití dynamického spojování tabulek a přístupu přes
index.
Relační databázista se při pohledu na tyto možnosti může obávat šíře přístupu.
Vždyť původní relační tabulka je pouhý jednoduchý speciální případ celé
koncepce. A což teprve dotazování. Doporučuji každému zkusit si na-psat několik
dotazů v SQL3 nebo OQL. Zdá se, že složitější struktury vedou k podstatně
složitějšímu dotazování. Před uživate-lem ORSŘBD bude zřejmě dost problémů s
použitelností nabízených možností. Na druhé stra-ně existují názory, že ORSŘBD
se prostřednictvím nějaké formy SQL přiblíží podstatně k uživateli, protože
zvládnutí OOSŘBD se odhaduje na 6 měsíců až rok.

8 1895 / or









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.