Objektorienterte databaser - 6

Objektorienterte databaser - 6 Arne Maus

Problemstillinger , hvorfor OO-databaser ? • dagens relasjonsdatabaser (RDB) passer ikke for alle anvendelser - ønsker rikere semantikk (modellere mer i databaseskjema av systemets krav) • samme OO modell og begreper for hele prosessen (analyse/design, program, database,..) • ønsker bare ett språk - ikke to (SQL + applikasjonsprogrammets språk, f.eks C++, Java) (+ ønsker å prøve OO på "alt", også databaser)

Dagens Objektorienterte databaser- To retninger • Utbygging av SQL (Sybase, Oracle 8 og 9) • Utbygging av prog.språk som C++, Smalltalk og Java (GemStone, ObjectStore,O2 og Objectivity) • Data og pekere lagres, men ikke (like bra) program • ONTOS, O2 (Ardent) og GemStone minner noe om nettverks (CODASYL) databaser. • ODMG har standardisert : • ODL – for å definere databasen (database skjema) • OQL – spørrespråk mot databasen • Ulemper og fordeler med begge tilnærmingsmåtene.

Problemer / utfordringer for OODB • Vi ønsker at (noen av) de objekter vi har i programmet skal kunne overleve fra en programkjøring til neste = persistente objekter • De andre kalles transiente objekter(disse behøver ikke overleve i databasen) • Ikke bare lage data, men også pekere og metoder (i praksis lagres signatruren til metoder– dvs. navnet på metoden og typen(e) på parametre) – en såkalt ADT eller interface i Java-forstand)

a) Objekt-identitet: • I relasjonsdatabaser identifiseres tupler/entiteter ved deres innhold (primary key). • I OO systemer har alle objekter et 'navn’ – oid , en identitet. (To objekter med samme datainnhold er forskjellige !)

b) Lagring av relasjoner mellom objekter (=pekerverdier) • Pekere i et program er (ofte) hukommelseadresser. Neste gang programmet skal brukes, er disse adressene ikke riktige. Hvordan få med omgivelsene til et objekt: i) Få med alle persistente objekter som pekes på av et objekt.ii) Få med alle persistente objekter som peker på et objekt. • Ofte (O2 & ObjectStore) må brukeren selv navngi og lagre i egne set (mengder) de objektene som være 'persistente' og som skal lagres.

c) Spørrespråk • Problem: Fundamentale forskjeller på spørrespråk i SQL og C++ (transformasjoner til/fra problematisk) 'Løsning:’ i) "Sømløs" tilpassing av et programmeringsspråk med database - funksjonalitet -dvs. lage et SQL-lignende spørrespråk (men med pekere) – ny standard: OQL. ii) Utvidelser av SQL for å gjøre dette OO (=SQL3 = SQL99) OQL

Eksempel på ODL – database-def class Emne ( extent emnene key emnekode) { attribute String emnekode; attribute String navn; attribute Integer vekttall; relationship Set <Kurs> arrangerte_kurs inverse Kurs:emnet; } class Kurs {attribute Chars semester; attribute Integer årstall; relationship Emne emnet; inverse Emne:arrangerte_kurs; relationship List <Student> deltagere inverse Student:emner order_by navn; void registrer_sensur(); } class Student ( extent studentene ) { attribute String navn attribute Date f_dato; attribute String e_mail; relationship Set <Kurs> emner inverse Kurs:deltagere; Boolean oppmelding (in String emnekode) raises (Ikke_noe_slikt_emne); }

OQL - eksempel select s.navn, s.fdato from studentene s group by immatrikulert: s.immatrikulert_aar select * from studentene s group by borteboer?: s.hjemmekommune != ”Oslo” evig_student?: s.immatrikulert_aar < 1990 having (s.studentstatus = ”Aktiv” and not (s.hjemmekommune =”Ski” or s.hjemmekommune =”Nesodden”)) Svarene på spørsmålene blir hver et objekt som inneholder et Set (mengde)

d) Navigasjon i basen • i) Fra objekt til objekt (som nettverksdatabaser) • ii) Fra (objekt) mengde til mengde. Vanskeligere å optimalisere C++uttrykk enn SQL I ekte OO databser kan nå både navigere i basen og søke i mengder som SQL

e) Versjoner av objektene • Ofte hendig å kunne få adgang til eldre versjoner av objekter (tekstbehandling, DAK, programutvikling) • Versjonshåndtering av: • Databasesystemet (DAMOKLES), • eget program (Encore) • applikasjonen (GemStone)

f) Skjema-utvidelser (utvidet definisjon av basen) • Gamle data i basen: • i) Endres (autom.) til nye objekt-def (ORION) • ii) Binde opp alle data til versjoner av skjema

g) Transaksjoner i OO-anvendelser • Ofte meget lange transaksjoner (kan være "uendelige") • eks. DAK, pasientjournaler • Flerbrukerproblematikken: • - tradisjonelt låsing av alt som aksesseres • - Lange transaksjoner, "umulig å låse alt” • Løsninger: • i) sende melding om mulig konflikt • ii) hver ny skriving = ny versjon av objektet (kan gi problemer) • iii) låsing på objekt-nivå • iv) type- spesifikk låsing (eks. kø)

A) Ulemper med SQL-metoden • Har fortsatt to språk, problemer mellom program og database (ulike modeller). • Relasjonsmodellen (kanskje) lite egnet ved lange transaksjoner • SQL99 prøver å legge objekter til relasjonsmodellen.

B) Noen få ulemper med OO-prog.språk baserte databaser • Noe vanskelig å forstå for sluttbruker, vanskeligere å programmere. • Vanskeligere med ad hoc (’på sparket’) spørsmål mot basen. • ODL og OQL er nytt – ikke fullt implementert

SQL 3 / 99 • En ny SQL-standard (SQL 3) har kommet • Denne utvider SQL med objekter. • Bl.a vil innholdet i en tabellposisjon kunne være et helt objekt. • Vil gradvis komme i produktene.Objektorienterte databaser med utgangspunkt i et programmeringsspråk, synes nå å konkludere at selve programmeringsspråket (f.eks. C++) ikke kan nyttes direkte mot databasen, men at det må defineres et eget database-manipulering-språk. • Det er på det nåværende utviklingstrinnet ikke sikkert at rene OO-databaser også er en god ide for administrativ databehandling.

Fordeler med OO - databaser • Modellerer komplekse datastrukturer bra • Objektene (fra verden) blir ikke 'normalisert bort' i en rekke tabeller • Raskere enn Relasjonsdatabaser • Ofte 'samme språk' i program og database (C++, Java) • Konklusjon: • For visse typer anvendelser (eks. DAK, GIS) hvor det er komplisert datastruktur og lange transaksjoner, vil det være fornuftig å bruke OO databaser. Mange OODB-applikasjoner finnes allerede i dag. Neppe like aktuelt for ordinære administrative systemer.

Objektorienterte databaser - 6