Kapittel 2 · Forelesning 2 · Lærebok 2 + notater 3.2 og 4.1
Relasjonsmodellen og relasjonsalgebra
Det formelle fundamentet bak SQL: tabeller med skjema og nøkler, og operatorene som tar relasjoner inn og gir relasjoner ut.
Helhetsbilde
Hvorfor dette kapittelet er kritisk
Alt resten av kurset bygger på dette. SQL (kapittel 3–5), normalisering (7), querybehandling (13) og indekser (10–11) snakker alle om relasjoner, nøkler og algebra-uttrykk. Hvis vokabularet sitter løst her, blir resten kjempetungt.
- Codd 1970 — én datatype (tabellen), én operasjonsfamilie (algebraen). Brukeren beskriver hva; systemet finner ut hvordan.
- Relasjon = mengde av tupler over et skjema. Ingen rekkefølge, ingen duplikater, atomiske domener.
- Nøkler binder modellen sammen. Primærnøkler identifiserer rader; fremmednøkler kobler tabeller.
- SQL er overflaten — relasjonsalgebra er fundamentet. Optimalisatoren manipulerer algebra-uttrykk for å finne en rask plan.
Læringssti
Anbefalt rekkefølge
Følger du denne rekkefølgen, har du modellen på plass før du møter operatorene som virker på den.
Begreper
Et minimalt kart
Hvordan begrepene henger sammen — bruk det som sjekkliste.
Test deg selv
15 spørsmål som dekker hele kapittelet — fra modell til algebra. Ikke bla til svaret før du har et eget forsøk.
Spørsmål 1 · Lett · Modell
Hva betyr det at en relasjon er en mengde av tupler, og hvilke to praktiske konsekvenser har det?
Det betyr at (1) rekkefølgen på rader er irrelevant — du kan ikke spørre etter «den tredje raden», og (2) duplikater ikke finnes — to identiske rader er per definisjon én rad. SQL tar et praktisk avvik fra dette og bruker multimengder (bag-semantikk) — derfor må du skrive
DISTINCT for å få mengdesemantikk.Spørsmål 2 · Lett · Modell
Forklar forskjellen på skjema og instans.
Skjemaet er den logiske strukturen — attributtnavn, domener, nøkler, fremmednøkler. Det endres sjelden. Instansen er øyeblikksbildet av tuplene som finnes nå, og endres ved hver INSERT/UPDATE/DELETE. Sammenlign med programmering: skjema = type, instans = verdi.
Spørsmål 3 · Middels · Atomisitet
Hvilket av disse er ikke en gyldig relasjon i Codds forstand, og hvorfor?
Et eksempel som
person(navn, telefoner) der telefoner inneholder en liste eller mengde, bryter med kravet om atomiske domener. Løsningen er en separat tabell person_phone(person_id, phone) med én rad per telefonnummer.Spørsmål 4 · Middels · Nøkler
Skjemaet er
enrollment(student_id, course_id, semester, year, grade). Hva er den minimale primærnøkkelen, og kan du ha to ulike kandidatnøkler her?Primærnøkkel:
{student_id, course_id, semester, year} — en student kan ta samme kurs på nytt i et annet semester. Andre kandidater er sjeldne her, men hvis hver student bare kan ta hvert kurs én gang totalt, kunne {student_id, course_id} fungert. Da må forretningsregelen være eksplisitt — kandidatnøkkel er en egenskap ved skjemaet, ikke ved en tilfeldig instans.Spørsmål 5 · Vanskelig · Nøkler
En kollega argumenterer for at e-post kan være primærnøkkel for
users. Hva er problemene med det?(1) Ikke stabil — folk bytter e-post; det betyr cascading oppdateringer i alle FK-er som peker hit. (2) Personopplysning — havner alle steder primærnøkkelen brukes, gir GDPR-utfordringer. (3) Lengde — e-poster er lange og varierer; en syntetisk INT-id er raskere som indeksnøkkel. Praksis: bruk syntetisk id som primærnøkkel og legg
UNIQUE på e-post.Spørsmål 6 · Middels · Fremmednøkler
Du har
orders → customers via fremmednøkkel. Hvilken delete-strategi er aldri god her, og hvorfor?CASCADE er problematisk — sletter du en kunde, mister du hele ordrehistorikken, som du normalt trenger for regnskap, retur og rapportering. Bedre: RESTRICT (blokker sletting) eller bruk en «soft delete» (
customers.deleted_at) slik at historikken blir bevart. SET NULL bryter referanseintegritet i nyttigheten — orden hører til noen, ikke ingen.Spørsmål 7 · Lett · Integritet
Hva er entitetsintegritet, og hvorfor følger den naturlig fra hva primærnøkkelen skal gjøre?
Entitetsintegritet: ingen del av primærnøkkelen kan være NULL. Følger fordi primærnøkkelen skal identifisere en rad — og NULL betyr «ukjent» og er ikke engang lik seg selv. To rader med NULL i primærnøkkelen vil ikke kunne skilles.
Spørsmål 8 · Vanskelig · NULL
Hvorfor kan
NOT IN med en sub-spørring som inneholder NULL gi ingen rader, selv om du venter mange?Fordi
x NOT IN (a, b, NULL) er ekvivalent med x ≠ a ∧ x ≠ b ∧ x ≠ NULL. Den siste er alltid UNKNOWN, og UNKNOWN i AND-kjede gir UNKNOWN totalt — som filtreres ut i WHERE. Bytt til NOT EXISTS eller filtrer NULL-er ut av sub-spørringen først.Spørsmål 9 · Lett · Algebra
List de seks fundamentale operatorene i relasjonsalgebra, og en avledet operator du oftere bruker.
Fundamentale:
σ select, π project, × kartesisk produkt, ∪ union, − differanse, ρ rename. Avledet: ⋈ join (= σ etter ×), ∩ intersect (= R − (R − S)), ÷ division.Spørsmål 10 · Middels · Algebra
Skriv et relasjonsalgebra-uttrykk som finner navnet til alle Physics-instruktører som tjener mer enn 80 000.
πname(σdept_name = "Physics" ∧ salary > 80000(instructor)). Alternativt kan du sammensette to selects: πname(σsalary > 80000(σdept_name = "Physics"(instructor))) — de gir samme resultat.Spørsmål 11 · Middels · Join
Hva er forskjellen mellom natural join og theta-join? Når blir natural join farlig?
Natural join matcher implisitt på alle attributter med samme navn i begge relasjonene, og slår sammen til én kolonne. Theta-join lar deg oppgi et eksplisitt predikat. Natural join blir farlig når skjemaer endres — legges et nytt likt-navngitt attributt til (f.eks.
created_at), endres semantikken stille uten at spørringen feiler. Eksplisitt JOIN ... ON er tryggere i produksjonskode.Spørsmål 12 · Middels · Outer join
Hvilken instruktør-rad mister du i
instructor ⋈ teaches, og hvilken algebra-operator beholder den?Du mister enhver instructor uten match i
teaches — altså instruktører som ikke underviser noe kurs. Left outer join instructor ⟕ teaches beholder alle rader fra venstre side; manglende attributter fra høyre fylles med NULL.Spørsmål 13 · Vanskelig · Mengdeoperatorer
Hvorfor må
R og S være «kompatible» for at R ∪ S skal være lov, og hva betyr kompatibel her?Resultatet av union må selv være en relasjon — én klar liste av attributter med klare typer. Kompatibel betyr (1) samme aritet, og (2) samme type på den i-te attributten i begge. Det er posisjon som teller, ikke navn — du må projisere først for å justere skjemaene hvis de avviker.
Spørsmål 14 · Vanskelig · Division
Forklar med ord hva
R ÷ S beregner, og gi et naturlig eksempel.R ÷ S finner de tuplene fra R (over attributtene som ikke er i S) som er paret med hver eneste rad i S. Klassisk: tatt(student, kurs) ÷ påkrevd(kurs) gir studenter som har tatt alle påkrevde kurs. I SQL implementeres det med dobbel NOT EXISTS.Spørsmål 15 · Vanskelig · Optimalisering
Hvorfor er det nyttig at
σp(R ⋈ S) ≡ (σp(R)) ⋈ S når p bare nevner attributter i R (for inner join)? Hva gjør optimalisatoren med dette?Optimalisatoren bruker «push selection past join»: ved å filtrere R først reduseres antall rader som må joines, og dermed kostnaden av joinen (som er en av de dyreste operasjonene). Dette er en av flere ekvivalensregler som lar planleggeren bygge billigere fysiske planer uten å endre resultatet. Husk: regelen gjelder ikke ubetinget for outer joins — der introduseres NULL-er som kan endre semantikken.
Klar for kapittel 3?
Når disse 15 sitter, er du klar for SQL — som tar hele algebraen og kler den i syntaks. Gå videre til kapittel 3.