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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Datamodellering: ER-modeller ER = Enitity-Relationship del 1: Notasjon og oversetting av ulike ER-modeller til tilsvarende relasjonsmodeller

Datamodellering: ER-modeller ER = Enitity-Relationship del 1: Notasjon og oversetting av ulike ER-modeller til tilsvarende relasjonsmodeller LC238D http://www.aitel.hist.no/fag/_dmdb/ Datamodellering: ER-modeller ER = Enitity-Relationship del 1: Notasjon og oversetting av ulike ER-modeller til tilsvarende relasjonsmodeller ER-modellen, intro.

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 Side 1 Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1010 Objektorientert programmering Eksamensdag: Tirsdag 12. juni 2012 Tid for eksamen: 9:00 15:00 Oppgavesettet er

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

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

Objektorientering i VB en introduksjon

Objektorientering i VB en introduksjon Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Objektorientering i VB en introduksjon Oppdatert av Atle Nes Objektorientering i VB en introduksjon Resymé: Visual Basic.NET er et objektorientert

Detaljer

UNIVERSITETET I BERGEN Det matematisk-naturvitenskapelige fakultet

UNIVERSITETET I BERGEN Det matematisk-naturvitenskapelige fakultet UNIVERSITETET I BERGEN Det matematisk-naturvitenskapelige fakultet Eksamen i emnet INF101/INF101-F - Programmering 2 Fredag 10. juni 2011, kl. 09-14 Bokmål Tillatte hjelpemidler: alle skrevne og trykte.

Detaljer

EKSAMENSOPPGAVE. : INF-1400 Objektorientert programmering. Oppgavesettet er på 5 sider inklusiv forside

EKSAMENSOPPGAVE. : INF-1400 Objektorientert programmering. Oppgavesettet er på 5 sider inklusiv forside FAKULTET FOR NATURVITENSKAP OG TEKNOLOGI! EKSAMENSOPPGAVE Eksamen i : INF-1400 Objektorientert programmering Dato : Mandag 27. mai 2013 Tid : 0900 1300 Sted : Åsgårdvegen 9 Tillatte hjelpemidler : Ingen

Detaljer

Metaspråket for å beskrive grammatikk

Metaspråket for å beskrive grammatikk 1 SQL-syntaks Korrekt språkbruk bygger på et sett av regler. Eksempler: En SQL utvalgsspørring inneholder alltid ordene SELECT og FROM, mens WHERE og tilhørende betingelse er valgfri. Etter SELECT kan

Detaljer

J2EE. CMP Entity Beans, Transaksjoner, JSP

J2EE. CMP Entity Beans, Transaksjoner, JSP J2EE CMP Entity Beans, Transaksjoner, JSP CMP Entity Beans Container Managed Persistence Container sin oppgave å lagre innholdet i EJB til varig lager (typisk DB). Implementasjonsklassen lages abstrakt.

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

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

notater Gule lapper Mine Et praktisk eksempel med objekter IT2 Læreplansmål Gløer Olav Langslet Sandvika VGS

notater Gule lapper Mine Et praktisk eksempel med objekter IT2 Læreplansmål Gløer Olav Langslet Sandvika VGS Mine notater Gløer Olav Langslet Sandvika VGS Et praktisk eksempel med objekter Vi kjenner alle til korktavlen med gule lapper. Vi henger opp en lapp for at vi selv eller andre skal huske eller bli minnet

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

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

TDT4102 - Prosedyre- og objektorientert programmering

TDT4102 - Prosedyre- og objektorientert programmering Konteringseksamen i TDT4102 - Prosedyre- og objektorientert programmering Lørdag 8. august 2009 Kontaktperson under eksamen: Hallvard Trætteberg Eksamensoppgaven er utarbeidet av Trond Aalberg Språkform:

Detaljer

HØGSKOLEN I SØR-TRØNDELAG

HØGSKOLEN I SØR-TRØNDELAG HØGSKOLEN I SØR-TRØNDELAG AVDELING FOR TEKNOLOGI Institutt for databehandling Kandidat nr.: Eksamensdato: 09.05.2005 Varighet: 0900-1200 (3 timer) Fagnummer: LO323D Fagnavn: Databaser Klasse(r): NETT 2006V

Detaljer

Objective-C. Shermila Thillaiampalam 01.11.2011

Objective-C. Shermila Thillaiampalam 01.11.2011 Objective-C Shermila Thillaiampalam 01.11.2011 Innhold 1 Kort om Objective-C 4 1.1 Xcode................................ 4 2 Historie 5 2.1 Programmeringsspråket C..................... 5 2.2 Smalltalk..............................

Detaljer

Ordliste. Obligatorisk oppgave 1 - Inf 1020

Ordliste. Obligatorisk oppgave 1 - Inf 1020 Ordliste. Obligatorisk oppgave 1 - Inf 1020 I denne oppgaven skal vi tenke oss at vi vil holde et register over alle norske ord (med alle bøyninger), og at vi skal lage operasjoner som kan brukes til f.

Detaljer

TDT4100 Objektorientert programmering

TDT4100 Objektorientert programmering Eksamensoppgave i TDT4100 Objektorientert programmering Mandag 6. august 2012, kl. 15:00-19:00 Oppgaven er utarbeidet av faglærer Hallvard Trætteberg og kvalitetssikrer Rune Sætre. Kontaktperson under

Detaljer

En lett innføring i foreninger (JOINs) i SQL

En lett innføring i foreninger (JOINs) i SQL En lett innføring i foreninger (JOINs) i SQL Noen ord om forening (JOIN)! 2 JOINs til gjennomgang! 3 1. INNER JOIN! 3 Eksempel på [INNER] JOIN! 4 NATURAL JOIN! 5 Eksempel på NATURAL JOIN! 5 2. LEFT [OUTER]

Detaljer

SQL Introduksjonskurs. Oversikt

SQL Introduksjonskurs. Oversikt SQL Introduksjonskurs Oversikt Oversikt 2/7 Introduksjon til datamodellering Normalisering Logisk skjema til Database Strukturelle operasjoner Operasjoner mot data Kontrolloperasjoner Aggregering og indekser

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: AITeL Eksamensdato: 4.mai 2011 Varighet: 0900-1300 Emnekode: Emnenavn: Klasser: LV195D Objektorientert programmering i C++ Nettstudenter

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: AITeL Eksamensdato: 2.desember 2009 Varighet: 0900-1300 Emnekode: Emnenavn: Klasse(r): LO191D / LC191D LO191D Videregående programmering

Detaljer

LO191D/LC191D Videregående programmering

LO191D/LC191D Videregående programmering LO191D/LC191D Videregående programmering Eksamen mai 2012 Løsningsforslag Oppgave 1 Klassen Destinasjon: // Oppgaven er uklar på hva som skal inn i klassen Destinasjon. // Her følger en minimumsutgave

Detaljer

PG4200 Algoritmer og datastrukturer Forelesning 7

PG4200 Algoritmer og datastrukturer Forelesning 7 PG4200 Algoritmer og datastrukturer Forelesning 7 Lars Sydnes, NITH 19. mars 2014 I. TERMINOLOGI FOR TRÆR TRÆR Lister: Lineære Trær: Hierarkiske Modell / Språk: Bestanddeler: Noder, forbindelser. Forbindelse

Detaljer

Argumenter fra kommandolinjen

Argumenter fra kommandolinjen Argumenter fra kommandolinjen Denne veiledningen er laget for å vise hvordan man kan overføre argumenter fra kommandolinjen til et program. Hvordan transportere data fra en kommandolinje slik at dataene

Detaljer

Andre sett obligatoriske oppgaver i INF3100 V2013

Andre sett obligatoriske oppgaver i INF3100 V2013 Andre sett obligatoriske oppgaver i INF3100 V2013 Oppgavesettet skal i utgangspunktet løses av grupper på to og to studenter som leverer felles besvarelse. Vi godkjenner også individuelle besvarelser,

Detaljer

Satsvise, interaktive, sanntids/innbakte systemer. Arne Maus, Ifi. Oppdeling av både program og data på flere maskiner

Satsvise, interaktive, sanntids/innbakte systemer. Arne Maus, Ifi. Oppdeling av både program og data på flere maskiner Typer av systemer, Arkitektur og Databaser Arne Maus, Ifi med takk til Dag Lorås(Visma) og Ian Sommerville for delvis lån av gamle foiler Dagens forelesning. Ulike typer systemer Satsvise, interaktive,

Detaljer

Dagens tema. C-programmering. Nøkkelen til å forstå C-programmering ligger i å forstå hvordan minnet brukes.

Dagens tema. C-programmering. Nøkkelen til å forstå C-programmering ligger i å forstå hvordan minnet brukes. Dagens tema Dagens tema C-programmering Nøkkelen til å forstå C-programmering ligger i å forstå hvordan minnet brukes. Adresser og pekere Parametre Vektorer (array-er) Tekster (string-er) Hvordan ser minnet

Detaljer

Eksamen i Internetteknologi Fagkode: ITE1526

Eksamen i Internetteknologi Fagkode: ITE1526 Høgskolen i Narvik Side 1 av 5 Eksamen i Internetteknologi Fagkode: ITE1526 Tid: Torsdag 15.06.06, 9:00-12:00 Tillatte hjelpemidler: Alle trykte og skrevne hjelpemidler tillatt. Eksamen består av 1 oppgave

Detaljer

Persistens. Erik Arisholm. Institutt for informatikk Erik Arisholm 18.03.2009. INF1050-persistens-1

Persistens. Erik Arisholm. Institutt for informatikk Erik Arisholm 18.03.2009. INF1050-persistens-1 Persistens Erik Arisholm INF1050-persistens-1 Samling av trådene Systemutvikling som helhet 1. Systemutvikling: motivasjon... Jo Hannay, Simula & Ifi 2. Systemutviklingsprosessen... Rune Steinberg, Visma

Detaljer

EKSAMEN. Objektorientert programmering

EKSAMEN. Objektorientert programmering EKSAMEN Emnekode: ITF 10609 Dato: 13.mai 2009 Emne: Objektorientert programmering Eksamenstid: kl 09.00 til kl 12.00 Hjelpemidler: 2 A4-ark med valgfritt innhold på begge sider. Faglærere: Tom Heine Nätt

Detaljer

Arne Maus, Ifi. delvis lån av gamle foiler

Arne Maus, Ifi. delvis lån av gamle foiler Typer av systemer, Arkitektur og Databaser Arne Maus, Ifi med takk til Dag Lorås(Visma) og Ian Sommerville for delvis lån av gamle foiler INF 1050 Systemutvikling v2010 1 Dagens forelesning 1. Ulike typer

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

1. Datamodellering. 1.1. Kommentarer til læreboka

1. Datamodellering. 1.1. Kommentarer til læreboka Tore Mallaug 20.10.2009 Opphavsrett: Forfatter og Stiftelsen TISIP Lærestoffet er utviklet for fagene LN323D Databaser 1. Datamodellering Resymé: Denne leksjonen viser et par eksempler på ER-modellering

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO 1 UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : IN 115 Eksamensdag : Lørdag 20 mai, 2000 Tid for eksamen : 09.00-15.00 Oppgavesettet er på : 5 sider Vedlegg : Intet. Tillatte

Detaljer

INF1000 - Uke 10. Ukesoppgaver 10 24. oktober 2012

INF1000 - Uke 10. Ukesoppgaver 10 24. oktober 2012 INF1000 - Uke 10 Ukesoppgaver 10 24. oktober 2012 Vanlige ukesoppgaver De første 4 oppgavene (Oppgave 1-4) handler om HashMap og bør absolutt gjøres før du starter på Oblig 4. Deretter er det en del repetisjonsoppgaver

Detaljer

TDT4100 Objektorientert programmering

TDT4100 Objektorientert programmering Eksamensoppgave i TDT4100 Objektorientert programmering Torsdag 12. august 2010, kl. 09:00-13:00 Oppgaven er utarbeidet av faglærer Hallvard Trætteberg og kvalitetssikret av Svein Erik Bratsberg. Kontaktperson

Detaljer

INF1300 Relasjonsalgebra og SQL, mengder og bager. Lysark for forelesning v. 2.1

INF1300 Relasjonsalgebra og SQL, mengder og bager. Lysark for forelesning v. 2.1 INF1300 Relasjonsalgebra og SQL, mengder og bager. Lysark for forelesning v. 2.1 Dagens temaer Relasjonsalgebraen Renavning Algebra Heltallsalgebra Klassisk relasjonsalgebra Mengdeoperatorer Union Snitt

Detaljer

INF1000 Prøveeksamen Oppgave 7 og 9

INF1000 Prøveeksamen Oppgave 7 og 9 INF1000 Prøveeksamen Oppgave 7 og 9 Høst 2015 Siri Moe Jensen 7a) Skriv en klasse Gave med to variabler som forteller hva som er i gaven, og hvor mye den har kostet. Klassen skal ha en konstruktør med

Detaljer

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Øving 10 Frist: 2014-04-11 Mål for denne øvinga:

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i : INF3100/INF4100 Databasesystemer Eksamensdag : Tirsdag 8. juni 2004 Tid for eksamen : 09.00-12.00 Oppgavesettet er på : 5 sider

Detaljer

Eksamen i Internetteknologi Fagkode: IVA1379

Eksamen i Internetteknologi Fagkode: IVA1379 Høgskolen i Narvik Side 1 av 5 Eksamen i Internetteknologi Fagkode: IVA1379 Tid: Mandag, 07.06.04, 9:00-12:00 Tillatte hjelpemidler: Alle trykte og skrevne hjelpemidler tillatt. Eksamen består av 4 oppgaver

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 - AITeL Kandidatnr: Eksamensdato: 4.mai 2011 Varighet: 0900-1300 Emnekode: Emnenavn: Klasse(r): LO191D / LC191D Campus: LC191D Videregående

Detaljer

Fakultet for informasjonsteknologi, Tentativt løsningsforslag TDT4102 Prosedyre og objektorientert programmering. Fredag 6. juni 2008 Kl. 09.00 13.

Fakultet for informasjonsteknologi, Tentativt løsningsforslag TDT4102 Prosedyre og objektorientert programmering. Fredag 6. juni 2008 Kl. 09.00 13. BOKMÅ L Side 1 av 16 NTNU Norges teknisk-naturvitenskapelige universitet Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Tentativt løsningsforslag

Detaljer

Algoritmeanalyse. (og litt om datastrukturer)

Algoritmeanalyse. (og litt om datastrukturer) Algoritmeanalyse (og litt om datastrukturer) Datastrukturer definisjon En datastruktur er den måten en samling data er organisert på. Datastrukturen kan være ordnet (sortert på en eller annen måte) eller

Detaljer

EKSAMEN med løsningsforslag

EKSAMEN med løsningsforslag EKSAMEN med løsningsforslag Emnekode: ITF20006 Emne: Algoritmer og datastrukturer Dato: Eksamenstid: 20. mai 2009 kl 09.00 til kl 13.00 Hjelpemidler: 8 A4-sider (4 ark) med egne notater Kalkulator Faglærer:

Detaljer