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.
|
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:
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.
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.
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.