Mock-eksamen – IDATT2002

Eksamensoppgave i IDATT2002 – Databaser

Dato:	22. mai 2026
Tid:	09:00 – 13:00 (4 timer)
Hjelpemidler:	Kode E – Ingen hjelpemidler tillatt
Vekting:	Oppgave 1: 40% \| Oppgave 2: 40% \| Oppgave 3: 20%

Les oppgavene nøye og gjør dine egne antagelser. Presiser i besvarelsen hvilke forutsetninger du har lagt til grunn. Ingen håndtegninger – alt besvares her. Fasit vises når du klikker «Lever eksamen» nederst.

TID IGJEN

4:00:00

Oppgave 1 – Datamodellering og relasjonsmodellen

40%

ER-diagrammet nedenfor er en forenklet database for et biblioteksystem. Systemet holder rede på bøker, forfattere, medlemmer og utlån. En bok kan ha én eller flere forfattere, og en forfatter kan ha skrevet flere bøker. Et medlem kan låne flere bøker over tid, og samme bok kan lånes ut flere ganger (men kun til én person av gangen). En bok tilhører én sjanger. En utlånsregistrering har en utlånsdato og en innleveringsfrist.

SJANGER sjangerNavn beskrivelse 1..1 ↕ tilhører ↕ 0..* BOK tittel utgivelsesår antall_eksemplarer 0..* ↔ skrevet_av ↔ 1..* FORFATTER fornavn etternavn nasjonalitet 0..* ↕ låner ↕ 1..1 UTLÅN utlånsdato innleveringsfrist returnert_dato 1..1 ↔ registrert_på ↔ 0..* MEDLEM navn epost telefon registreringsdato

Oppgave 1a) 10p

Primærnøkler er ikke tegnet inn i ER-diagrammet. Foreslå en primærnøkkel for hver entitetstype. Du kan utvide med nye attributter hvis du synes det er hensiktsmessig. Begrunn kort forslagene dine.

Oppgave 1b) 10p

Oversett ER-diagrammet til relasjonell form. Understrek primærnøkler og marker fremmednøkler med *. Du skal ikke skrive CREATE TABLE eller foreslå datatyper.

Oppgave 1c) flervalg

En bok kan ha mange forfattere, og en forfatter kan ha skrevet mange bøker. Hvilken tabellstruktur er riktig oversettelse av denne mange-til-mange-relasjonen?

Oppgave 1d) 10p

Biblioteket ønsker å registrere hvilke sjangere et medlem er interessert i, slik at de kan få anbefalinger. Et medlem kan være interessert i null eller flere sjangere. Foreslå med tekst en utvidelse av databasen for dette, og vis hvilke endringer i løsningen fra 1b) dette medfører. Du skal ikke tegne et nytt ER-diagram.

Oppgave 2 – SQL

40%

Tabellene nedenfor representerer en forenklet database for et kinoanlegg. Primærnøkler er streket under, fremmednøkler er markert med *.

KINO (kino_id, navn, by, antall_saler) SAL (sal_id, kino_id*, navn, kapasitet) FILM (film_id, tittel, sjanger, varighet_min, aldersgrense) VISNING (visning_id, film_id*, sal_id*, dato, tidspunkt, pris) BILLETT (billett_id, visning_id*, sete_nr, kjøpt_dato, rabattkode)

En visning er én konkret forestilling av én film i én sal på en gitt dato og tidspunkt. Et billett er knyttet til én visning. Attributtet rabattkode er NULL hvis ingen rabatt er brukt.

Oppgave 2a) flervalg

Skriv ut det totale antallet visninger kinoen med navn 'Filmpalasset' har i juni 2026. Hvilken spørring er riktig?

Oppgave 2b) 8p

Skriv ut tittel, dato og tidspunkt for alle visninger av filmer med sjanger = 'komedie' som har solgt mer enn 50 billetter, sortert på dato stigende.

Oppgave 2c) 8p

Finn tittel på alle filmer som ikke har noen visninger registrert i databasen.

Oppgave 2d) 8p

Lag et VIEW kalt POPULAERE_FILMER som viser film_id, tittel og totalt antall solgte billetter for alle filmer som har solgt mer enn 100 billetter totalt på tvers av alle visninger.

Oppgave 2e) flervalg

Du vil finne saler som har kapasitet til minst 100 seter, men der ingen billetter er solgt til noen visning i den salen. Hvilken tilnærming er riktig?

Oppgave 3 – Diverse

20%

Oppgave 3a) flervalg

Tabellen BILLETT har attributtet rabattkode som kan inneholde ulike typer rabattdata – noen billetter har en tekstkode, andre har en prosentsats, andre har ingen rabatt (NULL). En utvikler foreslår å erstatte rabattkode med en JSON-kolonne rabatt_info som kan inneholde varierende struktur per rad. Hva er den viktigste fordelen med dette?

Oppgave 3b) 10p

Er tabellen VISNING normalisert til og med 3NF? Gi en kort tekstlig begrunnelse med eventuelle antagelser.

VISNING (visning_id, film_id*, sal_id*, dato, tidspunkt, pris)

Oppgave 3c) flervalg

En billettkjøp-transaksjon gjør følgende: (1) sjekker at setet ikke er opptatt, (2) setter inn en ny rad i BILLETT. Systemet krasjer mellom steg 1 og 2. Hvilken ACID-egenskap sikrer at ingen halv transaksjon ligger igjen i databasen?

Oppgave 3d) flervalg

To brukere prøver å kjøpe siste ledige sete (sete_nr 14) på samme visning samtidig. Transaksjon T1 leser at sete 14 er ledig. Transaksjon T2 leser at sete 14 er ledig. T1 kjøper setet og committer. T2 kjøper også setet og committer – nå er setet dobbeltsolgt. Hvilket problem er dette et eksempel på?

Når du er ferdig, klikk «Lever eksamen» for å se fasit og riktige svar på flervalgsspørsmålene.

FLERVALGSCORE

// Fasit – Oppgave 1

1a) Primærnøkler

SJANGER: sjangerNavn er naturlig PK (forutsatt unike sjangernavnavn). Alternativt surrogat-id sjanger_id.
BOK: Surrogat-id bok_id anbefales – tittel er ikke unik (samme tittel kan gis ut flere ganger).
FORFATTER: Surrogat-id forfatter_id – navn er ikke unik.
UTLÅN: Surrogat-id utlan_id. Alternativt sammensatt av bok_id* + medlem_id* + utlånsdato, men surrogat er enklere.
MEDLEM: Surrogat-id medlem_id, eller epost hvis den garanteres unik.

1b) Relasjonell form

SJANGER(sjanger_id, sjangerNavn, beskrivelse) BOK(bok_id, tittel, utgivelsesår, antall_eksemplarer, sjanger_id*) FORFATTER(forfatter_id, fornavn, etternavn, nasjonalitet) BOK_FORFATTER(bok_id*, forfatter_id*) MEDLEM(medlem_id, navn, epost, telefon, registreringsdato) UTLÅN(utlan_id, utlånsdato, innleveringsfrist, returnert_dato, bok_id*, medlem_id*)

BOK_FORFATTER er koblingstabellen for M:N-relasjonen mellom BOK og FORFATTER. UTLÅN kobler BOK og MEDLEM – en M:N med egne attributter.

1c) Flervalg – riktig svar: B

En mange-til-mange-relasjon oversettes alltid med en koblingstabell. BOK_FORFATTER(bok_id*, forfatter_id*) med sammensatt PK er den korrekte løsningen. Alternativ A bryter 1NF (liste i én celle).

1d) Utvidelse – interesser

Legg til en koblingstabell for M:N-relasjonen mellom MEDLEM og SJANGER:

MEDLEM_SJANGER(medlem_id*, sjanger_id*)

Ingen endringer i eksisterende tabeller er nødvendig – bare legg til den nye koblingstabellen.

// Fasit – Oppgave 2

2a) Flervalg – riktig svar: B

dato og kino-navn ligger i ulike tabeller – du må joine VISNING → SAL → KINO. Alternativ A feiler fordi navn ikke finnes i VISNING.

2b) Komedier med over 50 billetter

SELECT f.tittel, v.dato, v.tidspunkt FROM FILM f INNER JOIN VISNING v ON f.film_id = v.film_id INNER JOIN BILLETT b ON v.visning_id = b.visning_id WHERE f.sjanger = 'komedie' GROUP BY v.visning_id, f.tittel, v.dato, v.tidspunkt HAVING COUNT(b.billett_id) > 50 ORDER BY v.dato ASC;

2c) Filmer uten visninger

SELECT tittel FROM FILM WHERE film_id NOT IN (SELECT film_id FROM VISNING); -- Alternativt med LEFT JOIN: SELECT f.tittel FROM FILM f LEFT JOIN VISNING v ON f.film_id = v.film_id WHERE v.visning_id IS NULL;

2d) VIEW – populære filmer

CREATE VIEW POPULAERE_FILMER AS SELECT f.film_id, f.tittel, COUNT(b.billett_id) AS antall_solgte FROM FILM f INNER JOIN VISNING v ON f.film_id = v.film_id INNER JOIN BILLETT b ON v.visning_id = b.visning_id GROUP BY f.film_id, f.tittel HAVING COUNT(b.billett_id) > 100;

2e) Flervalg – riktig svar: B

Billetter er ikke direkte knyttet til SAL – du må gå SAL → VISNING → BILLETT. Alternativ A er feil fordi BILLETT ikke har sal_id direkte. Alternativ D finner saler uten visninger, ikke saler uten billetter – det er ikke det samme.

// Fasit – Oppgave 3

3a) Flervalg – riktig svar: B

Fordelen med JSON her er fleksibel struktur per rad – noen rader kan ha {type: "prosentkode", verdi: 15}, andre {type: "kampanjekode", kode: "SOMMER26"}, uten å endre tabellskjemaet. Ulemper: vanskeligere å søke på, ingen RI for innholdet.

3b) Er VISNING i 3NF?

Ja, VISNING(visning_id, film_id*, sal_id*, dato, tidspunkt, pris) er i 3NF. PK er visning_id. Alle andre attributter (film_id, sal_id, dato, tidspunkt, pris) er direkte avhengige av visning_id – ingen er avhengig av et annet ikke-nøkkelattributt. Det finnes ingen transitiv avhengighet.

Merk: Man kan diskutere om pris avhenger av sal eller film, men slik tabellen er definert antas pris å være en egenskap ved akkurat denne visningen.

3c) Flervalg – riktig svar: C

Atomicity = alt eller ingenting. Krasjer systemet midt i en transaksjon, rulles alle deloperasjoner tilbake. Ingen halv INSERT blir igjen.

3d) Flervalg – riktig svar: D

Dette er et lost update-problem: begge leste samme tilstand (sete ledig), begge skrev basert på den tilstanden, og T1s endring ble overskrevet av T2. Dirty read ville vært hvis T2 leste en ucommittet endring. Non-repeatable read ville vært hvis T2 leste setet på nytt og fikk en annen verdi.

🏠 Hjem