Datamodellering

En database skal være en gjenspeiling av virkeligheten, men den skal samtidig ikke inneholde mer data enn det som er nødvendig. Vi trenger å strukturere dataen på en måte som gjør det effektivt å finne, legge til og endre data. For å komme fram til en slik struktur er det nyttig å lage en visuell modell av databasen. Da kan man se hvilke forhold de forskjellige dataene har til hverandre og på den måten lage en solid struktur for databasen. Å lage en visuell modell av databasen gjør det også enklere å sørge for at databasen er robust og godt designet. Med et godt databasedesign kan vi sørge for at det ikke så lett oppstår feil i databasen.

Før du lager en datamodell, må du stille deg selv en del spørsmål og se for deg hvordan databasen skal brukes.

Den vanligste typen datamodell kalles ER-diagram. ER står for Entity-Relationship og brukes for å planlegge relasjonsdatabaser. I ER-diagram har vi entiteter, eller tabeller, som er koblet sammen med relasjoner.

Noen ganger kan vi ha all informasjonen vi trenger i én tabell, men som oftest trenger vi flere tabeller for å holde orden på informasjonen.

Hvis du skal lage en database med informasjon om vennene dine, trenger du kanskje bare én tabell, slik som denne:

Datamodellen for denne tabellen kan se ut som på bildet til høyre. Legg merke til at i tillegg til navn på kolonnene i tabellen er det lagt inn informasjon om hvilken type data som skal lagres i de ulike feltene. Vi kommer tilbake til datatyper senere.

Du kan også se at vi har lagt til et felt i datamodellen som heter VenneID, og denne har en liten nøkkel ved siden av seg. Dette er et identifikasjonsnummer som er unikt for hver person som legges inn i databasen. Ut fra denne ID-en kan vi finne all annen info om en person i tabellen. Dette feltet med unike data kalles primærnøkkelen til tabellen. Vi kunne også brukt et eksisterende felt som primærnøkkel, men da må vi være sikre på at dataen som skal legges inn i det feltet, er helt unik. Det bør heller ikke være data som kan endres, da primærnøkkelen også brukes til å koble tabeller sammen. Telefonnummer kan være et eksempel på et slikt felt som er unikt for hver person, men som likevel ikke passer som primærnøkkel. En primærnøkkel bør heller ikke være noe som kan endres. Derfor er det vanlig å opprette en slik ID. Vi skal komme mer tilbake til primærnøkler etterhvert.

I tabellen over ser du at vi har lagt inn postnummer og poststed. Dette er to felter som henger sammen, da alle radene i tabellen med samme poststed alltid vil ha samme postnummer. Vi sier at det er en avhengighet mellom de to feltene. Når du lager databaser, bør du unngå avhengigheter i tabellen, da det enkelt kan føre til at ukorrekte data kan legges inn, for eksempel hvis du staver et poststed feil. For å unngå avhengighet skiller vi ut postnummer og poststed i en egen tabell. Vi får da to tabeller:

Koble sammen tabellene

Nå har du to tabeller med informasjon: én med informasjon om venner og én med informasjon om postnummer. For å bruke denne informasjonen i praksis må du koble tabellene sammen med en relasjon. Det gjør vi både visuelt i en datamodell og praktisk ved å sette inn en fremmednøkkel i den ene tabellen. For å forklare hvordan dette gjøres tegner vi opp en datamodell med de to tabellene og en relasjon imellom.

Her ser du datamodellen med postnummer skilt ut i en egen tabell. I postnummer-tabellen er det feltet postnummer som er primærnøkkelen, da det vil være unikt for hver linje i tabellen. Når et felt har informasjon som er helt unik og som må fylles ut, trenger vi ikke lage en egen ID.

Mellom de to tabellene ser du en linje med noen tegn på endene. Denne linjen kalles en relasjon og angir at disse to tabellene er koblet sammen. Tegnene på endene angir at dette er en én-til-mange-relasjon. Vi skal komme tilbake til de forskjellige typene relasjoner senere, men i dette tilfellet betyr det at én venn kan ha ett og bare ett postnummer, mens ett postnummer kan høre til null eller flere venner.

Når vi lager en én-til-mange-relasjon, må vi legge inn primærnøkkelen fra tabellen på "én-siden" inn som et ekstra felt i tabellen på "mange-siden". Dette er for å kunne koble sammen informasjonen i praksis. Det ekstra feltet på mange-siden kalles en fremmednøkkel og er en direkte kobling til primærnøkkelen på én-siden. I figuren over kan du se at feltet postnummer i Venner-tabellen har en rød firkant foran seg. Det angir at dette feltet er en fremmednøkkel. Det betyr at postnummer i Venner-tabellen er koblet til primærnøkkelen postnummer i postnummer-tabellen, og det er denne koblingen som brukes for å finne poststed som hører til postnummeret.

Tenk deg at du skal lage et bilregister der du skal lagre informasjon om en rekke biler og hvem som eier dem. Da trenger du både informasjon om personer og om biler. I tillegg vet du at en person kan eie én eller flere biler, og at en bil kan kun ha én eier. Da vet du allerede at det her dreier seg om en én-til-mange-relasjon med to tabeller, én for informasjon om bilen og én for informasjon om bileieren.

For å lage ER-modellen over må du først spørre hva slags informasjon som er nødvendig. Når du skal lagre informasjon om hvem som eier en bil, trenger du informasjon om navn og telefonnummer, men du trenger ikke informasjon om kjønn, årsinntekt og skostørrelse. Når du skal lagre informasjon om en bil, er det svært mye informasjon du kan legge inn, og da må du avgjøre hva slags info som er nødvendig. For eksempel bør du alltid ha med informasjon som registreringsnummer, bilmerke, modell og årsmodell, men informasjon som farge, antall seter og hjuldimensjon kommer an på hva du skal bruke informasjonen til.

Når du har lagd tabellene og lagt inn feltene, gjenstår det bare å lage en relasjon mellom tabellene. Denne kan være én-til-én (1:1), én-til-mange (1:n) eller mange-til-mange (n:m). I dette tilfellet bruker vi én-til-mange-relasjon, da vi kan si at en bil har bare én eier, men en eier kan eie mange biler.