Lite grundläggande databasteori
Det låter kanske torrt, men det är inte helt fel att kunna lite teori om hur och varför man gör vissa saker om man vill arbeta med databasutveckling på ett seriöst sätt. Speciellt inte om du siktar på att göra riktiga jobb. Teorin nedan är lite förenklad och jag vet att jag inte tagit med allt. Tanken var att göra en sammanfattning av det viktigaste och då tvingas man ibland utelämna detaljer för att få fram poängen. Hoppas ni har överseende med detta.
I verkligheten, som det verkar som om man måste anpassa sig till då och då, finns det också oftast anledningar som gör att det inte går att vara riktigt så strikt som man kanske skulle önska att man kunde vara. Men, det är som med allt annat, desto bättre du kan ett ämne, desto enklare är det att ”bryta mot reglerna” när det krävs.
Med dessa ord så följer här vad undertecknad, subjektivt, tycker är bland det viktigast begreppen i lite grundläggande databasteori.
Introduktion och lite terminologi
Den engelska termen DataBase Management System (DBMS) eller, som det heter på svenska, en databashanterare är en samling data som är beroende av varandra samt alla de program som behövs för att läsa/ändra/radera denna data. En databas är den samlade datamängden och beskrivs oftast med en eller flera tabeller.
Dessa tabeller består av ett antal kolumner med namn (attribut) där data lagras på varje rad (tupel). Det finns givetvis även olika typer av databashanterare, men för oss som arbetar med webbteknik är det så gott som alltid en Relational DataBase Management System (RDBMS) från MySQL, Oracle, PostgreSQL eller Microsoft som används.
En databasdesign kallas för dess schema och informationen som finns lagrad i databasen vid en specifik tidpunkt kallas en instans av databasen.
Ytterligare en term som används ganska ofta, och som kan vara bra att känna till, är entitet. Det är ett ”objekt” i den verkliga världen som kan skiljas från alla andra objekt. En entitet har ett gäng med egenskaper som beskriver det och har ibland kan någon eller några av dessa egenskaper beskriva objektet unikt, dvs fungera som ett sätt att referera till just det här ”objektet”.
En entitetsmängd är, precis som det låter, en mängd entiteter av samma typ och med samma egenskaper. Ett exempel på detta är alla skivor i din skivsamling eller alla människor i Sverige.
| id | titel | artist | webbplats | 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 | Mental Jewelry | Live | www.friendsoflive.com | 1992-03-09 |
Tabell 1: Ett exempel på en entitetsmängd med attributen id, titel, artist och datum. Den visas i tabellform med tre tupler data.
Som nämndes ovan kan vissa attribut unikt bestämma en tupel med data i en tabell. I vårt exempel ovan är t.ex. id ett sådant attribut, detta kallas då för nyckel (eng. key).
I andra fall kan vi behöva använda flera attribut för att kunna identifiera en unik tupel. Detta är också tillåtet och fungerar på i princip samma sätt, men då kallas dessa gemensamma attribut för en supernyckel (eng. superkey). Det var många termer på relativt kort tid, så det det kanske passar bra ytterligare ett exempel:
Hela Sveriges befolkning beskrivas med en massa olika attribut där flera olika människor kan beskrivas som blonda, brunögda eller långa men där endast en unik människa kan refereras till med hjälp av ett personnummer.
Normalisering
När man designar en databas som skall användas professionellt (och som är lite mer komplex än tabellen med CD-skivorna ovan) så finns det några saker som man bör kunna och även bör tänka på. En av dessa saker är normalisering.
De stora vinsterna med normalisering är att du undviker redundant data och att det oftast går snabbare att leta reda på data i databasen. Redundant data betyder att samma information finns lagrad på många olika platser i databasen, vilket inte är att rekommendera då det kan leda till problem vid uppdateringar eftersom du måste uppdatera på många olika ställen.
Man bör alltså (oftast) normalisera databasen i så stor utsträckning som möjligt. Värt att notera är att de olika normalformerna nedan bygger på varandra, så för att uppfylla den tredje normalformen måste villkoren för de två första också vara uppfyllda.
Första normalform (1NF)
Varje rad i en kolumn får inte innehålla mer än ett värde. Om ett av banden ovan har två officiella webbplatser skall dessa alltså inte lagras som ”http://www.adress1.com, http://www.adress2.com” utan i två kolumner som då borde heta något i stil med webbplats1 och webbplats2 istället.
Det måste finnas en primär nyckel (eng. primary key) i varje tabell. Detta är en kolumn som unikt identifierar en instans av data (en rad i tabellen)
En primär nyckel kan även bestå av flera kolumner, med villkoret att kombinationen av dessa värden unikt identifiera en rad i tabellen.
Andra normalform (2NF)
Om flera rader har gemensam data, skall denna läggas i en separat tabell.
Relationen mellan den gamla och nya tabellen definieras med en främmande nyckel (eng. foreign key).
Vi använder vårt första exempel för att visa hur databasen som cd-samlingen lagrades i kan skrivas om till två separata tabeller för att följa 2NF:
| id | titel | artist | datum |
|---|---|---|---|
| 1 | Out of Time | R.E.M. | 1991-03-12 |
| 2 | Reveal | R.E.M. | 2001-05-07 |
| 3 | Mental Jewelry | Live | 1992-03-09 |
Tabell 2: Här har vi delat upp databasen i två tabeller med attributet artist som främmande nyckel. Detta för att rader med gemensam data skall brytas ut och läggas i en egen tabell.
| artist | webbplats |
|---|---|
| R.E.M. | www.remhq.com |
| Live | www.friendsoflive.com |
Tabell 3: I detta fallet fanns gemensamma data i kolumnen webbplats. Den har brutits ut och därav följer databasen nu 2NF.
Som ni ser så blir det mer och mer strikt allt eftersom graden på normalform stiger, men det är faktiskt inte så dumt att följa någon form av normalisering när man designar en databas. Har man stora datamängder blir fördelarna extra tydliga då detta gör att varje förändring framöver bara behöver göras i en tabell.
Tredje normalform (3NF)
Placera alla kolumner som inte beror enbart av den primära nyckel i en egen tabell.
Det finns även andra normaliseringsformer. Förutom fjärde och femte normalform finns exemplevis en som heter Boyce—Codd Normal Form (BCNF). Den form man brukar använda i praktiken är dock oftast 3NF eftersom de andra är blir lite väl omständliga om det inte är något jätteprojekt som skall utvecklas.
Vill du ha mer?
Detta var väl grunderna, kort sammanfattade, för att kunna gå på SQL och ”göra något på riktigt”. Vill du ha mer teori finns det mängder att läsa i facklitteratur eller på webben.
Håller du på att utbilda dig, eller är sugen på att vidareutbilda dig för den delen, finns det också möjlighet att läsa en kurs på en YH-utbildning, ett universitet eller en teknisk högskola.