Lær grunnleggende databasekonsepter, ER-modellering og enkel bruk av SQL for å hente og organisere data.
Hvor blir det av alt sammen?
Hver gang du logger inn et sted, bestiller noe på nett eller legger ut et bilde på sosiale medier, skjer det noe i kulissene: dataene dine blir lagret. Men hvor? Og hvordan finner systemet dem igjen et halvt sekund senere, blant millioner av andre brukeres data? Svaret er en database -- den stille hjørnesteinen under nesten alle digitale tjenester.
En database er en organisert samling av data som lagres og administreres elektronisk, slik at vi effektivt kan lagre, hente, oppdatere og slette informasjon. Den mest vanlige typen, relasjonsdatabasen, organiserer data i tabeller med tydelige forbindelser mellom dem. I dette kapittelet skal vi åpne lokket og se hvordan dette fungerer: hvordan data ordnes i tabeller med rader og kolonner, hvordan nøkler binder ting sammen, hvordan vi planlegger en database med ER-diagrammer, og hvordan vi snakker med databasen ved hjelp av språket SQL.
Tabeller, rader og nøklene som binder alt sammen
En relasjonsdatabase organiserer alt i tabeller, og hver tabell representerer én type ting -- elever, fag eller karakterer. Kolonnene definerer egenskapene, som fornavn, etternavn, klasse og e-post, mens radene er de enkelte postene, altså den enkelte eleven. Tenk på en tabell «Elever»: én rad kan inneholde Mia Hansen i klasse 1IMA, en annen Jonas Berg i 1IMB. Kolonnene bestemmer hva slags informasjon vi lagrer, og radene fyller dem med faktiske verdier.
Men hvordan vet databasen hvilken Mia vi snakker om, hvis det finnes flere? Her kommer primærnøkkelen inn -- en unik identifikator for hver rad, slik som en elevid. Ingen to rader kan ha samme primærnøkkel, så den fungerer som et fingeravtrykk for posten. Og når vi skal knytte tabeller sammen, bruker vi en fremmednøkkel -- en kolonne i én tabell som peker på primærnøkkelen i en annen. For eksempel kan en klasseid i Elever-tabellen være en fremmednøkkel som viser til Klasse-tabellen. Slik kobles informasjon på tvers av tabeller uten at vi må gjenta den overalt. Det er denne smarte koblingen av tabeller som gir relasjonsdatabasen navnet sitt.
Å tegne databasen før du bygger den
Før du lager en database, lønner det seg å planlegge strukturen -- og det gjør vi med et ER-diagram, der ER står for Entity-Relationship. Det er et visuelt verktøy som lar deg tegne ut hvordan dataene henger sammen før en eneste tabell er opprettet. I et slikt diagram er entitetene tingene vi lagrer data om, som Elev, Fag og Karakter, og de tegnes gjerne som rektangler. Attributtene er egenskapene til entitetene -- navn, dato, poeng -- og listes inni dem.
Det mest interessante er relasjonene, som viser hvordan entitetene er knyttet til hverandre. En en-til-en-relasjon (1:1) betyr at én ting hører til nøyaktig én annen, som at én elev har én brukerkonto. En en-til-mange-relasjon (1:N) betyr at én ting hører til flere andre, som at én klasse har mange elever. Og en mange-til-mange-relasjon (N:M) betyr at mange på begge sider knyttes sammen, som at mange elever tar mange fag. Det siste byr på en utfordring, for en database kan ikke representere mange-til-mange direkte -- derfor må vi legge inn en koblingstabell mellom de to tabellene. Tenk på relasjonen Elev har mange Karakterer, og hvert Fag har mange Karakterer fra ulike elever: Karakter-tabellen blir koblingen som binder Elev og Fag sammen. Ved å tegne dette ut på forhånd unngår du å oppdage strukturelle feil etter at du allerede har fylt databasen med data.
Å snakke med databasen
En database er lite verdt hvis du ikke kan kommunisere med den, og til det bruker vi SQL -- Structured Query Language, selve standardspråket for databaser. Det fine er at SQL er overraskende lesbart, nesten som forenklet engelsk. Vil du hente data, bruker du SELECT. Skriver du «SELECT fornavn, etternavn FROM elever», får du ut fornavn og etternavn for alle elever. Vil du bare ha dem fra én klasse, legger du til en betingelse: «SELECT * FROM elever WHERE klasse = 1IMA» henter alle kolonner for elevene i 1IMA, der stjernen betyr «alle kolonner».
De andre grunnkommandoene følger samme logikk. For å sette inn ny data bruker du INSERT, som i «INSERT INTO elever (fornavn, etternavn, klasse) VALUES (Erik, Larsen, 1IMB)». For å endre eksisterende data bruker du UPDATE sammen med en WHERE-betingelse, slik at du bare oppdaterer riktig rad -- «UPDATE elever SET klasse = 2IMA WHERE elev_id = 1». For å slette bruker du DELETE, også med WHERE, så du ikke ved et uhell sletter alt. I tillegg kan du sortere resultatene med ORDER BY, for eksempel etter etternavn, og filtrere med WHERE, som å hente bare karakterer med mer enn 50 poeng. Når du skal kombinere data fra flere tabeller -- for eksempel finne alle bøkene Mia Hansen har lånt på biblioteket -- kobler du tabellene sammen med JOIN, basert på nøklene som binder dem. Med disse byggesteinene kan du både stille spørsmål til databasen og forme innholdet i den.
Oppsummering
Vi har åpnet lokket på databasene som lagrer alt det digitale livet vårt. En database er en organisert samling av data, og en relasjonsdatabase ordner alt i tabeller med rader og kolonner. Primærnøkkelen gir hver rad en unik identitet, mens fremmednøkkelen binder tabeller sammen uten å gjenta informasjon.
Vi så hvordan vi planlegger en database med ER-diagrammer, der entiteter, attributter og relasjoner tegnes ut -- og hvordan en mange-til-mange-relasjon krever en koblingstabell. Til slutt lærte vi å snakke med databasen gjennom SQL, med grunnkommandoene SELECT for å hente, INSERT for å legge til, UPDATE for å endre og DELETE for å slette, samt WHERE for å filtrere og ORDER BY for å sortere. Databasekunnskap er nøkkelen til å forstå hvordan digitale systemer husker og organiserer informasjon.
Dette kapitlet er skrevet av Anthropics toppmodeller (Claude Opus og Claude Fable) og er foreløpig ikke manuelt gjennomgått — kvalitetskontrollen gjøres av uavhengige KI-agenter, og innmeldte feil rettes fortløpende. Funnet en feil? Meld fra, så retter vi den. Les mer om hvordan innholdet lages.