1 Objektorienterte databaser - 6 Arne Maus

2 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)

3 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,O 2 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.

4 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)

5 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 !)

6 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 (O 2 & ObjectStore) må brukeren selv navngi og lagre i egne set (mengder) de objektene som være 'persistente' og som skal lagres.

7 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 Stringnavn; attribute Integervekttall; relationship Set arrangerte_kurs inverse Kurs:emnet; } class Kurs {attribute Charssemester; attribute Integerårstall; relationship Emneemnet; inverse Emne:arrangerte_kurs; relationship List 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 emner inverse Kurs:deltagere; Boolean oppmelding (in String emnekode) raises (Ikke_noe_slikt_emne); }

9 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)

10 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

11 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)

12 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

13 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ø)

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

15 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

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

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