I objektorientering er det mange elementer som inngår og et av problemene er mangelen på et formelt fundament. Det finnes ingen omforent og formell mo

Objektorienterte databaser Trond Aalberg 1 Introduksjon Dette essayet tar for seg objektorienterte databaser. Innledningsvis gies en beskrivelse av objektorientering generelt (kap. 2), og deretter diskuteres sentrale aspekter ved objektorienterte databaser med basis i pensumartiklene [8, 5, 1] (kap. 3). I kap. 4 beskrives ODMG som er en standard for objektorienterte databaser. Et annet relevant område er utviklingen mot mer objektorientering i relasjonsdatabaser og dette er kort oppsummert i kap. 5. Avslutningsvis i dette essayet diskuteres noen egne erfaringer i bruk av objektorienterte databaser med fokus på den nære koblingen mellom datalagring og programmeringsspråk (kap. 6). 2 Objektorientering Objektorientering slik vi kjenner det i informasjonsteknologien i dag, har sitt opphav i objektorientert programmering. Simula-67 er generelt ansett som det f rste objektorienterte programmeringsspråket. Etter dette har forskning i og utvikling av objektorientert programmeringsspråk fulgt to veier enten som utvikling av nye objektorienterte programmeringsspråk som Smalltalk, eller som objektorienterte utvidelser til eksisterende programmeringsspråk, f.eks. objective C og C++, eller objektorienterte varianter av Lisp som Flavors og LOOPS [6]. Objektorientering har vist seg å være en attraktiv abstraksjons og gjenbruksmekanisme og objektorientering er etterhvert overf rt til en rekke andre områder eksempelvis design og modellering, databaser og distribuerte systemer. Kort beskrevet innebærer objektorientering at data og funksjonalitet samles i objekter som representerer (mer eller mindre) naturlige abstraksjonsenheter. Et objekt er en innkapslet enhet med operasjoner som det synlige grensesnittet mens implementeringen eller realiseringen av objektets datastruktur og metoder er skjult. Enkelte skiller mellom objektbaserte systemer som kun er basert på bruken av klasser og objekter (instanser av klassene), og objektorienterte systemer som indikerer egenskaper som arv og polymorfi for å st tte gjenbruk og utvidbarhet. 1

I objektorientering er det mange elementer som inngår og et av problemene er mangelen på et formelt fundament. Det finnes ingen omforent og formell modell for objektorientering som definerer det eksakte kravet til egenskaper som skal til for at noe kan karakteriseres som objekt, og dette f rer til at den underliggende modellen for objektorientering varierer mellom forskjellige programmeringsspråk, eller mellom objektorientert i modellering, programmeringsspråk og database. De sentrale trekkene ved objektorientering er likevel rimelig omforent selv om den faktiske modellen som ligger i bunnen av en spesifikk bruk av objektorientering vil variere både med hensyn til hvilke objektorienterte egenskaper som st ttes og hvordan disse st ttes. De mest sentrale egenskaper i objektorientering er: Innkapsling som er det å samle relatert funksjonalitet og data i en avgrenset enhet med identitet. Innkapsling impliserer også former for skjuling (hiding) ved at data og implementasjoner kun er synlig eller aksesserbart gjennom et veldefinert grensesnitt. Forskjellige former for innkapsling forekommer f.eks. med hensyn til om attributter skal kunne aksesseres direkte, kun via objektets operasjoner eller om dette skal være et brukerdefinert valg. Klasser og instanser er skillet mellom typer av objekter og den enkelte konkrete objekt. En klasse kan defineres som fellestrekkene til en gruppe av objekter med samme egenskaper, operasjoner, relasjoner og semantikk, mens en instans er konkret objekt ihht. til denne klassen. Enkelte skiller mellom klasse og type [1] hvor type er en beskrivelse av felles karakteristika for et sett av objekter, f.eks. tilsvarende interface definisjoner i Java, abstrakte klasser i C++ eller interface-definisjoner i OMG's IDL. I relasjon til type er klasse noe av det samme, men en klasse er da mer et run-time relatert konsept som også inkluderer en implementering og mekanisme for å instansiere objekter. Arv er deling eller gjenbruk av operasjoner og attributter mellom klasser basert på hierarkiske relasjoner mellom klassene. Arv kan st ttes på forskjellige måter og det st rste skillet går mellom hvorvidt det er mulig å arve fra flere superklasser eller om en klasse kun kan arve fra en superklasse. Arv er også en måte å st tte utvidbarhet på, ved at nye klasser kan arve allerede eksisterende attributter og metoder og kun legge til nye attributter eller metoder. Polymorfi er at samme operasjon/metode kan ha forskjellig implementasjon og oppf rsel i forskjellige klasser. Ved å redefinering en generell operasjon i en subklasse kan ny oppf rsel tilpasset den arvede klassen implementeres (overriding). Polymorfi er en viktig teknikk i objekt- 2

orientering fordi det st tter opp under objektorientering som abstraksjonsmekanisme. Vi kan definere generell funksjonalitet (operasjoner) som deles av klassene, men som under overflaten er implementert forskjellig. Polymorfi er også viktig i forhold til gjenbruk og fleksibilitet fordi det muliggj r at oppf rsel som allerede er definert i klassehierarkiet kan reimplementeres hvis det er behov for annen oppf rsel. 3 Objektorienterte databaser Objektorienterte databaser vokste frem som en egen retning i databaseverdenen i l pet av siste halvdel av 1980-tallet. Motivasjon for denne utviklingen er flerdelt, men elementer som har drevet fram denne kan være at: I l pet av 1980-tallet ble man klar over en rekke begrensinger ved relasjonsdatabasene, f.eks. med hensyn til komplekse datastrukturer og behovet for å lagre tekst og multimedia dokumenter o.l. En objektorientert tilnærming var da en alternativ måte for å finne l sninger på dette. En generell utvikling mot objektorientering som også smittet over til databasesystemer. Objektorientering hadde mange fordeler i forhold til prosedurale programmeringsspråk noe som kunne indikere at en objektorientering for databaser hadde tilsvarende fordeler i forhold til relasjonsdatabaser. Behovet for å ha en nær korrespondanse mellom databasen og den virkelige verden, basert på den oppfatningen at en objektorientert modell er nærmere den menneskelige oppfatning av virkeligheten enn f.eks. en relasjonsmodell for data. Behovet for integrering med objektorienterte programmeringsspråk. I The Objekt-Oriented Database System Manifesto karakteriseres den f rste utvikling av objektorienterte databaser som preget av eksperimentell virksomhet og en mangel på en felles datamodell og formelt fundament [1]. Dette er kanskje karakteristisk for situasjonen også for årene etter at denne artikkel ble publisert (i 1990), selv om det riktignok har kommet standarder på dette området (f.eks. ODMG). Krav til hva systemer må st tte for å kunne karakteriseres som objektorienterte databasesystemer (OODBMS) er i henhold til The Objekt-Oriented Database System Manifesto f lgende: St tte for komplekse objekter som lister, set og arrays. St tte for objektidentitet ved at objekter har identitet uavhengig av verdien(e) objektet inneholder. 3

St tte for innkapsling som her indikerer to forhold hvor det ene går på separering mellom objektets spesifikasjon (grensesnitt) og implementeringen av objektet. Det andre forholdet gjelder modularitet og artikkelen presiserer at for objektorienterte databaser b r både data og operasjoner lagres i databasen. St tte for typer og/eller klasser og st tte for ekstensjoner (noe som vil si at databasen skal kunne vedlikeholde settet av alle instanser av en klasse/type i databasen). St tte for arv, men det er ikke et krav at systemet skal st tte arv fra multiple superklasser. St tte for polymorfisme i form av overriding, overloading og sen binding. Systemet skal være komputasjonelt komplett, noe som krever at et objektorientert databasesystem må st tte programmering enten via et etablert programmeringsspråk eller et egendefinert data manipuleringsspråk (DML). I tillegg til predefinerte datatyper må databasesystemet være utvidbart og st tte brukerdefinerte datatyper. Andre krav som er relatert til at en objektorientert database skal håndtere data er behovet for at data skal være persistente utover levetiden til en prosess et transparent lagringssystem som har de egenskapenes som kreves mht. indeksering, buffring, query optimalisering mm. samtidighet recovery tjeneste for sp rring som kan være ad hoc Det er også en rekke andre karakteristikker som er relevante for objektorienterte databaser. Enkelte av disse er valgfrie tilleggsegenskaper som st tte for multippel arv, distribuering, design transaksjoner og objektversjoner. Andre egenskaper som må implementeres er ikke sentrale for hvorvidt dette er en OODBMS eller ikke, men måten dette implementeres på overlates til databaseleverand r, f.eks. valg av programmerings paradigme og syntaks. Ibåde [8], [5] og [6] finner vi også diskusjoner rundt hva som b r være fundamentet for objektorienterte databaser, med varierende grad av uavhengighet i forhold til relasjonsmodell eller andre etablerte databasekonvensjoner. Viktig å fremheve er blant annet behovet for å st tte relasjoner mellom objekter som poengtert i [8]. 4

4 Standardisering av OODBMS (The Object Data Standard) The Object Data Management Group (ODMG) ble etablert i 1991 med det formål å utvikle standardiserte spesifikasjoner for integrering av objektorienterte databaser og objektorientert programmering. ODMG er en sammenslutning av en rekke akt rer både leverand rer av objektorienterte databaser og akademiske institusjoner som har utviklet The Object Data Standard som i 2000 ble utgitt i versjon 3.0 [3, 4]. ODMG's fokus er på portabilitet og integrering. Med portabilitet menes her at samme programvare skal kunne brukes mot flere databaseprodukter ved hjelp av standardiserte data skjema, bindinger til programmeringsspråk, data manipulering og query språk. Med integrering menes en bedre integrering mellom programmeringsspråket (fortrinnsvis objektorienterte) og databasen. ODMG adresserer ikke kun objektorienterte databaser men bruker den mer generelle kategorien ODMS (Object Data Management Systems) for å favne både ODBMS (Object Database Management Systems) og ODM (Object-to-Database Mappings). Sistnevnte kategori er produkter som oversetter objekter til andre lagringsmodeller f.eks. relasjonsdatabaser eller andre systemer. Felles for disse er at de integrerer databaseegenskaper med objektorienterte programmeringsspråk, uten bruk av en database som n yaktig gjenspeiler objektmodellen i programmet. Selve ODMG standarden består av flere komponenter; en objekt modell, objektspesifiksasjons språk for å definere objekter og for å dumpe og laste objektenes tilstand mellom database og fil, et sp rrespråk (OQL) samt bindinger til programmeringsspråkene C++, Java og Smalltalk. ODMG spesifikasjonen definerer ikke et DML/OML (data/object manipulation language) av den enkle grunn at dette blir ivaretatt av programmeringsspråkene. Dette kan sees som en skritt videre i forhold til f.eks. bruken av SQL for å endre/oppdatere databasen, ved at ODMG i stedet er basert på en felles underliggende objekt modell som gjenspeiles i bindingene til de forskjellige programmeringsspråkene. Dette burde i prinsippet si at et DML er overfl dig. 4.1 Objekt modellen ODMG's objektmodell er modellen som både objekt definisjons språket og sp rrespråket er basert på, og som utgj r en standard objektmodell for objektorienterte databaser. Objektmodellen skiller mellom objekter og literals hvor en literal er en enkeltverdi av en basis datatype. Et objekt har en unik identitet i systemet (objekt-id), og kan i tillegg ha et navn som et program kan benytte for å aksessere objektet. Navn fungerer også som aksess punkt i databasen ved at et objekter kan hentes fram via 5

dets navn og benyttes som startpunkt for å navigere til andre objekter via referanser fra det navngitte objektet. Livstiden til objekter kan enten være begrenset til prosessens levetid (et transient objekt) eller objektet kan overleve prosessens levetid ved at det er et persistent databaseobjekt. Objekter har struktur og kan være samlinger (collection objekter). Et atomisk objekt er et objekt som ikke er en samling men dette er ikke det samme som at objektet kun representerer en enkeltverdi. Brukerdefinerte objekter er mer eller mindre synonymt med atomiske objekter i denne modellen. Samlinger i ODMG er predefinerte konstruksjoner for set, bag, list, array og dictionary som kan inneholde objekter, både andre samlinger og atomiske, men alle objekter i en samling må være av samme type. Atomiske objekter er de objektene som brukerne definerer og de fleste av disse vil være strukturerte objekter som består av et sett egenskaper og operasjoner. Egenskaper er trad. attributter, men kan også være brukerdefinerte relasjoner. I ODMG defineres relasjoner som en egen type egenskap et objekt kan ha. ODMG's objektmodell skiller også mellom interface og klasse. Interface er en typemekanisme for å definere operasjoner til en objekttype som ikke kan instansieres. En klasse er derimot en type som definerer både operasjoner og egenskaper og kan instansieres. Dette gir også opphav til to typer arv. Behaviour er en type arv som kan være mellom grensesnitt eller mellom et grensesnitt som supertype og klasse som subtype. EXTENDS er en annen type arv hvor både operasjoner og attributter arves og både supertype og subtype må da være en klasse. For en klasse er det også mulig å definere en navngitt ekstensjon (extent) for klassen, som i realiteten er et sett-objekt som automatisk vil inneholde alle instansierte objekter av denne klassen. For en klasse med extent er det også mulig å definere et n kkelattributt basert på en eller flere attributter og/eller relasjoner. ODMG's objektmodell legger også en del andre f ringer f.eks. hvordan et databasesystem logisk skal fremstå for brukerne samt f ringer på kontroll av samtidighet ved å definere en lås-mekanisme og transaksjonshåndtering. 4.2 Objekt spesifikasjons språkene ODL og OIF ODMG definerer to objektspesifikasjons språk. Objekt Definition Language (ODL) er en syntaks for å spesifisere objekt-typer som er konforme med ODMG's objekt modell. Dette språket kan f.eks. brukes til å definere databaseskjema som er portable mellom databasesystemer som st tter ODMG standarden. Syntaksen i ODL er til en hvis grad kompatibel med OMG's Interface Definition Language (IDL) ved at ODL er en utvidelse av IDL. ODL er ikke proseduralt, men et programmeringsspråk-uavhengig og deklerativt språk tilsvarende et DDL (data definition language). Intensjonen er at ODL skal kunne brukes for å spesifisere objektstrukturen til en 6

database og fungere som en lingua franca for integrering. En ODL spesifikasjon kan realiseres ved hjelp av programmeringspråk som C++, Java og Smalltalk. I motsetning til ODL er OIF (Object Interchange Format) et språk/syntaks for å spesifisere instanser ved dumping og lasting av objekter mellom database og fil(er). Informasjon relevant for å beskrive tilstanden til et objekt er; objekt identifikator, type binding, attributt verdier og lenker til andre objekter. 4.3 Object query språket OQL er ODMG's sp rrespråk for objektorienterte databaser basert på ODMG's objektmodell. OQL har en syntaks som er nær SQL, men med utvidelser som st tter komplekse objekter, objekt identitet, sti-uttrykk og operasjonskall. Tilsvarende som for SQL er OQL heller ikke komputasjonelt komplett, men kun et sp rrespråk. I kontrast til SQL innholder ikke OQL operatorer for å oppdatere objekter, men baserer seg i stedet på objektenes operasjoner til dette formålet. 4.4 Bindinger til forskjellige språk ODMG definerer ikke et eget objekt manipulerings språk, men baserer seg på at objekter skal implementeres via tradisjonelle programmeringsspråk og manipuleres i applikasjoner skrevet i disse språkene. ODMG har spesifisert hvordan objektmodellen og ODL skal mappes til programmeringspråkene C++, Java og Smalltalk og i tillegg definert en syntaks for aksess til objekter og manipulering av objekter (basert på programmeringsspråkenes egen syntaks). Sammen med et sett av objekter og operasjoner for å håndtere databasesesjoner, transaksjoner og andre elementer utgj r dette et API hvor et programbibliotek (eller pakke for Java) er brukernes grensesnitt mot objektbasen. 4.5 Reell bruk av ODMG 3.0 I hvor stor grad ODMG har lykkes i å lage en standard som objektdatabase leverand rer er villige til å f lge er diskutabelt. En rekke leverand rer av objektorienterte databaser og objekt-relasjons mapping produkter st tter ODMG standarden [2], men graden av st tte varierer. OQL og ODL er generelt dårligere st ttet enn C++ og Java bindingene. 5 OORDBMS Objektorienterte databaser og relasjonsdatabaser reprepresenterer to forskjellige retninger med hensyn til datamodell. I realiteten er det kanskje 7

riktigere å se disse to forskjellige retningene i lys av andre aspekter. Behovet for nye egenskaper i forhold til dataorganisering og datarepresentasjon er også anerkjent i den relasjonsorienterte databasetradisjonen, men det er mer måten dette skal implementeres som er hovedelementet i diskusjonene om objektorienterte database kontra databaser som er tuftet på relasjonsmodellen. I Third-Generation Database System Manifesto [7] fra 1990 presenteres tre læresetninger for den videre utvikling mot neste generasjons databaser (tredje generasjons databaser) og en rekke konkrete forslag hvordan presserende behov best skal adresseres. Enkelte av disse er direkte tilsvar på forslag som ble promotert av objektorienterte database entusiaster, andre er mer konkrete forslag til den videre utvikling av relasjonsdatabaser: St tte for rikere objektstrukturer og regler i tillegg til tradisjonelle data behandlingstjenester. Det er behov å st tte rikere typesystemer, både via et sett av collection-typer, og muligheten for å deklarere nye brukerdefinerte typer m.m. Det er også behov for å st tte former for arv og ha muligheten for prosedyrer og metoder på databasesiden kombinert med muligheten for innkapsling. På databasesiden b r det også være mulig å definere triggere og regler som kan kontrollere constraints som applikasjonsuavhengig funksjonalitet. Tredje generasjons databaser må bygge videre på andre generasjons relasjonsdatabaser Dette impliserer å bygge videre på bruk av et h ynivå og ikkeproseduralt språk for aksess til data (SQL). Tredje generasjons databaser må være åpne for andre systemer Databasen må være tilgjengelig fra flere h ynivå språk og persistens for f.eks. objekter skal st ttes som del av runtime milj et eller ved kompilering. SQL er i kommet for å bli og b r fortsatt være aksess-språket til databaser. Spesielt viktig er SQL i et distribuert milj hvor quieries og resultatsvar er den mest egnede kommunikasjonsmekanismen mellom klienter og databasetjenere. Third-Generation Database System Manifesto er i stor grad basert på det synet at det er en naturlig utvikling fra andre generasjons databaser (relasjonsdatabaser) til å st tte egenskaper det er enighet om i begge leirer. Dette inkluderer egenskaper som rikere typesystem, funksjoner, arv og innkapsling. Den rene objektorienterte databasen som bygger på en objektorientert modell vurderes som for smal og ensidig fokusert på objekt håndtering. Det andre sentrale standpunktet er datauavhengighet og at data kun skal 8

aksesseres gjennom et sp rrespråk. Siden det ikke finnes noe programmeringsspråk ekvivalent til esperanto, er det mest naturlig å bygge videre på SQL. Artikkelen kan sees som en introduksjon til den utviklingen i databaseteknologi som ofte blir kalt objektorienterte relasjonsdatabaser (OORDBMS). I l pet av 1990-tallet har slike systemer blitt utviklet via proprietære l sninger som Informix Universal Server og deres Datablade teknologi, men det har også pågått et standardiseringsarbeid for neste generasjon av SQL (SQL3) som inkluderer egenskaper i tråd med flere av forslagene som ble diskutert i Third-Generation Database System Manifesto. 5.1 SQL3 SQL er et h ynivå deklerativt språk for relasjonsdatabaser som har i sin tidligste utgave ble utviklet av IBM. SQL er etter hvert blitt fellespråket for relasjonsdatabaser og ble ANSI og ISO standardisert i 1986. En revidert utgave av SQL (ofte kalt SQL2) kom i 1992 og i 1999 kom en ny versjon av standarden som også introduserte en rekke objekt inspirerte elementer 1. I hovedsak er de objektorienterte elementene i SQL3 introdusert ved utvidelser til TYPE og TABLE primitivene. Kortversjonen av objektorientering i SQL3 kan oppsummeres med: St tte for komplekse objekter ved at SQL3 muliggj r brukerdefinerte abstrakte datatype og en array-lignende type, samt at SQL3 spesifiserer datatyper for store dataobjekter enten binærdata eller for tekstdata. En rekke uttrykk er lagt til SQL3 for å gi mulighet for å spesifisere prosedural kode slik at SQL3 st tter deklarering av metode implementasjoner. Brukerdefinerte typer kan innkapsle data og operasjoner tilsvarende en klassedefinisjon. Arv kan benyttes både mellom brukerdefinerte typer og mellom tabeller. 6 Erfaringer fra bruk av objektorienterte databaser Erfaringer i bruk av objektorienterte databaser er hentet fra diverse prototyper for digitale bibliotek systemer det har vært jobbet med i gruppen for Informasjonsforvaltning ved IDI, NTNU. Erfaringene er basert på bruk av to forskjellige objektorienterte databaser: 1 Informasjon om SQL3 er i stor grad hentet fra [4] og fra diverse str -informasjon som er funnet på nettet. 9

O 2 som er en objektorientert database mye referert til i akademisk sammenheng siden dette var en av de f rste ODMG konforme databaser. Denne st tter både ODMG C++, Java og Smalltalk bindinger samt OQL 2. Versant som er en objektorientert database med st tte for ODMG C++ og Java bindinger, men som benytter et proprietært sp rrespråk. Årsaken til at objektorienterte databaser er valgt i disse prototypene er behovet for å gj re objektene i applikasjonene persistente på en enklest mulig måte. Databasene har vært brukt i forbindelse med lagring og manipulering av XML-baserte strukturer hvor konvertering mellom en relasjonsmodell og applikasjonenes objektmodell blir tungvint og krevende. Et annet eksempel på vår anvendelse persistents for CORBA objekter. Felles for disse protoypene er at det har vært et behov for en nær kobling mellom datalagring og programmeringsspråk, og det er dette aspektet som er fokus for denne diskusjonen. 6.1 Komplekse objekter Objektorienterte databaser har i disse prototypene vist seg å være relevant l sninger for komplekse objekter. Databasene har vært brukt til å lagre bla. hierarkiske trestrukturer som representerer XML-dokumenters elementstruktur, og det å kunne lagre eller aksessere disse objektstrukturene direkte uten å transformere frem og tilbake mellom applikasjonens objekter og en relasjonsdatabase har vært en fordel både mht. enklere kode og effektivitet. En annen viktig egenskap i denne sammenhengen har vært muligheten til å kunne navigere enkelt og effektivt i slike trestrukturen, noe som ville vært mer komplisert og antagelig vesentlig tidkrevende med en relasjonsdatabase i bunnen. 6.2 Bruk av eksterne bibliotek Datadefinering for begge disse databasene f lger samme m nster ved at objektstrukturen defineres som klassedefinisjoner i programmeringsspråket. Begge databasene er basert på at klassedefinisjonene endres for å tilf res kode som binder klassene til databasen. For C++ gj res dette ved å preprossesere klassedefinisjonene f r kompilering, mens for Java gj res dette ved å prosessere byte-koden som er generert. For enkle applikasjoner medf rer ikke dette problemer, men for mer komplekse applikasjoner som er basert på eksterne pakker eller biblioteker fra ytterligere leverand rer har dette ofte medf rt problemer. 2 Etter å ha vandret fra eier til eier i en periode besluttet siste leverand ren av denne databasen å ta den vekk fra markedet pga. manglende salg. 10

For java baserte applikasjoner (og bruk av Versant OODBMS) har det vist seg at når brukerdefinerte klasser som skal være persistente arver fra andre klasser, kreves det at også superklassene prosesseres og endres. Dette betyr at hvis f.eks. en implementasjon av et CORBA objekt skal være persistent så kreves det at hele hierarkiet som denne implementasjonen arver fra også må prosesseres og evt. gj res persistent. For å implementere persistente CORBA objekter har det derfor vært behov for å definere egne persistente objekter som data hentes fra og lagres til, noe som i prinsippet like gjerne kunne vært l st med en relasjonsdatabase. Et tilsvarende problem oppstod ved bruk av C++ og databasen O 2. Egendefinerte klasser som arver fra klasser definert i andre bibliotek kan i dette tilfellet enkelt gj res persistente, men attributtene som arves er ikke persistente. Dette gj r at bare deler av objektet er persistent, noe som selvsagt resulterer i at objektet reinstansierers med feil tilstand. Begge eksemplene over viser at en tett integrering mellom programmeringsspråk kan introdusere uhåndterlige problemer hvor man må implementere en l sning hvor data og applikasjonsobjekt er separert. 6.3 Skjema endringer Spesielt i en prototyp situasjon vil klassedefinisjoner endres ofte. Begge disse databasene st tter visse endringer i klassedefinisjonene, med påf lgende automatisk sletting eller endringer i databasen. Det har likevel vist seg i mange tilfeller at endringer som gj res i klassedefinisjonene f rer til inkompatibilitet mellom database og klassedefinisjon. På grunn av avhengigheten mellom database og programmeringsspråk har det da vært vanskelig å gjenbruke data i de endrede klassene, med det resultat at hele databasen må gjennoppbygges. Dette er kanskje et problem som er spesifikt knyttet til prototyping, men det indikerer likevel at h y grad av avhengighet mellom applikasjonsobjekter og datalager kan være problematisk. 6.4 Transaksjoner En av de erfaringen vi generelt har gjort med objektorienterte databaser er at persistens sjeldent er transparent. Mye av problematikken i dette er knyttet til transaksjoner. Begge databasene som har vært i bruk er basert på bruk av en objektbuffer for å forhindre at database ikke aksesseres for hvert eneste kall som gj res i applikasjonen. Databasen oppdateres med objektenes endringer når applikasjonen gj r en commit. I hovedsak kan to forskjellige commit-metoder kalles; en vanlig commit forårsaker at alle objektene i bufferen slettes noe som gj r at alle objektreferanser til persistente objekter blir ugyldige en retain variant som ikke sletter objektene i bufferen 11

Begge disse variantene har sine ulemper. Hvis objektene slettes må applikasjonen oppdatere referanser til persistenete objekter og hvis objektene ikke slettes vil objektene oppta plass i minnet siden det er ved commit at minne i objektbufferet frigj res. For å få samtidige applikasjonen til å fungere effektivt i forhold til databasen har det derfor vært behov for å n ye designe transaksjonerm nsteret til applikasjonen for å unngå ugyldige referanser på den ene siden og et overforbruk av minne 3. Spesielt vanskelig har dette vært kombinert med flertrådede implementasjoner. Dette forholdet gj r at persistens i liten grad er er en transparent egenskap. Det at persistens er så tett integrert med applikasjonen blir problematisk bla. fordi det er vanskelig å forutsi sekvensen av programmets utf relse, og dermed hvor det er naturlig å gj re en commit. En generell konklusjon på dette er at de fordeler en transparent persistens av applikasjonsobjekter gir i f rste omgang, fort kan oppveies av merarbeid og kompleksitet på andre områder 6.5 Konklusjon I avsnittene over er det presentert en del erfaringene fra bruk av objektorienterte databaser som i stor grad er negative og en generell konklusjon er at den tette koblingen mellom database og programmeringsspråk ikke er uten problemer. På en del andre områder har det vist seg at objektorienterte database har fordeler. Generelt er disse erfaringene alt for usystematiske og begrensede til noen endelig konklusjon, men de kan kanskje være en indikasjon på at man b r ha et pragmatisk forhold til valg av databaseteknologi. Både relasjonsdatabaser og objektorienterte databaser har sine fordeler og ulemper. For applikasjoner med komplekse og rekursive datastrukturer og behov for effektiv navigering som f.eks. i objektmodeller for XML vil objektorienterte databaser være en fordel, men denne fordelen kan fort utjevnes når det er behov for mer kontroll over interaksjonen med databasen og transaksjonene. Referanser [1] Malcolm Atkinson, François Bancilhon, David dewitt, Klaus Dittrich, David Maier, and Stanley Zdonik. The object-oriented database system manifesto. In Won Kim, Jean-Marie Nicolas, and Shojiro Nishio, editors, Deductive and Object-Oriented Databases, Proceedings of the First International Conference on Deductive and Object-Oriented Databases (DOOD'89), Kyoto Research Park, Kyoto, Japan, 4-6 December 1989. North-Holland/Elsevier Science Publishers. ISBN 0-444-88433-5. 3 Dette problemet er muligens spesifikt for Java som i utgangspunktet har et h yt minneforbruk. 12

[2] Inc. Barry & Associates. Odmg compliance from the object storage fact books. http://www.barryandassociates.com/odmg-compliance.html. [3] R. G. G. Cattell and Douglas K. Barry, editors. The Object Data Standard : ODMG 3.0. Morgan Kaufmann Publishers, 2000. [4] Ramez Elmasri and Shamkant B. Navathe. Fundamentals of Database Systems. Benjamin/Cummings publishing Company, 2000. [5] Won Kim. Object-oriented databases: Definitions and research directions. IEEE Transactions on Knowledge and Data Engineering, September 1990. [6] Won Kim. Research directions in object-oriented database systems. In Proceedings of the ninth ACM SIGACT-SIGMOD-SIGART symposium on Principles of database systems, Nashville, TN USA, April 2-4 1990. ACM, ACM. [7] Michael Stonebraker, Lawrence A. Rowe, Bruce Lindsay, James Gray, Michael Carey, Michael Brodie, Philip Bernstein, and David Beech. Thirdgeneration database manifesto. ACM SIGMOD Record, 19(3), September 1990. [8] Stanley B. Zdonik and David Maier, editors. Readings in Object-Oriented Database Systems. The Morgan Kaufmann Series in Data Management. Systems Morgan Kaufmann Publishers Inc, San Mateo, CA, 1990. ISBN 1-55860-000-0, ISSN 1046-1698. 13