// Normalformer – rask oversikt
På eksamen v26: Ingen «forklar hva 3NF er». Du får en tabell og skal vurdere om den er i 3NF, og eventuelt rette den. Teori er bakt inn i case.
1. Normalform (1NF)
En tabell er i 1NF hvis:
- Alle attributtverdier er atomiske (ikke lister eller sammensatte verdier)
- Ingen repeterende grupper
- Alle rader er unike (det finnes en PK)
-- BRYTER 1NF: telefoner er en liste
KUNDE(kunde_id, navn, telefoner) -- telefoner = "91234567, 98765432"
-- I 1NF:
KUNDE(kunde_id, navn)
KUNDE_TELEFON(kunde_id*, telefon)
2. Normalform (2NF)
En tabell er i 2NF hvis den er i 1NF OG alle ikke-nøkkelattributter er fullt funksjonelt avhengige av hele primærnøkkelen (ikke bare en del av den).
Kun relevant når PK er sammensatt.
-- BRYTER 2NF: kurs_navn avhenger kun av kurs_id, ikke av (student_id, kurs_id)
PÅMELDING(student_id*, kurs_id*, kurs_navn, dato)
-- I 2NF:
KURS(kurs_id, kurs_navn)
PÅMELDING(student_id*, kurs_id*, dato)
3. Normalform (3NF)
En tabell er i 3NF hvis den er i 2NF OG ingen ikke-nøkkelattributter er transitivt avhengige av PK.
Transitiv avhengighet: A → B → C, der A er PK og B er ikke-nøkkel.
-- BRYTER 3NF: post_sted avhenger av postnr, ikke direkte av kunde_id
KUNDE(kunde_id, navn, postnr, post_sted)
-- Transitiv: kunde_id → postnr → post_sted
-- I 3NF:
POSTSTED(postnr, post_sted)
KUNDE(kunde_id, navn, postnr*)
Huskeregel for 3NF: Hvert ikke-nøkkelattributt skal avhenge av PK, hele PK, og kun PK.
// ACID – transaksjonsegenskaper
Eksamenrelevant
ACID beskriver fire egenskaper som garanterer pålitelige transaksjoner:
- Atomicity (Atomisitet) – Alt eller ingenting. Hvis én del feiler, rulles hele transaksjonen tilbake (ROLLBACK).
- Consistency (Konsistens) – Databasen går fra én gyldig tilstand til en annen. Alle constraints overholdes.
- Isolation (Isolasjon) – Samtidige transaksjoner påvirker ikke hverandre. Resultatet er det samme som om de kjørte sekvensielt.
- Durability (Holdbarhet) – Når en transaksjon er committed, overlever endringene systemkrasj (lagres til disk).
-- Eksempel: bankoverføring
BEGIN TRANSACTION;
UPDATE KONTO SET saldo = saldo - 500 WHERE konto_id = 'A';
UPDATE KONTO SET saldo = saldo + 500 WHERE konto_id = 'B';
COMMIT; -- begge eller ingen (Atomicity)
// Samtidige transaksjoner – problemer
Eksamenrelevant
Dirty Read
T1 leser data som T2 har endret men ikke committed. Hvis T2 gjør ROLLBACK, har T1 lest ugyldig data.
Non-repeatable Read
T1 leser en rad. T2 endrer og committer raden. T1 leser raden igjen og får et annet resultat.
Phantom Read
T1 kjører en spørring og får N rader. T2 setter inn nye rader som matcher. T1 kjører samme spørring og får N+M rader.
Deadlock
T1 holder lås på A og venter på B. T2 holder lås på B og venter på A. Ingen kan fortsette – systemet velger én som «offer» og ruller den tilbake.
På eksamen: Du vil typisk få beskrevet et scenario og skal identifisere hvilket problem det er. Lær deg de fire navnene og hva som skiller dem.
// NoSQL
NoSQL-databaser er alternativer til relasjonsdatabaser. Fire hovedtyper:
- Dokumentdatabaser (MongoDB) – lagrer data som JSON-dokumenter. Fleksibelt skjema.
- Nøkkel-verdi (Redis) – enkel oppslag på nøkkel. Veldig rask, brukes til caching.
- Grafdatabaser (Neo4j) – optimalisert for relasjoner mellom noder. Sosiale nettverk, anbefalingssystemer.
- Kolonnebaserte (Cassandra) – data lagres per kolonne, ikke per rad. Bra for store datamengder.
Merk v26: Ingen MongoDB-kode på eksamen. Du skal vite hva NoSQL er, hvilke typer som finnes, og fordeler/ulemper vs. relasjonsdatabaser.
SQL vs. NoSQL – når bruker du hva?
- SQL – strukturerte data, komplekse relasjoner, krav til konsistens (bank, HR-system)
- NoSQL – semi-strukturerte data, varierende skjema, horisontal skalering, høy ytelse (logg, sensor-data, sosiale medier)
// JSON i databaser
Eksamenrelevant
MySQL støtter en JSON-datatype som lar deg lagre semi-strukturert data direkte i en kolonne.
Når er JSON et godt valg?
- Data har varierende struktur mellom rader (f.eks. svarene i en spørreundersøkelse)
- Du trenger fleksibilitet uten å endre tabellstruktur
- Data leses oftest samlet, sjelden filtrert på enkeltfelt
Ulemper med JSON i SQL
- Vanskeligere å søke/filtrere på innhold i JSON-feltet
- Ingen referanseintegritet for verdier inne i JSON
- Bryter med normaliseringstankegangen
-- Eksempel: lagre intervjunotater som JSON
INTERVJU(intervju_id, dato, søker_id*, notater JSON)
-- Innhold i notater-kolonnen for én rad:
{
"inntrykk": "Positiv",
"teknisk_score": 4,
"kommentar": "God erfaring med databaser"
}
🎯 Øv på normaliserings-spørsmål i quizen →