Laste ned presentasjonen
Presentasjon lastes. Vennligst vent
1
1 Objektorienterte databaser - 6 Arne Maus
2
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
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
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
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
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
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
8
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
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
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
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
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
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
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
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
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
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.
Liknende presentasjoner
