OODBS sa dnes dá charakterizova? ako absencia univerzálneho dátového modelu. V sú?asnosti sa implementácia tohto modelu iba h?adá a táto cesta nie je jednoduchá.

Referát z predmetu objektovo orientované databázové systémy

Základná myšlienka OODBS

OODBS sa dnes dá charakterizova? ako absencia univerzálneho dátového modelu. V sú?asnosti sa implementácia tohto modelu iba h?adá a táto cesta nie je jednoduchá.

Základnou myšlienkou objektovo orientovaných databáz je priblíženie dát bližšie k programátorovi. V rela?nom databázovom systéme sa prístup k dátam realizuje prostredníctvom ur?itého rozhrania, teda napr. JDBC, SQL.. Naopak, OODBS nám umož?uje používa? vlastné štruktúry a objekty v programe a jednoducho ich spravi? perzistentnými. K takto vytvoreným objektom môžme následne kedyko?vek pristupova? a nahra? ich z uloženého stavu do bežiaceho programu.

Programátorovi je bližšie pracova? s dátami, ktoré majú hierarchickú štruktúru. Táto štruktúra vernejšie opisuje obraz reálneho sveta.

Manifest Objektovo-Orientovaných databáz

O základných vlastnostiach, ktoré by takýto systém mal sp??a? pojednáva tzv. Manifest Objektovo-Orientovaných databáz.

Má za úlohu definova? takýto systém a popisuje jeho hlavné znaky a charakteristiky, ktoré musí sp??a? aby bol plnohodnotným objektovo-orientovaným databázovým systémom.

Sú rozdelené do týchto troch skupín: povinné, volite?né a otvorené.

Medzi povinné patria:

• OODBS musí by? DBMS (databáse management system) a mal by by? kompatibilný so sú?asnými objektovo orientovanými jazykmi

• OODBS má podporova? komplexné objekty(množina, záznam, zoznam), z ktorých môžu by? následne odvodené ?alšie ešte komplexnejšie typy.

• OODBS má podporova? identitu objektov? ?iže rozdiel medzi identickos?ou (dva objekty sú rovnaké, ?o sa týka dát) a rovnos?ou (sú rovnakým objektom). V tomto systéme je možné to, že jeden objekt zdie?a spolo?ný komponent ostatných objektov. Ak máme napr. ?lenov rodiny majúcich rovnakého potomka, tento objekt nemusí fyzicky existova? dvakrát.

• V OODBS sa majú da? zapuzdrova? objekty? myšlienka modularity ? je potrebná na štruktúrovanie zložitých aplikácií. V sú?asnosti predstavuje trend, ktorý prispieva k vyššej efektivite práce a škálovate?nosti daného projektu. Táto zapúzdrenos? tiež zabezpe?uje logickú nezávislos? dát ? zmena implementácie si nevyžaduje zmenu programov pracujúcich s týmto typom.Objekt sa musí sklada? z dvoch ?astí: interface a implementácia. Implementácia z dátovej a procedurálnej ?asti.

• OODBS má podporova? typy a triedy? Typ predstavuje množinu objektov s rovnakými charakteristikami a zodpovedá abstraktnému dátovému typu. Obsahuje dve ?asti ? interface a implementáciu.

• Triedy alebo typy v OODBS majú dedi? vlastnosti svojich predkov? táto metóda má výhodu pri modelovaní, pretože dovo?uje dos? verne popísa? vonkajší svet a tiež umož?uje vyvíja? zdie?ané špecifikácie a implementácie. Používané hlavne pri aplikáciách založených na komponentoch. Existujú štyri typy dedi?nosti ? substitution, inclusion, constraint, a specialization.

• OODBS má podporova? prekrývanie, pre?ažovanie a oneskorené pridávanie operácií. Prekrývanie(overriding) znamená, že implementácia je zadefinovaná viackrát v závislosti od typu parametrov. Pre?ažovanie (overloading) znamená, že jej meno potom odkazuje na viac metód s rovnakým názvom.Oneskorené priradenie (late binding) ? znamená, že systém nemôže priradi? mená operácii ich kódom po?as prekladu, ale až za behu programu.

• OODBS má by? výpo?tovo úplný? znamená to to?ko, že sa ?ubovo?ná vypo?ítate?ná funkcia sa dá popísa? použitím DML (Data Manipulation Language).
  DML sa používa na vkladanie, update a mazanie dát v existujúcej dátovej schéme. Je ur?ený na neprocedurálne získavanie ?asti dát spadajúcich pod podmienky vyh?adávania používate?a. DML program je konštruovaný zoznamom sekcií, z ktorej každá hovorí programu, ?o bude vykonáva?.

Príklad DML:

section  ::=              INCREMENTAL DATA TESTING SECTION                                              ENDSECTION            | LOOP TRANSFORMATION SECTION                                               ENDSECTION            | CODE GENERATION SECTION                                               ENDSECTION

• OODBS majú by? rozšírite?né? možnos? rozšírenia preddefinovaných typov programátorom

• OODBS si majú pamäta? svoje dáta? táto vlastnos? je známa zo strany databáz. Nazýva sa tiež perzistencia ? programátorom vytvorené dáta zotrvajú uložené až do vykonania akcie na ich vymazanie alebo update.

• OODBS majú vedie? spravova? ve?mi ve?ké databázy? zah??a správu indexov, clustrovanie, buffer-ovanie, výber prístupových ciest a optimalizáciu dotazov.Tieto mechanizmy sú používate?ovi transparentné ? nemusí sa týmito mechanizmami priamo zapodieva?.

• OODBS majú akceptova? navzájom si konkurujúcich používate?ov? musí zabezpe?i? koexistenciu simultánne pracujúcich používate?ov a každého sa snaži? obslúži? v najkratšom možnom ?ase. Musí podporova? nedelite?né sekvencie operácií ? tranzakcie, a zdie?anie údajov.

• OODBS sa majú vedie? zotavi? po hardwareových a softwareových haváriách? systém sa musí sám vedie? vráti? do konzistentného stavu. Táto vo?ba je v podstate nevyhnutnos?ou pri reálnom nasadení databázy do praxe.

• OODBS majú poskytova? jednoduchý spôsob pristupovania k dátam? ?i už pomocou jednoduchého dotazovacieho jazyka, umož?ujúcemu používate?ovi takéto dotazy zadáva? a prehliada? ich výsledky.

Medzi volite?né vlastnosti o ktorých pojednáva manifest patria:

• Viacnásobná dedi?nos? ? zaradenie tejto možnosti je otázne, pretože ešte nie je jasné stanovisko zo strany komunity zaoberajúcej sa objektovo orientovaným programovaním.

• Kontrola typov a odvodené typy? úrove? kontroly nie je jednozna?ne daná, no ?ím bude vä?šia, tým lepšie, pretože tým menej môže nasta? chýb po?as behu programu.

• Distribuovanos?? taktiež volite?ná vlastnos? a záleží už len na návrhárovi architektúry ?i systém bude sp??a? túto podmienku.

• Návrh tranzakcií? v sú?asnosti nie je návrh tranzakcií uspokojivý, pretože tranzakcie môžu by? príliš dlhé a oby?ajné kritériá serializovate?nosti nemusia posta?ova?.

• Podpora verzií? va?šina systémov v sú?asnej dobe podporuje systém verzií, no v tomto prípade to nie je podmienka.

Otvorené vo?by:

• Štýl programovania? Nie je dôvod uprednost?ova? výhradne jeden štýl programovania - ?i už ide o logické, funkcionálne alebo procedurálne.. pre OODBS môže by? použitý ?ubovo?ný z nich..

• Systém reprezentácií? je definovaný množinou základných typov a množinou konštruktorov. Je možné tieto typy rozširova?.

• Typový systém? v tejto oblasti je úplná sloboda, dôraz sa však prikladá na zapúzdrenie (encapsulation)

• Uniformnos? ? táto vlastnos? je ve?mi diskutovaná ? ide o to, aký stupe? uniformnosti sa má o?akáva? od takýchto systémov. Spor ?i je typ, metóda uniformný objekt, alebo sú to rozdielne veci. Tento problém má tri poh?ady na danú problematiku ? poh?ad z implementa?nej úrovne, problém z h?adiska programovacieho jazyka a problém z h?adiska interface-u. Na implementovanie OODBS potrebujeme komplexný dátový sklad, cache mechanizmus, spracovanie objektovo orientovaného jazyka a metódy na kontrolu celého procesu programátorom.

Výhody OODBS

• Vysoká výkonnos?. Udáva sa 10-1000 násobné zrýchlenie tranzakcií. Je to predovšetkým docielené tým, že systém nemusí robi? preklad medzi dátovými modelmi ? mapovaním tabuliek na objekty a naopak, cache-ovaním a rýchlos?ou navigácie v databáze.

• Komplexnos? dát ? umož?uje existenciu zmiešaných objektov (zoznamov, hierarchických stromových štruktúr, objektovo orientovaného dátového modelu, dynamickú ve?kos? bez limitu, a vysokú škálovate?nos?). Objekty v OODBMS môžu obsahova? nespo?etné množstvo primitívnych typov ako aj iných objektov. Je tiež možné uchováva? ve?kú triedu, obsahujúcu mnoho stredne ve?kých tried, obsahujúcich triedy malé, a takto až do nekone?na. Napriek tomu v rela?ných DB, by to muselo by? uskuto?nené existenciou obrovskej tabu?ky s množstvom NULL polí alebo množstvom menších, normalizovaných tabuliek ktoré sú poprepájané pomocou foreign k?ú?ov. Ma? viac malých tabuliek je problém, pretože zakaždým, ako chceme robi? nejaký dotaz, musí sa vykona? JOIN.

• Znížené náklady a ?as vývoja aplikácií? operácie sú transparentné ? programátor sa nemusí zaobera? ako má systém uložené dáta, jednovrstvový dátový model, at?.. Umož?uje mu koncentrova? sa na podstatnejšie veci.

• Rýchlos? - monitorovanie web prístupov ukázalo, že 1/3 ?asu bola použitá na komunikáciu s prehliada?om, ?alšia tretina na spustenie java programu, a posledná tretina na komunikáciu s databázou. OODB vie eliminova? dve z spomenutých oneskorení, ?o predstavuje faktor zrýchlenia 3. V praxi je to však nejakých 1.5 krát. Ve?kos? tohto zrýchlenia predovšetkým pochádza z cache-ovania. Je taktiež možné pridanie cache-ovania do rela?nej databázy, no problém je vyrovna? sa s implemenáciou cacheovania tranzakcií.

• Rýchlos? na strane jazyka - Týka sa príkazov ako napr. table.getData(row, columnName), ktorý zabezpe?uje nájdenie st?pca.

Nevýhody OODBS

• Vyžaduje od programátora znalos? dát, s ktorými pracuje ? niekedy je prinútený používa? rozhranie k rela?nej databáze na zadávanie ???

• Udržiava poh?ad na dáta z komplexnej strany? bežní ?udia sa k nim môžu dosta? len prostredníctvom programátora, ktorý pozná ako sa k daným uloženým objektom dosta?. Málo ?astá možnos? výpisu dát vo forme tabuliek štýlu Excel, Access.. at?.

• Nie sú tak rozšírené ako rela?né databázy ? ?o vzbudzuje ur?itý stupe? nedôvery v novšiu technológiu oproti technológii zaužívanej.

• Špecifický OODBS môže by? naviazaný na špecifický OO jazyk, ktorý sa programátor musí nau?i?.

?alšie alternatívy:

• Jednou z alternatív je pridanie OO vlastností do rela?nej databázy (Oracle) ? zahr?uje to predovšetkým podporu ukladania objektov, ich identifikátorov a odkazov, hierarchické dotazy a viac komplexné dáta ako sú napr. polia.

• Objektovo-rela?né rozhrania - Tie umož?ujú ukladanie objektov v rela?ných databázach, ich vzájomné mapovanie a konverziu. Kód tohto rozhrania je napísaný programátormi a nachádza sa mimo rela?nú databázu.

Najpoužívanejšie OODBMS:

Komer?né databázy:

• Polyhedra-

?objektovo/rela?ná, riadená pomocou správ, pamä?ovo-rezidentná, perzistentný databázový systém s atraktívnou klient-server architektúrou a 4GL objektovo orientovaným grafickým klientom. Je multiplatformová a zvláda bezchybný chod distribuovaných aplikácií v reálnom ?ase na heterogénnej po?íta?ovej sieti.

Poet, Gemstone, EyeDB ? OODBMS,

• Objectivity/DB

- Komer?ná DB použitá v satelitnom telekomunika?nom systéme Iridium.

• ObjectDB

- objektová databáza na použitie v Java aplikáciách.

Medzi ?alšie patria: Jasmine, Itasca, MetaKit, ConteXt, XDb, Fresher,ObjectStore, Versant, POET/FastObjects, Kodo, Prismtech/OpenFusion..

Vo?ne dostupné objektovo orientované databázy:

• Ozone Java -

ozone je objektovo orientovaný databázový systém kompletne implementovaný v jazyku Java. Podporuje tranzakcie, metódy prístupu a práv k objektom, RMI, multipoužívate?ský prístup, multivláknovos? atd.

• Db4o -

Knižnica jazyka Java malá 60KByteov ponúkajúca rozhranie dovo?ujúca pripoji? Java triedy k dátovým štruktúram ktoré môžu by? uchované na disku.

• Zope

Zope je Objektovo orientovaný databázový systém, ktorý poskytuje perzistenciu a manažment týchto objektov. Má komer?ný komponent s názvom Z Enterprise Objects ? klient-server balík, ktorý s Zope pracuje a pomocou neho môže by? databáza použitá na rôznych Zope clientoch, ktoré sú jeho inštanciami. Komunikujú prostredníctvom TCP/IP.

• Coldstore

Coldstore je sada C++ knižníc umož?ujúcich pripojenie C++ objektov k perzistetným databázam. Základnou myšlienkou je serializácia dát do súborov. Všetko ?o potrebujeme, sú funkcie read a write.

• GOODS-

Goods je plne distribuovaný multiplatformovýOODBMS založený na modelovi klienta s jazykovo nezávislým rozhraním. Databázový server je implementovaný pomocou viacvláknového jadra a poskytuje ve?mi dobrú odozvu na klientské požiadavky. Dostupné sú rozhrania k jazykom C++ a Java.

• Tdb

Funguje na princípe ukladania textových dát a metadát, ktoré sú potom dotazované pomocou query-language.

• ?alšie z databáz sú: StoredObjects, Lincks, Texas Persistent Store Library, MinneStore version2, IronDOC, MetaKit, RubyGOODS, MNESIA, goodmis.org, e4graph, OOFile, Cog ..at?

Príklady použitia OODBS

Na demonštrovanie som použil technolódiu JDO (Java Data Objects), kedže ide o jednu z ?astých používaných alternatív umož?ujúcich rýchly vývoj aplikácií.

JDO

Java Data Objects (JDO) API je štandard, vyvinutý Java Komunitou a firmou Sun Microsystems, ako reakcia na ?Java specification request ?íslo 12?, ktorý obsahuje požiadavku na existenciu objektovo-orientovanej databázovej špecifikácie.

JDO špecifikácia poskytuje definíciu rozhraní dátových skladov a tranzakcií, vo?bu a transformáciu perzistentných dát do natívnych objektov jazyka Java.

Aplikácie napísané v JDO API sú prenosite?né, platformovo nezávislé od rela?nej databázy nad ktorou bežia.

Vytvorenie inštancie PersistentManager-a

Tento manager je základný objekt, ktorý poskytuje manažovanie perzistencie spracovaných dát. Pre jeho vytvorenie je nutné vytvori? inštanciu PersistenceManagerFactory.

PersistenceManagerFactory pmf = ...;

PersistenceManager pm = pmf.getPersistenceManager(); ... p.close();

!!! Nikdy nesmieme zabudnú na zatvorenie tohto manažéra.

Properties p = new Properties();

p.load(new FileInputStream("speedo.properties")); PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory(p);

Inštancia objektu PersistenceManagerFactory by mala osta? globálnou premennou v celom rozsahu perzistentnej aplikácie.

Ako urobi? objekt perzistentným?

Musíme vola? metódu makePersistent na inštancii objektu PersistenceManager.

PersistenceManager pm = pmf.getPersistenceManager();  Address addr = new Address("Seb", "myStreet", "myZip", "myTown", "France"); ... pm.makePersistent(addr);  ...  pm.close();

Vymazanie objektu - metóda deletePersistent

PersistenceManager pm = pmf.getPersistenceManager();

Address addr = ...;  pm.deletePersistent(addr);  ... pm.close();  Príklad spravenia výberu pomocou jeho identifikátora: PersistenceManager pm = pmf.getPersistenceManager();Object oid =  pm.objectIdInstance(Invoice.class, new Integer(54321));  Invoice i = (Invoice) pm.getObjectById(oid, false); ... //use of the 'i' variable  pm.close();  Príklad dotazu na iný objekt.. PersistenceManager pm = pmf.getPersistenceManager() Object oid = pm.objectIdInstance(Address.class, new AddressID("Seb", "myStreet", "myTown"))  Address a = (Address) pm.getObjectById(oid, false) ... //use of the 'a' variable pm.close();

Aby náš dotaz vyhovoval ur?itým kritériám, je použitá metóda setFilter

PersistenceManager pm = pmf.getPersistenceManager();  Query query = pm.getQuery(Address.class);  query.setFilter("(name == myParam)");  query.declareParameters("String myParam");  Collection col = (Collection) query.execute("Seb");  Iterator it = col.iterator();  if (it.hasNext()) {      //there is a result      while(it.hasNext()) {          Address a = (Address) it.next();          ...     }  } else {      //no persistent object found      ... }  query.closeAll(); ... pm.close();

Filter definuje rovnos? medzi polí?kom meno a parametrom myParam. Výsledkom tejto operácie je java.util.Collection z ktorej následnou iteráciou získame požadovaný element.

Je potrebné vždy zatvorenie query pomocou closeAll() metódy.

Získanie rozsahu objektov

PersistenceManager pm = pmf.getPersistenceManager();

Extent extent = pm.getExtent(Address.class, false);  Iterator it = extent.iterator();  while(it.hasNext()) {      Address a = (Address) it.next();          ... } extent.closeAll();  ... pm.close();

Je potrebné vždy zatvorenie query pomocou closeAll() metódy.

Enterprise Java Beans Query Language

Enterprise JavaBeans (EJB) technológia je komponentová architektúra na strane servera pre Java2EE platformu. EJB ponúka rýchly a zjednodušený vývoj distribuovaných, tranzak?ných, bezpe?ných a prenosite?ných aplikácií na báze Java technológie.

Pre ukladanie a perzistenciu EJB beansov je použitá perzistencia na strane kontajnera (Container Managed Persistence), kde celý tento bean môže by? perzistentný ako v objektovej, tak v rela?nej databáze. Spomínam ho preto, lebo jeho jazyk ? EJB QL umož?uje ve?mi dobrú a efektívnu prácu s perzistentnými objektmi.

Jednoduché príklady EJB-QL dotazov:

SELECT OBJECT(p) FROM Player p  

Prijaté dáta: Zoznam všetkých hrá?ov

SELECT DISTINCT OBJECT(p) FROM Player p WHERE p.position = ?1

Prijaté dáta: hrá?i sp??ajúci podmienku vo finder metóde

SELECT DISTINCT OBJECT(p) FROM Player p WHERE p.position = ?1 AND p.name = ?2

Prijaté dáta: Hrá?i s danou pozíciou a daným menom

EJB QL výraz vie prechádza? cez pridružené triedy, ako v tomto prípade trieda teams:

SELECT DISTINCT OBJECT(p) FROM Player p, IN (p.teams) AS t WHERE t.city = ?1

Použitie rozsahu na výber objektov:

SELECT DISTINCT OBJECT(p)

FROM Player p WHERE p.salary BETWEEN ?1 AND ?2  

SELECT DISTINCT OBJECT(p1)  FROM Player p1, Player p2 WHERE p1.salary > p2.salary AND p2.name = ?1  SELECT DISTINCT t.league  FROM Player p, IN (p.teams) AS t WHERE p = ?1

Záver

Dozvedeli sme sa o použití, výhodách a nevýhodách Objektovo orientovaných databázových systémov. Je však len na nás, ?i sa prikloníme k ich používaniu alebo zostaneme pri zaužívaných rela?ných databázach. Dá sa však poveda?, že OODBS majú va?šie množstvo výhod oproti rela?ným databázam, a preto ich použitie by som odporu?il hlavne pri rozsiahlejších projektoch.

Zdroje:

http://www.25hoursaday.com/WhyArentYouUsingAnOODBMS.html

http://speedo.objectweb.org/doc/jdotutorial.html

http://www.idi.ntnu.no/grupper/su/courses/dif8901/presentation2003/d3.ppt

http://cbbrowne.com/info/oodbms.html

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBQL4.html#73277