Oppsummering – IDATT2002

På eksamen v26: Ingen rene teorispørsmål. Teorien kommer som del av case-oppgaver. Du skal bruke kunnskapen, ikke gjengi definisjoner. Ingen MongoDB-kode, ingen CREATE TABLE.

// Normalformer

Tre regler du sjekker i rekkefølge. Hver form bygger på den forrige.

Huskeregel: Hvert attributt skal avhenge av PK, hele PK, og kun PK.

Hva betyr atomisk?

Atomisk betyr "ikke delbar" – én verdi per celle, ikke en liste eller flere ting pakket sammen.

-- IKKE atomisk:
telefoner = "91234567, 98765432"   ← liste i én celle
adresse   = "Kongens gate 5, Oslo" ← flere ting i én celle

-- Atomisk:
telefon = "91234567"               ← én verdi per rad

1NF – ingen lister i celler

Alle verdier er atomiske. Ingen repeterende grupper.

-- BRYTER 1NF:
STUDENT(student_id, navn, telefoner)  -- telefoner = "91234567, 98765432"

-- I 1NF:
STUDENT(student_id, navn)
STUDENT_TELEFON(student_id*, telefon)

Hva er sammensatt PK?

En PK som består av to eller flere kolonner i kombinasjon. Verken kolonne A eller B er unik alene – men kombinasjonen er det.

-- Sammensatt PK: (student_id, kurs_id) sammen er unike
PÅMELDING(student_id*, kurs_id*, dato)
-- En student kan melde seg på mange kurs
-- Et kurs kan ha mange studenter
-- Men en student kan bare melde seg på samme kurs én gang

2NF – ingen delvise avhengigheter

Kun relevant når PK er sammensatt. Alle attributter må avhenge av hele PK, ikke bare en del.

-- BRYTER 2NF: kurs_navn avhenger kun av kurs_id, ikke av begge
PÅMELDING(student_id*, kurs_id*, kurs_navn, dato)

-- I 2NF:
KURS(kurs_id, kurs_navn)
PÅMELDING(student_id*, kurs_id*, dato)

Hva er transitiv avhengighet?

A → B → C, der A er PK og B er ikke-nøkkel. C avhenger av A, men bare gjennom B – ikke direkte.

ANSATT(ansatt_id, navn, avd_id, avd_navn)
-- ansatt_id → avd_id → avd_navn  ← transitiv
-- avd_navn avhenger av avd_id, ikke direkte av PK

-- Problemet: endre avdelingsnavnet → må oppdatere alle ansatt-rader

3NF – ingen transitive avhengigheter

Ingen ikke-nøkkel-attributt skal avhenge av et annet ikke-nøkkel-attributt.

-- BRYTER 3NF:
ANSATT(ansatt_id, navn, avd_id, avd_navn)

-- I 3NF:
AVDELING(avd_id, avd_navn)
ANSATT(ansatt_id, navn, avd_id*)

Slik vurderer du en tabell på eksamen

Still deg disse spørsmålene i rekkefølge:

Er alle verdier atomiske? → 1NF
Er PK sammensatt? Hvis ja – avhenger alle attributter av hele PK? → 2NF
Avhenger noe attributt av et annet ikke-nøkkel-attributt? → 3NF

// ACID

Fire egenskaper som garanterer pålitelige transaksjoner. Gjelder alle relasjonsdatabaser (MySQL, PostgreSQL, MariaDB). Du trenger ikke gjøre noe spesielt – databasen håndterer det i bakgrunnen.

Bokstav	Navn	Betyr
A	Atomicity	Alt eller ingenting. Krasjer det midt i → alt rulles tilbake (ROLLBACK)
C	Consistency	Databasen går alltid fra én gyldig tilstand til en annen. Alle regler overholdes
I	Isolation	Samtidige transaksjoner forstyrrer ikke hverandre. Styres med isolasjonsnivå
D	Durability	Committed data overlever krasj og strømbrudd – skrevet til disk

-- Slik bruker du transaksjoner eksplisitt:
BEGIN TRANSACTION;
  UPDATE KONTO SET saldo = saldo - 500 WHERE konto_id = 'A';
  UPDATE KONTO SET saldo = saldo + 500 WHERE konto_id = 'B';
COMMIT;    -- alt gikk bra
-- eller:
ROLLBACK;  -- noe gikk galt, angre alt

NoSQL og ACID: NoSQL-databaser har svakere eller ingen ACID-garantier som standard. De prioriterer hastighet og skalering over sterk konsistens.

// Transaksjons-problemer

Oppstår kun ved samtidig bruk av databasen – mange brukere/prosesser på samme tid. Isolation i ACID er det som beskytter mot dem, styrt av isolasjonsnivå.

De fem problemene

Problem	Hva skjer	Nøkkelord
Dirty read	T1 leser data T2 har endret men ikke committert. T2 gjør ROLLBACK – T1 har lest data som aldri eksisterte	Leste ucommittet data
Non-repeatable read	T1 leser en rad. T2 endrer og committer. T1 leser samme rad igjen og får en annen verdi	Samme rad, ulik verdi
Phantom read	T1 kjører en spørring og får N rader. T2 setter inn nye rader. T1 kjører samme spørring og får N+M rader	Samme spørring, flere rader
Lost update	T1 og T2 leser begge samme verdi. Begge skriver basert på den. T2s commit overskriver T1s endring	Begge leste samme, én forsvant
Deadlock	T1 venter på T2s lås. T2 venter på T1s lås. Ingen kan fortsette. Databasen velger én som offer og ruller den tilbake	Begge venter på hverandre

Hva beskytter mot hva?

Problem	Løses med
Dirty read	✅ Isolasjonsnivå (READ COMMITTED eller høyere)
Non-repeatable read	✅ Isolasjonsnivå (REPEATABLE READ eller høyere)
Phantom read	✅ Isolasjonsnivå (SERIALIZABLE)
Lost update	⚠️ Delvis isolasjonsnivå – best løst med eksplisitt låsing (SELECT ... FOR UPDATE)
Deadlock	❌ Ikke isolasjonsnivå – databasen oppdager og ruller én transaksjon tilbake automatisk

På eksamen: Du trenger ikke pugge isolasjonsnivåene med navn. Det viktige er å kjenne igjen de fem problemene og vite hva som skiller dem.

// NoSQL

NoSQL = "Not only SQL". Databaser som ikke bruker relasjonsmodellen. Fire hovedtyper:

Type	Eksempel	Brukes til
Dokumentdatabase	MongoDB	Fleksible JSON-dokumenter der struktur varierer mellom rader
Nøkkel-verdi	Redis	Lynrask oppslag på nøkkel – caching, sesjoner
Graf	Neo4j	Relasjoner mellom noder – sosiale nettverk, anbefalinger
Kolonnebasert	Cassandra	Enorme datamengder – logg, sensordata

SQL vs NoSQL

	SQL	NoSQL
Skjema	Fast, definert på forhånd	Fleksibelt, varierer per rad
Skalering	Vertikalt (kraftigere server)	Horisontalt (flere servere)
Konsistens	Sterk (ACID)	Ofte svakere
Passer til	Bank, HR, ordre – strukturert data	Logg, sosiale medier, sensorer

På eksamen: Ingen MongoDB-kode. Du skal vite hva NoSQL er, hvilke fire typer som finnes, og kunne argumentere for/mot i en gitt situasjon.

// JSON i databaser

Lagre semi-strukturert data direkte i én kolonne. Nyttig når strukturen varierer mellom rader.

-- En rad kan ha én struktur:
{ "inntrykk": "Positiv", "teknisk_score": 4, "språk": ["Python", "SQL"] }

-- En annen rad kan ha helt andre felt:
{ "inntrykk": "Nøytral", "kommentar": "Trenger mer erfaring" }

Fordeler	Ulemper
Fleksibel struktur per rad	Vanskelig å søke på enkeltfelt
Slipper å endre tabellskjema	Ingen referanseintegritet for innholdet
Bra når data leses samlet	Bryter med normalisering

Tommelfingerregel: Varierende struktur + sjelden filtrering på enkeltfelt → JSON. Fast struktur + hyppige spørringer → normaliser.

På eksamen v26: Du skal ikke skrive JSON-kode. Du skal kunne argumentere for/mot JSON i en gitt kontekst.

📐 Les mer om normalisering 📝 Ta mock-eksamen