Kapittel 2 · 2A · Lærebok 2.1–2.5

Relasjonsmodellen

Den formelle modellen bak SQL: tabeller med skjema, tupler over domener, og nøkler som binder alt sammen.

01 · Hvorfor relasjoner

Codd 1970 — én datatype, én operasjons­familie

Før 1970 var data lagret i hierarkiske og nettverkbaserte modeller, der applikasjonen måtte kjenne den fysiske layouten — pekere, lister, tre-traverseringer. Bytter man indeks eller filformat, må alle programmer skrives om.

Edgar F. Codd publiserte i 1970 artikkelen «A Relational Model of Data for Large Shared Data Banks» hos IBM. Innsikten var radikalt enkel:

All data er bare tabeller. Spørringer er funksjoner som tar tabeller inn og gir tabeller ut. Brukeren beskriver hva som skal hentes — systemet finner ut hvordan.

Det er denne deklarative tankegangen som gjør at SQL kan optimaliseres, indekser kan endres, og maskinvare kan byttes ut — uten at applikasjonen merker noe. Codd fikk Turing-prisen for arbeidet.

Sammenheng

SQL er den deklarative overflaten. Relasjons­algebra (kapittel 2B) er det formelle fundamentet — det er det optimalisatoren faktisk manipulerer når den planlegger en spørring.

Kontrollspørsmål · Lett
Hva er hovedforskjellen mellom relasjonsmodellen og tidligere modeller (hierarkisk/nettverk)?
Relasjonsmodellen er deklarativ: brukeren oppgir hvilken data hen vil ha, ikke hvordan den skal hentes. Dette skiller logisk modell fra fysisk lagring, slik at indekser, filformat og maskinvare kan endres uten at spørringer må skrives om.
02 · Strukturen

Tabell, attributt, tuppel, domene

En relasjon er en tabell. Hver kolonne er et attributt med et tilhørende domene (mengden av lovlige verdier). Hver rad er et tuppel.

instructor
IDnamedept_namesalary
10101SrinivasanComp. Sci.65 000
22222EinsteinPhysics95 000
33456GoldPhysics87 000
76766CrickBiology72 000
Relasjonen instructor med 4 attributter og 4 tupler. ID (markert) er primærnøkkel.
RELASJON r (skjema R) (10101, "Srinivasan", "Comp. Sci.", 65000) (22222, "Einstein", "Physics", 95000) (33456, "Gold", "Physics", 87000) (76766, "Crick", "Biology", 72000) en mengde av tupler — rekkefølge er irrelevant
Matematisk er en relasjon en mengde av tupler. Rekkefølge spiller ingen rolle, og duplikater eksisterer ikke.

Atomiske domener (1. normalform)

Codd krevde at alle attributtverdier er atomiske — de betraktes som udelelige enheter. Det er ikke lov å lagre {555-1234, 555-9999} som én verdi i kolonnen phone. Lister, sett, og nestede strukturer skal flates ut til egne tabeller. Dette er kjernen i 1. normalform (1NF).

Hvorfor atomisk?

Hvis verdier kan være sammensatte, mister du muligheten til å skrive enkle predikater (WHERE phone = '555-1234') og må i stedet manipulere indre struktur — akkurat det Codd ville unngå.

Egenskapene som følger av at relasjoner er mengder

  • Ingen duplikater — to identiske rader er per definisjon én rad.
  • Ingen rekkefølge — du kan ikke spørre etter «den tredje raden».
  • Ingen kolonnerekkefølge i ren teori — i praksis har SQL en, men spørringer bør referere til kolonner ved navn.
SQL vs. relasjonsalgebra

SQL bruker multimengder (bags) — duplikater er tillatt med mindre du sier DISTINCT. Det er en praktisk avvik fra Codds rene mengdedefinisjon, men semantikken må du være våken på.

Kontrollspørsmål · Middels
En kollega lagrer kolonnen tags som en kommaseparert streng "matte,db,vår26". Hvorfor bryter dette med relasjonsmodellen, og hva er den vanlige løsningen?
Verdien er ikke atomisk — den har indre struktur som applikasjonen må parse. Du mister muligheten til å indeksere og spørre direkte («finn alt med tag = 'db'»). Standardløsningen er en separat tabell article_tag(article_id, tag) — én rad per kombinasjon.
03 · Skjema vs. instans

Strukturen er stabil — innholdet er ikke

Skjema
Logisk design. Liste med attributter og deres domener: instructor(ID, name, dept_name, salary). Endres sjelden. Tilsvarer en typedefinisjon i et programmeringsspråk.
Instans
Et øyeblikksbilde av tuplene som finnes akkurat nå. Endres ved hver INSERT, UPDATE, DELETE. Tilsvarer en verdi av en variabel.
Database­skjema
Samlingen av alle relasjons­skjemaene + nøkler og fremmednøkler.
Database­instans
Samlingen av alle relasjons­instansene på et gitt tidspunkt.

Ofte bruker vi samme navn — «instructor» — for både skjema og instans, og lar konteksten avgjøre. Når det er viktig, sier vi eksplisitt «instructor-skjemaet» eller «en instans av instructor».

Notasjon

Et relasjonsskjema skrives R(A1, A2, …, An), der Ai er attributter. Et tuppel t ∈ R har én verdi per attributt. t[Ai] er verdien til attributt Ai i tuplet t.

Kontrollspørsmål · Lett
Hvilket av disse er en del av skjemaet til instructor, og ikke en del av en bestemt instans?
Attributtnavn (ID, name, dept_name, salary), domener (heltall, tekst, tekst, kroner) og constraints (ID er primærnøkkel) er skjema. Konkrete tupler — at Einstein finnes med ID 22222 — er instans.
04 · Nøkler

Hva som identifiserer en rad

Vi må kunne skille tupler. Nøkler formaliserer hvilke attributt­kombinasjoner som er garantert unike.

Supernøkkel Kandidatnøkkel Primærnøkkel Fremmednøkkel

Supernøkkel

En mengde attributter K ⊆ R er en supernøkkel hvis ingen to tupler i noen lovlig instans kan ha samme verdi på alle attributter i K. Formelt: for alle t1 ≠ t2, t1[K] ≠ t2[K].

I instructor(ID, name, dept_name, salary) er {ID} en supernøkkel. Det er {ID, name} også — alle supersett av en supernøkkel er supernøkler. Men {name} alene er ikke, fordi to professorer kan hete det samme.

Kandidatnøkkel

En minimal supernøkkel: ingen ekte delmengde av den er supernøkkel. Hvis {ID} er supernøkkel, er {ID, name} ikke kandidat — du kan fjerne name og fortsatt ha unikhet.

En relasjon kan ha flere kandidat­nøkler. person(ssn, fødselsdato, navn, …) kan ha både {ssn} og — hvis det er garantert — {fødselsdato, navn} som kandidater.

Primærnøkkel

Den kandidatnøkkelen designeren velger som primær identifikator. Markeres med understreking i skjema: instructor(ID, name, dept_name, salary). Bør være kort, stabil (sjelden endring), og helst syntetisk (autoincrement, UUID).

Velg primærnøkkel med hodet

Adresse er en dårlig primærnøkkel — den endrer seg når folk flytter. Personnummer fungerer i Norge (stabilt), men er sensitivt og finnes ikke alltid. I praksis lager man oftest en syntetisk id-kolonne.

Visualisering — supernøkkel ⊃ kandidat ⊃ primær

supernøkler — alle unike kombinasjoner kandidatnøkler — minimale supernøkler primærnøkkel {ID} {ID, name}, {ID, salary}, … {ID, name, dept_name, salary}
Inklusjons­hierarki. Primærnøkkel ⊆ kandidatnøkler ⊆ supernøkler.
Oppgave · Middels
I tabellen section(course_id, sec_id, semester, year, building, room, time_slot): hvorfor er ikke {course_id} alene en kandidatnøkkel?
Et kurs kan tilbys flere ganger — i ulike semestre, og med flere parallelle seksjoner i samme semester (CS-190 har sec_id 1 og 2 i Spring 2017). Du trenger derfor minst {course_id, sec_id, semester, year} for å garantere unikhet.
Tankegang · Vanskelig
I en gitt instans har ingen to instructor-tupler samme name. Kan vi konkludere med at name er en supernøkkel?
Nei. En supernøkkel er en egenskap ved skjemaet (alle lovlige instanser), ikke ved en spesifikk instans. To personer kan godt hete «Jens Hansen» — at de tilfeldigvis ikke gjør det nå, gir ingen garanti for fremtiden. Skjemaet beskriver hva som er tillatt; nøkkel-egenskapen må følge av forretnings­regelen, ikke av tilfeldig dataliv.
05 · Fremmednøkler

Pekere mellom tabeller

En fremmednøkkel er en attributtmengde A i relasjon r1 som refererer til primærnøkkelen B i relasjon r2. Krav: for hvert tuppel i r1 må verdien av A finnes som verdi av B i r2 — eller være NULL.

department (referert)
dept_namebuildingbudget
Comp. Sci.Taylor100 000
PhysicsWatson70 000
BiologyWatson90 000
instructor (refererende)
IDnamedept_namesalary
10101SrinivasanComp. Sci.65 000
22222EinsteinPhysics95 000
33456GoldPhysics87 000

Fremmednøkkel: instructor.dept_name → department.dept_name

Skjemadiagram

Et skjemadiagram tegner relasjoner som bokser, primærnøkler understreket, og fremmednøkler som piler.

department dept_name building budget instructor ID name dept_name salary course course_id title dept_name
Skjemadiagram. Pilen peker fra fremmednøkkel til primærnøkkelen den refererer.

Referanseintegritet og hva som skjer ved sletting

Når du sletter et tuppel i den refererte tabellen (department), må DBMS-en bestemme hva som skal skje med tupler som peker til det. Standard­alternativene i SQL:

department Comp. Sci. · Taylor Physics · Watson ⟵ DELETE Biology · Watson instructor 10101 · Srinivasan · CS 22222 · Einstein · Physics 33456 · Gold · Physics 76766 · Crick · Biology RESTRICT: slett blokkeres — det finnes refererende rader.
  • RESTRICT (eller NO ACTION) — slett blokkeres. Standard i mange DBMS.
  • CASCADE — referanser slettes med. Brukes ofte ved komposisjon (en ordrelinje gir ikke mening uten ordren).
  • SET NULL — fremmednøkkelen settes til NULL. Krever at kolonnen ikke er NOT NULL.
  • SET DEFAULT — settes til default-verdi (sjeldnere brukt).
Generalisering

Fremmednøkkel-constraints er et spesialtilfelle av referanseintegritets-constraints, der det refererte attributtet må være primærnøkkel. Den generelle varianten (henvist attributt trenger ikke være primærnøkkel) støttes sjelden direkte av kommersielle DBMS.

Praktisk · Middels
Du har orders(order_id, customer_id, …) og order_lines(order_id, line_no, product, …) hvor order_lines.order_id refererer til orders.order_id. Hvilken delete-strategi er mest naturlig her?
CASCADE — en ordrelinje uten en ordre er meningsløs (komposisjon). Sletter du ordren, skal linjene følge med. SET NULL gir foreldreløse linjer; RESTRICT tvinger deg til å rydde manuelt før du kan slette.
06 · Integritetskrav

Hva DBMS-en garanterer

Integritets­krav er regler som alle instanser må oppfylle. De er en del av skjemaet, og DBMS-en håndhever dem ved hver oppdatering.

Domene­integritet
Verdier må være av riktig type/format (salary INT, email LIKE '%@%', CHECK(salary >= 0)).
Entitets­integritet
Primærnøkkel kan ikke være NULL. Følger av at NULL ikke kan brukes til å identifisere en rad — to NULL-er er ikke nødvendigvis like.
Referanse­integritet
Fremmednøkler må peke på eksisterende rader (eller være NULL).
Nøkkel­begrensning
UNIQUE garanterer at kandidatnøkler faktisk er unike på tvers av instansen.
Forretnings­regler
Spesifikke for domenet (start_date < end_date, discount <= price). Uttrykkes via CHECK, TRIGGER eller assertions.
Begrep · Lett
Hva er forskjellen mellom entitetsintegritet og referanseintegritet?
Entitetsintegritet: primærnøkkelen i en relasjon må være ikke-NULL og unik (intern garanti for at hver entitet er identifiserbar). Referanseintegritet: en fremmednøkkel må peke på en faktisk eksisterende primærnøkkel-verdi i en annen tabell (ekstern garanti for konsistens mellom relasjoner).
07 · NULL og 3-verdig logikk

Når «ukjent» roter alt til

NULL er en spesialverdi som betyr «ukjent» eller «ikke aktuelt». Den hører ikke til noe domene, og oppfører seg derfor unormalt i sammenligninger.

Sammenligning med NULL gir ikke FALSE — den gir UNKNOWN

Predikatet salary > 50000 evaluerer til UNKNOWN hvis salary IS NULL. Det er heller ikke TRUE og ikke FALSE — det er en tredje sannhetsverdi. Derfor får SQL en treverdig logikk.

AND
TFU
TTFU
FFFF
UUFU
F dominerer i AND — gir alltid F.
OR
TFU
TTTT
FTFU
UTUU
T dominerer i OR — gir alltid T.

WHERE filtrerer bort UNKNOWN

SQL beholder bare rader der WHERE-predikatet er TRUE. UNKNOWN behandles som FALSE i dette filteret. Derfor er resultatet av SELECT * FROM emp WHERE bonus > 0 ikke komplementært til SELECT * FROM emp WHERE bonus <= 0 — rader med bonus = NULL mangler i begge.

IS NULL, ikke = NULL

x = NULL er alltid UNKNOWN — også når x selv er NULL. Bruk derfor alltid x IS NULL / x IS NOT NULL for å teste for fravær.

Konsekvenser i praksis

  • Aggregater hopper over NULL — AVG(salary) teller bare ikke-NULL rader. Unntak: COUNT(*) teller alle rader.
  • NOT IN ⟵⟶ NULL — x NOT IN (1, 2, NULL) blir UNKNOWN selv når x = 3. Klassisk kilde til «manglende rader».
  • UNIQUE-constraint tillater normalt flere NULL-verdier (de regnes ikke som «like»).
Felle · Vanskelig
Tabellen emp(name, dept) har 5 rader; én har dept = NULL. Hva returnerer SELECT name FROM emp WHERE dept <> 'HR'?
Bare ansatte med kjent avdeling ulik 'HR' — raden med NULL kommer ikke med, fordi NULL <> 'HR' er UNKNOWN, og UNKNOWN filtreres bort. Vil du ha NULL med, må du skrive WHERE dept IS NULL OR dept <> 'HR'.
Refleksjon · Middels
Hvorfor sier vi at NULL «bør unngås når mulig»? Når er det likevel uunngåelig?
NULL gjør spørringer subtile (3-verdig logikk, NOT IN-feller, aggregater). Mange skjemafeil løses bedre ved å splitte i flere relasjoner — f.eks. en egen employee_phone-tabell heller enn nullbar phone. NULL er likevel uunngåelig for ekte valgfri informasjon (utløpsdato før den er satt, partneradresse i CV-er, osv.).
08 · Oppsummering

Du bør nå kunne …

  • … forklare hvorfor relasjons­modellen vant fram (deklarativ tilgang, separasjon av logisk og fysisk lag).
  • … definere relasjon, tuppel, attributt, domene, og hvorfor atomiske domener er viktig.
  • … skille skjema fra instans.
  • … identifisere supernøkler, kandidatnøkler og primærnøkler i et gitt skjema.
  • … tegne et skjemadiagram med fremmednøkler og argumentere for delete-strategi.
  • … forklare entitets- og referanseintegritet.
  • … resonnere om NULL og treverdig logikk.
Neste skritt

Med modellen på plass kan vi nå snakke om operasjoner på relasjoner — det formelle språket SQL bygger på. Gå videre til 2B · Relasjonsalgebra.