En liten saga om en databas

Transkript

1 En liten saga om en databas Av Marcus Medina

2 Det här är en liten saga om en databas, öar, broar och en massa personer och saker. Det var en gång en grupp människor. De hade olika namn, de gjorde olika saker och de tyckte om olika sorters mat. Dessa människor hade helt vanliga namn som Johanna, Marie, Niklas, Magnus, Peter, Marcus mm En dag hade Johanna ett fint rött äpple, hon var inte hungrig så hon gav det fina röda äpplet till Niklas. Niklas tyckte om det fina röda äpplet, men då han hade en stor gul banan som han inte skulle äta så gav han den till Peter. Peter hade nyss köpt en stor mumsig chokladkaka och tyckte den stora gula bananen verkade godare så han gav den stora mumsiga chokladen till Marie. Niklas åt upp sitt fina röda äpple Marie la undan den stora mumsiga chokladen i skåpet (hon var inte sugen på choklad just då) Marcus åt en liten söt clementin Magnus gick till restaurangen och åt en stor muffin Johanna lämnade över shoppinglista till Magnus Magnus hade inte tid så Marcus fick ta hand om shoppinglistan Marie åt upp den stora mumsiga chokladen Det hände alltså en massa saker, det var flera människor inblandade och flera objekt som brukades på ett eller annat sätt. I själva berättelsen upprepas en hel del information och det gör att sagan blir lång och samtidigt en smula tråkig. En människa kan förstå texten, men en dator skulle bli förvirrad av händelseförloppet. SELECT page WHERE id = 1

3 För att kunna göra berättelsen enklare skulle man kunna dela upp den i tre listor (eller kolumner). Allt i tabellform Personer Händelser Objekt Johanna att ge Ett fint rött äpple Niklas tycka om Ett fint rött äpple Peter tycka om En stor gul banan Peter Handla En stor mumsig chokladkaka Marie lägga undan En stor mumsig chokladkaka Magnus Äta Restaurang Marcus Äta Clementin Johanna lämna Shoppinglista Marcus ta hand om Shoppinglista Marie Äta En stor mumsig chokladkaka Nu har vi tre kolumner. För att databasen ska kunna förstå informationen får vi skriva in det som data. Alltså snyggt uppdelat tabeller där varje tabell börjar på ett och räknar sedan uppåt. Siffran kallas för ett ID. Personer ID Namn 1 Johanna 2 Marie 3 Niklas 4 Magnus 5 Peter 6 Marcus SELECT page WHERE id = 2

4 Händelser ID Händelse 1 ge 2 tycka om 3 handla 4 lägga undan 5 äta 6 gå 7 Lämna 8 ta hand om Objekt ID Objekt 1 Ett fint rött äpple 2 En stor gul banan 3 En stor mumsig chokladkaka 4 En söt clementin 5 Restaurang 6 En stor muffin 7 Shoppinglista Nu har vi tre tabeller. Varje tabell har ett ID. Det ID är unikt för varje objekt i tabellen. Alltså Niklas har nummer 3, det innebär att ingen annan person har samma ID, ungefär som ett personnummer fast här är det en mindre siffra. Varje händelse har sitt specifika ID likaså varje objekt. Även om Niklas och chokladkakan har samma ID så har de egentligen ingen koppling alls. Man kan poetiskt uttrycka det som att varje tabell är som en ö i databasens hav. För att kunna föra över information mellan tabellerna måste vi skapa en relation (koppling/samband). Det innebär med andra ord att om öarna ska mötas så måste vi bygga broar. Om vi nu tittar på första meningen i sagan En dag hade Johanna ett fint rött äpple, hon var inte hungrig så hon gav det fina röda äpplet till Niklas. Vi kan undersöka meningen genom att ställa följande frågor. SELECT page WHERE id = 3

5 1. Vem gör vad? 2. Vad är det som görs? 3. Vad är det som används? 4. Mot eller med vem görs detta? Vi läser meningen igen och hittar följande svar till frågorna 1. Johanna 2. ge 3. Ett fint rött äpple 4. Niklas Nu har vi all information vi behöver för att förse databasen med information om händelsen. Frågan är nu var vi ska fylla i det och hur vi ska lagra informationen så att kommande generationer inte går miste om det spännande händelseförloppet i sagan. Vi får helt enkelt skapa en ny tabell som håller reda på hur vi ska koppla informationen i databasen. En slags karta på hur broarna dras mellan öarna. Den sortens tabell kallas kopplingstabell (eller sambandstabell) och den innehåller bara hänvisningar till ID i de första tabellerna. Det är en karta med streck och pilar som egentligen inte säger något om man inte vet vilka tabeller som beskrivs. Den här tabellen bygger vi upp precis som frågorna vi ställde innan Koppling/Samband Person1 Handling Objekt Person2 Vi säger som så att Person1 är den som gör något, Handling beskriver vad som görs, Objekt är själva saken som användes och Person2 är mottagaren. Hur beskriver vi första meningen för databasen då? Den informationen vi har är följande Johanna, Ge, Ett fint rött äpple, Niklas men för att slippa skriva detta om och om igen så använder vi oss av IDsiffror i stället. Om vi tar en titt på tabellerna vi skapade först så ser vi att SELECT page WHERE id = 4

6 Johanna = personer ID 1 Ge = Händelse ID 1 Ett fint rött äpple = objekt ID 1 Niklas = personer ID 3 För databasen ser det ut såhär 1,1,1,3 Om vi nu skulle ändra historien att Magnus lämnar en stor mumsig chokladkaka hos Marcus får vi följande värden. Magnus = personer ID 4 Lämna = händelse ID 7 En stor mumsig Chokladkaka=objekt ID 3 Marcus = personer ID 6 För databasen ser det ut såhär 4,7,3,6 För oss ser det helt obeskrivligt dumt att skriva berättelsen i form av 1,1,1,3 men för databasen är saken väldigt klar. Det är det för oss också om vi tittar på tabellerna. Vi går nu tillbaka till vår karta på broarna. Den saknar en sak som de andra har, och det är ett ID. Den tabellen har ingen ID, det behövs inte för informationen kopplas från de andra tabellerna, men tänk om man vill veta vad som hände vid tredje händelsen, hur ska man då veta det? Det kan vi inte. Alltså måste vi ha ett ID. Koppling/Samband (med ID) ID Person1 Handling Objekt Person2 Med hjälp av den här tabellen kan vi nu se vad som hände och när det hände, självklart skulle vi kunna lägga in datum och tid till händelserna också, eller lägga till efternamn på personerna, eller mer utförliga beskrivningar på objekten. Men i detta fallet bryr vi oss inte om detaljer. SELECT page WHERE id = 5

7 Som jag sa innan så är kartan helt betydelselös om man inte vet hur den är kopplad och till vad den är kopplad. Siffrorna 1,1,1,3 har absolut ingen betydelse om man inte vet varför de är där och vad de betyder. Vi får alltså skapa index och relationer. Genom att tala om att ID fälten i varje tabell är ett index så skapar databasen en dold tabell med bara länkar till informationen så att den lättare ska kunna hitta det du söker. Det fungerar ungefär som när man ska beskriva en bil, för mig som är helt ointresserad av bilar är bilen som körde förbi bara en röd liten sak, en bilintresserad vet direkt att det rör sig om en Ford och vilket årtal den är från. En som är riktigt snabb på ögat kommer säker att se bilnumret. Man kan sammanfatta situationen som sådan Jag (helt ointresserad av bilar) har information om bilen (röd, liten) Den bilintresserade har ID till bilen (ford + årtal) Den snabbögde har indexet till bilen, alltså bilnumret. Det skulle ta mig flera år att hitta rätt bil, den bilintresserade skulle kunna hitta de på kortare tid, och den snabbögde hittar bilen på ett par sekunder genom att kontakta bilregistret. Alltså behöver vi indexnycklar och samband. Sambanden beskriver hur broarna går mellan öarna. Då utgår man ifrån att bron alltid står på samma plats från samma ö till samma grann-ö. Vi tittar nu på kopplingstabellen vi gjorde (kartan) Förklarad kopplingstabell ID Person1 Handling Objekt Person2 Händelse Kopplas till index på Persontabellen Kopplas till index på Handling Kopplas till index på Objekt Kopplas till index på Persontabellen Först nu blir kartan läsbar, när vi kan se var informationen hämtas ifrån. SELECT page WHERE id = 6

8 Nu fyller vi i några rader ur sagan En dag hade Johanna ett fint rött äpple, hon var inte hungrig så hon gav det fina röda äpplet till Niklas. Niklas tyckte om det fina röda äpplet, men då han hade en stor gul banan som han inte skulle äta så gav han den till Peter. Peter hade nyss köpt en stor mumsig chokladkaka och tyckte den stora gula bananen verkade godare så han gav den stora mumsiga chokladen till Marie. Jag skriver orden i parantes, men när informationen matas in i databasen sker det enbart i siffror. Fylld kopplingstabell ID Person1 Handling Objekt Person2 1 1 (Johanna) 1 (ge) 1 (Äpple) 3 (Niklas) 2 3 (Niklas) 2 (tycka om) 1 (Äpple) 3 3 (Niklas) 1 (ge) 2 (Banan) 5 (Peter) 4 5 (Peter) 3 (handla) 3 (choklad) 5 5 (Peter) 2 (tycka om) 2 (Banan) 6 5 (Peter) 1 (ge) 3 (choklad) 2 (Marie) I databasens ögon blir det såhär ID Person1 Handling Objekt Person Genom att ge varje person, handling och objekt ett värde så slipper vi skriva om informationen samtidigt som vi kan lägga det i databasen på ett trevligt sätt som inte alls tar upp mycket plats. Vi har nu tabeller där namn och händelser beskrivs i textform, men resten av tabellerna innehåller mest siffror. Det gör att det blir enklare och snabbare att söka i tabellerna. SELECT page WHERE id = 7

9 Om sagan hade handlat om folk som säljer saker på Blocket så skulle tabellerna ändå varit ganska lika det de är nu, händelsetabellen skulle sett annorlunda ut, men resten skulle varit nästan likadant. Det är hela magin med databaser, man skapar listor på information och kopplar sedan ihop det med andra tabeller genom hänvisningar till ID. Självklart hade vi kunnat skapa en tabell med en rad text i var datarad, men det skulle innebära att texten upprepas och att man måste ändra i texten för att ändra i sagan. Det finns olika sätt att dela upp informationen på, och så länge man inte upprepar för mycket data så är alla sätt bra (utom de dåliga). Så var det med det. Nu vet du i alla fall lite mer om hur en dator med databas tänker. Prova själv med att skapa tabellerna, mata in datan och se sedan vilken saga du får ut från databasen... SELECT page WHERE id = 8

10 Disclaimer Alla personer och händelser i detta häfte är uppdiktade och historien är i sin helhet ett resultat av min fantasi (dock är informationen om databasens funktion och uppbyggnad helt sann). All eventuell liknelse med namn på levande eller döda personer är rena tillfälligheter. SELECT page WHERE id = 9