Embedded Files
Introduktion til databaser
Introduktion til databaser
Her er et billede af datalaget fra applab, det vil sige applabs database. Til venstre ses en login side. Til højre ses den tabel i databasen som diverse login data (brugernavn og password) opbevares i.
For at et IT-system kan huske brugerne eller de ting som brugerne gør, må det opbevare data. Hvis et brugernavn skal kunne huskes og findes frem igen, må vi gemme det på en systematisk måde. En computer kan kun finde ting frem, hvis de er gemt og struktureret på en meget systematisk måde. Derfor sætter vi alt hvad der skal huskes og findes ind i systematisk strukturerede tabeller.
En computer har meget svært ved at søge i data som ikke er opbevaret på en systematisk måde. At sætte data ind i en tabel er en god måde at systematisere data på.
En database er som udgangspunkt bare en samling af data opbevaret i én eller flere tabeller.
Når der ofte er flere tabeller skyldes det at det ikke altid giver mening at opbevare alle typer data i samme tabel. Skulle vi f.eks. udvide tabellen på billedet til også at indeholde alle beskeder som de enkelte brugere sender via chatten i vores IT-system, så ville tabellen hurtigt blive meget uoverskuelig fordi hver eneste bruger kan sende mange beskeder. For hver besked en bruger sender ville vi være nødt til at registrere brugernavn og password endnu engang, for ellers ville man ikke kunne se i tabellen, hvilken bruger der havde sendt hvilke beskeder.
Forklarende videoer
Forklarende videoer
Introduktion til databasenøgler
Introduktion til databasenøgler
En video hvor jeg forklarer og viser hvordan man arbejder med primær og fremmed nøgler, for at få tabellerne i sin database til at hænge sammen.
Kunsten at normalisere
Kunsten at normalisere
En video hvor jeg forklarer og viser hvordan man normaliserer en database, samt hvad normalisering er.
Kunsten at lave E/R-diagrammer
Kunsten at lave E/R-diagrammer
En video hvor jeg forklarer og viser hvordan man laver E/R diagrammer med draw.io.
Primærnøgler
Primærnøgler
Yderst til venstre i tabellen foroven er der en kolonne med titlen "ID". Kolonnen indeholder ikke andet en tal. Denne kolonne kalder man for primærnøglen. Kolonnen må kun indeholde unikke tal, hvilket vil sige at intet tal må optræde mere end én gang i kolonnen. På den måde kan man sikre sig at selv hvis to brugere hedder det samme og samme password, så har de stadig to forskellige tal i "ID"-kolonnen. Derfor kan computeren stadig kende forskel på dem.
Hvis der ikke var en primærnøgle og to af brugerne i tabellen hed det samme og havde samme password, så ville computeren ikke kunne kende forskel på dem og ville derfor lave fejl hvis vi for eksempel søgte på én af dem i systemet.
Kort sagt:
En primærnøgle er en kolonne i en tabel der indeholder unikke værdier.
En primærnøgle skal være unik, ellers er den ikke en primærnøgle.
Alle tabeller i en database har som udgangspunkt en primærnøgle.
En primærnøgle gør det muligt at kende forskel på alle tabellens rækker, selv hvis de ellers indeholder lignende informationer.
Fremmednøgler
Fremmednøgler
En fremmednøgle kan defineres her som: En primærnøgle fra en anden tabel.
Dvs. at en fremmednøgle er en kolonne der indeholder de samme værdier som en primærnøgle i en anden tabel, men værdierne behøver ikke være i samme rækkefølge, eller at være unikke.
Grafikken viser et eksempel hvor en kundedatabase består af to små tabeller. I adresse-tabellen er der fire adresser. I kundetabellen er der fire kunder.
Den sidste kolonne i kundetabellen er en fremmednøgle (AdresseID). Ved hjælp af denne fremmednøgle undgås redundansen i at skulle skrive navnet på en adresse for hver gang en kunde bor der. Istedet kan man nu blot skrive adressen ID-nr, eller dens primærnøgle. Et 1-tal betyder således "Rylevej 1" og et 4-tal betyder "Dalen 17".
Normalisering!
Normalisering!
Normaliseringsregler:
Ingen kolonne må gentage en anden kolonnes værdi.
Ingen kolonne må indeholde en sammensat værdi.
Der må kun være én datatype i hver kolonne.
Der må kun være én primærnøgle i hver tabel.
Ingen kolonne må være afhængig af andre kolonner end primærnøglen.
Eksempel på afhængighed i databaser
Eksempel på afhængighed i databaser
På grafikken ses en dårlig (ikke normaliseret database). For det første er primærnøglen brudt da den ikke er unik fordi to brugere begge har "Kunde ID" = 1. For det andet er der en kolonne som ikke er afhængig af primærnøglen.
Afhængighed i databaser handler om at se på tabeller som om de beskriver én bestemt ting og kun én. I eksemplet ovenfor hedder primærnøglen "Kunde ID" derfor må vi antage at tabellen har til formål at beskrive, eller indeholde, informationer om kunder. Derfor giver det mening at kolonnerne "Fornavn" og "Efternavn" er i tabellen, for de er begge vigtige informationer om kunden. Med andre ord er de afhængige af primærnøglen, som er det tal der unikt identificerer kunden. Ligeledes kunne tabellen have kolonner som "Email" og "Telefonnummer" og disse ville også være afhængige kunden (primærnøglen).
Der hvor det går galt er "Kat ID". Kunde nr. 1 ejer to katte og derfor tvinges vi til at registrere alle kundens informationer én gang for hver kat hun ejer. Det skaber redundans (dobbelt-registrering).
For at løse problemet skulle man dele tabellen op i to, hvor den ene tabel har kolonnerne "Kunde ID", "Fornavn" og "Efternavn", og den anden har "Kat ID" som primærnøgle med tal og "Kattenavn" hvor kattenes navne står.
Det gode trick
Det gode trick
Hvis du er i tvivl om hvorvidt en kolonne er afhængig af primærnøglen, så stil følgende spørgsmål:
"Kan én X have flere Y", hvor X er primærnøglen og Y er den kolonne du tjekker.
Eksempel:
Primærnøglen er kolonnen "Kunde ID" og den kolonne vi tjekker er "Kat ID":
"Kan én "kunde" have flere "katte"". Hvis svaret er "ja" så skal "Kat ID" ud i en tabel for sig selv.
Tabelskitser
Tabelskitser
Det kan hurtigt blive uoverskueligt at designe en database, derfor kan det være en fordel at arbejde med skitser. Det er i øvrigt sjældent at man har data klar til databasen før man designer den. Der er ingen grund til at arbejde med hele tabeller.
En tabel fra en kundedatabase
En tabel fra en kundedatabase
På billedet er en tabel fra en kundedatabase. Når du opretter en profil på en shopping-side registreres informationerne om dig i en tabel som denne.
Læg mærke til feltet "Kunde ID". Det er tabellens primærnøgle. Primærnøglen er ofte et tal som skal bruges til at sikre at alle rækker er unikke (der kan ikke være to ens rækker så længe der er en primærnøgle).
I denne tabel kan det eksempelvis være at "Rikke Rytter" får navneforandring. På grund af primærnøglen er det ikke et problem, hun ville stadig være Kunde nr. 1, fordi hun har Kunde ID 1.
Det kan ske at en ny kunde bliver registreret i vores database, som også hedder Hanne Haller (Kunde nr. 2). Det er ikke et problem. Så længe vi har en primærnøgle der er unik kan computeren kende forskel.
Andre eksempler på primærnøgler er dit CPR-nummer, eller din bils registreringsnummer.
Den allervigtigste regel hvad angår primærnøgler er at en primærnøgle SKAL VÆRE UNIK. Hvis den ikke er unik, så er den ikke en primærnøgle.
En tabelskitse over tabellen
En tabelskitse over tabellen
På billedet er en skitse over tabellen fra kundedatabasen (i venstre side).
Læg mærke til hvordan skitsen kun indeholder navnene på kolonnerne. Når man skitserer en tabel er der ingen grund til at have andet end kolonnenavne med, for så kan vi se ca. hvilke typer af data der skal være i tabellen. Vi behøver ikke se rækker/data når vi skitserer databasen.
Læg også mærke til at primærnøglen (kundeID er fremhævet). En tabel har kun én primærnøgle og derfor er det lettest at identificere tabellen ud fra denne.
Eksempel på relation med databaseskitser
Eksempel på relation med databaseskitser
Herunder ses en databaseskitse med to tabeller (Kunde ID og Bil ID). Hvis en kunde kun kunne have én bil, så ville der ikke være grund til at have to tabeller, men fordi en kunde, i teorien, kan have mange biler, så er det bedre at have to tabeller. Havde vi ikke to tabeller, så ville vi være nødt til at registrere den samme kunde flere gange i kundetabellen, for hver gang de havde en ny bil. Med to tabeller kan vi i stedet registrere hver kunde og hver bil én gang og derfor undgår vi redundans (dobbelt-registreringer).
I denne databaseskitse er tabellerne forbundet med fremmednøglen "Kunde ID" i bil-tabellen som henviser til primærnøglen "Kunde ID" i kunde-tabellen.
Herunder er et eksempel hvor man i stedet for at have fremmednøglen "Kunde ID" i bil-tabellen har lavet en relationstabel med fremmednøglerne "Kunde ID" og "Bil ID" som henviser til henholdsvis kunde-tabellen og bil-tabellen. En relationstabel er en tabel der typisk består udelukkende af fremmednøgler. Derfor behøver den ikke en primærnøgle, da kombinationen af fremmednøgler altid er unik. Det skyldes at det aldrig er nødvendigt at registrere den samme relation flere gange, så hvis kunden med Kunde ID nr. 1 ejer bilen med Bil ID nr. 1, så behøver vi kun at registrere det forhold én gang og derfor så er kombinationen af de to fremmednøgler unik.
Her er tabelskitsen sådan som den kunne se ud som færdige tabeller (læg mærke til navnene på kolonner i tabellerne og i skitsen ovenfor):
Den midterste af vores tabeller er i tabelskitsen en "relationstabel" fordi den forbinder de to andre tabeller ved at indeholde en fremmednøgle fra dem hver især. På den måde kan man se at kunde nr.1 et, som vist i tabellen, ejer bil nr. 2 og 3.
At sætte det op på denne måde betyder at vi undgår redundans (dobbelt-registreringer) for vi behøver ikke at registrere en kunde eller bils data flere gange. Hvis vi skal genbruge deres data nu, kan vi bare skrive deres ID. Således er kunden med ID nr. 1 = (Hans, hans@gmail.com, 54783290) og bilen med Bil ID nr. 1 = (Kia, Ceed).
Hvis vi ikke havde en relationstabel og ikke forstod at bruge fremmednøgler, ville vores data se således ud:
Tabellen er redundant fordi vi bliver nødt til at registrere den samme kundes informationer flere gange, fordi han (Hans) ejer flere biler. Dette betyder også at primærnøglen ikke er unik, hvilket gør at et givent IT-system som skal bruge databasen kan have problemer med at identificere Hans som en unik kunde.
Hertil er der en kunde som ikke ejer en bil og derfor er nogle af vores felter tomme, hvilket kan skabe problemer i et IT-system der leder efter biler i vores database.
Tre typer af database-skitser
Tre typer af database-skitser
E/R-diagrammer
E/R-diagrammer
Til venstre i billedet vises et E/R diagram over kunde/katte-databasen som ses i højre side af billedet. De buede linjer viser hvilke tabeller kasserne i diagrammet repræsenterer.
Page updated
Report abuse