Republic / Artiklar /

Artikeln uppdaterad 2021-04-14.
Skriven av Christofer Sandin.

Lite grundläg­gande databasteori

Det låter kanske tor­rt, men det är inte helt fel att kun­na lite teori om hur och var­för man gör vis­sa sak­er om man vill arbe­ta med data­ba­sutveck­ling på ett ser­iöst sätt. Speciellt inte om du sik­tar på att göra rik­ti­ga jobb. Teorin nedan är lite fören­klad och jag vet att jag inte tag­it med allt. Tanken var att göra en sam­man­fat­tning av det vik­ti­gaste och då tvin­gas man ibland uteläm­na detal­jer för att få fram poän­gen. Hop­pas ni har överseende med detta.

I verk­ligheten, som det verkar som om man måste anpas­sa sig till då och då, finns det ock­så oftast anled­ningar som gör att det inte går att vara rik­tigt så strikt som man kanske skulle öns­ka att man kunde vara. Men, det är som med allt annat, desto bät­tre du kan ett ämne, desto enklare är det att ​”bry­ta mot regler­na” när det krävs.

Med dessa ord så föl­jer här vad under­teck­nad, sub­jek­tivt, tyck­er är bland det vik­ti­gast begrep­pen i lite grundläg­gande databasteori.

Intro­duk­tion och lite terminologi

Den engel­s­ka ter­men Data­Base Man­age­ment Sys­tem (DBMS) eller, som det het­er på sven­s­ka, en data­bashanter­are är en sam­ling data som är beroende av varan­dra samt alla de pro­gram som behövs för att läsa/​ändra/​radera den­na data. En data­bas är den sam­lade datamäng­den och beskrivs oftast med en eller flera tabeller.

Dessa tabeller består av ett antal kolum­n­er med namn (attrib­ut) där data lagras på var­je rad (tupel). Det finns givetvis även oli­ka typer av data­bashanter­are, men för oss som arbe­tar med webbteknik är det så gott som alltid en Rela­tion­al Data­Base Man­age­ment Sys­tem (RDBMS) från MySQL, Ora­cle, Post­greSQL eller Microsoft som används.

En data­bas­de­sign kallas för dess schema och infor­ma­tio­nen som finns lagrad i data­basen vid en speci­fik tid­punkt kallas en instans av databasen.

Ytterli­gare en term som används gan­s­ka ofta, och som kan vara bra att kän­na till, är entitet. Det är ett ​”objekt” i den verk­li­ga världen som kan skil­jas från alla andra objekt. En entitet har ett gäng med egen­skaper som beskriv­er det och har ibland kan någon eller några av dessa egen­skaper beskri­va objek­tet unikt, dvs fungera som ett sätt att ref­er­era till just det här ​”objek­tet”.

En entitetsmängd är, pré­cis som det låter, en mängd entiteter av sam­ma typ och med sam­ma egen­skaper. Ett exem­pel på det­ta är alla skivor i din skivsam­ling eller alla män­niskor i Sverige.

id	titel	artist	webb­plats	datum
1	Out of Time	R.E.M.	www​.remhq​.com	1991-03-12
2	Reveal	R.E.M.	www​.remhq​.com	2001-05-07
3	Men­tal Jewelry	Live	www​.friend​soflive​.com	1992-03-09

Tabell 1: Ett exem­pel på en entitetsmängd med attribut­en id, titel, artist och datum. Den visas i tabell­form med tre tupler data.

Som näm­n­des ovan kan vis­sa attrib­ut unikt bestäm­ma en tupel med data i en tabell. I vårt exem­pel ovan är t.ex. id ett sådant attrib­ut, det­ta kallas då för nyck­el (eng. key).

I andra fall kan vi behö­va använ­da flera attrib­ut för att kun­na iden­ti­fiera en unik tupel. Det­ta är ock­så tillåtet och funger­ar på i prin­cip sam­ma sätt, men då kallas dessa gemen­sam­ma attrib­ut för en superny­ck­el (eng. superkey). Det var mån­ga ter­mer på rel­a­tivt kort tid, så det det kanske pas­sar bra ytterli­gare ett exempel:

Hela Sveriges befolkn­ing beskri­vas med en mas­sa oli­ka attrib­ut där flera oli­ka män­niskor kan beskri­vas som blon­da, brunög­da eller lån­ga men där endast en unik män­niska kan ref­er­eras till med hjälp av ett personnummer.

Nor­malis­er­ing

När man des­ig­nar en data­bas som skall använ­das pro­fes­sionellt (och som är lite mer kom­plex än tabellen med CD-skivor­na ovan) så finns det några sak­er som man bör kun­na och även bör tän­ka på. En av dessa sak­er är normalisering.

De sto­ra vin­ster­na med nor­malis­er­ing är att du und­viker redun­dant data och att det oftast går snab­bare att leta reda på data i data­basen. Redun­dant data bety­der att sam­ma infor­ma­tion finns lagrad på mån­ga oli­ka platser i data­basen, vilket inte är att rek­om­mendera då det kan leda till prob­lem vid upp­da­teringar efter­som du måste upp­dat­era på mån­ga oli­ka ställen.

Man bör allt­så (oftast) nor­malis­era data­basen i så stor utsträck­n­ing som möjligt. Värt att notera är att de oli­ka nor­mal­former­na nedan byg­ger på varan­dra, så för att upp­fyl­la den tred­je nor­mal­for­men måste vil­lko­ren för de två förs­ta ock­så vara uppfyllda.

Förs­ta nor­mal­form (1NF)

Var­je rad i en kol­umn får inte innehål­la mer än ett värde. Om ett av ban­den ovan har två offi­ciel­la webb­platser skall dessa allt­så inte lagras som ​”http://​www​.adress1​.com, http://​www​.adress2​.com” utan i två kolum­n­er som då bor­de heta något i stil med webbplats1 och webbplats2 istället.

Det måste finnas en primär nyck­el (eng. pri­ma­ry key) i var­je tabell. Det­ta är en kol­umn som unikt iden­ti­fier­ar en instans av data (en rad i tabellen)

En primär nyck­el kan även bestå av flera kolum­n­er, med vil­lko­ret att kom­bi­na­tio­nen av dessa vär­den unikt iden­ti­fiera en rad i tabellen.

Andra nor­mal­form (2NF)

Om flera rad­er har gemen­sam data, skall den­na läg­gas i en sep­a­rat tabell.

Rela­tio­nen mel­lan den gam­la och nya tabellen definieras med en främ­mande nyck­el (eng. for­eign key).

Vi använ­der vårt förs­ta exem­pel för att visa hur data­basen som cd-sam­lin­gen lagrades i kan skri­vas om till två sep­a­ra­ta tabeller för att föl­ja 2NF:

id	titel	artist	datum
1	Out of Time	R.E.M.	1991-03-12
2	Reveal	R.E.M.	2001-05-07
3	Men­tal Jewelry	Live	1992-03-09

Tabell 2: Här har vi delat upp data­basen i två tabeller med attrib­ut­et artist som främ­mande nyck­el. Det­ta för att rad­er med gemen­sam data skall bry­tas ut och läg­gas i en egen tabell.

artist	webb­plats
R.E.M.	www​.remhq​.com
Live	www​.friend​soflive​.com

Tabell 3: I det­ta fal­l­et fanns gemen­sam­ma data i kolum­nen webb­plats. Den har bru­tits ut och därav föl­jer data­basen nu 2NF.

Som ni ser så blir det mer och mer strikt allt efter­som graden på nor­mal­form stiger, men det är fak­tiskt inte så dumt att föl­ja någon form av nor­malis­er­ing när man des­ig­nar en data­bas. Har man sto­ra datamängder blir förde­lar­na extra tydli­ga då det­ta gör att var­je förän­dring framöver bara behöver göras i en tabell.

Tred­je nor­mal­form (3NF)

Plac­era alla kolum­n­er som inte beror enbart av den primära nyck­el i en egen tabell.

Det finns även andra nor­malis­er­ings­former. Föru­tom fjärde och femte nor­mal­form finns exem­ple­vis en som het­er Boyce — Codd Nor­mal Form (BCNF). Den form man brukar använ­da i prak­tiken är dock oftast 3NF efter­som de andra är blir lite väl omständli­ga om det inte är något jät­tepro­jekt som skall utvecklas.

Vill du ha mer?

Det­ta var väl grun­der­na, kort sam­man­fat­tade, för att kun­na gå på SQL och ​”göra något på rik­tigt”. Vill du ha mer teori finns det mängder att läsa i fack­lit­ter­atur eller på webben. 

Håller du på att utbil­da dig, eller är sug­en på att vidareut­bil­da dig för den delen, finns det ock­så möj­lighet att läsa en kurs på en YH-utbild­ning, ett uni­ver­sitet eller en teknisk högskola.