Kapittel 4 · Forelesning 7–9 · Lærebok 6.1–6.9, 7.1–7.3, 7.6
Relasjonsdatabasedesign
Fra virkeligheten via et ER-diagram til et normalformet skjema — uten redundans, uten anomali, uten oppdateringskaos.
01 · Helhetsbilde
Hvorfor bry seg om design
Et dårlig databaseskjema lager det samme problemet om og om igjen: samme faktum lagres flere steder, oppdateringer lekker ut av synkronisering, og du klarer ikke registrere viktig informasjon før noen helt annen rad er på plass. Resultatet kalles anomali — og det er ikke en bugg du kan rette i applikasjonskoden, det er en strukturell svakhet i selve skjemaet.
Sentral idé
Design er ikke et estetisk valg. Det er et matematisk spørsmål: kan jeg representere alle gyldige situasjoner uten redundans, uten å miste informasjon, og uten å måtte sjekke regler på tvers av tabeller?
Konseptuelt
ER-diagram. Tegn problemet før du skriver tabeller. Snakker med stakeholders.
Logisk
Relasjonsskjema. Konkrete tabeller med kolonner, nøkler og fremmednøkler.
Mekanisk
Normalformer. Bevisbare garantier for at ingen redundansmønstre slipper gjennom.
02 · Designreisen
Fra virkelighet til BCNF
Hele kapittelet kan tegnes som én pil — men hvert pilhopp har sine egne regler og sine egne fallgruver.
Pensum-mapping
F7 dekker ER-modellen (lærebok 6.1–6.6). F8 dekker reduksjon til skjema, designproblemer og motivasjon for normalformer (6.7, 6.9, 7.1). F9 dekker funksjonelle avhengigheter, dekomponering og BCNF (7.1–7.3, 7.6).
03 · Tre underkapitler
Utforsk kapittelet
ER-modellen
Entiteter, attributter, relasjoner, kardinalitet, svake entiteter, ISA-hierarkier — med diagram-eksempler og innebygde quizzer.
ER → relasjonsskjema
Reduksjonsregler steg for steg, ISA-strategier, og en interaktiv oversettelse fra diagram til tabeller. Anomali introduseres mot slutten.
Normalformer
FD-er, lukning (med interaktiv kalkulator), 1NF–BCNF, dekomponering, og et fullt gjennomarbeidet eksempel.
04 · Sjekkliste
Du mestrer kapittel 4 når du kan…
- tegne et ER-diagram for et naturlig språk-krav, inkludert svake entiteter og ISA-hierarkier
- oversette diagrammet til et relasjonsskjema med riktige primær- og fremmednøkler
- identifisere oppdaterings-, innsettings- og sletteanomalier i et gitt skjema
- liste opp de funksjonelle avhengighetene og beregne lukningen
X⁺ - avgjøre om et gitt skjema er i 3NF eller BCNF — og begrunne det
- dekomponere et ikke-BCNF-skjema lossless og forklare hva man eventuelt taper i dependency preservation
Sluttquiz · Test helheten
Tolv spørsmål på tvers av 4A, 4B og 4C. Klikk på svaralternativene — riktig svar låser oppgaven; feil kan du prøve igjen.
Spørsmål 1 · Lett · ER-modellen
Hva skiller en svak entitet fra en sterk entitet?
En svak entitet trenger eierens nøkkel + en diskriminator for å skille instanser. Den tegnes med dobbel ramme i ER-diagrammet.
Spørsmål 2 · Middels · ER → tabell
For en N:M-relasjon mellom
Student og Emne i et ER-diagram, hvordan oversettes denne best til relasjonsskjema?N:M kan ikke representeres med fremmednøkkel på «den ene siden» — det finnes ingen «en» side. Mellomtabellen er den eneste lossless løsningen.
Spørsmål 3 · Lett · Anomali
Et tabellskjema lagrer instruktørens lønn og avdelingsbudsjett i samme rad. Hva er hovedrisikoen?
Redundans er ikke i seg selv ulovlig — problemet er at konsistens må håndheves manuelt for hver oppdatering. Det er den klassiske oppdateringsanomalien.
Spørsmål 4 · Middels · FD
Hvilken FD holder på relasjonsskjemaet
Bil(regnr, modell, eier_pnr, eier_navn), gitt at hver bil har én eier og hvert personnummer hører til én person?regnr er superkey, så regnr bestemmer alt. eier_pnr bestemmer eier_navn fordi personnummer er unikt. Eier_navn → eier_pnr holder ikke (flere personer kan hete det samme).
Spørsmål 5 · Vanskelig · Lukning
Gitt R(A,B,C,D) med FD-mengde F = {A→B, B→C, C→D}. Hva er lukningen
{A}⁺?Start med {A}. A→B gir B, så {A,B}. B→C gir C, så {A,B,C}. C→D gir D, så {A,B,C,D}. Siden lukningen er hele R, er A en supernøkkel.
Spørsmål 6 · Middels · BCNF
Et skjema er i BCNF hvis…
BCNF er definert i termer av FD-er og supernøkler. Atomaritet er 1NF. 3NF tillater visse FD-er som BCNF nekter (når β−α ligger i en kandidatnøkkel).
Spørsmål 7 · Vanskelig · Lossless join
Vi splitter R(A,B,C,D) i R₁(A,B) og R₂(B,C,D). FD-mengden er {B→C, C→D}. Er dekomposisjonen lossless?
Test:
R₁ ∩ R₂ = {B}. Beregn {B}⁺ = {B, C, D}, som dekker R₂. Da er {B} supernøkkel for R₂, og dekomposisjonen er lossless.Spørsmål 8 · Middels · 3NF vs BCNF
Hvorfor velger man av og til 3NF i stedet for BCNF?
Trade-off-en: BCNF eliminerer mer redundans, men når en FD ikke kan «holdes» i én tabell etter dekomponering, går dependency preservation tapt. 3NF beholder alle FD-er.
Spørsmål 9 · Lett · ISA
Hva betyr disjoint i en ISA-spesialisering?
«Disjoint» er ortogonalt med «total». Disjoint = ingen overlapp mellom subklasser. Total = alle superklasse-instanser hører til en subklasse.
Spørsmål 10 · Middels · Anomali
Hvilken anomali oppstår når man ikke får lagt inn en ny avdeling fordi det ennå ikke finnes ansatte i den?
Innsettingsanomali = det vi ønsker å lagre, kan ikke uttrykkes uten å lyve om noe annet (eller fylle inn null). Symptom på at avdelings-fakta er smeltet inn i ansattes tabell.
Spørsmål 11 · Vanskelig · Kandidatnøkler
Gitt R(A,B,C,D,E) med FD-er {AB→C, C→D, D→E}. Hvilket sett er kandidatnøkkel?
{A,B}⁺ = {A,B,C,D,E} via AB→C, C→D, D→E. {A}⁺={A} dekker ikke alt. {A,B,C} er supernøkkel men ikke minimal — C kan fjernes.
Spørsmål 12 · Vanskelig · Designvalg
Du har et 3NF-skjema som taper dependency preservation hvis du dekomponerer videre til BCNF. Hva er den faglig beste avveiningen?
Lærebokas anbefaling: gå for BCNF når mulig, fordi SQL likevel bare kan håndheve nøkkel-FD-er effektivt — så «mistet» dependency preservation ville ha vært en illusjon i 3NF også.