Objektově-orientovaná databáze

Termín objektově-orientovaný (OO) se objevil na počátku 80. let v souvislosti s jazykem Smalltalk--80. Idea OO programov


Termín objektově-orientovaný (OO) se objevil na počátku 80. let v souvislosti s
jazykem Smalltalk--80. Idea OO programování je ovšem minimálně ještě o 10 let
starší. V databázové komunitě se však širšího rozmachu OO dostalo až v polovině
80. let. Objektová orientace se pro databáze přímo nabízela. Již 10 let se
rozvíjely konceptuální modely založené na pojmech entity a vztahu, které
přirozeně modelovaly většinu aplikační reality dané např. podnikovými
informačními systémy.
Objekty, tak jak je používali programátoři, ovšem umožňovaly něco více než
pouhé datové modelování. Koncepce OO je natolik obecná, že dává možnost
analyzovat, navrhovat a implementovat v podstatě libovolný softwarový systém,
tj. mezi jinými i databázi.
Čelný protagonista OO Edward Yourdon charakterizoval v r. 1994 ve své publikaci
"Objektově-orientovaný návrh" OO systém jako systém vybudovaný pomocí OO metod,
jehož každá komponenta zapouzdřuje nějaká data a funkce, přičemž tyto
komponenty dědí atributy a chování z jiných takových komponent a komunikují
navzájem pomocí zpráv.
Charakterizovat OO v databázích znamená použít obecné koncepce OO a doplnit je
databázovými rysy. Jinými slovy řečeno, OOSŘBD je takový SŘBD, který podporuje
OO model. Odpovídající databáze je OO databáze.
Objektové rysy OOSŘBD
Asi nejdůležitějším rysem OOSŘBD, a dříve také jedním z hlavních argumentů pro
jejich použití, je pojem objektu sám. Objekty v objektovém světě jsou totiž
složitější než jednoduché entity známé z E-R modelování. Připomeňme např. typ
entity ZAMĚSTNANEC a vícehodnotový atribut VZDĚLÁNÍ. Situace, kdy do dotazníku
vyplňujeme potřebnou množinu zkratek absolvovaných škol, se v E-R a následně i
v relačním modelu dat (RMD) modeluje obtížně. Vícehodnotový atribut totiž E-R
metodologie běžně nemají v repertoáru, v relačních tabulkách by jeho přímá
realizace vedla k datovým strukturám, které nejsou v 1. normální formě.
Objekty v OO systémech mohou tedy být složité a, kromě jiného, snadno řeší
zmíněné problémy. Docházíme tak k jednomu dílčímu závěru: lOO umožňuje způsob
modelování aplikace v případech, ve kterých se E-R nebo RMD jeví nevhodný.
Jistě, lze namítnout, že vše lze nějak udělat. I prostorové objekty (např.
mapy) lze realizovat pomocí relační databáze. Hned však vyvstane problém s
přístupem k takovým objektům. Četné pokusy z praxe dokladují, že realizace
takových požadavků, např. pomocí SQL, vede k nesmírně složitým dotazům a velmi
neefektnímu provozu. Druhý dílčí závěr říká:
lOO umožňuje manipulaci složitých objektů efektivnějším způsobem než v relačním
SŘBD.
Jak složité objekty mohou být? Mezi obvyklé konstruktory objektů patří: n-tice,
množina, multimnožina či kolekce (prvky se mohou opakovat), seznam, pole.
Důležitá je ortogonalita těchto konstruktů. V nejlepším případě znamená, že
aplikace konstruktů lze libovolně hnízdit. V RMD můžeme z jednoduchých hodnot
pouze konstruovat řádky (n-tice) a z řádků množiny (relace, tabulky). V OO je
situace nadějnější, i když jak v OO metodologiích, tak v OO modelech
používaných v jednotlivých OOSŘBD, nebývá ortogonalita plně dodržena.
Aby mohly být objekty v OO aplikaci sdíleny jinými objekty,
je nutná identita objektů, řešená pomocí identifikátorů objektů (OID).
Referenční integrita, známá z relačních databází a sdílení objektů, se pak
snadno realizuje odkazem založeným na této identitě. Připomeňme však, že z
uživatelského hlediska to neznamená, že se má zcela vytratit pojem (primárního)
klíče, tolik známý z RMD. Protože uživateli není OID přístupný, zůstává v mnoha
případech, např. pro dotazování, takový klíč nutností. Některé přístupy
dovolují rozšiřitelnost ve smyslu možnosti definovat uživatelské typy. Ty by
neměly být odlišitelné od systémově daných typů, tj. způsob jejich použití při
tvorbě aplikací by měl být stejný.
Zapouzdření znamená v nejobecnějším smyslu separaci specifikace objektu od jeho
implementace. Pro OO databázi to znamená, že závisí na OOSŘBD zdali
strukturální část objektů je viditelná (prostřednictvím rozhraní) nebo skrytá
(je částí implementace). Neexistuje jednotný přístup, jak daleko jít v
implementaci zapouzdření.
Mezi další základní pojmy OO patří třída a typ. Specifikace obojího je podobná
a jednotlivé OOSŘBD se liší podle toho, zdali používají jedno či druhé nebo
obojí. Cílem je specifikovat společné rysy množiny objektů abstraktně. Zaměříme
se pouze na třídy. Třída představuje v OO databázi základní datovou strukturu
(např. třída ZAMĚSTNANEC, OBJEDNÁVKA apod.). Třída je popsaná pomocí atributů
(vlastností), např. DATUM_OBJEDNÁVKY, ADRESA apod. Typy atributů využívají již
zmíněných konstruktorů, které umožňují specifikovat strukturálně složité
objekty. Každý objekt je jistou instancí nějaké třídy. OOSŘBD musí rovněž
obsahovat mechanismy pro vytváření instancí a manipulaci množin instancí.
Chování objektů je ve třídě zapouzdřeno, tj. třída má k dispozici systémem i
uživatelem definované procedury. V terminologii OO se nazývají metody, které
poskytují potřebné rozhraní (API) pro aplikace pracující s objekty. Uživatel
zná signaturu metody, tj. její jméno a typy parametrů, implementace je skryta.
Komunikace mezi objekty se děje tradičně pomocí zpráv.
Pojem dědění souvisí s hierarchiemi typů či tříd. Dědění je mechanismus
umožňující nové třídě, která má být vybudována, využít metody a data
deklarovaná v jiných třídách. Podstatné je, že podtřída nedědí z rodičovské
třídy data, ale atributy a metody. Třída tedy není definicí dat, ale datové
struktury. Existuje-li dědění a uživatelské typy, musí OOSŘBD podporovat
přetížení (2 metody mají stejné jméno a různou signaturu) a s tím související
opožděné vazbení, tj. připojení těla procedury ke jménu až v době provádění
programu. Tyto rysy pomáhají vyhovět požadavku na nerozlišitelnost
uživatelských a systémově definovaných typů, dovolují redefinovat zděděné
metody či operátory se stejným jménem.
Databázové rysy OOSŘBD
Jak je patrné z historie OOSŘBD, první pokusy o vytvoření OO databází vycházely
z existence OO programovacích jazyků (hlavně Smalltalk a C++). Tyto jazyky se
rozšiřovaly tak, aby poskytovaly to nejzákladnější, co vůbec mohou databáze
poskytnout, tj.:
lperzistenci,
lřízení dat na vnějších pamětech,
lsdílení dat současně více uživateli,
lmechanismy zotavení z chyb,
lmožnost klást ad hoc dotazy na OO databázi.
Důraz je kladen na perzistenci, která by měla být ošetřována implicitně, tj.
aktualizace perzistentních objektů by se měly stát perzistentní (trvalé), aniž
by o to uživatel (program) explicitně žádal. Řízení vnějších pamětí souvisí s
provozem OO systému, ve kterém by se uživatel neměl starat o indexování
objektů, volbu přístupových mechanismů k nim (rozuměj: objektům uloženým na
magnetickém disku) apod. Také požadavek na sdílení dat (dnes obvykle založené
na transakčním zpracování) je přirozený a byl zdůrazňován a realizován i v těch
nejstarších klasických SŘBD. Totéž by se dalo říci i o požadavku na zotavení z
chyb.
Poslední požadavek je každému znám z pozice uživatele SQL ve světě relačních
databází. Existence silného neprocedurálního databázového jazyka je více než
žádoucí, vytváření aplikací bez něj si dnes již málokdo dovede představit.
Řekněme rovnou, že tento problém se dlouhá léta v OOSŘBD řešil pouze částečně a
tvořil také jeden z hlavních
terčů jejich kritiky. Ve většině OOSŘBD se vlastně vytvářely aplikace na úrovni
daného podpůrného programovacího jazyka, tj. na nízké úrovni abstrakce, v
podstatě navigačním způsobem.
Současné přístupy k OOSŘBD
Současné dění v OOSŘBD
nelze pochopit bez minulosti OOSŘBD. Neexistence společného objektového modelu
vedla konstruktéry OOSŘBD k mnoha ad hoc produktům, které se lišily v mnoha
detailech pojetí i implementace OO pojmů. Příznačnými pro přístup k OO v
databázích jsou manifesty. V r. 1989 byl formulován skupinou databázových
odborníků první z nich Manifest OOSŘBD, který lze zařadit mezi první pokusy
definovat charakteristiky OOSŘBD. Jeho autoři rozdělili jednotlivé rysy do 2
hlavních kategorií: povinné, volitelné. Mezi povinné rysy patří v podstatě
všechny již zmíněné výše. Zbývá uvést ještě výpočetní úplnost, tj. schopnost
realizovat libovolnou vyčíslitelnou funkci. Tento rys je obvykle splněn tím, že
základem OOSŘBD je výpočetně úplný objektově-orientovaný programovací jazyk.
Volitelné je pro konstrukci OOSŘBD vícenásobné dědění, tj. varianta hierarchií
tříd, kdy ke třídě existuje v hierarchii více než 1 rodičovská třída. Volitelná
je i možnost verzí objektů, distribuce a několik dalších možností. Jinou
možností, jak ocenit již existující OOSŘBD, je vyjít ze stávajících, definovat
sadu charakteristik a porovnat produkty vzhledem k nim. Na základě této metody
se mezi nejlepší adepty dostaly systémy O2, ObjectStore, Objectivity, Ontos a
Versant.
V r. 1993 se objevila první verze standardu ODMG-93, nazvaného Standard
objektových databází, jako výsledek práce skupiny ODMG (Object Database
Management Group), kterou tvořili čelní producenti OOSŘBD. Daný standard
zahrnuje objektový model, definiční jazyk pro objekty (ODL), objektový
dotazovací jazyk (OQL) a prvky nutné pro vazbu na C++ a Smalltalk. K těmto
jazykům se řadí od roku 1997 i JavaTM. Objektový model vychází z návrhu skupiny
OMG (Object Management Group), která se věnuje objektům šířeji než pouze z
databázového hlediska.
Syntaxe ODL poněkud rozšiřuje definiční jazyk pro rozhraní (IDL), který OMG
používá jako součást architektury CORBA. IDL a tedy i IDL jsou výrazně
ovlivněny jazykem C++. Jazyk OQL je neprocedurální jazyk, který umožňuje
dotazování a aktualizaci objektové databáze. Syntaxe OQL je podobná SQL, není s
ní však plně kompatibilní. Připomeňme, že v tomto případě jde o další přístup
ke standardizaci SQL3, což je verze SQL (dosud ne oficiálně vydaná), která řeší
problém objektů z hlediska jejich zapojení do RMD.
Dotazy v OQL mohou zahrnovat metody, a metody v podpůrném programovacím jazyku
mohou zahrnovat dotazy. Zdůrazněme, že OQL má prostředky k zacházení se
složitými objekty, což představuje výrazný pokrok v řešení ad hoc dotazů nad OO
databázi. Také standard ODMG-93 se vyvíjí, existuje již verze zvaná ODMG 2.0
vydaná v roce 1997. Mnoho problémů však přetrvává. Existují totiž některé silné
a koncepčně propracované produkty, např. O2, které se od ODMG liší např.
pojetím perzistence. Také pojetí typů v C++, Smalltalku a JavaTM nelze ve všech
aspektech sladit se standardem.
Použití OOSŘBD, další vývoj První představy vedoucí k prohlášením, že OO
databáze postupně nahradí relační, se nevyplnily. Úspěšnost nabízených produktů
(řádově několik desítek
typů) je poměrně nízká. Z obchodního hlediska jde o pouhá procenta trhu s
relačními databázemi. Důvodů je několik. Prv-ní z nich souvisí s kvalitou či
úrovní dosažené technologie. Zatímco relační SŘBD jsou na vrcholu
svého rozvoje, OO databázová technologie má za sebou podstatně kratší vývoj a
hlavně ještě řadu problémů k řešení. Patří sem např. optimalizace dotazů,
indexování a další rysy, které zejmé-na ovlivňují výkon databázového stroje a
tím i jeho atraktivnost pro uživatele. Nepochybně i dlouhá léta bez standardů,
která dala příležitost mnoha týmům vytvořit vlastní, jedinečné řešení, se
podepsala na pomalejším pronikání OOSŘBD do praxe. Mezi důvody lze zařadit i
to, že pro některé běžné podnikové aplikace se stávající relační technologie
ukázala zcela postačující a dokonce vhodnější než objektová. Je tedy užitečné
uvažovat různou funkcionalitu obou přístupů (obr. 1).
Na druhé straně, zpráva z workshopu o zkušenostech s použitím OOSŘBD v reálném
světě, který byl organizován ku příležitosti nejvýznamnější OO světové
konference OOPSLA v r. 1997, shrnuje, že OOSŘBD jsou úspěšně používány. Nejde
přitom pouze o tzv. netradiční aplikace (např. elektronická knihovna,
inženýrské databáze, databáze pro automatizovaný návrh, řízení webovských
struktur apod.), které byly jednou z hlavních motivací prvních OOSŘBD. Uváděny
jsou aplikace např. v bankovnictví. Případové studie ukazují, že aplikace
nejsou příliš testovány, ani nejsou příliš využívány dotazovací prostředky
odpovídajících produktů, schází kvalifikovaný personál, zkušenosti. Postavení
jednotlivých typů databází v aplikačním prostředí ukazuje obr. 2.
V r. 1997 se ukázalo, že tlak na kvalitativní pokrok ve vývoji je obrovský.
Objevují se objektová SQL, vysoká propustnost transakcí atd. Také aplikace se
rozšiřují, jak např. v oblasti řídicích systémů, tak v oblasti telekomunikací.
Další reálnou variantou jsou objektově-relační databáze. Na ty se zaměříme
příště.
8 1153 / or









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