De aktuelle er altså databasene 1 til 3. I praksis brukes mest 2 og 3. Vi skal likevel se på OODBMS også, siden det må antas å være kommende.

OO & DBMS Innledning Når man deklarerer en kunde Private Kunde kunde = new Kund(); så legges objektet i RAM. Scope er begrenset til referansens (variabelens) scope og levetiden til sesjonen. Objektet blir borte når sesjonen avsluttes, strømmen går o.l. Objektet er da transient. For mange objekter er det OK, fordi objektet er flyktig i seg selv, f.eks. grenseobjekter som håndterer påloggede brukere og printerobjekter og kontrollobjekter som håndterer køer, samtidighet osv. For objekter som skal ta vare på data typisk (men ikke bare) entitetsobjekter, holder det ikke. Da må man ha persistente objekter, som lagres på et ytre lagringsmedium mellom sesjoner. Da kan man bruke: 1) OODBMS (objektorienterte databaser) 2) RDBMS (relasjonelle databaser) 3) ORDBMS (objektrelasjonelle databaser) 4) Flate filer (direkte eller sekvensielle) 5) Andre DBMS, f.eks. nettverksdatabaser og hierarkiske databaser Alternativ 4 og 5 blir gammeldags og tungvint, f.eks. må vi selv håndtere kontroll med entitetsintegritet, referanseintegritet og samtidighet (med låsing, transaksjoner osv). De ser jeg følgelig bort fra her. De aktuelle er altså databasene 1 til 3. I praksis brukes mest 2 og 3. Vi skal likevel se på OODBMS også, siden det må antas å være kommende. Ad 1) OODBMS (objektorienterte databaser) Det vil passe ypperlig med et objektorientert program å ha en objektorientert database, der vi kan lagre objekter direkte, med attributter og metoder, for ikke å snakke om referanser direkte fra ett objekt til et annet. Det finnes flere muligheter, som er nærmere forklart nedenfor. OODBMS Generelt Det er en stor fordel med OODBMS at alle OOP-mekanismer implementeres direkte. Vi får bare ett paradigme (teknologi) å forholde oss til, så tilknytningen oppleves sømløs. Databasedefinisjoner, dataendringer og søk kan gjøres med OQL ( Object Query Language ) en form for utvidet SQL. I en OODBMS har objektene identitet (typisk gjennom en systemgenerert, intern peker kalt OID = object identifier, men ikke gjennom primærnøkkel). Objektene har en tilstand og en oppførsel. Det defineres objektklasse (ikke domener), og OODBMS støtter arv, polymorfisme, osv.). Det er likevel flere problemer med OODBMS. Et hovedproblem er at databasene ikke virker helt ferdige teknologien er fortsatt umoden. Et annet problem er manglende teori det har ikke vært noen Date & Codd som har arbeidet med OODBMS. Det er f.eks. ikke på noen måte klart hvordan man skal kunne håndtere transaksjoner, skjemaevolusjon (klassene endres Knut W. Hansson, Høgskolen i Buskerud oo & dbms.doc

over tid), beholde entydige pekere når objektene lagres distribuert, håndtere evt. multippel arv og annet. Typiske datastrukturer i OODBMS Med datastrukturer, forstår jeg her beskrivelser av samlinger av data ( collections ) med en viss struktur og visse regler. Dataene som inngår kalles elementer. I en samling, er alle elementer av samme type, evt. subtype. Det er typisk fire grunnleggende strukturer, som bygger på underliggende ADTer (abstrakte datatyper, dvs. datastrukturer som man bare får tilgang til med gitte metoder). I Java-pakken org.odmg finnes f.eks. grensesnittene DSet, DBag, DList og DArray som alle inneholder objekter av klassen Object. Mengde ( set ) inneholder et antall ulike elementer av samme type (eller subtype). Det kan være ingen (en tom mengde), én eller flere elementer i mengden uten grense oppad. Elementer legges til og fjernes. Når et nytt element legges til, øker antall elementer i mengden forutsatt at ikke elementet finnes der fra før. Når et element fjernes, blir antallet elementer i mengden mindre. Det finnes ingen tomme elementer 1 og ingen like 2. Det er ingen rekkefølge på elementene. {K,n,u,t}={t,u,n,K} Ingen ordning, rekkefølgen er uten betydning {b,o}+{b}={b,o} Ingen dubletter {K,n,u,t}-{n}={K,u,t} Fjerning gir færre antall elementer Bag er en mengde der like elementer (duplikater) er tillatt. {K,n,u,t}={t,u,n,K} Ingen ordning, rekkefølgen er uten betydning {b,o}+{b}={b,o,b} Dubletter er tillatt {K,n,u,t}-{n}={K,u,t} Fjerning gir færre antall elementer Liste er en ordnet bag, dvs. en unummerert sekvens av elementer. Elementene har en rekkefølge. Et element settes inn på en bestemt plass i listen. For å finne et bestemt element, må man bla gjennom listen fra første element (evt i en dobbeltlenket liste også fra siste element). Uttrykk som første element og neste element (evt. siste og forrige element ) har mening. Det er også meningsfylt å be om element nr i, men det medfører gjennomgang av listen fra den ene enden. {K,n,u,t} {t,u,n,k} Rekkefølgen har betydning {b,o}+{b bakerst}={b,o,b} Dubletter er tillatt, plassering har betydning {K,n,u,t}-{n}={K,u,t} Fjerning gir færre antall elementer Array er en liste med et fast og begrenset antall nummererte elementer. Hvert element er nummerert med en indeks. De som ikke er fylt med data er null. Direkte adgang til elementet vha indeksen. En array har begrenset kapasitet. Man kan ikke fjerne/legge til elementer i en array, men man kan slette elementet ved å sette det tomt eller ledig 3. 1 Noen tillater null-elementer. Det er da ikke det samme som et tomt element, men anses som et element med en spesiell verdi, og i en mengde kan det i så fall bare være ett slikt element. 2 Likhet må defineres for elementenes klasse. I Java gjøres det f.eks. ved å overstyre metoden equals(). 3 I OOP innebærer det å sette elementet til null. Her betyr null at elementet ikke har verdi det er tomt. Knut W. Hansson, Høgskolen i Buskerud Side 2 av 11

{K,n,u,t} {t,u,n,k} Rekkefølgen har betydning {b,o,null,null}+{b bakerst}={b,o,null,b} Dubletter er tillatt, plassering har betydning {K,n,u,t}-{tredje elelement}={k,n,null,t} Fjerning gir ikke færre antall elementer Java er spesielt glad i klassen Vector, som er en form for array. Object Query Language OQL OQL er definert av Open Data Management Group (odmg.org) OQL likner svært på SQL, men noen forskjeller er vesentlige: 1) SQL returnerer alltid en tabell. OQL kan returnere a) en verdi, f.eks. knut.stp er knut er et objekt og stp er en int som angir studiepoeng b) ett objekt, f.eks. knut.adresse der adresse er et objekt c) en struktur dvs. flere objekter, f.eks. en array med studenter i) med select returneres en bag ii) med select distinct returneres et set iii) med order by returneres en list men kan direkte brukes som en array hvis f.eks. studenter = select* order by navn; er det lov til å skrive studenter[3].navn 2) SQL refererer alltid til attributter, mens OQL kan referere både til alle medlemmer både attributter og metoder, f.eks. SQL: select navn from tblstudent s where s.navn = Knut Hansson ; OQL: select navn from student s where s.oppginavn() = Knut Hansson ; 3) SQL angir attributt med punktnotasjon, f.eks. s.navn, mens i OQL kan man gjerne ha flere punkt fordi returen kan være objekt, f.eks....where s.adresse.gate.navn = Storgaten 4) SQL har alltid tabeller i from-klausulen. OQL kan derimot ha objektstrukturer, f.eks. select s.navn, s.adresse.gate, s.adresse.husnr from student s, s.kurser k where k.kursnavn = sys2 der s.kurser er en array med referanse til mange kursobjekter. 1A) OODBMS med precompiler Dette alternativet går ut på at man kjøper en OODBMS tilpasset det OOP-språket vi programmerer i (C++, SmallTalk, Visual Basic, Java osv) og får derved på en måte utvidet programmeringsspråket. F.eks. kan vi da kanskje skrive Persistant Public Class Kunde, dbnew, dbdelete, dbsave evt. med tilleggsargumenter for å angi sikkerhetsnivå, brukernavn, passord o.l. Vi bruker da språket vårt som vanlig, men skriver kanskje dbnew istedenfor new for persistente objekter. Deretter kjører vi koden gjennom en precompiler som oversetter vår kode dbnew osv til vanlig kode etter normal syntaks for språket, men slik at effekten blir lagring på ytre lager. Kall på objektet vil føre til at objektet hentes fra ytre lager til RAM osv. Deretter kompileres den endrede koden helt som vanlig, men den vanlige kompilatoren for språket. Fordel: Det er enkelt å skrive koden pga mye automatikk (i precopileren) Ulempe: Koden som kompileres og eksekveres, er ikke lik den vi skrev selv det er vanskeligere å teste systematisk og å finne feil. 1B) OODMBS med klassebibliotek Med denne løsningen, kjøper vi et klassebibliotek tilpasset vårt språk. Persistens gjennomføres med arv og bruk av arvede metoder. F.eks. kan det kanskje se slik ut: Knut W. Hansson, Høgskolen i Buskerud Side 3 av 11

Class Kunde extends DB_UnsortedList I tillegg til pekere som implementerer lister ( lenker ) arver klassen metoder som håndterer listen. Da skriver vi ikke Kunde kunde1 = new Kunde() men kanskje Kunde kunde1 = Kunde.addNew() //bruker klassemetode evt. m/argumenter Metoden addnew() er tenkt å sørge for å opprette objektet i databasen, og legge til triggere som lagrer ved behov, f.eks. hver gang et attributt endres. Mange andre aktuelle metoder og attributter finnes i en slik klasse, f.eks. klassemetodene First(), NumberOf() eller Count(), Find(), Save(), FindNext() osv. Vi kan håndterer objektene gjennom klassen, som følgelig kalles en containerklasse. Java har f.eks. et grensesnitt ( interface ) kalt DCollection som kan brukes til slikt. Siden alle containerklasser har noe felles, arver de gjerne fra en generell containerklasse, men noen medlemmer må være forskjellige. F.eks. er addnew() to helt forskjellige ting for en kø og en stack. Fordel: Koden blir ren Java, C++ osv koden er lettere å endre, finne feil i osv. Ulempe: Man må forstå det tilbudte klassebiblioteket og medlemmene som følger med. Man kan ikke bruke standardmekanismer som new osv. 2) RDBMS Vi kan bruke OOP men lagre persistente objekter i en RDBMS. Da får vi problemer med å opprettholde OOPs hovedprinsipper innkapsling o abstraction = skjult implementering f.eks. ukjent programkode for metodene og private data/metoder o data/metoder holdes samlet arv polymorfisme containere, f.eks. set, bag, list og array. fordi disse mekanismene ikke finnes i RDBMS. I tillegg må RDBMS ha metadata (schema) som deklarerer tabeller, data, brukere, indekser osv. RDBMS har kun tabeller (matematisk relasjoner) og må ha minst ett felt, kalt primærnøkkel, som skal ha unike verdier. I OOP regnes to objekter som forskjellige, bare de er lagret hvert sitt sted i RAM. I OODBMS regnes de ofte forskjellige bare de har minst én attributtverdi forskjellig, men det kan variere hvilket attributt det er. I OOP kan et objekt være inkludert (som attributt ) i et annet objekt. I RDBMS er det ikke tillatt med en tabell inne i en annen tabell. Hvis vi skriver alle våre persistente objektklasser helt uten arv med unike nøkkelfelt med bare public attributter helt uten polymorfisme (følger av første punkt) med bare enkle datatyper Knut W. Hansson, Høgskolen i Buskerud Side 4 av 11

da kan klassestrukturen lett overføres til en RDBMS, men OOP blir det ikke! I praksis vil vi ikke bindes så sterkt, og vi får et problem med å mappe de persistente objektklassene til datatabeller i RDBMS. Mapping av OOP til RDBMS Med mapping forstår vi en omgjøring av strukturen. Hensikten er å lage regler for overgang fra en struktur her OOP til en annen her RDBMS. For å løse problemene som er nevnt ovenfor, kan vi bruke fire strategier for mapping: Vertikal mapping = Alle klasser får sin egen tabell. Horisontal mapping = Bare konkrete klasser mappes, alle arvede attributter tas med der. Filtrert mapping = Bare øverste klasse mappes, alle underliggende attributter trekkes opp dit og det legges til en type -attributt som angir hvilken klasse en post hører til. Generisk mapping = En fast mapping uansett modell i OOP. Når det skal benyttes en relasjonsdatabase, må det stilles krav til klassemodellen. Alle klasser må ha et eksplisitt identifikatorattributt (det holder ikke med adressen/referansen til objektet slik det gjør i objektorientering), de må ha atomære attributter (attributter som er strukturer som vektorer, arrays, andre klasser og liknende strukturer må løses opp) og alle relasjoner må realiseres med fremmedattributter (da følger det også at alle mange-til-mange assosiasjoner, og assosiative klasser, må objekteres). Nedenfor følger et eksempel, basert på følgende OOP-modell for de persistente klassene: {abstract} Kunde - navn : String KontantKunde - rabattkategori : int - kassenr : int KredittKunde - kundenr : int - kredittgrense : int - utestående : double - adresse : string A) Vertikal mapping (separasjon) Alle klasser mappes til sin egen tabell. Man innfører primærnøkkel (PK) etter behov. Det legges til en logisk peker fra subklasse til metaklasse. Kunde (navn, k_id) KontantKunde (rabattkategori, kassenr, *k_id, kontantkunde_id) KreditKunde (kundenr, kredittgrense, utestående, adresse, *k_id) Her er Kontantkunde.kontantkunde_id unødvendig, da k_id også kan brukes som PK. Knut W. Hansson, Høgskolen i Buskerud Side 5 av 11

B) Horisontal mapping (partisjonering) Bare de konkrete klassene mappes med alle attributter også de som er arvet til hver sin tabell. Innfører PK etter behov. KontantKunde (navn, rabattkategori, kassenr, kontantkunde_id) KredittKunde (navn, kundenr, kredittgrense, utestående, adresse) C) Filtrert mapping (absorpsjon) Alle tabellene i et hierarki slås sammen til én tabell. I tillegg kreves da en attributt som angir hvilken klasse posten tilhører, og selvsagt en PK. Kunde (navn, rabattkategori, kassenr, kundenr, kredittgrense, utestående, adresse, k-id, k_type) Her kunne det være fristende å bruke kundenr som PK, men det går ikke fordi kontantkunder ikke har kundenr. D) Generisk mapping Det brukes en fast mapping med tabellene Klasse, Attributt, Datatype og Verdi med relasjoner dem imellom (i tillegg kan egenrelasjonen til Klasse entitetiseres). Tabellen inneholder mest metadata verdiene lagres bare i tabellen Verdi. Denne er både vanskelig å bruke og å forstå, og diskuteres ikke nærmere her. Knut W. Hansson, Høgskolen i Buskerud Side 6 av 11

Mapping av noen spesielle situasjoner Eksemplet ovenfor var svært enkelt fordi det var ingen assosiasjoner, hverken en-til-mange eller mange-til-mange det var bare ett nivå med arv, kunne vært flere det var ingen objekter eller objektstrukturer (ADTer) blant attributtene Det er eksempler på de to første i den gjengitte eksamensoppgaven nedenfor (se denne), men ikke den tredje. Her er et eksempel med en objektstruktur som attributt: Medlem - navn : String - adresse : Adresse 1 1 Adresse - gatenavn : String - husnr : int - post : Post - medlem : Medlem * 1 Post - postnr : int - poststed : String - adresser : Adresse[] Her tenker vi oss først litt om. Vi ser at Adresse refererer til et Post-objekt, som på sin side refererer til mange Adresse-objekter. Det er et resultat av assosiasjonen mellom dem. I relasjonsdatabasen bruker vi bare den ene ( fra mange til én) den andre kan vi altså se bort fra. Videre ser vi at det er en én-til-én assosiasjon mellom Medlem og Adresse. Da har vi følgende alternativer: 1) Slå sammen objektene til én tabell i databasen og ikke lage fremmednøkkel. Behovet for fremmednøkler bortfaller. 2) Lage to tabeller, men legge fremmednøkkel i bare den ene av dem 3) Lage to tabeller, men legge fremmednøkkel i begge (det vil være uvanlig i relasjonsdatabaser fordi det er redundant). Knut W. Hansson, Høgskolen i Buskerud Side 7 av 11

Løsning 1: Medlem (navn, gatenavn, husnr, *postnr, medlem_id) Post (postnr, poststed) Løsning 2: Medlem (navn, *adresse_id, medlem_id) Adresse (gatenavn, husnr, *postnr, adresse_id) Post (postnr, poststed) Løsning 3: Medlem (navn, *adresse_id, medlem_id) Adresse (gatenavn, husnr, *postnr, *medlem_id, adresse_id) Post (postnr, poststed) Generelle betraktninger Ikke alle attributter behøver å lagres, f.eks. attributt som er der av praktiske grunner, men som kan finnes behov (f.eks. klasseattributtet antallkunder) attributt som har verdi bare midlertidig (f.eks. isdirty som angir om noe er endret) attributt som bare har mening i OOP (f.eks. nestekunde en peker til neste objekt i en liste) Noen attributter må legges til i RDBMS, f.eks. En identifikator, i form av en verdi, kreves i RDBMS Logisk peker til metaklassen i en vertikal mapping, eller en type-identifikator i en filtrert mapping Noen strukturer må gjøres om helt, f.eks. attributt som utgjør en struktur (en container som attributt) attributt som er et objekt mange-til-mange relasjoner multippel arv, der det støttes Aggregeringer ( består av ) krever triggere og/eller kaskadeeffekter, siden delene må slettes når aggregeringen slettes. RDBMS er like forskjellig fra OOP som f.eks. printere, bruker osv, og etter mitt syn bør de håndteres av grenseklasser som finner, henter/bygger objekter, lagrer, sletter og endrer databasen i takt med objektene i RAM. Det finnes noe programvare som er i stand til å mappe automatisk til ønsket database etter en angitt strategi. 3) ORDBMS En objektrelasjonell database er en mellomting mellom OODBMS og RDBMS. Man har utvidet relasjonsdatabasen til å bli mer objektlik med bl.a.: brukerdefinerte type, dvs. ADT med atributter og rutiner (prosedyrer) arv er tillatt, navngitte radtyper (struct/record) og distinkte typer (egendefinerte typer). Dette gjør man med typekonstruktører, f.eks. create distinct type kroner as decimal (9,2) samlinger (collections), dvs. set = vanlig tabell, list = tabell der én kolonne definerer rekkefølgen og multiset = bag. Slik kan én verdi i tabellen være samling. Knut W. Hansson, Høgskolen i Buskerud Side 8 av 11

brukerdefinerte funksjoner og prosedyrer, skrevet i SQL eller et annet, standard programmeringsspråk store objekter, også kalt BLOB (binary large object) og CLOB (character large object) subtabeller gir arv mellom tabeller (de arver kolonnene og kan legge til flere kolonner) direkte referanser til en rad i en (annen) tabell Likevel mangler fortsatt en del før de kan kalle seg OODBMS, f.eks. muligheten til å utføre handlinger på alle objektene i en ADT referanser eller navn på enkeltrader ADTer må lagres som verdi i en kolonne altså kan ingen være helt like etter definisjonen i ADTen (en definisjon av likhet er obligatorisk) tabeller utgjør fortsatt den grunnleggende strukturen Slik kan det se ut: create table avdeling (avdnr char(10), kontorsjef ansatt, avdsjef ansatt instance) Der det lages en tabell med tre kolonner. I den andre kontorsjef lagres en referanse til en bestemt ansatt. I den tredje avdsjef lagres en ansatt som ett element (som ikke er atomært). Mapping av OOP til ORDBMS Mappingen gjøres på omtrent samme måte som til RDBMS, men man kan selvsagt utnytte de ekstra mulighetene som ligger i ORDBMS. Knut W. Hansson, Høgskolen i Buskerud Side 9 av 11

Fra eksamen SYS2 H01 Spørsmål: Forklar meget kort prinsippene for de tre måtene å mappe på, og gjennomfør så alle de tre variantene for hele modellen nedenfor (inkludert RESULTAT og FAG). <<Abstract>> STUDENT StudentNr : Unik teller Navn : String Adresse : String tar 0..* 1..* FAG FagNavn : String Vekttall : Int PASSIV STUDENT FraDato : Dato AKTIV STUDENT DatoForStudielån : Dato RESULTAT År : Int Semester : {H,V} = H Karakter = NULL HELTIDSSTUDENT Tillitsverv : String = "" DELTIDSSTUDENT Prosent : Double Fra sensorveiledningen (løsningsforslag) Primærnøkler er understreket, fremmednøkler merket med *. Det kan synes rart, men oppgaven synes å tyde på at det finnes studenter som er aktive, uten å være hverken heltidsstudent eller deltidsstudent (AKTIV STUDENT er persistent). Oppgaven er løst slik nedenfor. Vertikalt FAG (FagNavn, Vekttall, FAG-ID) RESULTAT(År, Semester, Karakter, *FAG-ID, *StudentNr) STUDENT(StudentNr, Navn, Adresse) PASSIV-STUDENT(FraDato, PASSIV-STUDENT-ID, *StudentNr) AKTIV-STUDENT(DatoForStudielån, AKTIV-STUDENT-ID, *StudentNr) HELTIDSSTUDENT(Tillitsverv, DatoForStudielån, HELTIDSSTUDENT-ID, *StudentNr) DELTIDSSTUDENT(Prosent, DatoForStudielån, DELTIDSSTUDENT-ID, *StudentNr) Alternativt, med StudentNr som ID: PASSIV-STUDENT(FraDato, *StudentNr) AKTIV-STUDENT(DatoForStudielån, *StudentNr) HELTIDSSTUDENT(Tillitsverv, DatoForStudielån, *StudentNr) DELTIDSSTUDENT(Prosent, DatoForStudielån, *StudentNr) StudentNr er unik og kan brukes som ID. De som har StudentNr som fremmednøkkel, kan også bruke den som ID. Det kan være fristende å bruke FagNavn som ID i FAG. Det synes jeg er tvilsomt. HELTIDSSTUDENT og DELTIDSSTUDENT: Disse må arve attributtene fra AKTIV STUDENT fordi den er persistent. Knut W. Hansson, Høgskolen i Buskerud Side 10 av 11

Horisontalt FAG (FagNavn, Vekttall, FAG-ID) RESULTAT(År, Semester, Karakter, *FAG-ID, *StudentNr) PASSIV-STUDENT(StudentNr, Navn, Adresse, FraDato) AKTIV-STUDENT(StudentNr, Navn, Adresse, DatoForStudielån) HELTIDSSTUDENT(StudentNr, Navn, Adresse, Tillitsverv, DatoForStudielån) DELTIDSSTUDENT(StudentNr, Navn, Adresse, Prosent, DatoForStudielån) Her har jeg gjennomført brukt StudentNr som ID (den arves av alle de andre klassene). Hvis man ikke gjør det, vil man få store problemer med relasjonen RESULTAT-STUDENT når sistnevnte klasse splittes i fire tabeller. Filtrert FAG (FagNavn, Vekttall, FAG-ID) RESULTAT(År, Semester, Karakter, *FAG-ID, *StudentNr) STUDENT(StudentNr, Navn, Adresse, FraDato, DatoForStudielån, Tillitsverv, Prosent, Klasse) En vanlig feil er å mangle attributtet Klasse eller tilsvarende i STUDENT. Knut W. Hansson, Høgskolen i Buskerud Side 11 av 11