Objektdatabaser: Når dataene er objekter
En objektdatabase (OODBMS, Object-Oriented Database Management System) lagrer data som objekter, slik de finnes i et objektorientert programmeringsspråk. Klasser, arv og referanser mellom objekter lagres direkte. Dataene trenger dermed ikke å oversettes til tabeller og rader, slik de må i en relasjonsdatabase.
- Objektdatabaser lagrer objekter med tilstand, arv og referanser, uten mapping til tabeller
- De løser den såkalte impedansmismatchen mellom objektorientert kode og relasjonsdatabaser
- I dag er de en nisje: de fleste systemer bruker relasjonsdatabaser med ORM, eller dokumentdatabaser
Historisk bakgrunn
Objektdatabaser vokste frem på 1980- og 1990-tallet, samtidig med at objektorienterte språk som Smalltalk og C++ ble utbredt. Organisasjonen Object Data Management Group (ODMG) utarbeidet en felles standard med spørrespråket OQL (Object Query Language). Den siste versjonen, ODMG 3.0, kom rundt år 2000.
Mange regnet med at objektdatabasene skulle overta for relasjonsdatabasene, men slik gikk det ikke. Relasjonsdatabasene hadde SQL, modne verktøy og stor utbredelse. De tok i stedet opp i seg objektorienterte trekk, og ORM-verktøy gjorde det enkelt å jobbe med objekter mot tabeller.
Hvordan fungerer en objektdatabase?
I en objektdatabase lagres objektene slik programmet bruker dem:
- Objektidentitet: Hvert objekt har en unik identitet (OID) som er uavhengig av verdiene det inneholder. Den spiller samme rolle som en primærnøkkel.
- Referanser i stedet for fremmednøkler: Et objekt peker direkte på andre objekter, og databasen følger referansene uten JOIN.
- Arv og polymorfi: Klassehierarkier lagres som de er, og en spørring mot en basisklasse gir også objekter av subklassene.
- Persistens: Mange objektdatabaser gjør objekter persistente nesten transparent. Programmet endrer objektet, og databasen lagrer endringen i en transaksjon.
Eksempel: En ordre med ordrelinjer og en kunde. I en relasjonsdatabase blir dette tre tabeller koblet med fremmednøkler, og koden må sette sammen objektene igjen ved hver lesing. I en objektdatabase lagres Ordre-objektet med referanser til Kunde og en liste med Ordrelinje-objekter, og programmet navigerer rett fra ordren til kunden.
Objektdatabaser og relasjonsdatabaser
| Egenskap | Objektdatabase | Relasjonsdatabase |
|---|---|---|
| Datamodell | Objekter, klasser og referanser | Tabeller, rader og kolonner |
| Relasjoner | Direkte referanser mellom objekter | Fremmednøkler og JOIN |
| Spørrespråk | OQL eller språkspesifikke API-er | Standardisert SQL |
| Kobling til koden | Tett, ofte bundet til ett programmeringsspråk | Løs, mange språk og verktøy kan bruke samme database |
| Ad hoc-spørringer og rapportering | Begrenset | Svært god |
Objekt-relasjonelle databaser og ORM
I praksis har to løsninger tatt over det meste av rollen objektdatabasene var tiltenkt:
- Objekt-relasjonelle databaser: SQL:1999 innførte brukerdefinerte strukturerte typer i SQL-standarden. PostgreSQL kaller seg en objekt-relasjonell database, med blant annet tabellarv og egne datatyper. Oracle har objekttyper, og SQL Server støtter brukerdefinerte CLR-typer.
- ORM (Object-Relational Mapping): Verktøy som Entity Framework Core for .NET og Hibernate for Java mapper objekter til tabeller automatisk. Utvikleren jobber med objekter, mens dataene ligger i en vanlig relasjonsdatabase.
I tillegg har dokumentdatabaser som MongoDB overtatt mange av brukstilfellene. Et JSON-dokument ligger nær et objekt i koden, uten å være bundet til ett programmeringsspråk.
Eksempler på objektdatabaser
- ObjectDB: Objektdatabase for Java med støtte for standardene JPA og JDO.
- GemStone/S: Objektdatabase og applikasjonsserver for Smalltalk.
- ZODB: Objektdatabase for Python, kjent fra Zope og Plone.
- InterSystems IRIS: Multimodell-database der de samme dataene kan nås både som objekter og med SQL.
- Versant og ObjectStore: Kommersielle objektdatabaser fra 1990-tallet som fortsatt brukes i enkelte eldre systemer.
Fordeler og ulemper
Fordeler
- Ingen mapping mellom objekter og tabeller, og dermed mindre kode
- Rask navigering i komplekse, sammenkoblede objektstrukturer
- Naturlig støtte for arv, polymorfi og nøstede objekter
Ulemper
- Tett koblet til ett programmeringsspråk og én applikasjon
- Svakere støtte for ad hoc-spørringer, rapportering og BI-verktøy
- Lite utbredt, med få leverandører, et lite økosystem og få utviklere med erfaring
- ODMG-standarden er ikke videreutviklet, så det finnes ikke noe felles spørrespråk i praksis
Når passer en objektdatabase?
Objektdatabaser passer best når dataene er komplekse objektstrukturer som brukes av én applikasjon og ett programmeringsspråk, og når navigering mellom objekter er viktigere enn fleksible spørringer. Typiske eksempler er CAD/CAM, simulering, vitenskapelige modeller og innebygde systemer.
Skal dataene deles mellom flere systemer, brukes til rapportering eller leve lenger enn applikasjonen, er en relasjonsdatabase med ORM nesten alltid et tryggere valg.
Konklusjon
Objektdatabaser løser et reelt problem: avstanden mellom objektene i koden og tabellene i databasen. De tapte likevel kampen mot relasjonsdatabasene, som fikk objektorienterte utvidelser og gode ORM-verktøy, og senere mot dokumentdatabasene. I dag er objektdatabaser et nisjevalg, men ideene deres lever videre i ORM, objekt-relasjonelle funksjoner og dokumentdatabaser.