Det här är ett avsnitt i en webbkurs om databaser som finns fritt tillgänglig på adressen http://www.databasteknik.se/webbkursen/. Senaste ändring: 18 juli 2005.

Av Thomas Padron-McCarthy. Copyright, alla rättigheter reserverade, osv. Skicka gärna kommentarer till webbkursen@databasteknik.se.

Objektdatabaser

I en databas kan man använda olika datamodeller, dvs olika sätt att beskriva världen, och därigenom olika sätt att organisera databasens data. Olika databashanterare använder olika datamodeller, men den vanligaste idag är relationsmodellen som går ut på att man beskriver världen med hjälp av tabeller.

Men det är också populärt med olika objektorienterade datamodeller, och det ska vi kort beskriva i det här kapitlet.

Databaser som arbetar med en objektorienterad datamodell brukar delas in i två kategorier:

Jag använder här termen objektdatabaser som ett samlingsnamn för objektorienterade och objekt-relationella databaser.

Objektorientering

Objektorienterad datamodellering och programmering handlar om klasser, objekt, attribut och metoder. Objekten motsvarar saker i verkligheten, och klasserna motsvarar typer av saker. Klasserna finns i schemat, och objekten är data. Klasserna påminner mycket om entitetstyper i ER-modellen, och precis som i den utvidgade ER-modellen (EER-modellen) kan en klass ärva egenskaper (attribut) från en annan klass. En sak som tillkommer jämfört med EER-modellen är att i en i en objektorienterad datamodell brukar man även ha med beteende, dvs klasserna har inte bara attribut utan också procedurer eller funktioner (metoder). Även metoderna kan ärvas.

Till skillnad från relationsmodellen, där en rad i en tabell bara kan identifieras med hjälp av de data den innehåller, har varje objekt i en objektorienterad databas en unik objektidentitet, en OID. Man kan referera till ett visst objekt med dess OID, och behöver inte upprepa värdet på en nyckel som med relationsmodellens referensattribut. Ett objekt kan motsvara en post som innehåller data om en sak i verkligheten, men det kan också vara en mängd andra objekt, en lista, osv.

Problem med relationsdatabaser

En traditionell relationsdatabashanterare är optimerad för många och enkla data, som det utförs många och enkla transaktioner på. Typexemplet är en bank, med miljoner bankkonton (som bara består av några numeriska värden på en rad), och som man gör miljoner insättningar och uttag på (som bara är enkla adderingar eller subtraktioner). Det går inte att definiera nya datatyper eller datatypsspecifika operationer.

Traditionella relationsdatabashanterare kan därför vara olämpliga för tillämpningar som har komplicerade data och som utför komplicerade transaktioner på dem. Exempel är CAD-system, multimediasystem och en del telekomtillämpningar.

Ett problem vid lagring i relationsdatabas är så kallad impedance mismatch, som betyder att applikationen och databasen använder olika datamodeller, som man måste översätta fram och tillbaka mellan. Tänk dig till exempel ett komplicerat C++-program, som arbetar med komplicerade datastrukturer med objekt som innehåller pekare till varandra. Programmets data går att översätta till tabeller. Till exempel kanske man får skapa en nyckel för varje objekt, och sen göra om alla pekare till referensattribut som refererar till den nyckeln. Men det vore bra mycket lättare (och snabbare, både när man skriver programmet och när man kör det) om man kunde spara ner C++-objekten direkt i en databas.

Ett annat problem är att man kan få dåliga prestanda för vissa tillämpningar. Att bara följa en pekare i C++ går extremt fort (nanosekunder), medan en uppslagning via ett index i en typisk diskbaserad relationsdatabashanterare med klient/server-arkitektur tar åtminstone 10-20 millisekunder.

Objektorienterade databaser

Objektorienterade, eller "första generationens objektorienterade", databaser är tänkta som en lösning på problemen ovan med relationsdatabaser för vissa tillämpningar. Som vi nämnde ovan kan man tänka sig en objektorienterad databas som ett objektorienterat programmeringsspråk där man lagt till databasfunktionalitet. Man skriver sitt C++-program ungefär som vanligt, men i stället för att alla objekten försvinner när programmet avslutas, så sparas de undan och finns tillgängliga nästa gång programmet startas.

En vanlig arkitektur för sådana här objektorienterade databashanterare är att objekten finns i processens adressrymd, precis som vanliga objekt i C++, men databashanteraren ser till att spara dem på disk, och läsa in dem igen. Då får man höga prestanda. Normalt sparas inte alla objekt, utan programmeraren anger vilka som ska sparas. Det kan ske per objekt, per klass, eller på så sätt att alla objekt som är nåbara genom att följa pekare från något persistent objekt sparas.

Stödet för vissa operationer som man kanske vant sig vid om man arbetat med relationsdatabaser, till exempel möjligheterna att ändra i schemat eller att ställa deklarativa frågor, är ofta sämre än i relationsdatabaser.

Ett exempel på en objektorienterad databas är ObjectStore.

Objektrelationella databaser

Objektrelationella, eller "andra generationens objektorienterade", databaser är mer fullständiga databashanterare. Man har ett deklarativt frågespråk, som kan arbeta med klasser och objekt.

Litteratur


Webbkursen om databaser av Thomas Padron-McCarthy.