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.

Størrelse: px
Begynne med side:

Download "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."

Transkript

1 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

2 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

3 {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

4 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

5 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

6 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

7 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

8 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

9 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

10 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

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

Databaser & objektorientering.

Databaser & objektorientering. Databaser & objektorientering. Noen grunnbegreper innen objektorientering. Klasser og forekomster klasser beskriver strukturen for noe. Beskrivelsen inneholder: et navn attributter /egenskaper / tilstander

Detaljer

OO-eksempel. Modellen ser slik ut: Studenter + antstudenter : int = 0

OO-eksempel. Modellen ser slik ut: Studenter + antstudenter : int = 0 OO-eksempel I eksemplet er det deklarert tre klasser: 1) Fag (skal instansieres ett objekt for hvert fag) 2) Student (skal instansieres ett objekt for hver student) 3) Studenter (abstrakt klasse skal ikke

Detaljer

Normalisering av objektorienterte systemer Versjon B

Normalisering av objektorienterte systemer Versjon B Normalisering av objektorienterte systemer Versjon B Knut W. Hansson Førstelektor Høgskolen i Buskerud August 2003/Sept 2005 Innhold Innledning...3 Hvilke klasser bør inngå i normaliseringen...3 Antall

Detaljer

Databaser. Relasjonsmodellen 1 Læreboka: Kap. 2 Relasjonsmodellen Faglærere: Tore Mallaug, Kjell Toft Hansen

Databaser. Relasjonsmodellen 1 Læreboka: Kap. 2 Relasjonsmodellen Faglærere: Tore Mallaug, Kjell Toft Hansen Databaser Relasjonsmodellen 1 Læreboka: Kap. 2 Relasjonsmodellen Faglærere: Tore Mallaug, Kjell Toft Hansen Tema for dagen Relasjonsmodellen Hvorfor relasjoner? Fra ER diagram til relasjoner 22.09.2008

Detaljer

Introduksjon til fagfeltet

Introduksjon til fagfeltet LC238D http://www.aitel.hist.no/fag/_dmdb/ Introduksjon til fagfeltet Datafiler side 2 Databasesystemer side 3-5 Databasearkitektur ANSI/SPARC side 6-7 Datamodeller side 8 Flerbruker databasesystem side

Detaljer

Liste som abstrakt konsept/datatype

Liste som abstrakt konsept/datatype Lister Liste som abstrakt konsept/datatype Listen er en lineær struktur (men kan allikevel implementeres ikke-lineært bak kulissene ) Hvert element har en forgjenger, unntatt første element i listen Hvert

Detaljer

1. Innføring i bruk av MySQL Query Browser

1. Innføring i bruk av MySQL Query Browser Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Innføring i bruk av MySQL Query Browser Kjell Toft Hansen 28.02.2007 Lærestoffet er utviklet for faget LV338D Databaseadministrasjon 1. Innføring

Detaljer

1. Relasjonsmodellen. 1.1. Kommentarer til læreboka

1. Relasjonsmodellen. 1.1. Kommentarer til læreboka Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Relasjonsmodellen Tore Mallaug 2.9.2013 Lærestoffet er utviklet for faget Databaser 1. Relasjonsmodellen Resymé: Denne leksjonen gir en kort

Detaljer

Hva er en liste? Hvert element har en forgjenger, unntatt første element i listen. Hvert element har en etterfølger, unntatt siste element i listen

Hva er en liste? Hvert element har en forgjenger, unntatt første element i listen. Hvert element har en etterfølger, unntatt siste element i listen Lister Hva er en liste? Listen er en lineær datastruktur Hvert element har en forgjenger, unntatt første element i listen Hvert element har en etterfølger, unntatt siste element i listen I motsetning til

Detaljer

INF 329: Web-Teknologier. Dataimplementasjon. Fra Kapittel 11 i «Designing Data-Intensive Web Applications» Presentasjonsdato: 17/10/2004

INF 329: Web-Teknologier. Dataimplementasjon. Fra Kapittel 11 i «Designing Data-Intensive Web Applications» Presentasjonsdato: 17/10/2004 INF 329: Web-Teknologier Dataimplementasjon Fra Kapittel 11 i «Designing Data-Intensive Web Applications» Presentasjonsdato: 17/10/2004 av: Dag Viggo Lokøen (dagvl@ii.uib.no) Kent Inge F. Simonsen (kentis@ii.uib.no)

Detaljer

OM DATABASER DATABASESYSTEMER

OM DATABASER DATABASESYSTEMER OM DATABASER DATABASESYSTEMER Begrepet database brukes på flere måter, og det er ikke uvanlig å bruke det for å angi en total samling av data (i dette tilfellet lagrede opplysninger) uavhengig av hvordan

Detaljer

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

Detaljer

Oppgaver Oppgave a: Sett opp mulige relasjoner

Oppgaver Oppgave a: Sett opp mulige relasjoner Løsningsforslag til øving 4: Relasjonsmodellen Kjell Toft Hansen 18.09.2008 Opphavsrett: Forfatter og AITeL Lærestoffet er utviklet for faget LO151D Informatikk 1: databaser Oppgaver Oppgave a: Sett opp

Detaljer

Eksamen. Objektorientert Programmering IGR 1372

Eksamen. Objektorientert Programmering IGR 1372 + JVNROHQL1DUYLN $YGHOLQJIRU7HNQRORJL Eksamen i Objektorientert Programmering IGR 1372 7LG'HVHPEHU± 7LOODWWHKMHOSHPLGOHU 6NULYHVDNHU2UGE NHU -DYD6RIWZDUH6ROXWLRQV)RXQGDWLRQVRI3URJUDP 'HVLJQVNUHYHWDY/HZLV

Detaljer

Integritetsregler i SQL. Primærnøkler

Integritetsregler i SQL. Primærnøkler Integritetsregler i SQL Kandidat- og primærnøkler Referanseintegritet - fremmednøkler Domenebegrensende integritetsregler skranker på attributter og tupler Interrelasjonsskranker assertions Triggere INF212

Detaljer

Lenkelister. Lister og køer.

Lenkelister. Lister og køer. Lenkelister. Lister og køer. INF1010 Stein Michael Storleer 27. januar 2011 Dagens forelesning Lenkede lister Lenkede lister Eksempel på en lenket liste: personliste Operasjoner på lenkede lister (enkeltlenket)

Detaljer

Etter uke 9 skal du. Introduksjon til objektorientert programmering. Innhold. Klasser som abstraksjoner

Etter uke 9 skal du. Introduksjon til objektorientert programmering. Innhold. Klasser som abstraksjoner Etter uke 9 skal du Introduksjon til objektorientert programmering INF1001 Høst 2016 Uke 9 Kunne designe og implementere en programstruktur med flere klasser Kunne etablere og manipulere objekter i (sammensatte)

Detaljer

Læringsmål for forelesningen

Læringsmål for forelesningen Læringsmål for forelesningen Objektorientering Regler for oppførsel Java-programmering JUnit-testing Eclipse Opprette JUnit-test og kjøre den 1 Pensum Testing dekkes ikke av Liang! Er en viktig del av

Detaljer

23.09.2015. Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert.

23.09.2015. Introduksjon til objektorientert. programmering. Hva skjedde ~1967? Lokale (og globale) helter. Grunnkurs i objektorientert. Grunnkurs i objektorientert programmering Introduksjon til objektorientert programmering INF1000 Høst 2015 Siri Moe Jensen INF1000 - Høst 2015 uke 5 1 Siri Moe Jensen INF1000 - Høst 2015 uke 5 2 Kristen

Detaljer

Algoritmer og datastrukturer Kapittel 3 - Delkapittel 3.1

Algoritmer og datastrukturer Kapittel 3 - Delkapittel 3.1 Delkapittel 3.1 Grensesnittet Liste Side 1 av 11 Algoritmer og datastrukturer Kapittel 3 - Delkapittel 3.1 3.1 En beholder 3.1.1 En beholder En pappeske er en beholder En beholder er noe vi kan legge ting

Detaljer

Løsningsforslag ukeoppg. 6: 28. sep - 4. okt (INF1000 - Høst 2011)

Løsningsforslag ukeoppg. 6: 28. sep - 4. okt (INF1000 - Høst 2011) Løsningsforslag ukeoppg. 6: 28. sep - 4. okt (INF1000 - Høst 2011) Løsningsforslag til oppgave 7, 8, og 9 mangler Klasser og objekter (kap. 8.1-8.14 i "Rett på Java" 3. utg.) NB! Legg merke til at disse

Detaljer

HØGSKOLEN I SØR-TRØNDELAG

HØGSKOLEN I SØR-TRØNDELAG HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring Kandidatnr: Eksamensdato: 10.desember 2008 Varighet: 0900 1200 Fagnummer: Fagnavn: LO346D Java EE og distribuerte systemer Klasse(r): NETT

Detaljer

Datamodellering og databaser http://www.aitel.hist.no/fag/_dmdb/ SQL, del 2

Datamodellering og databaser http://www.aitel.hist.no/fag/_dmdb/ SQL, del 2 http://www.aitel.hist.no/fag/_dmdb/ SQL, del 2 Eksempelbase side 2 Virtuelle tabeller (views) side 3-6 NULL-verdier side 7-14 UPDATE-setningen side 15-16 INSERT-setningen side 17 DELETE-setningen side

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Kandidatnr Eksamen i INF1000 Grunnkurs i objektorientert programmering Eksamensdag: Onsdag 1. desember 2010 Tid for eksamen: 14.00 18.00

Detaljer

OPPGAVE 1 OBLIGATORISKE OPPGAVER (OBLIG 1) (1) Uten å selv implementere og kjøre koden under, hva skriver koden ut til konsollen?

OPPGAVE 1 OBLIGATORISKE OPPGAVER (OBLIG 1) (1) Uten å selv implementere og kjøre koden under, hva skriver koden ut til konsollen? OPPGAVESETT 4 PROSEDYRER Oppgavesett 4 i Programmering: prosedyrer. I dette oppgavesettet blir du introdusert til programmering av prosedyrer i Java. Prosedyrer er også kjent som funksjoner eller subrutiner.

Detaljer

Introduksjon til objektorientert programmering

Introduksjon til objektorientert programmering Introduksjon til objektorientert programmering Samt litt mer om strenger og variable INF1000, uke6 Ragnhild Kobro Runde Grunnkurs i objektorientert programmering Strategi: Splitt og hersk Metoder kan brukes

Detaljer

Å bruke Java API-et til å sortere tabeller/arraylister der elementene er (referanser til) objekter

Å bruke Java API-et til å sortere tabeller/arraylister der elementene er (referanser til) objekter Sortering og søking i Java-API-et Tabeller og Arraylister Comaparable Comparator equals() LC9D Videregående programmering Semesterplan: http://aitel.hist.no/fag/vprg/index_lc9d.php Høgskolen i Sør-Trøndelag,

Detaljer

Enkle generiske klasser i Java

Enkle generiske klasser i Java Enkle generiske klasser i Java Oslo, 7/1-13 Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo Del 1: Enkle pekere Før vi tar fatt på det som er nytt i dette notatet, skal vi repetere litt

Detaljer

Integritetsregler i SQL

Integritetsregler i SQL UNIVERSITETET I OSLO Integritetsregler i SQL INF3100 8.2.2005 Ragnar Normann 1 Integritetsregler i SQL Kandidat- og primærnøkler Referanseintegritet - fremmednøkler Domenebegrensende integritetsregler

Detaljer

BOKMÅL Side 1 av 7. KONTINUASJONSEKSAMEN I FAG TDT4100 Objektorientert programmering / IT1104 Programmering, videregående kurs

BOKMÅL Side 1 av 7. KONTINUASJONSEKSAMEN I FAG TDT4100 Objektorientert programmering / IT1104 Programmering, videregående kurs BOKMÅL Side 1 av 7 NTNU Norges teknisk-naturvitenskapelige universitet Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap KONTINUASJONSEKSAMEN

Detaljer

Læringsmål for forelesningen

Læringsmål for forelesningen Læringsmål for forelesningen Objektorientering Abstrakte klasser og grensesnitt, redefinering av metoder Java-programmering Arv og bruk av abstrakte klasser Eclipse Undersøke instanser i Eclipse 1 Dagens

Detaljer

2 Om statiske variable/konstanter og statiske metoder.

2 Om statiske variable/konstanter og statiske metoder. Litt om datastrukturer i Java Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo 1 Innledning Dette notatet beskriver noe av det som foregår i primærlageret når et Javaprogram utføres.

Detaljer

INF1300 Introduksjon til databaser

INF1300 Introduksjon til databaser INF1300 Introduksjon til databaser INF1300 Introduksjon til databaser INF1300 Introduksjon til databaser INF1300 Introduksjon til databaser databaser data (transiente, persistente) informasjon interesseområdet

Detaljer

Innhold Forord Innledning Kapittel 1 Introduksjon til databaser og databasesystem

Innhold Forord Innledning Kapittel 1 Introduksjon til databaser og databasesystem Innhold Forord....................................................... 5 Innledning.................................................... 15 Databaser som basis i grunnopplæringen....................... 15

Detaljer

Eksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus

Eksekveringsrekkefølgen (del 1) Oppgave 1. Eksekveringsrekkefølgen (del 2) Kommentar til oppgave 1. } // class Bolighus // class Bygning Oppgave 1 System.out.println( Bolighus ); // class Bolighus Hva blir utskriften fra dette programmet? class Blokk extends Bolighus{ // class Blokk IN105subclassesII-1 Eksekveringsrekkefølgen

Detaljer

Kunnskapsorganisasjon og gjenfinning 1

Kunnskapsorganisasjon og gjenfinning 1 Kunnskapsorganisasjon og gjenfinning 1 Normalisering Tine Lodberg Frost Normalisering 14.10.2014 Dagens forelesning Pensum Berget, G. (2010). Relasjonsdatabaser og datamodellering (3. utg.). Oslo: Høgskolen

Detaljer

INF1000 HashMap. Marit Nybakken marnybak@ifi.uio.no 2. november 2003

INF1000 HashMap. Marit Nybakken marnybak@ifi.uio.no 2. november 2003 INF1000 HashMap Marit Nybakken marnybak@ifi.uio.no 2. november 2003 Dette dokumentet skal tas med en klype salt og forfatteren sier fra seg alt ansvar. Dere bør ikke bruke definisjonene i dette dokumentet

Detaljer

Prosedyrer. Lars Vidar Magnusson. October 26, Lars Vidar Magnusson () Forelesning i DAS October 26, / 19

Prosedyrer. Lars Vidar Magnusson. October 26, Lars Vidar Magnusson () Forelesning i DAS October 26, / 19 Prosedyrer Lars Vidar Magnusson October 26, 2011 Lars Vidar Magnusson () Forelesning i DAS 11.10.2011 October 26, 2011 1 / 19 Repetisjon om triggere og prosedyrer Triggere og prosedyrer ligner på hverandre

Detaljer

Programmering i C++ Løsningsforslag Eksamen høsten 2005

Programmering i C++ Løsningsforslag Eksamen høsten 2005 Programmering i C++ Eksamen høsten 2005 Simen Hagen Høgskolen i Oslo, Avdeling for Ingeniørutdanning 7. desember 2005 Generelt Denne eksamensoppgaven består av tre oppgaver, pluss en ekstraoppgave. Det

Detaljer

Utvikling fra kjernen og ut

Utvikling fra kjernen og ut Utvikling fra kjernen og ut PHP-arkitektur Brukergrensesnitt! inn ut Dynamisk web-side bygges opp på grunnlag av spørring mot databasen Utviklingsretning Applikasjon Virkelighetsmodell Plattform Bruker

Detaljer

EKSAMEN I INF244: OBJEKTORIENTERT PROGRAMVAREUTVIKLING I BACHELORSTUDIET I IT OG INFORMASJONSSYSTEMER BACHELORSTUDIET I IT OG ENTREPRENØRSKAP

EKSAMEN I INF244: OBJEKTORIENTERT PROGRAMVAREUTVIKLING I BACHELORSTUDIET I IT OG INFORMASJONSSYSTEMER BACHELORSTUDIET I IT OG ENTREPRENØRSKAP Høgskolen i Buskerud Avdeling for økonomi og samfunnsvitenskap 3502 Hønefoss EKSAMEN I INF244: OBJEKTORIENTERT PROGRAMVAREUTVIKLING I BACHELORSTUDIET I IT OG INFORMASJONSSYSTEMER BACHELORSTUDIET I IT OG

Detaljer

Kapittel 7: Mer om arv

Kapittel 7: Mer om arv Kapittel 7: Mer om arv Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk Forlag,

Detaljer

EKSAMENSOPPGAVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER. Faglig kontakt under eksamen: Svein Erik Bratsberg og Roger Midtstraum

EKSAMENSOPPGAVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER. Faglig kontakt under eksamen: Svein Erik Bratsberg og Roger Midtstraum Side 1 av 5 Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap EKSAMENSOPPGAVE I TDT4145 DATAMODELLERING OG DATABASESYSTEMER Faglig kontakt under eksamen:

Detaljer

INF1300 Introduksjon til databaser

INF1300 Introduksjon til databaser UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: Informasjonsbærende referansemåter Resten av realiseringsalgoritmen Sterk realisering Realisering versus modellering INF1300-31.10.2016

Detaljer

INF1000 EKSTRATILBUD. Stoff fra uke 1-5 (6) 3. oktober 2012 Siri Moe Jensen

INF1000 EKSTRATILBUD. Stoff fra uke 1-5 (6) 3. oktober 2012 Siri Moe Jensen INF1000 EKSTRATILBUD Stoff fra uke 1-5 (6) 3. oktober 2012 Siri Moe Jensen PLAN FOR DAGEN gjennomgå stoff fra uke 1-5(6), men med en litt annen tilnærming kun gjennomgått stoff, men vekt på konsepter og

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Kandidatnummer: Bokmål UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : INF1000 Grunnkurs i objektorientert programmering Eksamensdag : Torsdag 5. desember 2013 Tid for eksamen

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i INF3110/4110 Programmeringsspråk Eksamensdag: 3. desember 2004 Tid for eksamen: 9.00 12.00 Oppgavesettet er på 8 sider. Vedlegg:

Detaljer

Datamodellering 101 En tenkt høgskoledatabase

Datamodellering 101 En tenkt høgskoledatabase Datamodellering 101 En tenkt høgskoledatabase Spesifikasjoner for databasen vi skal modellere: Oversikt over studenter med: Fullt navn Klasse Studium Avdeling Brukernavn Fødselsdag Adresse Telefonnummer

Detaljer

INF1300 Introduksjon til databaser

INF1300 Introduksjon til databaser UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: Data, databaser og databasehåndteringssystemer Data versus informasjon Beskrivelse av interesseområdet Begreper og representasjon av

Detaljer

Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først

Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først Køer Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først Et nytt element legges alltid til sist i køen Skal vi ta ut et element, tar vi alltid

Detaljer

Datamodellering og databaser SQL, del 2

Datamodellering og databaser  SQL, del 2 http://www.aitel.hist.no/fag/_dmdb/ SQL, del 2 Eksempelbase side 2 Virtuelle tabeller (views) side 3-6 NULL-verdier side 7-14 UPDATE-setningen side 15-16 INSERT-setningen side 17 DELETE-setningen side

Detaljer

EKSAMEN 6102 / 6102N DATABASER

EKSAMEN 6102 / 6102N DATABASER EKSAMEN 6102 / 6102N DATABASER 06.12.2016 Tid: 4 timer (10-14) Målform: Sidetall: Hjelpemidler: Merknader: Vedlegg: Bokmål / nynorsk 13 (inkludert denne) Ingen Ingen Eksempeltabeller Sensuren finner du

Detaljer

Tilkobling og Triggere

Tilkobling og Triggere Tilkobling og Triggere Lars Vidar Magnusson October 12, 2011 Lars Vidar Magnusson () Forelesning i DAS 11.10.2011 October 12, 2011 1 / 25 Tilkobling med PHP PHP bruker databasespesifike moduler til å koble

Detaljer

Del 1: ER-modellering og databaseteori

Del 1: ER-modellering og databaseteori Del 1: ER-modellering og databaseteori (a) ER-modellering Oppgavens del 1a er delt i tre deler. I første del skal det lages et ER-diagram for databasen til firmaet Sjokoladeland. Deretter skal det lages

Detaljer

... Når internminnet blir for lite. Dagens plan: Løsning: Utvidbar hashing. hash(x) katalog. O modellen er ikke lenger gyldig ved

... Når internminnet blir for lite. Dagens plan: Løsning: Utvidbar hashing. hash(x) katalog. O modellen er ikke lenger gyldig ved Dagens plan: Utvidbar hashing (kapittel 5.6) B-trær (kap. 4.7) Abstrakte datatyper (kap. 3.1) Stakker (kap. 3.3) Når internminnet blir for lite En lese-/skriveoperasjon på en harddisk (aksesstid 7-12 millisekunder)

Detaljer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer

Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Institutt for datateknikk og informasjonsvitenskap Eksamensoppgave i TDT4145 Datamodellering og databasesystemer Faglig kontakt under eksamen: Svein Erik Bratsberg: 99539963 Roger Midtstraum: 99572420

Detaljer

Hva er en metode. Hva skjer når vi kaller en metode

Hva er en metode. Hva skjer når vi kaller en metode Hva er en metode Uke 9 - Repetisjon av metoder, klasser og objekter Innkapsling: private og public Statisk programmering vs. programmering med objeker 18 okt. 2005, Arild Waaler Inst. for informatikk,

Detaljer

public static navn_til_prosedyre() { // implementasjon av prosedyren

public static <returtype> navn_til_prosedyre(<parameter liste>) { // implementasjon av prosedyren Prosedyrer Hensikten med en prosedyre Hensikten med en prosedyre er, logisk sett, å representere en jobb eller en funksjonalitet i et eller flere programmer. Bruk av entall er viktig: vi har generelt en

Detaljer

Oppgave 3 - normalisering

Oppgave 3 - normalisering Oppgave 3 - normalisering Løsningsforslag Oppgave 3 - løsning 22.10.2014 Øvelsesoppgave 3 1. Normaliser logisk skjema fra oppgave 1 og 2 (Læringssenter) 2. Normaliser logisk skjema fra seminarøvelsen (Nøsteelskere)

Detaljer

Del 3: Noark 5-basert databasestruktur

Del 3: Noark 5-basert databasestruktur Del 3: Noark 5-basert databasestruktur Oppgaven består av en CREATE-del, en INSERT-del og en SELECT-del. CREATEdelen går ut på å lage en databasestruktur etter spesifikasjonene i Noark 5. Strukturen er

Detaljer

Plan for dagen. Vprg 4. Dagens tema - filbehandling! Strømmer. Klassen FilLeser.java. Tekstfiler

Plan for dagen. Vprg 4. Dagens tema - filbehandling! Strømmer. Klassen FilLeser.java. Tekstfiler Plan for dagen Vprg 4 LC191D Videregående programmering Høgskolen i Sør-Trøndelag Avdeling for informatikk og e-læring Anette Wrålsen Del: Intro til tekstfiler Del II: Mer om tekstfiler, Scanner-klassen

Detaljer

Høgskolen i Telemark EKSAMEN 6102 DATABASER 10.12.2015. Tid: 10-14. Hjelpemidler: Vedlegg: Eksempeldata til oppgave 1

Høgskolen i Telemark EKSAMEN 6102 DATABASER 10.12.2015. Tid: 10-14. Hjelpemidler: Vedlegg: Eksempeldata til oppgave 1 Høgskolen i Telemark EKSAMEN 6102 DATABASER 10.12.2015 Tid: 10-14 Målform: Sidetall: Hjelpemidler: Merknader: Bokmål/nynorsk 13 med forside Ingen Ingen Vedlegg: Eksempeldata til oppgave 1 Eksamensresultater

Detaljer

Høgskolen i Telemark EKSAMEN 6102 DATABASER Tid: Hjelpemidler: Vedlegg: Eksempeldata til oppgave 1

Høgskolen i Telemark EKSAMEN 6102 DATABASER Tid: Hjelpemidler: Vedlegg: Eksempeldata til oppgave 1 Høgskolen i Telemark EKSAMEN 6102 DATABASER 02.12.2014 Tid: 10-14 Målform: Sidetall: Hjelpemidler: Merknader: Bokmål/nynorsk 13 med forside Ingen Ingen Vedlegg: Eksempeldata til oppgave 1 Eksamensresultater

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Kandidatnr Eksamen i INF1000 Grunnkurs i objektorientert programmering Eksamensdag: Onsdag 10. juni 2009 Tid for eksamen: 9.00 12.00 Oppgavesettet

Detaljer

INF Innleveringsoppgave 6

INF Innleveringsoppgave 6 INF1010 - Innleveringsoppgave 6 Frist: Onsdag 16. mars, 10:00 Maks 6 poeng Om obligatorisk oppgave 4, 6 og 7 i INF1010, våren 2016: "Leger og resepter" Du skal jobbe med en problemstilling omkring leger

Detaljer

Innhold. INF1000 Høst Unified Modeling Language (UML) Unified Modeling Language (UML)

Innhold. INF1000 Høst Unified Modeling Language (UML) Unified Modeling Language (UML) Innhold Unified Modelling Language UML INF1000 Høst 2015 Uke 8: Mer objektorientert programmering Siri Moe Jensen En ny type for-løkke Organisering av mengder av objekter HashMap Valg av representasjon

Detaljer

Oblig 4Hybelhus litt mer tips enn i oppgaven

Oblig 4Hybelhus litt mer tips enn i oppgaven Oblig 4Hybelhus litt mer tips enn i oppgaven lørdag 19. okt 2013 Arne Maus Obligatorisk oppgave 4 Gulbrand Grås husleiesystem I denne oppgaven skal vi se på hans studenthus Utsyn. Utsyn består av 3 etasjer,

Detaljer

Kap3: Klassemodellering

Kap3: Klassemodellering Kap3: Klassemodellering I dag: Litt repetisjon fra sist (innledende om klassemodellen) Deretter egentlig litt mer repetisjon, men nå fra intro- Felt-/Instansvariabler og kurset i Java: Klasser og Objekt,

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i Eksamensdag: 6. juni 2006 Tid for eksamen: 1430 1730 Oppgavesettet er på 6 sider. Vedlegg: INF1010 Objektorientert programmering

Detaljer

Spesifikasjon av Lag emne

Spesifikasjon av Lag emne Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Detaljer

LC191D/LO191D Videregående programmering mai 2010

LC191D/LO191D Videregående programmering mai 2010 LC191D/LO191D Videregående programmering mai 2010 Løsningsforslag Oppgave 1 Transporttype er en tekst som er felles for klassene AnnenEgenTransport og Kollektivtransport. Vi legger den derfor i klassen

Detaljer

Versjon (vil bli endret).

Versjon (vil bli endret). Versjon 24.01.2012 (vil bli endret). Dette dokumentet bør leses før forelesningen 26. januar 2012 og er en del av «pensum». De er også laget med tanke på repetisjon. (Lysarkene som blir brukt egner seg

Detaljer

ORDBMS og OODBMS i praksis

ORDBMS og OODBMS i praksis ORDBMS og OODBMS i praksis Lars Vidar Magnusson November 2, 2011 Lars Vidar Magnusson () Forelesning i DAS 01.11.2011 November 2, 2011 1 / 18 Eksempler på ORDBMS Flere av de store databaser i dag hevder

Detaljer

TDT4100 Objektorientert programmering

TDT4100 Objektorientert programmering Eksamensoppgave i TDT4100 Objektorientert programmering Tirsdag 2. juni 2009, kl. 09:00-13:00 Oppgaven er utarbeidet av faglærer Hallvard Trætteberg og kvalitetssikrer Trond Aalberg. Kontaktperson under

Detaljer

Kapittel 8: Programutvikling

Kapittel 8: Programutvikling Kapittel 8: Programutvikling Redigert av: Khalid Azim Mughal (khalid@ii.uib.no) Kilde: Java som første programmeringsspråk (3. utgave) Khalid Azim Mughal, Torill Hamre, Rolf W. Rasmussen Cappelen Akademisk

Detaljer

Databaser. Relasjonsmodellen 2 Læreboka: Kap. 2 Relasjonsmodellen

Databaser. Relasjonsmodellen 2 Læreboka: Kap. 2 Relasjonsmodellen Databaser Relasjonsmodellen 2 Læreboka: Kap. 2 Relasjonsmodellen Tema for dagen Hva er relasjonsalgebra? Seleksjon Projeksjon Produkt Indre forening Ytterforening Settoperasjoner: union, snitt, differanse

Detaljer

INF1010 våren januar. Objektorientering i Java

INF1010 våren januar. Objektorientering i Java INF1010 våren 2017 25. januar Objektorientering i Java Om enhetstesting (Repetisjon av INF1000 og lær deg Java for INF1001 og INF1100) Stein Gjessing Hva er objektorientert programmering? F.eks: En sort

Detaljer

Dagens tema: Relasjonsmodellen (funksjonelle avhengigheter og nøkler, integritetsregler) Realisering: Fra ORM til relasjoner

Dagens tema: Relasjonsmodellen (funksjonelle avhengigheter og nøkler, integritetsregler) Realisering: Fra ORM til relasjoner UNIVERSITETET I OSLO INF1300 Introduksjon til databaser Dagens tema: Relasjonsmodellen (funksjonelle avhengigheter og nøkler, integritetsregler) Realisering: Fra ORM til relasjoner Institutt for informatikk

Detaljer

Læringsmål for forelesningen

Læringsmål for forelesningen Læringsmål for forelesningen Objektorientering Bruk av grensesnitt og implementasjoner i Collection-klasser Java-prog, kap. 14-16 i Big Java Og side 990-997 i Appendix D Collection-rammeverket og iterasjon

Detaljer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use

Detaljer

1. Finn klassene (hvilke objekter er det i problemet) 1. Dataene som beskriver problemet (hvilke objekter har vi og hvor mange klasser er det?

1. Finn klassene (hvilke objekter er det i problemet) 1. Dataene som beskriver problemet (hvilke objekter har vi og hvor mange klasser er det? Obligatorisk oppgave 3 Gulbrand Grås husleiesystem Oblig 3hus litt mer tips enn i oppgaven I denne oppgaven skal vi se på hans studenthus Utsyn. Utsyn består av 3 etasjer, nummerert fra -3. I hver etasje

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF2810 Eksamensdag: Fredag 5. juni 2015 Tid for eksamen: 14:30 (4 timer) Oppgavesettet er på 4 sider (ikke medregnet denne siden)

Detaljer

LC191D Videregående programmering Høgskolen i Sør-Trøndelag, Avdeling for informatikk og e-læring. Else Lervik, januar 2012.

LC191D Videregående programmering Høgskolen i Sør-Trøndelag, Avdeling for informatikk og e-læring. Else Lervik, januar 2012. Repetisjon innkapsling static tabell av primitiv datatype LC191D Videregående programmering Høgskolen i Sør-Trøndelag, Avdeling for informatikk og e-læring. Else Lervik, januar 2012. Objektorientert modellering

Detaljer

ADDML. Archival Data Description Markup Language. Generell del. Versjon PA 0.07 Sist oppdatert: TPD. ADDML_8_2.doc 03/03/2011 1(12)

ADDML. Archival Data Description Markup Language. Generell del. Versjon PA 0.07 Sist oppdatert: TPD. ADDML_8_2.doc 03/03/2011 1(12) ADDML Archival Data Description Markup Language Generell del Versjon PA 0.07 Sist oppdatert: 2010-09-16 TPD ADDML_8_2.doc 03/03/2011 1(12) Innledning... 4 Mål... 4 Historie... 4 Hvordan benytte ADDML...

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1000 Grunnkurs i objektorientert programmering Eksamensdag: Fredag 4. desember 2015 Tid for eksamen: 14.30 (4 timer)

Detaljer

Informasjonssystemer, DBMSer og databaser

Informasjonssystemer, DBMSer og databaser UNIVERSITETET I OSLO Informasjonssystemer, DBMSer og databaser Institutt for Informatikk INF3100-21.1.2008 Ellen Munthe-Kaas 1 Interesseområdet (UoD = Universe of Discourse) Interesseområdet er en del

Detaljer

1. SQL datadefinisjon og manipulering

1. SQL datadefinisjon og manipulering Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag SQL datadefinisjon og manipulering Tore Mallaug 7.10.2008 Lærestoffet er utviklet for faget Databaser 1. SQL datadefinisjon og manipulering

Detaljer

EKSAMEN. Emne: Webprogrammering med PHP (kont.) Webprogrammering 1 (kont.) Eksamenstid: 09.00-13.00

EKSAMEN. Emne: Webprogrammering med PHP (kont.) Webprogrammering 1 (kont.) Eksamenstid: 09.00-13.00 EKSAMEN Emnekode: ITM20606 ITF10208 Dato: Emne: Webprogrammering med PHP (kont.) Webprogrammering 1 (kont.) Eksamenstid: 09.00-13.00 05/06-2009 Hjelpemidler: 2 A4 ark (4 sider) med egenproduserte notater

Detaljer

NB!!! Veldig korte svar er gitt her. Disse burde det vært skrevet mer på ved en eksamen..

NB!!! Veldig korte svar er gitt her. Disse burde det vært skrevet mer på ved en eksamen.. Løsningsforslag Eksamen V2007 Oppgave 1 NB!!! Veldig korte svar er gitt her. Disse burde det vært skrevet mer på ved en eksamen.. Oppgave 1.1 Klasse som pakke rinne n primitiv datatype, slik at vi kan

Detaljer

Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først

Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først Køer Hva er en kø? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn først Et nytt element legges alltid til sist i køen Skal vi ta ut et element, tar vi alltid

Detaljer

HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring - AITeL

HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring - AITeL HØGSKOLEN I SØR-TRØNDELAG Avdeling for informatikk og e-læring - AITeL Kandidatnr: Eksamensdato: 15. mai 2003 Varighet: Fagnummer: Fagnavn: Klasse(r): 3 timer LO116D Programmering i Visual Basic FU Studiepoeng:

Detaljer

INF1010 - Seminaroppgaver til uke 3

INF1010 - Seminaroppgaver til uke 3 INF1010 - Seminaroppgaver til uke 3 Oppgave 1 I denne oppgaven skal vi lage et klassehiearki av drikker. Alle klassene i hiearkiet skal implementere følgende grensesnitt p u b l i c i n t e r f a c e Drikkbar

Detaljer

EKSAMEN I FAG TDT4100 Objekt-orientert programmering. Fredag 3. juni 2005 KL. 09.00 13.00

EKSAMEN I FAG TDT4100 Objekt-orientert programmering. Fredag 3. juni 2005 KL. 09.00 13.00 Side 1 av 6 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap EKSAMEN I FAG

Detaljer

Stack. En enkel, lineær datastruktur

Stack. En enkel, lineær datastruktur Stack En enkel, lineær datastruktur Hva er en stack? En datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn sist Et nytt element legges alltid på toppen av stakken Skal vi

Detaljer

klassen Vin må få en ny variabel Vin neste alle personvariable (personpekere) i listeklassen må byttes til Vin

klassen Vin må få en ny variabel Vin neste alle personvariable (personpekere) i listeklassen må byttes til Vin INF1010 forelesning Lenkelister II Dette skrivet inneholder en oversikt over det jeg planlegger å forelese på andre forlesning om lenkelister. Det inneholder stort sett programeksempler med kommentarer

Detaljer

UNIVERSITETET I OSLO SQL. Structured Query Language. (The intergalactic dataspeak) Institutt for Informatikk. INF Ragnar Normann 1

UNIVERSITETET I OSLO SQL. Structured Query Language. (The intergalactic dataspeak) Institutt for Informatikk. INF Ragnar Normann 1 UNIVERSITETET I OSLO SQL Structured Query Language (The intergalactic dataspeak) Institutt for Informatikk INF3100 1.2.2005 Ragnar Normann 1 SQL SQL Structured Query Language er et deklarativt språk for

Detaljer

Hva er en stack? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn sist

Hva er en stack? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn sist Stack Hva er en stack? En lineær datastruktur der vi til enhver tid kun har tilgang til elementet som ble lagt inn sist Et nytt element legges alltid på toppen av stakken Skal vi ta ut et element, tar

Detaljer

Oppgave 1 Datamodellering 22 %

Oppgave 1 Datamodellering 22 % Side 1 av 8 Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap LØSNINGSFORSLAG TIL EKSAMENSOPPGAVE I FAG TDT4145 DATAMODELLERING OG DATABASESYSTEMER Eksamensdato:

Detaljer

INF1010 Arv. Marit Nybakken marnybak@ifi.uio.no 2. februar 2004

INF1010 Arv. Marit Nybakken marnybak@ifi.uio.no 2. februar 2004 INF1010 Arv Marit Nybakken marnybak@ifi.uio.no 2. februar 2004 Motivasjon Arv bruker vi så vi skal slippe å skrive oss i hjel. Når vi programmerer, prøver vi gjerne å modellere en del av verden ved hjelp

Detaljer

Eksamen Objektorientert Programmering 2013

Eksamen Objektorientert Programmering 2013 Eksamen Objektorientert Programmering 2013 Høgskolen i Østfold 2013-01-07 Emnekode Emne ITF10611 Dato 2013-01-07 Eksamenstid 09:00-13:00 Hjelpemidler Faglærer Objektorientert Programmering To A4-ark (fire

Detaljer